qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [v2 PATCH] target-mips: implement UserLocal Register


From: James Hogan
Subject: Re: [Qemu-devel] [v2 PATCH] target-mips: implement UserLocal Register
Date: Wed, 28 May 2014 12:14:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 27/05/14 17:01, James Hogan wrote:
> On 26/05/14 22:18, Andreas Färber wrote:
>> Am 26.05.2014 19:28, schrieb Petar Jovanovic:
>>> RDHWR instruction. To do so, bit 29 of the HWREna register must be set to a
>>> 1 to enable unprivileged access to the register.
>>>
>>> Signed-off-by: Petar Jovanovic <address@hidden>
>>> ---
>>> v2:
>>> - Defined MIPS_HFLAG_CP0UL flag, checks are now based on hflags
>>> - CP0_UserLocal moved to struct TCState
>>> - Added tc->CP0_UserLocal in save_tc/load_tc in target-mips/machine.c
>>> - Reused CP0_UserLocal field for user-mode purpose
>> [...]
>>> diff --git a/target-mips/machine.c b/target-mips/machine.c
>>> index 0a07db8..cbd9d7a 100644
>>> --- a/target-mips/machine.c
>>> +++ b/target-mips/machine.c
>>> @@ -25,6 +25,7 @@ static void save_tc(QEMUFile *f, TCState *tc)
>>>      qemu_put_betls(f, &tc->CP0_TCSchedule);
>>>      qemu_put_betls(f, &tc->CP0_TCScheFBack);
>>>      qemu_put_sbe32s(f, &tc->CP0_Debug_tcstatus);
>>> +    qemu_put_betls(f, &tc->CP0_UserLocal);
>>>  }
>>>  
>>>  static void save_fpu(QEMUFile *f, CPUMIPSFPUContext *fpu)
>>> @@ -173,6 +174,7 @@ static void load_tc(QEMUFile *f, TCState *tc)
>>>      qemu_get_betls(f, &tc->CP0_TCSchedule);
>>>      qemu_get_betls(f, &tc->CP0_TCScheFBack);
>>>      qemu_get_sbe32s(f, &tc->CP0_Debug_tcstatus);
>>> +    qemu_get_betls(f, &tc->CP0_UserLocal);
>>>  }
>>>  
>>>  static void load_fpu(QEMUFile *f, CPUMIPSFPUContext *fpu)
>>
>> You can't just add fields here. When loading you'll need to check the
>> version you're loading for whether or not to load the field, and for
>> saving you need to increment the version.
> 
> Also, I wonder if it makes sense to alter Config3 to enable/disable ULRI
> depending on whether a userlocal is provided, or something like that, so
> that you don't end up restoring a VM with an undefined UserLocal that
> doesn't trap when accessed.

Apologies, ignore that. I see Config3 is already saved/restored so it
would happen automatically.

Cheers
James



reply via email to

[Prev in Thread] Current Thread [Next in Thread]