Re: [PATCH v4 2/4] xen: Add files needed for minimal ppc64le build

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.06.2023 17:49, Shawn Anastasio wrote:
> On 6/16/23 3:24 PM, Andrew Cooper wrote:
>> On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
>>> Add the build system changes required to build for ppc64le (POWER8+).
>>> As of now the resulting image simply boots to an infinite loop.
>>>
>>> $ make XEN_TARGET_ARCH=ppc64 -C xen openpower_defconfig
>>> $ make XEN_TARGET_ARCH=ppc64 SUBSYSTEMS=xen -C xen build
>>
>> I think the first of these isn't needed, given the config ARCH_DEFCONFIG
>> default.  I'd suggest dropping it.
> 
> It seems like the build system expects an `$(ARCH)_defconfig` present if
> you don't manually specify a defconfig target. I see riscv64 has a
> tiny64_defconfig and a riscv64_defconfig that are idential, probably for
> this same reason. Would you like me to take the same approach of
> duplicating openpower_defconfig to ppc64_defconfig?

It's a symlink for RISC-V iirc, so wants to be that same way for PPC
then (for the time being, again like there).

>>> --- /dev/null
>>> +++ b/xen/arch/ppc/ppc64/head.S
>>> @@ -0,0 +1,27 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>>> +
>>> +.section .text.header, "ax", %progbits
>>> +
>>> +ENTRY(start)
>>> +    /*
>>> +     * Depending on how we were booted, the CPU could be running in either
>>> +     * Little Endian or Big Endian mode. The following trampoline from 
>>> Linux
>>> +     * cleverly uses an instruction that encodes to a NOP if the CPU's
>>> +     * endianness matches the assumption of the assembler (LE, in our case)
>>> +     * or a branch to code that performs the endian switch in the other 
>>> case.
>>> +     */
>>> +    tdi 0, 0, 0x48    /* Reverse endian of b . + 8          */
>>> +    b . + 44          /* Skip trampoline if endian is good  */
>>> +    .long 0xa600607d  /* mfmsr r11                          */
>>> +    .long 0x01006b69  /* xori r11,r11,1                     */
>>> +    .long 0x00004039  /* li r10,0                           */
>>> +    .long 0x6401417d  /* mtmsrd r10,1                       */
>>> +    .long 0x05009f42  /* bcl 20,31,$+4                      */
>>> +    .long 0xa602487d  /* mflr r10                           */
>>> +    .long 0x14004a39  /* addi r10,r10,20                    */
>>> +    .long 0xa6035a7d  /* mtsrr0 r10                         */
>>> +    .long 0xa6037b7d  /* mtsrr1 r11                         */
>>> +    .long 0x2400004c  /* rfid                               */
>>> +
>>> +    /* Now that the endianness is confirmed, continue */
>>> +1:  b 1b
>>
>> .size start, . - start
>> .type start, %function
>>
>> Lets get the ELF metadata right from the start.
> 
> Good point. Following the example in the Power ELFv2 ABI
> specification [1] for function type annotation, I'll place
> 
> .type start, @function
> 
> in the ENTRY macro. It's not clear what the difference between %function
> and @function are in this context (my toolchain seems to accept both and
> produce the same ELF metadata), but the latter is more idiomatic in
> Power assembly. The same goes for its placement before the entrypoint
> vs. after the last instruction.

% and @ are entirely the same here, except for targets like arm-*,
where @ starts a comment.

>>> --- /dev/null
>>> +++ b/xen/arch/ppc/xen.lds.S
>>> @@ -0,0 +1,172 @@
>>> <snip>
>>> +    DISCARD_SECTIONS
>>> +
>>> +    STABS_DEBUG_SECTIONS
>>> +
>>> +    ELF_DETAILS_SECTIONS
>>> +}
>>
>> In the other architectures, we now assert that sections such as .got are
>> empty, because we've had enough bugs in the past.
>>
>> I'd recommend doing the same from the outset for all the dynamic
>> relocation sections, unless you're expecting to have to support them?
> 
> No plans on supporting dynamic relocation (for now), so I can go ahead
> and add these assertions.

How would you ever use dynamic relocations? You have no loader to
process them for you. (Yes, there can of course be relocation free
head.S code which deals with relocations, but doing such in assembly
is likely not the best idea. Yet as soon as you enter C code you're
at risk of hitting a place requiring such a relocation, perhaps
simply because of a "careless" function call on some infrequently
used code path.)

Jan