On 13/12/2017 09:51, Maxime Coquelin wrote:
> This series fixes this by destroying all but first queue pair in
> the backend if VIRTIO_NET_F_MQ isn't negotiated. First patches
> makes sure that VHOST_USER_SET_FEATURES request doesn't change
> Virtio features while the device is running, which should never
> happen as per the Virtio spec. This helps to make sure vitqueues
> aren't destroyed while being processed, but also protect from
> other illegal features changes (e.g. VIRTIO_NET_F_MRG_RXBUF).
Hi Maxime,
I think this series is wrong from the virtio spec's point of view. If
the driver requests VIRTIO_NET_F_MQ, that does not mean "the driver
knows about multiqueue", it only means that "the driver wants to read
max_virtqueue_pairs" from configuration space.
Just like it's perfectly fine for a device to propose VIRTIO_NET_F_MQ
and set max_virtqueue_pairs=1, a driver can negotiate VIRTIO_NET_F_MQ
and then skip initialization of some virtqueues.
In fact, for virtio-net there is an explicit way to say how many
virtqueue pairs are available; the virtio spec's section 5.1.5 (Network
device, Device Initialization) mentions that
Even with VIRTIO_NET_F_MQ, only receiveq1, transmitq1 and
controlq are used by default. The driver would send the
VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command specifying the number of
the transmit and receive queues to use.
Thanks,
Paolo
