From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56954 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgOQ9-0000mA-8J for qemu-devel@nongnu.org; Tue, 03 Aug 2010 16:49:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OgOQ6-0004A9-RQ for qemu-devel@nongnu.org; Tue, 03 Aug 2010 16:49:09 -0400 Received: from mail-qy0-f173.google.com ([209.85.216.173]:62970) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgOQ6-0004A5-PF for qemu-devel@nongnu.org; Tue, 03 Aug 2010 16:49:06 -0400 Received: by qyk35 with SMTP id 35so1274810qyk.4 for ; Tue, 03 Aug 2010 13:49:06 -0700 (PDT) Message-ID: <4C5880BC.2080802@codemonkey.ws> Date: Tue, 03 Aug 2010 15:49:00 -0500 From: Anthony Liguori 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> In-Reply-To: <20100803200057.GB28523@amd.home.annexia.org> 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: "Richard W.M. Jones" Cc: kvm@vger.kernel.org, Avi Kivity , Gleb Natapov , qemu-devel@nongnu.org On 08/03/2010 03:00 PM, Richard W.M. Jones wrote: > On Tue, Aug 03, 2010 at 10:22:22PM +0300, Avi Kivity wrote: > >> On 08/03/2010 10:13 PM, Richard W.M. Jones wrote: >> >>> On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote: >>> >>>> libguestfs does not depend on an x86 architectural feature. >>>> qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We >>>> should discourage people from depending on this interface for >>>> production use. >>>> >>> I really don't get this whole thing where we must slavishly >>> emulate an exact PC ... >>> >> This has two motivations: >> >> - documented interfaces: we suck at documentation. We seldom >> document. Even when we do document something, the documentation is >> often inaccurate, misleading, and incomplete. While an "exact PC" >> unfortunately doesn't exist, it's a lot closer to reality than, say, >> an "exact Linux syscall interface". If we adopt an existing >> interface, we already have the documentation, and if there's a >> conflict between the documentation and our implementation, it's >> clear who wins (well, not always). >> >> - preexisting guests: if we design a new interface, we get to update >> all guests; and there are many of them. Whereas an "exact PC" will >> be seen by the guest vendors as well who will then add whatever >> support is necessary. >> > On the other hand we end up with stuff like only being able to add 29 > virtio-blk devices to a single guest. As best as I can tell, this > comes from PCI No, this comes from us being too clever for our own good and not following the way hardware does it. All modern systems keep disks on their own dedicated bus. In virtio-blk, we have a 1-1 relationship between disks and PCI devices. That's a perfect example of what happens when we try to "improve" things. > , and this limit required a bunch of hacks when > implementing virt-df. > > These are reasonable motivations, but I think they are partially about > us: > > We could document things better and make things future-proof. I'm > surprised by how lacking the doc requirements are for qemu (compared > to, hmm, libguestfs for example). > We enjoy complaining about our lack of documentation more than we like actually writing documentation. > We could demand that OSes write device drivers for more qemu devices > -- already OS vendors write thousands of device drivers for all sorts > of obscure devices, so this isn't really much of a demand for them. > In fact, they're already doing it. > So far, MS hasn't quite gotten the clue yet that they should write device drivers for qemu :-) In fact, noone has. Regards, Anthony Liguori > Rich. > >