xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Tim Deegan <tim@xen.org>
To: Christoph Egger <Christoph.Egger@amd.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [PATCH] nestedsvm: fix paging mode
Date: Thu, 4 Oct 2012 14:23:55 +0100	[thread overview]
Message-ID: <20121004132355.GF38243@ocelot.phlegethon.org> (raw)
In-Reply-To: <506D7DBB.7000900@amd.com>

At 14:14 +0200 on 04 Oct (1349360091), Christoph Egger wrote:
> On 10/04/12 12:37, Tim Deegan wrote:
> 
> > At 15:50 +0200 on 01 Oct (1349106630), Christoph Egger wrote:
> >> On 09/27/12 16:53, Tim Deegan wrote:
> >>
> >>> At 16:01 +0200 on 21 Sep (1348243291), Christoph Egger wrote:
> >>>>
> >>>> On VMRUN and VMEXIT emulation update the paging mode
> >>>> for Shadow-on-Nested. This allows Xen to walk the
> >>>> l1 hypervisors shadow page table correctly.
> >>>> Problem found with 64bit Win7 and 32bit XPMode where
> >>>> Win7 switches forth and back between long mode and
> >>>> PAE legacy pagetables.
> >>>>
> >>>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> >>>
> >>> Don't you have to do this in other cases as well?  I think that
> >>> shadow-on-shadow might need it, at least.
> >>
> >> It is needed for all cases where the l1 guest does shadow paging.
> >> This includes: Shadow-on-Nested and Shadow-on-Shadow.
> > 
> > I've looked more closely at this and now I'm more confused. :)
> > 
> > Hap-on-hap seems to be OK without it because the special case in
> > paging_gva_to_gfn() does the right thing, using the nestedmode's pt
> > walker.
> > 
> > Why is that not good enough for shadow-on-hap?  Is there another path
> > that does unguarded pt walks?  If so:
> >  - why is that path not a problem for hap-on-hap; and
> >  - shouldn't that be handled the same way, i.e. either handle everything
> >    at lookup time, like paging_gva_to_gfn() does, or handle everything
> >    by switching modes at VMRUN/EXIT?
> 
> 
> If the l1 guest does not do nested paging then Xen doesn't use the
> nestedmode's pt walker.

Ah, I was led astray by the nestedhvm_is_n2() check.  It turns out that:
nestedhvm_is_n2() returns 0 for guests that are in n2 but aren't
hap-on-hap.  That's pretty confusing, and I encourage you to change it.

Anyway, I've checked in a modified version of your patch, as 
http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a9c84069c248
Please check that it still does what you wanted. :)

Cheers,

Tim.

  reply	other threads:[~2012-10-04 13:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-21 14:01 [PATCH] nestedsvm: fix paging mode Christoph Egger
2012-09-27 14:53 ` Tim Deegan
2012-10-01 13:50   ` Christoph Egger
2012-10-04 10:37     ` Tim Deegan
2012-10-04 12:14       ` Christoph Egger
2012-10-04 13:23         ` Tim Deegan [this message]
2012-10-05  9:07           ` Christoph Egger

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=20121004132355.GF38243@ocelot.phlegethon.org \
    --to=tim@xen.org \
    --cc=Christoph.Egger@amd.com \
    --cc=xen-devel@lists.xen.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).