[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access

[Scott Wood <scottwood@freescale.com>]

On Thu, 3 Feb 2011 10:19:06 +0100
Alexander Graf <agraf@suse.de> wrote:

> Yeah, that one's tricky. Usually the way the memory resolver in qemu works is as follows:
> 
>  * kvm goes to qemu
>  * qemu fetches all mmu and register data from kvm
>  * qemu runs its mmu resolution function as if the target was emulated
> 
> So the "normal" way would be to fetch _all_ TLB entries from KVM, shove them into env and implement the MMU in qemu (at least enough of it to enable debugging). No other target modifies this code path. But no other target needs to copy > 30kb of data only to get the mmu data either :).

I guess you mean that cpu_synchronize_state() is supposed to pull in the
MMU state, though I don't see where it gets called for 'm'/'M' commands in
the gdb stub.

The MMU code seems to be pretty target-specific.  It's not clear to what
extent there is a "normal" way, versus what book3s happens to rely on in
its get_physical_address() code.  I don't think there are any platforms
supported yet (with both KVM and a non-empty cpu_get_phys_page_debug()
implementation) that have a pure software-managed TLB.  x86 has page
tables, and book3s has the hash table (603/e300 doesn't, or more accurately
Linux doesn't use it, but I guess that's not supported by KVM yet?).

We could probably do some sort of lazy state transfer only when MMU code
that needs it is run.  This could initially include debug translations, for
testing a non-KVM-dependent get_physical_address() implementation, but
eventually that would use KVM_TRANSLATE (when KVM is used) and thus not
trigger the state transfer.  I'd also like to add an "info tlb" command,
which would require the state transfer.

BTW, how much other than the MMU is missing to be able to run an e500
target in qemu, without kvm?

-Scott