For reference, here's how /proc/ioports looks on my arm64 system with this change: root@ubuntu:/home/john# more /proc/ioports 00010000-0001ffff : PCI Bus 0002:f8 00010000-00010fff : PCI Bus 0002:f9 00010000-00010007 : 0002:f9:00.0 00010000-00010007 : serial 00010008-0001000f : 0002:f9:00.1 00010008-0001000f : serial 00010010-00010017 : 0002:f9:00.2 00010018-0001001f : 0002:f9:00.2 00020000-0002ffff : PCI Bus 0004:88 00030000-0003ffff : PCI Bus 0005:78 00040000-0004ffff : PCI Bus 0006:c0 00050000-0005ffff : PCI Bus 0007:90 00060000-0006ffff : PCI Bus 000a:10 00070000-0007ffff : PCI Bus 000c:20 00080000-0008ffff : PCI Bus 000d:30
Hi Arnd,
Doesn't this mean we lose the ability to access PCI devices with legacy ISA compatibility? Most importantly, any GPU today should in theory still support VGA frame buffer mode or text console, but both of these stop working if the low I/O ports are not mapped to the corresponding PCI bus.
Hmmm.. so are you saying that there is an expectation that the kernel PIO region assigned for these devices must start at 0x0? If so, I assume it's because fixed IO ports are used.
There is of course already a problem if you have multiple PCI host bridges, and each one gets its own PIO range, which means that only one of them can have an ISA bridge with working PIO behind it.
The answer to my question, above, seems to be 'yes' now.
Another such case would be a BMC that has legacy ISA devices behind a (real or emulated) LPC bus, e.g. a 8250 UART, ps2 keyboard, RTC, or an ATA CDROM. Not sure if any of those are ever used on Arm machines. Regarding the size of the reservation, does this actually need to cover the 0x0fff...0xffff range or just 0x0000...0x0fff? I don't think there are any drivers that hardcode I/O ports beyond 0x0fff because those would not work on ISA buses but require PCI assigned BARs.
I just chose the complete legacy IO port range, that being 0x0--0xffff. If there would be no hardcoded ports beyond 0x0fff, then reserving 0x0--0xfff would work.
One more thought: There are two common ways in which PCI host bridges map their PIO ports: either each host bridge has its own 0x0...0xffff BAR range but gets remapped to an arbitrary range of port numbers in the kernel, or each host bridge uses a distinct range of port numbers, and the kernel can use a 1:1 mapping between hardware and software port numbers, i.e. the number in the BAR is the same as in the kernel. If all numbers are shifted by 0x10000, that second case no longer works, and there is always an offset.
Yes, this change would definitely break the second. But does - or could - anyone use it on arm64? I didn't think that it was possible.
Thanks, John
