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 <baolu...@linux.intel.com>
---
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,
baolu
Robin.
+ return -ENODEV;
+
if (intel_iommu_enable_pasid(iommu, dev))
return -ENODEV;
Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
