[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 1/3] xen/ppc: Set up a basic C environment


  • To: Shawn Anastasio <sanastasio@xxxxxxxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 22 Jun 2023 23:49:11 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UE5A1DoJf6f0CukC8p7GbsiMKdDyxC78NP6pfzbctag=; b=c18DWS1ueJUtBvzH+YHoTLjU9w5ESFEEOuhQLG7MY2f2TexkCFWoPtqFW8z4I0ztyNscvIn3uMaYEKG+koVVcuLwEGmB9V3Ht9YIm2pubJM3a2pyPz+ZkRLDyvEgPsOFD2GgQUKPOLM4GhWrJWRYGvlXmZTMMBE73/OZnUjU0H+6eEJPiwRphXtG4MjSupi230EA2mtW8ySvIvKfknCuaGqvTb22ymajI2Vk7lMEmn6iGDGBk/R7he6U/qmy1Y1jg5bZ7C1wnq89bDtPUHoSMy15HFyEvzFkkz0xfcaLlJ/am2eXTMcfH2lsgdZLiAW0zKXXdPeO1HhjV74JPRdrDQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z3HMR2D9oHb5zhKdVjrJP2xaGip0av/iQt/v0VRiigQvSJ/e5+yl0QhSydVE0xZdPEXXv00O476+I8PKoEUWLWt8AkzePVc02on7QhDijVnUBpR6SCIAATyTCr110wXn/sCz/cNXzZVhtC0w7SHmJf7F/RqHKOOZHadQ6c8e9OdtCcaGYc50RmSpGSo0XWNHArLOA4Hhje59iCuY2RIfbkyUb4kAubK+bkNzVQBGDuP0mNh0+nghFetqjNv8wxHn8V57chvf4kO8uzRQzecd7iAdL2QVKGs04BvUgkRRHTgTFFBbcb+aw7d6O4ZmuksbPCa0xHlGidLFHY1JYAzeMQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Timothy Pearson <tpearson@xxxxxxxxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>
  • Delivery-date: Thu, 22 Jun 2023 22:49:34 +0000
  • Ironport-data: A9a23:swiK1qABolROoRVW/8Hiw5YqxClBgxIJ4kV8jS/XYbTApDxz0jMAz TAcCm2EOvnfM2qmctF1ad60oxxXvJSHztRhQQY4rX1jcSlH+JHPbTi7wuUcHAvJd5GeExg3h yk6QoOdRCzhZiaE/n9BCpC48T8nk/nOHuGmYAL9EngZbRd+Tys8gg5Ulec8g4p56fC0GArIs t7pyyHlEAbNNwVcbCRMsspvlDs15K6p4G1C5ARjDRx2lAS2e0c9Xcp3yZ6ZdxMUcqEMdsamS uDKyq2O/2+x13/B3fv8z94X2mVTKlLjFVDmZkh+AsBOsTAbzsAG6Y4pNeJ0VKtio27hc+ada jl6ncfYpQ8BZsUgkQmGOvVSO3kW0aZuoNcrLZUj2CA6IoKvn3bEmp1T4E8K0YIwp8xsHEF+t vgkBR8ucTSAie6W0JeHVbw57igjBJGD0II3nFhFlGucKMl8BJfJTuPN+MNS2yo2ioZWB/HCa sEFaD1pKhPdfxlIPVRRA5U79AuqriCnL3sE9xTL++xruwA/zyQouFTpGPPTdsaHWoN+mUGAq 3id12/4HgsbJJqUzj/tHneE37aUw3KqCdpKfFG+3vAtnkSi2kFLMgQLEnzli/qIt0LncPsKf iT4/QJr98De7neDVdD7VgakqWWFuTYGUsJMFPc37g6MzKfZ+QefCS4PSTspQMwrsoo6SCIn0 neNnsj1Hnp/vbuNU3Wf+7yI6zSoNkA9MXcPbDUfSg0t+dD7vIYpgxTAT9BuHbS0iNKzEjb1q xiIpiUjg7QYjeYQyr62u1vAhlqEpIXNTwMzzhXaWCSi9AwRWWK+T4mh6Fye6OkaKo+cFwOFp CJcx5DY6/0SB5aQkiDLWP8KALyi+/eCNnvbnEJrGJ4isT+q/hZPYLxt3d23H28xWu5sRNMjS BS7Vd95jHOLAEaXUA==
  • Ironport-hdrordr: A9a23:8h8tb68iUcCuhZ0tOXxuk+Hvd71zdoMgy1knxilNoENuE/Bwxv rBoB1E73DJYW4qKQsdcLC7UpVoMkmsiKKdgLNhSotKOTOHhILGFvAb0WKP+UyEJ8SczJ8q6U 4DSdkENDSYNzET5qqKg3jbLz9K+qjhzEncv5am854bd3ANV0gP1XYcNu+cKCBLbTgDIaB8OI uX58JBqTblU28QdN6DHXUAX/LOvZniiI/mSQRuPW9l1CC+yReTrJLqGRmR2RkTFxlVx605yH PIlwzi6r/mm+2nyzvR3W7a6JRNnLLau5l+Lf3JrvJQBiTniw6uaogkcaaFpioNu+2q6Ewnip 3lvwogBcJu8HncF1vF5CfF6k3F6nID+nXiwViXjT/IusriXgsgB85An45CNjDywSMbzYhB+Z MO+1jcm4tcDBvGkii4zcPPTQtSjUaxoWAvi6oopVk3a/pYVJZh6agkuG9FGpYJGyz3rKo9Fv N1NdrR4PZNfUnfUmvQuXN3xsewY286ERiHSHUTo8D96UkToFlJi28jgOAPlHYJ85wwD7Ne4f 7fC79lkLFVQtVTZaVhBP0ZSc/yEGbERhjLN3+fMEmPLtBcB1v977rMpJkl7uCjf5IFiLEono 7aaUhVsW4pd1irDcGVxpVE/grKXH62UV3Wu4djzqk8noe5aKvgMCWFRlxrudCnue8nGcHeW+ y+ItZRGP/sLWznHIxN3wH4RplKIXQSS8EOoL8AKgqzi/OODrevmv3Qcf7VKraoOy0jQHnHGX cGXCL+PoFY9UagVmXjjBWUUGOoeUri5pV5Fajc8YEoudUwH7wJljJQpUWy58mNJzEHmLcxZl FGO7/ikrm2vy2q5m7O9XxuIQdBFU5b77XrTmNSqWYxQhjJWIdGn+/aVXFZ3XOBKBM6ZdjRCh Rjq1N+/r/yB4CMxAg5YujXel6yvj82njanXp0ckqqM6YPOYZUjFKsrX6R3CEHiCwF1owB3s2 1OATV0DXM3Vwmew5lNvqZkSN03ROMMzztD5vQk5043gH/s6P3HgEFrHgJGH/TnwTrGDAAk+m GZu5Vv/4ZoMwzfdVfXxt5IeWGlrA+scex75MPvXvQKpljmFTsAM1uilHiUjQo+dXHt8FhXjm v9LTeMcfWOGVZFvGtEu5yahG+cW1/tDX6YUEoKxLGVOV62yUqbi9X7F5Zb+1HhGmc//g==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 22/06/2023 9:57 pm, Shawn Anastasio wrote:
