[Top][All Lists]

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

Re: [Qemu-devel] softmmu thoughts

From: Fabrice Bellard
Subject: Re: [Qemu-devel] softmmu thoughts
Date: Wed, 20 Oct 2004 20:30:08 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803

Magnus Damm wrote:

- It would be more efficient and simpler to map one 4KB host memory page every 8 KB. Then you can have a fixed mmap() mapping (no syscall overhead to change the mappings) and a simple way to handle unaligned accesses.

If I understand correctly the second page is used to generate a signal
for memory accesses that crosses the page boundary like I said earlier,
right? So the entire memory available to the guest is mapped into memory
using this technique. But how will protection work? What if two virtual
pages with different protection modes map to the same physical page? Do
we have two copies of all memory, one read-only and one read-write?

No. You can use different indirection tables for read and write, and for user and kernel accesses, which means 4 tables of 4 MB each. 2 tables of 4 MB can be used at the cost of a table flush when switching between user and kernel mode. Auxiliary smaller tables should be used to record which 4MB table entries are used so that it is not necessary to rewrite all the tables to flush them.

- The critical point would be to keep standard soft MMU accesses for device access. An architectural change is needed to do that, but it seems easy to add.

How do you plan to do that? Just curious.

QEMU will recompile dynamically a basic block which does device access so that it uses the standard soft MMU. It is done to some extend in qemu-fast, but it is not optimized. It means that there will be some performance penalty if the same basic block of code is used for both device access and normal memory access (memcpy could be an example of such code).

- This patch should work with qemu, not qemu-fast. The future of qemu-fast is to use a kernel module to have near native performances. It is not worthwhile to invest time in soft MMU or dynamic translation when you can just execute the code as is !

I fully agree. So, who is porting the patch from qemu-fast to qemu? I'm
available for some powerpc-specific hacking on the weekends.

Since the submitted patch does not implement what I suggested, it is not a problem of porting it :-)


reply via email to

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