Re: [PATCH RFC 0/4] Fix arm64 crash for accessing unmapped IO port regions (reboot)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux