From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LFUo9-0006iD-PZ for qemu-devel@nongnu.org; Wed, 24 Dec 2008 09:33:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LFUo9-0006hZ-6H for qemu-devel@nongnu.org; Wed, 24 Dec 2008 09:33:57 -0500 Received: from [199.232.76.173] (port=41675 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LFUo8-0006hE-Un for qemu-devel@nongnu.org; Wed, 24 Dec 2008 09:33:56 -0500 Received: from mail.sterilesecurity.com ([173.45.227.235]:46026) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LFUo6-0000Zb-IN for qemu-devel@nongnu.org; Wed, 24 Dec 2008 09:33:55 -0500 Message-ID: <4952484F.6010406@turnkeylinux.org> Date: Wed, 24 Dec 2008 16:33:51 +0200 From: Liraz Siri MIME-Version: 1.0 Subject: Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu? References: <49522F8D.4000203@turnkeylinux.org> <200812241336.01702.paul@codesourcery.com> In-Reply-To: <200812241336.01702.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: turnkey-discuss@lists.turnkeylinux.org, qemu-devel@nongnu.org Paul Brook wrote: > You need root privileges to load the random kernel modules required to d this. > Not going to happen for qemu. There's at least one counter-precedent. qemu takes advantage of kqemu which is also a "random kernel module". How would supporting a kernel module that simplified a bridged networking be any different? Also, qemu seems to require root privileges to setup tap devices, so it wouldn't be a first. BTW, we don't need this for our own use. We setup VDE + tap devices bridged to the network interface. Works great, at least for NICs that support bridging. Also it doesn't require root privileges, only permissions to connect to the unix socket vde is listening on. Unfortunately, for most users setting something like this up would probably be a challenge. It would be beneficial if qemu supported an easier way to set this up - like VirtualBox. >> 2) improved support for running 64bit guests on 32bit hosts >> >> On my Intel Core 2.4 rig I booted the Debian Lenny live CD in 48 >> seconds. >> >> By contrast, I booted the same CD under qemu-system-x86_64 in >> 257 seconds, or 5 times slower... > > You're comparing apples to oranges. Virtualbox uses virtualization, qemu use > emulation. I suspect if you boot a 64-bit OS you'll find things significantly > slower. Sorry if I wasn't clear. I am booting a 64-bit OS. I tested booting an amd64 Lenny live CD and an amd64 Ubuntu hardy desktop. My hardware supports 64bits but I'm still using a 32bit operating system. I don't really understand the implementation VirtualBox uses to accomplish running 64bit VM guests on a 32bit host. Is it possible VirtualBox have figured out how to run 64bit instructions on a host running in 32bit mode? (otherwise they'll need to be doing some kind of emulation) Testing this VirtualBox feature on hardware that doesn't support 64bit instructions will be revealing... > If you're running a 32-bit operating system on a 64-bit machine I'm completely > uninterested. Run a proper operating system that actually supports your > hardware. That's your choice, but keep in mind there are many types of users who have to work under different conditions... > Not quite true. IIRC VirtualBox is released under a proprietary licence, with > some parts dual licenced as GPL. QEMU is a mixture of GPL, LGPL and BSD. This > discrepancy tends to disourage cooperation. According to their website VirtualBox OSE (the opensource edition) is in fact licensed under the GPL. Cheers, Liraz