Re: [PATCH v5 08/19] KVM:x86: Report KVM supported CET MSRs as to-be-saved
From: Paolo Bonzini
Date: Fri Aug 04 2023 - 18:02:10 EST
On 8/4/23 20:51, Sean Christopherson wrote:
+ case MSR_IA32_PL0_SSP ... MSR_IA32_INT_SSP_TAB:
+ if (!kvm_is_cet_supported())
shall we consider the case where IBT is supported while SS isn't
(e.g., in L1 guest)?
Yes, but userspace should be able to access SHSTK MSRs even only IBT is
exposed to guest so far as KVM can support SHSTK MSRs.
Why should userspace be allowed to access SHSTK MSRs in this case? L1 may not
even enumerate SHSTK (qemu removes -shstk explicitly but keeps IBT), how KVM in
L1 can allow its userspace to do that?
+1. And specifically, this isn't about SHSTK being exposed to the guest, it's about
SHSTK being _supported by KVM_. This is all about KVM telling userspace what MSRs
are valid and/or need to be saved+restored. If KVM doesn't support a feature,
then the MSRs are invalid and there is no reason for userspace to save+restore
the MSRs on live migration.
I think you three are talking past each other.
There are four cases:
- U_CET/S_CET supported by the host and exposed (obvious).
- U_CET/S_CET supported by the host, IBT or SHSTK partially exposed. The
MSRs should still be guest-accessible and bits that apply to absent features
should be reserved (bits 0-1 for SHSTK, bits 2-63 for IBT).
- U_CET/S_CET supported by the host, IBT or SHSTK not exposed. The MSRs
should still be host-accessible and writable to the default value. This is
clearer if you think that KVM_GET_MSR_INDEX_LIST is a system ioctl. Whether
to allow writing 0 from the guest is debatable.
- U_CET/S_CET not supported by the host. Then the MSRs should not be
enabled and should not be in KVM_GET_MSR_INDEX_LIST, and also IBT/SHSTK
should not be in KVM_GET_SUPPORTED_CPUID.
In my opinion it is reasonable to require both U_CET and S_CET to be
supported from the beginning in the host in order to support CET. It
is simpler and keeps the feature matrix at bay.
Paolo