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

[André Przywara]

On 02/07/17 15:17, Maxime Ripard wrote:

Hi,

> 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

Those messages are normal and happen on every machine. The Xen VGIC
implementation cannot clear the active flag [1] (for more complex
reasons), and fortunately Linux and other OSes actually don't need it,
so we get away with it. What the kernel does here is to make sure that
no IRQ is active, which is basically a NOP on a pristine and just
initialized (V)GIC.

But you said that it stopped at boot? Are you sure that your Xen setup
works in the first place? Xen on A20 seems to be somewhat supported, by
maybe there is some other A83T speciality that gets in the way?

A more reliable and easier to debug test would be KVM, I guess.
You can use kvmtool[2] instead of QEMU if that is too complex to setup:
$ lkvm run -k zImage -p console=ttyS0
gives you a shell in a guest, if you want to have a proper rootfs:
$ lkvm run -k zImage -d somerootfs.img -p "console=ttyS0 root=/dev/vda"

Cheers,
Andre.

[1]
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/vgic-v2.c;hb=HEAD#l487
[2] git://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git
(just checkout and "make" on the target)

> 
> 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
>