Scott Wood wrote: > 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. > Well, we could also call it in get_phys_page_debug in target-ppc, but yes. I guess the reason it works for now is that SDR1 is pretty constant and was fetched earlier on. For BookE not syncing is obviously even more broken. > 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?). > As for PPC, only 440, e500 and G3-5 are basically supported. It happens to work on POWER4 and above too and I've even got reports that it's good on e600 :). > 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 > Yup :). > trigger the state transfer. I'd also like to add an "info tlb" command, > which would require the state transfer. > Very nice. > BTW, how much other than the MMU is missing to be able to run an e500 > target in qemu, without kvm? > The last person working on BookE emulation was Edgar. Edgar, how far did you get? Alex -- 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
