search for: device_op

...e = intel_vgpu_write, > .mmap = intel_vgpu_mmap, > .ioctl = intel_vgpu_ioctl, > }; > > +static struct mdev_parent_ops intel_vgpu_ops = { > + .mdev_attr_groups = intel_vgpu_groups, > + .create = intel_vgpu_create, > + .remove = intel_vgpu_remove, > + .device_ops = &intel_vfio_vgpu_ops, > +}; > + > static int kvmgt_host_init(struct device *dev, void *gvt, const void *ops) > { > struct attribute **kvm_type_attrs; > diff --git a/drivers/s390/cio/vfio_ccw_ops.c > b/drivers/s390/cio/vfio_ccw_ops.c > index f87d9409e290..9...

...e = intel_vgpu_write, > .mmap = intel_vgpu_mmap, > .ioctl = intel_vgpu_ioctl, > }; > > +static struct mdev_parent_ops intel_vgpu_ops = { > + .mdev_attr_groups = intel_vgpu_groups, > + .create = intel_vgpu_create, > + .remove = intel_vgpu_remove, > + .device_ops = &intel_vfio_vgpu_ops, > +}; > + > static int kvmgt_host_init(struct device *dev, void *gvt, const void *ops) > { > struct attribute **kvm_type_attrs; > diff --git a/drivers/s390/cio/vfio_ccw_ops.c > b/drivers/s390/cio/vfio_ccw_ops.c > index f87d9409e290..9...

...parent device, per mdev type, or any other categorization. Vendor drivers are expected to be fully asynchronous in this respect or provide their own internal resource protection.) -The callbacks in the mdev_parent_ops structure are as follows: +The device specific callbacks are referred through device_ops pointer +in mdev_parent_ops. For vfio-mdev device, its callbacks in device_ops +are as follows: * open: open callback of mediated device * close: close callback of mediated device diff --git a/MAINTAINERS b/MAINTAINERS index b2326dece28e..89832b316500 100644 --- a/MAINTAINERS +++ b/MAINTAINERS...

...ease, - .read = intel_vgpu_read, .write = intel_vgpu_write, .mmap = intel_vgpu_mmap, .ioctl = intel_vgpu_ioctl, }; +static struct mdev_parent_ops intel_vgpu_ops = { + .mdev_attr_groups = intel_vgpu_groups, + .create = intel_vgpu_create, + .remove = intel_vgpu_remove, + .device_ops = &intel_vfio_vgpu_ops, +}; + static int kvmgt_host_init(struct device *dev, void *gvt, const void *ops) { struct attribute **kvm_type_attrs; diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c index f87d9409e290..96e9f18100ae 100644 --- a/drivers/s390/ci...

...categorization. >> Vendor drivers are expected to be fully asynchronous in this respect or >> provide their own internal resource protection.) >> >> -The callbacks in the mdev_parent_ops structure are as follows: >> +The device specific callbacks are referred through device_ops pointer >> +in mdev_parent_ops. For vfio-mdev device, its callbacks in device_ops >> +are as follows: >> >> * open: open callback of mediated device >> * close: close callback of mediated device diff --git a/MAINTAINERS >> b/MAINTAINERS index b2326dece28e..898...

