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

[Edgar E. Iglesias]

On Thu, Feb 10, 2011 at 12:55:22PM +0100, Alexander Graf wrote:
> 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?

Hi,

TBH, I don't really know. My goal was to get linux running on an PPC-440
embedded with the Xilinx FPGA's. I managed to fix enough BookE emulation
to get that far.

After that, we've done a few more hacks to run fsboot and uboot. Also,
we've added support for some of the BookE debug registers to be able
to run gdbserver from within linux guests. Some of these patches haven't
made it upstream yet.

I haven't taken the time to compare the specs to qemu code, so I don't
really know how much is missing. My guess is that If you wan't to run
linux guests, the MMU won't be the limiting factor.

Cheers