From: Bandan Das <bsd@redhat.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: David Hildenbrand <david@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 14:05:14 -0400 [thread overview]
Message-ID: <jpgtw2ialyd.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <20170711135251.GA3326@potion> ("Radim \=\?utf-8\?B\?S3LEjW3DocWZ\?\= \=\?utf-8\?B\?Iidz\?\= message of "Tue, 11 Jul 2017 15:52:52 +0200")
Radim Krčmář <rkrcmar@redhat.com> writes:
> [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. :])
IMO, for now, this should be fine because we are not even passing through the
hardware's eptp switching. Even if there are other vm functions, they
won't be available for the nested case and cause any conflict.
>> > + 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)))
I will reverse the order here but the vm entry check is unnecessary because
the check on the list address is already being done in this function.
> after adding the check.
next prev parent reply other threads:[~2017-07-11 18:05 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ář
2017-07-11 18:05 ` Bandan Das [this message]
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=jpgtw2ialyd.fsf@linux.bootlegged.copy \
--to=bsd@redhat.com \
--cc=david@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox