Re: [PATCH 2/3] xen/ppc: Relocate kernel to physical address 0 on boot

[Shawn Anastasio <sanastasio@xxxxxxxxxxxxxxxxxxxxx>]

On 8/1/23 1:08 AM, Jan Beulich wrote:
> On 01.08.2023 01:37, Shawn Anastasio wrote:
>> On 7/31/23 10:46 AM, Jan Beulich wrote:
>>> On 29.07.2023 00:21, Shawn Anastasio wrote:
>>>> +    /* If we're at the correct address, skip copy */
>>>> +    cmpld   %r1, %r12
>>>> +    beq     .L_correct_address
>>>
>>> Can this ever be the case, especially with the MMU-off behavior you
>>> describe in the comment above? Wouldn't you need to ignore the top
>>> four bits in the comparison?
>>
>> It will always be the case after the code jumps to XEN_VIRT_START after
>> the copy takes place.
> 
> Well, of course.
> 
>> I could have it jump past the copy loop entirely,
>> but then I'd need to duplicate the TOC setup.
> 
> I don't think I understand this part of your reply: .L_correct_address
> _is_ past the copy loop.

Sorry, let me elaborate. I meant that I could have the end of the copy
loop (the mtctr + btctr preceeding .L_correct_address) jump to
(XEN_VIRT_START + .L_correct_address) as opposed to XEN_VIRT_START so
that the address comparison you originally commented on wouldn't be hit
again.

This would mean adding another TOC setup block at .L_correct_address,
though, since we'd be skipping over the one at the beginning of the
routine and the TOC needs to be reconfigured after the relocation.

>>>> +    /* Copy bytes until _end */
>>>> +    LOAD_REG_ADDR(%r11, _end)
>>>> +    addi    %r1, %r1, -8
>>>> +    li      %r13, -8
>>>> +.L_copy_xen:
>>>> +    ldu     %r10, 8(%r1)
>>>> +    stdu    %r10, 8(%r13)
>>>> +    cmpld   %r1, %r11
>>>> +    blt     .L_copy_xen
>>>> +
>>>> +    /* Jump to XEN_VIRT_START */
>>>> +    mtctr   %r12
>>>> +    bctr
>>>> +.L_correct_address:
>>>
>>> Can the two regions potentially overlap? Looking at the ELF header
>>> it's not clear to me what guarantees there are that this can't
>>> happen.
>>
>> As I understand it, any bootloader that placed the kernel at a low
>> enough address for this to be an issue wouldn't be able to boot Linux or
>> FreeBSD, so in practice it's a safe bet that this won't be the case.
> 
> Fair enough then.
> 
> Jan

Thanks,
Shawn