kern/57067: QEMU arm and aarch64 panics on -current in vioif or hangs if vioif is disabled

To: kern-bug-people%netbsd.org@localhost,gnats-admin%netbsd.org@localhost,netbsd-bugs%netbsd.org@localhost
Subject: kern/57067: QEMU arm and aarch64 panics on -current in vioif or hangs if vioif is disabled
From: brad%anduin.eldar.org@localhost
Date: Fri, 21 Oct 2022 01:15:01 +0000 (UTC)

>Number:         57067
>Category:       kern
>Synopsis:       QEMU arm and aarch64 panics on -current in vioif or hangs if vioif is disabled
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Oct 21 01:15:01 +0000 2022
>Originator:     brad%anduin.eldar.org@localhost
>Release:        NetBSD 9.99.101
>Organization:
	eldar.org
>Environment:
System: (QEMU host) NetBSD nbsd9test 9.2_STABLE NetBSD 9.2_STABLE (XEN3_DOMU) #0: Thu Jul 28 08:57:05 EDT 2022  brad%samwise.nat.eldar.org@localhost:/usr/src/sys/arch/amd64/compile/XEN3_DOMU amd64
Architecture: x86_64
Machine: amd64
>Description:

(this may be a QEMU bug...)

Given a QEMU host that is a 9.2_STABLE build with QEMU 7.0.0 built from pkgsrc 2022Q2.  The following command was used:

qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -m 1g -drive if=none,file=arm64.img,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -netdev type=user,id=net0 -device virtio-net-device,netdev=net0,mac=00:11:22:33:44:55 -bios QEMU_EFI_ARM64.fd -nographic

This is more or less the example from: https://wiki.netbsd.org/ports/evbarm/qemu_arm/

The arm64.img file is from a build of 9.99.101 and QEMU_EFI_ARM64.fd
is a rename of this:

https://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/4480/QEMU-AARCH64/RELEASE_GCC5/QEMU_EFI.fd


Booting this will produce the following panic on a 9.99.101 image:

[   1.0000040] vioif0 at virtio30: features: 0x31870020<EVENT_IDX,INDIRECT_DESC,NOTIFY_ON_EMPTY,CTRL_MAC,CTRL_RX,CTRL_VQ,STATUS,MAC>
[   1.0000040] vioif0: Ethernet address 00:11:22:33:44:55
[   1.0000040] panic: kernel diagnostic assertion "len > 0 && offset + len <= map->dm_mapsize" failed: file "/usr/src/sys/arch/arm/arm32/bus_dma.c", line 1112 len 22 offset 5 mapsize 8
[   1.0000040] cpu0: Begin traceback...
[   1.0000040] trace fp ffffc000011f3fc0
[   1.0000040] fp ffffc000011f3ff0 vpanic() at ffffc00000583498 netbsd:vpanic+0x178
[   1.0000040] fp ffffc000011f4050 kern_assert() at ffffc00000817648 netbsd:kern_assert+0x58
[   1.0000040] fp ffffc000011f40e0 _bus_dmamap_sync() at ffffc000000ab674 netbsd:_bus_dmamap_sync+0x90
[   1.0000040] fp ffffc000011f4150 virtio_init_vq() at ffffc000007a34a0 netbsd:virtio_init_vq+0x1a0
[   1.0000040] fp ffffc000011f41c0 virtio_alloc_vq() at ffffc000007a47bc netbsd:virtio_alloc_vq+0x2c8
[   1.0000040] fp ffffc000011f42a0 vioif_attach() at ffffc000007aa7d8 netbsd:vioif_attach+0xe28
[   1.0000040] fp ffffc000011f43a0 config_attach_internal() at ffffc00000563adc netbsd:config_attach_internal+0x1b8
[   1.0000040] fp ffffc000011f4400 config_found() at ffffc00000563d38 netbsd:config_found+0xd8
[   1.0000040] fp ffffc000011f4470 virtio_acpi_attach() at ffffc00000089c30 netbsd:virtio_acpi_attach+0x170
[   1.0000040] fp ffffc000011f4540 config_attach_internal() at ffffc00000563adc netbsd:config_attach_internal+0x1b8
[   1.0000040] fp ffffc000011f45a0 config_found() at ffffc00000563d38 netbsd:config_found+0xd8
[   1.0000040] fp ffffc000011f4610 acpi_rescan() at ffffc0000007a014 netbsd:acpi_rescan+0x2d4
[   1.0000040] fp ffffc000011f4730 acpi_attach() at ffffc0000007a578 netbsd:acpi_attach+0x3c8
[   1.0000040] fp ffffc000011f4800 config_attach_internal() at ffffc00000563adc netbsd:config_attach_internal+0x1b8
[   1.0000040] fp ffffc000011f4860 config_found() at ffffc00000563d38 netbsd:config_found+0xd8
[   1.0000040] fp ffffc000011f4900 acpi_fdt_attach() at ffffc00000078218 netbsd:acpi_fdt_attach+0xb8
[   1.0000040] fp ffffc000011f4980 config_attach_internal() at ffffc00000563adc netbsd:config_attach_internal+0x1b8
[   1.0000040] fp ffffc000011f49e0 config_attach() at ffffc00000563e54 netbsd:config_attach+0x54
[   1.0000040] fp ffffc000011f4a50 fdt_scan() at ffffc00000697424 netbsd:fdt_scan+0x164
[   1.0000040] fp ffffc000011f4be0 fdt_rescan() at ffffc00000697940 netbsd:fdt_rescan+0x50
[   1.0000040] fp ffffc000011f4c10 config_attach_internal() at ffffc00000563adc netbsd:config_attach_internal+0x1b8
[   1.0000040] fp ffffc000011f4c70 config_found() at ffffc00000563d38 netbsd:config_found+0xd8
[   1.0000040] fp ffffc000011f4ce0 arm_fdt_attach() at ffffc00000072b68 netbsd:arm_fdt_attach+0x94
[   1.0000040] fp ffffc000011f4d40 config_attach_internal() at ffffc00000563adc netbsd:config_attach_internal+0x1b8
[   1.0000040] fp ffffc000011f4da0 config_rootfound() at ffffc00000563f04 netbsd:config_rootfound+0x64
[   1.0000040] fp ffffc000011f4e00 cpu_configure() at ffffc0000006e64c netbsd:cpu_configure+0x4c
[   1.0000040] fp ffffc000011f4e30 main() at ffffc00000817924 netbsd:main+0x2d4
[   1.0000040] fp 0000000000000000 aarch64_start() at ffffc0000000189c netbsd:aarch64_start+0x109c
[   1.0000040] cpu0: End traceback...
Stopped in pid 0.0 (system) at  netbsd:cpu_Debugger+0xc:        ldp     x29, x30
, [sp],#16

