On Mon, Feb 20, 2023 at 10:36:27AM +0800, Jason Wang wrote:

On Fri, Feb 17, 2023 at 6:11 PM Michael S. Tsirkin [off-list ref] wrote:

quoted

On Fri, Feb 17, 2023 at 01:35:59PM +0800, Jason Wang wrote:

quoted

On Fri, Feb 17, 2023 at 8:15 AM Jason Gunthorpe [off-list ref] wrote:

quoted

On Tue, Feb 07, 2023 at 08:08:43PM +0800, Nanyong Sun wrote:

quoted

From: Rong Wang <redacted>

Once enable iommu domain for one device, the MSI
translation tables have to be there for software-managed MSI.
Otherwise, platform with software-managed MSI without an
irq bypass function, can not get a correct memory write event
from pcie, will not get irqs.
The solution is to obtain the MSI phy base address from
iommu reserved region, and set it to iommu MSI cookie,
then translation tables will be created while request irq.

Probably not what anyone wants to hear, but I would prefer we not add
more uses of this stuff. It looks like we have to get rid of
iommu_get_msi_cookie() :\

I'd like it if vdpa could move to iommufd not keep copying stuff from
it..

Yes, but we probably need a patch for -stable.

Hmm do we? this looks like it's enabling new platforms is not a bugfix...

I think we haven't limited vDPA to any specific arch in the past?

Thanks

No, but it still fails gracefully right?

Anyway, this will need iommu maintainer's ack.  We'll see.

quoted

quoted

quoted

Also the iommu_group_has_isolated_msi() check is missing on the vdpa
path, and it is missing the iommu ownership mechanism.

Ok.

quoted

Also which in-tree VDPA driver that uses the iommu runs on ARM? Please

ifcvf and vp_vpda are two drivers that use platform IOMMU.

Thanks

quoted

don't propose core changes for unmerged drivers. :(

Jason