Re: [meta-virtualization] [PATCH v5 2/2] crosvm-image-minimal: add a reference image for crosvm demo

Hi Bruce,

> The remaining gap is qemuarm64. I can't reproduce qcs9100-ride-sx
> without the hardware, so the arm64 path is effectively un-testable
> from my side right now. Did you try qemuarm64 with nested
> virtualization (the way you did qemux86-64), and if so what
> happened? Even a "I tried, it didn't boot because X" would tell me
> whether we need to ask upstream for qemuarm64 support or whether it
> just needs some Yocto config wiring.

Nested virtualization via qemu64 was not supported on the native arm64 server I had access to nor on the qcs9100-rise-sx device. With x86-64 host running an arm64 guest which again runs a vm inside it, the setup is extremely slow, it did not boot after 8+ hrs wait time. The only sane solution given these constraints was to test on physical hw if the guestvm would boot. You are right in stating upstream qemu64 needs to do something about providing nested virtualization support that is moderately fast for arm64. Both the physical arm64 device and the arm64 server I had access to did not support native kvm accl(there was cpu support but qemu backed out) forcing me to use tcg on x86-64 which did not boot the 2nd guest(using tcg on arm64 yields the same result), its too slow or rather just stuck when trying to boot the 2nd guest from within the 1st guest. It may benefit to discuss this in quemu forums ?

The qemu cmdline I used on an x86-64 host:

qemu-system-aarch64 -cpu cortex-a57 -machine virt,virtualization=on -smp 8 -m 16376 -kernel Image -drive file=crosvm-image-minimal-qemuarm64.rootfs.ext4,format=raw,if=none,id=rootfs -device virtio-blk-pci,drive=rootfs -append "root=/dev/vda rw rootwait console=ttyAMA0 earlycon" -nographic

Last few logs(if it helps) when booting the 2nd vm using crosvm from the 1st vm:

[2026-05-26T10:04:34.465695943+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 1!
[2026-05-26T10:04:34.467123732+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 2!
[2026-05-26T10:04:34.468690776+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 3!
[2026-05-26T10:04:34.469804614+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 4!
[2026-05-26T10:04:34.471032068+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 5!
[2026-05-26T10:04:34.472381430+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 6!
[2026-05-26T10:04:34.473522822+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 7!
[2026-05-26T10:04:34.474818881+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 8!
[2026-05-26T10:04:34.476900802+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 9!
[2026-05-26T10:04:34.478251681+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 10!
[2026-05-26T10:04:34.479289071+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 11!
[2026-05-26T10:04:34.480722260+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 12!
[2026-05-26T10:04:34.482246479+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 13!
[2026-05-26T10:04:34.483322573+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 14!
[2026-05-26T10:04:34.484896724+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 15!
[2026-05-26T10:04:34.486036774+00:00 DEBUG devices::usb::xhci::device_slot] resetting device slot 16!
[2026-05-26T10:04:34.532898423+00:00 DEBUG devices::usb::xhci] xhci_controller: halt device
[2026-05-26T10:04:34.534384706+00:00 DEBUG devices::usb::xhci] xhci_controller: interrupter enable?: false
[2026-05-26T10:04:34.538624229+00:00 DEBUG devices::usb::xhci] xhci_controller: clear halt bits
[2026-05-26T10:04:34.540089300+00:00 DEBUG devices::usb::xhci] xhci_controller: interrupter enable?: true
[28761.296705] hrtimer: interrupt took 9440429 ns
[635866.980323] sched: DL replenish lagged too much
Killed

Note: I killed the process after giving up on wait time.

qemu cmd line I used on arm64 server/device:

qemu-system-aarch64   -machine virt,accel=kvm,gic-version=host,virtual
ization=on   -cpu host   -smp 4   -m 4096   -kernel Image   -drive file=crosvm-image-minimal-qemuarm64.rootfs.ext4,format=raw,if=none
,id=rootfs   -device virtio-blk-pci,drive=rootfs   -append "root=/dev/vda rw rootwait console=ttyAMA0 earlycon"   -nographic

Logs if it helps:

qemu-system-aarch64: mach-virt: KVM does not support providing Virtualization extensions to the guest CPU

> x86_64 is handled. arm64 is empty (KVM_MODULES = "" with no
> :aarch64 override). On arm64, KVM is built into the kernel and
> not a loadable module on most boards — so an empty list is right.
> But should we add explicit a :aarch64 = "" comment or some
> documentation so the reader doesn't wonder if it's a bug?

Ack. Will add the explicit override for arm64/aarch64.

> Sensible default. The PARSE-TIME do_rootfs[depends] += that uses
> this variable means changing it in local.conf actually works
> correctly (because += happens at parse time, before the dep is
> read). Worth a comment in the recipe to that effect so users know
> they can override without surprises.

Ack. Will add the comment in the bb recipe.

Thank you,
Keerthivasan Raghavan