From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LFTuI-0001vc-M6 for qemu-devel@nongnu.org; Wed, 24 Dec 2008 08:36:14 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LFTuG-0001vC-R1 for qemu-devel@nongnu.org; Wed, 24 Dec 2008 08:36:13 -0500 Received: from [199.232.76.173] (port=53347 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LFTuG-0001v9-NW for qemu-devel@nongnu.org; Wed, 24 Dec 2008 08:36:12 -0500 Received: from mx20.gnu.org ([199.232.41.8]:62646) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LFTuG-0002LX-Dw for qemu-devel@nongnu.org; Wed, 24 Dec 2008 08:36:12 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LFTuE-0002P4-MX for qemu-devel@nongnu.org; Wed, 24 Dec 2008 08:36:10 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu? Date: Wed, 24 Dec 2008 13:36:01 +0000 References: <49522F8D.4000203@turnkeylinux.org> In-Reply-To: <49522F8D.4000203@turnkeylinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200812241336.01702.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: turnkey-discuss@lists.turnkeylinux.org, Liraz Siri > 1) complex setup is no longer required for "bridged" networking: > > This works without root privileges somehow, probably by taking > advantage of new infrastructure in the VirtualBox device driver. You need root privileges to load the random kernel modules required to d th= is.=20 Not going to happen for qemu. > 2) improved support for running 64bit guests on 32bit hosts > > =A0 =A0On my Intel Core 2.4 rig I booted the Debian Lenny live CD in 48 > =A0 =A0seconds. > > =A0 =A0By contrast, I booted the same CD under qemu-system-x86_64 in > =A0 =A0257 seconds, or 5 times slower... You're comparing apples to oranges. Virtualbox uses virtualization, qemu us= e=20 emulation. I suspect if you boot a 64-bit OS you'll find things significant= ly=20 slower. If you're running a 32-bit operating system on a 64-bit machine I'm complet= ely=20 uninterested. Run a proper operating system that actually supports your=20 hardware. If you want 32-bit on 64-bit virtualization you need to talk to the KVM=20 people. I doubt you'll find much interest though. Any hardware that support= s=20 KVM is already 64-bit, and you're almost entirely targetting obsolete=20 hardware. On a related note, VirtualBox has the same problem as kqemu: Out of tree=20 kernel modules are just plain wrong. A large proportion of the linux=20 community (me included) isn't going to take it seriously until it's [aiming= =20 to be] merged into mainstream kernels. To do that you probably need to make= =20 it use the KVM interface. > These are dramatic improvements in usability and I'm curious whether it > is likely that these changes will find there way to qemu? I know that > both projects are under the same opensource license Not quite true. IIRC VirtualBox is released under a proprietary licence, wi= th=20 some parts dual licenced as GPL. QEMU is a mixture of GPL, LGPL and BSD. Th= is=20 discrepancy tends to disourage cooperation. Paul