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

[Avi Kivity <avi@redhat.com>]

On 02/07/2011 07:30 PM, Yoder Stuart-B08248 wrote:
>
> >  -----Original Message-----
> >  From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org]
> >  On Behalf Of Avi Kivity
> >  Sent: Monday, February 07, 2011 11:14 AM
> >  To: Alexander Graf
> >  Cc: Wood Scott-B07421; Yoder Stuart-B08248; kvm-ppc@vger.kernel.org;
> >  kvm@vger.kernel.org; qemu-devel@nongnu.org
> >  Subject: Re: RFC: New API for PPC for vcpu mmu access
> >
> >  On 02/03/2011 11:19 AM, Alexander Graf wrote:
> >  >  >
> >  >  >   I have no idea what things will look like 10 years down the road,
> >  >  >  but  currently e500mc has 576 entries (512 TLB0, 64 TLB1).
> >  >
> >  >  That sums up to 64 * 576 bytes, which is 36kb. Ouch. Certainly nothing we
> >  want to transfer every time qemu feels like resolving an EA.
> >
> >  You could have an ioctl to translate addresses (x86 had KVM_TRANSLATE or
> >  similar), or have the TLB stored in user memory, so there is no need to
> >  transfer it (on the other hand, you have to re-validate it every time you
> >  peek at it).
>
> The most convenient and flexible thing for  Power Book III-E I think
> will be something that operates like a TLB search instruction.  Inputs
> are 'address space' and 'process id' and outputs are in which TLB the
> entry was found and all the components of a TLB entry:
>     address space
>     pid
>     entry number
>     ea
>     rpn
>     guest state
>     permissions flags
>     attributes (WIMGE)
>
> Since all of those fields are architected in MAS registers, in the previous
> proposal we just proposed to return several 32-bit fields (one per MAS)
> that use the architected layout instead of inventing a brand new
> structure defining these fields.
>

This looks reasonable assuming you can take the hit of a system call per 
translation.

-- 
error compiling committee.c: too many arguments to function