[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: non-contiguous allocations

On 09/05/2011 13:43, "Olaf Hering" <olaf@xxxxxxxxx> 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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel