From patchwork Wed Apr 15 23:52:42 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Benjamin Serebrin X-Patchwork-Id: 6223421 Return-Path: X-Original-To: patchwork-kvm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 17FBBBF4A7 for ; Wed, 15 Apr 2015 23:53:11 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2835B20306 for ; Wed, 15 Apr 2015 23:53:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3C9C32034B for ; Wed, 15 Apr 2015 23:53:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754994AbbDOXxE (ORCPT ); Wed, 15 Apr 2015 19:53:04 -0400 Received: from mail-qk0-f171.google.com ([209.85.220.171]:33510 "EHLO mail-qk0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932841AbbDOXw6 (ORCPT ); Wed, 15 Apr 2015 19:52:58 -0400 Received: by qkx62 with SMTP id 62so109292469qkx.0 for ; Wed, 15 Apr 2015 16:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=u/0t8KCeZugVG54MfsBsbzVsquhW89IPUx4bvPCAUaE=; b=Sx+lEio/P9o4eKLNSUMqPV7KAyRdoqGALwgbKl/7RIAR6h6nbdgKlw9xisb3RVr0F4 zlKDJDr25aLaueqf+c/PxT5w88n1yCUrs+X8s8YjEpE0CWZlsJXxobCtqv4WaulHigDs gaut2Pl9ecreF93fEum2/PnzrEr6SEQ0HJr9RDDnBJktHWluvCNBrPb9pZG/nFmADcUY xi+6f/uHK0M0jzygh1CtgHQA0bK2JG4kMXGgF/vueGGlKO9L+9xlpLw1FDtV2myH599C BGVp4dxpz8sbLKlARBEq16dojol2J4Dlcejxzy9AN9fORcC8Ac48aMQqRtxLgC05zgpR 9R6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=u/0t8KCeZugVG54MfsBsbzVsquhW89IPUx4bvPCAUaE=; b=L8wXughUMtV4I5O0voaicKC2WLrVRTtSpykXBBuZoee7qoxro+wS+8Om8DBXE8S5AH fCrDn4qiPZu7LvhmuKxTMWba0veD4DFemfXxt4wh00zMn9JWb//sT8FK7HBx912MK0ss /6Vw8tSGq3nQ545rcvOQgH/hrzkv8QQLX69HS7jlwaatUtMuFa3MpTDNEVCGo8w46NRX 5dXv5g8NnVfsWd8QVmb41/cXkdRBZN9BcfanVYFaXditdP1yLgStoDjbZ3IXtyxp5biv Q7OilqRbVX3fKaH2D9iBliGcBHo3GGM8yXDSKj6WOUhVMJdkT/qjjIL6pBh6nfpfNoR+ Ax3A== X-Gm-Message-State: ALoCoQkBOd8yIc8SuQMjMO7t6gymm441w2kvUyXJ+qZtQ1zi78/Ev6+UqXpPc0vmSDZoMRveAHt4 MIME-Version: 1.0 X-Received: by 10.55.43.83 with SMTP id r80mr57326811qkh.80.1429141962662; Wed, 15 Apr 2015 16:52:42 -0700 (PDT) Received: by 10.229.120.201 with HTTP; Wed, 15 Apr 2015 16:52:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Apr 2015 16:52:42 -0700 Message-ID: Subject: Fwd: [RFC] Keeping host value of CR4.MCE (and other bits) live during guest execution From: Benjamin Serebrin To: kvm@vger.kernel.org, pbonzini@redhat.com, luto@amacapital.net Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP There's a bug in kvm/vmx.c: if the host enabled machine check (CR4.MCE==1), the value gets zeroed while the CPU is running in guest context. If a machine check event arrives while the CPU is in guest context and effective CR4.MCE is zero, the machine raises CATERR and crashes. We should make sure the host value of CR4.MCE is always active. There are read and write shadows for the guest to think it wrote its own value. For discussion: there's new complexity with CR4 shadowing (1e02ce4cccdcb9688386e5b8d2c9fa4660b45389). I measure CR4 reads at 24 cycles on haswell and 36 on sandybridge, which compares well with L2 miss costs. Is the shadowing worth the complexity? CR4 is also cached (with no real consistency mechanism) in the VMCS at the time of guest VCPU creation. If there is ever a change in CR4 value over time, or if CR4 is different on different CPUs in the system, all this logic gets broken. Thanks, Ben --- The host's decision to enable machine check exceptions should remain in force during non-root mode. KVM was writing 0 to cr4 on VCPU reset and passed a slightly-modified 0 to the vmcs.guest_cr4 value. Tested: Inject machine check while a guest is spinning. Before the change, if guest CR4.MCE==0, then the machine check is escalated to Catastrophic Error (CATERR) and the machine dies. If guest CR4.MCE==1, then the machine check causes VMEXIT and is handled normally by host Linux. After the change, injecting a machine check causes normal Linux machine check handling. --- arch/x86/kvm/vmx.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) /* -- -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index a214104..44c8d24 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -3456,8 +3456,16 @@ static void vmx_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3) static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4) { - unsigned long hw_cr4 = cr4 | (to_vmx(vcpu)->rmode.vm86_active ? - KVM_RMODE_VM_CR4_ALWAYS_ON : KVM_PMODE_VM_CR4_ALWAYS_ON); + /* + * Pass through host's Machine Check Enable value to hw_cr4, which + * is in force while we are in guest mode. Do not let guests control + * this bit, even if host CR4.MCE == 0. + */ + unsigned long hw_cr4 = + (read_cr4() & X86_CR4_MCE) | + (cr4 & ~X86_CR4_MCE) | + (to_vmx(vcpu)->rmode.vm86_active ? + KVM_RMODE_VM_CR4_ALWAYS_ON : KVM_PMODE_VM_CR4_ALWAYS_ON); if (cr4 & X86_CR4_VMXE) {