On Fri, 4 Apr 2025 01:33:28 -0400 "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > > > > I think, a consequence of this design is that all queues need to be > > created and allocated at initialization time. > > Why? after feature negotiation. What I mean is, with this change having queues that exist but are not set up before the device becomes operational is not viable any more. Let me use the virtio-net example again. I assume by the current spec it would be OK to have max_virtqueue_pairs quite big e.g. 64, just in case the guest ends up having many vCPUs hotplugged. But start out with 2 vcpus, 2 queue pairs and initially doing VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET with 2. And then grow the guest to 8 vcpus, 'discover' virtqueues 2(I-1) receiveqI, 2(I-1)+1 transmitqI for 2 < I < 9 (I is a natural number) and do another VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET with 8. Please notice that the controlq would sit at index 128 (64*2) all along. That is in the old world. In the new world we don't do holes, so we need to allocate all the virtqueues up to controlq up-front. To avoid having holes. Or any queue-pairs that are discoverd after the initial vq discovery would need to have an index larger than controlq has. Regards, Halil
