I don't have much yet to comment on the patch itself, but I've had it booting as successfully as the vexpress-a15 platform. (There's a caveat there as my vexpress setup isn't exactly perfect in the first place). The UART support is a great help while debugging boot issues, although it occurs to me it would be better still if the virt memory map placed it in the same location as the vexpress-a15, which I assume might be enough to get the earlyprintk CONFIG_DEBUG_VEXPRESS_UART0_RS1 option to work. I realise this is a big old hack, and might not work anyway, but it seems like it can only be a good thing to reduce the amount of variation in how UARTs are setup across different platforms.
One issue I've found is that virt mounts drives in the opposite order compared to the vexpress-a15. On vexpress-a15 I have to reverse the order of the -device parameters when I use multiple virtio drives:
qemu-system-arm \
-drive file=first.qcow2,if=none,id=vda \
-drive file=second.qcow2,if=none,id=vdb \
-drive file=third.qcow2,if=none,id=vdc \
-device virtio-blk-device,drive=vdc \
-device virtio-blk-device,drive=vdb \
-device virtio-blk-device,drive=vda \
-machine vexpress-a15 [...]
Whereas on virt they have to be in natural order:
qemu-system-arm \
-drive file=first.qcow2,if=none,id=vda \
-drive file=second.qcow2,if=none,id=vdb \
-drive file=third.qcow2,if=none,id=vdc \
-device virtio-blk-device,drive=vda \
-device virtio-blk-device,drive=vdb \
-device virtio-blk-device,drive=vdc \
-device virtio-fb \
-machine virt [...]
(There's some other weirdness with command-line parameter ordering that I haven't entirely got to the bottom of, something to do with other virtio devices I'm using which may or may not be related. And I'm aware the id names I've given don't have any effect on what /dev/vd* device they appear on but I've chosen to name them after where they will get mounted for my own sanity.)
I'd prefer to have vexpress behave like virt and have the first device be the first on the command line, but if there's compatibility concerns just having them both behave the same would be a start.
Cheers,
Tom
On 12 Sep 2013, at 11:17, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote:
> This patch series adds a 'virt' platform which uses the
> kernel's mach-virt (fully device-tree driven) support
> to create a simple minimalist platform intended for
> use for KVM VM guests.
>
> The major change here is that I've added a PL011 UART.
>
> Sample command line:
>
> qemu-system-arm -machine type=virt -display none \
> -kernel zImage \
> -append 'root=/dev/vda rw console=ttyAMA0 rootwait'
> -cpu cortex-a15 \
> -device virtio-blk-device,drive=foo \
> -drive if=none,file=arm-wheezy.img,id=foo \
> -m 2048 -serial stdio
>
> Note that there is no earlyprintk via the PL011 because
> there's no defined device tree binding for "hey, here
> is your earlyprintk UART".
>
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
