Re: [Qemu-devel] softmmu thoughts

[Fabrice Bellard]

Magnus Damm wrote:
> Hello,
>
>
> > - 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 :-)

Fabrice.