Re: [RFC v2] /dev/iommu uAPI proposal

[Jason Gunthorpe]

On Mon, Jul 12, 2021 at 11:56:24PM +0000, Tian, Kevin wrote:

> Maybe I misunderstood your question. Are you specifically worried
> about establishing the security context for a mdev vs. for its
> parent?

The way to think about the cookie, and the device bind/attach in
general, is as taking control of a portion of the IOMMU routing:

 - RID
 - RID + PASID
 - "software"

For the first two there can be only one device attachment per value so
the cookie is unambiguous.

For "software" the iommu layer has little to do with this - everything
is constructed outside by the mdev. If the mdev wishes to communicate
on /dev/iommu using the cookie then it has to do so using some iommufd
api and we can convay the proper device at that point.

Kevin didn't show it, but along side the PCI attaches:

        struct iommu_attach_data * iommu_pci_device_attach(
                struct iommu_dev *dev, struct pci_device *pdev,
                u32 ioasid);

There would also be a software attach for mdev:

        struct iommu_attach_data * iommu_sw_device_attach(
                struct iommu_dev *dev, struct device *pdev, u32 ioasid);

Which does not connect anything to the iommu layer.

It would have to return something that allows querying the IO page
table, and the mdev would use that API instead of vfio_pin_pages().

Jason