On Thu, 3 Feb 2011 10:19:06 +0100 Alexander Graf <agraf@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
