qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] softmmu thoughts


From: Magnus Damm
Subject: Re: [Qemu-devel] softmmu thoughts
Date: Sun, 31 Oct 2004 13:21:58 +0100

On Wed, 2004-10-20 at 20:30, Fabrice Bellard wrote:
> Since the submitted patch does not implement what I suggested, it is not 
> a problem of porting it :-)

Gotcha. =) 

So, I would really like to see this implemented, and I would be happy to
give it a go myself if no one else is working on it.

But...

How should the code be added? 
-----------------------------
By adding a CONFIG_SOFTMMU_MMAP that controls if the extra code should
be added to the softmmu target? This extra code will check if it is
possible to use the mmap trick to speed up the emulation and if not it
will fall back to the ordinary softmmu code.

Maybe it is better to create a new target? I do not think so, I believe
that it is good to keep the number binaries low if possible.

Locating physical pages: With an array or just base + offset?
----------------------------------------------------------
If we arrange all the physical memory so each page of real data is
followed by a page used to generate a signal, then how do we then locate
the pages containing real data?

Is it good to arrange all pages linearly so every other page is the
actual data and the pages in between are used to generate signals? We
locate the actual physical page by using a base address and calculating
the offset to the real page.

Or, is it better to keep an array of page pointers and allocating all
two-page combinations where ever they fit into the process memory space?
The lower bits of the address to each page could used to replace
phys_ram_dirty.

I like the first idea, but maybe the latter is more portable.

Should we keep phys_ram_base?
-----------------------------
Maybe it is a good thing to keep one linear copy of the physical memory?
That way much of the softmmu code could be kept intact.

The drawback of having the memory mapped at two places is of course that
more of the process address space will be used. Which means that the
maximum amount of emulated ram will be affected.

I would prefer to keep one linear copy of the physical memory together
with all two-page combinations. But that requires that the host OS
allows us to map the same physical page at two virtual addresses...

Thanks!

/ magnus





reply via email to

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