From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49817) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QBr1R-0006Vp-Ds for qemu-devel@nongnu.org; Mon, 18 Apr 2011 12:09:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QBr1M-0004Md-Lb for qemu-devel@nongnu.org; Mon, 18 Apr 2011 12:09:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19905) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QBr1M-0004M6-DC for qemu-devel@nongnu.org; Mon, 18 Apr 2011 12:09:52 -0400 Message-ID: <4DAC6246.5030908@redhat.com> Date: Mon, 18 Apr 2011 18:09:42 +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> <4DA8B106.4080809@redhat.com> <4DAC4516.6090600@suse.de> In-Reply-To: <4DAC4516.6090600@suse.de> 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: Hannes Reinecke Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, "Nicholas A. Bellinger" , "Michael S. Tsirkin" On 04/18/2011 04:05 PM, Hannes Reinecke wrote: > My proposal would be to implement a full virtio-scsi _host_, and extend > the proposal to be able to handle the transport layer too. Yes, I have added this independently from Friday to today, and it is why I haven't sent the proposal yet. > At the lastest we would need to include a LUN address before the CDB, > and define TMF command values for proper error recovery. I haven't yet worked out TMF, but I did add a LUN. > That way we could handle hotplug / -unplug via a simple host rescan It's a bit more complicated because you also want guest-initiated unplug, and SAM transport reset events include more than hotplug/unplug. >> 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. Will do. Paolo