...map = intel_vgpu_mmap, >> .ioctl = intel_vgpu_ioctl, >> }; >> >> +static struct mdev_parent_ops intel_vgpu_ops = { >> + .mdev_attr_groups = intel_vgpu_groups, >> + .create = intel_vgpu_create, >> + .remove = intel_vgpu_remove, >> + .device_ops = &intel_vfio_vgpu_ops, >> +}; >> + >> static int kvmgt_host_init(struct device *dev, void *gvt, const void *ops) >> { >> struct attribute **kvm_type_attrs; >> diff --git a/drivers/s390/cio/vfio_ccw_ops.c >> b/drivers/s390/cio/vfio_ccw_o...

....ioctl = intel_vgpu_ioctl, > >> }; > >> > >> +static struct mdev_parent_ops intel_vgpu_ops = { > >> + .mdev_attr_groups = intel_vgpu_groups, > >> + .create = intel_vgpu_create, > >> + .remove = intel_vgpu_remove, > >> + .device_ops = &intel_vfio_vgpu_ops, > >> +}; > >> + > >> static int kvmgt_host_init(struct device *dev, void *gvt, const void *ops) > >> { > >> struct attribute **kvm_type_attrs; > >> diff --git a/drivers/s390/cio/vfio_ccw_ops.c > &gt...

Hi all: During the development of virtio-mdev[1]. I find that mdev needs to be extended to support devices other than vfio mdev device. So this series tries to extend the mdev to be able to differ from different devices by: - device id and matching for mdev bus - device speicfic callbacks and move vfio callbacks there Sent for early reivew, compile test only! Thanks [1]

Hi all: During the development of virtio-mdev[1]. I find that mdev needs to be extended to support devices other than vfio mdev device. So this series tries to extend the mdev to be able to differ from different devices by: - device id and matching for mdev bus - device speicfic callbacks and move vfio callbacks there Sent for early reivew, compile test only! Thanks [1]

...o, virtio, and vendor class) >>> Yet another suggestion: have the class id derive from the function >>> you use to set up the ops. >>> >>> void mdev_set_vfio_ops(struct mdev_device *mdev, const struct >>> vfio_mdev_ops *vfio_ops) { >>> mdev->device_ops = vfio_ops; >>> mdev->class_id = MDEV_ID_VFIO; >>> } >>> >>> void mdev_set_virtio_ops(struct mdev_device *mdev, const struct >>> virtio_mdev_ops *virtio_ops) { >>> mdev->device_ops = virtio_ops; >>> mdev->class_id = MDEV_ID...

...o, virtio, and vendor class) >>> Yet another suggestion: have the class id derive from the function >>> you use to set up the ops. >>> >>> void mdev_set_vfio_ops(struct mdev_device *mdev, const struct >>> vfio_mdev_ops *vfio_ops) { >>> mdev->device_ops = vfio_ops; >>> mdev->class_id = MDEV_ID_VFIO; >>> } >>> >>> void mdev_set_virtio_ops(struct mdev_device *mdev, const struct >>> virtio_mdev_ops *virtio_ops) { >>> mdev->device_ops = virtio_ops; >>> mdev->class_id = MDEV_ID...

...v_model = > + cdev->private->dma_area->senseid.dev_model; These fit into one line. > +/** > + * Allocate zeroed dma coherent 31 bit addressable memory using > + * the subchannels dma pool. Maximal size of allocation supported > + * is PAGE_SIZE. > + */ drivers/s390/cio/device_ops.c:708: warning: Function parameter or member 'cdev' not described in 'ccw_device_dma_zalloc' drivers/s390/cio/device_ops.c:708: warning: Function parameter or member 'size' not described in 'ccw_device_dma_zalloc' Reviewed-by: Sebastian Ott <sebott at linux.ibm...

...t; > Pktgen test was done with virito-net + mvnet loop back device. > > Please review. > > [1] https://lkml.org/lkml/2019/9/16/869 > > Changes from V1: > > - move virtio_mdev.c to drivers/virtio > - store class_id in mdev_device instead of mdev_parent > - store device_ops in mdev_device instead of mdev_parent > - reorder the patch, vringh fix comes first > - really silent compiling warnings > - really switch to use u16 for class_id > - uevent and modpost support for mdev class_id > - vraious tweaks per comments from Parav > > Changes from RFC-...

...ith id_talbe claimed by the driver. On top, this seris also decouple device specific parents ops out of the common ones. Pktgen test was done with virito-net + mvnet loop back device. Please review. Changes from V1: - rename device id to class id - add docs for class id and device specific ops (device_ops) - split device_ops into seperate headers - drop the mdev_set_dma_ops() - use device_ops to implement the transport API, then it's not a part of UAPI any more - use GFP_ATOMIC in mvnet sample device and other tweaks - set_vring_base/get_vring_base support for mvnet device Jason Wang (6):...

...ype, or any other categorization. > Vendor drivers are expected to be fully asynchronous in this respect or > provide their own internal resource protection.) > > -The callbacks in the mdev_parent_ops structure are as follows: > +The device specific callbacks are referred through device_ops pointer > +in mdev_parent_ops. For vfio-mdev device, its callbacks in device_ops > +are as follows: This is not accurate. device_ops is now on the mdev_device and is an mdev bus driver specific structure of callbacks that must be registered for each mdev device by the parent driver during...

...ype, or any other categorization. > Vendor drivers are expected to be fully asynchronous in this respect or > provide their own internal resource protection.) > > -The callbacks in the mdev_parent_ops structure are as follows: > +The device specific callbacks are referred through device_ops pointer > +in mdev_parent_ops. For vfio-mdev device, its callbacks in device_ops > +are as follows: This is not accurate. device_ops is now on the mdev_device and is an mdev bus driver specific structure of callbacks that must be registered for each mdev device by the parent driver during...

...no strict requirement for this. We > > > will export a version value for userspace for compatibility. > > Given it's tied to virtio we probably want kernel+userspace > > feature bits? > > > Yes, then I think we could probably have a version field inside e.g > device_ops structure. Then it could be fetched from both kernel and > userspace driver. > > Thanks > my point was feature bits not a version number. > >

...gt; >>> Yet another suggestion: have the class id derive from the function > >>> you use to set up the ops. > >>> > >>> void mdev_set_vfio_ops(struct mdev_device *mdev, const struct > >>> vfio_mdev_ops *vfio_ops) { > >>> mdev->device_ops = vfio_ops; > >>> mdev->class_id = MDEV_ID_VFIO; > >>> } > >>> > >>> void mdev_set_virtio_ops(struct mdev_device *mdev, const struct > >>> virtio_mdev_ops *virtio_ops) { > >>> mdev->device_ops = virtio_ops; > >&g...

...no strict requirement for this. We > > > will export a version value for userspace for compatibility. > > Given it's tied to virtio we probably want kernel+userspace > > feature bits? > > > Yes, then I think we could probably have a version field inside e.g > device_ops structure. Then it could be fetched from both kernel and > userspace driver. > > Thanks > my point was feature bits not a version number. > >

...D_VHOST for future vhost-mdev work - introduce "virtio" type for mvnet and make "vhost" type for future work - add entries in MAINTAINER - tweak and typos fixes in commit log Changes from RFC-V1: - rename device id to class id - add docs for class id and device specific ops (device_ops) - split device_ops into seperate headers - drop the mdev_set_dma_ops() - use device_ops to implement the transport API, then it's not a part of UAPI any more - use GFP_ATOMIC in mvnet sample device and other tweaks - set_vring_base/get_vring_base support for mvnet device Jason Wang (6):...