[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH] booke_206_tlbwe: Discard invalid bit

From: Alexander Graf
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH] booke_206_tlbwe: Discard invalid bits in MAS2
Date: Mon, 21 May 2012 13:11:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3

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<address@hidden>  wrote:

On 09.05.2012, at 15:28, Fabien Chouteau<address@hidden>  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<address@hidden>
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 :).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]