search for: mdev_set_class_id

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(&...