* TCG change broke MorphOS boot on sam460ex @ 2024-02-27 16:47 BALATON Zoltan 2024-02-27 18:15 ` Philippe Mathieu-Daudé 0 siblings, 1 reply; 10+ messages in thread From: BALATON Zoltan @ 2024-02-27 16:47 UTC (permalink / raw) To: qemu-devel; +Cc: qemu-ppc, Richard Henderson, Philippe Mathieu-Daudé Hello, Commit 18a536f1f8 (accel/tcg: Always require can_do_io) broke booting MorphOS on sam460ex (this was before 8.2.0 and I thought I've verified it before that release but apparently missed it back then). It can be reproduced with https://www.morphos-team.net/morphos-3.18.iso and following command: qemu-system-ppc -M sam460ex -serial stdio -d unimp,guest_errors \ -drive if=none,id=cd,format=raw,file=morphos-3.18.iso \ -device ide-cd,drive=cd,bus=ide.1 before: Invalid read at addr 0xC08001216, size 1, region '(null)', reason: rejected Invalid read at addr 0x216, size 1, region '(null)', reason: rejected Invalid read at addr 0x4FDF6BFB0, size 4, region '(null)', reason: rejected Invalid write at addr 0xE10000014, size 4, region '(null)', reason: rejected Invalid write at addr 0xE10000214, size 4, region '(null)', reason: rejected Invalid write at addr 0xE30000014, size 4, region '(null)', reason: rejected Invalid write at addr 0xE30000214, size 4, region '(null)', reason: rejected 8.440| sam460_i2c_write: Error while writing, sts 34 8.463| 8.463| 8.463| ABox 1.30 (2.7.2018)... after: Invalid read at addr 0xC08001216, size 1, region '(null)', reason: rejected Invalid read at addr 0x216, size 1, region '(null)', reason: rejected Invalid read at addr 0x4F0C01374, size 4, region '(null)', reason: rejected invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 00c01374 Invalid read at addr 0x4F0000700, size 4, region '(null)', reason: rejected invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 00000700 Not sure what it's trying to do here, maybe decompressing some code and then trying to execute it? Any idea what could be the problem or what to check further? Regards, BALATON Zoltan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TCG change broke MorphOS boot on sam460ex 2024-02-27 16:47 TCG change broke MorphOS boot on sam460ex BALATON Zoltan @ 2024-02-27 18:15 ` Philippe Mathieu-Daudé 2024-02-27 19:48 ` BALATON Zoltan 2024-03-21 18:41 ` BALATON Zoltan 0 siblings, 2 replies; 10+ messages in thread From: Philippe Mathieu-Daudé @ 2024-02-27 18:15 UTC (permalink / raw) To: BALATON Zoltan, qemu-devel; +Cc: qemu-ppc, Richard Henderson Hi Zoltan, On 27/2/24 17:47, BALATON Zoltan wrote: > Hello, > > Commit 18a536f1f8 (accel/tcg: Always require can_do_io) broke booting > MorphOS on sam460ex (this was before 8.2.0 and I thought I've verified > it before that release but apparently missed it back then). It can be > reproduced with https://www.morphos-team.net/morphos-3.18.iso and > following command: > > qemu-system-ppc -M sam460ex -serial stdio -d unimp,guest_errors \ > -drive if=none,id=cd,format=raw,file=morphos-3.18.iso \ > -device ide-cd,drive=cd,bus=ide.1 > > before: > Invalid read at addr 0xC08001216, size 1, region '(null)', reason: rejected > Invalid read at addr 0x216, size 1, region '(null)', reason: rejected > Invalid read at addr 0x4FDF6BFB0, size 4, region '(null)', reason: rejected > Invalid write at addr 0xE10000014, size 4, region '(null)', reason: > rejected > Invalid write at addr 0xE10000214, size 4, region '(null)', reason: > rejected > Invalid write at addr 0xE30000014, size 4, region '(null)', reason: > rejected > Invalid write at addr 0xE30000214, size 4, region '(null)', reason: > rejected > 8.440| sam460_i2c_write: Error while writing, sts 34 > 8.463| > 8.463| > 8.463| ABox 1.30 (2.7.2018)... > > after: > Invalid read at addr 0xC08001216, size 1, region '(null)', reason: rejected > Invalid read at addr 0x216, size 1, region '(null)', reason: rejected > Invalid read at addr 0x4F0C01374, size 4, region '(null)', reason: rejected > invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 00c01374 > Invalid read at addr 0x4F0000700, size 4, region '(null)', reason: rejected > invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 00000700 > > Not sure what it's trying to do here, maybe decompressing some code and > then trying to execute it? Any idea what could be the problem or what to > check further? Are you testing with commit cf9b5790db ("accel/tcg: Remove CF_LAST_IO") included? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TCG change broke MorphOS boot on sam460ex 2024-02-27 18:15 ` Philippe Mathieu-Daudé @ 2024-02-27 19:48 ` BALATON Zoltan 2024-03-21 18:41 ` BALATON Zoltan 1 sibling, 0 replies; 10+ messages in thread From: BALATON Zoltan @ 2024-02-27 19:48 UTC (permalink / raw) To: Philippe Mathieu-Daudé; +Cc: qemu-devel, qemu-ppc, Richard Henderson [-- Attachment #1: Type: text/plain, Size: 2272 bytes --] On Tue, 27 Feb 2024, Philippe Mathieu-Daudé wrote: > Hi Zoltan, > > On 27/2/24 17:47, BALATON Zoltan wrote: >> Hello, >> >> Commit 18a536f1f8 (accel/tcg: Always require can_do_io) broke booting >> MorphOS on sam460ex (this was before 8.2.0 and I thought I've verified it >> before that release but apparently missed it back then). It can be >> reproduced with https://www.morphos-team.net/morphos-3.18.iso and following >> command: >> >> qemu-system-ppc -M sam460ex -serial stdio -d unimp,guest_errors \ >> -drive if=none,id=cd,format=raw,file=morphos-3.18.iso \ >> -device ide-cd,drive=cd,bus=ide.1 >> >> before: >> Invalid read at addr 0xC08001216, size 1, region '(null)', reason: rejected >> Invalid read at addr 0x216, size 1, region '(null)', reason: rejected >> Invalid read at addr 0x4FDF6BFB0, size 4, region '(null)', reason: rejected >> Invalid write at addr 0xE10000014, size 4, region '(null)', reason: >> rejected >> Invalid write at addr 0xE10000214, size 4, region '(null)', reason: >> rejected >> Invalid write at addr 0xE30000014, size 4, region '(null)', reason: >> rejected >> Invalid write at addr 0xE30000214, size 4, region '(null)', reason: >> rejected >> 8.440| sam460_i2c_write: Error while writing, sts 34 >> 8.463| >> 8.463| >> 8.463| ABox 1.30 (2.7.2018)... >> >> after: >> Invalid read at addr 0xC08001216, size 1, region '(null)', reason: rejected >> Invalid read at addr 0x216, size 1, region '(null)', reason: rejected >> Invalid read at addr 0x4F0C01374, size 4, region '(null)', reason: rejected >> invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 00c01374 >> Invalid read at addr 0x4F0000700, size 4, region '(null)', reason: rejected >> invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 00000700 >> >> Not sure what it's trying to do here, maybe decompressing some code and >> then trying to execute it? Any idea what could be the problem or what to >> check further? > > Are you testing with commit cf9b5790db ("accel/tcg: Remove CF_LAST_IO") > included? The issue happens starting with commit 18a536f1f8 and present even in current master. The commit before it (200c1f904f accel/tcg: Always set CF_LAST_IO with CF_NOIRQ) still works. Commit cf9b5790db does not work. Regards, BALATON Zoltan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TCG change broke MorphOS boot on sam460ex 2024-02-27 18:15 ` Philippe Mathieu-Daudé 2024-02-27 19:48 ` BALATON Zoltan @ 2024-03-21 18:41 ` BALATON Zoltan 2024-04-02 11:32 ` BALATON Zoltan 1 sibling, 1 reply; 10+ messages in thread From: BALATON Zoltan @ 2024-03-21 18:41 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: qemu-devel, qemu-ppc, Nicholas Piggin, Richard Henderson [-- Attachment #1: Type: text/plain, Size: 7251 bytes --] On 27/2/24 17:47, BALATON Zoltan wrote: > Hello, > > Commit 18a536f1f8 (accel/tcg: Always require can_do_io) broke booting > MorphOS on sam460ex (this was before 8.2.0 and I thought I've verified > it before that release but apparently missed it back then). It can be > reproduced with https://www.morphos-team.net/morphos-3.18.iso and > following command: > > qemu-system-ppc -M sam460ex -serial stdio -d unimp,guest_errors \ > -drive if=none,id=cd,format=raw,file=morphos-3.18.iso \ > -device ide-cd,drive=cd,bus=ide.1 Although it breaks at the TCG change it may also be related to tlbwe changes somehow but I don't really understand it. I've tried to get some more debug info in case somebody can tell what's happening. With 18a536f1f8^ (the commit before the one it broke at and still works) I get: ---------------- IN: ppcemb_tlb_check: TLB 0 address 00c01000 PID 0 <=> f0000000 f0000000 0 7f mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 1 address 00c01000 PID 0 <=> d0000000 f0000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 2 address 00c01000 PID 0 <=> 80000000 f0000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 3 address 00c01000 PID 0 <=> 90000000 f0000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 4 address 00c01000 PID 0 <=> a0000000 f0000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 5 address 00c01000 PID 0 <=> b0000000 f0000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 6 address 00c01000 PID 0 <=> c0000000 f0000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 7 address 00c01000 PID 0 <=> e0000000 ff000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 8 address 00c01000 PID 0 <=> e1000000 ff000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 9 address 00c01000 PID 0 <=> e3000000 fffffc00 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 10 address 00c01000 PID 0 <=> e3001000 fffffc00 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 11 address 00c01000 PID 0 <=> e4000000 ffffc000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 12 address 00c01000 PID 0 <=> e5000000 fff00000 0 7f mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 13 address 00c01000 PID 0 <=> ef000000 ff000000 0 7f mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 14 address 00c01000 PID 0 <=> e2000000 fff00000 0 7f mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 15 address 00c01000 PID 0 <=> 00000000 f0000000 0 7f mmubooke_check_tlb: good TLB! mmubooke_get_physical_address: access granted 00c01000 => 0000000000c01000 7 0 0x00c01354: 38c00040 li r6, 0x40 0x00c01358: 38e10204 addi r7, r1, 0x204 0x00c0135c: 39010104 addi r8, r1, 0x104 0x00c01360: 39410004 addi r10, r1, 4 0x00c01364: 39200000 li r9, 0 0x00c01368: 7cc903a6 mtctr r6 0x00c0136c: 84c70004 lwzu r6, 4(r7) 0x00c01370: 7cc907a4 tlbwehi r6, r9 0x00c01374: 84c80004 lwzu r6, 4(r8) 0x00c01378: 7cc90fa4 tlbwelo r6, r9 0x00c0137c: 84ca0004 lwzu r6, 4(r10) 0x00c01380: 7cc917a4 tlbwehi r6, r9 0x00c01384: 39290001 addi r9, r9, 1 0x00c01388: 4200ffe4 bdnz 0xc0136c helper_440_tlbwe word 0 entry 0 value 00000290 ppcemb_tlb_check: TLB 0 address 0df6bfb0 PID 0 <=> 00000000 f0000000 0 7f mmubooke_check_tlb: good TLB! mmubooke_get_physical_address: access granted 0df6bfb0 => 00000004fdf6bfb0 7 0 Invalid read at addr 0x4FDF6BFB0, size 4, region '(null)', reason: rejected helper_440_tlbwe word 1 entry 0 value 00000000 ppcemb_tlb_check: TLB 0 address 0df6beb0 PID 0 <=> 00000000 f0000000 0 7f mmubooke_check_tlb: good TLB! mmubooke_get_physical_address: access granted 0df6beb0 => 000000000df6beb0 7 0 helper_440_tlbwe word 2 entry 0 value 0000003f ppcemb_tlb_check: TLB 0 address 00c0136c PID 0 <=> 00000000 f0000000 0 7f mmubooke_check_tlb: good TLB! mmubooke_get_physical_address: access granted 00c0136c => 0000000000c0136c 7 0 ---------------- and with commit 18a536f1f8 this changes to ---------------- IN: ppcemb_tlb_check: TLB 0 address 00c01000 PID 0 <=> f0000000 f0000000 0 7f mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 1 address 00c01000 PID 0 <=> d0000000 f0000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 2 address 00c01000 PID 0 <=> 80000000 f0000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 3 address 00c01000 PID 0 <=> 90000000 f0000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 4 address 00c01000 PID 0 <=> a0000000 f0000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 5 address 00c01000 PID 0 <=> b0000000 f0000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 6 address 00c01000 PID 0 <=> c0000000 f0000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 7 address 00c01000 PID 0 <=> e0000000 ff000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 8 address 00c01000 PID 0 <=> e1000000 ff000000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 9 address 00c01000 PID 0 <=> e3000000 fffffc00 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 10 address 00c01000 PID 0 <=> e3001000 fffffc00 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 11 address 00c01000 PID 0 <=> e4000000 ffffc000 0 3b mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 12 address 00c01000 PID 0 <=> e5000000 fff00000 0 7f mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 13 address 00c01000 PID 0 <=> ef000000 ff000000 0 7f mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 14 address 00c01000 PID 0 <=> e2000000 fff00000 0 7f mmubooke_check_tlb: TLB entry not found ppcemb_tlb_check: TLB 15 address 00c01000 PID 0 <=> 00000000 f0000000 0 7f mmubooke_check_tlb: good TLB! mmubooke_get_physical_address: access granted 00c01000 => 0000000000c01000 7 0 0x00c01354: 38c00040 li r6, 0x40 0x00c01358: 38e10204 addi r7, r1, 0x204 0x00c0135c: 39010104 addi r8, r1, 0x104 0x00c01360: 39410004 addi r10, r1, 4 0x00c01364: 39200000 li r9, 0 0x00c01368: 7cc903a6 mtctr r6 0x00c0136c: 84c70004 lwzu r6, 4(r7) 0x00c01370: 7cc907a4 tlbwehi r6, r9 0x00c01374: 84c80004 lwzu r6, 4(r8) 0x00c01378: 7cc90fa4 tlbwelo r6, r9 0x00c0137c: 84ca0004 lwzu r6, 4(r10) 0x00c01380: 7cc917a4 tlbwehi r6, r9 0x00c01384: 39290001 addi r9, r9, 1 0x00c01388: 4200ffe4 bdnz 0xc0136c helper_440_tlbwe word 0 entry 0 value 00000290 ppcemb_tlb_check: TLB 0 address 0df6bfb0 PID 0 <=> 00000000 f0000000 0 7f mmubooke_check_tlb: good TLB! mmubooke_get_physical_address: access granted 0df6bfb0 => 00000004fdf6bfb0 7 0 ppcemb_tlb_check: TLB 0 address 00c01374 PID 0 <=> 00000000 f0000000 0 7f mmubooke_check_tlb: good TLB! mmubooke_get_physical_address: access granted 00c01374 => 00000004f0c01374 7 0 Invalid read at addr 0x4F0C01374, size 4, region '(null)', reason: rejected invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 00c01374 ---------------- Any idea? Regards, BALATON Zoltan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TCG change broke MorphOS boot on sam460ex 2024-03-21 18:41 ` BALATON Zoltan @ 2024-04-02 11:32 ` BALATON Zoltan 2024-04-03 5:15 ` Nicholas Piggin 0 siblings, 1 reply; 10+ messages in thread From: BALATON Zoltan @ 2024-04-02 11:32 UTC (permalink / raw) To: qemu-devel; +Cc: qemu-ppc, Nicholas Piggin, Richard Henderson [-- Attachment #1: Type: text/plain, Size: 7978 bytes --] On Thu, 21 Mar 2024, BALATON Zoltan wrote: > On 27/2/24 17:47, BALATON Zoltan wrote: >> Hello, >> >> Commit 18a536f1f8 (accel/tcg: Always require can_do_io) broke booting >> MorphOS on sam460ex (this was before 8.2.0 and I thought I've verified it >> before that release but apparently missed it back then). It can be >> reproduced with https://www.morphos-team.net/morphos-3.18.iso and following >> command: >> >> qemu-system-ppc -M sam460ex -serial stdio -d unimp,guest_errors \ >> -drive if=none,id=cd,format=raw,file=morphos-3.18.iso \ >> -device ide-cd,drive=cd,bus=ide.1 Any idea on this one? While MorphOS boots on other machines and other OSes seem to boot on this machine it may still suggest there's some problem somewhere as this worked before. So it may worth investigating it to make sure there's no bug that could affect other OSes too even if they boot. I don't know how to debug this so some help would be needed. Regards, BALATON Zoltan > Although it breaks at the TCG change it may also be related to tlbwe changes > somehow but I don't really understand it. I've tried to get some more debug > info in case somebody can tell what's happening. With 18a536f1f8^ (the commit > before the one it broke at and still works) I get: > > ---------------- > IN: > ppcemb_tlb_check: TLB 0 address 00c01000 PID 0 <=> f0000000 f0000000 0 7f > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 1 address 00c01000 PID 0 <=> d0000000 f0000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 2 address 00c01000 PID 0 <=> 80000000 f0000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 3 address 00c01000 PID 0 <=> 90000000 f0000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 4 address 00c01000 PID 0 <=> a0000000 f0000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 5 address 00c01000 PID 0 <=> b0000000 f0000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 6 address 00c01000 PID 0 <=> c0000000 f0000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 7 address 00c01000 PID 0 <=> e0000000 ff000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 8 address 00c01000 PID 0 <=> e1000000 ff000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 9 address 00c01000 PID 0 <=> e3000000 fffffc00 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 10 address 00c01000 PID 0 <=> e3001000 fffffc00 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 11 address 00c01000 PID 0 <=> e4000000 ffffc000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 12 address 00c01000 PID 0 <=> e5000000 fff00000 0 7f > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 13 address 00c01000 PID 0 <=> ef000000 ff000000 0 7f > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 14 address 00c01000 PID 0 <=> e2000000 fff00000 0 7f > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 15 address 00c01000 PID 0 <=> 00000000 f0000000 0 7f > mmubooke_check_tlb: good TLB! > mmubooke_get_physical_address: access granted 00c01000 => 0000000000c01000 7 > 0 > 0x00c01354: 38c00040 li r6, 0x40 > 0x00c01358: 38e10204 addi r7, r1, 0x204 > 0x00c0135c: 39010104 addi r8, r1, 0x104 > 0x00c01360: 39410004 addi r10, r1, 4 > 0x00c01364: 39200000 li r9, 0 > 0x00c01368: 7cc903a6 mtctr r6 > 0x00c0136c: 84c70004 lwzu r6, 4(r7) > 0x00c01370: 7cc907a4 tlbwehi r6, r9 > 0x00c01374: 84c80004 lwzu r6, 4(r8) > 0x00c01378: 7cc90fa4 tlbwelo r6, r9 > 0x00c0137c: 84ca0004 lwzu r6, 4(r10) > 0x00c01380: 7cc917a4 tlbwehi r6, r9 > 0x00c01384: 39290001 addi r9, r9, 1 > 0x00c01388: 4200ffe4 bdnz 0xc0136c > > helper_440_tlbwe word 0 entry 0 value 00000290 > ppcemb_tlb_check: TLB 0 address 0df6bfb0 PID 0 <=> 00000000 f0000000 0 7f > mmubooke_check_tlb: good TLB! > mmubooke_get_physical_address: access granted 0df6bfb0 => 00000004fdf6bfb0 7 > 0 > Invalid read at addr 0x4FDF6BFB0, size 4, region '(null)', reason: rejected > helper_440_tlbwe word 1 entry 0 value 00000000 > ppcemb_tlb_check: TLB 0 address 0df6beb0 PID 0 <=> 00000000 f0000000 0 7f > mmubooke_check_tlb: good TLB! > mmubooke_get_physical_address: access granted 0df6beb0 => 000000000df6beb0 7 > 0 > helper_440_tlbwe word 2 entry 0 value 0000003f > ppcemb_tlb_check: TLB 0 address 00c0136c PID 0 <=> 00000000 f0000000 0 7f > mmubooke_check_tlb: good TLB! > mmubooke_get_physical_address: access granted 00c0136c => 0000000000c0136c 7 > 0 > ---------------- > > and with commit 18a536f1f8 this changes to > > ---------------- > IN: > ppcemb_tlb_check: TLB 0 address 00c01000 PID 0 <=> f0000000 f0000000 0 7f > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 1 address 00c01000 PID 0 <=> d0000000 f0000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 2 address 00c01000 PID 0 <=> 80000000 f0000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 3 address 00c01000 PID 0 <=> 90000000 f0000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 4 address 00c01000 PID 0 <=> a0000000 f0000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 5 address 00c01000 PID 0 <=> b0000000 f0000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 6 address 00c01000 PID 0 <=> c0000000 f0000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 7 address 00c01000 PID 0 <=> e0000000 ff000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 8 address 00c01000 PID 0 <=> e1000000 ff000000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 9 address 00c01000 PID 0 <=> e3000000 fffffc00 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 10 address 00c01000 PID 0 <=> e3001000 fffffc00 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 11 address 00c01000 PID 0 <=> e4000000 ffffc000 0 3b > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 12 address 00c01000 PID 0 <=> e5000000 fff00000 0 7f > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 13 address 00c01000 PID 0 <=> ef000000 ff000000 0 7f > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 14 address 00c01000 PID 0 <=> e2000000 fff00000 0 7f > mmubooke_check_tlb: TLB entry not found > ppcemb_tlb_check: TLB 15 address 00c01000 PID 0 <=> 00000000 f0000000 0 7f > mmubooke_check_tlb: good TLB! > mmubooke_get_physical_address: access granted 00c01000 => 0000000000c01000 7 > 0 > 0x00c01354: 38c00040 li r6, 0x40 > 0x00c01358: 38e10204 addi r7, r1, 0x204 > 0x00c0135c: 39010104 addi r8, r1, 0x104 > 0x00c01360: 39410004 addi r10, r1, 4 > 0x00c01364: 39200000 li r9, 0 > 0x00c01368: 7cc903a6 mtctr r6 > 0x00c0136c: 84c70004 lwzu r6, 4(r7) > 0x00c01370: 7cc907a4 tlbwehi r6, r9 > 0x00c01374: 84c80004 lwzu r6, 4(r8) > 0x00c01378: 7cc90fa4 tlbwelo r6, r9 > 0x00c0137c: 84ca0004 lwzu r6, 4(r10) > 0x00c01380: 7cc917a4 tlbwehi r6, r9 > 0x00c01384: 39290001 addi r9, r9, 1 > 0x00c01388: 4200ffe4 bdnz 0xc0136c > > helper_440_tlbwe word 0 entry 0 value 00000290 > ppcemb_tlb_check: TLB 0 address 0df6bfb0 PID 0 <=> 00000000 f0000000 0 7f > mmubooke_check_tlb: good TLB! > mmubooke_get_physical_address: access granted 0df6bfb0 => 00000004fdf6bfb0 7 > 0 > ppcemb_tlb_check: TLB 0 address 00c01374 PID 0 <=> 00000000 f0000000 0 7f > mmubooke_check_tlb: good TLB! > mmubooke_get_physical_address: access granted 00c01374 => 00000004f0c01374 7 > 0 > Invalid read at addr 0x4F0C01374, size 4, region '(null)', reason: rejected > invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 00c01374 > ---------------- > > Any idea? > > Regards, > BALATON Zoltan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TCG change broke MorphOS boot on sam460ex 2024-04-02 11:32 ` BALATON Zoltan @ 2024-04-03 5:15 ` Nicholas Piggin 2024-04-03 22:23 ` BALATON Zoltan 2024-05-27 22:23 ` BALATON Zoltan 0 siblings, 2 replies; 10+ messages in thread From: Nicholas Piggin @ 2024-04-03 5:15 UTC (permalink / raw) To: BALATON Zoltan, qemu-devel; +Cc: qemu-ppc, Richard Henderson On Tue Apr 2, 2024 at 9:32 PM AEST, BALATON Zoltan wrote: > On Thu, 21 Mar 2024, BALATON Zoltan wrote: > > On 27/2/24 17:47, BALATON Zoltan wrote: > >> Hello, > >> > >> Commit 18a536f1f8 (accel/tcg: Always require can_do_io) broke booting > >> MorphOS on sam460ex (this was before 8.2.0 and I thought I've verified it > >> before that release but apparently missed it back then). It can be > >> reproduced with https://www.morphos-team.net/morphos-3.18.iso and following > >> command: > >> > >> qemu-system-ppc -M sam460ex -serial stdio -d unimp,guest_errors \ > >> -drive if=none,id=cd,format=raw,file=morphos-3.18.iso \ > >> -device ide-cd,drive=cd,bus=ide.1 > > Any idea on this one? While MorphOS boots on other machines and other OSes > seem to boot on this machine it may still suggest there's some problem > somewhere as this worked before. So it may worth investigating it to make > sure there's no bug that could affect other OSes too even if they boot. I > don't know how to debug this so some help would be needed. In the bad case it crashes after running this TB: ---------------- IN: 0x00c01354: 38c00040 li r6, 0x40 0x00c01358: 38e10204 addi r7, r1, 0x204 0x00c0135c: 39010104 addi r8, r1, 0x104 0x00c01360: 39410004 addi r10, r1, 4 0x00c01364: 39200000 li r9, 0 0x00c01368: 7cc903a6 mtctr r6 0x00c0136c: 84c70004 lwzu r6, 4(r7) 0x00c01370: 7cc907a4 tlbwehi r6, r9 0x00c01374: 84c80004 lwzu r6, 4(r8) 0x00c01378: 7cc90fa4 tlbwelo r6, r9 0x00c0137c: 84ca0004 lwzu r6, 4(r10) 0x00c01380: 7cc917a4 tlbwehi r6, r9 0x00c01384: 39290001 addi r9, r9, 1 0x00c01388: 4200ffe4 bdnz 0xc0136c ---------------- IN: 0x00c01374: unable to read memory ---------------- "unable to read memory" is the tracer, it does actually translate the address, but it points to a wayward real address which returns 0 to TCG, which is an invalid instruction. The good case instead doesn't exit the TB after 0x00c01370 but after the complete loop at the bdnz. That look like this after the same first TB: ---------------- IN: 0x00c0136c: 84c70004 lwzu r6, 4(r7) 0x00c01370: 7cc907a4 tlbwehi r6, r9 0x00c01374: 84c80004 lwzu r6, 4(r8) 0x00c01378: 7cc90fa4 tlbwelo r6, r9 0x00c0137c: 84ca0004 lwzu r6, 4(r10) 0x00c01380: 7cc917a4 tlbwehi r6, r9 0x00c01384: 39290001 addi r9, r9, 1 0x00c01388: 4200ffe4 bdnz 0xc0136c ---------------- IN: 0x00c0138c: 4c00012c isync All the tlbwe are executed in the same TB. MMU tracing shows the first tlbwehi creates a new valid(!) TLB for 0x00000000-0x100000000 that has a garbage RPN because the tlbwelo did not run yet. What's happening in the bad case is that the translator breaks and "re-fetches" instructions in the middle of that sequence, and that's where the bogus translation causes 0 to be returned. The good case the whole block is executed in the same fetch which creates correct translations. So it looks like a morphos bug, the can-do-io change just happens to cause it to re-fetch in that place, but that could happen for a number of reasons, so you can't rely on TLB *only* changing or ifetch *only* re-fetching at a sync point like isync. I would expect code like this to write an invalid entry with tlbwehi, then tlbwelo to set the correct RPN, then make the entry valid with the second tlbwehi. It would probably fix the bug if you just did the first tlbwehi with r6=0 (or at least without the 0x200 bit set). Thanks, Nick ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TCG change broke MorphOS boot on sam460ex 2024-04-03 5:15 ` Nicholas Piggin @ 2024-04-03 22:23 ` BALATON Zoltan 2024-05-27 22:23 ` BALATON Zoltan 1 sibling, 0 replies; 10+ messages in thread From: BALATON Zoltan @ 2024-04-03 22:23 UTC (permalink / raw) To: Nicholas Piggin; +Cc: qemu-devel, qemu-ppc, Richard Henderson [-- Attachment #1: Type: text/plain, Size: 4362 bytes --] On Wed, 3 Apr 2024, Nicholas Piggin wrote: > On Tue Apr 2, 2024 at 9:32 PM AEST, BALATON Zoltan wrote: >> On Thu, 21 Mar 2024, BALATON Zoltan wrote: >>> On 27/2/24 17:47, BALATON Zoltan wrote: >>>> Hello, >>>> >>>> Commit 18a536f1f8 (accel/tcg: Always require can_do_io) broke booting >>>> MorphOS on sam460ex (this was before 8.2.0 and I thought I've verified it >>>> before that release but apparently missed it back then). It can be >>>> reproduced with https://www.morphos-team.net/morphos-3.18.iso and following >>>> command: >>>> >>>> qemu-system-ppc -M sam460ex -serial stdio -d unimp,guest_errors \ >>>> -drive if=none,id=cd,format=raw,file=morphos-3.18.iso \ >>>> -device ide-cd,drive=cd,bus=ide.1 >> >> Any idea on this one? While MorphOS boots on other machines and other OSes >> seem to boot on this machine it may still suggest there's some problem >> somewhere as this worked before. So it may worth investigating it to make >> sure there's no bug that could affect other OSes too even if they boot. I >> don't know how to debug this so some help would be needed. > > In the bad case it crashes after running this TB: > > ---------------- > IN: > 0x00c01354: 38c00040 li r6, 0x40 > 0x00c01358: 38e10204 addi r7, r1, 0x204 > 0x00c0135c: 39010104 addi r8, r1, 0x104 > 0x00c01360: 39410004 addi r10, r1, 4 > 0x00c01364: 39200000 li r9, 0 > 0x00c01368: 7cc903a6 mtctr r6 > 0x00c0136c: 84c70004 lwzu r6, 4(r7) > 0x00c01370: 7cc907a4 tlbwehi r6, r9 > 0x00c01374: 84c80004 lwzu r6, 4(r8) > 0x00c01378: 7cc90fa4 tlbwelo r6, r9 > 0x00c0137c: 84ca0004 lwzu r6, 4(r10) > 0x00c01380: 7cc917a4 tlbwehi r6, r9 > 0x00c01384: 39290001 addi r9, r9, 1 > 0x00c01388: 4200ffe4 bdnz 0xc0136c > ---------------- > IN: > 0x00c01374: unable to read memory > ---------------- > > "unable to read memory" is the tracer, it does actually translate > the address, but it points to a wayward real address which returns > 0 to TCG, which is an invalid instruction. > > The good case instead doesn't exit the TB after 0x00c01370 but after > the complete loop at the bdnz. That look like this after the same > first TB: > > ---------------- > IN: > 0x00c0136c: 84c70004 lwzu r6, 4(r7) > 0x00c01370: 7cc907a4 tlbwehi r6, r9 > 0x00c01374: 84c80004 lwzu r6, 4(r8) > 0x00c01378: 7cc90fa4 tlbwelo r6, r9 > 0x00c0137c: 84ca0004 lwzu r6, 4(r10) > 0x00c01380: 7cc917a4 tlbwehi r6, r9 > 0x00c01384: 39290001 addi r9, r9, 1 > 0x00c01388: 4200ffe4 bdnz 0xc0136c > ---------------- > IN: > 0x00c0138c: 4c00012c isync > > All the tlbwe are executed in the same TB. MMU tracing shows the > first tlbwehi creates a new valid(!) TLB for 0x00000000-0x100000000 > that has a garbage RPN because the tlbwelo did not run yet. > > What's happening in the bad case is that the translator breaks > and "re-fetches" instructions in the middle of that sequence, and > that's where the bogus translation causes 0 to be returned. The > good case the whole block is executed in the same fetch which > creates correct translations. > > So it looks like a morphos bug, the can-do-io change just happens > to cause it to re-fetch in that place, but that could happen for > a number of reasons, so you can't rely on TLB *only* changing or > ifetch *only* re-fetching at a sync point like isync. Thanks a lot for the analysis. Probably ir works on real machine due to cache effects so maybe it was just luck this did not break. > I would expect code like this to write an invalid entry with tlbwehi, > then tlbwelo to set the correct RPN, then make the entry valid with > the second tlbwehi. It would probably fix the bug if you just did the > first tlbwehi with r6=0 (or at least without the 0x200 bit set). I think I had to fix a similar issue in AROS years ago when I've first tried to make sam460ex emulation work and used AROS for testing: https://github.com/aros-development-team/AROS/commit/586a8ada8a5b861a77cab177d39e01de8c3f4cf5 I can't fix MorphOS as it's not open source but hope MorphOS people will get to know about this and do something with it. It still works better on other emulated machines such as pegasos2 and mac99 so it's not a big deal, just wanted to make sure it would not be a bug that could affect other OSes on sam460ex. Thank you, BALATON Zoltan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TCG change broke MorphOS boot on sam460ex 2024-04-03 5:15 ` Nicholas Piggin 2024-04-03 22:23 ` BALATON Zoltan @ 2024-05-27 22:23 ` BALATON Zoltan 2024-05-27 22:55 ` BALATON Zoltan 2024-05-28 3:30 ` Nicholas Piggin 1 sibling, 2 replies; 10+ messages in thread From: BALATON Zoltan @ 2024-05-27 22:23 UTC (permalink / raw) To: Nicholas Piggin; +Cc: qemu-devel, qemu-ppc, Richard Henderson [-- Attachment #1: Type: text/plain, Size: 12668 bytes --] On Wed, 3 Apr 2024, Nicholas Piggin wrote: > On Tue Apr 2, 2024 at 9:32 PM AEST, BALATON Zoltan wrote: >> On Thu, 21 Mar 2024, BALATON Zoltan wrote: >>> On 27/2/24 17:47, BALATON Zoltan wrote: >>>> Hello, >>>> >>>> Commit 18a536f1f8 (accel/tcg: Always require can_do_io) broke booting >>>> MorphOS on sam460ex (this was before 8.2.0 and I thought I've verified it >>>> before that release but apparently missed it back then). It can be >>>> reproduced with https://www.morphos-team.net/morphos-3.18.iso and following >>>> command: >>>> >>>> qemu-system-ppc -M sam460ex -serial stdio -d unimp,guest_errors \ >>>> -drive if=none,id=cd,format=raw,file=morphos-3.18.iso \ >>>> -device ide-cd,drive=cd,bus=ide.1 >> >> Any idea on this one? While MorphOS boots on other machines and other OSes >> seem to boot on this machine it may still suggest there's some problem >> somewhere as this worked before. So it may worth investigating it to make >> sure there's no bug that could affect other OSes too even if they boot. I >> don't know how to debug this so some help would be needed. > > In the bad case it crashes after running this TB: > > ---------------- > IN: > 0x00c01354: 38c00040 li r6, 0x40 > 0x00c01358: 38e10204 addi r7, r1, 0x204 > 0x00c0135c: 39010104 addi r8, r1, 0x104 > 0x00c01360: 39410004 addi r10, r1, 4 > 0x00c01364: 39200000 li r9, 0 > 0x00c01368: 7cc903a6 mtctr r6 > 0x00c0136c: 84c70004 lwzu r6, 4(r7) > 0x00c01370: 7cc907a4 tlbwehi r6, r9 > 0x00c01374: 84c80004 lwzu r6, 4(r8) > 0x00c01378: 7cc90fa4 tlbwelo r6, r9 > 0x00c0137c: 84ca0004 lwzu r6, 4(r10) > 0x00c01380: 7cc917a4 tlbwehi r6, r9 > 0x00c01384: 39290001 addi r9, r9, 1 > 0x00c01388: 4200ffe4 bdnz 0xc0136c > ---------------- > IN: > 0x00c01374: unable to read memory > ---------------- > > "unable to read memory" is the tracer, it does actually translate > the address, but it points to a wayward real address which returns > 0 to TCG, which is an invalid instruction. > > The good case instead doesn't exit the TB after 0x00c01370 but after > the complete loop at the bdnz. That look like this after the same > first TB: > > ---------------- > IN: > 0x00c0136c: 84c70004 lwzu r6, 4(r7) > 0x00c01370: 7cc907a4 tlbwehi r6, r9 > 0x00c01374: 84c80004 lwzu r6, 4(r8) > 0x00c01378: 7cc90fa4 tlbwelo r6, r9 > 0x00c0137c: 84ca0004 lwzu r6, 4(r10) > 0x00c01380: 7cc917a4 tlbwehi r6, r9 > 0x00c01384: 39290001 addi r9, r9, 1 > 0x00c01388: 4200ffe4 bdnz 0xc0136c > ---------------- > IN: > 0x00c0138c: 4c00012c isync > > All the tlbwe are executed in the same TB. MMU tracing shows the > first tlbwehi creates a new valid(!) TLB for 0x00000000-0x100000000 > that has a garbage RPN because the tlbwelo did not run yet. > > What's happening in the bad case is that the translator breaks > and "re-fetches" instructions in the middle of that sequence, and > that's where the bogus translation causes 0 to be returned. The > good case the whole block is executed in the same fetch which > creates correct translations. > > So it looks like a morphos bug, the can-do-io change just happens > to cause it to re-fetch in that place, but that could happen for > a number of reasons, so you can't rely on TLB *only* changing or > ifetch *only* re-fetching at a sync point like isync. > > I would expect code like this to write an invalid entry with tlbwehi, > then tlbwelo to set the correct RPN, then make the entry valid with > the second tlbwehi. It would probably fix the bug if you just did the > first tlbwehi with r6=0 (or at least without the 0x200 bit set). Revisiting this, I've found in the docs that PPC440 has shadow TLBs so this code can rely upon the TLB not being invalidated until isync and works on real machine but breaks on QEMU. We would either need to make sure the TB runs until the sync or somehow emulate the shadow TLB. I've experimented with the latter but I could not make it work (and unexpectedly keeping a cache of the most recently used entries is slower than always searching through all TLB entries as done now so I've abandoned that idea). The problem is that an entry is modified by multiple tlbwe instructions but these can come in any order (and sometimes only one of them is done like invalidating an entry seems to only do one write) so I don't know when to copy the new entry to the TLB and when to wait for more parts and keep the old one. Any idea how to fix this? Also I'm not sure if it's related but by running the stream benchmark on sam460ex now I can reproduce some memory access problem but I'm not sure what causes it. The full output of that benchmark under AmigaOS on sam460ex is this: ------------------------------------------------------------- STREAM version $Revision: 5.10 $ ------------------------------------------------------------- This system uses 8 bytes per array element. ------------------------------------------------------------- Array size = 10000000 (elements), Offset = 0 (elements) Memory per array = 76.3 MiB (= 0.1 GiB). Total memory required = 228.9 MiB (= 0.2 GiB). Each kernel will be executed 10 times. The *best* time for each kernel (excluding the first iteration) will be used to compute the reported bandwidth. ------------------------------------------------------------- Your clock granularity/precision appears to be 3 microseconds. Each test below will take on the order of 186279 microseconds. (= 62093 clock ticks) Increase the size of the arrays if this shows that you are not getting at least 20 clock ticks per test. ------------------------------------------------------------- WARNING -- The above is only a rough guideline. For best results, please be sure you know the precision of your system timer. ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 1723.8 0.095517 0.092821 0.103645 Scale: 790.2 0.206338 0.202479 0.214062 Add: 994.7 0.246171 0.241289 0.256950 Triad: 763.2 0.323731 0.314454 0.343873 ------------------------------------------------------------- Failed Validation on array a[], AvgRelAbsErr > epsilon (1.000000e-13) Expected Value: 1.153301e+12, AvgAbsErr: 1.137394e+12, AvgRelAbsErr: 9.862079e-01 For array a[], 9863168 errors were found. Failed Validation on array b[], AvgRelAbsErr > epsilon (1.000000e-13) Expected Value: 2.306602e+11, AvgAbsErr: 2.274872e+11, AvgRelAbsErr: 9.862438e-01 AvgRelAbsErr > Epsilon (1.000000e-13) For array b[], 9863168 errors were found. Failed Validation on array c[], AvgRelAbsErr > epsilon (1.000000e-13) Expected Value: 3.075469e+11, AvgAbsErr: 3.033024e+11, AvgRelAbsErr: 9.861989e-01 AvgRelAbsErr > Epsilon (1.000000e-13) For array c[], 9863168 errors were found. ------------------------------------------------------------- while on amigaone or pegasos2 the same executable finishes with: ------------------------------------------------------------- Solution Validates: avg error less than 1.000000e-13 on all three arrays ------------------------------------------------------------- On a real Sam460EX this same executable also validates as confirmed here: https://www.amigans.net/modules/newbb/viewtopic.php?post_id=148020#forumpost148020 The binary and source is from here: http://os4depot.net/?function=showfile&file=utility/benchmark/stream.lha This binary runs on QEMU amigaone and pegasos2 that use G4 and validates so only seems to be a problem with 460EX. I've compiled the source for PPC Linux and tried running that with qemu-ppc linux-user to verify it which does not use MMU so it's expected to work and it does: $ qemu-ppc -cpu 460ex streamPPC ------------------------------------------------------------- Based on STREAM version $Revision: 5.10 $ ------------------------------------------------------------- This system uses 8 bytes per array element. ------------------------------------------------------------- Array size = 10000000 (elements), Offset = 0 (elements) Memory per array = 76.3 MiB (= 0.1 GiB). Total memory required = 228.9 MiB (= 0.2 GiB). Each kernel will be executed 10 times. The *best* time for each kernel (excluding the first iteration) will be used to compute the reported bandwidth. ------------------------------------------------------------- Your clock granularity/precision appears to be 1 microseconds. Each test below will take on the order of 192649 microseconds. (= 192649 clock ticks) Increase the size of the arrays if this shows that you are not getting at least 20 clock ticks per test. ------------------------------------------------------------- WARNING -- The above is only a rough guideline. For best results, please be sure you know the precision of your system timer. ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 3191.5 0.050227 0.050133 0.050584 Scale: 889.5 0.181873 0.179880 0.183075 Add: 1174.7 0.207856 0.204303 0.213941 Triad: 683.0 0.354251 0.351415 0.358936 ------------------------------------------------------------- Solution Validates: avg error less than 1.000000e-13 on all three arrays Results Validation Verbose Results: Expected a(1), b(1), c(1): 1153300781250.000000 230660156250.000000 307546875000.000000 Observed a(1), b(1), c(1): 1153300781250.000000 230660156250.000000 307546875000.000000 Rel Errors on a, b, c: 0.000000e+00 0.000000e+00 0.000000e+00 ------------------------------------------------------------- or compiled with -O3 that was said to be used for the AmigaOS binary it's even better (as long as no FPU is used at least which is another known weak point of QEMU): $ qemu-ppc -cpu 460ex streamPPCpowerpcO3 ------------------------------------------------------------- Based on STREAM version $Revision: 5.10 $ ------------------------------------------------------------- This system uses 8 bytes per array element. ------------------------------------------------------------- Array size = 10000000 (elements), Offset = 0 (elements) Memory per array = 76.3 MiB (= 0.1 GiB). Total memory required = 228.9 MiB (= 0.2 GiB). Each kernel will be executed 10 times. The *best* time for each kernel (excluding the first iteration) will be used to compute the reported bandwidth. ------------------------------------------------------------- Your clock granularity/precision appears to be 1 microseconds. Each test below will take on the order of 171833 microseconds. (= 171833 clock ticks) Increase the size of the arrays if this shows that you are not getting at least 20 clock ticks per test. ------------------------------------------------------------- WARNING -- The above is only a rough guideline. For best results, please be sure you know the precision of your system timer. ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 8931.7 0.017950 0.017914 0.018114 Scale: 1078.1 0.151183 0.148407 0.153068 Add: 1359.3 0.178790 0.176561 0.184122 Triad: 1161.2 0.210525 0.206683 0.216876 ------------------------------------------------------------- Solution Validates: avg error less than 1.000000e-13 on all three arrays Results Validation Verbose Results: Expected a(1), b(1), c(1): 1153300781250.000000 230660156250.000000 307546875000.000000 Observed a(1), b(1), c(1): 1153300781250.000000 230660156250.000000 307546875000.000000 Rel Errors on a, b, c: 0.000000e+00 0.000000e+00 0.000000e+00 ------------------------------------------------------------- Then I've tried booting Linux on QEMU sam460ex and run my compiled Linux exe under that and it validates there so I could only reproduce this on AmigaOS with the binary in stream.lha but that binary works on real machine so there is some problem somewhere but I'm not sure what and how to debug it. I think this may be related to TLB writes though as AmigaOS seems to do a lot of those when running this test so maybe it hits some issues that does not happen normally. Fixing the known issue with missing shadow TLB as found with MorphOS might fix this too or we could at least rule that out then. I'm open to ideas on this one as I don't have any on how to proceed. Regards, BALATON Zoltan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TCG change broke MorphOS boot on sam460ex 2024-05-27 22:23 ` BALATON Zoltan @ 2024-05-27 22:55 ` BALATON Zoltan 2024-05-28 3:30 ` Nicholas Piggin 1 sibling, 0 replies; 10+ messages in thread From: BALATON Zoltan @ 2024-05-27 22:55 UTC (permalink / raw) To: Nicholas Piggin; +Cc: qemu-devel, qemu-ppc, Richard Henderson [-- Attachment #1: Type: text/plain, Size: 15404 bytes --] On Tue, 28 May 2024, BALATON Zoltan wrote: > On Wed, 3 Apr 2024, Nicholas Piggin wrote: >> On Tue Apr 2, 2024 at 9:32 PM AEST, BALATON Zoltan wrote: >>> On Thu, 21 Mar 2024, BALATON Zoltan wrote: >>>> On 27/2/24 17:47, BALATON Zoltan wrote: >>>>> Hello, >>>>> >>>>> Commit 18a536f1f8 (accel/tcg: Always require can_do_io) broke booting >>>>> MorphOS on sam460ex (this was before 8.2.0 and I thought I've verified >>>>> it >>>>> before that release but apparently missed it back then). It can be >>>>> reproduced with https://www.morphos-team.net/morphos-3.18.iso and >>>>> following >>>>> command: >>>>> >>>>> qemu-system-ppc -M sam460ex -serial stdio -d unimp,guest_errors \ >>>>> -drive if=none,id=cd,format=raw,file=morphos-3.18.iso \ >>>>> -device ide-cd,drive=cd,bus=ide.1 >>> >>> Any idea on this one? While MorphOS boots on other machines and other OSes >>> seem to boot on this machine it may still suggest there's some problem >>> somewhere as this worked before. So it may worth investigating it to make >>> sure there's no bug that could affect other OSes too even if they boot. I >>> don't know how to debug this so some help would be needed. >> >> In the bad case it crashes after running this TB: >> >> ---------------- >> IN: >> 0x00c01354: 38c00040 li r6, 0x40 >> 0x00c01358: 38e10204 addi r7, r1, 0x204 >> 0x00c0135c: 39010104 addi r8, r1, 0x104 >> 0x00c01360: 39410004 addi r10, r1, 4 >> 0x00c01364: 39200000 li r9, 0 >> 0x00c01368: 7cc903a6 mtctr r6 >> 0x00c0136c: 84c70004 lwzu r6, 4(r7) >> 0x00c01370: 7cc907a4 tlbwehi r6, r9 >> 0x00c01374: 84c80004 lwzu r6, 4(r8) >> 0x00c01378: 7cc90fa4 tlbwelo r6, r9 >> 0x00c0137c: 84ca0004 lwzu r6, 4(r10) >> 0x00c01380: 7cc917a4 tlbwehi r6, r9 >> 0x00c01384: 39290001 addi r9, r9, 1 >> 0x00c01388: 4200ffe4 bdnz 0xc0136c >> ---------------- >> IN: >> 0x00c01374: unable to read memory >> ---------------- >> >> "unable to read memory" is the tracer, it does actually translate >> the address, but it points to a wayward real address which returns >> 0 to TCG, which is an invalid instruction. >> >> The good case instead doesn't exit the TB after 0x00c01370 but after >> the complete loop at the bdnz. That look like this after the same >> first TB: >> >> ---------------- >> IN: >> 0x00c0136c: 84c70004 lwzu r6, 4(r7) >> 0x00c01370: 7cc907a4 tlbwehi r6, r9 >> 0x00c01374: 84c80004 lwzu r6, 4(r8) >> 0x00c01378: 7cc90fa4 tlbwelo r6, r9 >> 0x00c0137c: 84ca0004 lwzu r6, 4(r10) >> 0x00c01380: 7cc917a4 tlbwehi r6, r9 >> 0x00c01384: 39290001 addi r9, r9, 1 >> 0x00c01388: 4200ffe4 bdnz 0xc0136c >> ---------------- >> IN: >> 0x00c0138c: 4c00012c isync >> >> All the tlbwe are executed in the same TB. MMU tracing shows the >> first tlbwehi creates a new valid(!) TLB for 0x00000000-0x100000000 >> that has a garbage RPN because the tlbwelo did not run yet. >> >> What's happening in the bad case is that the translator breaks >> and "re-fetches" instructions in the middle of that sequence, and >> that's where the bogus translation causes 0 to be returned. The >> good case the whole block is executed in the same fetch which >> creates correct translations. >> >> So it looks like a morphos bug, the can-do-io change just happens >> to cause it to re-fetch in that place, but that could happen for >> a number of reasons, so you can't rely on TLB *only* changing or >> ifetch *only* re-fetching at a sync point like isync. >> >> I would expect code like this to write an invalid entry with tlbwehi, >> then tlbwelo to set the correct RPN, then make the entry valid with >> the second tlbwehi. It would probably fix the bug if you just did the >> first tlbwehi with r6=0 (or at least without the 0x200 bit set). > > Revisiting this, I've found in the docs that PPC440 has shadow TLBs so this > code can rely upon the TLB not being invalidated until isync and works on > real machine but breaks on QEMU. We would either need to make sure the TB > runs until the sync or somehow emulate the shadow TLB. I've experimented with > the latter but I could not make it work (and unexpectedly keeping a cache of > the most recently used entries is slower than always searching through all > TLB entries as done now so I've abandoned that idea). The problem is that an > entry is modified by multiple tlbwe instructions but these can come in any > order (and sometimes only one of them is done like invalidating an entry > seems to only do one write) so I don't know when to copy the new entry to the > TLB and when to wait for more parts and keep the old one. Any idea how to fix > this? > > Also I'm not sure if it's related but by running the stream benchmark on > sam460ex now I can reproduce some memory access problem but I'm not sure what > causes it. The full output of that benchmark under AmigaOS on sam460ex is > this: > > ------------------------------------------------------------- > STREAM version $Revision: 5.10 $ > ------------------------------------------------------------- > This system uses 8 bytes per array element. > ------------------------------------------------------------- > Array size = 10000000 (elements), Offset = 0 (elements) > Memory per array = 76.3 MiB (= 0.1 GiB). > Total memory required = 228.9 MiB (= 0.2 GiB). > Each kernel will be executed 10 times. > The *best* time for each kernel (excluding the first iteration) > will be used to compute the reported bandwidth. > ------------------------------------------------------------- > Your clock granularity/precision appears to be 3 microseconds. > Each test below will take on the order of 186279 microseconds. > (= 62093 clock ticks) > Increase the size of the arrays if this shows that > you are not getting at least 20 clock ticks per test. > ------------------------------------------------------------- > WARNING -- The above is only a rough guideline. > For best results, please be sure you know the > precision of your system timer. > ------------------------------------------------------------- > Function Best Rate MB/s Avg time Min time Max time > Copy: 1723.8 0.095517 0.092821 0.103645 > Scale: 790.2 0.206338 0.202479 0.214062 > Add: 994.7 0.246171 0.241289 0.256950 > Triad: 763.2 0.323731 0.314454 0.343873 > ------------------------------------------------------------- > Failed Validation on array a[], AvgRelAbsErr > epsilon (1.000000e-13) > Expected Value: 1.153301e+12, AvgAbsErr: 1.137394e+12, AvgRelAbsErr: > 9.862079e-01 > For array a[], 9863168 errors were found. > Failed Validation on array b[], AvgRelAbsErr > epsilon (1.000000e-13) > Expected Value: 2.306602e+11, AvgAbsErr: 2.274872e+11, AvgRelAbsErr: > 9.862438e-01 > AvgRelAbsErr > Epsilon (1.000000e-13) > For array b[], 9863168 errors were found. > Failed Validation on array c[], AvgRelAbsErr > epsilon (1.000000e-13) > Expected Value: 3.075469e+11, AvgAbsErr: 3.033024e+11, AvgRelAbsErr: > 9.861989e-01 > AvgRelAbsErr > Epsilon (1.000000e-13) > For array c[], 9863168 errors were found. > ------------------------------------------------------------- > > while on amigaone or pegasos2 the same executable finishes with: > ------------------------------------------------------------- > Solution Validates: avg error less than 1.000000e-13 on all three arrays > ------------------------------------------------------------- > > On a real Sam460EX this same executable also validates as confirmed here: > https://www.amigans.net/modules/newbb/viewtopic.php?post_id=148020#forumpost148020 > > The binary and source is from here: > http://os4depot.net/?function=showfile&file=utility/benchmark/stream.lha > > This binary runs on QEMU amigaone and pegasos2 that use G4 and validates so > only seems to be a problem with 460EX. I've compiled the source for PPC Linux > and tried running that with qemu-ppc linux-user to verify it which does not > use MMU so it's expected to work and it does: > > $ qemu-ppc -cpu 460ex streamPPC > ------------------------------------------------------------- > Based on STREAM version $Revision: 5.10 $ > ------------------------------------------------------------- > This system uses 8 bytes per array element. > ------------------------------------------------------------- > Array size = 10000000 (elements), Offset = 0 (elements) > Memory per array = 76.3 MiB (= 0.1 GiB). > Total memory required = 228.9 MiB (= 0.2 GiB). > Each kernel will be executed 10 times. > The *best* time for each kernel (excluding the first iteration) > will be used to compute the reported bandwidth. > ------------------------------------------------------------- > Your clock granularity/precision appears to be 1 microseconds. > Each test below will take on the order of 192649 microseconds. > (= 192649 clock ticks) > Increase the size of the arrays if this shows that > you are not getting at least 20 clock ticks per test. > ------------------------------------------------------------- > WARNING -- The above is only a rough guideline. > For best results, please be sure you know the > precision of your system timer. > ------------------------------------------------------------- > Function Best Rate MB/s Avg time Min time Max time > Copy: 3191.5 0.050227 0.050133 0.050584 > Scale: 889.5 0.181873 0.179880 0.183075 > Add: 1174.7 0.207856 0.204303 0.213941 > Triad: 683.0 0.354251 0.351415 0.358936 > ------------------------------------------------------------- > Solution Validates: avg error less than 1.000000e-13 on all three arrays > Results Validation Verbose Results: > Expected a(1), b(1), c(1): 1153300781250.000000 230660156250.000000 > 307546875000.000000 > Observed a(1), b(1), c(1): 1153300781250.000000 230660156250.000000 > 307546875000.000000 > Rel Errors on a, b, c: 0.000000e+00 0.000000e+00 0.000000e+00 > ------------------------------------------------------------- > > or compiled with -O3 that was said to be used for the AmigaOS binary it's > even better (as long as no FPU is used at least which is another known weak > point of QEMU): > > $ qemu-ppc -cpu 460ex streamPPCpowerpcO3 > ------------------------------------------------------------- > Based on STREAM version $Revision: 5.10 $ > ------------------------------------------------------------- > This system uses 8 bytes per array element. > ------------------------------------------------------------- > Array size = 10000000 (elements), Offset = 0 (elements) > Memory per array = 76.3 MiB (= 0.1 GiB). > Total memory required = 228.9 MiB (= 0.2 GiB). > Each kernel will be executed 10 times. > The *best* time for each kernel (excluding the first iteration) > will be used to compute the reported bandwidth. > ------------------------------------------------------------- > Your clock granularity/precision appears to be 1 microseconds. > Each test below will take on the order of 171833 microseconds. > (= 171833 clock ticks) > Increase the size of the arrays if this shows that > you are not getting at least 20 clock ticks per test. > ------------------------------------------------------------- > WARNING -- The above is only a rough guideline. > For best results, please be sure you know the > precision of your system timer. > ------------------------------------------------------------- > Function Best Rate MB/s Avg time Min time Max time > Copy: 8931.7 0.017950 0.017914 0.018114 > Scale: 1078.1 0.151183 0.148407 0.153068 > Add: 1359.3 0.178790 0.176561 0.184122 > Triad: 1161.2 0.210525 0.206683 0.216876 > ------------------------------------------------------------- > Solution Validates: avg error less than 1.000000e-13 on all three arrays > Results Validation Verbose Results: > Expected a(1), b(1), c(1): 1153300781250.000000 230660156250.000000 > 307546875000.000000 > Observed a(1), b(1), c(1): 1153300781250.000000 230660156250.000000 > 307546875000.000000 > Rel Errors on a, b, c: 0.000000e+00 0.000000e+00 0.000000e+00 > ------------------------------------------------------------- > > Then I've tried booting Linux on QEMU sam460ex and run my compiled Linux exe > under that and it validates there so I could only reproduce this on AmigaOS For completeness here's the run on sam460ex Linux: $ ./streamPPCpowerpcO3 ------------------------------------------------------------- Based on STREAM version $Revision: 5.10 $ ------------------------------------------------------------- This system uses 8 bytes per array element. ------------------------------------------------------------- Array size = 10000000 (elements), Offset = 0 (elements) Memory per array = 76.3 MiB (= 0.1 GiB). Total memory required = 228.9 MiB (= 0.2 GiB). Each kernel will be executed 10 times. The *best* time for each kernel (excluding the first iteration) will be used to compute the reported bandwidth. ------------------------------------------------------------- Your clock granularity/precision appears to be 2 microseconds. Each test below will take on the order of 169662 microseconds. (= 84831 clock ticks) Increase the size of the arrays if this shows that you are not getting at least 20 clock ticks per test. ------------------------------------------------------------- WARNING -- The above is only a rough guideline. For best results, please be sure you know the precision of your system timer. ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 2143.7 0.075259 0.074636 0.076172 Scale: 846.4 0.190517 0.189029 0.192099 Add: 1043.7 0.232548 0.229945 0.237299 Triad: 814.4 0.299620 0.294695 0.309323 ------------------------------------------------------------- Solution Validates: avg error less than 1.000000e-13 on all three arrays Results Validation Verbose Results: Expected a(1), b(1), c(1): 1153300781250.000000 230660156250.000000 307546875000.000000 Observed a(1), b(1), c(1): 1153300781250.000000 230660156250.000000 307546875000.000000 Rel Errors on a, b, c: 0.000000e+00 0.000000e+00 0.000000e+00 ------------------------------------------------------------- > with the binary in stream.lha but that binary works on real machine so there > is some problem somewhere but I'm not sure what and how to debug it. I think > this may be related to TLB writes though as AmigaOS seems to do a lot of > those when running this test so maybe it hits some issues that does not > happen normally. Fixing the known issue with missing shadow TLB as found with > MorphOS might fix this too or we could at least rule that out then. Also it's not something that broke recently and thus could be bisected. I get the same validation error with QEMU v8.2.0 before any embedded tlb changes or even before that so it may be something pre existing and then not related to the MorphOS boot problem above. > I'm open to ideas on this one as I don't have any on how to proceed. > > Regards, > BALATON Zoltan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TCG change broke MorphOS boot on sam460ex 2024-05-27 22:23 ` BALATON Zoltan 2024-05-27 22:55 ` BALATON Zoltan @ 2024-05-28 3:30 ` Nicholas Piggin 1 sibling, 0 replies; 10+ messages in thread From: Nicholas Piggin @ 2024-05-28 3:30 UTC (permalink / raw) To: BALATON Zoltan; +Cc: qemu-devel, qemu-ppc, Richard Henderson On Tue May 28, 2024 at 8:23 AM AEST, BALATON Zoltan wrote: > On Wed, 3 Apr 2024, Nicholas Piggin wrote: > > On Tue Apr 2, 2024 at 9:32 PM AEST, BALATON Zoltan wrote: > >> On Thu, 21 Mar 2024, BALATON Zoltan wrote: > >>> On 27/2/24 17:47, BALATON Zoltan wrote: > >>>> Hello, > >>>> > >>>> Commit 18a536f1f8 (accel/tcg: Always require can_do_io) broke booting > >>>> MorphOS on sam460ex (this was before 8.2.0 and I thought I've verified it > >>>> before that release but apparently missed it back then). It can be > >>>> reproduced with https://www.morphos-team.net/morphos-3.18.iso and following > >>>> command: > >>>> > >>>> qemu-system-ppc -M sam460ex -serial stdio -d unimp,guest_errors \ > >>>> -drive if=none,id=cd,format=raw,file=morphos-3.18.iso \ > >>>> -device ide-cd,drive=cd,bus=ide.1 > >> > >> Any idea on this one? While MorphOS boots on other machines and other OSes > >> seem to boot on this machine it may still suggest there's some problem > >> somewhere as this worked before. So it may worth investigating it to make > >> sure there's no bug that could affect other OSes too even if they boot. I > >> don't know how to debug this so some help would be needed. > > > > In the bad case it crashes after running this TB: > > > > ---------------- > > IN: > > 0x00c01354: 38c00040 li r6, 0x40 > > 0x00c01358: 38e10204 addi r7, r1, 0x204 > > 0x00c0135c: 39010104 addi r8, r1, 0x104 > > 0x00c01360: 39410004 addi r10, r1, 4 > > 0x00c01364: 39200000 li r9, 0 > > 0x00c01368: 7cc903a6 mtctr r6 > > 0x00c0136c: 84c70004 lwzu r6, 4(r7) > > 0x00c01370: 7cc907a4 tlbwehi r6, r9 > > 0x00c01374: 84c80004 lwzu r6, 4(r8) > > 0x00c01378: 7cc90fa4 tlbwelo r6, r9 > > 0x00c0137c: 84ca0004 lwzu r6, 4(r10) > > 0x00c01380: 7cc917a4 tlbwehi r6, r9 > > 0x00c01384: 39290001 addi r9, r9, 1 > > 0x00c01388: 4200ffe4 bdnz 0xc0136c > > ---------------- > > IN: > > 0x00c01374: unable to read memory > > ---------------- > > > > "unable to read memory" is the tracer, it does actually translate > > the address, but it points to a wayward real address which returns > > 0 to TCG, which is an invalid instruction. > > > > The good case instead doesn't exit the TB after 0x00c01370 but after > > the complete loop at the bdnz. That look like this after the same > > first TB: > > > > ---------------- > > IN: > > 0x00c0136c: 84c70004 lwzu r6, 4(r7) > > 0x00c01370: 7cc907a4 tlbwehi r6, r9 > > 0x00c01374: 84c80004 lwzu r6, 4(r8) > > 0x00c01378: 7cc90fa4 tlbwelo r6, r9 > > 0x00c0137c: 84ca0004 lwzu r6, 4(r10) > > 0x00c01380: 7cc917a4 tlbwehi r6, r9 > > 0x00c01384: 39290001 addi r9, r9, 1 > > 0x00c01388: 4200ffe4 bdnz 0xc0136c > > ---------------- > > IN: > > 0x00c0138c: 4c00012c isync > > > > All the tlbwe are executed in the same TB. MMU tracing shows the > > first tlbwehi creates a new valid(!) TLB for 0x00000000-0x100000000 > > that has a garbage RPN because the tlbwelo did not run yet. > > > > What's happening in the bad case is that the translator breaks > > and "re-fetches" instructions in the middle of that sequence, and > > that's where the bogus translation causes 0 to be returned. The > > good case the whole block is executed in the same fetch which > > creates correct translations. > > > > So it looks like a morphos bug, the can-do-io change just happens > > to cause it to re-fetch in that place, but that could happen for > > a number of reasons, so you can't rely on TLB *only* changing or > > ifetch *only* re-fetching at a sync point like isync. > > > > I would expect code like this to write an invalid entry with tlbwehi, > > then tlbwelo to set the correct RPN, then make the entry valid with > > the second tlbwehi. It would probably fix the bug if you just did the > > first tlbwehi with r6=0 (or at least without the 0x200 bit set). > > Revisiting this, I've found in the docs that PPC440 has shadow TLBs so > this code can rely upon the TLB not being invalidated until isync and > works on real machine but breaks on QEMU. I never programmed for 440 but it's unclear to me from the docs how much you can rely on this programatically (you would have to ensure no page crossings, disable interrupts, hope for no machine check, etc). But it does break real software so whether or not it is following exact letter of the law, it would be good to fix. > We would either need to make > sure the TB runs until the sync or somehow emulate the shadow TLB. I've > experimented with the latter but I could not make it work (and > unexpectedly keeping a cache of the most recently used entries is slower > than always searching through all TLB entries as done now so I've > abandoned that idea). The problem is that an entry is modified by multiple > tlbwe instructions but these can come in any order (and sometimes only one > of them is done like invalidating an entry seems to only do one write) so > I don't know when to copy the new entry to the TLB and when to wait for > more parts and keep the old one. Any idea how to fix this? Depends what the important common cases are and exactly how faithfully you want to model the hardware behaviour I guess. How are you trying to emulate the shadow TLB? I attached a really quick hack to see what that would look like... That is modeling the hardware filled TLB structure ahead of the machine's software TLB. It's not a perfect model but might be enough, one downside is that it flushes entire QEMU TLB for any BookE TLB entry change. The other way to go might be to keep a structure containing the list of outstanding BookE TLB modifications, and replay that into the TLB on sync events. That way your QEMU TLB refill path has no extra data structure to look up or maintain, and you could do more precise flushing of the QEMU TLB when you apply the changes. Difficulty would be that TLB instructions would become more complicated and expensive (reads can't just go to the TLB they would have to find the most recent change, etc). But maybe that is the better tradeoff if your lookups are relatively much more common than software-tlb instructions are not. Thanks, Nick --- diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h index 2015e603d4..afbc766fd1 100644 --- a/target/ppc/cpu.h +++ b/target/ppc/cpu.h @@ -377,6 +377,12 @@ union ppc_tlb_t { ppc6xx_tlb_t *tlb6; ppcemb_tlb_t *tlbe; ppcmas_tlb_t *tlbm; + + /* 440 shadow TLB */ + ppcemb_tlb_t ishadow[4]; + int ishadow_idx; + ppcemb_tlb_t dshadow[8]; + int dshadow_idx; }; /* possible TLB variants */ diff --git a/target/ppc/helper_regs.c b/target/ppc/helper_regs.c index 02076e96fb..3207b594e1 100644 --- a/target/ppc/helper_regs.c +++ b/target/ppc/helper_regs.c @@ -363,10 +363,22 @@ void store_40x_sler(CPUPPCState *env, uint32_t val) env->spr[SPR_405_SLER] = val; } +void ppc4xx_tlb_invalidate_shadow(CPUPPCState *env); void check_tlb_flush(CPUPPCState *env, bool global) { CPUState *cs = env_cpu(env); + if (env->mmu_model == POWERPC_MMU_SOFT_4xx) { + assert(!(env->tlb_need_flush & TLB_NEED_GLOBAL_FLUSH)); + + if (env->tlb_need_flush & TLB_NEED_LOCAL_FLUSH) { + env->tlb_need_flush &= ~TLB_NEED_LOCAL_FLUSH; + ppc4xx_tlb_invalidate_shadow(env); + tlb_flush(cs); + } + return; + } + /* Handle global flushes first */ if (global && (env->tlb_need_flush & TLB_NEED_GLOBAL_FLUSH)) { env->tlb_need_flush &= ~TLB_NEED_GLOBAL_FLUSH; diff --git a/target/ppc/mmu-booke.c b/target/ppc/mmu-booke.c index 55e5dd7c6b..31509be39b 100644 --- a/target/ppc/mmu-booke.c +++ b/target/ppc/mmu-booke.c @@ -74,55 +74,91 @@ int mmu40x_get_physical_address(CPUPPCState *env, hwaddr *raddr, int *prot, { ppcemb_tlb_t *tlb; int i, ret, zsel, zpr, pr; + uint32_t pid = env->spr[SPR_40x_PID]; ret = -1; - pr = FIELD_EX64(env->msr, MSR, PR); + + /* Check "shadow TLBs" first */ + if (access_type == MMU_INST_FETCH) { + for (i = 0; i < 4; i++) { + tlb = &env->tlb.ishadow[i]; + if (ppcemb_tlb_check(env, tlb, raddr, address, pid, -i)) { + goto found; + } + } + } else { + for (i = 0; i < 8; i++) { + tlb = &env->tlb.dshadow[i]; + if (ppcemb_tlb_check(env, tlb, raddr, address, pid, -i)) { + goto found; + } + } + } + /* Then check main (software visible) TLB */ for (i = 0; i < env->nb_tlb; i++) { tlb = &env->tlb.tlbe[i]; - if (!ppcemb_tlb_check(env, tlb, raddr, address, - env->spr[SPR_40x_PID], i)) { - continue; + if (ppcemb_tlb_check(env, tlb, raddr, address, pid, i)) { + goto found_main; } - zsel = (tlb->attr >> 4) & 0xF; - zpr = (env->spr[SPR_40x_ZPR] >> (30 - (2 * zsel))) & 0x3; - qemu_log_mask(CPU_LOG_MMU, - "%s: TLB %d zsel %d zpr %d ty %d attr %08x\n", - __func__, i, zsel, zpr, access_type, tlb->attr); - /* Check execute enable bit */ - switch (zpr) { - case 0x2: - if (pr != 0) { - goto check_perms; - } - /* fall through */ - case 0x3: - /* All accesses granted */ - *prot = PAGE_RWX; - ret = 0; - break; + } + goto out; - case 0x0: - if (pr != 0) { - /* Raise Zone protection fault. */ - env->spr[SPR_40x_ESR] = 1 << 22; - *prot = 0; - ret = -2; - break; - } - /* fall through */ - case 0x1: -check_perms: - /* Check from TLB entry */ - *prot = tlb->prot; - if (check_prot_access_type(*prot, access_type)) { - ret = 0; - } else { - env->spr[SPR_40x_ESR] = 0; - ret = -2; - } +found_main: + /* Shadow must be reloaded, FIFO replacement */ + if (access_type == MMU_INST_FETCH) { + env->tlb.ishadow[env->tlb.ishadow_idx] = *tlb; + env->tlb.ishadow_idx++; + env->tlb.ishadow_idx %= 4; + } else { + env->tlb.dshadow[env->tlb.dshadow_idx] = *tlb; + env->tlb.dshadow_idx++; + env->tlb.dshadow_idx %= 8; + } + +found: + pr = FIELD_EX64(env->msr, MSR, PR); + + zsel = (tlb->attr >> 4) & 0xF; + zpr = (env->spr[SPR_40x_ZPR] >> (30 - (2 * zsel))) & 0x3; + qemu_log_mask(CPU_LOG_MMU, + "%s: TLB %d zsel %d zpr %d ty %d attr %08x\n", + __func__, i, zsel, zpr, access_type, tlb->attr); + /* Check execute enable bit */ + switch (zpr) { + case 0x2: + if (pr != 0) { + goto check_perms; + } + /* fall through */ + case 0x3: + /* All accesses granted */ + *prot = PAGE_RWX; + ret = 0; + break; + + case 0x0: + if (pr != 0) { + /* Raise Zone protection fault. */ + env->spr[SPR_40x_ESR] = 1 << 22; + *prot = 0; + ret = -2; break; } + /* fall through */ + case 0x1: +check_perms: + /* Check from TLB entry */ + *prot = tlb->prot; + if (check_prot_access_type(*prot, access_type)) { + ret = 0; + } else { + env->spr[SPR_40x_ESR] = 0; + ret = -2; + } + break; } + +out: qemu_log_mask(CPU_LOG_MMU, "%s: access %s " TARGET_FMT_lx " => " HWADDR_FMT_plx " %d %d\n", __func__, ret < 0 ? "refused" : "granted", address, diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c index b0a0676beb..502ddf65b6 100644 --- a/target/ppc/mmu_helper.c +++ b/target/ppc/mmu_helper.c @@ -108,6 +108,22 @@ static void ppc6xx_tlb_store(CPUPPCState *env, target_ulong EPN, int way, } /* Helpers specific to PowerPC 40x implementations */ +void ppc4xx_tlb_invalidate_shadow(CPUPPCState *env); +void ppc4xx_tlb_invalidate_shadow(CPUPPCState *env) +{ + ppcemb_tlb_t *tlb; + int i; + + for (i = 0; i < 4; i++) { + tlb = &env->tlb.ishadow[i]; + tlb->prot &= ~PAGE_VALID; + } + for (i = 0; i < 8; i++) { + tlb = &env->tlb.dshadow[i]; + tlb->prot &= ~PAGE_VALID; + } +} + static inline void ppc4xx_tlb_invalidate_all(CPUPPCState *env) { ppcemb_tlb_t *tlb; @@ -117,6 +133,7 @@ static inline void ppc4xx_tlb_invalidate_all(CPUPPCState *env) tlb = &env->tlb.tlbe[i]; tlb->prot &= ~PAGE_VALID; } + ppc4xx_tlb_invalidate_shadow(env); tlb_flush(env_cpu(env)); } @@ -719,6 +736,7 @@ target_ulong helper_4xx_tlbre_lo(CPUPPCState *env, target_ulong entry) return ret; } +#if 0 static void ppcemb_tlb_flush(CPUState *cs, ppcemb_tlb_t *tlb) { unsigned mmu_idx = 0; @@ -736,6 +754,7 @@ static void ppcemb_tlb_flush(CPUState *cs, ppcemb_tlb_t *tlb) tlb_flush_range_by_mmuidx(cs, tlb->EPN, tlb->size, mmu_idx, TARGET_LONG_BITS); } +#endif void helper_4xx_tlbwe_hi(CPUPPCState *env, target_ulong entry, target_ulong val) @@ -753,7 +772,7 @@ void helper_4xx_tlbwe_hi(CPUPPCState *env, target_ulong entry, qemu_log_mask(CPU_LOG_MMU, "%s: invalidate old TLB %d start " TARGET_FMT_lx " end " TARGET_FMT_lx "\n", __func__, (int)entry, tlb->EPN, tlb->EPN + tlb->size); - ppcemb_tlb_flush(cs, tlb); + env->tlb_need_flush |= TLB_NEED_LOCAL_FLUSH; } tlb->size = booke_tlb_to_page_size((val >> PPC4XX_TLBHI_SIZE_SHIFT) & PPC4XX_TLBHI_SIZE_MASK); @@ -792,7 +811,7 @@ void helper_4xx_tlbwe_hi(CPUPPCState *env, target_ulong entry, void helper_4xx_tlbwe_lo(CPUPPCState *env, target_ulong entry, target_ulong val) { - CPUState *cs = env_cpu(env); +// CPUState *cs = env_cpu(env); ppcemb_tlb_t *tlb; qemu_log_mask(CPU_LOG_MMU, "%s entry %i val " TARGET_FMT_lx "\n", @@ -804,7 +823,7 @@ void helper_4xx_tlbwe_lo(CPUPPCState *env, target_ulong entry, qemu_log_mask(CPU_LOG_MMU, "%s: invalidate old TLB %d start " TARGET_FMT_lx " end " TARGET_FMT_lx "\n", __func__, (int)entry, tlb->EPN, tlb->EPN + tlb->size); - ppcemb_tlb_flush(cs, tlb); + env->tlb_need_flush |= TLB_NEED_LOCAL_FLUSH; } tlb->attr = val & PPC4XX_TLBLO_ATTR_MASK; tlb->RPN = val & PPC4XX_TLBLO_RPN_MASK; @@ -865,7 +884,7 @@ void helper_440_tlbwe(CPUPPCState *env, uint32_t word, target_ulong entry, qemu_log_mask(CPU_LOG_MMU, "%s: invalidate old TLB %d start " TARGET_FMT_lx " end " TARGET_FMT_lx "\n", __func__, (int)entry, tlb->EPN, tlb->EPN + tlb->size); - ppcemb_tlb_flush(env_cpu(env), tlb); + env->tlb_need_flush |= TLB_NEED_LOCAL_FLUSH; } switch (word) { ^ permalink raw reply related [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-05-28 3:31 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-02-27 16:47 TCG change broke MorphOS boot on sam460ex BALATON Zoltan 2024-02-27 18:15 ` Philippe Mathieu-Daudé 2024-02-27 19:48 ` BALATON Zoltan 2024-03-21 18:41 ` BALATON Zoltan 2024-04-02 11:32 ` BALATON Zoltan 2024-04-03 5:15 ` Nicholas Piggin 2024-04-03 22:23 ` BALATON Zoltan 2024-05-27 22:23 ` BALATON Zoltan 2024-05-27 22:55 ` BALATON Zoltan 2024-05-28 3:30 ` Nicholas Piggin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).