Messages in this thread | | | Date | Mon, 22 May 2023 09:02:00 +0800 | Subject | Re: [RFC PATCH v2 06/11] KVM: x86: Advertise ARCH_CAP_VIRTUAL_ENUM support | From | Xiaoyao Li <> |
| |
On 5/19/2023 5:57 PM, Chao Gao wrote: > On Thu, May 18, 2023 at 06:14:40PM +0800, Xiaoyao Li wrote: >>> static u32 msr_based_features[ARRAY_SIZE(msr_based_features_all)]; >>> @@ -1591,7 +1593,8 @@ static unsigned int num_msr_based_features; >>> ARCH_CAP_SKIP_VMENTRY_L1DFLUSH | ARCH_CAP_SSB_NO | ARCH_CAP_MDS_NO | \ >>> ARCH_CAP_PSCHANGE_MC_NO | ARCH_CAP_TSX_CTRL_MSR | ARCH_CAP_TAA_NO | \ >>> ARCH_CAP_SBDR_SSDP_NO | ARCH_CAP_FBSDP_NO | ARCH_CAP_PSDP_NO | \ >>> - ARCH_CAP_FB_CLEAR | ARCH_CAP_RRSBA | ARCH_CAP_PBRSB_NO) >>> + ARCH_CAP_FB_CLEAR | ARCH_CAP_RRSBA | ARCH_CAP_PBRSB_NO | \ >>> + ARCH_CAP_VIRTUAL_ENUM) >> >> We cannot do it. >> >> Otherwise, an AMD L1 with X86_FEATURE_ARCH_CAPABILITIES configured is >> possible to expose MSR_VIRTUAL_ENUMERATION to L2 while no support for it. > > How does AMD L1 see the ARCH_CAP_VIRTUAL_ENUM feature in the first > place? because ... > >> >>> static u64 kvm_get_arch_capabilities(void) >>> { >>> @@ -1610,6 +1613,17 @@ static u64 kvm_get_arch_capabilities(void) >>> */ >>> data |= ARCH_CAP_PSCHANGE_MC_NO; >>> + /* >>> + * Virtual enumeration is a paravirt feature. The only usage for now >>> + * is to bridge the gap caused by microarchitecture changes between >>> + * different Intel processors. And its usage is linked to "virtualize >>> + * IA32_SPEC_CTRL" which is a VMX feature. Whether AMD SVM can benefit >>> + * from the same usage and how to implement it is still unclear. Limit >>> + * virtual enumeration to VMX. >>> + */ >>> + if (static_call(kvm_x86_has_emulated_msr)(NULL, MSR_VIRTUAL_ENUMERATION)) >>> + data |= ARCH_CAP_VIRTUAL_ENUM; > > the feature is exposed on Intel CPUs only. > > Do you mean AMD L1 created on Intel L0? and Intel L0 even emulates > nested (SVM) support for the L1? This sounds a very contrived case.
you are right. I was thinking of an rare case but ignored the fact that VMX doesn't nested svm.
Sorry for it.
>>> + >>> /* >>> * If we're doing cache flushes (either "always" or "cond") >>> * we will do one whenever the guest does a vmlaunch/vmresume. >>
| |