On 6/16/2022 10:18 PM, Peter Zijlstra wrote:
On Thu, Jun 16, 2022 at 12:21:20PM +0200, Paolo Bonzini wrote:
On 6/16/22 12:12, Peter Zijlstra wrote:
Do I understand this right in that a host without X86_KERNEL_IBT cannot
run a guest with X86_KERNEL_IBT on? That seems unfortunate, since that
was exactly what I did while developing the X86_KERNEL_IBT patches.
I'm thinking that if the hardware supports it, KVM should expose it,
irrespective of the host kernel using it.
For IBT in particular, I think all processor state is only loaded and stored
at vmentry/vmexit (does not need XSAVES), so it should be feasible.
That would be the S_CET stuff, yeah, that's VMCS managed. The U_CET
stuff is all XSAVE though.
Thank you Peter and Paolo!
In this version, I referenced host kernel settings when expose
X86_KERNEL_IBT to guest.
The reason would be _IF_ host, for whatever reason, disabled the IBT
feature, exposing the
feature blindly to guest could be risking, e.g., hitting some issues
host wants to mitigate.
The actual implementation depends on the agreement we got :-)
But funny thing, CPUID doesn't enumerate {U,S}_CET separately. It *does*
enumerate IBT and SS separately, but for each IBT/SS you have to
implement both U and S.
Exactly, the CPUID enumeration could be a pain point for the KVM solution.
It makes {U,S}_CET feature control harder for guest.
That was a problem with the first series, which only implemented support
for U_CET while advertising IBT and SS (very much including S_CET), and
still is a problem with this series because S_SS is missing while
advertised.
KVM has problem advertising S_SS alone to guest when U_CET(both SS and
IBT) are
not available to guest. I would like to hear the voice from community on
how to
make the features control straightforward and reasonable. Existing CPUID
enumeration
cannot advertise {U, S}_SS and {U,S}_IBT well.
