On Fri, 2022-05-06 at 14:53 +0200, Arnd Bergmann wrote:
On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki <macro@xxxxxxxxxxx> wrote:
On Fri, 6 May 2022, Arnd Bergmann wrote:
If this is PCI/PCIe indeed, then an I/O access is just a different bit
pattern put on the bus/in the TLP in the address phase. So what is there
inherent to the s390 architecture that prevents that different bit pattern
from being used?
The hardware design for PCI on s390 is very different from any other
architecture, and more abstract. Rather than implementing MMIO register
access as pointer dereference, this is a separate CPU instruction that
takes a device/bar plus offset as arguments rather than a pointer, and
Linux encodes this back into a fake __iomem token.
OK, that seems to me like a reasonable and quite a clean design (on the
hardware side).
So what happens if the instruction is given an I/O rather than memory BAR
as the relevant argument? Is the address space indicator bit (bit #0)
simply ignored or what?
Not sure. My best guess is that it would actually work as you'd expect,
but is deliberately left out of the architecture specification so they don't
have to to validate the correctness. Note that only a small number of
PCIe cards are actually supported by IBM, and I think the firmware
only passes devices to the OS if they are whitelisted.
Arnd
Yes, though in Linux we do try hard to work with whatever is plugged
in. We did benefit from this in the past working with a new NIC from a
different vendor with 0 additional changes. Also you can use vfio-pci
to pass-through arbitrary PCI devices to a QEMU emulating s390x.
