Re: [PATCH 06/15] x86/PVH: keep a copy of Dom0's initial E820 map

[Jan Beulich <jbeulich@suse.com>]

On 13.10.2026 15:48, Roger Pau Monné wrote:
> On Mon, Oct 12, 2026 at 10:21:55AM +0200, Jan Beulich wrote:
>> pvh_populate_p2m() needs to populate RAM according to the initial map
>> established, prior to any stealing by pvh_steal_ram(). Subsequently the
>> invocations of those functions will (need to) move ahead of
>> pvh_populate_p2m(), so what to act on is no longer Dom0's memory map at
>> the time of invocation.
> 
> But (most of?) the uses of pvh_steal_ram() expect to access the stolen
> RAM, and hence using pvh_steal_ram() ahead of pvh_populate_p2m() is
> not a present use-case?
> 
> I assume you have a further use-case for pvh_steal_ram() that wants to
> steal a range before it's populated, which might be worth mentioning
> here, to add a bit more context?

I thought that I'm saying just that already with "Subsequently ...". All
that logic needs splitting: Obtain a range ahead of populating, access
the range only afterwards.

>> @@ -1389,6 +1395,15 @@ int __init dom0_construct_pvh(const stru
>>  
>>      iommu_hwdom_init(d);
>>  
>> +    nr_orig_e820 = d->arch.nr_e820;
>> +    orig_e820 = xvmalloc_array(struct e820entry, nr_orig_e820);
>> +    if ( !orig_e820 )
>> +    {
>> +        printk("No memory for copy of E820 map (%u entries)\n", nr_orig_e820);
> 
> For some of the printks during dom0 PVH construction we already print
> the domain (%pd), and I think it would be good to print it here also.
> Some not-yet-upstream uses (hyperlaunch) create several domains using
> this logic, it would be good to easily spot which domain triggered the
> errors.

Can do, sure. That'll be a little inconsistent then for a while; maybe
I should add a patch adjusting all printk()s I didn't otherwise touch.

Jan