Re: [Qemu-devel] 4G address space remapping on 64-bit host

[Fabrice Bellard <fabrice@bellard.org>]

Blue Swirl wrote:
> On 6/29/07, Fabrice Bellard <fabrice@bellard.org> wrote:
>> In fact, running in 64 bit is not necessary : It is simpler and more
>> efficient to use kqemu (or KVM) to handle the address space remapping.
>> The trick is to run the translator in the upper part or lower part of
>> the 32 bit address space and to protect it with segments.
> 
> Would that be hard to implement for the kqemu case? What is your
> guesstimate on what kind of performance benefit would Sparc32
> emulation get from that?

The kqemu part could be quite simple. A new execution mode could be 
added so that:

- shadow page table faults generate a specific signal in the user guest 
code.
- A kqemu "syscall" callable from the user guest code could be used to 
do the equivalent of tlb_set_page(), tlb_flush_page() and tlb_flush().

Note that I don't think it is worth using Xen for that. Modifying kqemu 
(or even KVM) should be more flexible. With kqemu it could also work on 
FreeBSD, Solaris, Windows and Linux.

The more complicated part is to split QEMU in two parts : one part 
containing the translator (and maybe some devices) would be executed as 
guest user code in kqemu. The other part would be executed as a regular 
process to handle what is left (graphic, disk access, etc).

If TB where MMIO accesses are done are compiled specifically, I think it 
can be quite efficient.

For the specific sparc32 case, I think that a better register window 
handling and a faster soft mmu code (using 4MB TLBs as it was proposed 
in a patch long ago) should already give an important speed boost (say a 
factor 1.5 to 2). The kqemu optimisation should give at least as much 
performance gain, depending on the ratio of instructions which do a 
memory access and on the number of TLB faults.

Regards,

Fabrice.