| Message ID | 20170418070126.A18EF67952@localhost.localdomain (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
From: Christophe Leroy > By default, PPC8xx PINs an ITLB on the first 8M of memory in order > to avoid any ITLB miss on kernel code. > However, with some debug functions like DEBUG_PAGEALLOC and > (soon to come) DEBUG_RODATA, the PINned TLB is invalidated soon > after startup so ITLB missed start to happen also on the kernel code. > > In order to avoid any ITLB miss in a critical section, we have to > ensure that their is no page boundary crossed between the setup of > a new value in SRR0/SRR1 and the associated RFI. This cannot be done > easily if entry_32 functions sits in the middle of other .text > functions. By placing entry_32 just after the .head section (as already > done for entry_64 on PPC64), we can more easily ensure the issue > doesn't happen. Shouldn't this be done by putting all the functions that 'matter' into a named section instead of relying on the order of the input files? (Which is what I think this is doing.) David
David Laight <David.Laight@ACULAB.COM> writes: > From: Christophe Leroy >> By default, PPC8xx PINs an ITLB on the first 8M of memory in order >> to avoid any ITLB miss on kernel code. >> However, with some debug functions like DEBUG_PAGEALLOC and >> (soon to come) DEBUG_RODATA, the PINned TLB is invalidated soon >> after startup so ITLB missed start to happen also on the kernel code. >> >> In order to avoid any ITLB miss in a critical section, we have to >> ensure that their is no page boundary crossed between the setup of >> a new value in SRR0/SRR1 and the associated RFI. This cannot be done >> easily if entry_32 functions sits in the middle of other .text >> functions. By placing entry_32 just after the .head section (as already >> done for entry_64 on PPC64), we can more easily ensure the issue >> doesn't happen. > > Shouldn't this be done by putting all the functions that 'matter' > into a named section instead of relying on the order of the input files? > (Which is what I think this is doing.) Yeah that is fragile if there's nothing more to it. I'm not sure if we need a special section. If the functions that must not cross a page boundary are aligned to a page boundary (with .align) then that would also work wouldn't it? cheers
Le 20/04/2017 à 13:25, Michael Ellerman a écrit : > David Laight <David.Laight@ACULAB.COM> writes: > >> From: Christophe Leroy >>> By default, PPC8xx PINs an ITLB on the first 8M of memory in order >>> to avoid any ITLB miss on kernel code. >>> However, with some debug functions like DEBUG_PAGEALLOC and >>> (soon to come) DEBUG_RODATA, the PINned TLB is invalidated soon >>> after startup so ITLB missed start to happen also on the kernel code. >>> >>> In order to avoid any ITLB miss in a critical section, we have to >>> ensure that their is no page boundary crossed between the setup of >>> a new value in SRR0/SRR1 and the associated RFI. This cannot be done >>> easily if entry_32 functions sits in the middle of other .text >>> functions. By placing entry_32 just after the .head section (as already >>> done for entry_64 on PPC64), we can more easily ensure the issue >>> doesn't happen. >> >> Shouldn't this be done by putting all the functions that 'matter' >> into a named section instead of relying on the order of the input files? >> (Which is what I think this is doing.) > > Yeah that is fragile if there's nothing more to it. > > I'm not sure if we need a special section. If the functions that must > not cross a page boundary are aligned to a page boundary (with .align) > then that would also work wouldn't it? Yes it would work, but we would also 'loose' some space (up to one page ?), as I don't think 'ld' would fill the blanks with other functions. Maybe we can find a lower alignment than a page boundary, I'll investigate that. Christophe
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 19b0d1a81959..8aa1dafb14eb 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -243,7 +243,7 @@ head-$(CONFIG_40x) := arch/powerpc/kernel/head_40x.o head-$(CONFIG_44x) := arch/powerpc/kernel/head_44x.o head-$(CONFIG_FSL_BOOKE) := arch/powerpc/kernel/head_fsl_booke.o -head-$(CONFIG_PPC64) += arch/powerpc/kernel/entry_64.o +head-y += arch/powerpc/kernel/entry_$(BITS).o head-$(CONFIG_PPC_FPU) += arch/powerpc/kernel/fpu.o head-$(CONFIG_ALTIVEC) += arch/powerpc/kernel/vector.o head-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE) += arch/powerpc/kernel/prom_init.o diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index 811f441a125f..eb2db44c5fe9 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -90,7 +90,7 @@ extra-y += vmlinux.lds obj-$(CONFIG_RELOCATABLE) += reloc_$(BITS).o -obj-$(CONFIG_PPC32) += entry_32.o setup_32.o +obj-$(CONFIG_PPC32) += setup_32.o obj-$(CONFIG_PPC64) += dma-iommu.o iommu.o obj-$(CONFIG_KGDB) += kgdb.o obj-$(CONFIG_BOOTX_TEXT) += btext.o @@ -154,7 +154,7 @@ UBSAN_SANITIZE_vdso.o := n extra-$(CONFIG_PPC_FPU) += fpu.o extra-$(CONFIG_ALTIVEC) += vector.o -extra-$(CONFIG_PPC64) += entry_64.o +extra-y += entry_$(BITS).o extra-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE) += prom_init.o extra-y += systbl_chk.i
By default, PPC8xx PINs an ITLB on the first 8M of memory in order to avoid any ITLB miss on kernel code. However, with some debug functions like DEBUG_PAGEALLOC and (soon to come) DEBUG_RODATA, the PINned TLB is invalidated soon after startup so ITLB missed start to happen also on the kernel code. In order to avoid any ITLB miss in a critical section, we have to ensure that their is no page boundary crossed between the setup of a new value in SRR0/SRR1 and the associated RFI. This cannot be done easily if entry_32 functions sits in the middle of other .text functions. By placing entry_32 just after the .head section (as already done for entry_64 on PPC64), we can more easily ensure the issue doesn't happen. Ex: with this change, all entry_32 functions playing with srr0/srr1 appears between 0xc0002000 and 0xc0002fff on PPC_8xx. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> --- arch/powerpc/Makefile | 2 +- arch/powerpc/kernel/Makefile | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)