PCIe/PCI I/O access (was: Re: VT340 Emulation)

[Kevin Bowling]

Thanks this was interesting learning.

On Sun, Jun 27, 2021 at 9:41 AM Maciej W. Rozycki via cctalk <
cctalk at classiccmp.org> wrote:

> On Sun, 27 Jun 2021, Paul Koning wrote:
>
> > > However both serial and parallel ports remain reasonably available as
> > > PCIe option devices.  Though parallel ports seem to be made as legacy
> PCIe
> > > devices only, that is accessed with I/O rather than memory read/write
> bus
> > > cycles, which are not, as I have learnt the hard way recently,
> supported
> > > by all computer systems nowadays.  I guess x86 systems will continue
> to
> > > support them however as x86 CPUs have native I/O access instructions.
> >
> > I/O cycles on PCI have no direct connection to I/O instructions.  I've
> > routinely used I/O operations in PCI on a MIPS platform, which of course
> > has no such concept; all that was needed is to send the memory cycles to
> > the address block that the PCI bridge maps onto I/O cycles rather than
> > memory cycles.
>
>  That's not my point.  The host bridge has to implement them and some do
> not (e.g. the POWER9 PHB4).  For CPU architectures that do not have native
> I/O cycle support an MMIO window has to be defined by the host bridge for
> memory cycles decoded within that window to be forwarded downstream as
> PCIe I/O Read/Write TLPs (likewise with legacy PCI I/O Read/Write
> cycles).
> If you don't define such a window along with associated circuitry (like
> with the PHB4), then there's simply no way to produce I/O TLPs on PCIe.
>
>  When you have a CPU architecture such as x86 that does do I/O cycles
> natively, then they're just forwarded by the host bridge as PCIe I/O
> Read/Write TLPs.  Of course one can envisage an x86 host bridge that won't
> forward I/O cycles produced by the CPU to PCIe and will either terminate
> them with a bus error or let them time out, but I find it highly
> unlikely.
> For one I suspect the circuitry required to terminate unclaimed host bus
> I/O cycles is no less expensive than one to just forward them downstream;
> after all a PCIe I/O TLP is told apart from a memory TLP merely by a
> difference in a bit pattern sent downstream that encodes the cycle type,
> one of several (likewise with PCI cycles).
>
>  NB PCIe I/O Read/Write TLPs have been deprecated ever since the first
> revision of the PCIe specification and PCIe devices that do require I/O
> TLPs for operation have always been referred to as legacy PCIe devices.
> I guess support for such devices has been added to the specification so as
> to aid the industry with switching entirely to the MMIO operating model,
> with initial PCIe devices expected to be implemented by placing the
> original PCI/PCI-X ASIC behind a PCIe-to-PCI bridge, until new PCIe ASICs
> have been made.  For some option cards it seems the only way to date, e.g.
> PCIe ATM network adapters.
>
>  As it has turned out actual PCIe ASICs have been manufactured that do
> require I/O Read/Write TLPs for their operation such as said IEEE 1284
> parallel ports.  It's not actually clear to me why, but a plausible
> explanation is they have been considered too niche at that point for the
> effort required for the OS drivers to be updated.
>
>   Maciej
>