qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: Re: [PATCH v5 03/18] pci: isolated address space for PCI bus
Date: Wed, 2 Feb 2022 11:53:55 -0500

On Wed, Feb 02, 2022 at 08:49:33AM -0700, Alex Williamson wrote:
> > 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

Right, it would seem devices can initiate I/O space transactions but IOMMUs
don't support virtualizing them and so neither does VFIO.


-- 
MST




reply via email to

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