From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: [PATCH 13/13] Nested Virtualization: hap-on-hap Date: Mon, 20 Dec 2010 17:27:23 +0100 Message-ID: <201012201727.23672.Christoph.Egger@amd.com> References: <201011121945.57564.Christoph.Egger@amd.com> <201012081132.01901.Christoph.Egger@amd.com> <20101208105508.GD9912@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20101208105508.GD9912@whitby.uk.xensource.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Wednesday 08 December 2010 11:55:08 Tim Deegan wrote: > At 10:32 +0000 on 08 Dec (1291804321), Christoph Egger wrote: > > On Wednesday 08 December 2010 11:17:15 Tim Deegan wrote: > > > At 17:49 +0000 on 02 Dec (1291312156), Christoph Egger wrote: > > > > > My comments on why p2m_flush_locked() isn't enough to reclaim an > > > > > in-use p2m for recycling still stand. > > > > > > > > Can you point me to the mail in the ML archive you refer to, please? > > > > > > It's the discussion at the end of this email: > > > http://lists.xensource.com/archives/html/xen-devel/2010-09/msg00624.htm > > >l > > > > Tnx. I see it is related to your suggestion to check cr3 against -1 you > > already mentioned. > > It's similar, but different. In particular, checking CR3 against -1 > may not fix it. It's possible that I'm just missing the path on vmentry > that checks the p2m hasn't been reassigned. My comments are based on the seventh patch series I just sent out. The assumption is that the p2m is *empty*. So in case it is reassigned the (v)cpu will fall out with a nested page fault since the MMU can't do a page table walk. > > Quoting my two concerns from before: > > > Is this enough? If this p2m might be in host_vmcb->h_cr3 somewhere on > > > another vcpu, then you need to make sure that vcpu gets reset not to > > > use it any more. > > > > There are three possibilities: > > An other vcpu is in VMRUN emulation before a nestedp2m is assigned. > > In this case, it will get a new nestedp2m as it won't find its 'old' > > nestedp2m anymore. > > > > An other vcpu is in VMRUN emulation after a nestedp2m is assigned. > > It will VMEXIT with a nested page fault. > > Why? Because the p2m is empty. The MMU can not do a page table walk. > > An other vcpu already running l2 guest. > > It will VMEXIT with a nested page fault immediately. > > Hmm. It will exit for the TLB shootdown IPI, but I think you need to > clear vcpu_nestedhvm(v).nh_p2m on the other vcpu to make sure it doesn't > re-enter with the p2m you've just recycled. The p2m is empty so I don't see a problem when it gets recycled. Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632