virtio — archive

[Michael S. Tsirkin]

On Mon, Mar 06, 2023 at 03:17:59PM -0500, Stefan Hajnoczi wrote: > On Mon, Mar 06, 2023 at 01:37:31PM -0500, Michael S. Tsirkin wrote: > > On Mon, Mar 06, 2023 at 06:03:40AM -0500, Stefan Hajnoczi wrote: > > > On Sun, Mar 05, 2023 at 07:18:24PM -0500, Michael S. Tsirkin wrote: > > > > On Sun, Mar 05, 2023 at 07:03:02PM -0500, Stefan Hajnoczi wrote: > > > > > 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. > > > > > > > > Let's say I submit a write followed by read - is read > > > > guaranteed to return an up to date info? > > > > > > In general, no. The driver must wait for the write completion before > > > submitting the read if it wants consistency. > > > > > > Stefan > > > > I see. I think it's a good design to follow then. > > > > I'll just copy > > The driver queues requests to an arbitrary request queue, and > > they are used by the device on that same queue. It is the > > responsibility of the driver to ensure strict request ordering > > for commands placed on different queues, because they will be > > consumed with no order constraints. > > > > replacing "request" with "admin". > > That sounds like it's only about multi-queue because it says "... for > commands placed on different queues". What I mentioned about a write > followed by a read quest also applies within a single queue. > > Can you clarify the semantics in the single queue case? > > Stefan This will be addressed in the latest version. However, should not scsi and blk also adjust the wording to make it clear device does not guarantee consistency? -- MST