On 02.02.2011, at 23:34, Yoder Stuart-B08248 wrote: > > >> -----Original Message----- >> From: Alexander Graf [mailto:agraf@xxxxxxx] >> Sent: Wednesday, February 02, 2011 3:34 PM >> To: Yoder Stuart-B08248 >> Cc: kvm-ppc@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; qemu-devel@xxxxxxxxxx >> Subject: Re: RFC: New API for PPC for vcpu mmu access >> >> >> On 02.02.2011, at 21:33, Yoder Stuart-B08248 wrote: >> >>> Below is a proposal for a new API for PPC to allow KVM clients to set >>> MMU state in a vcpu. >>> >>> BookE processors have one or more software managed TLBs and currently >>> there is no mechanism for Qemu to initialize or access them. This is >>> needed for normal initialization as well as debug. >>> >>> There are 4 APIs: >>> >>> -KVM_PPC_SET_MMU_TYPE allows the client to negotiate the type of MMU >>> with KVM-- the type determines the size and format of the data in the >>> other APIs >> >> This should be done through the PVR hint in sregs, no? Usually a single CPU >> type only has a single MMU type. >> >>> -KVM_PPC_INVALIDATE_TLB invalidates all TLB entries in all TLBs in the >>> vcpu >>> >>> -KVM_PPC_SET_TLBE sets a TLB entry-- the Power architecture specifies >>> the format of the MMU data passed in >> >> This seems to fine-grained. I'd prefer a list of all TLB entries to be >> pushed in either direction. What's the foreseeable number of TLB entries >> within the next 10 years? >> >> Having the whole stack available would make the sync with qemu easier and >> also allows us to only do a single ioctl for all the TLB management. Thanks >> to the PVR we know the size of the TLB, so we don't have to shove that >> around. > > Yes, we thought about that approach but the idea here, as Scott > described, was to provide an API that could work if user space > is unaware of the geometry of the TLB. Userspace shouldn't be unaware of the TLB, that's the whole point :). In principle, all state should be fetchable from userspace - so it has to know the geometry. > Take a look at Power ISA Version 2.06.1 (on power.org) at the definition > of TLBnCFG in Book E. The NENTRY and ASSOC fields now have meaning that > allow TLB geometries that cannot be described in the TLBnCFG > registers. It's certainly not easy to assemble all the required information in userspace, but we need to do so nevertheless - having the state available simply buys us a lot in terms of flexibility. > I think the use case where this API would be used the most > would be from a gdb stub that needed to look up an effective > address. I agree. As I stated in my previous mail, there's probably good rationale to explicitly tune that path. That doesn't mean that we have to leave out the generic one. It should only be an acceleration. After all, this whole flexibility thing with all the potential possibilities is KVM's strong point. We should not close the doors on those :). 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
