All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: stefanha@redhat.com, christophe.de.dinechin@gmail.com,
	kvm@vger.kernel.org, mst@redhat.com, airlied@linux.ie,
	joonas.lahtinen@linux.intel.com, heiko.carstens@de.ibm.com,
	dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org, kwankhede@nvidia.com,
	rob.miller@broadcom.com, linux-s390@vger.kernel.org,
	sebott@linux.ibm.com, lulu@redhat.com, eperezma@redhat.com,
	pasic@linux.ibm.com, borntraeger@de.ibm.com,
	haotian.wang@sifive.com, zhi.a.wang@intel.com,
	farman@linux.ibm.com, idos@mellanox.com, gor@linux.ibm.com,
	intel-gfx@lists.freedesktop.org, jani.nikula@linux.intel.com,
	rodrigo.vivi@intel.com, xiao.w.wang@intel.com,
	freude@linux.ibm.com, zhenyuw@linux.intel.com,
	parav@mellanox.com, zhihong.wang@intel.com,
	intel-gvt-dev@lists.freedesktop.org, akrowiak@linux.ibm.com,
	oberpar@linux.ibm.com, netdev@vger.kernel.org, cohuck@redhat.com,
	linux-kernel@vger.ke
Subject: Re: [PATCH V5 1/6] mdev: class id support
Date: Fri, 25 Oct 2019 09:42:31 +0800	[thread overview]
Message-ID: <c8ab994e-8daa-926c-c91d-785e9d3c5044__19742.3959428974$1571967803$gmane$org@redhat.com> (raw)
In-Reply-To: <20191024141330.017a6480@x1.home>


