Re: [PATCH 4/5] iommu/vt-d: Disallow SVA if devices don't support 64-bit address

From: Lu Baolu
Date: Wed Jul 21 2021 - 10:18:18 EST

On 2021/7/21 19:12, Robin Murphy wrote:
On 2021-07-21 02:50, Lu Baolu wrote:
Hi Robin,

Thanks a lot for reviewing my patch!

On 7/20/21 5:27 PM, Robin Murphy wrote:
On 2021-07-20 02:38, Lu Baolu wrote:
When the device and CPU share an address space (such as SVA), the device
must support the same addressing capability as the CPU. The CPU does not
consider the addressing ability of any device when managing the page table
of a process, so the device must have enough addressing ability to bind
the page table of the process.

Signed-off-by: Lu Baolu <>
  drivers/iommu/intel/iommu.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index f45c80ce2381..f3cca1dd384d 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -5372,6 +5372,9 @@ static int intel_iommu_enable_sva(struct device *dev)
      if (!(iommu->flags & VTD_FLAG_SVM_CAPABLE))
          return -ENODEV;
+    if (!dev->dma_mask || *dev->dma_mask != DMA_BIT_MASK(64))

Careful - VFIO doesn't set DMA masks (since it doesn't use the DMA API),

SVA doesn't work through the VFIO framework.

Did anyone say it does? My point is that, as far as I understand, the SVA UAPI is very much intended to work *with* VFIO, and even if the finer details are still mired in the /dev/ioasid discussion today we should definitely expect to see VFIO-like use-cases at some point. I certainly don't see why any of the guest SVA stuff exists already if not for VFIO-assigned devices?

Agreed. From /dev/ioasid design point of view, it's possible to have
VFIO-like use case of SVA. Perhaps the device addressing capability
could be included in GET_DEV_INFO of /dev/ioasid UAPI.

so this appears to be relying on another driver having bound previously,

Yes. You are right.

otherwise the mask would still be the default 32-bit one from pci_setup_device(). I'm not sure that's an entirely robust assumption.

Currently SVA implementation always requires a native kernel driver. The
assumption is that the drivers should check and set 64-bit addressing
capability before calling iommu_sva_xxx() APIs.

...and given that that is not a documented requirement, and certainly not a technical one (even a self-contained kernel driver could choose to only use SVA contexts and not touch the DMA API), it's an inherently fragile assumption which I'm confident *will* be broken eventually :)

Fair enough. I will drop this patch.

Thanks a lot for the comments.

Best regards,


+        return -ENODEV;
      if (intel_iommu_enable_pasid(iommu, dev))
          return -ENODEV;

Best regards,