Displaying 6 results from an estimated 6 matches for "mdev_class_id_virtiov2".
Did you mean:
mdev_class_id_virtio
2019 Oct 24
1
[PATCH V5 4/6] mdev: introduce virtio device and its device ops
...t; > structure defined by the version... isn't that a bit circular? This
> > seems redundant to me versus the class id. The fact that the parent
> > driver defines the device as MDEV_CLASS_ID_VIRTIO should tell us this
> > already. If it was incremented, we'd need an MDEV_CLASS_ID_VIRTIOv2,
> > which the virtio-mdev bus driver could add to its id table and handle
> > differently.
>
>
> My understanding is versions are only allowed to increase monotonically,
> this seems less flexible than features. E.g we have features A, B, C,
> mdev device can choos...
2019 Oct 23
2
[PATCH V5 4/6] mdev: introduce virtio device and its device ops
...is returned by a callback within the
structure defined by the version... isn't that a bit circular? This
seems redundant to me versus the class id. The fact that the parent
driver defines the device as MDEV_CLASS_ID_VIRTIO should tell us this
already. If it was incremented, we'd need an MDEV_CLASS_ID_VIRTIOv2,
which the virtio-mdev bus driver could add to its id table and handle
differently.
> + *
> + * @set_vq_address: Set the address of virtqueue
> + * @mdev: mediated device
> + * @idx: virtqueue index
> + * @desc_area: address of desc area
> + * @driver_area: address o...
2019 Oct 23
2
[PATCH V5 4/6] mdev: introduce virtio device and its device ops
...is returned by a callback within the
structure defined by the version... isn't that a bit circular? This
seems redundant to me versus the class id. The fact that the parent
driver defines the device as MDEV_CLASS_ID_VIRTIO should tell us this
already. If it was incremented, we'd need an MDEV_CLASS_ID_VIRTIOv2,
which the virtio-mdev bus driver could add to its id table and handle
differently.
> + *
> + * @set_vq_address: Set the address of virtqueue
> + * @mdev: mediated device
> + * @idx: virtqueue index
> + * @desc_area: address of desc area
> + * @driver_area: address o...
2019 Oct 24
0
[PATCH V5 4/6] mdev: introduce virtio device and its device ops
...llback within the
> structure defined by the version... isn't that a bit circular? This
> seems redundant to me versus the class id. The fact that the parent
> driver defines the device as MDEV_CLASS_ID_VIRTIO should tell us this
> already. If it was incremented, we'd need an MDEV_CLASS_ID_VIRTIOv2,
> which the virtio-mdev bus driver could add to its id table and handle
> differently.
My understanding is versions are only allowed to increase monotonically,
this seems less flexible than features. E.g we have features A, B, C,
mdev device can choose to support only a subset. E.g when...
2019 Oct 23
10
[PATCH V5 0/6] mdev based hardware virtio offloading support
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
2019 Oct 23
10
[PATCH V5 0/6] mdev based hardware virtio offloading support
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