Messages in this thread | | | Date | Wed, 8 Nov 2023 15:45:17 +0800 | Subject | Re: [RFC 3/7] iommufd: Add iommufd_device_bind_pasid() | From | Yi Liu <> |
| |
On 2023/10/10 16:19, Tian, Kevin wrote: >> From: Liu, Yi L <yi.l.liu@intel.com> >> Sent: Monday, October 9, 2023 4:51 PM >> >> +struct iommufd_device *iommufd_device_bind_pasid(struct iommufd_ctx >> *ictx, >> + struct device *dev, >> + u32 pasid, u32 *id) >> +{ >> + struct iommufd_device *idev; >> + int rc; >> + >> + /* >> + * iommufd always sets IOMMU_CACHE because we offer no way for >> userspace >> + * to restore cache coherency. >> + */ >> + if (!device_iommu_capable(dev, IOMMU_CAP_CACHE_COHERENCY)) >> + return ERR_PTR(-EINVAL); >> + >> + /* >> + * No iommu supports pasid-granular msi message today. Here we >> + * just check whether the parent device can do safe interrupts. >> + * Isolation between virtual devices within the parent device >> + * relies on the parent driver to enforce. >> + */ >> + if (!iommufd_selftest_is_mock_dev(dev) && >> + !msi_device_has_isolated_msi(dev)) { >> + rc = iommufd_allow_unsafe_interrupts(dev); >> + if (rc) >> + return ERR_PTR(rc); >> + } >> + > > Only MemWr w/o pasid can be interpreted as an interrupt message > then we need msi isolation to protect.
yes.
> > But for SIOV all MemWr's are tagged with a pasid hence can never > trigger an interrupt. From this angle looks this check is unnecessary.
But the interrupts out from a SIOV virtual device do not have pasid (at least today). Seems still need a check here if we consider this bind for a SIOV virtual device just like binding a physical device.
-- Regards, Yi Liu
| |