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

[Jason Andryuk <jason.andryuk@amd.com>]

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