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

[Roger Pau Monné <roger@xxxxxxxxxxxxxx>]

On Fri, Oct 16, 2026 at 11:12:34AM +0200, Jan Beulich wrote:
> On 16.10.2026 11:01, Roger Pau Monné wrote:
> > On Fri, Oct 16, 2026 at 10:58:09AM +0200, Jan Beulich wrote:
> >> On 15.10.2026 19:41, Roger Pau Monné wrote:
> >>> On Mon, Oct 12, 2026 at 10:25:11AM +0200, Jan Beulich wrote:
> >>>> @@ -867,7 +1078,7 @@ static int __init pvh_load_kernel(
> >>>>          }
> >>>>          start_info.modlist_paddr = last_addr;
> >>>>          start_info.nr_modules = 1;
> >>>> -        last_addr += sizeof(mod);
> >>>> +        last_addr += sizeof(*mod);
> >>>>      }
> >>>>  
> >>>>      start_info.magic = XEN_HVM_START_MAGIC_VALUE;
> >>>
> >>> Isn't this still not properly ordered, as start_info address must
> >>> strictly be below 4GB (as is passed in a CPU register with the CPU in
> >>> 32bit mode), yet it is allocated last in pvh_load_kernel()?
> >>
> >> Well. For one, this is pre-existing. With the size of the region that
> >> find_memory() needs to find greatly reduced when the initrd isn't
> >> included there, there's about zero chance that it won't find a suitable
> >> region below 4G. Once we have find_memory() go downwards from 4G, the
> >> remaining little bit of a risk will also go away.
> > 
> > Might be worth mentioning then, so it doesn't look like an oversight
> > since you adjust the ACPI allocations.  No strong opinion, just
> > noticed it was left behind.
> 
> I've added mention of this, but only in the remark of the patch. Really
> pvh_setup_cpus() may want to check for no truncation? Or the parameter
> type may want to change to uint32_t, with the no-truncation check then
> living elsewhere?

I think it would indeed be best if Xen checked for truncation.
Whether it's in pvh_setup_cpus() or somewhere else I don't have a
strong opinion.

Thanks, Roger.