Re: [Xen-devel] [PATCH] xen: provide pse36 cpuid bit

[Tim Deegan <tim@xxxxxxx>]

At 15:59 +0100 on 27 Oct (1319731185), Keir Fraser wrote:
> >> This patch appears to advertise PSE36 support to guests without actually
> >> supporting PSE36.  Or am I missing something?
> > 
> > That's right. The paging format differs only in 32bit legacy mode.
> > Since Hyper-V is not running in 32bit legacy mode but insists on having
> > these cpuid bits present it is sufficient to just populate them to the
> > guest when guest paging mode != 32bit legacy mode.
> 
> It would be nice if we didn't have to toggle CPUID.PSE36 based on current
> guest mode. How hard would it be to pull out bits 35..32 of a physical
> address from bits 16..13 of a legacy 32-bit PDE whose PS flag = 1?

Should be easy.  It's another bit of logic on the pagetable walker, but
nothing too expensive, and we already handle other simlar special cases.

> I'm actually surprised we don't do it already, it's so trivial! The code
> explicitly says we don't though, and for a reason that makes no sense to
> me...

If you mean this:

 * PSE disabled / PSE36
 * We don't support any modes other than PSE enabled, PSE36 disabled.
 * Neither of those would be hard to change, but we'd need to be able to
 * deal with shadows made in one mode and used in another.

the worry was that we'd need a whole nother shadow mode to handle the
case where one VCPU was in normal 32-bit and another was in PSE36 (since
they can't share shadows).

As it happens the current code does detect PSE-disabled in shadow mode
but just DTRT for the current VCPU, so a mix of PSE-enabled and
PSE-disabled VCPUs will get unpredicatble results from shadow
pagetables. :(

Which means that supporting PSE36 to the same degree (i.e. assuming all
VCPUs behave the same, or if they don't they don't share pagetables)
would be OK too. :)

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel