From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: RFC: New API for PPC for vcpu mmu access Date: Tue, 08 Feb 2011 11:10:20 +0200 Message-ID: <4D51087C.7060108@redhat.com> References: <9F6FE96B71CF29479FF1CDC8046E15030BCD40@039-SN1MPN1-002.039d.mgd.msft.net> <20110202160821.5a223366@udp111988uds> <4D50284A.4020606@redhat.com> <9F6FE96B71CF29479FF1CDC8046E15030C15B0@039-SN1MPN1-002.039d.mgd.msft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , Wood Scott-B07421 , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" To: Yoder Stuart-B08248 Return-path: In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E15030C15B0@039-SN1MPN1-002.039d.mgd.msft.net> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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