[U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
Marc Zyngier
marc.zyngier at arm.com
Sun Jul 2 15:27:52 UTC 2017
On Sun, 2 Jul 2017 20:36:04 +0800
<icenowy at aosc.io> wrote:
> 在 2017-07-02 19:22，Marc Zyngier 写道：
> > On Sun, 2 Jul 2017 15:08:12 +0800
> > <icenowy at aosc.io> wrote:
> >
> >> 在 2017-06-23 21:50，Chen-Yu Tsai 写道：
> >> > On Fri, Jun 23, 2017 at 9:39 PM, <icenowy at aosc.io> wrote:
> >> >> 在 2017-06-23 21:35，Maxime Ripard 写道：
> >> >>>
> >> >>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icenowy at aosc.io wrote:
> >> >>>>
> >> >>>> 在 2017-06-07 20:51，Marc Zyngier 写道：
> >> >>>> > On 07/06/17 13:12, Icenowy Zheng wrote:
> >> >>>> > >
> >> >>>> > >
> >> >>>> > > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier
> >> >>>> > > <marc.zyngier at arm.com> 写到:
> >> >>>> > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
> >> >>>> > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> >> >>>> > > > > <maxime.ripard at free-electrons.com> wrote:
> >> >>>> > > > > > On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
> >> >>>> > > > > > > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng
> >> >>>> > > > > > > <icenowy at aosc.io>
> >> >>>> > > > wrote:
> >> >>>> > > > > > > >
> >> >>>> > > > > > > >
> >> >>>> > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
> >> >>>> > > > > > > > Tsai <wens at csie.org> 写到:
> >> >>>> > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
> >> >>>> > > > > > > > > <icenowy at aosc.io>
> >> >>>> > > > wrote:
> >> >>>> > > > > > > > > > As we have now a basical implementation
> >> >>>> > > > > > > > > > of PSCI for A83T, enable
> >> >>>> > > > > > > > > > non-secure boot support and PSCI on A83T now.
> >> >>>> > > > > > > > > >
> >> >>>> > > > > > > > > > Signed-off-by: Icenowy Zheng <icenowy at aosc.io>
> >> >>>> > > > > > > > > > ---
> >> >>>> > > > > > > > > > arch/arm/mach-sunxi/Kconfig | 4 ++++
> >> >>>> > > > > > > > > > 1 file changed, 4 insertions(+)
> >> >>>> > > > > > > > > >
> >> >>>> > > > > > > > > > diff --git a/arch/arm/mach-sunxi/Kconfig
> >> >>>> > > > > > > > > b/arch/arm/mach-sunxi/Kconfig
> >> >>>> > > > > > > > > > index 7ced838d6a..31d29de428 100644
> >> >>>> > > > > > > > > > --- a/arch/arm/mach-sunxi/Kconfig
> >> >>>> > > > > > > > > > +++ b/arch/arm/mach-sunxi/Kconfig
> >> >>>> > > > > > > > > > @@ -98,8 +98,12 @@ config MACH_SUN8I_A33
> >> >>>> > > > > > > > > > config MACH_SUN8I_A83T
> >> >>>> > > > > > > > > > bool "sun8i (Allwinner A83T)"
> >> >>>> > > > > > > > > > select CPU_V7
> >> >>>> > > > > > > > > > + select CPU_V7_HAS_NONSEC
> >> >>>> > > > > > > > > > + select CPU_V7_HAS_VIRT
> >> >>>> > > > > > > > > > + select ARCH_SUPPORT_PSCI
> >> >>>> > > > > > > > > > select SUNXI_GEN_SUN6I
> >> >>>> > > > > > > > > > select SUPPORT_SPL
> >> >>>> > > > > > > > > > + select ARMV7_BOOT_SEC_DEFAULT if
> >> >>>> > > > > > > > > > OLD_SUNXI_KERNEL_COMPAT
> >> >>>> > > > > > > > >
> >> >>>> > > > > > > > > The kernel does not work yet. Please have it boot to
> >> >>>> > > > > > > > > secure by
> >> >>>> > > > default
> >> >>>> > > > > > > > > regardless of the kernel. We can have it
> >> >>>> > > > > > > > > boot non-secure once the
> >> >>>> > > > > > > > > kernel
> >> >>>> > > > > > > > > has been working for a reasonable amount of time.
> >> >>>> > > > > > > > >
> >> >>>> > > > > > > > > I don't want clueless users coming and asking why it
> >> >>>> > > > > > > > > suddenly
> >> >>>> > > > stopped
> >> >>>> > > > > > > > > working. This should be an experimental feature.
> >> >>>> > > > > > > >
> >> >>>> > > > > > > > Maybe you should send out the fix, and tag them to also
> >> >>>> > > > > > > > apply to
> >> >>>> > > > > > > > stable tree.
> >> >>>> > > > > > > >
> >> >>>> > > > > > > > GIC is really broken, UP systems only work by chance. We
> >> >>>> > > > > > > > shouldn't depend on this behavior.
> >> >>>> > > > > > >
> >> >>>> > > > > > > As I previously explained, it is not the GIC that is broken.
> >> >>>> > > > > > > I
> >> >>>> > > > believe
> >> >>>> > > > > > > the GIC is working exactly as it is supposed to with
> >> >>>> > > > > > > regards to its
> >> >>>> > > > > > > input signals.
> >> >>>> > > > > > >
> >> >>>> > > > > > > Allwinner's security extensions implementation simply does
> >> >>>> > > > > > > not
> >> >>>> > > > properly
> >> >>>> > > > > > > forward the AXI secure bit when the e-fuse's secure bit isn't
> >> >>>> > > > burned.
> >> >>>> > > >
> >> >>>> > > > Arghh. Puke. Now I remember this, and I wish I didn't...
> >> >>>> > > >
> >> >>>> > > > > > Is that on all revisions, or just the revB ?
> >> >>>> > > > >
> >> >>>> > > > > It's the A80, but I'm guessing the same applies to the A83T. It's
> >> >>>> > > > more
> >> >>>> > > > > of a guess really, but I think it's a logical one. If the e-fuse
> >> >>>> > > > isn't
> >> >>>> > > > > programmed, the TZPC doesn't work, and access to all secure
> >> >>>> > > > peripherals
> >> >>>> > > > > still work, even from non-secure mode. The only one that
> >> >>>> > > > > does work is
> >> >>>> > > > > the secure SRAM.
> >> >>>> > > > >
> >> >>>> > > > > The GIC still has the banked secure/non-secure registers, just
> >> >>>> > > > > that
> >> >>>> > > > all
> >> >>>> > > > > cores access the secure bank, even when in non-secure mode. The
> >> >>>> > > > workaround
> >> >>>> > > > > is to use the alias set of non-secure registers in Linux.
> >> >>>> > > >
> >> >>>> > > > That's a pretty dire workaround. Also, I expect that secure writes
> >> >>>> > > > to
> >> >>>> > > > GICV/GICH will not do the right thing. At this point, what is the
> >> >>>> > > > requirement for running non-secure?
> >> >>>> > >
> >> >>>> > > Write Secure Boot eFUSE, which will break *all* existing softwares.
> >> >>>> >
> >> >>>> > Don't do it, then.
> >> >>>> >
> >> >>>> > Any other *real* use case for running non-secure? As in "Stuff that
> >> >>>> > would benefit to a user"? Because if the answer is "none" as I suspect
> >> >>>> > it is, you might as well keep the system in secure mode.
> >> >>>>
> >> >>>> Maybe we should then use legacy SMP bringup method (code in kernel)
> >> >>>> rather than PSCI?
> >> >>>
> >> >>>
> >> >>> I guess it all depends on the answer to Marc's question. If
> >> >>> virtualization doesn't work, then we don't have any incentive anymore
> >> >>> to use PSCI and that would be a sensible option, yes.
> >> >>
> >> >>
> >> >> I remember non-secure is a dependency for virtualization (HYP mode).
> >> >>
> >> >> So if we do not do the workaround on GIC, we won't have stable
> >> >> non-secure, then we won't have HYP mode, then we can drop PSCI.
> >> >
> >> > I think you got it the other way around.
> >> >
> >> > If virtualization doesn't work, despite the workaround, then there's
> >> > no need for it, and we can just do legacy SMP.
> >>
> >> I tried `qemu-system-arm -enable-kvm` on A83T with this patchset and
> >> Chen-Yu's GIC workaround patchset, and *FAILED*.
> >>
> >> The workaround patchset in fact slightly broke vGIC code by changing
> >> a macro name -- it's easy to fix.
> >>
> >> However, it seems that with this fixed the KVM cannot still work --
> >> I tried to start a virtual machine, but it silently fails (no kernel
> >> log are shown when the VM starting fails).
> >>
> >> So, at least this workaround cannot let virtualization work.
> >
> > Before discounting it altogether, it'd be interesting to find out what
> > breaks exactly. How did you start the guest? What is the failure mode?
>
> Oh, I'm sorry. I used wrong command for it... (forgot -cpu host
> parameter)
>
> Now it works.
>
> Virtual machine boot log is available at [1].
>
> [1] https://pastebin.anthonos.org/view/66a9ca54
>
> So it may be valuable to apply the workaround now?
It definitely requires extra testing (booting the kernel hardly shakes
the GIC), but that's certainly encouraging. Can you run some
significant workload in a guest (kernel compilation, hackbench) and
report the results?
If the above shows that nothing bad happens, I'd like to see a full
picture of the required changes on the host kernel side and see how we
can support this in a non-invasive way.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
More information about the U-Boot
mailing list