On Thu, May 16, 2024, Dave Hansen wrote: > On 5/16/24 07:39, Sean Christopherson wrote: > >> We synced the issue internally, and got conclusion that KVM should honor host > >> IBT config. In this case IBT bit in boot_cpu_data should be honored. With > >> this policy, it can avoid CPUID confusion to guest side due to host ibt=off > >> config. > > What was the reasoning? CPUID confusion is a weak justification, e.g. it's not > > like the guest has visibility into the host kernel, and raw CPUID will still show > > IBT support in the host. > > I'm basically arguing for the path of least resistance (at least to start). > > We should just do what takes the least amount of code for now that > results in mostly sane behavior, then debate about making it perfect later. > > In other words, let's say the place we'd *IDEALLY* end up is that guests > can have any random FPU state which is disconnected from the host. But > the reality, for now, is that the host needs to have XFEATURE_CET_USER > set in order to pass it into the guest and that means keeping > X86_FEATURE_SHSTK set. > > If you want guest XFEATURE_CET_USER, you must have host > X86_FEATURE_SHSTK ... for now. Ah, because fpu__init_system_xstate() will clear XFEATURE_CET_USER via the X86_FEATURE_SHSTK connection in xsave_cpuid_features. Please put something to that effect in the changelog. "this literally won't work (without more changes)" is very different than us making a largely arbitrary decision.
