similar to: [PATCHv5] virtio-spec: virtio network device RFS support

Add RFS support to virtio network device. Add a new feature flag VIRTIO_NET_F_RFS for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_RFS to program packet steering for unidirectional protocols. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> -- Changes from v3: - rename multiqueue ->

Add RFS support to virtio network device. Add a new feature flag VIRTIO_NET_F_RFS for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_RFS to program packet steering for unidirectional protocols. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> -- Changes from v3: - rename multiqueue ->

At Jason's request, I am trying to help finalize the spec for the new multiqueue feature. Changes from Jason's rfc: - reserved vq 3: this makes all rx vqs even and tx vqs odd, which looks nicer to me. - documented packet steering, added a generalized steering programming command. Current modes are single queue and host driven multiqueue, but I envision support for guest driven

At Jason's request, I am trying to help finalize the spec for the new multiqueue feature. Changes from Jason's rfc: - reserved vq 3: this makes all rx vqs even and tx vqs odd, which looks nicer to me. - documented packet steering, added a generalized steering programming command. Current modes are single queue and host driven multiqueue, but I envision support for guest driven

Add field for guest to specify command size for virtio-blk. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- virtio-spec.lyx | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 78 insertions(+), 5 deletions(-) diff --git a/virtio-spec.lyx b/virtio-spec.lyx index a8ce3f9..fea97ed 100644 --- a/virtio-spec.lyx +++ b/virtio-spec.lyx @@ -5826,6 +5826,16 @@

Add field for guest to specify command size for virtio-blk. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- virtio-spec.lyx | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 78 insertions(+), 5 deletions(-) diff --git a/virtio-spec.lyx b/virtio-spec.lyx index a8ce3f9..fea97ed 100644 --- a/virtio-spec.lyx +++ b/virtio-spec.lyx @@ -5826,6 +5826,16 @@

Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program packet steering for unidirectional protocols. --- Changes in v6: - rename RFS -> multiqueue to avoid confusion with RFS in linux mention

Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program packet steering for unidirectional protocols. --- Changes in v6: - rename RFS -> multiqueue to avoid confusion with RFS in linux mention

The idea of the VIRTIO_BALLOON_F_MUST_TELL_HOST feature is to let drivers skip usage of the deflate queue when leaking the balloon ("silent deflation"). Guests may benefit from silent deflate by aggressively inflating the balloon; they know that they will be able to use ballooned pages without issuing a (blocking) request to the device. The problem is that this feature is a

The idea of the VIRTIO_BALLOON_F_MUST_TELL_HOST feature is to let drivers skip usage of the deflate queue when leaking the balloon ("silent deflation"). Guests may benefit from silent deflate by aggressively inflating the balloon; they know that they will be able to use ballooned pages without issuing a (blocking) request to the device. The problem is that this feature is a

I took a stub at documenting CMD and FLUSH request types in virtio block. Christoph, could you look over this please? I note that the interface seems full of warts to me, this might be a first step to cleaning them. One issue I struggled with especially is how type field mixes bits and non-bit values. I ended up simply defining all legal values, so that we have CMD = 2, CMD_OUT = 3 and so on.

I took a stub at documenting CMD and FLUSH request types in virtio block. Christoph, could you look over this please? I note that the interface seems full of warts to me, this might be a first step to cleaning them. One issue I struggled with especially is how type field mixes bits and non-bit values. I ended up simply defining all legal values, so that we have CMD = 2, CMD_OUT = 3 and so on.

Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program packet steering for unidirectional protocols. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Changes in v8: - Fix value for CTRL_MQ

Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program packet steering for unidirectional protocols. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Changes in v8: - Fix value for CTRL_MQ

Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program packet steering for unidirectional protocols. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Changes in v7: - 8000h -> 0x8000 at

Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program packet steering for unidirectional protocols. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Changes in v7: - 8000h -> 0x8000 at

Drivers treat MUST_TELL_HOST as optional: windows drivers do not ack it and expect this means they can tell host *after* deflate. This was not the intent but the documentation was not very clear on this point. Luckily hyprevisors did not implement this feature yet so to provide guidance for future devices make spec match drivers expectations, and clarify that this feature only has effect if

Drivers treat MUST_TELL_HOST as optional: windows drivers do not ack it and expect this means they can tell host *after* deflate. This was not the intent but the documentation was not very clear on this point. Luckily hyprevisors did not implement this feature yet so to provide guidance for future devices make spec match drivers expectations, and clarify that this feature only has effect if

VIRTIO_BALLOON_F_MUST_TELL_HOST cannot be used properly because it is a "negative" feature: it tells you that silent defalte is not supported. Right now, QEMU refuses migration if the target does not support all the features that were negotiated. But then: - a migration from non-MUST_TELL_HOST to MUST_TELL_HOST will succeed, which is wrong; - a migration from MUST_TELL_HOST to

VIRTIO_BALLOON_F_MUST_TELL_HOST cannot be used properly because it is a "negative" feature: it tells you that silent defalte is not supported. Right now, QEMU refuses migration if the target does not support all the features that were negotiated. But then: - a migration from non-MUST_TELL_HOST to MUST_TELL_HOST will succeed, which is wrong; - a migration from MUST_TELL_HOST to