On 16.06.2025 15:27, Roger Pau Monné wrote:
> On Tue, Feb 25, 2025 at 03:58:34PM +0100, Jan Beulich wrote:
>> Entities building domains are expected to deal with higher order
>> allocation attempts (for populating a new domain) failing. If we set
>> aside a reservation for DMA, try to avoid taking higher order pages from
>> that reserve pool.
>>
>> Instead favor order-0 ones which often can still be
>> supplied from higher addressed memory, even if we've run out of
>> large/huge pages there.
>
> I would maybe write that last sentence as: force non zero order
> allocations to use the non-DMA region, and if the region cannot
> fulfill the request return an error to the caller for it to retry with
> a smaller order. Effectively this limits allocations from the DMA
> region to only be of order 0 during physmap domain population.
I can take this text, sure.
>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -192,6 +192,14 @@ static void populate_physmap(struct memo
>> * delayed.
>> */
>> a->memflags |= MEMF_no_icache_flush;
>> +
>> + /*
>> + * Heuristically assume that during domain construction the caller
>> is
>> + * capable of falling back to order-0 allocations, allowing us to
>> + * conserve on memory otherwise held back for DMA purposes.
>> + */
>> + if ( a->extent_order )
>> + a->memflags |= MEMF_no_dma;
>
> For PV domains: is it possible for toolstack to try to allocate a
> certain amount of pages from the DMA pool for the benefit of the
> domain?
Not directly at least. To benefit the domain, it would also need to be
told where in PFN space those pages would have ended up.
> I also wonder if it would make sense to attempt to implement the
> logic on the toolstack side: meminit_{hvm,pv}()?
>
> No strong opinion, but slightly less logic in the hypervisor, and
> won't change the interface for possibly existing toolstacks that don't
> pass MEMF_no_dma on purpose.
MEMF_no_dma isn't exposed outside of the hypervisor.
Jan
