From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWQWY-0002BP-ST for qemu-devel@nongnu.org; Mon, 21 May 2012 07:11:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWQWT-0004Vm-B6 for qemu-devel@nongnu.org; Mon, 21 May 2012 07:11:38 -0400 Message-ID: <4FBA22DD.7070506@suse.de> Date: Mon, 21 May 2012 13:11:25 +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> In-Reply-To: <4FBA200E.8060201@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 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? > >> 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 :). Alex