Re: [PATCH v4 5/5] x86/PVH: Support relocatable dom0 kernels

[Jason Andryuk <jason.andryuk@xxxxxxx>]

On 2024-03-26 09:40, Jan Beulich wrote:
> On 26.03.2024 14:24, Jason Andryuk wrote:
> > On 2024-03-26 03:50, Jan Beulich wrote:
> > > On 25.03.2024 21:45, Jason Andryuk wrote:
> > > > @@ -227,6 +239,27 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
> > > > +        }
> > > > +        if ( descsz >= 8 )
> > > > +        {
> > > > +            parms->phys_min = elf_note_numeric_array(elf, note, 4, 1);
> > > > +            elf_msg(elf, " min: %#"PRIx32, parms->phys_min);
> > > > +        }
> > > > +        if ( descsz >= 12 )
> > > > +        {
> > > > +            parms->phys_align = elf_note_numeric_array(elf, note, 4, 2);
> > > > +            elf_msg(elf, " align: %#"PRIx32, parms->phys_align);
> > > > +        }
> > > I'd like us to reconsider this ordering: I'm inclined to say that MAX isn't
> > > the most likely one a guest may find a need to use. Instead I'd expect both
> > > MIN and ALIGN wanting to be given higher priority; what I'm less certain
> > > about is the ordering between the two. To keep MIN and MAX adjacent, how
> > > about ALIGN, MIN, MAX?
> > ALIGN, MIN, MAX works for me.
> >
> > On the Linux side, I'm expecting them all to be set:
> > ALIGN = CONFIG_PHYSICAL_ALIGN
> > MIN = LOAD_PHYSICAL_ADDR
> > MAX = KERNEL_IMAGE_SIZE
> >
> > You need enough identity page tables to cover up to MAX.
> > LOAD_PHYSICAL_ADDR is used as a minimum, so requesting placement above
> > MIN makes sense to me.
> Hmm, setting MIN like this means moving down is precluded. Why would it
> not be possible to move a kernel to lower than the default of 16M, when
> CONFIG_PHYSICAL_START can be as low as 0? (In fact, I doubt 0 would work
> if chosen, but 2M surely does work, as I build some of my Dom0 kernels
> that way.)
I successfully booted at a lower address when testing, so it's possible. 
 The bzImage early boot code uses LOAD_PHYSICAL_ADDR as a minimum for 
extracting vmlinux, so I matched that.  It's not clear to me exactly why 
that is used, though it avoids using the 16MB ISA DMA region.
Kconfig RELOCATABLE has this:
Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address
it has been loaded at and the compile time physical address
(CONFIG_PHYSICAL_START) is used as the minimum location.

Which is again why I thought to use it as MIN.

> MAX, otoh, I guess really wants setting as you say, for KERNEL_IMAGE_SIZE
> actually being commented upon as mis-named. Just that it now really wants
> to be KERNEL_IMAGE_SIZE-1.
Yes.

If placement changes to favor higher addresses, then ALIGN, MAX, MIN 
becomes a little more important since that should be consulted first.
Thanks,
Jason