From: "Radim Krčmář" <rkrcmar@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Bandan Das <bsd@redhat.com>,
kvm@vger.kernel.org, pbonzini@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor
Date: Tue, 11 Jul 2017 15:52:52 +0200 [thread overview]
Message-ID: <20170711135251.GA3326@potion> (raw)
In-Reply-To: <2d50ebc4-9328-ce08-b55b-6a331ee13cc3@redhat.com>
[David did a great review, so I'll just point out things I noticed.]
2017-07-11 09:51+0200, David Hildenbrand:
> On 10.07.2017 22:49, Bandan Das wrote:
> > When L2 uses vmfunc, L0 utilizes the associated vmexit to
> > emulate a switching of the ept pointer by reloading the
> > guest MMU.
> >
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > Signed-off-by: Bandan Das <bsd@redhat.com>
> > ---
> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > @@ -7784,11 +7801,46 @@ static int handle_vmfunc(struct kvm_vcpu *vcpu)
> > }
> >
> > vmcs12 = get_vmcs12(vcpu);
> > - if ((vmcs12->vm_function_control & (1 << function)) == 0)
> > + if (((vmcs12->vm_function_control & (1 << function)) == 0) ||
> > + WARN_ON_ONCE(function))
>
> "... instruction causes a VM exit if the bit at position EAX is 0 in the
> VM-function controls (the selected VM function is
> not enabled)."
>
> So g2 can trigger this WARN_ON_ONCE, no? I think we should drop it then
> completely.
It assumes that vm_function_control is not > 1, which is (should be)
guaranteed by VM entry check, because the nested_vmx_vmfunc_controls MSR
is 1.
> > + goto fail;
The rest of the code assumes that the function is
VMX_VMFUNC_EPTP_SWITCHING, so some WARN_ON_ONCE is reasonable.
Writing it as
WARN_ON_ONCE(function != VMX_VMFUNC_EPTP_SWITCHING)
would be cleared and I'd prefer to move the part that handles
VMX_VMFUNC_EPTP_SWITCHING into a new function. (Imagine that Intel is
going to add more than one VM FUNC. :])
> > + if (!nested_cpu_has_ept(vmcs12) ||
> > + !nested_cpu_has_eptp_switching(vmcs12))
> > + goto fail;
This brings me to a missing vm-entry check:
If “EPTP switching” VM-function control is 1, the “enable EPT”
VM-execution control must also be 1. In addition, the EPTP-list address
must satisfy the following checks:
• Bits 11:0 of the address must be 0.
• The address must not set any bits beyond the processor’s
physical-address width.
so this one could be
if (!nested_cpu_has_eptp_switching(vmcs12) ||
WARN_ON_ONCE(!nested_cpu_has_ept(vmcs12)))
after adding the check.
next prev parent reply other threads:[~2017-07-11 13:52 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 20:49 [PATCH v4 0/3] Expose VMFUNC to the nested hypervisor Bandan Das
2017-07-10 20:49 ` [PATCH v4 1/3] KVM: vmx: Enable VMFUNCs Bandan Das
2017-07-10 20:49 ` [PATCH v4 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor Bandan Das
2017-07-10 20:49 ` [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching " Bandan Das
2017-07-11 7:51 ` David Hildenbrand
2017-07-11 8:39 ` Paolo Bonzini
2017-07-11 13:52 ` Radim Krčmář [this message]
2017-07-11 18:05 ` Bandan Das
2017-07-11 19:12 ` Radim Krčmář
2017-07-11 19:34 ` Bandan Das
2017-07-11 17:58 ` Bandan Das
2017-07-11 18:22 ` Jim Mattson
2017-07-11 18:35 ` Bandan Das
2017-07-11 19:13 ` Radim Krčmář
2017-07-11 19:38 ` Bandan Das
2017-07-11 20:22 ` Radim Krčmář
2017-07-11 20:45 ` Bandan Das
2017-07-12 13:41 ` Radim Krčmář
2017-07-12 18:04 ` Bandan Das
2017-07-11 18:24 ` Bandan Das
2017-07-11 19:32 ` Radim Krčmář
2017-07-11 19:50 ` Bandan Das
2017-07-11 20:21 ` Radim Krčmář
2017-07-11 20:34 ` Bandan Das
2017-07-11 20:45 ` Radim Krčmář
2017-07-11 21:08 ` Bandan Das
2017-07-12 13:24 ` Radim Krčmář
2017-07-12 18:11 ` Bandan Das
2017-07-12 19:18 ` Radim Krčmář
2017-07-17 17:58 ` Bandan Das
2017-07-19 9:30 ` Radim Krčmář
2017-07-19 17:54 ` Bandan Das
2017-07-13 15:39 ` David Hildenbrand
2017-07-13 17:08 ` Bandan Das
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=20170711135251.GA3326@potion \
--to=rkrcmar@redhat.com \
--cc=bsd@redhat.com \
--cc=david@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@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.