On 2019/10/25 上午4:13, Alex Williamson wrote:
> On Thu, 24 Oct 2019 13:46:36 -0600
> Alex Williamson <alex.williamson@redhat.com> wrote:
>
>> On Thu, 24 Oct 2019 11:27:36 +0800
>> Jason Wang <jasowang@redhat.com> wrote:
>>
>>> On 2019/10/24 上午5:42, Alex Williamson wrote:
>>>> On Wed, 23 Oct 2019 21:07:47 +0800
>>>> Jason Wang <jasowang@redhat.com> wrote:
>>>>     
>>>>> Mdev bus only supports vfio driver right now, so it doesn't implement
>>>>> match method. But in the future, we may add drivers other than vfio,
>>>>> the first driver could be virtio-mdev. This means we need to add
>>>>> device class id support in bus match method to pair the mdev device
>>>>> and mdev driver correctly.
>>>>>
>>>>> So this patch adds id_table to mdev_driver and class_id for mdev
>>>>> device with the match method for mdev bus.
>>>>>
>>>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>>>>> ---
>>>>>    .../driver-api/vfio-mediated-device.rst       |  5 +++++
>>>>>    drivers/gpu/drm/i915/gvt/kvmgt.c              |  1 +
>>>>>    drivers/s390/cio/vfio_ccw_ops.c               |  1 +
>>>>>    drivers/s390/crypto/vfio_ap_ops.c             |  1 +
>>>>>    drivers/vfio/mdev/mdev_core.c                 | 18 +++++++++++++++
>>>>>    drivers/vfio/mdev/mdev_driver.c               | 22 +++++++++++++++++++
>>>>>    drivers/vfio/mdev/mdev_private.h              |  1 +
>>>>>    drivers/vfio/mdev/vfio_mdev.c                 |  6 +++++
>>>>>    include/linux/mdev.h                          |  8 +++++++
>>>>>    include/linux/mod_devicetable.h               |  8 +++++++
>>>>>    samples/vfio-mdev/mbochs.c                    |  1 +
>>>>>    samples/vfio-mdev/mdpy.c                      |  1 +
>>>>>    samples/vfio-mdev/mtty.c                      |  1 +
>>>>>    13 files changed, 74 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst
>>>>> index 25eb7d5b834b..6709413bee29 100644
>>>>> --- a/Documentation/driver-api/vfio-mediated-device.rst
>>>>> +++ b/Documentation/driver-api/vfio-mediated-device.rst
>>>>> @@ -102,12 +102,14 @@ structure to represent a mediated device's driver::
>>>>>          * @probe: called when new device created
>>>>>          * @remove: called when device removed
>>>>>          * @driver: device driver structure
>>>>> +      * @id_table: the ids serviced by this driver
>>>>>          */
>>>>>         struct mdev_driver {
>>>>>    	     const char *name;
>>>>>    	     int  (*probe)  (struct device *dev);
>>>>>    	     void (*remove) (struct device *dev);
>>>>>    	     struct device_driver    driver;
>>>>> +	     const struct mdev_class_id *id_table;
>>>>>         };
>>>>>    
>>>>>    A mediated bus driver for mdev should use this structure in the function calls
>>>>> @@ -170,6 +172,9 @@ that a driver should use to unregister itself with the mdev core driver::
>>>>>    
>>>>>    	extern void mdev_unregister_device(struct device *dev);
>>>>>    
>>>>> +It is also required to specify the class_id in create() callback through::
>>>>> +
>>>>> +	int mdev_set_class(struct mdev_device *mdev, u16 id);
>>>>>    
>>>>>    Mediated Device Management Interface Through sysfs
>>>>>    ==================================================
>>>>> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
>>>>> index 343d79c1cb7e..6420f0dbd31b 100644
>>>>> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
>>>>> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
>>>>> @@ -678,6 +678,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
>>>>>    		     dev_name(mdev_dev(mdev)));
>>>>>    	ret = 0;
>>>>>    
>>>>> +	mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
>>>>>    out:
>>>>>    	return ret;
>>>>>    }
>>>>> diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
>>>>> index f0d71ab77c50..cf2c013ae32f 100644
>>>>> --- a/drivers/s390/cio/vfio_ccw_ops.c
>>>>> +++ b/drivers/s390/cio/vfio_ccw_ops.c
>>>>> @@ -129,6 +129,7 @@ static int vfio_ccw_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
>>>>>    			   private->sch->schid.ssid,
>>>>>    			   private->sch->schid.sch_no);
>>>>>    
>>>>> +	mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
>>>>>    	return 0;
>>>>>    }
>>>>>    
>>>>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
>>>>> index 5c0f53c6dde7..07c31070afeb 100644
>>>>> --- a/drivers/s390/crypto/vfio_ap_ops.c
>>>>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>>>>> @@ -343,6 +343,7 @@ static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
>>>>>    	list_add(&matrix_mdev->node, &matrix_dev->mdev_list);
>>>>>    	mutex_unlock(&matrix_dev->lock);
>>>>>    
>>>>> +	mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
>>>>>    	return 0;
>>>>>    }
>>>>>    
>>>>> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
>>>>> index b558d4cfd082..3a9c52d71b4e 100644
>>>>> --- a/drivers/vfio/mdev/mdev_core.c
>>>>> +++ b/drivers/vfio/mdev/mdev_core.c
>>>>> @@ -45,6 +45,16 @@ void mdev_set_drvdata(struct mdev_device *mdev, void *data)
>>>>>    }
>>>>>    EXPORT_SYMBOL(mdev_set_drvdata);
>>>>>    
>>>>> +/* Specify the class for the mdev device, this must be called during
>>>>> + * create() callback.
>>>>> + */
>>>>> +void mdev_set_class(struct mdev_device *mdev, u16 id)
>>>>> +{
>>>>> +	WARN_ON(mdev->class_id);
>>>>> +	mdev->class_id = id;
>>>>> +}
>>>>> +EXPORT_SYMBOL(mdev_set_class);
>>>>> +
>>>>>    struct device *mdev_dev(struct mdev_device *mdev)
>>>>>    {
>>>>>    	return &mdev->dev;
>>>>> @@ -135,6 +145,7 @@ static int mdev_device_remove_cb(struct device *dev, void *data)
>>>>>     * mdev_register_device : Register a device
>>>>>     * @dev: device structure representing parent device.
>>>>>     * @ops: Parent device operation structure to be registered.
>>>>> + * @id: class id.
>>>>>     *
>>>>>     * Add device to list of registered parent devices.
>>>>>     * Returns a negative value on error, otherwise 0.
>>>>> @@ -324,6 +335,13 @@ int mdev_device_create(struct kobject *kobj,
>>>>>    	if (ret)
>>>>>    		goto ops_create_fail;
>>>>>    
>>>>> +	if (!mdev->class_id) {
>>>>> +		ret = -EINVAL;
>>>>> +		WARN(1, "class id must be specified for device %s\n",
>>>>> +		     dev_name(dev));
>>>> Nit, dev_warn(dev, "mdev vendor driver failed to specify device class\n");
>>>
>>> Will fix.
>>>
>>>    
>>>>     
>>>>> +		goto add_fail;
>>>>> +	}
>>>>> +
>>>>>    	ret = device_add(&mdev->dev);
>>>>>    	if (ret)
>>>>>    		goto add_fail;
>>>>> diff --git a/drivers/vfio/mdev/mdev_driver.c b/drivers/vfio/mdev/mdev_driver.c
>>>>> index 0d3223aee20b..319d886ffaf7 100644
>>>>> --- a/drivers/vfio/mdev/mdev_driver.c
>>>>> +++ b/drivers/vfio/mdev/mdev_driver.c
>>>>> @@ -69,8 +69,30 @@ static int mdev_remove(struct device *dev)
>>>>>    	return 0;
>>>>>    }
>>>>>    
>>>>> +static int mdev_match(struct device *dev, struct device_driver *drv)
>>>>> +{
>>>>> +	unsigned int i;
>>>>> +	struct mdev_device *mdev = to_mdev_device(dev);
>>>>> +	struct mdev_driver *mdrv = to_mdev_driver(drv);
>>>>> +	const struct mdev_class_id *ids = mdrv->id_table;
>>>>> +
>>>> Nit, as we start to allow new mdev bus drivers, mdev-core might want to
>>>> protect itself from a NULL id_table, by either failing the
>>>> mdev_register_driver() or failing the match here.  I think such a
>>>> condition would segfault as written here, but clearly we don't have
>>>> such external drivers yet.  Thanks,
>>>
>>> I'm not sure I get the point here. My understanding is that mdev-core
>>> won't try to be matched here since it was not a complete mdev device.
>> The parent driver failing to set a type vs the parent driver failing to
> Correction, the second half of this should be in reference to the mdev
> bus driver.
>
>> register with a struct mdev_driver where id_table is not null are
>> different issues.  I agree that if a vendor driver was not updated for
>> this series that they'd never successfully create a device because the
>> mdev-core would reject it for not setting a class, but mdev_match() is
>> called for devices that might be created by other vendor drivers, so
>> loading a parent driver with a null id_table potentially breaks
>> matching for everyone.  Thanks,
> The point is still valid though, for example if vfio-mdev registered
> with a null id_table it would break matching for virtio-mdev depending
> on the order we iterate through drivers as we call mdev_match().
> Thanks,
>
> Alex


I see the point, so I can check the existence of id_table before trying 
to do the match here.

Thanks

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2019-10-25  1:42 UTC|newest]

Thread overview: 117+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23 13:07 [PATCH V5 0/6] mdev based hardware virtio offloading support Jason Wang
2019-10-23 13:07 ` [Intel-gfx] " Jason Wang
2019-10-23 13:07 ` Jason Wang
2019-10-23 13:07 ` Jason Wang
2019-10-23 13:07 ` [PATCH V5 1/6] mdev: class id support Jason Wang
2019-10-23 13:07   ` [Intel-gfx] " Jason Wang
2019-10-23 13:07   ` Jason Wang
2019-10-23 13:07   ` Jason Wang
2019-10-23 16:30   ` Parav Pandit
2019-10-23 16:30     ` [Intel-gfx] " Parav Pandit
2019-10-23 16:30     ` Parav Pandit
2019-10-23 16:30     ` Parav Pandit
2019-10-23 16:30     ` Parav Pandit
2019-10-23 21:42   ` Alex Williamson
2019-10-23 21:42     ` [Intel-gfx] " Alex Williamson
2019-10-23 21:42     ` Alex Williamson
2019-10-23 21:42     ` Alex Williamson
2019-10-24  3:27     ` Jason Wang
2019-10-24  3:27       ` [Intel-gfx] " Jason Wang
2019-10-24  3:27       ` Jason Wang
2019-10-24  3:27       ` Jason Wang
2019-10-24 19:46       ` Alex Williamson
2019-10-24 19:46       ` Alex Williamson
2019-10-24 19:46         ` [Intel-gfx] " Alex Williamson
2019-10-24 19:46         ` Alex Williamson
2019-10-24 19:46         ` Alex Williamson
2019-10-24 20:13         ` Alex Williamson
2019-10-24 20:13           ` [Intel-gfx] " Alex Williamson
2019-10-24 20:13           ` Alex Williamson
2019-10-24 20:13           ` Alex Williamson
2019-10-25  1:42           ` Jason Wang [this message]
2019-10-25  1:42           ` Jason Wang
2019-10-25  1:42             ` [Intel-gfx] " Jason Wang
2019-10-25  1:42             ` Jason Wang
2019-10-25  1:42             ` Jason Wang
2019-10-24  3:27     ` Jason Wang
2019-10-23 21:42   ` Alex Williamson
2019-10-23 13:07 ` [PATCH V5 2/6] modpost: add support for mdev class id Jason Wang
2019-10-23 13:07 ` Jason Wang
2019-10-23 13:07   ` [Intel-gfx] " Jason Wang
2019-10-23 13:07   ` Jason Wang
2019-10-23 21:42   ` Alex Williamson
2019-10-23 21:42     ` [Intel-gfx] " Alex Williamson
2019-10-23 21:42     ` Alex Williamson
2019-10-23 21:42     ` Alex Williamson
2019-10-24  3:31     ` Jason Wang
2019-10-24  3:31     ` Jason Wang
2019-10-24  3:31       ` [Intel-gfx] " Jason Wang
2019-10-24  3:31       ` Jason Wang
2019-10-24  3:31       ` Jason Wang
2019-10-24 19:54       ` Alex Williamson
2019-10-24 19:54       ` Alex Williamson
2019-10-24 19:54         ` [Intel-gfx] " Alex Williamson
2019-10-24 19:54         ` Alex Williamson
2019-10-24 19:54         ` Alex Williamson
2019-10-25  1:44         ` Jason Wang
2019-10-25  1:44           ` [Intel-gfx] " Jason Wang
2019-10-25  1:44           ` Jason Wang
2019-10-25  1:44           ` Jason Wang
2019-10-25  1:44         ` Jason Wang
2019-10-23 21:42   ` Alex Williamson
2019-10-23 13:07 ` [PATCH V5 3/6] mdev: introduce device specific ops Jason Wang
2019-10-23 13:07   ` [Intel-gfx] " Jason Wang
2019-10-23 13:07   ` Jason Wang
2019-10-23 13:07   ` Jason Wang
2019-10-23 13:07 ` Jason Wang
2019-10-23 13:07 ` [PATCH V5 4/6] mdev: introduce virtio device and its device ops Jason Wang
2019-10-23 13:07   ` [Intel-gfx] " Jason Wang
2019-10-23 13:07   ` Jason Wang
2019-10-23 13:07   ` Jason Wang
2019-10-23 21:57   ` Alex Williamson
2019-10-23 21:57     ` [Intel-gfx] " Alex Williamson
2019-10-23 21:57     ` Alex Williamson
2019-10-23 21:57     ` Alex Williamson
2019-10-24  3:51     ` Jason Wang
2019-10-24  3:51       ` [Intel-gfx] " Jason Wang
2019-10-24  3:51       ` Jason Wang
2019-10-24  3:51       ` Jason Wang
2019-10-24 20:44       ` Alex Williamson
2019-10-24 20:44       ` Alex Williamson
2019-10-24 20:44         ` [Intel-gfx] " Alex Williamson
2019-10-24 20:44         ` Alex Williamson
2019-10-24 20:44         ` Alex Williamson
2019-10-25  1:54         ` Jason Wang
2019-10-25  1:54         ` Jason Wang
2019-10-25  1:54           ` [Intel-gfx] " Jason Wang
2019-10-25  1:54           ` Jason Wang
2019-10-25  1:54           ` Jason Wang
2019-10-24  3:51     ` Jason Wang
2019-10-29  7:42   ` Zhu Lingshan
2019-10-29  7:42     ` [Intel-gfx] " Zhu Lingshan
2019-10-29  7:42     ` Zhu Lingshan
2019-10-29  7:42     ` Zhu Lingshan
2019-10-29 10:42     ` Jason Wang
2019-10-29 10:42     ` Jason Wang
2019-10-29 10:42       ` [Intel-gfx] " Jason Wang
2019-10-29 10:42       ` Jason Wang
2019-10-30  7:36       ` Zhu Lingshan
2019-10-30  7:36         ` [Intel-gfx] " Zhu Lingshan
2019-10-30  7:36         ` Zhu Lingshan
2019-10-23 13:07 ` Jason Wang
2019-10-23 13:07 ` [PATCH V5 5/6] virtio: introduce a mdev based transport Jason Wang
2019-10-23 13:07 ` Jason Wang
2019-10-23 13:07   ` [Intel-gfx] " Jason Wang
2019-10-23 13:07   ` Jason Wang
2019-10-23 13:07   ` Jason Wang
2019-10-23 13:07 ` [PATCH V5 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework Jason Wang
2019-10-23 13:07   ` [Intel-gfx] " Jason Wang
2019-10-23 13:07   ` Jason Wang
2019-10-23 13:07   ` Jason Wang
2019-10-23 13:07 ` Jason Wang
2019-10-23 23:42 ` ✗ Fi.CI.CHECKPATCH: warning for mdev based hardware virtio offloading support (rev6) Patchwork
2019-10-23 23:42   ` [Intel-gfx] " Patchwork
2019-10-24  0:10 ` ✓ Fi.CI.BAT: success " Patchwork
2019-10-24  0:10   ` [Intel-gfx] " Patchwork
2019-10-24 20:36 ` ✗ Fi.CI.IGT: failure " Patchwork
2019-10-24 20:36   ` [Intel-gfx] " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='c8ab994e-8daa-926c-c91d-785e9d3c5044__19742.3959428974$1571967803$gmane$org@redhat.com' \
    --to=jasowang@redhat.com \
    --cc=airlied@linux.ie \
    --cc=akrowiak@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=christophe.de.dinechin@gmail.com \
    --cc=cohuck@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eperezma@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=haotian.wang@sifive.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=idos@mellanox.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.ke \
    --cc=linux-s390@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=oberpar@linux.ibm.com \
    --cc=parav@mellanox.com \
    --cc=pasic@linux.ibm.com \
    --cc=rob.miller@broadcom.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=sebott@linux.ibm.com \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xiao.w.wang@intel.com \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhi.a.wang@intel.com \
    --cc=zhihong.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.