On 02/21/2010 03:14 PM, Avi Kivity wrote:
On 02/21/2010 03:09 PM, Joerg Roedel wrote:
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?
(Either synthetic msrs, or an new state ioctl). The state would
contain a bit that says whether the guest is in guest or host mode.
However, since we're breaking the architecture one way or another,
let's just go with the synthetic INTR intercept.
On the other hand, there is no equivalent intercept in vmx. The
"external interrupt" exit can be configured to run an INTACK cycle and
capture the vector in a vmcs field, and there's no vector we can insert
there (Xen for example uses this).
--
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
