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

[Roger Pau Monné <roger@xxxxxxxxxxxxxx>]

On Tue, Oct 13, 2026 at 04:53:11PM +0200, Jan Beulich wrote:
> 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.

OK, it wasn't obviously clear from the message.  I would possibly
explicitly mention that it's just the allocation that's moved ahead,
the access must be kept after pvh_populate_p2m().

> >> @@ -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.

It's kind of inconsistent already, see for example the messages at the
top of dom0_construct_pvh().  I won't request that you fix the
existing ones, but it would be better if new additions print the
domain as part of the message.

Thanks, Roger.