From: Christoph Egger <Christoph.Egger@amd.com>
To: Tim Deegan <Tim.Deegan@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Dong, Eddie" <eddie.dong@intel.com>
Subject: Re: Re: [PATCH 12/13] Nested Virtualization: vram
Date: Mon, 13 Sep 2010 18:08:34 +0200 [thread overview]
Message-ID: <201009131808.35671.Christoph.Egger@amd.com> (raw)
In-Reply-To: <20100913155115.GL3844@whitby.uk.xensource.com>
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
hostp2m.
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
next prev parent reply other threads:[~2010-09-13 16:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-01 15:17 [PATCH 12/13] Nested Virtualization: vram Christoph Egger
2010-09-08 15:07 ` Tim Deegan
2010-09-08 15:47 ` Christoph Egger
2010-09-13 13:16 ` Tim Deegan
2010-09-13 13:32 ` Christoph Egger
2010-09-13 13:50 ` Tim Deegan
2010-09-13 15:36 ` Christoph Egger
2010-09-13 15:51 ` Tim Deegan
2010-09-13 16:08 ` Christoph Egger [this message]
2010-09-13 16:17 ` Tim Deegan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201009131808.35671.Christoph.Egger@amd.com \
--to=christoph.egger@amd.com \
--cc=Tim.Deegan@citrix.com \
--cc=eddie.dong@intel.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.