Scott Wood wrote: > On Thu, 3 Feb 2011 10:19:06 +0100 > Alexander Graf <ag...@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. >
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
