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.
VIRTIO-101, VIRTIO-102, VIRTIO-103 and VIRTIO-104 all look good.
VIRTIO-105 - we retract the request.
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?
>> 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 <> 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.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
(Brian W. Kernighan)
