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

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.html
> 
> 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.

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?

> 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.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel