On 7/15/2022 3:36 AM, Sean Christopherson wrote:
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.
Yeah, CET definitely can be virtualized without considering host usages,
but to make things
easier, still back on some kind of host side support, e.g., xsaves.
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.
Speaking of MPX, is it really active in recent kernel? I can find little
piece of code at native side,
instead, more code in KVM.
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.
CET may fall into one of the three or combination of them :-), depending
on the complexity
of the implementation.
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.
I'm thinking of tweaking the patches to construct a safe yet flexible
solution based on
a bunch of MSRs/CPUIDs/VMCS fields/XSAVES elements + a few host side
constraints.
Thanks for the enlightenment!
