search for: set_mdev_featur

...d (*get_config)(struct mdev_device *mdev, unsigned int offset, > + void *buf, unsigned int len); > + void (*set_config)(struct mdev_device *mdev, unsigned int offset, > + const void *buf, unsigned int len); > + u64 (*get_mdev_features)(struct mdev_device *mdev); Do we need a .set_mdev_features method as well? It's not very clear what does mdev_features mean. Does it mean the vhost backend features? https://github.com/torvalds/linux/blob/0e2adab6cf285c41e825b6c74a3aa61324d1132c/include/uapi/linux/vhost.h#L93-L94 > + u32 (*get_generation)(struct mdev_device *mdev); > +}; &g...

...@get_mdev_features: Set a set of features that will be s/get/set/ > + * used by the driver. > + * @features: features used by the driver > + * Returns bollean: whether the features s/bollean/boolean/ How does one provide a set of features to set given this prototype? bool (*set_mdev_feature)(struct mdev_device *mdev); This is starting to look like a grab bag of callbacks, what sort of mdev features would the driver have the ability to set on a device? Note that this is not listed as optional, but the sample driver doesn't implement it :-\ Thanks, Alex > + * is accepted...

...@get_mdev_features: Set a set of features that will be s/get/set/ > + * used by the driver. > + * @features: features used by the driver > + * Returns bollean: whether the features s/bollean/boolean/ How does one provide a set of features to set given this prototype? bool (*set_mdev_feature)(struct mdev_device *mdev); This is starting to look like a grab bag of callbacks, what sort of mdev features would the driver have the ability to set on a device? Note that this is not listed as optional, but the sample driver doesn't implement it :-\ Thanks, Alex > + * is accepted...

...gt;> + * used by the driver. > >> + * @features: features used by the driver > >> + * Returns bollean: whether the features > > s/bollean/boolean/ > > > > How does one provide a set of features to set given this prototype? > > > > bool (*set_mdev_feature)(struct mdev_device *mdev); > > > > This is starting to look like a grab bag of callbacks, what sort of > > mdev features would the driver have the ability to set on a device? > > > Yes, e.g device support A,B,C, but driver will only use B and C. Can you give a _con...

...> s/get/set/ Will fix. > >> + * used by the driver. >> + * @features: features used by the driver >> + * Returns bollean: whether the features > s/bollean/boolean/ > > How does one provide a set of features to set given this prototype? > > bool (*set_mdev_feature)(struct mdev_device *mdev); > > This is starting to look like a grab bag of callbacks, what sort of > mdev features would the driver have the ability to set on a device? Yes, e.g device support A,B,C, but driver will only use B and C. > > Note that this is not listed as optional...

...length to write to + * configration space + * @get_generation: Get device config generaton (optional) + * @mdev: mediated device + * Returns u32: device generation + */ +struct mdev_virtio_device_ops { + /* Mdev device ops */ + u64 (*get_mdev_features)(struct mdev_device *mdev); + bool (*set_mdev_feature)(struct mdev_device *mdev); + /* Virtqueue ops */ + int (*set_vq_address)(struct mdev_device *mdev, + u16 idx, u64 desc_area, u64 driver_area, + u64 device_area); + void (*set_vq_num)(struct mdev_device *mdev, u16 idx, u32 num); + void (*kick_vq)(struct mdev_device *mdev, u16 idx);...

Hi all: There are hardwares 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

Hi all: There are hardwares 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

Hi all: There are hardwares 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