virtio — archive

[Stefan Hajnoczi]

On Sun, Mar 05, 2023 at 04:38:59AM -0500, Michael S. Tsirkin wrote: > On Fri, Mar 03, 2023 at 03:21:33PM -0500, Stefan Hajnoczi wrote: > > What happens if a command takes 1 second to complete, is the device > > allowed to process the next command from the virtqueue during this time, > > possibly completing it before the first command? > > > > This requires additional clarification in the spec because "they are > > processed by the device in the order in which they are queued" does not > > explain whether commands block the virtqueue (in order completion) or > > not (out of order completion). > > Oh I begin to see. Hmm how does e.g. virtio scsi handle this? virtio-scsi, virtio-blk, and NVMe requests may complete out of order. Several may be processed by the device at the same time. They rely on multi-queue for abort operations: In virtio-scsi the abort requests (VIRTIO_SCSI_T_TMF_ABORT_TASK) are sent on the control virtqueue. The the request identifier namespace is shared across all virtqueues so it's possible to abort a request that was submitted to any command virtqueue. NVMe also follows the same design where abort commands are sent on the Admin Submission Queue instead of an I/O Submission Queue. It's possible to identify NVMe requests by <Submission Queue ID, Command Identifier>. virtio-blk doesn't support aborting requests. I think the logic behind this design is that if a queue gets stuck processing long-running requests, then the device should not be forced to perform lookahead in the queue to find abort commands. A separate control/admin queue is used for the abort requests. Stefan