From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH v2 5/8] KVM: nVMX: Fix guest CR3 read-back on VM-exit Date: Tue, 6 Aug 2013 17:41:17 +0300 Message-ID: <20130806144117.GD8218@redhat.com> References: <0816baee846f9c8f4d54c6738b2582a95f9c56a3.1375778397.git.jan.kiszka@web.de> <20130806101236.GN8218@redhat.com> <20130806140248.GB8218@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kiszka , Paolo Bonzini , kvm , Xiao Guangrong , "Nakajima, Jun" , Arthur Chunqi Li To: "Zhang, Yang Z" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:6703 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754515Ab3HFOlY (ORCPT ); Tue, 6 Aug 2013 10:41:24 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Aug 06, 2013 at 02:12:51PM +0000, Zhang, Yang Z wrote: > Gleb Natapov wrote on 2013-08-06: > > On Tue, Aug 06, 2013 at 11:44:41AM +0000, Zhang, Yang Z wrote: > >> Gleb Natapov wrote on 2013-08-06: > >>> On Tue, Aug 06, 2013 at 10:39:59AM +0200, Jan Kiszka wrote: > >>>> From: Jan Kiszka > >>>> > >>>> If nested EPT is enabled, the L2 guest may change CR3 without any exits. > >>>> We therefore have to read the current value from the VMCS when > >>>> switching to L1. However, if paging wasn't enabled, L0 tracks > >>>> L2's CR3, and > >>>> GUEST_CR3 rather contains the real-mode identity map. So we need > >>>> to retrieve CR3 from the architectural state after conditionally > >>>> updating it - and this is what kvm_read_cr3 does. > >>>> > >>> I have a headache from trying to think about it already, but > >>> shouldn't > >>> L1 be the one who setups identity map for L2? I traced what > >>> vmcs_read64(GUEST_CR3)/kvm_read_cr3(vcpu) return here and do not > >>> see > >> Here is my understanding: > >> In vmx_set_cr3(), if enabled ept, it will check whether target vcpu > >> is enabling > > paging. When L2 running in real mode, then target vcpu is not enabling > > paging and it will use L0's identity map for L2. If you read GUEST_CR3 > > from VMCS, then you may get the L2's identity map not L1's. > >> > > Yes, but why it makes sense to use L0 identity map for L2? I didn't see > > different vmcs_read64(GUEST_CR3)/kvm_read_cr3(vcpu) values because L0 > > and L1 use the same identity map address. When I changed identity > > address L1 configures vmcs_read64(GUEST_CR3)/kvm_read_cr3(vcpu) are > > indeed different, but the real CR3 L2 uses points to L0 identity map. If > > I zero L1 identity map page L2 still works. > > > If L2 in real mode, then L2PA == L1PA. So L0's identity map also works if L2 is in real mode. > That not the point. It may work accidentally for kvm on kvm, but what if other hypervisor plays different tricks and builds different ident map for its guest? -- Gleb.