[Xen-ia64-devel] RE: PMT vs. 3 level page table (was: Xen/ia64 - global or per VP VHPT)

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

 > > I left the 3-level page tables in for
> > guest-physical-to-machine-physical because I expected 
> physical memory
> > on ia64 to generally be much 
> > larger than x86 and the existing Linux method for handling VA
> > spaces seemed suitable.  Is there Xen-common code for this
> > that is better?  (I think this code is archdep right now, though
> > I suppose it could be moved back from archdep to common if it
> > is truly architecture-independent, e.g. if ppc could use it too.)
> > 
> Dan, maybe I didn't understand the benefit well. What is the 
> benifit of 3 level page table?
> PMT is very strightforward for VMM although it may consume 
> more memory in IA64 than in IA32.
> In my strightforward thinking, a PMT even consume less memory 
> than page table.
>  What is the reason for 3 level page table? 
> BTW, I am assume HV always present guest linear memory space 
> from 0 -- XXX except domain 0 which is directly mapped, and I 
> guess your 3 level page table is also per
> domain instance.

I wasn't really justifying the benefit of the 3-level
page table, just providing the history and original
reasoning.

Yes, the 3-level page table is per-domain (except domain0)
and is used only for guest-physical to machine-physical lookup
for domains other than domain0.

The only real benefits of the 3-level page table are:

1) it works, uses well-tested code (from Linux) and is
   well understood by most system software developers
2) it can cover a very large guest-physical address space.
   In fact when Greg Edwards did the rebase to 2.6.11, he
   grabbed the new Linux code for 4-level page tables so
   it could now cover a very very very large address space :-)
3) it is based entirely on page-size dynamically malloc'ed
   units of memory so it is not necessary to pre-allocate
   a large table when a new domain is instantiated

An obvious disadvantage for the 3-level page table is
performance.  A straight lookup table would be much faster,
and perturb the cache and DTLB/VHPT less.  However, I don't
think lookups are very frequent so performance is probably
not an important issue.  You are also correct that it
would consume less memory, though by a very small margin
since the first- and second- levels are a very small fraction
of the total size of the third level.

I am certainly open to a better implementation though, unless
this implementation just doesn't work for VTi, I would think
there are higher priority things to work on.

Yes, Xen/ia64 presents a guest-physical memory starting
at zero (except for domain0) however this need not be
the case -- it could be a domain-creation-time administrative
parameter.  Note also that guest-physical memory is created
"on demand" -- only when it is read/written.  Thus if a guest
is given 4GB of memory but only uses 1GB, the other 3GB is
usable by other domains' ballooning.

Dan

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