RE: RFC: New API for PPC for vcpu mmu access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----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.

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.

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.

Stuart

--
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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux