On 02/21/2010 03:09 AM, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 02:54:01PM +0200, Avi Kivity wrote:
So, if some other cpu (or the guest itself, with appropriate
permissions) modifies the msr permission bitmap, svm will not notice
this? svm loads the bitmap during entry?
Yes.
Ugh. So we have non-reversible architectural state all over again.
There are ways around this problem, all ugly, but the easiest is
shadowing the MSR permission bitmap.
I don't think you can tell, unless the host cpu modifying the vmcb is
synchronized with the guest (or the guest modifies its own vmcb). But
this is all academic.
Hmm, another thing comes to mind. We would need some redesign of the
nested_svm code to allow userspace to put a vcpu directly into nested
state. With the MSR approach, all userspace does is to write MSRs into
the vcpu before the first run?
How does MSR_KVM_NESTED_SVM_ACTIVE not solve this problem?
--
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
