From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33976 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgYrU-0006Y4-B2 for qemu-devel@nongnu.org; Wed, 04 Aug 2010 03:58:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OgYrT-0003oM-4X for qemu-devel@nongnu.org; Wed, 04 Aug 2010 03:58:04 -0400 Received: from mail-bw0-f45.google.com ([209.85.214.45]:51862) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgYrS-0003oD-Uz for qemu-devel@nongnu.org; Wed, 04 Aug 2010 03:58:03 -0400 Received: by bwz16 with SMTP id 16so2612451bwz.4 for ; Wed, 04 Aug 2010 00:58:01 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4C591D87.5020809@redhat.com> Date: Wed, 04 Aug 2010 09:57:59 +0200 From: Paolo Bonzini MIME-Version: 1.0 Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35? References: <4C5847CD.9080107@codemonkey.ws> <4C5848C7.3090806@redhat.com> <4C584982.5000108@codemonkey.ws> <4C584B66.5070404@redhat.com> <4C5854F1.3000905@codemonkey.ws> <4C5858B2.9090801@redhat.com> <4C585F5B.5070502@codemonkey.ws> <4C58635B.7020407@redhat.com> <20100803191346.GA28523@amd.home.annexia.org> <4C586C6E.9030002@redhat.com> <20100803200057.GB28523@amd.home.annexia.org> <4C5880BC.2080802@codemonkey.ws> <4C588685.8070509@redhat.com> <4C588B7D.5040902@codemonkey.ws> In-Reply-To: <4C588B7D.5040902@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, "Richard W.M. Jones" , Gleb Natapov , Avi Kivity On 08/03/2010 11:34 PM, Anthony Liguori wrote: >> >> Comparing (from personal experience) the complexity of the Windows >> drivers for Xen and virtio shows that it's not a bad idea at all. > > Not quite sure what you're suggesting, but I could have been clearer. > Instead of having virtio-blk where a virtio disk has a 1-1 mapping to a > PCI device, we probably should have just done virtio-scsi. If you did virtio-scsi you might have as well ditched virtio-pci altogether and provide a single PCI device just like Xen does. Just make your network device also speak SCSI (which is actually in the spec...), and the same for serial devices. But now your driver that has to implement its own hot-plug/hot-unplug mechanism rather than deferring it to the PCI subsystem of the OS (like Xen), greatly adding to the complication. In fact, a SCSI controller's firmware has a lot of other communication channels with the driver besides SCSI commands, and all this would be mapped into additional complexity on both the host side and the guest side. Yet another reminder of Xen. Despite the shortcomings, I think virtio-pci is the best example of balancing PV-specific aspects (do not make things too complicated) and "real world" aspects (do not invent new buses and the like). Paolo