qemu-devel
[Top][All Lists]
Advanced

[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: Yoder Stuart-B08248
Subject: [Qemu-devel] RE: RFC: New API for PPC for vcpu mmu access
Date: Mon, 7 Feb 2011 17:30:18 +0000


> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> On Behalf Of Avi Kivity
> Sent: Monday, February 07, 2011 11:14 AM
> To: Alexander Graf
> Cc: Wood Scott-B07421; Yoder Stuart-B08248; address@hidden;
> address@hidden; address@hidden
> 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.

Stuart




reply via email to

[Prev in Thread] Current Thread [Next in Thread]