|
From: | Alexander Graf |
Subject: | Re: [Qemu-devel] [Qemu-ppc] [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 :).
Alex
[Prev in Thread] | Current Thread | [Next in Thread] |