Message-ID: <582BF432.6030506@intel.com>
Date: Wed, 16 Nov 2016 13:52:50 +0800
From: Jike Song <jike.song@intel.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Alex Williamson <alex.williamson@redhat.com>
CC: Kirti Wankhede <kwankhede@nvidia.com>, pbonzini@redhat.com,
        kraxel@redhat.com, cjia@nvidia.com, qemu-devel@nongnu.org,
        kvm@vger.kernel.org, kevin.tian@intel.com, bjsdjshi@linux.vnet.ibm.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v12 12/22] vfio: Add notifier callback to parent's ops
 structure of mdev
References: <1479138156-28905-1-git-send-email-kwankhede@nvidia.com> <1479138156-28905-13-git-send-email-kwankhede@nvidia.com> <582AAF16.5080906@intel.com> <20161115081908.070b10ae@t450s.home>
In-Reply-To: <20161115081908.070b10ae@t450s.home>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3218
Lines: 79

On 11/15/2016 11:19 PM, Alex Williamson wrote:
> On Tue, 15 Nov 2016 14:45:42 +0800
> Jike Song <jike.song@intel.com> wrote:
> 
>> On 11/14/2016 11:42 PM, Kirti Wankhede wrote:
>>> Add a notifier calback to parent's ops structure of mdev device so that per
>>> device notifer for vfio module is registered through vfio_mdev module.
>>>
>>> Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
>>> Signed-off-by: Neo Jia <cjia@nvidia.com>
>>> Change-Id: Iafa6f1721aecdd6e50eb93b153b5621e6d29b637
>>> ---
>>>  drivers/vfio/mdev/vfio_mdev.c | 19 +++++++++++++++++++
>>>  include/linux/mdev.h          |  9 +++++++++
>>>  2 files changed, 28 insertions(+)
>>>
>>> diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
>>> index ffc36758cb84..1694b1635607 100644
>>> --- a/drivers/vfio/mdev/vfio_mdev.c
>>> +++ b/drivers/vfio/mdev/vfio_mdev.c
>>> @@ -24,6 +24,15 @@
>>>  #define DRIVER_AUTHOR   "NVIDIA Corporation"
>>>  #define DRIVER_DESC     "VFIO based driver for Mediated device"
>>>  
>>> +static int vfio_mdev_notifier(struct notifier_block *nb, unsigned long action,
>>> +			      void *data)
>>> +{
>>> +	struct mdev_device *mdev = container_of(nb, struct mdev_device, nb);
>>> +	struct parent_device *parent = mdev->parent;
>>> +
>>> +	return parent->ops->notifier(mdev, action, data);
>>> +}
>>> +
>>>  static int vfio_mdev_open(void *device_data)
>>>  {
>>>  	struct mdev_device *mdev = device_data;
>>> @@ -40,6 +49,11 @@ static int vfio_mdev_open(void *device_data)
>>>  	if (ret)
>>>  		module_put(THIS_MODULE);
>>>  
>>> +	if (likely(parent->ops->notifier)) {
>>> +		mdev->nb.notifier_call = vfio_mdev_notifier;
>>> +		if (vfio_register_notifier(&mdev->dev, &mdev->nb))
>>> +			pr_err("Failed to register notifier for mdev\n");
>>> +	}  
>>
>> Hi Kirti,
>>
>> Could you please move the notifier registration before parent->ops->open()?
>> as you might know, I'm extending your vfio_register_notifier to also include
>> the attaching/detaching events of vfio_group and kvm.  Basically if vfio_group
>> not attached to any kvm instance, the parent->ops->open() should return -ENODEV
>> to indicate the failure, but to know whether kvm is available in open(), the
>> notifier registration should be earlier.
> 
> It seems like you're giving general guidance for how a vendor driver
> open() function should work, yet a hard dependency on KVM should be
> discouraged.  You're making a choice for your vendor driver alone.

I apologize for any confusion, but all I meant here was, if the real
world requires a vendor driver to indicate errors instead of false
success, it has to know some information before making the choice.

> I would also be very cautious about the coherency of signaling the KVM
> association relative to the user of the group.  Is it possible that the
> association of one KVM instance by a user of the group can leak to the
> next user?  Does vfio need to seen a gratuitous un-set of the KVM
> association on group close()? etc.  Thanks,

I failed to see how this is possible, per my understanding the
vfio_group_set_kvm gets called twice (once with kvm, another with NULL)
during kvm's holding the group reference.

Would you elaborate a bit more?


--
Thanks,
Jike