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