| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] PAE issue (32-on-64 work)
> >Why not just have a fixed per-vcpu L4 and L3, into which the 4 PAE
L3's
> >get copied on every cr3 load?
> >It's most analogous to what happens today.
>
> In the shadowing (PAE, 32bit) case (a code path that, as I said, I'd
rather
> see ripped out).
Why? It's essential to allow PAE PGDs to live above 4GB, which is a PITA
otherwise.
> In the general 64-bit case, this would add another
> (needless) distinct code path. I think I still like better the idea of
> clearing out the final 518 entries.
>
> >We've thought of removing the page-size restriction on PAE L3's in
the
> >past, but it's pretty low down the priority list as it typically
doesn't
> >cost a great deal of memory.
>
> Ah. I would have felt different.
Most machines probably only have a hundred processes (we can exclude
kernel threads and threads in general), hence maybe a few hundred KB
wasted, tops.
If we did remove the size restriction, we'd still want to put them in
their own slab cache rather than the general 32b cache, as you don't
want them being shared with other non-PGD data. This is a PITA that
mandates how we handle shadowing of PAE PGDs in the HVM case where we
can't control what they're allocated alongside.
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home