If 4 cpus and 4GB of memory are used (as the docs have) the same panic
will still happen.

If one stops the boot and uses "userconf disable vioif" and then
"boot", the kernel will get further but will produce a line from qemu
before the guest hangs:

(if you limit the guest to 1 CPU and 1GB)
[   1.0000040] vendor 1b36 product 0008 (host bridge) at pci0 dev 0 function 0 not configured
[   1.0000040] acpiged0 at acpi0 (GED, ACPI0013-GED): irq 41
[   1.0000040] acpibut0 at acpi0 (PWRB, PNP0C0C-0): ACPI Power Button
qemu-system-aarch64: virtio: bogus descriptor or out of resources
[   1.0000040] cpu0: PMU interrupting on irq 23
[   1.3784087] WARNING: system needs entropy for security; see entropy(7)

(if you allow the guest to have 4 CPUs and 4GB)
[   1.0000040] vendor 1b36 product 0008 (host bridge) at pci0 dev 0 function 0 not configured
[   1.0000040] acpiged0 at acpi0 (GED, ACPI0013-GED): irq 41
[   1.0000040] acpibut0 at acpi0 (PWRB, PNP0C0C-0): ACPI Power Button
qemu-system-aarch64: virtio-blk missing headers
[   4.8920296] cpu0: PMU interrupting on irq 23
[   5.8825180] WARNING: system needs entropy for security; see entropy(7)

The first message hints that the guest may have sent something down
the virtio path that qemu didn't like (at least some talk on the Net
implies that).

In either case, the guest does not continue to boot.  These two
problems happen on armv7 or aarch64 images.  I also tried the images
on ArchLinux using QEMU verion 7.0.1 and the same panic and hangs
occur.

At one point I have seen this work.

>How-To-Repeat:

Try a recent -current armv7 or aarch64 image from the gzimg of a
release with qemu using the documention at

https://wiki.netbsd.org/ports/evbarm/qemu_arm/

>Fix:

Don't know, unsure if this a qemu bug or a NetBSD bug, honestly...

Prev by Date: NetBSD Nightly Trouble Ticket Report
Next by Date: Re: kern/57067 (QEMU arm and aarch64 panics on -current in vioif or hangs if vioif is disabled)
Previous by Thread: kern/57066: Concurrent O_DIRECT and fork() can flood the kernel log and reduce tmpfs capacity to 0
Next by Thread: Re: kern/57067 (QEMU arm and aarch64 panics on -current in vioif or hangs if vioif is disabled)
Indexes:

Home | Main Index | Thread Index | Old Index