Avi Kivity wrote:
> On 03/08/2010 03:44 PM, Alexander Graf wrote:
>> Avi Kivity wrote:
>>
>>> On 03/05/2010 06:50 PM, Alexander Graf wrote:
>>>
>>>> We have wrappers to do for example gpr read/write accesses with,
>>>> because the contents of registers could be either in the PACA
>>>> or in the VCPU struct.
>>>>
>>>> There's nothing that says we have to have the guest vcpu loaded
>>>> when using these wrappers though, so let's introduce a flag that
>>>> tells us whether we're inside a vcpu_load context.
>>>>
>>>>
>>>>
>>> On x86 we always access registers within vcpu_load() context. That
>>> simplifies things. Does this not apply here?
>>>
>>> Even so, sometimes guest registers are present on the cpu, and
>>> sometimes in shadow variables (for example, msrs might be loaded or
>>> not). The approach here is to always unload and access the variable
>>> data. See for example vmx_set_msr() calling vmx_load_host_state()
>>> before accessing msrs.
>>>
>>> Seems like this could reduce the if () tree?
>>>
>> Well - it would probably render this particular patch void. In fact, I
>> think it is already useless thanks to the other "always do vcpu_load"
>> patch.
>>
>> As far as the already existing if goes, we can't really get rid of that.
>> I want to be fast in the instruction emulation. Copying around the
>> registers won't help there.
>>
>
> So do it the other way around. Always load the registers (of course,
> do nothing if already loaded) and then access them in just one way. I
> assume during emulation the registers will always be loaded?
During emulation we're always in VCPU_RUN, so the vcpu is loaded.
Do you mean something like:
read_register(num) {
vcpu_load();
read register from PACA(num);
vcpu_put();
}
? Does vcpu_load incur overhead when it doesnt' need to do anything?
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
