Displaying 13 results from an estimated 13 matches for "mdev_set_class_id".
2019 Sep 24
1
[PATCH V2 2/8] mdev: class id support
...const struct mdev_parent_ops *ops);
>
> +
> However, the mdev_parent_ops structure is not required in the function call
> that a driver should use to unregister itself with the mdev core driver::
Unintended extra line? Doesn't seem to match surrounding formatting.
Calling mdev_set_class_id() as part of create seems relatively
fundamental to the vendor driver with this change, it should be added
to the documentation.
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 23aa3e50cbf8..f793252a3d2a 100644
> --- a/drivers/gpu/drm/i915/gvt/kv...
2019 Sep 25
1
[PATCH V2 2/8] mdev: class id support
...x 23aa3e50cbf8..f793252a3d2a 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_id(mdev, MDEV_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..d258ef1fedb9 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -129,6 +129,...
2019 Sep 24
0
[PATCH V2 2/8] mdev: class id support
...b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 23aa3e50cbf8..f793252a3d2a 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_id(mdev, MDEV_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..d258ef1fedb9 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 k...
2019 Sep 24
3
[PATCH V2 5/8] mdev: introduce device specific ops
...e_ops intel_vfio_vgpu_dev_ops;
> +
> static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
> {
> struct intel_vgpu *vgpu = NULL;
> @@ -679,6 +682,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
> ret = 0;
>
> mdev_set_class_id(mdev, MDEV_ID_VFIO);
> + mdev_set_dev_ops(mdev, &intel_vfio_vgpu_dev_ops);
This seems rather unrefined. We're registering interdependent data in
separate calls. All drivers need to make both of these calls. I'm not
sure if this is a good idea, but what if we had:
static const st...
2019 Sep 24
3
[PATCH V2 5/8] mdev: introduce device specific ops
...e_ops intel_vfio_vgpu_dev_ops;
> +
> static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
> {
> struct intel_vgpu *vgpu = NULL;
> @@ -679,6 +682,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
> ret = 0;
>
> mdev_set_class_id(mdev, MDEV_ID_VFIO);
> + mdev_set_dev_ops(mdev, &intel_vfio_vgpu_dev_ops);
This seems rather unrefined. We're registering interdependent data in
separate calls. All drivers need to make both of these calls. I'm not
sure if this is a good idea, but what if we had:
static const st...
2019 Sep 24
0
[PATCH V2 5/8] mdev: introduce device specific ops
...ce);
}
+static struct vfio_mdev_device_ops intel_vfio_vgpu_dev_ops;
+
static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
{
struct intel_vgpu *vgpu = NULL;
@@ -679,6 +682,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
ret = 0;
mdev_set_class_id(mdev, MDEV_ID_VFIO);
+ mdev_set_dev_ops(mdev, &intel_vfio_vgpu_dev_ops);
out:
return ret;
}
@@ -1601,20 +1605,21 @@ static const struct attribute_group *intel_vgpu_groups[] = {
NULL,
};
-static struct mdev_parent_ops intel_vgpu_ops = {
- .mdev_attr_groups = intel_vgpu_groups,
- ....
2019 Sep 25
0
[PATCH V2 5/8] mdev: introduce device specific ops
...> static int intel_vgpu_create(struct kobject *kobj, struct mdev_device
> *mdev)
> > {
> > struct intel_vgpu *vgpu = NULL;
> > @@ -679,6 +682,7 @@ static int intel_vgpu_create(struct kobject *kobj,
> struct mdev_device *mdev)
> > ret = 0;
> >
> > mdev_set_class_id(mdev, MDEV_ID_VFIO);
> > + mdev_set_dev_ops(mdev, &intel_vfio_vgpu_dev_ops);
>
> This seems rather unrefined. We're registering interdependent data in
> separate calls. All drivers need to make both of these calls. I'm not
> sure if this is a good idea, but what if...
2019 Sep 24
17
[PATCH V2 0/8] mdev based hardware virtio offloading support
Hi all:
There are hardware that can do virtio datapath offloading while having
its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and register itself as a new kind of mdev driver. Then
it provides a unified way for kernel virtio driver to
2019 Sep 24
17
[PATCH V2 0/8] mdev based hardware virtio offloading support
Hi all:
There are hardware that can do virtio datapath offloading while having
its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and register itself as a new kind of mdev driver. Then
it provides a unified way for kernel virtio driver to
2019 Sep 25
3
[PATCH V2 5/8] mdev: introduce device specific ops
...ect *kobj, struct mdev_device
> > *mdev)
> > > {
> > > struct intel_vgpu *vgpu = NULL;
> > > @@ -679,6 +682,7 @@ static int intel_vgpu_create(struct kobject *kobj,
> > struct mdev_device *mdev)
> > > ret = 0;
> > >
> > > mdev_set_class_id(mdev, MDEV_ID_VFIO);
> > > + mdev_set_dev_ops(mdev, &intel_vfio_vgpu_dev_ops);
> >
> > This seems rather unrefined. We're registering interdependent data in
> > separate calls. All drivers need to make both of these calls. I'm not
> > sure if this i...
2019 Sep 25
3
[PATCH V2 5/8] mdev: introduce device specific ops
...ect *kobj, struct mdev_device
> > *mdev)
> > > {
> > > struct intel_vgpu *vgpu = NULL;
> > > @@ -679,6 +682,7 @@ static int intel_vgpu_create(struct kobject *kobj,
> > struct mdev_device *mdev)
> > > ret = 0;
> > >
> > > mdev_set_class_id(mdev, MDEV_ID_VFIO);
> > > + mdev_set_dev_ops(mdev, &intel_vfio_vgpu_dev_ops);
> >
> > This seems rather unrefined. We're registering interdependent data in
> > separate calls. All drivers need to make both of these calls. I'm not
> > sure if this i...
2019 Oct 21
0
[RFC 2/2] vhost: IFC VF vdpa layer
...v);
>>> +??? int ret = 0;
>>> +
>>> +??? mutex_lock(&adapter->mdev_lock);
>>> +
>>> +??? if (adapter->mdev_count < 1) {
>>> +??????? ret = -EINVAL;
>>> +??????? goto out;
>>> +??? }
>>> +
>>> +??? mdev_set_class_id(mdev, MDEV_ID_VHOST);
>>> +??? mdev_set_dev_ops(mdev, &ifc_mdev_ops);
>>> +
>>> +??? mdev_set_drvdata(mdev, adapter);
>>> +??? mdev_set_iommu_device(mdev_dev(mdev), dev);
>>> +
>>> +??? INIT_LIST_HEAD(&adapter->dma_maps);
>>>...
2019 Oct 16
0
[RFC 2/2] vhost: IFC VF vdpa layer
...;
> + struct pci_dev *pdev = to_pci_dev(dev);
> + struct ifcvf_adapter *adapter = pci_get_drvdata(pdev);
> + int ret = 0;
> +
> + mutex_lock(&adapter->mdev_lock);
> +
> + if (adapter->mdev_count < 1) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + mdev_set_class_id(mdev, MDEV_ID_VHOST);
> + mdev_set_dev_ops(mdev, &ifc_mdev_ops);
> +
> + mdev_set_drvdata(mdev, adapter);
> + mdev_set_iommu_device(mdev_dev(mdev), dev);
> +
> + INIT_LIST_HEAD(&adapter->dma_maps);
> + adapter->mdev_count--;
> +
> +out:
> + mutex_unlock(&...