On 5/17/2024 10:26 PM, Sean Christopherson wrote:
On Fri, May 17, 2024, Thomas Gleixner wrote:
On Thu, May 16 2024 at 07:39, Sean Christopherson wrote:
On Thu, May 16, 2024, Weijiang Yang 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.
On the other hand, I can definitely see folks wanting to expose IBT to guests
when running non-complaint host kernels, especially when live migration is in
play, i.e. when hiding IBT from the guest will actively cause problems.
I have to disagree here violently.
If the exposure of a CPUID bit to a guest requires host side support,
e.g. in xstate handling, then exposing it to a guest is simply not
possible.
Ya, I don't disagree, I just didn't realize that CET_USER would be cleared in the
supported xfeatures mask.
For host side support, fortunately, this patch already has some checks for that. But for userspace
CPUID config, it allows IBT to be exposed alone.
IIUC, this series tries to tie IBT to SHSTK feature, i.e., IBT cannot be exposed as an independent
feature to guest without exposing SHSTK at the same time. If it is, then below patch is not needed
anymore:
https://lore.kernel.org/all/20240219074733.122080-3-weijiang.yang@xxxxxxxxx/
I'd check and clear IBT bit from CPUID when userspace enables only IBT via KVM_SET_CPUID2.
And update related code of the series given the implicit dependency.
Thanks!
