From mboxrd@z Thu Jan  1 00:00:00 1970
From: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Subject: Re: [v3 4/5] vfio: implement APIs to set/put kvm to/from vfio group
Date: Wed, 9 Nov 2016 22:00:01 +0800
Message-ID: <56d1a231-d989-d36d-d374-4188a2451db9@linux.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>
 <c94565d2-555d-fdd8-1131-4e7a316e2e4d@redhat.com>
 <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Alex Williamson <alex.williamson@redhat.com>, kwankhede@nvidia.com,
        cjia@nvidia.com, kevin.tian@intel.com, kvm@vger.kernel.org
To: Paolo Bonzini <pbonzini@redhat.com>,
        Jike Song <jike.song@intel.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mga07.intel.com ([134.134.136.100]:44429 "EHLO mga07.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752715AbcKIOHt (ORCPT <rfc822;kvm@vger.kernel.org>);
        Wed, 9 Nov 2016 09:07:49 -0500
In-Reply-To: <02c27131-80fd-b882-1838-fe56f3f871d3@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>



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.