From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [PATCH v4 03/13] nEPT: Fix wrong test in kvm_set_cr3 Date: Wed, 31 Jul 2013 16:02:37 +0800 Message-ID: <51F8C49D.1070109@linux.vnet.ibm.com> References: <1374750001-28527-1-git-send-email-gleb@redhat.com> <1374750001-28527-4-git-send-email-gleb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Jun Nakajima , Yang Zhang , pbonzini@redhat.com To: Gleb Natapov Return-path: Received: from e23smtp06.au.ibm.com ([202.81.31.148]:45210 "EHLO e23smtp06.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754976Ab3GaICr (ORCPT ); Wed, 31 Jul 2013 04:02:47 -0400 Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 31 Jul 2013 17:54:45 +1000 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [9.190.235.152]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id 57CBA3578051 for ; Wed, 31 Jul 2013 18:02:41 +1000 (EST) Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r6V7l0A91769978 for ; Wed, 31 Jul 2013 17:47:00 +1000 Received: from d23av01.au.ibm.com (localhost [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r6V82eja003734 for ; Wed, 31 Jul 2013 18:02:40 +1000 In-Reply-To: <1374750001-28527-4-git-send-email-gleb@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/25/2013 06:59 PM, Gleb Natapov wrote: > From: Nadav Har'El > > 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. > Reviewed-by: Xiao Guangrong