From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QAq4N-0007g4-Bi for qemu-devel@nongnu.org; Fri, 15 Apr 2011 16:56:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QAq4M-0003PZ-Di for qemu-devel@nongnu.org; Fri, 15 Apr 2011 16:56:47 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:36301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QAq4M-0003PP-8L for qemu-devel@nongnu.org; Fri, 15 Apr 2011 16:56:46 -0400 Received: by pwj6 with SMTP id 6so1599156pwj.4 for ; Fri, 15 Apr 2011 13:56:44 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4DA8B106.4080809@redhat.com> Date: Fri, 15 Apr 2011 22:56:38 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1302874976-22248-1-git-send-email-pbonzini@redhat.com> <4DA85370.4080909@redhat.com> <4DA85831.5080209@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH] implement vmware pvscsi device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: "Michael S. Tsirkin" , Hannes Reinecke , "Nicholas A. Bellinger" , qemu-devel@nongnu.org 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). > There seem to be recent/exotic commands that can have both data-in and > data-out buffers. 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. Paolo