From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QBp6c-0005Zx-Lv for qemu-devel@nongnu.org; Mon, 18 Apr 2011 10:07:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QBp6Y-0007sR-Ok for qemu-devel@nongnu.org; Mon, 18 Apr 2011 10:07:10 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49221 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QBp6Y-0007sB-EG for qemu-devel@nongnu.org; Mon, 18 Apr 2011 10:07:06 -0400 Message-ID: <4DAC4516.6090600@suse.de> Date: Mon, 18 Apr 2011 16:05:10 +0200 From: Hannes Reinecke MIME-Version: 1.0 References: <1302874976-22248-1-git-send-email-pbonzini@redhat.com> <4DA85370.4080909@redhat.com> <4DA85831.5080209@redhat.com> <4DA8B106.4080809@redhat.com> In-Reply-To: <4DA8B106.4080809@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH] implement vmware pvscsi device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, "Nicholas A. Bellinger" , "Michael S. Tsirkin" 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=20 initiator and target. Anything else (like hotplug, error recovery,=20 target addressing etc) is out of the scope of the spec and needs to=20 be implemented on another layer (that's the ominous transport layer). Hence any protocol implemented to the above spec would be missing=20 those parts, and they would need to be implemented additionally. Which also explains why these features are missing when just using=20 SCSI CDBs as the main command container. My proposal would be to implement a full virtio-scsi _host_, and=20 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=20 CDB, and define TMF command values for proper error recovery. That way we could handle hotplug / -unplug via a simple host rescan,=20 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=20 and length field. Check SG_IO header on how it's done. Cheers, Hannes --=20 Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg GF: Markus Rex, HRB 16746 (AG N=FCrnberg)