[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] simulated memory instead of host memory

From: Fabrice Bellard
Subject: Re: [Qemu-devel] simulated memory instead of host memory
Date: Mon, 09 Jun 2003 21:09:37 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1) Gecko/20020828

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]