| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] understanding __linear_l2_table and friends
> > We have to take 4 slots in the L2 handling the top of the VA space,
> > and have the four slots point at the 4 L2s. We can use this
> to access
> > all the L1's and L2's.
>
> That's exactly what I'm doing at the moment.
>
> > We then take another slot in the uppermost L2 and have it
> point at the
> > L3.
>
> That I don't ;)
There are three possible soloutions for L3 accesses :
* wrap them in map_domain_mem. This will be very slow
* burn 2MB of VA space in an L2 to map the L3
* insist on every pagetable having a reserved L1 in which we can steal
a 4KB slot
Both 2 and 3 are plausible, though 3 might waste a little physical
memory unless we arranged such that the kernel could made use of the
remaining slots. Having a per-pagetable L2 with reserved slots is going
to be a pain enough anyhow.
> While I'm at it: Which levels writable pagetables are used
> for (without shadowing)? Only the first? Or also the other ones?
We currently just use them for L1's, as you typically don't see many
batch updates to L2s (at least relatively speaking). We currently use
mmu_update hypercalls for L2 updates, though it probably wouldn't be
much slower if we just used the instruction emulation path. Since its
all hidden in the setpgd macro its not a big deal either way...
In the first instance, it probably makes sense to get PAE working using
hypercalls everywhere, and then debug the emulation path, and finally
enable full writeable pagetables.
Cheers,
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home