From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: RFC: New API for PPC for vcpu mmu access Date: Tue, 15 Feb 2011 00:39:51 +0100 Message-ID: <32AC591D-A27F-4D76-82D4-CB93D66D71E1@suse.de> References: <9F6FE96B71CF29479FF1CDC8046E15030BCD40@039-SN1MPN1-002.039d.mgd.msft.net> <20110202160821.5a223366@udp111988uds> <20110204163338.54690220@udp111988uds> <30BEE027-929B-43E5-A638-A58389F90B6F@suse.de> <20110207141547.58e49caa@udp111988uds> <220F22AA-31E5-4ACB-B0D5-557010096B91@suse.de> <20110209170928.6c629514@udp111988uds> <4D53CFE2.6080008@suse.de> <20110210125112.6d1f0380@udp111988uds> <8ACEDFEA-AA7F-400F-88F1-5F99864E8AAF@suse.de> <63E8AA2B-685F-4360-9BC8-E760A2CAD570@suse.de> <49812881-9E7C-4295-B708-CFA986EE9500@suse.de> <20110211145340.70c5812b@udp111988uds> <113B6114-C44E-4DD4-B318-4CAC826179DE@suse.de> <20110211185734.42f7f73f@udp111988uds> <4DC23D10-A9C9-4C11-A344-A9779C370296 @suse.de> <20110214111153.07f884b6@udp111988uds> <20110214151657.0ce8c4a4@schlenkerla.am.freescale.net> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT Cc: Yoder Stuart-B08248 , "" , "kvm@vger.kernel.org list" , "qemu-devel@nongnu.org List" To: Scott Wood Return-path: Received: from cantor2.suse.de ([195.135.220.15]:43256 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753862Ab1BNXjy convert rfc822-to-8bit (ORCPT ); Mon, 14 Feb 2011 18:39:54 -0500 In-Reply-To: <20110214151657.0ce8c4a4@schlenkerla.am.freescale.net> Sender: kvm-owner@vger.kernel.org List-ID: On 14.02.2011, at 22:16, Scott Wood wrote: > On Mon, 14 Feb 2011 21:19:19 +0100 > Alexander Graf wrote: > >> There's no nack here :). The only thing that needs to change is the anonymous part, as that's a gnu extension. Just name the structs and unions and all is well. > > Ah, I thought it was an aesthetic objection -- didn't realize it was a > GNUism. Oh well. Maybe it was some other random extension, but it's certainly less compatible :). > >> The reason I was asking is that I assumed the code would end up being easier, not more complex without the u32s. In fact, it probably would. I'll leave the final decision if you want to access things by entry->u81.split.mas8 or entry->mas8_1 & MAS8_1_MAS8_MASK. > > After sending that, I was thinking that mas7_3 is more naturally used > as a pair, so I'd stick with the u64 there. > > I think mas8_1 benefits less from the pairing, though -- it's only really > useful if you're going to put the value directly in hardware, which we > won't. Sounds good. Make it 2 u32s then :). > >>>> The struct name should also have >>>> a version indicator - it's the data descriptor only a single specific >>>> mmu_type, right? >>> >>> It handles both KVM_MMU_PPC_BOOK3E_NOHV and KVM_MMU_PPC_BOOK3E_HV. >> >> Even fictional future changes to the tlb layout? > > No, those need a new MMU type ID. ... which means they need a new name, but then booke_tlb_entry is taken. > >>>> Please state the size explicitly then. It's 1k, right? >>> >>> It's 4K on Freescale chips. We should probably implement sregs first, in >>> which case qemu can read the MMU config registers to find out the minimum >>> supported page size. >>> >>> If we specify 4K here, we should probably just go ahead and stick FSL in >>> the MMU type name. Specifying the hash itself already makes me nervous >>> about claiming the more generic name. >> >> Yup, sounds good :). > > Which one, "read the MMU config registers" or "specify 4K and stick FSL in > the name"? The "specify 4k and stick fsl in the name" part. If we simply always define it to 4k for all currently supported clients of the interface (e500) we should be good, no? No need for evaluations then. Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48824 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pp81T-00061h-9g for qemu-devel@nongnu.org; Mon, 14 Feb 2011 18:40:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pp81L-0002gq-B2 for qemu-devel@nongnu.org; Mon, 14 Feb 2011 18:39:59 -0500 Received: from cantor2.suse.de ([195.135.220.15]:43254 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pp81K-0002gk-Q4 for qemu-devel@nongnu.org; Mon, 14 Feb 2011 18:39:55 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Alexander Graf In-Reply-To: <20110214151657.0ce8c4a4@schlenkerla.am.freescale.net> Date: Tue, 15 Feb 2011 00:39:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <32AC591D-A27F-4D76-82D4-CB93D66D71E1@suse.de> References: <9F6FE96B71CF29479FF1CDC8046E15030BCD40@039-SN1MPN1-002.039d.mgd.msft.net> <20110202160821.5a223366@udp111988uds> <20110204163338.54690220@udp111988uds> <30BEE027-929B-43E5-A638-A58389F90B6F@suse.de> <20110207141547.58e49caa@udp111988uds> <220F22AA-31E5-4ACB-B0D5-557010096B91@suse.de> <20110209170928.6c629514@udp111988uds> <4D53CFE2.6080008@suse.de> <20110210125112.6d1f0380@udp111988uds> <8ACEDFEA-AA7F-400F-88F1-5F99864E8AAF@suse.de> <63E8AA2B-685F-4360-9BC8-E760A2CAD570@suse.de> <49812881-9E7C-4295-B708-CFA986EE9500@suse.de> <20110211145340.70c5812b@udp111988uds> <113B6114-C44E-4DD4-B318-4CAC826179DE@suse.de> <20110211185734.42f7f73f@udp111988uds> <4DC23D10-A9C9-4C11-A344-A9779C370296@suse.de> <20110214111153.07f884b6@udp111988uds> <20110214151657.0ce8c4a4@schlenkerla.am.freescale.net> Subject: [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Scott Wood Cc: Yoder Stuart-B08248 , "kvm@vger.kernel.org list" , "" , "qemu-devel@nongnu.org List" On 14.02.2011, at 22:16, Scott Wood wrote: > On Mon, 14 Feb 2011 21:19:19 +0100 > Alexander Graf wrote: >=20 >> There's no nack here :). The only thing that needs to change is the = anonymous part, as that's a gnu extension. Just name the structs and = unions and all is well. >=20 > Ah, I thought it was an aesthetic objection -- didn't realize it was a > GNUism. Oh well. Maybe it was some other random extension, but it's certainly less = compatible :). >=20 >> The reason I was asking is that I assumed the code would end up being = easier, not more complex without the u32s. In fact, it probably would. = I'll leave the final decision if you want to access things by = entry->u81.split.mas8 or entry->mas8_1 & MAS8_1_MAS8_MASK. >=20 > After sending that, I was thinking that mas7_3 is more naturally used > as a pair, so I'd stick with the u64 there. >=20 > I think mas8_1 benefits less from the pairing, though -- it's only = really > useful if you're going to put the value directly in hardware, which we > won't. Sounds good. Make it 2 u32s then :). >=20 >>>> The struct name should also have >>>> a version indicator - it's the data descriptor only a single = specific >>>> mmu_type, right? >>>=20 >>> It handles both KVM_MMU_PPC_BOOK3E_NOHV and KVM_MMU_PPC_BOOK3E_HV. >>=20 >> Even fictional future changes to the tlb layout? >=20 > No, those need a new MMU type ID. ... which means they need a new name, but then booke_tlb_entry is taken. >=20 >>>> Please state the size explicitly then. It's 1k, right? >>>=20 >>> It's 4K on Freescale chips. We should probably implement sregs = first, in >>> which case qemu can read the MMU config registers to find out the = minimum >>> supported page size. >>>=20 >>> If we specify 4K here, we should probably just go ahead and stick = FSL in >>> the MMU type name. Specifying the hash itself already makes me = nervous >>> about claiming the more generic name. >>=20 >> Yup, sounds good :). >=20 > Which one, "read the MMU config registers" or "specify 4K and stick = FSL in > the name"? The "specify 4k and stick fsl in the name" part. If we simply always = define it to 4k for all currently supported clients of the interface = (e500) we should be good, no? No need for evaluations then. Alex From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Mon, 14 Feb 2011 23:39:51 +0000 Subject: Re: RFC: New API for PPC for vcpu mmu access Message-Id: <32AC591D-A27F-4D76-82D4-CB93D66D71E1@suse.de> List-Id: References: <9F6FE96B71CF29479FF1CDC8046E15030BCD40@039-SN1MPN1-002.039d.mgd.msft.net> <20110202160821.5a223366@udp111988uds> <20110204163338.54690220@udp111988uds> <30BEE027-929B-43E5-A638-A58389F90B6F@suse.de> <20110207141547.58e49caa@udp111988uds> <220F22AA-31E5-4ACB-B0D5-557010096B91@suse.de> <20110209170928.6c629514@udp111988uds> <4D53CFE2.6080008@suse.de> <20110210125112.6d1f0380@udp111988uds> <8ACEDFEA-AA7F-400F-88F1-5F99864E8AAF@suse.de> <63E8AA2B-685F-4360-9BC8-E760A2CAD570@suse.de> <49812881-9E7C-4295-B708-CFA986EE9500@suse.de> <20110211145340.70c5812b@udp111988uds> <113B6114-C44E-4DD4-B318-4CAC826179DE@suse.de> <20110211185734.42f7f73f@udp111988uds> <4DC23D10-A9C9-4C11-A344-A9779C370296 @suse.de> <20110214111153.07f884b6@udp111988uds> <20110214151657.0ce8c4a4@schlenkerla.am.freescale.net> In-Reply-To: <20110214151657.0ce8c4a4@schlenkerla.am.freescale.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Scott Wood Cc: Yoder Stuart-B08248 , "" , "kvm@vger.kernel.org list" , "qemu-devel@nongnu.org List" On 14.02.2011, at 22:16, Scott Wood wrote: > On Mon, 14 Feb 2011 21:19:19 +0100 > Alexander Graf wrote: > >> There's no nack here :). The only thing that needs to change is the anonymous part, as that's a gnu extension. Just name the structs and unions and all is well. > > Ah, I thought it was an aesthetic objection -- didn't realize it was a > GNUism. Oh well. Maybe it was some other random extension, but it's certainly less compatible :). > >> The reason I was asking is that I assumed the code would end up being easier, not more complex without the u32s. In fact, it probably would. I'll leave the final decision if you want to access things by entry->u81.split.mas8 or entry->mas8_1 & MAS8_1_MAS8_MASK. > > After sending that, I was thinking that mas7_3 is more naturally used > as a pair, so I'd stick with the u64 there. > > I think mas8_1 benefits less from the pairing, though -- it's only really > useful if you're going to put the value directly in hardware, which we > won't. Sounds good. Make it 2 u32s then :). > >>>> The struct name should also have >>>> a version indicator - it's the data descriptor only a single specific >>>> mmu_type, right? >>> >>> It handles both KVM_MMU_PPC_BOOK3E_NOHV and KVM_MMU_PPC_BOOK3E_HV. >> >> Even fictional future changes to the tlb layout? > > No, those need a new MMU type ID. ... which means they need a new name, but then booke_tlb_entry is taken. > >>>> Please state the size explicitly then. It's 1k, right? >>> >>> It's 4K on Freescale chips. We should probably implement sregs first, in >>> which case qemu can read the MMU config registers to find out the minimum >>> supported page size. >>> >>> If we specify 4K here, we should probably just go ahead and stick FSL in >>> the MMU type name. Specifying the hash itself already makes me nervous >>> about claiming the more generic name. >> >> Yup, sounds good :). > > Which one, "read the MMU config registers" or "specify 4K and stick FSL in > the name"? The "specify 4k and stick fsl in the name" part. If we simply always define it to 4k for all currently supported clients of the interface (e500) we should be good, no? No need for evaluations then. Alex