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

[Maxime Ripard <maxime.ripard@free-electrons.com>]

On Wed, Jun 07, 2017 at 03:06:55PM +0100, Marc Zyngier wrote:
> > If that is so fundamentally broken that this is the only benefit, I
> > guess we might as well use some old-style SMP ops.
> 
> Broken, for sure. Which is why I'm asking about the benefits of running
> non-secure on something that has evidently been very badly integrated,
> and for which non-secure is at best an afterthought.
> 
> Now, if someone could try and run guests on this turd and report whether
> this works correctly or not, that'd be an interesting data point.
> Because in the absence of a TEE running on the secure side,
> virtualization is basically the only thing you gain from running on the
> non-secure side.

I just tried running Xen on it, with an adjustment similar to what
Chen-Yu made in the kernel.

It fails at boot, and stops with:
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER20
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER24
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER0

It looks like it won't be easy to support. I guess we could just go
for smp_ops, and if someone really cares one day about it, we'll
always have the option to support it then.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170702/1244f509/attachment.sig>