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.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
