Re: [PATCH v5 03/18] pci: isolated address space for PCI bus

[Alex Williamson]

On Wed, 2 Feb 2022 05:06:49 -0500
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Wed, Feb 02, 2022 at 09:30:42AM +0000, Peter Maydell wrote:
> > > I/O port space is always the identity mapped CPU address space unless
> > > sparse translations are used to create multiple I/O port spaces (not
> > > implemented).  I/O port space is only accessed by the CPU, there are no
> > > device initiated I/O port transactions, so the address space relative
> > > to the device is irrelevant.  
> > 
> > Does the PCI spec actually forbid any master except the CPU from
> > issuing I/O port transactions, or is it just that in practice nobody
> > makes a PCI device that does weird stuff like that ?
> > 
> > thanks
> > -- PMM  
> 
> Hmm, the only thing vaguely related in the spec that I know of is this:
> 
>       PCI Express supports I/O Space for compatibility with legacy devices 
> which require their use.
>       Future revisions of this specification may deprecate the use of I/O 
> Space.
> 
> Alex, what did you refer to?

My evidence is largely by omission, but that might be that in practice
it's not used rather than explicitly forbidden.  I note that the bus
master enable bit specifies:

        Bus Master Enable - Controls the ability of a Function to issue
                Memory and I/O Read/Write Requests, and the ability of
                a Port to forward Memory and I/O Read/Write Requests in
                the Upstream direction.

That would suggest it's possible, but for PCI device assignment, I'm
not aware of any means through which we could support this.  There is
no support in the IOMMU core for mapping I/O port space, nor could we
trap such device initiated transactions to emulate them.  I can't spot
any mention of I/O port space in the VT-d spec, however the AMD-Vi spec
does include a field in the device table:

        controlIoCtl: port I/O control. Specifies whether
        device-initiated port I/O space transactions are blocked,
        forwarded, or translated.

        00b=Device-initiated port I/O is not allowed. The IOMMU target
        aborts the transaction if a port I/O space transaction is
        received. Translation requests are target aborted.
        
        01b=Device-initiated port I/O space transactions are allowed.
        The IOMMU must pass port I/O accesses untranslated. Translation
        requests are target aborted.
        
        10b=Transactions in the port I/O space address range are
        translated by the IOMMU page tables as memory transactions.

        11b=Reserved.

I don't see this field among the macros used by the Linux driver in
configuring these device entries, so I assume it's left to the default
value, ie. zero, blocking device initiated I/O port transactions.

So yes, I suppose device initiated I/O port transactions are possible,
but we have no support or reason to support them, so I'm going to go
ahead and continue believing any I/O port address space from the device
perspective is largely irrelevant ;)  Thanks,

Alex