On Fri, May 21, 2021 at 05:19:05PM -0700, Dave Jiang wrote: > The code has dependency on DEV_MSI/IMS enabling code: > https://lore.kernel.org/lkml/1614370277-23235-1-git-send-email-megha.dey@xxxxxxxxx/ > > The code has dependency on idxd driver sub-driver cleanup series: > https://lore.kernel.org/dmaengine/162163546245.260470.18336189072934823712.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxx/T/#t > > The code has dependency on Jason's VFIO refactoring: > https://lore.kernel.org/kvm/0-v2-7667f42c9bad+935-vfio3_jgg@xxxxxxxxxx/ That is quite an inter-tangled list, do you have a submission plan?? > Introducing mdev types “1dwq-v1” type. This mdev type allows > allocation of a single dedicated wq from available dedicated wqs. After > a workqueue (wq) is enabled, the user will generate an uuid. On mdev > creation, the mdev driver code will find a dwq depending on the mdev > type. When the create operation is successful, the user generated uuid > can be passed to qemu. When the guest boots up, it should discover a > DSA device when doing PCI discovery. > > For example of “1dwq-v1” type: > 1. Enable wq with “mdev” wq type > 2. A user generated uuid. > 3. The uuid is written to the mdev class sysfs path: > echo $UUID > /sys/class/mdev_bus/0000\:00\:0a.0/mdev_supported_types/idxd-1dwq-v1/create > 4. Pass the following parameter to qemu: > "-device vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:00:0a.0/$UUID" So the idxd core driver knows to create a "vfio" wq with its own much machinery but you still want to involve the horrible mdev guid stuff? Why?? Jason