On Sat, Sep 17, 2022, Borislav Petkov wrote:
> On Fri, Sep 16, 2022 at 02:00:26PM -0700, Jim Mattson wrote:
> > It's possible that SLES11 Xen 4.0 sets the bit, but never actually
> > uses truncated segments in 64-bit mode. In any case, according to the
> > original commit, it won't boot if setting EFER.LMSLE is not allowed.
>
> How is SLE11 at all relevant to the upstream kernel?
Yeah, I'm inclined to revert the original commit and advertise NO_LSMLE unconditionally.
I don't like the idea of knowingly ignoring the fact that KVM doesn't correctly
virtualize LMSLE.
Xen itself already does exactly this:
commit 23ccf530431561268b0190f0f1b740b618771b7b
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date: Fri Apr 2 14:10:25 2021 +0100
x86/cpuid: Advertise no-lmsl unilaterally to hvm guests
While part of the original AMD64 spec, Long Mode Segment Limit was a feature
not picked up by Intel, and therefore didn't see much adoption in software.
AMD have finally dropped the feature from hardware, and allocated a CPUID bit
to indicate its absence.
Xen has never supported the feature for guests, even when running on capable
hardware, so advertise the feature's absence unilaterally.
There is nothing specifically wrong with exposing this bit to PV guests, but
the PV ABI doesn't include a working concept of MSR_EFER in the first place,
so exposing it to PV guests would be out-of-place.
Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
because as noted in commit f2c6084442 ("x86/SVM: correct boot time cpu_data[] handling"),
Xen broke detection of LMSLE support shortly after it was added in 2010, presumably
before any official release. "Support" was added for HVM guests in by commit
727bc17d20 ("svm: support EFER.LMSLE for guests")
and then broken a few weeks later by commit
566ddbe833 ("x86: Fail CPU bringup cleanly if it cannot initialise HVM.")
Note that Xen did a "safe" WRMSR+RDMSR to detect LMSLE, so either someone added
extra out-of-tree code that caused Xen to fail to boot, or "necessary ... to boot
with nested svm" only meant being able to expose SVM to L2.
Either way, KVM appears to be carrying a half-baked "fix" for a buggy guest that's
long since gone. So like we did in commit 8805875aa473 ("Revert "KVM: nVMX: Do not
expose MPX VMX controls when guest MPX disabled""), I think we should just revert
the "fix".
