On 9/24/20 5:55 PM, Joerg Roedel wrote:
On Tue, Sep 22, 2020 at 02:10:37PM +0800, Lu Baolu wrote:
Hi Jorge and Alex,
A description of this patch series could be found here.
Hmm, I am wondering if we can avoid all this hassle and special APIs by
making the mdev framework more visible outside of the vfio code. There
is an underlying bus implementation for mdevs, so is there a reason
those can't use the standard iommu-core code to setup IOMMU mappings?
The original purpose of this series is to enable the device driver to
retrieve the aux-domain through iommu core after iommu
The domain was allocated in vfio/mdev, but it's also needed by the
device driver in mediated callbacks. The idea of this patch series is to
extend the aux-API so that the domain could be saved in group->domain
and get by the mediated driver through the existing
Back when we were developing the aux-domain, I proposed to keep the
domain in vfio/mdev.
It wasn't discussed at that time due to the lack of real consumer. Intel
is now adding aux-domain support in idxd (DMA streaming accelerator)
driver which becomes the first real consumer. So this problem is brought
back to the table.
What speaks against doing:
- IOMMU drivers capable of handling mdevs register iommu-ops
for the mdev_bus.
- iommu_domain_alloc() takes bus_type as parameter, so there can
be special domains be allocated for mdevs.
- Group creation and domain allocation will happen
automatically in the iommu-core when a new mdev is registered
through device-driver core code.
- There should be no need for special iommu_aux_* APIs, as one
can attach a domain directly to &mdev->dev with
Doing it this way will probably also keep the mdev-special code in VFIO
Fully understand now. Thanks for guide.
iommu mailing list