WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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