> Update ppc64/head.S to set up an initial boot stack, zero the .bss
> section, and jump to C.
>
> Also refactor the endian fixup trampoline into its own macro, since it
> will need to be used in multiple places, including every time we make a
> call into firmware (see next commit).
>
> Signed-off-by: Shawn Anastasio <sanastasio@xxxxxxxxxxxxxxxxxxxxx>

Thankyou for making this change - it definitely simplifies things.

> ---
>  xen/arch/ppc/Makefile                |  1 +
>  xen/arch/ppc/include/asm/asm-defns.h | 36 ++++++++++++++++++
>  xen/arch/ppc/ppc64/head.S            | 55 ++++++++++++++++++----------
>  xen/arch/ppc/setup.c                 | 13 +++++++
>  4 files changed, 85 insertions(+), 20 deletions(-)
>  create mode 100644 xen/arch/ppc/include/asm/asm-defns.h
>  create mode 100644 xen/arch/ppc/setup.c
>
> diff --git a/xen/arch/ppc/Makefile b/xen/arch/ppc/Makefile
> index 98220648af..fdbcd730d0 100644
> --- a/xen/arch/ppc/Makefile
> +++ b/xen/arch/ppc/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_PPC64) += ppc64/
> +obj-y += setup.o
>  
>  $(TARGET): $(TARGET)-syms
>       cp -f $< $@
> diff --git a/xen/arch/ppc/include/asm/asm-defns.h 
> b/xen/arch/ppc/include/asm/asm-defns.h
> new file mode 100644
> index 0000000000..3db2063a39
> --- /dev/null
> +++ b/xen/arch/ppc/include/asm/asm-defns.h
> @@ -0,0 +1,36 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +#ifndef _ASM_PPC_ASM_DEFNS_H
> +#define _ASM_PPC_ASM_DEFNS_H
> +
> +/*
> + * Load a 64-bit immediate value into the specified GPR.
> + */
> +#define LOAD_IMM64(reg, val)                                                 
> \
> +    lis reg, (val) @highest;                                                 
> \
> +    ori reg, reg, (val) @higher;                                             
> \
> +    rldicr reg, reg, 32, 31;                                                 
> \
> +    oris reg, reg, (val) @h;                                                 
> \
> +    ori reg, reg, (val) @l;
> +
> +/*
> + * 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.
> + */
> +#define FIXUP_ENDIAN                                                         
>   \
> +    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                               */
> +
> +#endif /* _ASM_PPC_ASM_DEFNS_H */
> diff --git a/xen/arch/ppc/ppc64/head.S b/xen/arch/ppc/ppc64/head.S
> index 2fcefb40d8..a7db5b7de2 100644
> --- a/xen/arch/ppc/ppc64/head.S
> +++ b/xen/arch/ppc/ppc64/head.S
> @@ -1,30 +1,45 @@
>  /* SPDX-License-Identifier: GPL-2.0-or-later */
>  
> +#include <asm/asm-defns.h>
> +
>      .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.
> +     * NOTE: argument registers (r3-r9) must be preserved until the C 
> entrypoint
>       */
> -    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
> +    FIXUP_ENDIAN
> +
> +    /* set up the initial stack */
> +    LOAD_IMM64(%r1, cpu0_boot_stack)
> +    li %r11, 0
> +    std %r11, 0(%r1)

