On Thu, May 16, 2024, Weijiang Yang wrote: > On 5/2/2024 7:15 AM, Sean Christopherson wrote: > > On Sun, Feb 18, 2024, Yang Weijiang wrote: > > > @@ -696,6 +697,20 @@ void kvm_set_cpu_caps(void) > > > kvm_cpu_cap_set(X86_FEATURE_INTEL_STIBP); > > > if (boot_cpu_has(X86_FEATURE_AMD_SSBD)) > > > kvm_cpu_cap_set(X86_FEATURE_SPEC_CTRL_SSBD); > > > + /* > > > + * Don't use boot_cpu_has() to check availability of IBT because the > > > + * feature bit is cleared in boot_cpu_data when ibt=off is applied > > > + * in host cmdline. > > I'm not convinced this is a good reason to diverge from the host kernel. E.g. > > PCID and many other features honor the host setup, I don't see what makes IBT > > special. > > > > > Hi, Sean, > 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. On the other hand, I can definitely see folks wanting to expose IBT to guests when running non-complaint host kernels, especially when live migration is in play, i.e. when hiding IBT from the guest will actively cause problems.
