Re: [PATCH 2/6] tools: arm: allocate superpages to guests.

[Julien Grall <julien.grall@linaro.org>]

On 06/10/2014 04:16 PM, Ian Campbell wrote:
>>> +/*  >0: success, *nr_pfns set to number actually populated
>>> + *   0: didn't try with this pfn shift (e.g. misaligned base etc)
>>> + *  <0: ERROR
>>> + */
>>> +static int populate_one_size(struct xc_dom_image *dom, int pfn_shift,
>>> +                             xen_pfn_t base_pfn, xen_pfn_t *nr_pfns)
>>> +{
>>> +    uint64_t mask = ((uint64_t)1<<(pfn_shift))-1;
>>> +    uint64_t next_mask = ((uint64_t)1<<(LPAE_SHIFT))-1;
>>> +    int nr, i, count = min_t(int, 1024*1024, *nr_pfns >> pfn_shift);
>>
>> Stupid question, where does come from the 1024*1024?
> 
> It was in the original as a backstop on allocsz. It would correspond to
> 4GB worth of 4K page I suppose

Ah ok. I didn't pay attention about it.

> 
>>> +    xen_pfn_t extents[count];
>>
>> If I follow the count definition, it's possible to allocate 1024*1024
>> xen_pfn_t (about 8MB) on the stack.
> 
> userspace stack isn't all that precious but 8MB does seem a little
> excessive. Previously this was using the already allocated host p2m so
> it wasn't an issue, but that doesn't work for allocations of page >4K.
> 
> The tradeoff is that smaller batches mean it will take longer.
> 
> I don't think it would be unreasonable to reduce this to be e.g. 1GB
> worth of entries (256*1024) or 2MB of stack.

It seems the default stack size is 8MB, I'm wondering if we can have
some use case where this limit is smaller.

Is there any issue to allocate this variable with malloc?

Regards,

-- 
Julien Grall