From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpNhE-0003ML-MZ for qemu-devel@nongnu.org; Mon, 23 Jan 2012 12:28:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpNh8-0001a9-T7 for qemu-devel@nongnu.org; Mon, 23 Jan 2012 12:28:44 -0500 Message-ID: <4F1D98BE.2000308@freescale.com> Date: Mon, 23 Jan 2012 11:28:30 -0600 From: Scott Wood 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> In-Reply-To: <4DD03C47-706E-451F-88E4-52CF12778C5A@suse.de> Content-Type: text/plain; charset="ISO-8859-1" 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: Alexander Graf Cc: "" , qemu-devel Developers , =?ISO-8859-1?Q?Andreas_F=E4rber?= 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. -Scott