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

[Blue Swirl]

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

The first step could be execution of TB code from kqemu, memory
accesses could bypass the TLB.

> 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.

About register windows, it's strange that enabling REG_REGWPTR
mysteriously does not work.