Hi,
On Sun, Jul 02, 2017 at 04:40:20PM +0100, André Przywara wrote:
On 02/07/17 15:17, Maxime Ripard wrote:
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.
Ok.
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?
It's basically stalled, yes, and didn't start dom0. I tested Xen in the past on an A33, and it worked like a charm, but it might very well be a PEBKAC.
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"
I didn't know kvmtool, thanks for the tip.
Icenowy seems to had it running, so I guess we can just focus on KVM for now.
Maxime