From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jike Song Subject: Re: [v3 4/5] vfio: implement APIs to set/put kvm to/from vfio group Date: Thu, 10 Nov 2016 12:13:57 +0800 Message-ID: <5823F405.5060008@intel.com> References: <1477895706-22824-1-git-send-email-jike.song@intel.com> <1477895706-22824-5-git-send-email-jike.song@intel.com> <20161107110412.5db26fd4@t450s.home> <20161107112834.2aa971df@t450s.home> <9e83a26f-e5dc-ed91-a1b5-c6f165eed7ed@redhat.com> <58231B5C.3010506@intel.com> <3e5299bc-e08e-f072-1001-7e0432cb1ca8@linux.intel.com> <02c27131-80fd-b882-1838-fe56f3f871d3@redhat.com> <56d1a231-d989-d36d-d374-4188a2451db9@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , Alex Williamson , kwankhede@nvidia.com, cjia@nvidia.com, kevin.tian@intel.com, kvm@vger.kernel.org To: Xiao Guangrong Return-path: Received: from mga11.intel.com ([192.55.52.93]:16571 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753256AbcKJERh (ORCPT ); Wed, 9 Nov 2016 23:17:37 -0500 In-Reply-To: <56d1a231-d989-d36d-d374-4188a2451db9@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/09/2016 10:00 PM, Xiao Guangrong wrote: > On 11/09/2016 09:31 PM, Paolo Bonzini wrote: >> On 09/11/2016 14:06, Xiao Guangrong wrote: >>> On 11/09/2016 08:49 PM, Jike Song wrote: >>> >>>> +void vfio_group_attach_kvm(struct vfio_group *group, struct kvm *kvm, >>>> + void (*fn)(struct kvm *)) >>>> +{ >>>> + mutex_lock(&group->udata.lock); >>> >>> This lock is needed, please see below. >> >> *not* needed I guess. > > Yes, indeed. Sorry for the typo. :( > >> >>>> + >>>> + fn(kvm); >>>> + blocking_notifier_call_chain(&group->udata.notifier, >>>> + VFIO_GROUP_NOTIFY_ATTACH_KVM, kvm); >>> >>> As this is a callback before KVM releases its last refcount, i do not >>> think vendor driver need to get additional KVM refcount. >> >> The *group* driver doesn't need it indeed. The mdev vendor driver >> however does, so it will use kvm_get_kvm under its own mutex. That is: > > Yes, own mutex is definitely can work.:) It is vendor driver internal > operation and it depends on the internal implementation. > > My idea is that we can make sure the KVM instance is valid before calling > DETACH callback. So if we can properly release all the resource associated > with the kvm instance in this callback, it is okay without additional kvm > ref. Yes, the mutex in vfio_group is actually pointless, now I understand and agree. Thanks Guangrong and Polao :) -- Thanks, Jike