From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41090) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QAkOz-0006QJ-7p for qemu-devel@nongnu.org; Fri, 15 Apr 2011 10:53:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QAkOv-0003r4-97 for qemu-devel@nongnu.org; Fri, 15 Apr 2011 10:53:41 -0400 Received: from cantor.suse.de ([195.135.220.2]:38943 helo=mx1.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QAkOv-0003qT-0W for qemu-devel@nongnu.org; Fri, 15 Apr 2011 10:53:37 -0400 Message-ID: <4DA85C7E.6030403@suse.de> Date: Fri, 15 Apr 2011 16:55:58 +0200 From: Hannes Reinecke MIME-Version: 1.0 References: <1302874976-22248-1-git-send-email-pbonzini@redhat.com> <4DA85370.4080909@redhat.com> In-Reply-To: <4DA85370.4080909@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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 04:17 PM, Paolo Bonzini wrote: > On 04/15/2011 04:01 PM, Stefan Hajnoczi wrote: >> I think SCSI brings many benefits. Guests can deal with it better >> than these alien vdX virtio-blk devices, which makes migration easier. >> It becomes possible to attach many disks without burning through free >> PCI slots. We don't need to update guests to add cache control, >> discard, and other commands because they are part of SCSI. We can >> pass through more exotic devices. The list goes on... >=20 > And we also have to reimplement all of MMC. :) >=20 > A few questions: >=20 > 1) Do you have anything posted for the virtio-scsi spec? I had started > working on one, but I haven't yet made it final. It included also > hotplug/unplug. I can send it out on Monday. >=20 > 2) Have you thought about making scsi-disk and scsi-generic provide a > logical unit rather than a target? Otherwise passthrough of a whole > host or target becomes hard or messy. >=20 > 3) Since I noticed Hannes is CCed, my next step for vmw_pvscsi would be > to dust off his patches to remove the bounce buffers, and see how they > apply to vmw_pvscsi. But I'd like to avoid duplicated work if possible= . >=20 Argl. Why vmw_pvscsi? Any paravirtualized driver doesn't improve the situation here; we still wouldn't have a driver for unmodified guests. So either emulate existing drivers (like megasas :-) or go the full route and do a proper virtio-scsi. As for the bounce buffers thing: Good luck. Paul Brook absolutely insists on having them, but they kill performance for any sane backend. And both are basically impossible to reconcile; tried it once but got pushed back. And after about the third attempt I gave up. Let me know if you have more luck here. But keep me in the loop for the virtio-scsi spec. I do have some ideas what needs to get in there. As I think hch has. 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)