From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpNjH-00056G-6i for qemu-devel@nongnu.org; Mon, 23 Jan 2012 12:30:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpNjF-0001xX-Pc for qemu-devel@nongnu.org; Mon, 23 Jan 2012 12:30:51 -0500 Message-ID: <4F1D9947.2020303@suse.de> Date: Mon, 23 Jan 2012 18:30:47 +0100 From: Alexander Graf MIME-Version: 1.0 References: <4F192141.6030107@suse.de> <1327065698-7538-1-git-send-email-agraf@suse.de> <4F19C82F.60203@freescale.com> <4DD03C47-706E-451F-88E4-52CF12778C5A@suse.de> <4F1D98BE.2000308@freescale.com> In-Reply-To: <4F1D98BE.2000308@freescale.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] PPC: booke206: Check for min/max TLB entry size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Scott Wood Cc: "" , qemu-devel Developers , =?ISO-8859-1?Q?Andreas_F=E4rber?= On 01/23/2012 06:28 PM, Scott Wood wrote: > On 01/20/2012 08:43 PM, Alexander Graf wrote: >> >> Am 20.01.2012 um 21:01 schrieb Scott Wood: >>> I'm not sure what happens when you write >>> an entry to TLB1 with an invalid TSIZE. >> What it says, the ISA means it's implementation dependent. What e500mc actually implements is an different question. Which still needs to be answered. > AFAIK it's not documented what e500mc does for invalid sizes in TLB1, so > I think anything that complies with the architecture's statement of any > supported size is OK. > >> However for now I think wde 're ok by not modeling every odd corner case. > Sure. I was just curious about the architectural statement. > >>>> + /* XXX only applies for MAV 1.0 */ >>>> + size_tlb = (tlb->mas1& MAS1_TSIZE_MASK)>> (MAS1_TSIZE_SHIFT + 1); >>>> + size_min = (tlbncfg& TLBnCFG_MINSIZE)>> TLBnCFG_MINSIZE_SHIFT; >>>> + size_max = (tlbncfg& TLBnCFG_MAXSIZE)>> TLBnCFG_MAXSIZE_SHIFT; >>>> + if ((size_tlb> size_max) || (size_tlb< size_min)) { >>>> + /* set to min size */ >>>> + tlb->mas1&= ~MAS1_TSIZE_MASK; >>>> + tlb->mas1 |= size_min<< (MAS1_TSIZE_SHIFT + 1); >>>> + } >>> You could just implement a bitmap now, which will work for MAV 2.0 as well. >>> >>> Especially since we're using the MAV 2.0 definition of tsize already, so >>> min/max isn't an accurate way to describe what we support. >> Not sure I follow. In MAV 1.0 the size constraints are defined in TLBnCFG, while for MAV 2.0 they are defned in their own bitmap registers (TLBnPS) >> >> Would you like to have a function called that returns a bitmap of >> supported sizes for the TLB depending on its MAV value based on >> either TLBnCFG or TLBnPS? We could then check if that size value bit >> is set. > Yes, use a bitmap internally regardless of how the programming model > says we convey the information to the target code. Already done :). Alex