Re: [Qemu-devel] softmmu thoughts

[Piotras]

Hi!

On Thu, 16 Dec 2004 23:16:39 +0100, Fabrice Bellard <address@hidden> wrote:
> Hi,
> 
> Here are a few points to look at:
> 
> 1) MMU_MAP -> SOFT_MMU transition : more work is needed there, but I
> will look at it too, but not in the near future (I think the best
> solution is to recompile the TB directly in the fault handler - the goal
> is to suppress 'HF_SOFTMMU_MASK' which slows down the emulator).

This sounds reasonable.


> 2) Try to make a Windows port. It seems doable because when you create a
> 64 KB mapping in Windows you can select which 4 KB subpages are mapped.

At present I don't have Windows development environment -- I don't 
even have Windows at home). Maybe someone could volunteer here?


> 3) Test it with the ppc emulation if not already done.

This will be my priority. It would be also nice to try PPC host.


> 4) Use assembly code in most of the SOFTMMU code to accelerate unaligned
> and I/O accesses (the current code is not optimized).

This is nice future project, but not relevant for this patch.


> 5) For you and me: reduce the number of ifdefs for SOFTMMU/MMU_MAP and
> mmap().

Agreed.


> 6) You can go even faster (at least on Linux or *BSD) by using hard mmu
> for pages between 0 and a given address 'L' by using mmap() and by using
> segment limits. You can fall back to MMU_MAP if the address is >= 'L',
> and fall back to soft MMU if I/O accesses are done. The advantage is
> that the 'code copy' mode can be used in that case, so you get closer to
> 1:1 performance on most of the user code.

Also it would be nice to investigate possibility to setting up two LDT
entries -- one for accessing 0-"L" memory range and another for 
accessing "L1"-0xffffff range (using expansion direction flag of segment 
descriptor). Probably it could be possible to mix two in single TB (one 
for data and other for stack access).

However at present I'm more interested in non-code-copy case.


> Fabrice.


Regards,

Piotrek