[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access
From: |
Alexander Graf |
Subject: |
[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access |
Date: |
Thu, 10 Feb 2011 12:55:22 +0100 |
User-agent: |
Thunderbird 2.0.0.23 (X11/20090817) |
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
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, (continued)
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Avi Kivity, 2011/02/07
- [Qemu-devel] RE: RFC: New API for PPC for vcpu mmu access, Yoder Stuart-B08248, 2011/02/07
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Avi Kivity, 2011/02/08
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/09
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access,
Alexander Graf <=
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Edgar E. Iglesias, 2011/02/10
- [Qemu-devel] RE: RFC: New API for PPC for vcpu mmu access, Yoder Stuart-B08248, 2011/02/02
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/03