Closed lauralt closed 2 years ago
The current implementation of the MMIO transport provides a way for the device to limit the number of queues the driver can access. If the driver tries to select a queue that has not been initialized by the device it will receive the value 0 in the QueueNumMax register and should consider the queue to be invalid. This way the driver is limited by the number of queues created by the device. A limitation could be added to the number of queues that can be created, but that should be device specific since adding a maximum of 1024 in the virtio-device would not allow for devices such as the network device to create up to 0x8000 queues as it is defined in the specification. The issue could be better handled in each device implementation instead of the generic virtio-device. Synced with @lauralt as well, and decided to close the issue.
We should consider limiting the maximum number of queues. Right now the MMIO transport implementation allows up to u16::MAX queues which is a bit too much. We could instead define a maximum number and when the driver wants to select the queue index, validate this index against the max one. qemu seems to be using 1024, which seems reasonable. This is not a blocker for publishing the virtio-queue as it is more related to the
virtio-device
scope.