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

[Alexander Graf]

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