From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH 2/3] xen/p2m: Using INVALID_MFN instead of mfn_valid Date: Thu, 16 Aug 2012 18:47:50 +0100 Message-ID: <20120816174750.GA32339@ocelot.phlegethon.org> References: <35799d4871cec6ffe122121e59d930fe.squirrel@webmail.lagarcavilla.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <35799d4871cec6ffe122121e59d930fe.squirrel@webmail.lagarcavilla.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andres Lagar-Cavilla Cc: xudong.hao@intel.com, xiantao.zhang@intel.com, Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.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.