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

[Roger Pau Monné <roger@xxxxxxxxxxxxxx>]

On Thu, Nov 05, 2026 at 09:06:15AM +0100, Jan Beulich wrote:
> On 15.10.2026 18:32, Roger Pau Monné wrote:
> > On Mon, Oct 12, 2026 at 10:25:11AM +0200, Jan Beulich wrote:
> >> 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.
> 
> In the course of replacing that find_memory() by pvh_steal_ram() (while
> converting to rangeset-based tracking) I learned the hard way that this
> isn't possible, even if it ought to be. Linux won't cope with parts of
> start-info (at least the module array) living outside of the first Gb
> (in 32-bit Linux it may go farther, depending on CONFIG_PAGE_OFFSET).

I assume start_info itself also needs to be < 1G then?

> See pvh_level3_ident_pgt[] having only its first direct-map entry
> populated, and pvh_start_xen() also only updating that one entry. Which
> causes xen_prepare_pvh() -> init_pvh_bootparams() to fall over anything
> living beyond the 1Gb boundary. (.memmap_paddr would apparently have
> the same issue, just that for Dom0 we don't set that.)

Hm, that's unfortunate.  We should fix Linux to the bootstrap
page-tables identity map the whole low 4G.  In the meantime, we keep
allocating upwards, and hope we don't cross the 1G boundary.

Thanks, Roger.