On 5/17/2024 12:58 AM, Sean Christopherson wrote:
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.
So I need to remove the trick here for guest IBT, right?
Side topic:
When X86_FEATURE_SHSTK and X86_FEATURE_IBT (no ibt=off set) are available on host side, then host XFEATURE_CET_USER is enabled. In this case, we still *need* below patch: https://lore.kernel.org/all/20240219074733.122080-3-weijiang.yang@xxxxxxxxx/ to correctly enable XFEATURE_CET_USER in *guest kernel*, because VMM userspace can enable IBT alone for guest by -cpu host -shstk, am I right?
