[U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC

[icenowy at aosc.io <icenowy@aosc.io>]

在 2017-07-02 19:22，Marc Zyngier 写道：
> On Sun, 2 Jul 2017 15:08:12 +0800
> <icenowy@aosc.io> wrote:
> 
>> 在 2017-06-23 21:50，Chen-Yu Tsai 写道：
>> > On Fri, Jun 23, 2017 at 9:39 PM,  <icenowy@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@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@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@aosc.io>
>> >>>> > > > wrote:
>> >>>> > > > > > > >
>> >>>> > > > > > > >
>> >>>> > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
>> >>>> > > > > > > > Tsai <wens@csie.org> 写到:
>> >>>> > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
>> >>>> > > > > > > > > <icenowy@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@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?

> 
> Thanks,
> 
> 	M.
> --
> Without deviation from the norm, progress is not possible.