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:
signature.asc
Description: OpenPGP digital signature
