From patchwork Fri Apr 26 06:43:25 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Nakajima, Jun" X-Patchwork-Id: 2491071 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 E1BD03FC64 for ; Fri, 26 Apr 2013 06:43:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758208Ab3DZGns (ORCPT ); Fri, 26 Apr 2013 02:43:48 -0400 Received: from mail-da0-f42.google.com ([209.85.210.42]:56156 "EHLO mail-da0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753605Ab3DZGnq (ORCPT ); Fri, 26 Apr 2013 02:43:46 -0400 Received: by mail-da0-f42.google.com with SMTP id n15so557630dad.1 for ; Thu, 25 Apr 2013 23:43:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:date:message-id:x-mailer:in-reply-to :references:x-gm-message-state; bh=YDDOUFGdvP/geR0L0LGj5071dr3dXaIDB0sEGneWRaw=; b=icnIceGLrxG1Nk9+oZizmlvMv9W+tdlHoCcmj/nrSy4tfrttFUy4fgWBlCkaF4CYVl bx6x03BdXcIt0WNpVb/Op/PiDqlIJVwD/151ax8w/SV9dIvcfNKUNC+1QKnFiCk6TOGJ fUdS4B598WP7MKmvYFrswVmbPqMSjN6a/mxbWGedstrK8wTddDfCE20P3uHHz1KOpugf rzfkdTrHP1XAn6sJQd/BohQAXFL0jr7ZZka+I+gEnHeVhvb379FBkHOuk2SuvwSrec3i Jl4P0y7kee/CZDyXexqkppBMEIpeffNj//vncAt8VWVpUmD6iR0j5ceqjgELPS3Iks7l Iegg== X-Received: by 10.67.1.4 with SMTP id bc4mr29215383pad.109.1366958626280; Thu, 25 Apr 2013 23:43:46 -0700 (PDT) Received: from localhost (c-98-207-34-191.hsd1.ca.comcast.net. [98.207.34.191]) by mx.google.com with ESMTPSA id qh4sm11450840pac.8.2013.04.25.23.43.44 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 25 Apr 2013 23:43:45 -0700 (PDT) From: Jun Nakajima To: kvm@vger.kernel.org Subject: [PATCH 05/11] nEPT: Fix wrong test in kvm_set_cr3 Date: Thu, 25 Apr 2013 23:43:25 -0700 Message-Id: <1366958611-6935-5-git-send-email-jun.nakajima@intel.com> X-Mailer: git-send-email 1.8.2.1.610.g562af5b In-Reply-To: <1366958611-6935-4-git-send-email-jun.nakajima@intel.com> References: <1366958611-6935-1-git-send-email-jun.nakajima@intel.com> <1366958611-6935-2-git-send-email-jun.nakajima@intel.com> <1366958611-6935-3-git-send-email-jun.nakajima@intel.com> <1366958611-6935-4-git-send-email-jun.nakajima@intel.com> X-Gm-Message-State: ALoCoQlZXenqjTrsCjfQlabeZXt3KGZM/chKsvQTqKgTTe+CQh3E2oYNfLceUk3mzp8vlA846R7H 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 Signed-off-by: Jun Nakajima Signed-off-by: Xinhao Xu --- arch/x86/kvm/x86.c | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index e172132..c34590d 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -659,17 +659,6 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3) */ } - /* - * 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);