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/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH 12/13] Nested Virtualization: vram

On Monday 13 September 2010 17:51:15 Tim Deegan wrote:
> At 16:36 +0100 on 13 Sep (1284395780), Christoph Egger wrote:
> > On Monday 13 September 2010 15:50:40 Tim Deegan wrote:
> > > OK.  That's certainly confusing.  I think the fix is to have all the
> > > outward-facing interfaces to the p2m code always operate on the host
> > > (L1->L0) p2m.  None of their callers would know what to do with an L2
> > > pfn anyway.  Only code that explicitly asks for it (e.g. the NPF
> > > handler) should see the L2->L0 p2m.
> >
> > The instruction emulator also must see the L2 -> L0 p2m
> > - to be more precise it is __hvm_copy() that fetches the
> > instruction - in order to be able to emulate instructions
> > for the L2 guest the L1 guest does not intercept.
> It needs to be able to fetch from virtual addresses; if we make
> paging_gva_to_gfn always return an N1 pfn then that should just work.
> Does the instruction emulator need to read N2 pfns for anything else?

The L2 -> L0 p2m (= nestedp2m) is needed to translate the L2 guest's
cr3 into host physical address in order to be able to walk the L2 guest's
page table. Then we have the L2 guest physical address where the
instruction sits. Then the instruction emulator is invoked and operates
as usual with the difference that the nestedp2m is used instead of the


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