Re: [PATCH 12/15] x86/PVH: heed the kernel in pvh_steal_ram()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.10.2026 09:16, Roger Pau Monné wrote:
> On Mon, Oct 12, 2026 at 10:25:40AM +0200, Jan Beulich wrote:
>> While the function working downwards will typically result in no conflict
>> with the kernel range, there's no guarantee of that.
>>
>> Fixes: 1d74282c455f ("x86: setup PVHv2 Dom0 ACPI tables")
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> --- a/xen/arch/x86/hvm/dom0_build.c
>> +++ b/xen/arch/x86/hvm/dom0_build.c
>> @@ -186,8 +186,12 @@ static int __init pvh_populate_memory_ra
>>  /* Steal RAM from the end of a memory region. */
>>  static int __init pvh_steal_ram(struct domain *d, unsigned long size,
>>                                  unsigned long align, paddr_t limit,
>> +                                const struct elf_binary *elf,
>>                                  paddr_t *addr)
>>  {
>> +    paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
>> +    paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size,
>> +                                 PAGE_SIZE);
>>      unsigned int i = d->arch.nr_e820;
>>  
>>      /*
>> @@ -203,6 +207,11 @@ static int __init pvh_steal_ram(struct d
>>              continue;
>>  
>>          *addr = (entry->addr + entry->size - size) & ~(align - 1);
>> +
>> +        /* Avoid kernel range, if this is the region it lives in. */
>> +        if ( *addr < kernel_end && *addr + size > kernel_start )
>> +            *addr = (kernel_start - size) & ~(align - 1);
>> +
>>          if ( *addr < entry->addr ||
>>               /* Don't steal from the low 1MB due to the copying done there. 
>> */
>>               *addr < MB(1) )
> 
> If you clip addr to remove the kernel range for allocation purposes
> you need to restore it before the `entry->size = *addr - entry->addr`
> adjustment.
> 
> Overall I continue to think this will be much simpler if we passed
> around a rangeset.  This series is adding a fair amount of extra code
> to deal with overlaps between kernel/initrd allocations vs everything
> else, which could be solved more easily by using a rangeset.

I've started moving to that approach. With the kernel range removed from
the rangeset early on, the need for this separate patch then disappears.

Jan