Re: [virtio-comment] Google Comments on Virtio Draft Spec

[Rusty Russell <rusty@au1.ibm.com>]

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.