Re: [PATCH v2] KVM: x86: Extend KVM_SET_VCPU_EVENTS with selective updates

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]

Avi Kivity wrote:
> On 12/15/2009 06:43 PM, Jan Kiszka wrote:
>>
>>> I now agree.  But instead of SCOPE_RESET and SCOPE_RUNTIME (or whatever
>>> that was), how about SCOPE_GPR, SCOPE_FPU, SCOPE_SREGS etc.  That means
>>> the backing code in kvm.c doesn't have to know what qemu is interested
>>> in wrt SCOPE_RESET, and it's easier for readers to infer what is meant.
>>>      
>> That's not my idea. I want to be able to state the scope in generic,
>> arch-independent, KVM-unaware code. What the scope actually means /wrt
>> writeback should only be defined in the arch-specific kvm service
>> implementing it. Your suggestion would go in the wrong direction IMO.
>>    
> 
> What I'm worried is how to tell which registers go in which scope?  And
> contrariwise, when doing a cpu_synchronize_state(), how to select the
> scope?  It's easy when there's just normal and reset, but what happens
> when we gain another one?  The code may not know who calls it.
> 

In my original patch, scopes could only be widened: If we first sync'ed
for potential register modifications and then added a sync for reset,
the latter ruled on write-back. In my current idea, there would be three
sync scopes (in increasing order):

CPU_SYNC_RUNTIME  - only write states that cannot not change
                    asynchronously
CPU_SYNC_RESET    - write everything that would change during a CPU
                    reset (excludes TSC MSR on x86)
CPU_SYNC_COMPLETE - write everything

I think these scopes are generic enough to match problems of other archs
beyond x86 as well (though I don't if any exist).

Hope I'll find some time soon to code this down, but I'm currently
stuffed with unrelated issues.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]