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

[Christoph Egger <Christoph.Egger@amd.com>]

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