All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	kvm@vger.kernel.org, Joerg Roedel <joerg.roedel@amd.com>
Subject: Re: [PATCH 2/2] KVM: x86 emulator: Drop EFER.SVME requirement from VMMCALL
Date: Tue, 05 Apr 2011 19:18:27 +0300	[thread overview]
Message-ID: <4D9B40D3.8050005@redhat.com> (raw)
In-Reply-To: <20110405134144.GA19819@8bytes.org>

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


      reply	other threads:[~2011-04-05 16:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-05 13:28 [PATCH 0/2] Fix a couple of bugs in VMMCALL Avi Kivity
2011-04-05 13:28 ` [PATCH 1/2] KVM: x86 emulator: Re-add VendorSpecific tag to VMMCALL insn Avi Kivity
2011-04-05 13:28 ` [PATCH 2/2] KVM: x86 emulator: Drop EFER.SVME requirement from VMMCALL Avi Kivity
2011-04-05 13:41   ` Joerg Roedel
2011-04-05 16:18     ` Avi Kivity [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D9B40D3.8050005@redhat.com \
    --to=avi@redhat.com \
    --cc=joerg.roedel@amd.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.