PCI host bridge should ignore 1- and 2-byte I/O accesses

[Henning Schild]

In PCI there are two IO modes. Deprecated Mode2 that uses single byte IO and Mode1 that uses 4byte IO.
According to the spec a host bridge that supports Mode1 should ignore all IO that is not 4bytes.

> Anytime a host bridge sees a full DWORD I/O write from the host to
> CONFIG_ADDRESS, the bridge must latch the data into its CONFIG_ADDRESS
> register. On full DWORD I/O reads to CONFIG_ADDRESS, the bridge must return the
> data in CONFIG_ADDRESS. Any other types of accesses to this address (non-DWORD)
> have no effect on CONFIG_ADDRESS and are executed as normal I/O transactions on
> the PCI bus. Therefore, the only I/O Space consumed by this register is a DWORD at the
> given address. I/O devices that share the same address but use BYTE or WORD registers
> are not affected because their transactions will pass through the host bridge unchanged.

In qemu the host bridge will accept 1-, 2-, and 4-byte reads/writes. That breakes plan9 guests that do not use the bios to access the PCI config space.

have a look at:
http://code.google.com/p/plan9front/source/browse/sys/src/9/pc/pci.c

In Lines 960-967 the check for PCI Mode1 is done. This check assumes that the 4-byte write at line 961 succeeds and the single byte write at 962 is ignored.
On qemu line 962 will not be ignored and the test in line 963 will fail.
The plan9 kernel will fall back to Mode2 which does not work.
The result is that the guest will not see any PCI devices.

I do not really have an image that you guys could quickly check this with, but i could prepare one if need be.
An easy way to reproduce this in linux would be to stick an outb between those two lines from pci_check_type1(void).

> outl(0x80000000, 0xCF8);
+ outb0x01, 0xcfb);
> if (inl(0xCF8) == 0x80000000 && pci_sanity_check(&pci_direct_conf1)) {

I did not try this but i guess on real hardware the linux kernel would still work while it would not work anymore on qemu.

I tried to come up with a patch but did not find a quick solution. I found that in hw/piic_pci.c sysbus_add_io is used which will register read/write functions for 1, 2, and 4 bytes. This is done in ioport.c ioport_register. I guess if i provided a patch you guys might not like it :). So i figured i should report the bug, let me know if you need any additional information.

[Henning Schild (k-henning-z)]

I tried the following quick fix but the BIOS does not seem to like that.

[Thomas Huth (th-huth)]

Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?

[Philippe Mathieu-Daudé (philmd)]

Cc'ing Julia (can't find her on Launchpad) because this looks
similar to a bug she has been tracking.

On 8/7/20 10:08 AM, Thomas Huth wrote:
> Looking through old bug tickets... is this still an issue with the
> latest version of QEMU? Or could we close this ticket nowadays?
>
>
> ** Changed in: qemu
> Status: New => Incomplete
>

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]