On Fri, Dec 1, 2023 at 5:05 PM Maciej S. Szmigiero <mail@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On 1.12.2023 00:57, Jim Mattson wrote: > > On Thu, Nov 30, 2023 at 2:00 PM Maciej S. Szmigiero > > <mail@xxxxxxxxxxxxxxxxxxxxx> wrote: > >> I think that if particular guest would work on bare metal it should > >> work on "-cpu host" too - no tinkering should be required for such > >> basic functionality as being able to successfully finish booting. > > > > I disagree. Let's not focus on one particular erratum. If, for > > whatever reason, the host kernel is booted with "noxsaves," I don't > > think KVM should allow a guest to bypass that directive. > > This could be achieved by either adding special "noxsaves" flag > or by setting X86_BUG_XSAVES_AVOID instead of clearing > X86_FEATURE_XSAVES on these CPUs. > > Then the core kernel XSAVES code would check for lack of > X86_BUG_XSAVES_AVOID (in addition to checking for > presence of X86_FEATURE_XSAVES) while KVM would keep using > only X86_FEATURE_XSAVES. This is feasible, on the other hand the erratum is pretty bad. Since the workaround is easy (just disable XSAVEC; and maybe XGETBV1 as well?), you could just do a printk_ratelimited() on the write to HV_X64_MSR_GUEST_OS_ID, in particular if: 1) guest CPUID has XSAVEC and SVM 2) host CPUID does not have XSAVES 3) guest OS id indicates Windows Server 10.x (which is 2016 to 2022), which should be 0x0001040A00??????. Paolo
