On 02/07/2011 07:30 PM, Yoder Stuart-B08248 wrote:
> -----Original Message----- > From: kvm-ppc-owner@xxxxxxxxxxxxxxx [mailto:kvm-ppc-owner@xxxxxxxxxxxxxxx] > 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@xxxxxxxxxxxxxxx; > kvm@xxxxxxxxxxxxxxx; qemu-devel@xxxxxxxxxx > 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 -- 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
