OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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 <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.




--
"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)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]