qemu-arm
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]