From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWQKu-0003uZ-HJ for qemu-devel@nongnu.org; Mon, 21 May 2012 06:59:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWQKs-0001RQ-CD for qemu-devel@nongnu.org; Mon, 21 May 2012 06:59:36 -0400 Message-ID: <4FBA200E.8060201@adacore.com> Date: Mon, 21 May 2012 12:59:26 +0200 From: Fabien Chouteau MIME-Version: 1.0 References: <1336570134-25343-1-git-send-email-chouteau@adacore.com> <4FBA0354.8020107@adacore.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] booke_206_tlbwe: Discard invalid bits in MAS2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "qemu-ppc@nongnu.org" , "qemu-devel@nongnu.org" On 05/21/2012 11:08 AM, Alexander Graf wrote: > > On 21.05.2012, at 10:56, Fabien Chouteau wrote: > >> On 05/20/2012 12:18 PM, Alexander Graf wrote: >>> >>> >>> On 20.05.2012, at 12:15, Alexander Graf wrote: >>> >>>> >>>> >>>> On 09.05.2012, at 15:28, Fabien Chouteau wrote: >>>> >>>>> The size of EPN field in MAS2 depends on page size. This patch adds a >>>>> mask to discard invalid bits in EPN field. >>>>> >>>>> Definition of EPN field from e500v2 RM: >>>>> EPN Effective page number: Depending on page size, only the bits >>>>> associated with a page boundary are valid. Bits that represent offsets >>>>> within a page are ignored and should be cleared. >>>>> >>>>> There is a similar (but more complicated) definition in PowerISA V2.06. >>>>> >>>>> Signed-off-by: Fabien Chouteau >>>>> --- >>>>> target-ppc/op_helper.c | 10 ++++++++-- >>>>> 1 file changed, 8 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c >>>>> index 4ef2332..6bc64ad 100644 >>>>> --- a/target-ppc/op_helper.c >>>>> +++ b/target-ppc/op_helper.c >>>>> @@ -4227,6 +4227,8 @@ void helper_booke206_tlbwe(void) >>>>> uint32_t tlbncfg, tlbn; >>>>> ppcmas_tlb_t *tlb; >>>>> uint32_t size_tlb, size_ps; >>>>> + target_ulong mask; >>>>> + >>>>> >>>>> switch (env->spr[SPR_BOOKE_MAS0] & MAS0_WQ_MASK) { >>>>> case MAS0_WQ_ALWAYS: >>>>> @@ -4289,8 +4291,12 @@ void helper_booke206_tlbwe(void) >>>>> tlb->mas1 |= (tlbncfg & TLBnCFG_MINSIZE) >> 12; >>>>> } >>>>> >>>>> - /* XXX needs to change when supporting 64-bit e500 */ >>>>> - tlb->mas2 = env->spr[SPR_BOOKE_MAS2] & 0xffffffff; >>>>> + /* Make a mask from TLB size to discard invalid bits in EPN field */ >>>>> + mask = ~(booke206_tlb_to_page_size(env, tlb) >>>> >>>> This breaks execution of -cpu with qemu-system-ppc64, no? >>> >>> -cpu e500 I mean of course :). >>> >> >> Maybe but I don't see why... > > Because the effective address might be padded to be negative, rendering lots of f's in the upper 32 bits. Sorry I don't understand, can you provide an example? > Do you maybe have an idea how this works for 64-bit BookE hardware? How does it make sure that a TLB entry only covers the lower 32 bits of the EA when running 32-bit user space? > No I don't know 64-bit BookE hardware. But I don't see why this would be a special case. A 32-bit address would be padded with zeros to get a 64-bit address to compare with EPN. 0x00100000 -> 0x0000000000100000 It's up to the OS to provide a good mapping in a 32-bit process (i.e. use 32-bit EPN). -- Fabien Chouteau