| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 17 Dec 2018 02:28:37 +0100
From: Jonathan Neuschäfer <j.neuschaefer@....net>
To: Christophe Leroy <christophe.leroy@....fr>
Cc: Jonathan Neuschäfer <j.neuschaefer@....net>,
linuxppc-dev@...ts.ozlabs.org, Paul Mackerras <paulus@...ba.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 03/13] powerpc/mm/32s: rework mmu_mapin_ram()
Hi, thanks for your reply.
On Thu, Dec 13, 2018 at 03:51:32PM +0100, Christophe Leroy wrote:
> Hi Again,
>
> Le 13/12/2018 à 13:16, Christophe Leroy a écrit :
[...]
> > Can you tell/provide the .config and dts used ?
I'm using wii.dts and almost the wii_defconfig from my tree (save-
defconfig result is attached), which is 4.20-rc5 plus a few patches:
https://github.com/neuschaefer/linux wii-4.20-rc5 (w/o your patches)
https://github.com/neuschaefer/linux wii-4.20-rc5-ppcbat (w/ your patches 1-3)
> > You seem to have 319MB RAM wherease arch/powerpc/boot/dts/wii.dts only
> > has 88MB Memory:
> >
> > memory {
> > device_type = "memory";
> > reg = <0x00000000 0x01800000 /* MEM1 24MB 1T-SRAM */
> > 0x10000000 0x04000000>; /* MEM2 64MB GDDR3 */
> > };
This is, I think, because something marks all the address space from 0
to the end of MEM2 as RAM, and then cuts out a hole in the middle. I'm
not sure about the exact mechanism.
Unfortunately this hole has to be treated carefully because it contains
MMIO devices.
> Putting the same description in my mpc832x board DTS and doing a few hacks
> to get the WII functions called, I get the following:
>
> [ 0.000000] Top of RAM: 0x14000000, Total RAM: 0x5800000
> [ 0.000000] Memory hole size: 232MB
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA [mem 0x0000000000000000-0x0000000013ffffff]
> [ 0.000000] Normal empty
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000000000000-0x00000000017fffff]
> [ 0.000000] node 0: [mem 0x0000000010000000-0x0000000013ffffff]
> [ 0.000000] Initmem setup node 0 [mem
> 0x0000000000000000-0x0000000013ffffff]
> [ 0.000000] On node 0 totalpages: 22528
> [ 0.000000] DMA zone: 640 pages used for memmap
> [ 0.000000] DMA zone: 0 pages reserved
> [ 0.000000] DMA zone: 22528 pages, LIFO batch:3
> [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> [ 0.000000] pcpu-alloc: [0] 0
> [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 21888
> [ 0.000000] Kernel command line: loglevel=7
> ip=192.168.2.5:192.168.2.2::255.0
> [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536
> bytes)
> [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> [ 0.000000] Memory: 77060K/90112K available (6548K kernel code, 1156K
> rwdata,
> [ 0.000000] Kernel virtual memory layout:
> [ 0.000000] * 0xfffdf000..0xfffff000 : fixmap
> [ 0.000000] * 0xfdffd000..0xfe000000 : early ioremap
> [ 0.000000] * 0xd5000000..0xfdffd000 : vmalloc & ioremap
>
>
>
>
> root@...ippro:~# cat /sys/kernel/debug/powerpc/block_address_translation
> ---[ Instruction Block Address Translation ]---
> 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel EXEC coherent
> 1: -
> 2: 0xc1000000-0xc17fffff 0x01000000 Kernel EXEC coherent
> 3: -
> 4: 0xd0000000-0xd3ffffff 0x10000000 Kernel EXEC coherent
> 5: -
> 6: -
> 7: -
>
> ---[ Data Block Address Translation ]---
> 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel RW coherent
> 1: 0xfffe0000-0xffffffff 0x0d000000 Kernel RW no cache guarded
> 2: 0xc1000000-0xc17fffff 0x01000000 Kernel RW coherent
> 3: -
> 4: 0xd0000000-0xd3ffffff 0x10000000 Kernel RW coherent
> 5: -
> 6: -
> 7: -
>
>
> Could you please provide the dmesg and
> /sys/kernel/debug/powerpc/block_address_translation from before this patch,
> so that we can compare and identify the differences if any ?
After applying the patch that adds this debugfs file and enabling
CONFIG_PPC_PTDUMP, I get this:
# cat /sys/kernel/debug/powerpc/block_address_translation
---[ Instruction Block Address Translation ]---
0: -
1: -
2: 0xc0000000-0xc0ffffff 0x00000000 Kernel EXEC
3: 0xc1000000-0xc17fffff 0x01000000 Kernel EXEC
4: 0xd0000000-0xd1ffffff 0x10000000 Kernel EXEC
5: -
6: -
7: -
---[ Data Block Address Translation ]---
0: -
1: 0xfffe0000-0xffffffff 0x0d000000 Kernel RW no cache guarded
2: 0xc0000000-0xc0ffffff 0x00000000 Kernel RW
3: 0xc1000000-0xc17fffff 0x01000000 Kernel RW
4: 0xd0000000-0xd1ffffff 0x10000000 Kernel RW
5: -
6: -
7: -
dmesg is attached.
I added some tracing to the setbat function:
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index f6f575bae3bc..4da3dc54fe46 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -120,6 +120,9 @@ void __init setbat(int index, unsigned long virt, phys_addr_t phys,
struct ppc_bat *bat = BATS[index];
unsigned long flags = pgprot_val(prot);
+ pr_info("setbat(%u, %px, %px, %px, %lx)\n",
+ index, (void *)virt, (void *)phys, (void *)size, flags);
+
if ((flags & _PAGE_NO_CACHE) ||
(cpu_has_feature(CPU_FTR_NEED_COHERENT) == 0))
flags &= ~_PAGE_COHERENT;
And here's what I got:
Before your patches (circa v4.20-rc5):
[ 0.000000] setbat(2, c0000000, 00000000, 01000000, 591)
[ 0.000000] setbat(3, c1000000, 01000000, 00800000, 591)
[ 0.000000] setbat(4, d0000000, 10000000, 02000000, 591)
With patches 1-3:
[ 0.000000] setbat(0, c0000000, 00000000, 01000000, 311)
[ 0.000000] setbat(2, c1000000, 01000000, 00800000, 311)
[ 0.000000] setbat(4, d0000000, 10000000, 02000000, 791)
According to arch/powerpc/include/asm/book3s/32/hash.h,
- 0x591 = _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | _PAGE_PRESENT
- 0x311 = _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_COHERENT | _PAGE_PRESENT
- 0x791 = _PAGE_RW | _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | _PAGE_PRESENT
Changing the flags back to 0x591 in setbat doesn't result in a booting
system.
> > > I've tested at patch 1, 2, 3, 4, and 13, so I don't know if it works
> > > somewhere in the middle, but probably not.
(I get the same results if I also merge powerpc/next, btw)
I hope this helps somewhat,
Jonathan Neuschäfer
View attachment "wii-dmesg.txt" of type "text/plain" (10334 bytes)
View attachment "wii-conf" of type "text/plain" (3065 bytes)
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists