On 12/01/2016 01:06 AM, Alex Williamson wrote: > On Tue, 29 Nov 2016 11:02:02 +0800 > Jike Song <jike.song@xxxxxxxxx> wrote: > >> On 11/22/2016 02:09 PM, Jike Song wrote: >>> So far KVM and VFIO are mostly transparent to each other. >>> However, there are users who would rely on them both. For >>> example, KVMGT relies on VFIO to mediate device operations, >>> and it also relies on KVM for features such as guest page >>> tracking. To do that, it needs to know which KVM instance >>> a vfio_group is attached to, when it will be detached. >>> >>> There is already a kvm_vfio device serving for similar >>> purpose, this series extends it to allow users register >>> notifiers on a vfio_group, and notify kvm:group attaching >>> and detaching events to that. >>> >>> >>> Changes v7: >>> - replace vfio->opened with container user like iommu notifier registration >>> - fix a typo >>> Changes v6: >>> - only allow registration on already opened vfio_group >>> - moved WARN_ON from vfio_group_release to vfio_group_fops_release >>> - remove unnecessary check >>> Changes v5: >>> - separate vfio_group and vfio_iommu events from each other >>> - force user to specify which type it is interested in, and which events. >>> Register it IFF all required events are supported >>> Changes v4: >>> - use a notifier-based implementation in vfio_group >>> - combine the notifier along with iommu notifier by Kirti >>> Changes v3: >>> - don't touch kvm_put_kvm, vfio won't need it >>> - fix a race condition >>> Changes v2: >>> - As Paolo suggested, drop the type and get/put ops from >>> vfio, assuming that the data will always be kvm. >>> >>> >>> >>> Jike Song (3): >>> vfio: vfio_register_notifier: classify iommu notifier >>> vfio: support notifier chain in vfio_group >>> kvm: set/clear kvm to/from vfio_group when group add/delete >>> >>> drivers/vfio/vfio.c | 167 ++++++++++++++++++++++++++++++++++++++++++++------- >>> include/linux/vfio.h | 22 ++++++- >>> virt/kvm/vfio.c | 31 ++++++++++ >>> 3 files changed, 195 insertions(+), 25 deletions(-) >> >> Hi Alex, >> >> Since Paolo has ACKed a previous version of PATCH [3/3] before, if you have >> no more comments on this series, could you pick them up? Please be aware that >> 1/3 was updated, or I can send a v8 if you prefer :) > > Sorry for the delay, I was on holiday. Please send a v8, particularly > since I noted updates in patch 3/3 as well. I would prefer to commit > this with a R-b from Kirti since the NVIDIA driver is also affected by > this, but I believe this is the right approach for us long term. I'm > also having trouble finding an ack from Paolo that's particularly > relevant for the kvm-vfio portion, but I don't think this is a > controversial issue, I feel comfortable that he's onboard with the > idea. Thanks, Hi Alex, Yes thanks, I will push the v8 asap. Hi Kirti, I will commit 1/3 with your R-b in next version, hope you are okay with that :-) Hi Paolo, I got you ACK on one of v3: http://www.spinics.net/lists/kvm/msg139498.html Now 3/3 of this version is a little different: kvm_get_kvm is removed from kvm_vfio_group_set_kvm, and kvm_put_kvm is removed from kvm_vfio_group_put_kvm, since: the former is already in kvm_ioctl_create_device, and the latter is already in kvm_device_release. Are you okay with that? I'll still put your ACK in 3/3, hope you are okay with that :-) -- Thanks, Jike -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
