From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Re: non-contiguous allocations Date: Mon, 09 May 2011 15:14:10 +0100 Message-ID: References: <20110509124314.GA19179@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110509124314.GA19179@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Olaf Hering Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 09/05/2011 13:43, "Olaf Hering" wrote: >> Yes, sticking with alloc_xenheap_pages() is good. > > Another question: > alloc_trace_bufs() calls alloc_xenheap_pages(0, MEMF_bits(32 + PAGE_SHIFT)); > > MEMF_bits() is not used in the i386 codepath in alloc_heap_pages(), > unless I miss something. On i386 the xenheap is drawn from the bottom 12MB of physical memory, hence restricting address width doesn't need to be explicitly handled -- no caller requires addresses below 8MB. > Otherwise alloc_domheap_pages() is called, which passes BITS_PER_LONG > instead of 32 to domain_clamp_alloc_bitsize(). > > Is the hardcoded 32+PAGE_SHIFT required in some way, The allocated MFNs get passed to dom0 userspace in a uint32_t array. Hence MFNs cannot be wider than 32 bits. Hence physical addresses of trace pages cannot be wider than 32+PAGE_SHIFT bits. > or could I just use > the alloc_xenheap_page() macro and let alloc_domheap_pages() deal with > allocation details? No, the explicit MEMF_bits restriction is required, unless you widen the MFN arrays passed to dom0 userspace to contain uint64_t entries. -- Keir