[Top][All Lists]

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

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

From: Fabrice Bellard
Subject: Re: [Qemu-devel] 4G address space remapping on 64-bit host
Date: Fri, 29 Jun 2007 22:48:36 +0200
User-agent: Thunderbird (X11/20070212)

Blue Swirl wrote:
On 6/29/07, Fabrice Bellard <address@hidden> 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.



reply via email to

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