[virtio] [OASIS Issue Tracker] (VIRTIO-106) Virtio SCSI

[Rusty Russell]

Hi Paolo,

I tried to assign this to you, but you don't have a JIRA id in
OASIS it seems.

Thanks,
Rusty.

------------------------------------
Summary: Virtio SCSI
Key: VIRTIO-106
URL: https://tools.oasis-open.org/issues/browse/VIRTIO-106
Project: OASIS Virtual I/O Device (VIRTIO) TC
Issue Type: Sub-task
Affects Versions: virtio 1.0 csprd01
Reporter: Rusty Russell
Virtio SCSI
max_channel, max_target, max_lun
Are comparisons here less-than or less-than-or-equal? Both interpretations are in the fields.
Could we standardize on returning the VIRTIO_SCSI_S_TRANSPORT_FAILURE code for in flight commands when the device is unplugged.
The spec states “all task attributes may be mapped to SIMPLE by the device” - this makes S_ORDERED, S_HEAD_OF_QUEUE or S_ACA commands impossible to issue - plus some commands have implicit head of queue attribute conflicting with this statement.
VIRTIO_SCSI_S_OVERRUN - could the length referred to be clarified - the virtio buffers or the allocation_length in the CBD?
VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET - what is the expected behavior when commands are in flight? What about an incomplete TMF_ABORT?
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-***@lists.oasis-open.org
Unsubscribe: virtio-comment-***@lists.oasis-open.org
List help: virtio-comment-***@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[Paolo Bonzini]

Post by Rusty Russell
Hi Paolo,
I tried to assign this to you, but you don't have a JIRA id in
OASIS it seems.

No, I hadn't realized that you need to do it separately. I'll reply here
and send a patch next week.

Post by Rusty Russell
max_channel, max_target, max_lun
Are comparisons here less-than or less-than-or-equal? Both interpretations are in the fields.

It is always less-than-or-equal. Confusion stems from Linux SCSI code
that requires less-than-or-equal for max_channel, and less-than for max_id
aka max_target and max_lun.

Post by Rusty Russell
Could we standardize on returning the VIRTIO_SCSI_S_TRANSPORT_FAILURE code for
in flight commands when the device is unplugged.

Yeah, that can work.

Post by Rusty Russell
The spec states “all task attributes may be mapped to SIMPLE by the device”
- this makes S_ORDERED, S_HEAD_OF_QUEUE or S_ACA commands impossible to issue

Yes, that's explicitly allowed by the SCSI spec. These task attributes
are just suggestions (in the case of ACA, nobody implements it anyway).
ORDERED is the same as the old virtio-blk barrier, and you can understand
why it's a good idea to ignore it.

Post by Rusty Russell
- plus some commands have implicit head of queue attribute conflicting with this statement.

The device will still provide implicit head of queue semantics for
commands that require that, even if the task attribute is SIMPLE.
S_HEAD_OF_QUEUE is for commands that do not have implicit head
of queue semantics, and the device is free to ignore that.

Post by Rusty Russell
VIRTIO_SCSI_S_OVERRUN - could the length referred to be clarified - the virtio buffers or the allocation_length in the CBD?

It means that the allocation length or parameter length in the CDB is greater
than (respectively) the size of the dataout/datain virtio buffers.

Post by Rusty Russell
VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET - what is the expected behavior when commands are in flight?

Commands that are in flight will either be completed, or will return
VIRTIO_SCSI_S_RESET.

Post by Rusty Russell
What about an incomplete TMF_ABORT?

Since LUN reset will also abort the command, the TMF_ABORT will succeed.
It is undefined whether the commands will return VIRTIO_SCSI_S_RESET or
VIRTIO_SCSI_S_ABORTED.

Paolo

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-***@lists.oasis-open.org
Unsubscribe: virtio-comment-***@lists.oasis-open.org
List help: virtio-comment-***@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[Rusty Russell]

Post by Paolo Bonzini

Post by Rusty Russell
Hi Paolo,
I tried to assign this to you, but you don't have a JIRA id in
OASIS it seems.

No, I hadn't realized that you need to do it separately. I'll reply here
and send a patch next week.

Sure... if you have a patch (which you're happy with!) before the
meeting please post so we can vote on it.

Thanks,
Rusty.


This publicly archived list offers a means to provide input to the

OASIS Virtual I/O Device (VIRTIO) TC.



In order to verify user consent to the Feedback License terms and

to minimize spam in the list archive, subscription is required

before posting.



Subscribe: virtio-comment-***@lists.oasis-open.org

Unsubscribe: virtio-comment-***@lists.oasis-open.org

List help: virtio-comment-***@lists.oasis-open.org

List archive: https://lists.oasis-open.org/archives/virtio-comment/

Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf

List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists

Committee: https://www.oasis-open.org/committees/virtio/

Join OASIS: https://www.oasis-open.org/join/

[Paolo Bonzini]

Post by Paolo Bonzini

Could we standardize on returning the VIRTIO_SCSI_S_TRANSPORT_FAILURE code for
in flight commands when the device is unplugged.

Yeah, that can work.

Thinking more about it, TRANSPORT_FAILURE currently is for communication
between the host (that is, what sits "behind" the device) and the
target. So FAILURE is more appropriate, and the device may also choose
to abort pending commands and make them return ABORTED.

Paolo

This publicly archived list offers a means to provide input to the

OASIS Virtual I/O Device (VIRTIO) TC.



In order to verify user consent to the Feedback License terms and

to minimize spam in the list archive, subscription is required

before posting.



Subscribe: virtio-comment-***@lists.oasis-open.org

Unsubscribe: virtio-comment-***@lists.oasis-open.org

List help: virtio-comment-***@lists.oasis-open.org

List archive: https://lists.oasis-open.org/archives/virtio-comment/

Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf

List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists

Committee: https://www.oasis-open.org/committees/virtio/

Join OASIS: https://www.oasis-open.org/join/