On Wed, Sep 21, 2022 at 6:54 AM Borislav Petkov <bp@xxxxxxxxx> wrote: > > On Wed, Sep 21, 2022 at 06:45:24AM -0700, Jim Mattson wrote: > > EFER.LMLSE is not a reserved bit on AMD64 CPUs, unless > > CPUID.80000008:EBX[20] is set (or you're running very, very old > > hardware). > > > > We really shouldn't just decide on a whim to treat EFER.LMSLE as > > reserved under KVM. The guest CPUID information represents our > > detailed contract with the guest software. By setting > > CPUID.80000008:EBX[20], we are telling the guest that if it tries to > > set EFER.LMSLE, we will raise a #GP. > > I understand all that. What I'm asking is, what happens in KVM *after* > your patch 1/3 is applied when a guest tries to set EFER.LMSLE? Does it > #GP or does it allow the WRMSR to succeed? I.e., does KVM check when > reserved bits in that MSR are being set? > > By looking at it, there's kvm_enable_efer_bits() so it looks like KVM > does control which bits are allowed to set and which not...? Yes, after the revert, KVM will treat the bit as reserved, and it will synthesize a #GP, *in violation of the architectural specification.* As I said, we could document this behavior as a KVM erratum. > > If we don't set that bit in the guest CPUID information and we raise > > #GP on an attempt to set EFER.LMSLE, the virtual hardware is > > defective. > > See, this is what I don't get - why is it defective? After the revert, > that bit to KVM is reserved. KVM can't just decide willy nilly to reserve arbitrary bits. If it is in violation of AMD's architectural specification, the virtual CPU is defective. > > We could document this behavior as an erratum, but since a > > mechanism exists to declare that the guest can expect EFER.LMSLE to > > #GP, doesn't it make sense to use it? > > I don't mind all that and the X86_FEATURE bit and so on - I'm just > trying to ask you guys: what is KVM's behavior when the guest tries to > set a reserved EFER bit. > > Maybe I'm not expressing myself precisely enough... I feel the same way. :-( The two patches after the revert are to amend the contract with the guest (as expressed by the guest CPUID table) so that the KVM virtual CPU can raise a #GP on EFER.LMSLE and still conform to the architectural specification. >From the APM, volume 2, 4.12.2 Data Limit Checks in 64-bit Mode: > Data segment limit checking in 64-bit mode is not supported by all processor implementations and has been deprecated. If CPUID Fn8000_0008_EBX[EferLmlseUnsupported](bit 20) = 1, 64-bit mode segment limit checking is not supported and attempting to enable this feature by setting EFER.LMSLE =1 will result in a #GP exception.
