(cc Bjorn)
On Mon, 26 Jul 2021 at 11:08, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
On 7/26/21 12:56 AM, Guenter Roeck wrote:
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]
IIUC, these lines are read back from the BARs
[ 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]
... and this is the assignment created by the kernel.
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]
The problem here is that Linux, for legacy reasons, does not support
I/O ports <= 0x1000 on PCI, so the I/O assignment created by EFI is
rejected.
This might make sense on x86, where legacy I/O ports may exist, but on
other architectures, this makes no sense.