From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: RE: [RFC] fix xen_in_range() Date: Fri, 24 Apr 2009 08:16:12 +0100 Message-ID: References: <49F180A8.76EA.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49F180A8.76EA.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , Joseph Cihula , "xen-devel@lists.xensource.com" Cc: Dexuan Cui , Shane Wang , Yunhong Jiang , Xiaowei Yang , Liping Ke , Xin Li List-Id: xen-devel@lists.xenproject.org On 24/04/2009 08:04, "Jan Beulich" wrote: > Also, after suggesting to use gb-pages when possible here I realized that > it's probably a latent bug to map more space than was allocated - if the > non-allocated-but-mapped pages happen to later get allocated to a domain, > that domain may change the cacheability attributes of any of these pages, > resulting in aliasing issues. I'll put together a patch for this, but it'll be > a couple of days until I'll be able to do so. I think we should shatter the superpage on demand. This would also be required for superpage mappings of Xen itself: when we free initmem that memory can now be allocated to a domain (now xenheap and domheap are merged on x86/64). An alternative might be to mark such partially-freed superpages as Xenheap-only, and allocate them preferentially for Xenheap callers (i.e., alloc those pages first, then from the general heap). -- Keir