From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cs2SG-0008Q1-6o for qemu-devel@nongnu.org; Fri, 21 Jan 2005 12:20:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cs2SC-0008O4-NN for qemu-devel@nongnu.org; Fri, 21 Jan 2005 12:20:13 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cs2SB-0008MT-56 for qemu-devel@nongnu.org; Fri, 21 Jan 2005 12:20:11 -0500 Received: from [38.113.3.61] (helo=smtp-out.hotpop.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cs2BE-0005Dt-3P for qemu-devel@nongnu.org; Fri, 21 Jan 2005 12:02:40 -0500 Received: from phreaker.net (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id 450B0D36FDF for ; Fri, 21 Jan 2005 17:02:30 +0000 (UTC) Received: from jbrown.mylinuxbox.org (pcp03144805pcs.midval01.tn.comcast.net [68.59.228.236]) by smtp-1.hotpop.com (Postfix) with ESMTP id E2B2D1A00F5 for ; Fri, 21 Jan 2005 17:02:16 +0000 (UTC) Date: Fri, 21 Jan 2005 12:02:02 -0500 From: "Jim C. Brown" Subject: Re: [Qemu-devel] OT: Running qemu without host os? Message-ID: <20050121170202.GA11609@jbrown.mylinuxbox.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On Fri, Jan 21, 2005 at 05:10:33PM +0100, Peter Karlsson wrote: > Hi! > > I'm toying with the idea of running qemu as a vm from linuxbios and then > boot another os inside the vm (qemu). Qemu would have to virtualise the > hardware but still let the virtual os access hardware via normal hardware > registers, i.e. the os would not know a real computer from a virtualised > one. Is this theoretically possible, or maybe even practically? >>From instead a host OS the virtual (or guest) OS would not know that it is not a real computer. Emulating from the hardware would make this even harder to figure out. The part about giving access to the native hardware directly (instead of access to emulated hardware) is interesting. > > One of the reasons for doing something like this would be to snoop windows > driver registers for example reverse engineering of graphics hardware and > maybe wireless network cards. But I can think of several other useful > areas like high-availability, remote management of cluster nodes etc... This can still be done in a host OS. The only benefit of using qemu directly is the factor of speed and RAM usage (you can go faster when you access the bare metal and you don't have to load up an OS). > > Best regards > > Peter K > > -- > We Can Put an End to Word Attachments: > http://www.fsf.org/philosophy/no-word-attachments.html > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.