Re: [PATCH 09/15] x86/PVH: split pvh_setup_vmx_realmode_helpers()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 14.10.2026 11:38, Roger Pau Monné wrote:
> On Mon, Oct 12, 2026 at 10:24:07AM +0200, Jan Beulich wrote:
>> All E820 manipulations want to happen before the initrd is placed, or else
>> pvh_steal_ram() may steal from the tail part of it. While this is
>> currently suitably ordered, mapping the initrd directly into Dom0 will
>> want to happen ahead of pvh_populate_p2m(). Hence as a third step, split
>> placing VMX data (if needed at all) from actually populating it.
>>
>> Also move the invocation of pvh_setup_vmx_realmode_helpers() out of
>> pvh_populate_p2m(). Make it unconditional as well, instead bailing from
>> the function when pvh_place_vmx_realmode_helpers() wasn't called.
> 
> I'm overall happy with the idea of moving
> pvh_setup_vmx_realmode_helpers() out of pvh_populate_p2m(), however I
> would much rather prefer for us to keep two memory maps (the real one
> in the domain struct), plus a temporary one that signals used memory,
> rather than doing allocation vs placement in two steps.  Having to
> add custom {acpi,vmx}_info structures for each metadata we want to
> place seems strictly worse than keeping two memory maps.

Hmm, that's unfortunate: I see it the other way around. I also can't seem
to be able to see how the order of operations (as listed in the reply on
the ACPI patch sub-thread) could be changed to accommodate what you want.
There's one basic ordering requirement: We need to know where the initrd
is to go ahead of populating the P2M. Yet among kernel, ACPI, and initrd
the latter is what has the least constraints on placement. Hence before
determining where the initrd is to go, we need to determine where to put
kernel and ACPI tables (as said elsewhere, I'm not finally certain about
VMX metadata).

Jan