From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] KVM: VMX: Gracefully handle faults on VMXON
Date: Sun, 22 Mar 2020 14:37:50 +0100 [thread overview]
Message-ID: <87d094bjdd.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20200321193751.24985-4-sean.j.christopherson@intel.com>
Sean Christopherson <sean.j.christopherson@intel.com> writes:
> Gracefully handle faults on VMXON, e.g. #GP due to VMX being disabled by
> BIOS, instead of letting the fault crash the system. Now that KVM uses
> cpufeatures to query support instead of reading MSR_IA32_FEAT_CTL
> directly, it's possible for a bug in a different subsystem to cause KVM
> to incorrectly attempt VMXON[*]. Crashing the system is especially
> annoying if the system is configured such that hardware_enable() will
> be triggered during boot.
>
> Oppurtunistically rename @addr to @vmxon_pointer and use a named param
> to reference it in the inline assembly.
>
> Print 0xdeadbeef in the ultra-"rare" case that reading MSR_IA32_FEAT_CTL
> also faults.
>
> [*] https://lkml.kernel.org/r/20200226231615.13664-1-sean.j.christopherson@intel.com
> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> ---
> arch/x86/kvm/vmx/vmx.c | 24 +++++++++++++++++++++---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 07634caa560d..3aba51d782e2 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -2218,18 +2218,33 @@ static __init int vmx_disabled_by_bios(void)
> !boot_cpu_has(X86_FEATURE_VMX);
> }
>
> -static void kvm_cpu_vmxon(u64 addr)
> +static int kvm_cpu_vmxon(u64 vmxon_pointer)
> {
> + u64 msr;
> +
> cr4_set_bits(X86_CR4_VMXE);
> intel_pt_handle_vmx(1);
>
> - asm volatile ("vmxon %0" : : "m"(addr));
> + asm_volatile_goto("1: vmxon %[vmxon_pointer]\n\t"
> + _ASM_EXTABLE(1b, %l[fault])
> + : : [vmxon_pointer] "m"(vmxon_pointer)
> + : : fault);
> + return 0;
> +
> +fault:
> + WARN_ONCE(1, "VMXON faulted, MSR_IA32_FEAT_CTL (0x3a) = 0x%llx\n",
> + rdmsrl_safe(MSR_IA32_FEAT_CTL, &msr) ? 0xdeadbeef : msr);
We seem to be acting under an assumption that the fault is (likelt)
caused my disabled VMX feature but afaics the fault can be caused by
passing a bogus pointer too (but that would be a KVM bug, of course).
> + intel_pt_handle_vmx(0);
> + cr4_clear_bits(X86_CR4_VMXE);
> +
> + return -EFAULT;
> }
>
> static int hardware_enable(void)
> {
> int cpu = raw_smp_processor_id();
> u64 phys_addr = __pa(per_cpu(vmxarea, cpu));
> + int r;
>
> if (cr4_read_shadow() & X86_CR4_VMXE)
> return -EBUSY;
> @@ -2246,7 +2261,10 @@ static int hardware_enable(void)
> INIT_LIST_HEAD(&per_cpu(blocked_vcpu_on_cpu, cpu));
> spin_lock_init(&per_cpu(blocked_vcpu_on_cpu_lock, cpu));
>
> - kvm_cpu_vmxon(phys_addr);
> + r = kvm_cpu_vmxon(phys_addr);
> + if (r)
> + return r;
> +
> if (enable_ept)
> ept_sync_global();
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
--
Vitaly
next prev parent reply other threads:[~2020-03-22 13:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-21 19:37 [PATCH v2 0/3] KVM: VMX: Fix for kexec VMCLEAR and VMXON cleanup Sean Christopherson
2020-03-21 19:37 ` [PATCH v2 1/3] KVM: VMX: Always VMCLEAR in-use VMCSes during crash with kexec support Sean Christopherson
2020-03-21 19:37 ` [PATCH v2 2/3] KVM: VMX: Fold loaded_vmcs_init() into alloc_loaded_vmcs() Sean Christopherson
2020-03-22 13:08 ` Vitaly Kuznetsov
2020-03-21 19:37 ` [PATCH v2 3/3] KVM: VMX: Gracefully handle faults on VMXON Sean Christopherson
2020-03-22 13:37 ` Vitaly Kuznetsov [this message]
2020-04-07 11:01 ` [PATCH v2 0/3] KVM: VMX: Fix for kexec VMCLEAR and VMXON cleanup Baoquan He
2020-04-07 12:04 ` Vitaly Kuznetsov
2020-04-08 15:18 ` Baoquan He
2020-04-08 19:44 ` Vitaly Kuznetsov
2020-04-09 1:20 ` Baoquan He
2020-04-09 11:14 ` Vitaly Kuznetsov
2020-04-09 12:57 ` Baoquan He
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d094bjdd.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=wanpengli@tencent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox