From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWT6q-0004WH-Pv for qemu-devel@nongnu.org; Mon, 21 May 2012 09:57:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWT6l-00037T-5K for qemu-devel@nongnu.org; Mon, 21 May 2012 09:57:16 -0400 Message-ID: <4FBA49B1.9050207@suse.de> Date: Mon, 21 May 2012 15:57:05 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1336570134-25343-1-git-send-email-chouteau@adacore.com> <4FBA0354.8020107@adacore.com> <4FBA200E.8060201@adacore.com> <4FBA22DD.7070506@suse.de> <4FBA475E.3040609@adacore.com> In-Reply-To: <4FBA475E.3040609@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Fabien Chouteau Cc: "qemu-ppc@nongnu.org" , "qemu-devel@nongnu.org" On 05/21/2012 03:47 PM, Fabien Chouteau wrote: > On 05/21/2012 01:11 PM, Alexander Graf wrote: >> On 05/21/2012 12:59 PM, Fabien Chouteau wrote: >>> 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? >> Sure, just try to run your guest kernel with qemu-system-ppc64 and it will break :). >> >> lis r1, 0x8000 >> lwz r2, 0(r1) >> >> With qemu-system-ppc, this will translate to a read at 0x80000000. For qemu-system-ppc64 however, r1 contains 0xffffffff80000000, no? >> > r1 contains 0xffffffff80000000 but the effective address for lwz is > 0x0000000080000000. See below. > >>>> 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). >> Hrm. This is not about the OS, it's about the TLB. Does TLB matching restrict itself to the low 32 bits when not in a 64-bit context? If so, we could add that check and make it work again :). >> >> > OK I have the answer from PowerISA RM: > > 5.7.1 32-Bit Mode > > The computation of the 64-bit effective address is independent of > whether the thread is in 32-bit mode or 64-bit mode. In 32-bit mode > (MSRSF=0), the high-order 32 bits of the 64-bit effective address are > treated as zeros for the purpose of addressing storage. This applies to > both data accesses and instruction fetches. It applies independent of > whether address translation is enabled or disabled. This truncation of > the effective address is the only respect in which storage accesses in > 32-bit mode differ from those in 64-bit mode. This is Book3S, no? Maybe it applies to BookE too with s/SF/CM/? > 6.11.4.8 32-bit and 64-bit Specific MMU Behavior > > MMU behavior is largely unaffected by whether the thread is in 32-bit > computation mode (MSRCM=0) or 64-bit computation mode (MSRCM=1). The > only differences occur in the EPN field of the TLB entry and the EPN > field of MAS2. The differences are summarized here. > > - Executing a tlbwe instruction in 32-bit mode will set bits 0:31 of > the TLB EPN field to zero unless MAS0ATSEL is set, in which case > those bits are not written to zero. Aha! That's the one. We should mask the EA as 32-bit when !MSR_CM. Could you either add that to your patch or add it to another patch? :) The above logic is the reason we have the &= 0xffffffff in the code right now, which your patch removes. Alex