Re: [PATCH v2 for-6.0?] hw/pci-host/gpex: Don't fault for unmapped parts of MMIO and PIO windows

["Philippe Mathieu-Daudé" <f4bug@amsat.org>]

On 4/20/21 2:26 PM, Arnd Bergmann wrote:
> On Tue, Apr 20, 2021 at 1:52 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>> On 4/19/21 3:42 PM, Peter Maydell wrote:
>>>>
>>>> I suspect PCI-ISA bridges to provide an EISA bus.
>>>
>>> I'm not sure what you mean here -- there isn't an ISA bridge
>>> or an EISA bus involved here. This is purely about the behaviour
>>> of the memory window the PCI host controller exposes to the CPU
>>> (and in particular the window for when a PCI device's BAR is
>>> set to "IO" rather than "MMIO"), though we change both here.
>>
>> I guess I always interpreted the IO BAR were here to address ISA
>> backward compatibility. I don't know well PCI so I'll study it
>> more. Sorry for my confused comment.
> 
> It is mostly for compatibility, but there are many layers of it:
> 
> - PCI supports actual ISA/EISA/VLB/PCMCIA/LPC/PC104/... style
>   devices behind a bridge, using I/O ports at their native address.
> 
> - PCI devices themselves can have fixed I/O ports at well-known
>   addresses, e.g. VGA or IDE/ATA adapters
> 
> - PCI devices can behave like legacy devices using port I/O
>   but use PCI resource assignment to pick an arbitrary port
>   number outside of the legacy range
> 
> - PCIe can support all of the above by virtue of being backwards
>   compatible with PCI and allowing PCI buses behind bridges,
>   though port I/O is deprecated here and often not supported at all
> 
> The first two are very rare these days, but Linux still support them
> in order to run on old hardware, and any driver for these that
> assumes a hardcoded port number can crash the kernel if the
> PCI host bridge causes an asynchronous external abort or
> similar.

Thanks for the clarification and enumeration Arnd!