Re: [PATCH 2/3] xen/p2m: Using INVALID_MFN instead of mfn_valid

[Tim Deegan <tim@xen.org>]

At 10:17 -0700 on 16 Aug (1345112267), Andres Lagar-Cavilla wrote:
> > max_mapped_pfn should be the highest entry that's even had a mapping in
> > the p2m.  Its intent was to provide a fast path exit from p2m lookups in
> > the (at the time) common case where _emulated_ MMIO addresses were
> > higher than all the actual p2m mappings, and the cost of a failed lookup
> > (on 32-bit) was a page fault in the linear map.  Also, at the time, the
> > p2m wasn't typed and we didn't support direct MMIO, so mfn_valid() was
> > equivalent to 'entry is present'.
> >
> > These days, I'm not sure how useful max_mapped_pfn is, since (a) for any
> > VM with >3GB RAM the emulated MMIO lookups are not avoided, and (b) on
> > 64-bit builds there's not pagefault for a failed lookup.  Also it seems to
> > have been abused in a few places to do for() loops that touch every PFN
> > instead of just walking the tries.  So I might get rid of it after 4.2
> > is out.
> 
> max_mapped_pfn also helps keep XENMEM_maximum_gpfn O(1).

Ergh, true.  With a little tidying up in the tree update code (to
eliminate empty nodes) it will still be O(1) - just walking
rightmost-first down a trie of fixed height.  But that's a little
more work than I hoped for. :)

Tim.