On 06/10/2011 04:35 PM, Paolo Bonzini wrote:
If requests are placed on arbitrary queues you'll inevitably run on
locking issues to ensure strict request ordering.
I would add here:

If a device uses more than one queue it is the responsibility of the
device to ensure strict request ordering.

Applied with s/device/guest/g.

Please do not rely in bus/target/lun here. These are leftovers from
parallel SCSI and do not have any meaning on modern SCSI
implementation (eg FC or SAS). Rephrase that to

The lun field is the Logical Unit Number as defined in SAM.

Ok.

      The status byte is written by the device to be the SCSI status
      code.

?? I doubt that exists. Make that:

The status byte is written by the device to be the status code as
defined in SAM.

Ok.

      The response byte is written by the device to be one of the
      following:

      - VIRTIO_SCSI_S_OK when the request was completed and the
      status byte
        is filled with a SCSI status code (not necessarily "GOOD").

      - VIRTIO_SCSI_S_UNDERRUN if the content of the CDB requires
      transferring
        more data than is available in the data buffers.

      - VIRTIO_SCSI_S_ABORTED if the request was cancelled due to a
      reset
        or another task management function.

      - VIRTIO_SCSI_S_FAILURE for other host or guest error. In
      particular,
        if neither dataout nor datain is empty, and the
        VIRTIO_SCSI_F_INOUT
        feature has not been negotiated, the request will be
        immediately
        returned with a response equal to VIRTIO_SCSI_S_FAILURE.

And, of course:

VIRTIO_SCSI_S_DISCONNECT if the request could not be processed due
to a communication failure (eg device was removed or could not be
reached).

Ok.

This specification implies a strict one-to-one mapping between host
and target. IE there is no way of specifying more than one target
per host.

Actually no, the intention is to use hierarchical LUNs to support
more than one target per host.

Can't.

Hierarchical LUNs is a target-internal representation.
The initiator (ie guest OS) should _not_ try to assume anything about the internal structure and just use the LUN as an opaque number.

Reason being that the LUN addressing is not unique, and there are several choices on how to represent a given LUN.
So the consensus here is that different LUN numbers represent
different physical devices, regardless on the (internal) LUN representation. Which in turn means we cannot use the LUN number to convey anything else than a device identification relative to a target.

Cf SAM-3 paragraph 4.8:

A logical unit number is a field (see 4.9) containing 64 bits that identifies the logical unit within a SCSI target device
when accessed by a SCSI target port.

IE the LUN is dependent on the target, but you cannot make assumptions on the target.

Consequently, it's in the hosts' responsibility to figure out the targets in the system. After that it invokes the 'scan' function from the SCSI midlayer.
You can't start from a LUN and try to figure out the targets ...

If you want to support more than on target per host you need some sort of enumeration/callback which allows the host to figure out
the number of available targets.
But in general the targets are referenced by the target port identifier as specified in the appropriate standard (eg FC or SAS).
Sadly, we don't have any standard to fall back on for this.

If, however, we decide to expose some details about the backend, we could be using the values from the backend directly.
EG we could be forwarding the SCSI target port identifier here
(if backed by real hardware) or creating our own SAS-type
identifier when backed by qemu block. Then we could just query
the backend via a new command on the controlq
(eg 'list target ports') and wouldn't have to worry about any protocol specific details here.

Of course, when doing so we would be lose the ability to freely remap LUNs. But then remapping LUNs doesn't gain you much imho.
Plus you could always use qemu block backend here if you want
to hide the details.
But we would be finally able to use NPIV for KVM, something
I wanted to do for a _long_ time.

I personally _really_ would like to see the real backing device details exposed to the guest. Otherwise the more advanced stuff like persistent reservations becomes _really_ hard if not impossible.

Cheers,

Hannes
--
Dr. Hannes Reinecke                   zSeries & Storage
h...@suse.de                          +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to