Re: [PATCH 11/15] x86/PVH: try to map initrd directly into Dom0

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.10.2026 18:32, Roger Pau Monné wrote:
> On Mon, Oct 12, 2026 at 10:25:11AM +0200, Jan Beulich wrote:
>> Our present handling of initrd is problematic in particular when the
>> initrd is huge, and when at the same time "dom0_mem=" isn't in use to
>> significantly shrink Dom0's memory (from the default). In that case,
>> insufficient memory may exist for pvh_populate_p2m() to succeed (because
>> initrd memory can be freed only after copying).
>>
>> Make an attempt to map the blob (including headroom) into Dom0 instead,
> 
> I would use "dom0 p2m" instead of plain p2m, it's clearer IMO.

Can do, sure.

>> thus also saving the copying operation. With __start_xen() having arranged
>> for a larger than necessary blob, that mapping can typically be done with
>> superpage mappings.
>>
>> Reported-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> Is there a need to prune (scrub) the headroom space?
> 
> We already populate the p2m with memory allocated with MEMF_no_scrub,
> so there's no reason to scrub the headroom unless we also remove the
> MEMF_no_scrub for p2m population.

Oh, I hadn't noticed that. Away goes the remark.

>> Why does find_memory() go upwards, while find_kernel_memory() goes
>> downwards? And why do we use the lowest part of the region found by
>> find_memory() rather than the highest part?
> 
> find_memory() should probably start downwards from 4G.

I've added a todo item; maybe I can get this done in another patch in v2.

(Further remarks will be addressed separately.)

>> +    /*
>> +     * As we promise to place below 4G whatever fits there, make a first 
>> pass
>> +     * limiting permitted addresses.  If we can't fit it there, fall back to
>> +     * placing above 4G.
>> +     */
>> +    for ( paddr_t limit = GB(4); ; )
>> +    {
>> +        paddr_t start;
>> +
>> +        *blob_start = find_initrd_memory(d, elf, &try, align, limit);
>> +        if ( *blob_start != INVALID_PADDR )
>> +            break;
>> +
>> +        if ( align == PAGE_SIZE )
>> +        {
>> +            if ( !(limit + 1) )
>> +                return;
>> +
>> +            limit = -1;
>> +            align = 1UL << L3_PAGETABLE_SHIFT;
> 
> Aren't you possibly asking for an alignment better than what's
> required by the actual initrd memory?  Maybe it's using 2M pages yet
> you request 1G alignment here.

Yes and no: I may request too much here, but the very first condition in
find_initrd_memory() deals with that. When trying different variants of
coding this up, doing it this way seemed like the best way.

Jan