On Fri, May 17, 2024, Thomas Gleixner wrote: > On Thu, May 16 2024 at 07:39, Sean Christopherson wrote: > > On Thu, May 16, 2024, Weijiang Yang 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. > > > > 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. > > I have to disagree here violently. > > If the exposure of a CPUID bit to a guest requires host side support, > e.g. in xstate handling, then exposing it to a guest is simply not > possible. Ya, I don't disagree, I just didn't realize that CET_USER would be cleared in the supported xfeatures mask.
