Re: [Qemu-devel] [RFC PATCH] implement vmware pvscsi device

[Hannes Reinecke <hare@suse.de>]

On 04/15/2011 10:56 PM, Paolo Bonzini wrote:
> On 04/15/2011 05:04 PM, Stefan Hajnoczi wrote:
>> The way I approached virtio-scsi was to look at the SCSI Architecture
>> Model document and some of the Linux SCSI code. I'm not sure if
>> letting virtio-blk SCSI pass-through or scsi-generic guide us is a
>> good approach.
>>
>> How do your ioprio and barrier relate to SCSI?
>
> Both are part of the transport protocol, which can provide
> additional features with respect to SAM. For example SCSI doesn't
> provide the full details of hotplug/hotunplug, or doesn't have a way
> for the guest to trigger a drive unplug on the host, but these are
> all desirable features for virtio-scsi (and they are supported by
> vmw_pvscsi by the way).
>
And this is something I really miss in the current proposals, namely
a working transport layer.

The SCSI spec (SPC etc) itself just handles command delivery between 
initiator and target. Anything else (like hotplug, error recovery, 
target addressing etc) is out of the scope of the spec and needs to 
be implemented on another layer (that's the ominous
transport layer).

Hence any protocol implemented to the above spec would be missing 
those parts, and they would need to be implemented additionally.
Which also explains why these features are missing when just using 
SCSI CDBs as the main command container.

My proposal would be to implement a full virtio-scsi _host_, and 
extend the proposal to be able to handle the transport layer too.
At the lastest we would need to include a LUN address before the 
CDB, and define TMF command values for proper error recovery.

That way we could handle hotplug / -unplug via a simple host rescan, 
and would even be able to pass-in NPIV hosts.

>> There seem to be recent/exotic commands that can have both data-in
>> and data-out buffers.
>
These are bi-directional commands which are required for OSD.

> That can fit by adding more stuff at the end of the buffer. It can
> be in the first version, or it can be an extra feature for later.
> Since QEMU currently cannot handle it, probably it would need
> negotiation even if it were in the first version.
>
>> The sense buffer length is also not necessarily 96
>> bytes max, I believe.
>
> I couldn't find that in either SPC or SAM indeed. It seems like a
> pretty widespread assumption though. Perhaps Nicholas or Hannes know
> where it comes from.
>
96 bytes is a carry-over from scsi parallel. We shouldn't rely
on a fixed length here but rather use an additional pointer/iovec 
and length field.

Check SG_IO header on how it's done.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)