On 12/08/2009 11:17 PM, Jan Kiszka wrote:
I don't see the need for setting any state in kvm_vcpu_events
automatically, on kernel entry (apparently there was consensus that
saving similar state explicitly in qemu was the way to go).
(I don't think so. IMHO the cleaner way is to avoid loading critical
states unless we are resetting or vmloading.)
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.
kvm_arch_put_registers in qemu saves mpstate now that way,
and the same problem is present.
The sites to load vcpu_events would be machine reset and cpu_load
only, right?
That is how qemu use it, currently. But this interface should be
designed with more flexibility. For the (yet theoretical) case you want
to update RIP of a single VCPU, you also have to reset all the
context-related states but maybe not the asynchronously changing ones
like nmi.pending. We have no such use case yet, but KVM should not
prevent them by design (if the change is so trivial).
Yes.
--
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
