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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.11.2026 09:37, Roger Pau Monné wrote:
> 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?

Looks like it isn't, as that's getting copied before enabling paging.

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

Blindly mapping the first Gb as Linux does is already a problem imo:
In the first Mb there very likely is MMIO, which shouldn't be mapped WB.
Further up there may be MMIO as well, yet maybe that's unlikely. Up from
1Gb and below 4Gb there definitely is MMIO again.

>  In the meantime, we keep
> allocating upwards, and hope we don't cross the 1G boundary.

A hope which breaks with an initrd big enough to fit below 4Gb, but too
bit to fit in the first Gb.

Jan