Blue Swirl wrote:
On 6/29/07, Fabrice Bellard <[EMAIL PROTECTED]> 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.
