From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [RFC PATCH] xen/arm: Vmap allocator fails to allocate beyond 128M Date: Mon, 23 Feb 2015 17:10:29 +0000 Message-ID: <1424711429.27930.232.camel@citrix.com> References: <1424710994.27930.226.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1424710994.27930.226.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Vijay Kilari Cc: Stefano Stabellini , Julien Grall , Tim Deegan , "xen-devel@lists.xen.org" , Stefano Stabellini , Jan Beulich List-Id: xen-devel@lists.xenproject.org On Mon, 2015-02-23 at 17:03 +0000, Ian Campbell wrote: > MAP_SMALL_PAGES in no way indicates to me "create the PT structure but > do not map any actual data pages". It is documented on x86 as "don't use > superpages mappings", which doesn't imply anything to me about > non-superpage mappings either. OK I get it now, MAP_SMALL_PAGES is actually a modifier for the PAGE_* stuff, what's special about this particular usage is that it is a bare MAP_SMALL_PAGES, i.e. not PAGE_HYPERVISOR|MAP_SMALL_PAGES. Being bare it then lacks the present bit from PAGE_HYPERVISOR. It's a bit like saying PAGE_NONE|MAP_SMALL_PAGES (if PAGE_NONE existed) > Can we along with this fix perhaps rename to something which does > indicate this. MAP_NON_LEAF_PTS or something perhaps? (This is really a > question for Jan). So this then doesn't make any sense, as I'm sure Jan is about to tell me ;-) Ian.