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
prev parent 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.