I've done a bit of reading around, and it's rather sad that things prior
to Power10 don't have PC-relative addressing.  So the LOAD_IMM64()'s do
look necessary for the stack and bss.  I guess that means we can't be
sensibly be position independent in head.S?

Also, why store 0 onto the stack ?

> +
> +    /* clear .bss */
> +    LOAD_IMM64(%r14, __bss_start)
> +    LOAD_IMM64(%r15, __bss_end)
> +1:
> +    std %r11, 0(%r14)
> +    addi %r14, %r14, 8
> +    cmpld %r14, %r15
> +    blt 1b

This loop is correct, except for the corner case of this patch alone,
where the BSS is empty and this will write one word out-of-bounds.

For RISC-V, we put a temporary "char bss_tmp;" in setup.c, and I suggest
you do the same here, deleting it at a later point when there's real
data in the bss.

> +
> +    /* call the C entrypoint */
> +    LOAD_IMM64(%r12, start_xen)
> +    mtctr %r12
> +    bctrl

Why is this a LOAD_IMM64(), and not just:

    b start_xen

?  From the same reading around, PPC64 seems to have +/- 32M addressing
for branches, and the entire x86 hypervisor (.init included) is within 3M.

> +
> +    /* should never return */
> +    trap
>  
>      .size start, . - start
>      .type start, %function
> +
> +    .section .init.data, "aw", @progbits
> +
> +    /* Early init stack */
> +    .p2align 4
> +cpu0_boot_stack_bottom:
> +    .space STACK_SIZE
> +cpu0_boot_stack:
> +    .space STACK_FRAME_OVERHEAD

Why the extra space beyond the stack?

Also, I'd put cpu0_boot_stack in C, and just LOAD_IMM64(x,
cpu0_boot_stack + STACK_SIZE)

> diff --git a/xen/arch/ppc/setup.c b/xen/arch/ppc/setup.c
> new file mode 100644
> index 0000000000..4d1b72fa23
> --- /dev/null
> +++ b/xen/arch/ppc/setup.c
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +#include <xen/init.h>
> +
> +void __init noreturn start_xen(unsigned long r3, unsigned long r4,
> +                               unsigned long r5, unsigned long r6,
> +                               unsigned long r7)
> +{
> +    for ( ;; )
> +        /* Set current hardware thread to very low priority */
> +        asm volatile("or %r31, %r31, %r31");

Is there something magic about the OR instruction, or something magic
about %r31?

For a RISC architecture, this seems subtle.

~Andrew



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.