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.
