Displaying 10 results from an estimated 10 matches for "mdev_set_dev_op".
Did you mean:
mdev_set_dev_ops
2019 Sep 24
3
[PATCH V2 5/8] mdev: introduce device specific ops
...atic 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 struct vfio_mdev_device_ops intel_vfio_vgpu_de...
2019 Sep 24
3
[PATCH V2 5/8] mdev: introduce device specific ops
...atic 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 struct vfio_mdev_device_ops intel_vfio_vgpu_de...
2019 Sep 24
0
[PATCH V2 5/8] mdev: introduce device specific ops
..._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,
- .create = intel_vgpu_create,
- .remove...
2019 Sep 25
0
[PATCH V2 5/8] mdev: introduce device specific ops
...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 struct vfio_mdev...
2019 Sep 25
3
[PATCH V2 5/8] mdev: introduce device specific ops
...gt; {
> > > 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:
> >
> > s...
2019 Sep 25
3
[PATCH V2 5/8] mdev: introduce device specific ops
...gt; {
> > > 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:
> >
> > s...
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 Oct 21
0
[RFC 2/2] vhost: IFC VF vdpa layer
...> +??? 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--;
>>> +
>>&...
2019 Oct 16
0
[RFC 2/2] vhost: IFC VF vdpa layer
...;
> + 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(&adapter->mdev_lock);
> + return ret...