[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 13/13] Nested Virtualization: hap-on-hap
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |