From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Re: non-contiguous allocations Date: Mon, 09 May 2011 09:34:37 +0100 Message-ID: References: <4DC7C2400200007800040539@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4DC7C2400200007800040539@vpn.id2.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 , Olaf Hering Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 09/05/2011 09:30, "Jan Beulich" wrote: >> Yes, sticking with alloc_xenheap_pages() is good. > > It really depends on whether you expect to get memory that has > (even on 32-bit) a virtual mapping, or you want to map it at an > arbitrary virtual address after wards. alloc_xenheap_pages() gives > you mapped memory (and the amount you can get is rather limited > on 32-bit), while alloc_domheap_pages(NULL, ...) gives you > memory that has a mapping only on 64-bit (and, once we'll find it > necessary to support machines with more than 5Tb, even that > may not hold anymore) but it equally not associated with any > domain. We have a mechanism for sharing xenheap pages with a guest, which xentrace is already using. Doing the same with anonymous domheap pages would be extra hassle. The limitation of xenheap on x86_32 is uninteresting to me, especially when we're talking about a niche developer feature like xentrace. -- Keir