On Fri, Feb 28, 2020 at 03:40:07PM +0100, Jean-Philippe Brucker wrote: > > > Device > > > + * 00:00.0 accesses address spaces X and Y, each corresponding to an > > > mm_struct. > > > + * Devices 00:01.* only access address space Y. In addition each > > > + * IOMMU_DOMAIN_DMA domain has a private address space, io_pgtable, > > > that is > > > + * managed with iommu_map()/iommu_unmap(), and isn't shared with the > > > CPU MMU. > > So this would allow IOVA and SVA co-exist in the same address space? > > Hmm, not in the same address space, but they can co-exist in a device. In > fact the endpoint I'm testing (hisi zip accelerator) already needs normal > DMA alongside SVA for queue management. This one is integrated on an > Arm-based platform so shouldn't be a concern for VT-d at the moment, but > I suspect we might see more of this kind of device with mixed DMA. Probably the most interesting usecases for PASID definately require this, so this is more than a "suspect we might see" We want to see the privileged kernel control the general behavior of the PCI function and delegate only some DMAs to PASIDs associated with the user mm_struct. The device is always trusted the label its DMA properly. These programming models are already being used for years now with the opencapi implementation. Jason
