From: Sean Christopherson <seanjc@google.com>
To: Binbin Wu <binbin.wu@linux.intel.com>
Cc: Kai Huang <kai.huang@intel.com>, Chao Gao <chao.gao@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"robert.hu@linux.intel.com" <robert.hu@linux.intel.com>
Subject: Re: [PATCH v6 2/7] KVM: VMX: Use is_64_bit_mode() to check 64-bit mode
Date: Wed, 29 Mar 2023 10:34:45 -0700 [thread overview]
Message-ID: <ZCR2PBx/4lj9X0vD@google.com> (raw)
In-Reply-To: <b9e9dd1c-2213-81c7-cd45-f5cf7b86610b@linux.intel.com>
On Wed, Mar 29, 2023, Binbin Wu wrote:
>
> On 3/29/2023 10:04 AM, Huang, Kai wrote:
> > On Wed, 2023-03-29 at 09:27 +0800, Binbin Wu wrote:
> > > On 3/29/2023 7:33 AM, Huang, Kai wrote:
> > > > On Tue, 2023-03-21 at 14:35 -0700, Sean Christopherson wrote:
> > > > > On Mon, Mar 20, 2023, Chao Gao wrote:
> > > > > > On Sun, Mar 19, 2023 at 04:49:22PM +0800, Binbin Wu wrote:
> > > > > > > get_vmx_mem_address() and sgx_get_encls_gva() use is_long_mode()
> > > > > > > to check 64-bit mode. Should use is_64_bit_mode() instead.
> > > > > > >
> > > > > > > Fixes: f9eb4af67c9d ("KVM: nVMX: VMX instructions: add checks for #GP/#SS exceptions")
> > > > > > > Fixes: 70210c044b4e ("KVM: VMX: Add SGX ENCLS[ECREATE] handler to enforce CPUID restrictions")
> > > > > > It is better to split this patch into two: one for nested and one for
> > > > > > SGX.
> > > > > >
> > > > > > It is possible that there is a kernel release which has just one of
> > > > > > above two flawed commits, then this fix patch cannot be applied cleanly
> > > > > > to the release.
> > > > > The nVMX code isn't buggy, VMX instructions #UD in compatibility mode, and except
> > > > > for VMCALL, that #UD has higher priority than VM-Exit interception. So I'd say
> > > > > just drop the nVMX side of things.
> > > > But it looks the old code doesn't unconditionally inject #UD when in
> > > > compatibility mode?
> > > I think Sean means VMX instructions is not valid in compatibility mode
> > > and it triggers #UD, which has higher priority than VM-Exit, by the
> > > processor in non-root mode.
> > >
> > > So if there is a VM-Exit due to VMX instruction , it is in 64-bit mode
> > > for sure if it is in long mode.
> > Oh I see thanks.
> >
> > Then is it better to add some comment to explain, or add a WARN() if it's not in
> > 64-bit mode?
>
> I also prefer to add a comment if no objection.
>
> Seems I am not the only one who didn't get it� : )
I would rather have a code change than a comment, e.g.
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index f63b28f46a71..0460ca219f96 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -4931,7 +4931,8 @@ int get_vmx_mem_address(struct kvm_vcpu *vcpu, unsigned long exit_qualification,
int base_reg = (vmx_instruction_info >> 23) & 0xf;
bool base_is_valid = !(vmx_instruction_info & (1u << 27));
- if (is_reg) {
+ if (is_reg ||
+ WARN_ON_ONCE(is_long_mode(vcpu) && !is_64_bit_mode(vcpu))) {
kvm_queue_exception(vcpu, UD_VECTOR);
return 1;
}
The only downside is that querying is_64_bit_mode() could unnecessarily trigger a
VMREAD to get the current CS.L bit, but a measurable performance regressions is
extremely unlikely because is_64_bit_mode() all but guaranteed to be called in
these paths anyways (and KVM caches segment info), e.g. by kvm_register_read().
And then in a follow-up, we should also be able to do:
@@ -5402,7 +5403,7 @@ static int handle_vmread(struct kvm_vcpu *vcpu)
if (instr_info & BIT(10)) {
kvm_register_write(vcpu, (((instr_info) >> 3) & 0xf), value);
} else {
- len = is_64_bit_mode(vcpu) ? 8 : 4;
+ len = is_long_mode(vcpu) ? 8 : 4;
if (get_vmx_mem_address(vcpu, exit_qualification,
instr_info, true, len, &gva))
return 1;
@@ -5476,7 +5477,7 @@ static int handle_vmwrite(struct kvm_vcpu *vcpu)
if (instr_info & BIT(10))
value = kvm_register_read(vcpu, (((instr_info) >> 3) & 0xf));
else {
- len = is_64_bit_mode(vcpu) ? 8 : 4;
+ len = is_long_mode(vcpu) ? 8 : 4;
if (get_vmx_mem_address(vcpu, exit_qualification,
instr_info, false, len, &gva))
return 1;
next prev parent reply other threads:[~2023-03-29 17:34 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-19 8:49 [PATCH v6 0/7] Linear Address Masking (LAM) KVM Enabling Binbin Wu
2023-03-19 8:49 ` [PATCH v6 1/7] KVM: x86: Explicitly cast ulong to bool in kvm_set_cr3() Binbin Wu
2023-03-20 1:30 ` Binbin Wu
2023-03-19 8:49 ` [PATCH v6 2/7] KVM: VMX: Use is_64_bit_mode() to check 64-bit mode Binbin Wu
2023-03-20 12:36 ` Chao Gao
2023-03-20 12:51 ` Binbin Wu
2023-03-21 21:35 ` Sean Christopherson
2023-03-22 1:09 ` Binbin Wu
2023-03-28 23:33 ` Huang, Kai
2023-03-29 1:27 ` Binbin Wu
2023-03-29 2:04 ` Huang, Kai
2023-03-29 2:08 ` Binbin Wu
2023-03-29 17:34 ` Sean Christopherson [this message]
2023-03-29 22:46 ` Huang, Kai
2023-04-03 3:37 ` Binbin Wu
2023-04-03 11:24 ` Huang, Kai
2023-04-03 15:02 ` Sean Christopherson
2023-04-03 23:13 ` Huang, Kai
2023-04-04 1:21 ` Binbin Wu
2023-04-04 1:53 ` Huang, Kai
2023-04-04 2:45 ` Binbin Wu
2023-04-04 3:09 ` Huang, Kai
2023-04-04 3:15 ` Binbin Wu
2023-04-04 3:27 ` Binbin Wu
2023-04-04 1:31 ` Binbin Wu
2023-04-04 6:14 ` Binbin Wu
2023-03-20 22:36 ` Huang, Kai
2023-03-19 8:49 ` [PATCH v6 3/7] KVM: x86: Virtualize CR4.LAM_SUP Binbin Wu
2023-03-19 8:49 ` [PATCH v6 4/7] KVM: x86: Virtualize CR3.LAM_{U48,U57} Binbin Wu
2023-03-30 8:33 ` Yang, Weijiang
2023-03-30 8:40 ` Binbin Wu
2023-03-19 8:49 ` [PATCH v6 5/7] KVM: x86: Introduce untag_addr() in kvm_x86_ops Binbin Wu
2023-03-20 12:07 ` Chao Gao
2023-03-20 12:23 ` Binbin Wu
2023-03-29 1:54 ` Binbin Wu
2023-03-19 8:49 ` [PATCH v6 6/7] KVM: x86: Untag address when LAM applicable Binbin Wu
2023-03-20 11:51 ` Chao Gao
2023-03-20 11:56 ` Binbin Wu
2023-03-20 12:04 ` Binbin Wu
2023-03-29 5:02 ` Binbin Wu
2023-03-19 8:49 ` [PATCH v6 7/7] KVM: x86: Expose LAM feature to userspace VMM Binbin Wu
2023-03-20 8:57 ` Chao Gao
2023-03-20 12:00 ` Binbin Wu
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=ZCR2PBx/4lj9X0vD@google.com \
--to=seanjc@google.com \
--cc=binbin.wu@linux.intel.com \
--cc=chao.gao@intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=robert.hu@linux.intel.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;
as well as URLs for NNTP newsgroup(s).