On Tue, Jun 14, 2011 at 9:39 AM, Hannes Reinecke <hare@xxxxxxx> wrote: > 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. I think we want to be able to pass through one or more SCSI targets, so we probably need a 'list target ports' control command. Stefan _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
