Hi Jason. I hacked the idxd driver to remove mdev association and use vfio_device directly. Ran into some issues. Specifically mdev does some special handling when it comes to iommu domain. When we hit vfio_iommu_type1_attach_group(), there's a branch in there for mdev_bus_type. It sets the group with mdev_group flag, which later has effect of special handling for iommu_attach_group. And in addition, it ends up switching the bus to pci_bus_type before iommu_domain_alloc() is called. Do we need to provide similar type of handling for vfio_device that are not backed by an entire PCI device like vfio_pci? Not sure it's the right thing to do to attach these devices to pci_bus_type directly.
On 6/7/2021 12:11 PM, Jason Gunthorpe wrote:
On Mon, Jun 07, 2021 at 11:13:04AM -0700, Dave Jiang wrote:
So in step 1, we 'tag' the wq to be dedicated to guest usage and put theIt sounds like you could just as easially have a 'create new vfio'
hardware wq into enable state. For a dedicated mode wq, we can definitely
just register directly and skip the mdev step. For a shared wq mode, we can
have multiple mdev running on top of a single wq. So we need some way to
create more mdevs. We can either go with the existing established creation
path by mdev, or invent something custom for the driver as Jason suggested
to accomodate additional virtual devices for guests. We implemented the mdev
path originally with consideration of mdev is established and has a known
interface already.
file under the idxd sysfs.. Especially since you already have a bus
and dynamic vfio specific things being created on this bus.
Will explore this and using of 'struct vfio_device' without mdev.