Re: [PATCH] RISC-V: Add PCIe I/O BAR memory mapping

From: Paul Walmsley
Date: Thu Oct 24 2019 - 12:51:32 EST

On Thu, 24 Oct 2019, Logan Gunthorpe wrote:

> On 2019-10-24 3:14 a.m., Yash Shah wrote:
> > For I/O BARs to work correctly on RISC-V Linux, we need to establish a
> > reserved memory region for them, so that drivers that wish to use I/O BARs
> > can issue reads and writes against a memory region that is mapped to the
> > host PCIe controller's I/O BAR MMIO mapping.
> I don't think other arches do this.

$ git grep 'define PCI_IOBASE' arch/
arch/arm/include/asm/io.h:#define PCI_IOBASE ((void __iomem *)PCI_IO_VIRT_BASE)
arch/arm64/include/asm/io.h:#define PCI_IOBASE ((void __iomem *)PCI_IO_START)
arch/m68k/include/asm/io_no.h:#define PCI_IOBASE ((void __iomem *) PCI_IO_PA)
arch/microblaze/include/asm/io.h:#define PCI_IOBASE ((void __iomem *)_IO_BASE)
arch/unicore32/include/asm/io.h:#define PCI_IOBASE PKUNITY_PCILIO_BASE
arch/xtensa/include/asm/io.h:#define PCI_IOBASE ((void __iomem *)XCHAL_KIO_BYPASS_VADDR)

This is for the old x86-style, non-memory mapped I/O address space the
legacy PCI stuff that one would use in{b,w,l}()/out{b,w,l}() for.

Yash, you might consider updating your patch description to note that this
is for "legacy I/O BARs (i.e., non-MMIO BARs)" or something similar. That
might make things clearer.

> ioremap() typically just uses virtual address space in the VMALLOC
> region, PCI doesn't need it's own range. As far as I know the ioremap()
> implementation in riscv already does this.
> In any case, 16MB for PCI bar space seems woefully inadequate.

The modern MMIO PCI resources wind up in jost controller apertures, which
as you note, are usually much larger. They don't go in this legacy space.

Regarding sizing - I haven't seen any PCIe cards with more than 64KiB of
legacy I/O resources. (16MiB / 64KiB) = 256, so 16MiB sounds reasonable
from that point of view? ARM64 is using that.

- Paul