From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19PS1w-00055l-6u for qemu-devel@nongnu.org; Mon, 09 Jun 2003 15:10:08 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19PS1k-0004w8-0b for qemu-devel@nongnu.org; Mon, 09 Jun 2003 15:09:57 -0400 Received: from smtp6.wanadoo.fr ([193.252.22.28] helo=mwinf0303.wanadoo.fr) by monty-python.gnu.org with esmtp (Exim 4.20) id 19PS1j-0004sz-1u for qemu-devel@nongnu.org; Mon, 09 Jun 2003 15:09:55 -0400 Received: from free.fr (unknown [80.14.188.129]) by mwinf0303.wanadoo.fr (SMTP Server) with ESMTP id E43E55000912 for ; Mon, 9 Jun 2003 21:09:53 +0200 (CEST) Message-ID: <3EE4DB71.3090706@free.fr> Date: Mon, 09 Jun 2003 21:09:37 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] simulated memory instead of host memory References: <20030609203126.7fc1bb17.jrydberg@night.trouble.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , To: qemu-devel@nongnu.org Johan Rydberg wrote: > First question of the day; > > First of all I would like to say that I really like the concept of QEMU. > Let GCC do most of the work and just glue it all together. Brilliant. > One downside of it though is all the tampering with flags to GCC. Yes, on every new gcc version there may be problems... a solution may be to distribute binary only versions of some object files of QEMU. I hope that someday someone will make a proper code generator, but it is really a lot of work! > To the question. How hard would it be to make QEMU a full-system > simulator? Or, more concrete: How hard would it be to instead of using > the host memory for the simulated app, use simulated memory (on per-page > basis)? It would be possible. I spent a lot of time thinking about it, but I did not make it because of lack of time and motivation. I see three solutions: 1) The very slow (but simplest) solution is to just modify the memory access inline functions in 'cpu-i386.h' to emulate the x86 MMU. 2) A faster solution is to use 4MB tables containing the addresses of each CPU page. One 4MB table would be used for read, one table for write. The tables can be seen as big TLBs. Unmapped pages would have a NULL entry in the tables so that a fault is generated on access to fill the table. 3) An even faster solution is to use Linux memory mappings to emulate the MMU. The Linux MM state of the process would be considered as a TLB of the virtual x86 MMU state. It works only if the host has <= 4KB page size and if the guest OS don't do any mapping in memory >= 0xc0000000. With Linux as guest it would work as you can easily change the base address of the kernel. The restriction about mappings >= 0xc0000000 could be suppressed with a small (but tricky) kernel patch which would allow to mmap() at addresses >= 0xc0000000. I wanted to implement solution (3) to be able to simulate an unpatched Linux kernel (and call the project 'qplex86' !). To run any OS you would also need precise segment limits and rights emulation, at least for non user code. Fabrice.