From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v3 8/8] xen: arm: allocate more than one bank for 1:1 domain 0 if needed Date: Fri, 27 Jun 2014 13:52:52 +0100 Message-ID: <53AD6924.7070102@linaro.org> References: <1403777793.16595.21.camel@kazak.uk.xensource.com> <1403777837-16779-8-git-send-email-ian.campbell@citrix.com> <53AC6480.6080306@linaro.org> <1403861047.32314.15.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1403861047.32314.15.camel@kazak.uk.xensource.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: Ian Campbell Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 27/06/14 10:24, Ian Campbell wrote: > On Thu, 2014-06-26 at 19:20 +0100, Julien Grall wrote: >> On 06/26/2014 11:17 AM, Ian Campbell wrote: >>> Depending on where Xen and the initial modules were loaded into RAM we may not >>> be able to allocate a suitably contiguous block of memory for dom0. Especially >>> since the allocations made by alloc_domheap_pages are naturally aligned (e.g. a >>> 1GB allocation must be at a 1GB boundary). >>> >>> The alignment requirement in particular is a huge limitation, meaning that even >>> dom0_mem0=1G on a 2GB system is pretty likely to fail unless you are very >>> careful with your load addresses. People were also having trouble with dom0 > >>> 128MB on the 1GB cubieboard2 when using fairly standard load addresses for >>> things. >>> >>> This patch tries to allocate multiple banks of memory in order to try and >>> satisfy the entire requested domain 0 allocation. Sadly this turns out to be >>> pretty tricky to arrange (see the large comment in the code). >>> >>> Signed-off-by: Ian Campbell >>> Cc: Karim Raslan >>> --- >>> v3: >>> Handle running out of banks more gracefully >>> Allow order >= min_low_order, not strictly greater. Otherwise >>> dom0_mem=128M doesn't work. >> >> dom0_mem still not working on the versatile express (see my explanation >> a below). > >> >>> +static void allocate_memory_11(struct domain *d, struct kernel_info *kinfo) >>> +{ >>> + const unsigned int min_low_order = >>> + get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128))); >>> + const unsigned int min_order = get_order_from_bytes(MB(4)); >>> + struct page_info *pg; >>> + unsigned int order = get_11_allocation_size(kinfo->unassigned_mem); >>> + int i; >>> + >>> + bool_t lowmem = is_32bit_domain(d); >>> + unsigned int bits; >>> + >>> + printk("Allocating 1:1 mappings totalling %ldMB for dom0:\n", >>> + /* Don't want format this as PRIpaddr (16 digit hex) */ >>> + (unsigned long)(kinfo->unassigned_mem >> 20)); >>> + >>> + kinfo->mem.nr_banks = 0; >>> + >>> + /* >>> + * First try and allocate the largest thing we can as low as >>> + * possible to be bank 0. >>> + */ >>> + while ( order >= min_low_order ) >>> + { >>> + for ( bits = order ; bits < (lowmem ? 32 : PADDR_BITS); bits++ ) >> >> This has to be: bits <= (...). Indeed, we want to try all possible zone. After digging into the code, I confirm that we need the "<=". the zone is retrieved with this formula: fls(page_to_mfn(pg)), in the case of the versatile express the bank start mfn is 0x8000. So every page will reach the zone 20. At the same time zone 20 is equals to bits=32. Futhermore, it looks like we always allocate memory from the top of this zone. Is it normal? Regards, -- Julien Grall