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 -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
