[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 for-6.0?] hw/pci-host/gpex: Don't fault for unmapped parts
From: |
Arnd Bergmann |
Subject: |
Re: [PATCH v2 for-6.0?] hw/pci-host/gpex: Don't fault for unmapped parts of MMIO and PIO windows |
Date: |
Tue, 20 Apr 2021 14:26:27 +0200 |
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.
Arnd