From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jike Song Subject: Re: [v7 0/3] plumb kvm/vfio to notify kvm:group attach/detach Date: Thu, 01 Dec 2016 10:27:58 +0800 Message-ID: <583F8AAE.5070705@intel.com> References: <1479794973-11910-1-git-send-email-jike.song@intel.com> <583CEFAA.3070600@intel.com> <20161130100657.04ba599f@t450s.home> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: pbonzini@redhat.com, guangrong.xiao@linux.intel.com, kevin.tian@intel.com, kwankhede@nvidia.com, cjia@nvidia.com, kvm@vger.kernel.org To: Alex Williamson Return-path: Received: from mga05.intel.com ([192.55.52.43]:19477 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756942AbcLAC2V (ORCPT ); Wed, 30 Nov 2016 21:28:21 -0500 In-Reply-To: <20161130100657.04ba599f@t450s.home> Sender: kvm-owner@vger.kernel.org List-ID: On 12/01/2016 01:06 AM, Alex Williamson wrote: > On Tue, 29 Nov 2016 11:02:02 +0800 > Jike Song 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