| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] xen: provide pse36 cpuid bit
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
|
|
|
| |
|
Home