| Message ID | 20190307093143.77182-1-xiaoyao.li@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | kvm/x86/vmx: Make the emulation of MSR_IA32_ARCH_CAPABILITIES only for vmx | expand |
On 07/03/19 18:37, Sean Christopherson wrote: > On Thu, Mar 07, 2019 at 05:31:43PM +0800, Xiaoyao Li wrote: >> At present, we report F(ARCH_CAPABILITIES) for x86 arch(both vmx and svm) >> unconditionally, but we only emulate this MSR in vmx. It will cause #GP >> while guest kernel rdmsr(MSR_IA32_ARCH_CAPABILITIES) in an AMD host. >> >> Since MSR IA32_ARCH_CAPABILITIES is an intel-specific MSR, it makes no >> sense to emulate it in svm. Thus this patch chooses to only emulate it >> for vmx, and moves the related handling to vmx related files. > > What about emulating the MSR on an AMD host for testing purpsoes? It > might be a useful way for someone without Intel hardware to test spectre > related flows. > > In other words, an alternative to restricting emulation of the MSR to > Intel CPUS would be to move MSR_IA32_ARCH_CAPABILITIES handling into > kvm_{get,set}_msr_common(). Guest access to MSR_IA32_ARCH_CAPABILITIES > is gated by X86_FEATURE_ARCH_CAPABILITIES in the guest's CPUID, e.g. > RDMSR will naturally #GP fault if userspace passes through the host's > CPUID on a non-Intel system. This is also better because it wouldn't change the guest ABI for AMD processors. Dropping CPUID flags is generally not a good idea. Paolo
On Thu, 2019-03-07 at 19:15 +0100, Paolo Bonzini wrote: > On 07/03/19 18:37, Sean Christopherson wrote: > > On Thu, Mar 07, 2019 at 05:31:43PM +0800, Xiaoyao Li wrote: > > > At present, we report F(ARCH_CAPABILITIES) for x86 arch(both vmx and svm) > > > unconditionally, but we only emulate this MSR in vmx. It will cause #GP > > > while guest kernel rdmsr(MSR_IA32_ARCH_CAPABILITIES) in an AMD host. > > > > > > Since MSR IA32_ARCH_CAPABILITIES is an intel-specific MSR, it makes no > > > sense to emulate it in svm. Thus this patch chooses to only emulate it > > > for vmx, and moves the related handling to vmx related files. > > > > What about emulating the MSR on an AMD host for testing purpsoes? It > > might be a useful way for someone without Intel hardware to test spectre > > related flows. > > > > In other words, an alternative to restricting emulation of the MSR to > > Intel CPUS would be to move MSR_IA32_ARCH_CAPABILITIES handling into > > kvm_{get,set}_msr_common(). Guest access to MSR_IA32_ARCH_CAPABILITIES > > is gated by X86_FEATURE_ARCH_CAPABILITIES in the guest's CPUID, e.g. > > RDMSR will naturally #GP fault if userspace passes through the host's > > CPUID on a non-Intel system. > > This is also better because it wouldn't change the guest ABI for AMD > processors. Dropping CPUID flags is generally not a good idea. > > Paolo Hi, Paolo and Sean, OK, as you think it's better to emulate MSR ARCH_CAPABILITIES on all x86 host, so should I make the same to MSR CORE_CAPABILITY? If so, I will make it for our v5 patches of split lock detection to emualte MSR CORE_CAPABILITY in this way. Thanks, Xiaoyao
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 180373360e34..99ad4a1b5cf7 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1526,7 +1526,6 @@ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long ipi_bitmap_low, unsigned long ipi_bitmap_high, u32 min, unsigned long icr, int op_64_bit); -u64 kvm_get_arch_capabilities(void); void kvm_define_shared_msr(unsigned index, u32 msr); int kvm_set_shared_msr(unsigned index, u64 val, u64 mask); diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index c07958b59f50..1c14eef59b54 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -501,10 +501,12 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, entry->edx &= kvm_cpuid_7_0_edx_x86_features; cpuid_mask(&entry->edx, CPUID_7_EDX); /* - * We emulate ARCH_CAPABILITIES in software even - * if the host doesn't support it. + * MSR IA32_ARCH_CAPABILITIES is intel-specific. + * we emulate it in software even if the host doesn't + * support it. */ - entry->edx |= F(ARCH_CAPABILITIES); + if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) + entry->edx |= F(ARCH_CAPABILITIES); } else { entry->ebx = 0; entry->ecx = 0; diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 30a6bcd735ec..0d4f4fe1bb12 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -1633,6 +1633,27 @@ static inline bool vmx_feature_control_msr_valid(struct kvm_vcpu *vcpu, return !(val & ~valid_bits); } +static u64 vmx_get_arch_capabilities(void) +{ + u64 data; + + rdmsrl_safe(MSR_IA32_ARCH_CAPABILITIES, &data); + + /* + *If we're doing cache flushes (either "always" or "cond") + * we will do one whenever the guest does a vmlaunch/vmresume. + * If an outer hypervisor is doing the cache flush for us + * (VMENTER_L1D_FLUSH_NESTED_VM), we can safely pass that + * capability to the guest too, and if EPT is disabled we're not + * vulnerable. Overall, only VMENTER_L1D_FLUSH_NEVER will + * require a nested hypervisor to do a flush of its own. + */ + if (l1tf_vmx_mitigation != VMENTER_L1D_FLUSH_NEVER) + data |= ARCH_CAP_SKIP_VMENTRY_L1DFLUSH; + + return data; +} + static int vmx_get_msr_feature(struct kvm_msr_entry *msr) { switch (msr->index) { @@ -1640,6 +1661,9 @@ static int vmx_get_msr_feature(struct kvm_msr_entry *msr) if (!nested) return 1; return vmx_get_vmx_msr(&vmcs_config.nested, msr->index, &msr->data); + case MSR_IA32_ARCH_CAPABILITIES: + msr->data = vmx_get_arch_capabilities(); + break; default: return 1; } @@ -4083,7 +4107,7 @@ static void vmx_vcpu_setup(struct vcpu_vmx *vmx) ++vmx->nmsrs; } - vmx->arch_capabilities = kvm_get_arch_capabilities(); + vmx->arch_capabilities = vmx_get_arch_capabilities(); vm_exit_controls_init(vmx, vmx_vmexit_ctrl()); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 941f932373d0..b3ba336c4662 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1202,34 +1202,9 @@ static u32 msr_based_features[] = { static unsigned int num_msr_based_features; -u64 kvm_get_arch_capabilities(void) -{ - u64 data; - - rdmsrl_safe(MSR_IA32_ARCH_CAPABILITIES, &data); - - /* - * If we're doing cache flushes (either "always" or "cond") - * we will do one whenever the guest does a vmlaunch/vmresume. - * If an outer hypervisor is doing the cache flush for us - * (VMENTER_L1D_FLUSH_NESTED_VM), we can safely pass that - * capability to the guest too, and if EPT is disabled we're not - * vulnerable. Overall, only VMENTER_L1D_FLUSH_NEVER will - * require a nested hypervisor to do a flush of its own. - */ - if (l1tf_vmx_mitigation != VMENTER_L1D_FLUSH_NEVER) - data |= ARCH_CAP_SKIP_VMENTRY_L1DFLUSH; - - return data; -} -EXPORT_SYMBOL_GPL(kvm_get_arch_capabilities); - static int kvm_get_msr_feature(struct kvm_msr_entry *msr) { switch (msr->index) { - case MSR_IA32_ARCH_CAPABILITIES: - msr->data = kvm_get_arch_capabilities(); - break; case MSR_IA32_UCODE_REV: rdmsrl_safe(msr->index, &msr->data); break;
At present, we report F(ARCH_CAPABILITIES) for x86 arch(both vmx and svm) unconditionally, but we only emulate this MSR in vmx. It will cause #GP while guest kernel rdmsr(MSR_IA32_ARCH_CAPABILITIES) in an AMD host. Since MSR IA32_ARCH_CAPABILITIES is an intel-specific MSR, it makes no sense to emulate it in svm. Thus this patch chooses to only emulate it for vmx, and moves the related handling to vmx related files. Signed-off-by: Xiaoyao Li <xiaoyao.li@linux.intel.com> --- arch/x86/include/asm/kvm_host.h | 1 - arch/x86/kvm/cpuid.c | 8 +++++--- arch/x86/kvm/vmx/vmx.c | 26 +++++++++++++++++++++++++- arch/x86/kvm/x86.c | 25 ------------------------- 4 files changed, 30 insertions(+), 30 deletions(-)