From patchwork Wed Aug 1 14:39:15 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nadav Har'El X-Patchwork-Id: 1264441 Return-Path: X-Original-To: patchwork-kvm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id CD9053FC23 for ; Wed, 1 Aug 2012 14:39:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755174Ab2HAOj3 (ORCPT ); Wed, 1 Aug 2012 10:39:29 -0400 Received: from e06smtp16.uk.ibm.com ([195.75.94.112]:53825 "EHLO e06smtp16.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755004Ab2HAOj2 (ORCPT ); Wed, 1 Aug 2012 10:39:28 -0400 Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 1 Aug 2012 15:39:26 +0100 Received: from d06nrmr1507.portsmouth.uk.ibm.com (9.149.38.233) by e06smtp16.uk.ibm.com (192.168.101.146) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 1 Aug 2012 15:39:18 +0100 Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q71EdHxC2846908 for ; Wed, 1 Aug 2012 15:39:17 +0100 Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q71EH3eQ016952 for ; Wed, 1 Aug 2012 10:17:03 -0400 Received: from rice.haifa.ibm.com (rice.haifa.ibm.com [9.148.8.107]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q71EH2nX016918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 10:17:02 -0400 Received: from rice.haifa.ibm.com (lnx-nyh.haifa.ibm.com [127.0.0.1]) by rice.haifa.ibm.com (8.14.5/8.14.4) with ESMTP id q71EdF3x023865; Wed, 1 Aug 2012 17:39:15 +0300 Received: (from nyh@localhost) by rice.haifa.ibm.com (8.14.5/8.14.5/Submit) id q71EdFYE023863; Wed, 1 Aug 2012 17:39:15 +0300 Date: Wed, 1 Aug 2012 17:39:15 +0300 Message-Id: <201208011439.q71EdFYE023863@rice.haifa.ibm.com> X-Authentication-Warning: rice.haifa.ibm.com: nyh set sender to "Nadav Har'El" using -f Cc: Joerg.Roedel@amd.com, avi@redhat.com, owasserm@redhat.com, abelg@il.ibm.com, eddie.dong@intel.com, yang.z.zhang@intel.com To: kvm@vger.kernel.org From: "Nadav Har'El" References: <1343831766-nyh@il.ibm.com> Subject: [PATCH 05/10] nEPT: Fix wrong test in kvm_set_cr3 x-cbid: 12080114-3548-0000-0000-000002B63B64 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org kvm_set_cr3() attempts to check if the new cr3 is a valid guest physical address. The problem is that with nested EPT, cr3 is an *L2* physical address, not an L1 physical address as this test expects. As the comment above this test explains, it isn't necessary, and doesn't correspond to anything a real processor would do. So this patch removes it. Note that this wrong test could have also theoretically caused problems in nested NPT, not just in nested EPT. However, in practice, the problem was avoided: nested_svm_vmexit()/vmrun() do not call kvm_set_cr3 in the nested NPT case, and instead set the vmcb (and arch.cr3) directly, thus circumventing the problem. Additional potential calls to the buggy function are avoided in that we don't trap cr3 modifications when nested NPT is enabled. However, because in nested VMX we did want to use kvm_set_cr3() (as requested in Avi Kivity's review of the original nested VMX patches), we can't avoid this problem and need to fix it. Signed-off-by: Nadav Har'El --- arch/x86/kvm/x86.c | 11 ----------- 1 file changed, 11 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 --- .before/arch/x86/kvm/x86.c 2012-08-01 17:22:47.000000000 +0300 +++ .after/arch/x86/kvm/x86.c 2012-08-01 17:22:47.000000000 +0300 @@ -659,17 +659,6 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu, u */ } - /* - * Does the new cr3 value map to physical memory? (Note, we - * catch an invalid cr3 even in real-mode, because it would - * cause trouble later on when we turn on paging anyway.) - * - * A real CPU would silently accept an invalid cr3 and would - * attempt to use it - with largely undefined (and often hard - * to debug) behavior on the guest side. - */ - if (unlikely(!gfn_to_memslot(vcpu->kvm, cr3 >> PAGE_SHIFT))) - return 1; vcpu->arch.cr3 = cr3; __set_bit(VCPU_EXREG_CR3, (ulong *)&vcpu->arch.regs_avail); vcpu->arch.mmu.new_cr3(vcpu);