lkml.org 
[lkml]   [2021]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC v2] /dev/iommu uAPI proposal
On Tue, Jul 13, 2021 at 10:26:07AM -0600, Alex Williamson wrote:
> 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.

Binding is similar to attach, it will need to indicate the drivers
intention and a SW driver will not attach to the PCI device underneath
it.

> 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);

A default of binding to vdev->dev might turn out to be OK, but this
needs to be an overridable op in vfio_device and the SW mdevs will
have to do some 'iommu_register_sw_device()' and not pass in a dev at
all.

Jason

\
 
 \ /
  Last update: 2021-07-13 18:34    [W:0.371 / U:2.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site