On 2023/11/8 16:46, Tian, Kevin wrote:
From: Liu, Yi L <yi.l.liu@xxxxxxxxx>
Sent: Wednesday, November 8, 2023 3:45 PM
On 2023/10/10 16:19, Tian, Kevin wrote:
From: Liu, Yi L <yi.l.liu@xxxxxxxxx>
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.
this check assumes the device is trusted. as long as there is no way
for malicious guest to generate arbitrary interrupt messages then
it's fine.
for physical device a MemWr can be interpreted as interrupt so
we need msi isolation.
for SIOV all MemWr has pasid then we don't have such worry.
IMS is under host's control so interrupt messages are already
sanitized.
sure. this makes sense to me now.:)
--
Regards,
Yi Liu
