On 04/05/2011 04:41 PM, Joerg Roedel wrote:
On Tue, Apr 05, 2011 at 04:28:31PM +0300, Avi Kivity wrote:
> VMMCALL requires EFER.SVME to be enabled in the host, not in the guest, which
> is what check_svme() checks.
Well, yes and no. The guest has no dedicated EFER. EFER is switched in
VMRUN which is why SVME must be set in the VMCBs EFER. This value makes
it into the arch.efer too with Nested-SVM.
According to the documentation VMMCALL throws an #UD if SVME is 0 which
is why I added the check. On the other hand, at host-level it throws
always an #UD and in the guest EFER.SVME is always enabled, so the check
doesn't really make sense. I just added it because is is documented.
If the guest invokes VMMCALL, EFER.SVME refers to the host (and since
we're running a guest, it's bound to be on). However if a nested guest
invokes VMMCALL, then EFER.SVME refers to the guest. So the check
should look something like
if nested guest and not efer.svme:
#UD
--
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
