[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: aarch64 efi boot failures with qemu 6.0+

From: Guenter Roeck
Subject: Re: aarch64 efi boot failures with qemu 6.0+
Date: Sun, 25 Jul 2021 15:56:17 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 7/25/21 3:14 PM, Michael S. Tsirkin wrote:
On Sat, Jul 24, 2021 at 11:52:34AM -0700, Guenter Roeck wrote:
Hi all,

starting with qemu v6.0, some of my aarch64 efi boot tests no longer
work. Analysis shows that PCI devices with IO ports do not instantiate
in qemu v6.0 (or v6.1-rc0) when booting through efi. The problem affects
(at least) ne2k_pci, tulip, dc390, and am53c974. The problem only affects
aarch64, not x86/x86_64.

I bisected the problem to commit 0cf8882fd0 ("acpi/gpex: Inform os to
keep firmware resource map"). Since this commit, PCI device BAR
allocation has changed. Taking tulip as example, the kernel reports
the following PCI bar assignments when running qemu v5.2.

[    3.921801] pci 0000:00:01.0: [1011:0019] type 00 class 0x020000
[    3.922207] pci 0000:00:01.0: reg 0x10: [io  0x0000-0x007f]
[    3.922505] pci 0000:00:01.0: reg 0x14: [mem 0x10000000-0x1000007f]
[    3.927111] pci 0000:00:01.0: BAR 0: assigned [io  0x1000-0x107f]
[    3.927455] pci 0000:00:01.0: BAR 1: assigned [mem 0x10000000-0x1000007f]

With qemu v6.0, the assignment is reported as follows.

[    3.922887] pci 0000:00:01.0: [1011:0019] type 00 class 0x020000
[    3.923278] pci 0000:00:01.0: reg 0x10: [io  0x0000-0x007f]
[    3.923451] pci 0000:00:01.0: reg 0x14: [mem 0x10000000-0x1000007f]

and the controller does not instantiate. The problem disapears after
reverting commit 0cf8882fd0.

Attached is a summary of test runs with various devices and qemu v5.2
as well as qemu v6.0, and the command line I use for efi boots.

Did commit 0cf8882fd0 introduce a bug, do I now need need some different
command line to instantiate PCI devices with io ports, or are such devices
simply no longer supported if the system is booted with efi support ?


So that commit basically just says don't ignore what efi did.

The issue's thus likely efi.

I don't see the problem with efi boots on x86 and x86_64.
Any idea why that might be the case ?


Cc the maintainer. Philippe can you comment pls?

Command line (tulip network interface):

CMDLINE="root=/dev/vda console=ttyAMA0"

qemu-system-aarch64 -M virt -kernel arch/arm64/boot/Image -no-reboot \
         -m 512 -cpu cortex-a57 -no-reboot \
         -device tulip,netdev=net0 -netdev user,id=net0 \
         -bios QEMU_EFI-aarch64.fd \
         -snapshot \
         -device virtio-blk-device,drive=d0 \
         -drive file=${ROOTFS},if=none,id=d0,format=raw \
         -nographic -serial stdio -monitor none \
         --append "${CMDLINE}"

Boot tests with various devices known to work in qemu v5.2.

                v5.2    v6.0    v6.0
                efi     non-efi efi
e1000           pass    pass    pass
e1000-82544gc   pass    pass    pass
e1000-82545em   pass    pass    pass
e1000e          pass    pass    pass
i82550          pass    pass    pass
i82557a         pass    pass    pass
i82557b         pass    pass    pass
i82557c         pass    pass    pass
i82558a         pass    pass    pass
i82559b         pass    pass    pass
i82559c         pass    pass    pass
i82559er        pass    pass    pass
i82562          pass    pass    pass
i82801          pass    pass    pass
ne2k_pci        pass    pass    fail    <--
pcnet           pass    pass    pass
rtl8139         pass    pass    pass
tulip           pass    pass    fail    <--
usb-net         pass    pass    pass
                pass    pass    pass
virtio-net-pci  pass    pass    pass
                pass    pass    pass

usb-xhci        pass    pass    pass
usb-ehci        pass    pass    pass
usb-ohci        pass    pass    pass
usb-uas-xhci    pass    pass    pass
virtio          pass    pass    pass
virtio-blk-pci  pass    pass    pass
                pass    pass    pass
nvme            pass    pass    pass
sdhci           pass    pass    pass
dc390           pass    pass    fail    <--
am53c974        pass    pass    fail    <--
lsi53c895ai     pass    pass    pass
mptsas1068      pass    pass    pass
lsi53c810       pass    pass    pass
megasas         pass    pass    pass
megasas-gen2    pass    pass    pass
                pass    pass    pass
virtio-scsi-pci pass    pass    pass

reply via email to

[Prev in Thread] Current Thread [Next in Thread]