> From: Alex Williamson > Sent: Thursday, March 1, 2018 4:15 AM > > A vfio ioeventfd will perform the pre-specified device write on > triggering of an eventfd. When coupled with KVM ioeventfds, this > feature allows a VM to trap a device page for virtualization, while > also registering targeted ioeventfds to maintain performance of high > frequency register writes within the trapped range. Much like the > existing interrupt eventfd/irqfd coupling, such writes can be handled > entirely in the host kernel. > > The new VFIO device ioctl may be supported by any vfio bus driver, > including mdev drivers, but the implementation here only enables > vfio-pci. This is intended as an acceleration path, bus drivers > may choose which regions to support and userspace should always > intend to fall back to non-accelerated handling when unavailable. > it's a nice feature! A curious question. Is it possible for mdev driver to directly create ioeventfd on specified offset? Currently ioeventfd requires quirks in Qemu, which must know the device detail to create ioeventfd and then connect vfio and kvm together. However mdev instance is more software defined thus I'm not sure whether asking Qemu to catch up quirk with underlying software logic could be overwhelmed. Also in case of vendor driver emulating mdev with same DID/VID as a real device, it might be difficult for Qemu to figure out whether a vfio device is a real one or mdev one to apply a mdev specific quirk. On the other hand, since vendor driver knows all the logic constructing mdev, it would be more convenient allowing vendor driver to directly create/destroy ioeventfd on its demand? Thanks Kevin
