| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] understanding __linear_l2_table and friends
> > The alternative is to hack PAE Linux to force the L2
> containing kernel
> > mappings to be per-pagetable rather than shared. The
> downside of the
> > is that we use an extra 4KB per pagetable, and have the hassle of
> > faulting in kernel L2 mappings on demand (like non-PAE
> Linux has to).
> > This plays nicely with the TLB flush filter, and is fine
> for SMP guests.
>
> I think that one is better.
Good. The only hassle is the need for Linux's demand filling of L2 slots
pointing to kernel L1's, but seeing as non-PAE Linux has similar code
already, this shouldn't be too hard.
> The topmost L2 table with the
> kernel mappings is a special case anyway because it also has
> the hypervisor hole and thus differs from the other three L2
> tables when it comes to allocation and verification (and
> maybe other places as well).
> I'm considering adding a new page type for the topmost L2 in
> PAE mode to handle this. Comments? Better ideas?
You can just maintain the va back ptr index for L2's as well as L1's (we
may want to do this anyway to implement writeable L2 pagetables at some
point). If the va back ptr == 3, you know its an L2 with hypervisor
slots.
Part of validating an L3 will be to check that the top slot is filled in
and pointing to a validated L2. When alloc_l2_table is called with a
back pointer index of 3 it will install hypervisor entries in the L2.
I think this is much neater.
Best,
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home