On Sat, Jun 18, 2022, Yang, Weijiang wrote:
>
> On 6/16/2022 11:28 PM, Paolo Bonzini wrote:
> > If you build with !X86_KERNEL_IBT, KVM can still rely on the FPU state
> > for U_CET state, and S_CET is saved/restored via the VMCS independent of
> > X86_KERNEL_IBT.
>
> A fundamental question is, should KVM always honor host CET enablement
> before expose the feature to guest? i.e., check X86_KERNEL_IBT and
> X86_SHADOW_STACK.
If there is a legitimate use case to NOT require host enablement and it's 100%
safe to do so (within requiring hacks to the core kernel), then there's no hard
requirement that says KVM can't virtualize a feature that's not used by the host.
It's definitely uncommon; unless I'm forgetting features, LA57 is the only feature
that KVM fully virtualizes (as opposed to emulates in software) without requiring
host enablement. Ah, and good ol' MPX, which is probably the best prior are since
it shares the same XSAVE+VMCS for user+supervisor state management. So more than
one, but still not very many.
But, requiring host "support" is the de facto standard largely because features
tend to fall into one of three categories:
1. The feature is always available, i.e. doesn't have a software enable/disable
flag.
2. The feature isn't explicitly disabled in cpufeatures / x86_capability even
if it's not used by the host. E.g. MONITOR/MWAIT comes to mind where the
host can be configured to not use MWAIT for idle, but it's still reported
as supported (and for that case, KVM does have to explicitly guard against
X86_BUG_MONITOR).
3. Require some amount of host support, e.g. exposing XSAVE without the kernel
knowing how to save/restore all that state wouldn't end well.
In other words, virtualizing a feature if it's disabled in the host is allowed,
but it's rare because there just aren't many features where doing so is possible
_and_ necessary.
