On Thursday 29 January 2015 16:23:42 Christoffer Dall wrote: > On Wed, Jan 28, 2015 at 8:57 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > 8<---- > > Subject: [PATCH] ARM: KVM: avoid "HYP init code too big" error > > > > When building large kernels, the linker will emit lots of veneers > > into the .hyp.idmap.text section, which causes it to grow beyond > > one page, and that triggers the build error. > > > > do you have a config handy that generates this error? Attached to this mail. Use on linux-next > > This moves the section into .rodata instead, which avoids the > > veneers and is safe because the code is not executed directly > > but always copied into a separate page first. > > > > I am unsure if I wrote this the correct way though, so > > it needs to be reviewed carefully. > > > > Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx> > > > > diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S > > index ce01a2d3339f..f4de6e16d951 100644 > > --- a/arch/arm/kernel/vmlinux.lds.S > > +++ b/arch/arm/kernel/vmlinux.lds.S > > @@ -23,10 +23,14 @@ > > VMLINUX_SYMBOL(__idmap_text_start) = .; \ > > *(.idmap.text) \ > > VMLINUX_SYMBOL(__idmap_text_end) = .; \ > > - . = ALIGN(32); \ > > + . = ALIGN(32); > > + > > +#define IDMAP_RODATA \ > > + .rodata : { \ > > VMLINUX_SYMBOL(__hyp_idmap_text_start) = .; \ > > *(.hyp.idmap.text) \ > > - VMLINUX_SYMBOL(__hyp_idmap_text_end) = .; > > + VMLINUX_SYMBOL(__hyp_idmap_text_end) = .; \ > > + } > > > > #ifdef CONFIG_HOTPLUG_CPU > > #define ARM_CPU_DISCARD(x) > > @@ -123,6 +127,7 @@ SECTIONS > > . = ALIGN(1<<SECTION_SHIFT); > > #endif > > RO_DATA(PAGE_SIZE) > > + IDMAP_RODATA > > > > . = ALIGN(4); > > __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) { > > > > > the changes look ok, but I don't understand why putting stuff in rodata is > a good solution, is it simply by chance that the linker then generates > fewer veneers there? I think we're only branching internally in the hyp > idmap text page anyhow, so wondering why this appears in the first place... > hmmm. The linker will not generate any veneers for .rodata because it does not expect executable code in there. As I said, above, this is also correct because it matches how we access that section (read-only, never execute). Arnd
Attachment:
0x203B430A-config.gz
Description: application/gzip