From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QBqM3-0005wu-7w for qemu-devel@nongnu.org; Mon, 18 Apr 2011 11:27:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QBqM1-00055r-Su for qemu-devel@nongnu.org; Mon, 18 Apr 2011 11:27:11 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:44578) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QBqM1-00055l-Me for qemu-devel@nongnu.org; Mon, 18 Apr 2011 11:27:09 -0400 Received: by gyg4 with SMTP id 4so1846928gyg.4 for ; Mon, 18 Apr 2011 08:27:09 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4DAC4516.6090600@suse.de> References: <1302874976-22248-1-git-send-email-pbonzini@redhat.com> <4DA85370.4080909@redhat.com> <4DA85831.5080209@redhat.com> <4DA8B106.4080809@redhat.com> <4DAC4516.6090600@suse.de> Date: Mon, 18 Apr 2011 16:27:08 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC PATCH] implement vmware pvscsi device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hannes Reinecke Cc: Paolo Bonzini , qemu-devel@nongnu.org, "Nicholas A. Bellinger" , "Michael S. Tsirkin" On Mon, Apr 18, 2011 at 3:05 PM, Hannes Reinecke wrote: > 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. In my prototype there is a header and a footer for the request and response, respectively: http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=blob;f=include/linux/virtio_scsi.h;hb=refs/heads/tcm_vhost We definitely need more than plain CDB pass-through. Stefan