| Message ID | 20180521114156.6nppm5vomksxpeqv@flea |
|---|---|
| State | New |
| Headers | show |
| Series | [GIT,PULL] Allwinner core changes for 4.18 | expand |
On Mon, May 21, 2018 at 01:41:56PM +0200, Maxime Ripard wrote: > Hi, > > Here is our mach-sunxi changes for the next merge window, thanks! > Maxime > > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: > > Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-core-for-4.18 > > for you to fetch changes up to 6961275e72a8c15cc4ebf108a81eee758480a6a2: > > ARM: sun8i: smp: Add support for A83T (2018-05-08 15:00:20 +0200) > > ---------------------------------------------------------------- > Allwinner core changes for 4.18 > > The A83t, unlike the other Allwinner SoCs, cannot use PSCI because of a > silicon bug. As such, we needed to have some smp_ops in order to bringup > the various cores (and clusters) found on this SoC. Hrm. that's unfortunate. Is there any public documentation of what the bug is? (Merged). -Olof
On Fri, May 25, 2018 at 2:02 PM, Olof Johansson <olof@lixom.net> wrote: > On Mon, May 21, 2018 at 01:41:56PM +0200, Maxime Ripard wrote: >> Hi, >> >> Here is our mach-sunxi changes for the next merge window, thanks! >> Maxime >> >> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: >> >> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) >> >> are available in the Git repository at: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-core-for-4.18 >> >> for you to fetch changes up to 6961275e72a8c15cc4ebf108a81eee758480a6a2: >> >> ARM: sun8i: smp: Add support for A83T (2018-05-08 15:00:20 +0200) >> >> ---------------------------------------------------------------- >> Allwinner core changes for 4.18 >> >> The A83t, unlike the other Allwinner SoCs, cannot use PSCI because of a >> silicon bug. As such, we needed to have some smp_ops in order to bringup >> the various cores (and clusters) found on this SoC. > > Hrm. that's unfortunate. Is there any public documentation of what the bug is? The security extensions in the A80 and A83T is not entirely enabled. The security bit is not forwarded on to the bus, so all accesses from non-secure become secure. This is not documented, but was the result of some tests I did. See https://lists.denx.de/pipermail/u-boot/2017-June/294672.html for a summary (in the quotes) of what we think is the issue. Marc's suggestion is that if virtualization doesn't work on it, then there's no point in running it non-secure. [1] ChenYu [1] https://lists.denx.de/pipermail/u-boot/2017-June/294697.html
On Sat, May 26, 2018 at 6:22 PM, Chen-Yu Tsai <wens@csie.org> wrote: > On Fri, May 25, 2018 at 2:02 PM, Olof Johansson <olof@lixom.net> wrote: >> On Mon, May 21, 2018 at 01:41:56PM +0200, Maxime Ripard wrote: >>> Hi, >>> >>> Here is our mach-sunxi changes for the next merge window, thanks! >>> Maxime >>> >>> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: >>> >>> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) >>> >>> are available in the Git repository at: >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-core-for-4.18 >>> >>> for you to fetch changes up to 6961275e72a8c15cc4ebf108a81eee758480a6a2: >>> >>> ARM: sun8i: smp: Add support for A83T (2018-05-08 15:00:20 +0200) >>> >>> ---------------------------------------------------------------- >>> Allwinner core changes for 4.18 >>> >>> The A83t, unlike the other Allwinner SoCs, cannot use PSCI because of a >>> silicon bug. As such, we needed to have some smp_ops in order to bringup >>> the various cores (and clusters) found on this SoC. >> >> Hrm. that's unfortunate. Is there any public documentation of what the bug is? > > The security extensions in the A80 and A83T is not entirely enabled. > The security bit is not forwarded on to the bus, so all accesses from > non-secure become secure. This is not documented, but was the result > of some tests I did. > > See https://lists.denx.de/pipermail/u-boot/2017-June/294672.html > for a summary (in the quotes) of what we think is the issue. > > Marc's suggestion is that if virtualization doesn't work on it, then > there's no point in running it non-secure. [1] So it sounds like you can still use PSCI even if there's nothing that stops the kernel from also doing the same operations. It doesn't buy you any security benefits, but you can use the same standard interfaces as everybody else does. I think there's still value in that. Or am I missing some aspect of the errata implications? -Olof
On Sat, May 26, 2018 at 11:21 AM, Olof Johansson <olof@lixom.net> wrote: > On Sat, May 26, 2018 at 6:22 PM, Chen-Yu Tsai <wens@csie.org> wrote: >> On Fri, May 25, 2018 at 2:02 PM, Olof Johansson <olof@lixom.net> wrote: >>> On Mon, May 21, 2018 at 01:41:56PM +0200, Maxime Ripard wrote: >>>> Hi, >>>> >>>> Here is our mach-sunxi changes for the next merge window, thanks! >>>> Maxime >>>> >>>> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: >>>> >>>> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) >>>> >>>> are available in the Git repository at: >>>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-core-for-4.18 >>>> >>>> for you to fetch changes up to 6961275e72a8c15cc4ebf108a81eee758480a6a2: >>>> >>>> ARM: sun8i: smp: Add support for A83T (2018-05-08 15:00:20 +0200) >>>> >>>> ---------------------------------------------------------------- >>>> Allwinner core changes for 4.18 >>>> >>>> The A83t, unlike the other Allwinner SoCs, cannot use PSCI because of a >>>> silicon bug. As such, we needed to have some smp_ops in order to bringup >>>> the various cores (and clusters) found on this SoC. >>> >>> Hrm. that's unfortunate. Is there any public documentation of what the bug is? >> >> The security extensions in the A80 and A83T is not entirely enabled. >> The security bit is not forwarded on to the bus, so all accesses from >> non-secure become secure. This is not documented, but was the result >> of some tests I did. >> >> See https://lists.denx.de/pipermail/u-boot/2017-June/294672.html >> for a summary (in the quotes) of what we think is the issue. >> >> Marc's suggestion is that if virtualization doesn't work on it, then >> there's no point in running it non-secure. [1] > > So it sounds like you can still use PSCI even if there's nothing that > stops the kernel from also doing the same operations. It doesn't buy > you any security benefits, but you can use the same standard > interfaces as everybody else does. I think there's still value in > that. Or am I missing some aspect of the errata implications? IIRC the GIC does not work correctly. Interrupts are configured to be non-secure by the PSCI implementation, prior to entering the kernel. The GIC driver uses the standard registers to program or ack interrupts. But since non-secure accesses appear to be secure outside the ARM cores, it ends up touching the wrong set of registers. The driver needs to be taught to use the NS alias registers. But then, how does one confer the need for such a workaround? I actually did some patches that work for the A80, just to test things out. I asked Marc (CC-ed) for some input, and basically he said it's probably not worth the headache and trouble. ChenYu
On Sun, 27 May 2018 06:31:17 +0100, Chen-Yu Tsai wrote: > > On Sat, May 26, 2018 at 11:21 AM, Olof Johansson <olof@lixom.net> wrote: > > On Sat, May 26, 2018 at 6:22 PM, Chen-Yu Tsai <wens@csie.org> wrote: > >> On Fri, May 25, 2018 at 2:02 PM, Olof Johansson <olof@lixom.net> wrote: > >>> On Mon, May 21, 2018 at 01:41:56PM +0200, Maxime Ripard wrote: > >>>> Hi, > >>>> > >>>> Here is our mach-sunxi changes for the next merge window, thanks! > >>>> Maxime > >>>> > >>>> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: > >>>> > >>>> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) > >>>> > >>>> are available in the Git repository at: > >>>> > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-core-for-4.18 > >>>> > >>>> for you to fetch changes up to 6961275e72a8c15cc4ebf108a81eee758480a6a2: > >>>> > >>>> ARM: sun8i: smp: Add support for A83T (2018-05-08 15:00:20 +0200) > >>>> > >>>> ---------------------------------------------------------------- > >>>> Allwinner core changes for 4.18 > >>>> > >>>> The A83t, unlike the other Allwinner SoCs, cannot use PSCI because of a > >>>> silicon bug. As such, we needed to have some smp_ops in order to bringup > >>>> the various cores (and clusters) found on this SoC. > >>> > >>> Hrm. that's unfortunate. Is there any public documentation of what the bug is? > >> > >> The security extensions in the A80 and A83T is not entirely enabled. > >> The security bit is not forwarded on to the bus, so all accesses from > >> non-secure become secure. This is not documented, but was the result > >> of some tests I did. > >> > >> See https://lists.denx.de/pipermail/u-boot/2017-June/294672.html > >> for a summary (in the quotes) of what we think is the issue. > >> > >> Marc's suggestion is that if virtualization doesn't work on it, then > >> there's no point in running it non-secure. [1] > > > > So it sounds like you can still use PSCI even if there's nothing that > > stops the kernel from also doing the same operations. It doesn't buy > > you any security benefits, but you can use the same standard > > interfaces as everybody else does. I think there's still value in > > that. Or am I missing some aspect of the errata implications? > > IIRC the GIC does not work correctly. Interrupts are configured to be > non-secure by the PSCI implementation, prior to entering the kernel. > The GIC driver uses the standard registers to program or ack interrupts. > But since non-secure accesses appear to be secure outside the ARM > cores, it ends up touching the wrong set of registers. The driver > needs to be taught to use the NS alias registers. But then, how does > one confer the need for such a workaround? I actually did some patches > that work for the A80, just to test things out. > > I asked Marc (CC-ed) for some input, and basically he said it's probably > not worth the headache and trouble. I think it is worth splitting the two issues: - Yes, trying to use non-secure interrupts on a GIC that doesn't know about non-secure accesses is pretty terrible (the HW should never have made it into production). I"m definitely not entertaining the idea of taking patches for that. - I'm not sure that completely kills the idea of using PSCI. I don't think that PSCI, on its own, mandates that the OS runs in non-secure, and an implementation could probably be convinced to boot the kernel in secure mode. PSCI also doesn't say anything about the GIC, and it is just an implementation convenience to configure interrupts to be Group-1 NS as part of the PSCI implementation. At the end of the day, it is a matter of defining where we want the crap to be put (either in the firmware or in the kernel), and whether you can easily update the firmware to do PSCI and yet not mess with the GIC. Thanks, M.
Hi, Here is our mach-sunxi changes for the next merge window, thanks! Maxime The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-core-for-4.18 for you to fetch changes up to 6961275e72a8c15cc4ebf108a81eee758480a6a2: ARM: sun8i: smp: Add support for A83T (2018-05-08 15:00:20 +0200) ---------------------------------------------------------------- Allwinner core changes for 4.18 The A83t, unlike the other Allwinner SoCs, cannot use PSCI because of a silicon bug. As such, we needed to have some smp_ops in order to bringup the various cores (and clusters) found on this SoC. ---------------------------------------------------------------- Doug Berger (1): ARM: Allow this header to be included by assembly files Mylène Josserand (7): ARM: sunxi: smp: Move assembly code into a file ARM: smp: Add initialization of CNTVOFF ARM: sunxi: Add initialization of CNTVOFF ARM: shmobile: Convert file to use cntvoff ARM: sun9i: smp: Rename clusters's power-off ARM: sun9i: smp: Add is_a83t field ARM: sun8i: smp: Add support for A83T arch/arm/common/Makefile | 1 + arch/arm/common/secure_cntvoff.S | 32 +++++ arch/arm/include/asm/cputype.h | 10 +- arch/arm/include/asm/secure_cntvoff.h | 8 ++ arch/arm/mach-shmobile/common.h | 1 - arch/arm/mach-shmobile/headsmp-apmu.S | 22 +-- arch/arm/mach-shmobile/setup-rcar-gen2.c | 3 +- arch/arm/mach-sunxi/Kconfig | 2 +- arch/arm/mach-sunxi/Makefile | 2 +- arch/arm/mach-sunxi/headsmp.S | 81 +++++++++++ arch/arm/mach-sunxi/mc_smp.c | 239 +++++++++++++++++++------------ arch/arm/mach-sunxi/sunxi.c | 20 ++- 12 files changed, 298 insertions(+), 123 deletions(-) create mode 100644 arch/arm/common/secure_cntvoff.S create mode 100644 arch/arm/include/asm/secure_cntvoff.h create mode 100644 arch/arm/mach-sunxi/headsmp.S