On Tue, 13 Jul 2021 09:55:03 -0300
Jason Gunthorpe <j...@nvidia.com> wrote:
> 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().
Quoting this proposal again:
> 1) A successful binding call for the first device in the group creates
> the security context for the entire group, by:
>
> * Verifying group viability in a similar way as VFIO does;
>
> * Calling IOMMU-API to move the group into a block-dma state,
> which makes all devices in the group attached to an block-dma
> domain with an empty I/O page table;
>
> VFIO should not allow the user to mmap the MMIO bar of the bound
> device until the binding call succeeds.
The attach step is irrelevant to my question, the bind step is where
the device/group gets into a secure state for device access.
So for IGD we have two scenarios, direct assignment and software mdevs.
AIUI the operation of VFIO_DEVICE_BIND_IOMMU_FD looks like this:
iommu_ctx = iommu_ctx_fdget(iommu_fd);
mdev = mdev_from_dev(vdev->dev);
dev = mdev ? mdev_parent_dev(mdev) : vdev->dev;
iommu_dev = iommu_register_device(iommu_ctx, dev, cookie);
In either case, this last line is either registering the IGD itself
(ie. the struct device representing PCI device 0000:00:02.0) or the
parent of the GVT-g mdev (ie. the struct device representing PCI device
0000:00:02.0). They're the same! AIUI, the cookie is simply an
arbitrary user generated value which they'll use to refer to this
device via the iommu_fd uAPI.
So what magic is iommu_register_device() doing to infer my intentions
as to whether I'm asking for the IGD RID to be isolated or I'm only
creating a software context for an mdev? Thanks,
Alex
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
