From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/2] KVM: x86 emulator: Drop EFER.SVME requirement from VMMCALL Date: Tue, 05 Apr 2011 19:18:27 +0300 Message-ID: <4D9B40D3.8050005@redhat.com> References: <1302010111-23431-1-git-send-email-avi@redhat.com> <1302010111-23431-3-git-send-email-avi@redhat.com> <20110405134144.GA19819@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org, Joerg Roedel To: Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:59480 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753573Ab1DEQSi (ORCPT ); Tue, 5 Apr 2011 12:18:38 -0400 In-Reply-To: <20110405134144.GA19819@8bytes.org> Sender: kvm-owner@vger.kernel.org List-ID: 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