From: Guenter Roeck <linux@roeck-us.net>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
Jiahui Cen <cenjiahui@huawei.com>,
philmd@redhat.com, qemu-devel@nongnu.org
Subject: Re: aarch64 efi boot failures with qemu 6.0+
Date: Sun, 25 Jul 2021 15:56:17 -0700 [thread overview]
Message-ID: <14aff6ab-0b96-fe22-bc35-18d2e8528a5b@roeck-us.net> (raw)
In-Reply-To: <20210725181334-mutt-send-email-mst@kernel.org>
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 ?
>>
>> Thanks,
>> Guenter
>
>
> 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 ?
Thanks,
Guenter
> Cc the maintainer. Philippe can you comment pls?
>
>> ---
>> Command line (tulip network interface):
>>
>> CMDLINE="root=/dev/vda console=ttyAMA0"
>> ROOTFS="rootfs.ext2"
>>
>> 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
>> virtio-net-device
>> pass pass pass
>> virtio-net-pci pass pass pass
>> virtio-net-pci-non-transitional
>> 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
>> virtio-blk-device
>> 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
>> virtio-scsi-device
>> pass pass pass
>> virtio-scsi-pci pass pass pass
>
next prev parent reply other threads:[~2021-07-25 22:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-24 18:52 aarch64 efi boot failures with qemu 6.0+ Guenter Roeck
2021-07-25 22:14 ` Michael S. Tsirkin
2021-07-25 22:56 ` Guenter Roeck [this message]
2021-07-26 9:08 ` Philippe Mathieu-Daudé
2021-07-26 16:00 ` Ard Biesheuvel
2021-07-26 21:16 ` Bjorn Helgaas
2021-07-26 21:31 ` Bjorn Helgaas
2021-07-26 21:31 ` Bjorn Helgaas
2021-07-27 4:22 ` Guenter Roeck
2021-07-27 4:22 ` Guenter Roeck
2021-07-27 14:25 ` Bjorn Helgaas
2021-07-27 14:25 ` Bjorn Helgaas
2021-07-27 4:45 ` Michael S. Tsirkin
2021-07-27 5:12 ` Guenter Roeck
2021-07-27 7:04 ` Ard Biesheuvel
2021-07-27 9:02 ` Michael S. Tsirkin
2021-07-27 9:30 ` Michael S. Tsirkin
2021-07-27 9:50 ` Ard Biesheuvel
2021-07-27 10:07 ` Michael S. Tsirkin
2021-07-27 10:14 ` Ard Biesheuvel
2022-03-18 11:48 ` Lorenzo Pieralisi
2021-07-27 11:18 ` Guenter Roeck
2021-07-27 9:01 ` Michael S. Tsirkin
2021-07-27 10:36 ` Igor Mammedov
2021-07-27 11:32 ` Guenter Roeck
2021-07-28 13:11 ` Michael S. Tsirkin
2021-07-28 13:25 ` Ard Biesheuvel
2021-07-28 14:03 ` Guenter Roeck
2021-07-29 8:08 ` Philippe Mathieu-Daudé
2021-07-29 14:42 ` Bjorn Helgaas
2021-07-29 15:59 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14aff6ab-0b96-fe22-bc35-18d2e8528a5b@roeck-us.net \
--to=linux@roeck-us.net \
--cc=cenjiahui@huawei.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.