Re: [Xen-devel] [PATCH 13/13] Nested Virtualization: hap-on-hap

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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