[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 15:57:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3

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<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?

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/? 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.


reply via email to

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