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?