[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] Google Comments on Virtio Draft Spec
Andrew Thornton <andrewth@google.com> writes: > Hi Rusty, > > I send a couple of replies that seems to have gone astray. > > I have been told there have been some issues with posting to lists from an @ > google.com account so I'd be grateful if you could confirm receipt of this > mail. Sure. List is also publicly archived: https://lists.oasis-open.org/archives/virtio-comment/ > VIRTIO-106 - This is the reply I sent a couple of weeks ago that seems to > be missing: > >> 'Configuration' >>> Device configuration layout > > 1. max_sectors and cmd_per_lun are described as 'hints' > > 1.1. Can these become hard limits rather than 'hints'? (IE > devices can reject commands above the cmd_per_lun limit > or the max_sectors limit). If so, can we select a specific > error to return in that case? > > 2. cmd_per_lun describes 'the actual value to be used is the > minimum of cmd_per_lun and the virtqueue size'. > > 2.1. Does this mean that devices can reject concurrent commands > above min(cmd_per_lun, virtqueue_size)? > > 2.2. Do you really mean 'virtqueue_size'? At minimum a command > requires at least 2 entries in the virtqueue. Should this > minimum be virtqueue_size / 2? Indirect descriptors allow this. The virtqueue_size limit is more a "note: you can't have more than virtqueue_size descriptors outstanding anyway", rather than something which needs to be spelled out IMHO. Leaving the rest to the experts (Paolo cc'd). Thanks, Rusty. >>> Device operation: requestq > > 1. When a transport returns VIRTIO_SCSI_S_BUSY, can we specify that a > guest should retry the request? This would simplify device > implementations > in the face of resource limitations and would allow guests to control > I/O queueing. > > 2. When a target is hotunplugged with I/O inflight, can we specify which > error > response will be returned for the now-terminated I/Os? > >>> Device operation: controlq > > The ordering of Task Management Function completion with > respect to requests they are acting on is unspecified. However > SCSI midlayers require TMF commands complete _after_ the command(s) > they are aborting/reseting. > > EX: > requestq controlq > 1: REQUEST A > 2: TMF ABORT A > 3: COMPLETE A > (S_ABORTED) > 4: COMPLETION TMF ABORT A > [good ordering] > > requestq controlq > 1: REQUEST A > 2: TMF ABORT A > 3: COMPLETION TMF ABORT A > 4: COMPLETION A > [bad ordering! surprise completion may corrupt guest memory] > > This requires a device ensure ordering between the controlq and > requestq processing; for TMF RESET, this means a reset must > drain all the request queues (searching for undispatched > commands; QEMU does not do this currently and can corrupt guest > memory in the worst case). > > 1. If we could have a feature flag (VIRTIO_SCSI_F_TMF_ON_REQUESTQ) > that allowed TMF commands to be sent down the requestqueue,ordering > would be naturally enforced and devices would save a lot of complexity. > > 2. If that is not possible, a guest driver can cycle a > no-op command through request queue(s) before aborting/resetting > a command. To do this, we need to codify a safe no-op command. > > We could use a command w/ lun[0] = 0x0 as a safe no-op command. > This is currently the case for QEMU, vhost-scsi, and GCE. We would > like to have this formalized. > > Thanks, > > Andy > > On Thu, Jun 5, 2014 at 12:05 AM, Rusty Russell <rusty@au1.ibm.com> wrote: > >> OK, we've resolved/closed all these issues now. Below is a summary >> in conveniently quotable email form. Some responses were via >> the mailing list, but this lists all the actual spec changes which >> resulted: >> >> VIRTIO-101: Virtio General >> Closed (draft 2 has a shutdown section) >> >> VIRTIO-102: PCI discovery >> Resolved in r376: >> >> https://tools.oasis-open.org/version-control/browse/wsvn/virtio/?rev=376 >> >> VIRTIO-103: PCI Common configuration layout >> Resolved in r364 and r365: >> >> https://tools.oasis-open.org/version-control/browse/wsvn/virtio/?rev=364 >> >> https://tools.oasis-open.org/version-control/browse/wsvn/virtio/?rev=365 >> >> VIRTIO-104: PCI Operation >> Resolved in r375: >> >> https://tools.oasis-open.org/version-control/browse/wsvn/virtio/?rev=375 >> >> VIRTIO-105: Virtio NET >> Closed >> (See >> https://lists.oasis-open.org/archives/virtio-comment/201404/msg00013.html >> ) >> >> VIRTIO-106: Virtio SCSI >> Resolved in r372: >> >> https://tools.oasis-open.org/version-control/browse/wsvn/virtio/?rev=372 >> >> We don't seem to have closed the loop on getting responses from you, so >> we plan on releasing a third and final draft in two weeks. >> >> Cheers, >> Rusty.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]