[PATCH v5 04/16] arc: Switch to generic free_initrd_mem.

2018-03-29 Thread Shea Levy
The generic implementation is functionally identical.

Signed-off-by: Shea Levy 
---
 arch/arc/mm/init.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
index ba145065c579..7bcf23ab1756 100644
--- a/arch/arc/mm/init.c
+++ b/arch/arc/mm/init.c
@@ -229,10 +229,3 @@ void __ref free_initmem(void)
 {
free_initmem_default(-1);
 }
-
-#ifdef CONFIG_BLK_DEV_INITRD
-void __init free_initrd_mem(unsigned long start, unsigned long end)
-{
-   free_reserved_area((void *)start, (void *)end, -1, "initrd");
-}
-#endif
-- 
2.16.2


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] Extract initrd free logic from arch-specific code.

2018-03-29 Thread Russell King - ARM Linux
On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
>  wrote:
> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> >>
> >>
> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> >> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> >> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
> >> >>> Now only those architectures that have custom initrd free requirements
> >> >>> need to define free_initrd_mem.
> >> >> ...
> >> >>> --- a/arch/arc/mm/init.c
> >> >>> +++ b/arch/arc/mm/init.c
> >> >>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> >> >>>  {
> >> >>>   free_initmem_default(-1);
> >> >>>  }
> >> >>> -
> >> >>> -#ifdef CONFIG_BLK_DEV_INITRD
> >> >>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> >> >>> -{
> >> >>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> >> >>> -}
> >> >>> -#endif
> >> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> >>> index 3f972e83909b..19d1c5594e2d 100644
> >> >>> --- a/arch/arm/Kconfig
> >> >>> +++ b/arch/arm/Kconfig
> >> >>> @@ -47,6 +47,7 @@ config ARM
> >> >>>   select HARDIRQS_SW_RESEND
> >> >>>   select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> >> >>>   select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
> >> >>> + select HAVE_ARCH_FREE_INITRD_MEM
> >> >>>   select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
> >> >>>   select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
> >> >>>   select HAVE_ARCH_MMAP_RND_BITS if MMU
> >> >>
> >> >> Isn't this why weak symbols were invented?
> >> >
> >> > Weak symbols means that we end up with both the weakly-referenced code
> >> > and the arch code in the kernel image.  That's fine if the weak code
> >> > is small.
> >>
> >> The kernel's been able to build with link time garbage collection since 
> >> 2016:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
> >>
> >> Wouldn't that remove the unused one?
> >
> > Probably, if anyone bothered to use that, which they don't.
> >
> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> > what I can see, nothing selects it.  Therefore, the symbol is always
> > disabled, and so the feature never gets used in mainline kernels.
> >
> > Brings up the obvious question - why is it there if it's completely
> > unused?  (Maybe to cause confusion, and allowing a justification
> > for __weak ?)
> 
> IIRC Nick had some patches to do the arch enablement for powerpc, but
> I'm not sure what happened to them though. I suspect it just fell down
> Nick's ever growing TODO list.

I've given it a go on ARM, marking every linker-built table with KEEP()
and comparing the System.map files.  The resulting kernel is around
150k smaller, which seems good.

However, it doesn't boot - and I don't know why.  Booting the kernel
under kvmtool in a VM using virtio-console, I can find no way to get
any kernel messages out of it.  Using lkvm debug, I can see that the
PC is stuck inside die(), and that's the only information I have.
It dies before bringing up the other CPUs, so it's a very early death.

I don't think other console types are available under ARM64.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] Extract initrd free logic from arch-specific code.

2018-03-29 Thread Geert Uytterhoeven
On Thu, Mar 29, 2018 at 5:27 PM, Russell King - ARM Linux
 wrote:
> On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
>> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
>>  wrote:
>> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
>> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
>> >> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>> >> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
>> >> >>> Now only those architectures that have custom initrd free requirements
>> >> >>> need to define free_initrd_mem.
>> >> >> ...
>> >> >>> --- a/arch/arc/mm/init.c
>> >> >>> +++ b/arch/arc/mm/init.c
>> >> >>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
>> >> >>>  {
>> >> >>>   free_initmem_default(-1);
>> >> >>>  }
>> >> >>> -
>> >> >>> -#ifdef CONFIG_BLK_DEV_INITRD
>> >> >>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
>> >> >>> -{
>> >> >>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
>> >> >>> -}
>> >> >>> -#endif
>> >> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> >> >>> index 3f972e83909b..19d1c5594e2d 100644
>> >> >>> --- a/arch/arm/Kconfig
>> >> >>> +++ b/arch/arm/Kconfig
>> >> >>> @@ -47,6 +47,7 @@ config ARM
>> >> >>>   select HARDIRQS_SW_RESEND
>> >> >>>   select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
>> >> >>>   select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
>> >> >>> + select HAVE_ARCH_FREE_INITRD_MEM
>> >> >>>   select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && 
>> >> >>> MMU
>> >> >>>   select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
>> >> >>>   select HAVE_ARCH_MMAP_RND_BITS if MMU
>> >> >>
>> >> >> Isn't this why weak symbols were invented?
>> >> >
>> >> > Weak symbols means that we end up with both the weakly-referenced code
>> >> > and the arch code in the kernel image.  That's fine if the weak code
>> >> > is small.
>> >>
>> >> The kernel's been able to build with link time garbage collection since 
>> >> 2016:
>> >>
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
>> >>
>> >> Wouldn't that remove the unused one?
>> >
>> > Probably, if anyone bothered to use that, which they don't.
>> >
>> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
>> > what I can see, nothing selects it.  Therefore, the symbol is always
>> > disabled, and so the feature never gets used in mainline kernels.
>> >
>> > Brings up the obvious question - why is it there if it's completely
>> > unused?  (Maybe to cause confusion, and allowing a justification
>> > for __weak ?)
>>
>> IIRC Nick had some patches to do the arch enablement for powerpc, but
>> I'm not sure what happened to them though. I suspect it just fell down
>> Nick's ever growing TODO list.
>
> I've given it a go on ARM, marking every linker-built table with KEEP()
> and comparing the System.map files.  The resulting kernel is around
> 150k smaller, which seems good.
>
> However, it doesn't boot - and I don't know why.  Booting the kernel
> under kvmtool in a VM using virtio-console, I can find no way to get
> any kernel messages out of it.  Using lkvm debug, I can see that the
> PC is stuck inside die(), and that's the only information I have.
> It dies before bringing up the other CPUs, so it's a very early death.
>
> I don't think other console types are available under ARM64.

earlycon?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] Extract initrd free logic from arch-specific code.

2018-03-29 Thread Russell King - ARM Linux
On Thu, Mar 29, 2018 at 05:43:47PM +0200, Geert Uytterhoeven wrote:
> On Thu, Mar 29, 2018 at 5:27 PM, Russell King - ARM Linux
>  wrote:
> > On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
> >> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
> >>  wrote:
> >> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> >> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> >> >> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> >> >> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
> >> >> >>> Now only those architectures that have custom initrd free 
> >> >> >>> requirements
> >> >> >>> need to define free_initrd_mem.
> >> >> >> ...
> >> >> >>> --- a/arch/arc/mm/init.c
> >> >> >>> +++ b/arch/arc/mm/init.c
> >> >> >>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> >> >> >>>  {
> >> >> >>>   free_initmem_default(-1);
> >> >> >>>  }
> >> >> >>> -
> >> >> >>> -#ifdef CONFIG_BLK_DEV_INITRD
> >> >> >>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> >> >> >>> -{
> >> >> >>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> >> >> >>> -}
> >> >> >>> -#endif
> >> >> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> >> >>> index 3f972e83909b..19d1c5594e2d 100644
> >> >> >>> --- a/arch/arm/Kconfig
> >> >> >>> +++ b/arch/arm/Kconfig
> >> >> >>> @@ -47,6 +47,7 @@ config ARM
> >> >> >>>   select HARDIRQS_SW_RESEND
> >> >> >>>   select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> >> >> >>>   select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && 
> >> >> >>> !CPU_32v6
> >> >> >>> + select HAVE_ARCH_FREE_INITRD_MEM
> >> >> >>>   select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && 
> >> >> >>> MMU
> >> >> >>>   select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
> >> >> >>>   select HAVE_ARCH_MMAP_RND_BITS if MMU
> >> >> >>
> >> >> >> Isn't this why weak symbols were invented?
> >> >> >
> >> >> > Weak symbols means that we end up with both the weakly-referenced code
> >> >> > and the arch code in the kernel image.  That's fine if the weak code
> >> >> > is small.
> >> >>
> >> >> The kernel's been able to build with link time garbage collection since 
> >> >> 2016:
> >> >>
> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
> >> >>
> >> >> Wouldn't that remove the unused one?
> >> >
> >> > Probably, if anyone bothered to use that, which they don't.
> >> >
> >> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> >> > what I can see, nothing selects it.  Therefore, the symbol is always
> >> > disabled, and so the feature never gets used in mainline kernels.
> >> >
> >> > Brings up the obvious question - why is it there if it's completely
> >> > unused?  (Maybe to cause confusion, and allowing a justification
> >> > for __weak ?)
> >>
> >> IIRC Nick had some patches to do the arch enablement for powerpc, but
> >> I'm not sure what happened to them though. I suspect it just fell down
> >> Nick's ever growing TODO list.
> >
> > I've given it a go on ARM, marking every linker-built table with KEEP()
> > and comparing the System.map files.  The resulting kernel is around
> > 150k smaller, which seems good.
> >
> > However, it doesn't boot - and I don't know why.  Booting the kernel
> > under kvmtool in a VM using virtio-console, I can find no way to get
> > any kernel messages out of it.  Using lkvm debug, I can see that the
> > PC is stuck inside die(), and that's the only information I have.
> > It dies before bringing up the other CPUs, so it's a very early death.
> >
> > I don't think other console types are available under ARM64.
> 
> earlycon?

Through what - as I say above, I think the only thing that's present is
virtio-console, and the virtio stack only get initialised much later in
boot.

Eg, there's the memory-based virtio driver which interfaces any virtio
driver to a memory-based ring structures for communication with the host
(drivers/virtio/virtio_mmio.c) which is initialised at module_init()
time, and so isn't available for earlycon.

I don't think merely changing the module_init() calls in the appropriate
virtio bits will suffice - it's why I pointed out that it dies before
SMP initialisation, which also means that it dies before we start
running the initcalls for subsystems and drivers.

I'm not aware of there being an emulated UART in the guest's address
space, so serial based stuff doesn't work.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] Extract initrd free logic from arch-specific code.

2018-03-29 Thread Rob Landley


On 03/28/2018 05:14 PM, Russell King - ARM Linux wrote:
> On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
>>
>>
>> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
>>> On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
 On 03/28/2018 10:26 AM, Shea Levy wrote:
> Now only those architectures that have custom initrd free requirements
> need to define free_initrd_mem.
 ...
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
>  {
>   free_initmem_default(-1);
>  }
> -
> -#ifdef CONFIG_BLK_DEV_INITRD
> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> -{
> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> -}
> -#endif
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 3f972e83909b..19d1c5594e2d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -47,6 +47,7 @@ config ARM
>   select HARDIRQS_SW_RESEND
>   select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
>   select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
> + select HAVE_ARCH_FREE_INITRD_MEM
>   select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
>   select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
>   select HAVE_ARCH_MMAP_RND_BITS if MMU

 Isn't this why weak symbols were invented?
>>>
>>> Weak symbols means that we end up with both the weakly-referenced code
>>> and the arch code in the kernel image.  That's fine if the weak code
>>> is small.
>>
>> The kernel's been able to build with link time garbage collection since 2016:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
>>
>> Wouldn't that remove the unused one?
> 
> Probably, if anyone bothered to use that, which they don't.
> 
> LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> what I can see, nothing selects it.  Therefore, the symbol is always
> disabled, and so the feature never gets used in mainline kernels.

It looks like there are per-architecture linker scripts that need to be updated?
So if an architecture supports it, it's always done (well, it probes for the
toolchain supporting the flag). And if the architecture doesn't support it, the
linker script needs to be updated to mark sections with "I know nothing seems to
reference this at the ELF level but keep it anyway, we're pulling an assembly
trick".

> Brings up the obvious question - why is it there if it's completely
> unused?  (Maybe to cause confusion, and allowing a justification
> for __weak ?)

Presumably it will become the default on architectures as their linker scripts
are converted. Once they're all converted the config symbol can go away. (Given
the move to requiring gcc 4.7 or whatever it is, there can't be an architecture
depending on a toolchain that _doesn't_ support it after that point. I doubt you
can pair gcc 4.7 with a >12 year old binutils and expect good things...)

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] Extract initrd free logic from arch-specific code.

2018-03-29 Thread Marc Zyngier
On Thu, 29 Mar 2018 16:58:27 +0100,
Russell King - ARM Linux wrote:
> 
> On Thu, Mar 29, 2018 at 05:43:47PM +0200, Geert Uytterhoeven wrote:
> > On Thu, Mar 29, 2018 at 5:27 PM, Russell King - ARM Linux
> >  wrote:
> > > On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
> > >> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
> > >>  wrote:
> > >> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> > >> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> > >> >> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> > >> >> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
> > >> >> >>> Now only those architectures that have custom initrd free 
> > >> >> >>> requirements
> > >> >> >>> need to define free_initrd_mem.
> > >> >> >> ...
> > >> >> >>> --- a/arch/arc/mm/init.c
> > >> >> >>> +++ b/arch/arc/mm/init.c
> > >> >> >>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> > >> >> >>>  {
> > >> >> >>>   free_initmem_default(-1);
> > >> >> >>>  }
> > >> >> >>> -
> > >> >> >>> -#ifdef CONFIG_BLK_DEV_INITRD
> > >> >> >>> -void __init free_initrd_mem(unsigned long start, unsigned long 
> > >> >> >>> end)
> > >> >> >>> -{
> > >> >> >>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> > >> >> >>> -}
> > >> >> >>> -#endif
> > >> >> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > >> >> >>> index 3f972e83909b..19d1c5594e2d 100644
> > >> >> >>> --- a/arch/arm/Kconfig
> > >> >> >>> +++ b/arch/arm/Kconfig
> > >> >> >>> @@ -47,6 +47,7 @@ config ARM
> > >> >> >>>   select HARDIRQS_SW_RESEND
> > >> >> >>>   select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> > >> >> >>>   select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && 
> > >> >> >>> !CPU_32v6
> > >> >> >>> + select HAVE_ARCH_FREE_INITRD_MEM
> > >> >> >>>   select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 
> > >> >> >>> && MMU
> > >> >> >>>   select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
> > >> >> >>>   select HAVE_ARCH_MMAP_RND_BITS if MMU
> > >> >> >>
> > >> >> >> Isn't this why weak symbols were invented?
> > >> >> >
> > >> >> > Weak symbols means that we end up with both the weakly-referenced 
> > >> >> > code
> > >> >> > and the arch code in the kernel image.  That's fine if the weak code
> > >> >> > is small.
> > >> >>
> > >> >> The kernel's been able to build with link time garbage collection 
> > >> >> since 2016:
> > >> >>
> > >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
> > >> >>
> > >> >> Wouldn't that remove the unused one?
> > >> >
> > >> > Probably, if anyone bothered to use that, which they don't.
> > >> >
> > >> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> > >> > what I can see, nothing selects it.  Therefore, the symbol is always
> > >> > disabled, and so the feature never gets used in mainline kernels.
> > >> >
> > >> > Brings up the obvious question - why is it there if it's completely
> > >> > unused?  (Maybe to cause confusion, and allowing a justification
> > >> > for __weak ?)
> > >>
> > >> IIRC Nick had some patches to do the arch enablement for powerpc, but
> > >> I'm not sure what happened to them though. I suspect it just fell down
> > >> Nick's ever growing TODO list.
> > >
> > > I've given it a go on ARM, marking every linker-built table with KEEP()
> > > and comparing the System.map files.  The resulting kernel is around
> > > 150k smaller, which seems good.
> > >
> > > However, it doesn't boot - and I don't know why.  Booting the kernel
> > > under kvmtool in a VM using virtio-console, I can find no way to get
> > > any kernel messages out of it.  Using lkvm debug, I can see that the
> > > PC is stuck inside die(), and that's the only information I have.
> > > It dies before bringing up the other CPUs, so it's a very early death.
> > >
> > > I don't think other console types are available under ARM64.
> > 
> > earlycon?
> 
> Through what - as I say above, I think the only thing that's present is
> virtio-console, and the virtio stack only get initialised much later in
> boot.
> 
> Eg, there's the memory-based virtio driver which interfaces any virtio
> driver to a memory-based ring structures for communication with the host
> (drivers/virtio/virtio_mmio.c) which is initialised at module_init()
> time, and so isn't available for earlycon.
> 
> I don't think merely changing the module_init() calls in the appropriate
> virtio bits will suffice - it's why I pointed out that it dies before
> SMP initialisation, which also means that it dies before we start
> running the initcalls for subsystems and drivers.
> 
> I'm not aware of there being an emulated UART in the guest's address
> space, so serial based stuff doesn't work.

"earlycon=uart,mmio,0x3f8" is what you're looking for:

$ Work/kvmtool/lkvm run -c2 -k zImage -p "earlycon=uart,mmio,0x3f8" --console 
virtio --aarch32
  # lkvm run -k zImage -m 320 -c 2 --name guest-3856
  Info: Loaded kernel to 0x80008000 (6767

Re: [PATCH] Extract initrd free logic from arch-specific code.

2018-03-29 Thread Russell King - ARM Linux
On Thu, Mar 29, 2018 at 11:39:24AM -0500, Rob Landley wrote:
> 
> 
> On 03/28/2018 05:14 PM, Russell King - ARM Linux wrote:
> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> >>
> >>
> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> >>> On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>  On 03/28/2018 10:26 AM, Shea Levy wrote:
> > Now only those architectures that have custom initrd free requirements
> > need to define free_initrd_mem.
>  ...
> > --- a/arch/arc/mm/init.c
> > +++ b/arch/arc/mm/init.c
> > @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> >  {
> > free_initmem_default(-1);
> >  }
> > -
> > -#ifdef CONFIG_BLK_DEV_INITRD
> > -void __init free_initrd_mem(unsigned long start, unsigned long end)
> > -{
> > -   free_reserved_area((void *)start, (void *)end, -1, "initrd");
> > -}
> > -#endif
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 3f972e83909b..19d1c5594e2d 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -47,6 +47,7 @@ config ARM
> > select HARDIRQS_SW_RESEND
> > select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> > select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && 
> > !CPU_32v6
> > +   select HAVE_ARCH_FREE_INITRD_MEM
> > select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 
> > && MMU
> > select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
> > select HAVE_ARCH_MMAP_RND_BITS if MMU
> 
>  Isn't this why weak symbols were invented?
> >>>
> >>> Weak symbols means that we end up with both the weakly-referenced code
> >>> and the arch code in the kernel image.  That's fine if the weak code
> >>> is small.
> >>
> >> The kernel's been able to build with link time garbage collection since 
> >> 2016:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
> >>
> >> Wouldn't that remove the unused one?
> > 
> > Probably, if anyone bothered to use that, which they don't.
> > 
> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> > what I can see, nothing selects it.  Therefore, the symbol is always
> > disabled, and so the feature never gets used in mainline kernels.
> 
> It looks like there are per-architecture linker scripts that need to be 
> updated?
> So if an architecture supports it, it's always done (well, it probes for the
> toolchain supporting the flag). And if the architecture doesn't support it, 
> the
> linker script needs to be updated to mark sections with "I know nothing seems 
> to
> reference this at the ELF level but keep it anyway, we're pulling an assembly
> trick".

It looks like it needs much more than just architecture changes as the
reason it fails on ARM is because the init thread structure is missing
due to missing KEEP()s in INIT_TASK_DATA().  Probably means it doesn't
work anywhere.

8<===
From: Russell King 
Subject: [PATCH] Fix LD_DEAD_CODE_DATA_ELIMINATION

LD_DEAD_CODE_DATA_ELIMINATION fails to boot on ARM because the linker
eliminates the init thread data from the bottom of the init threads
stack.  This causes recursive faults that end up overwriting parts
of the kernel before they can print any message.

Signed-off-by: Russell King 
---
 include/asm-generic/vmlinux.lds.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 1ab0e520d6fc..41af8a74aae4 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -279,8 +279,8 @@
VMLINUX_SYMBOL(__start_init_task) = .;  \
VMLINUX_SYMBOL(init_thread_union) = .;  \
VMLINUX_SYMBOL(init_stack) = .; \
-   *(.data..init_task) \
-   *(.data..init_thread_info)  \
+   KEEP(*(.data..init_task))   \
+   KEEP(*(.data..init_thread_info))\
. = VMLINUX_SYMBOL(__start_init_task) + THREAD_SIZE;\
VMLINUX_SYMBOL(__end_init_task) = .;
 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] Extract initrd free logic from arch-specific code.

2018-03-29 Thread Russell King - ARM Linux
On Thu, Mar 29, 2018 at 05:53:14PM +0100, Marc Zyngier wrote:
> On Thu, 29 Mar 2018 16:58:27 +0100,
> Russell King - ARM Linux wrote:
> > 
> > On Thu, Mar 29, 2018 at 05:43:47PM +0200, Geert Uytterhoeven wrote:
> > > On Thu, Mar 29, 2018 at 5:27 PM, Russell King - ARM Linux
> > >  wrote:
> > > > On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
> > > >> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
> > > >>  wrote:
> > > >> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> > > >> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> > > >> >> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> > > >> >> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
> > > >> >> >>> Now only those architectures that have custom initrd free 
> > > >> >> >>> requirements
> > > >> >> >>> need to define free_initrd_mem.
> > > >> >> >> ...
> > > >> >> >>> --- a/arch/arc/mm/init.c
> > > >> >> >>> +++ b/arch/arc/mm/init.c
> > > >> >> >>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> > > >> >> >>>  {
> > > >> >> >>>   free_initmem_default(-1);
> > > >> >> >>>  }
> > > >> >> >>> -
> > > >> >> >>> -#ifdef CONFIG_BLK_DEV_INITRD
> > > >> >> >>> -void __init free_initrd_mem(unsigned long start, unsigned long 
> > > >> >> >>> end)
> > > >> >> >>> -{
> > > >> >> >>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> > > >> >> >>> -}
> > > >> >> >>> -#endif
> > > >> >> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > >> >> >>> index 3f972e83909b..19d1c5594e2d 100644
> > > >> >> >>> --- a/arch/arm/Kconfig
> > > >> >> >>> +++ b/arch/arm/Kconfig
> > > >> >> >>> @@ -47,6 +47,7 @@ config ARM
> > > >> >> >>>   select HARDIRQS_SW_RESEND
> > > >> >> >>>   select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> > > >> >> >>>   select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && 
> > > >> >> >>> !CPU_32v6
> > > >> >> >>> + select HAVE_ARCH_FREE_INITRD_MEM
> > > >> >> >>>   select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && 
> > > >> >> >>> !CPU_ENDIAN_BE32 && MMU
> > > >> >> >>>   select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
> > > >> >> >>>   select HAVE_ARCH_MMAP_RND_BITS if MMU
> > > >> >> >>
> > > >> >> >> Isn't this why weak symbols were invented?
> > > >> >> >
> > > >> >> > Weak symbols means that we end up with both the weakly-referenced 
> > > >> >> > code
> > > >> >> > and the arch code in the kernel image.  That's fine if the weak 
> > > >> >> > code
> > > >> >> > is small.
> > > >> >>
> > > >> >> The kernel's been able to build with link time garbage collection 
> > > >> >> since 2016:
> > > >> >>
> > > >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
> > > >> >>
> > > >> >> Wouldn't that remove the unused one?
> > > >> >
> > > >> > Probably, if anyone bothered to use that, which they don't.
> > > >> >
> > > >> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> > > >> > what I can see, nothing selects it.  Therefore, the symbol is always
> > > >> > disabled, and so the feature never gets used in mainline kernels.
> > > >> >
> > > >> > Brings up the obvious question - why is it there if it's completely
> > > >> > unused?  (Maybe to cause confusion, and allowing a justification
> > > >> > for __weak ?)
> > > >>
> > > >> IIRC Nick had some patches to do the arch enablement for powerpc, but
> > > >> I'm not sure what happened to them though. I suspect it just fell down
> > > >> Nick's ever growing TODO list.
> > > >
> > > > I've given it a go on ARM, marking every linker-built table with KEEP()
> > > > and comparing the System.map files.  The resulting kernel is around
> > > > 150k smaller, which seems good.
> > > >
> > > > However, it doesn't boot - and I don't know why.  Booting the kernel
> > > > under kvmtool in a VM using virtio-console, I can find no way to get
> > > > any kernel messages out of it.  Using lkvm debug, I can see that the
> > > > PC is stuck inside die(), and that's the only information I have.
> > > > It dies before bringing up the other CPUs, so it's a very early death.
> > > >
> > > > I don't think other console types are available under ARM64.
> > > 
> > > earlycon?
> > 
> > Through what - as I say above, I think the only thing that's present is
> > virtio-console, and the virtio stack only get initialised much later in
> > boot.
> > 
> > Eg, there's the memory-based virtio driver which interfaces any virtio
> > driver to a memory-based ring structures for communication with the host
> > (drivers/virtio/virtio_mmio.c) which is initialised at module_init()
> > time, and so isn't available for earlycon.
> > 
> > I don't think merely changing the module_init() calls in the appropriate
> > virtio bits will suffice - it's why I pointed out that it dies before
> > SMP initialisation, which also means that it dies before we start
> > running the initcalls for subsystems and drivers.
> > 
> > I'm not aware of there being an emulated UART in the guest's address
> > space

Re: [PATCH] Extract initrd free logic from arch-specific code.

2018-03-29 Thread Rob Landley
On 03/29/2018 10:27 AM, Russell King - ARM Linux wrote:
> On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
>> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
>>> LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
>>> what I can see, nothing selects it.  Therefore, the symbol is always
>>> disabled, and so the feature never gets used in mainline kernels.
>>>
>>> Brings up the obvious question - why is it there if it's completely
>>> unused?  (Maybe to cause confusion, and allowing a justification
>>> for __weak ?)
>>
>> IIRC Nick had some patches to do the arch enablement for powerpc, but
>> I'm not sure what happened to them though. I suspect it just fell down
>> Nick's ever growing TODO list.
> 
> I've given it a go on ARM, marking every linker-built table with KEEP()
> and comparing the System.map files.  The resulting kernel is around
> 150k smaller, which seems good.
> 
> However, it doesn't boot - and I don't know why.  Booting the kernel
> under kvmtool in a VM using virtio-console, I can find no way to get
> any kernel messages out of it.  Using lkvm debug, I can see that the
> PC is stuck inside die(), and that's the only information I have.

qemu-system-arm's "-s" option lets you hook to the hardware with gdb, as if
using one of those jtags that speaks gdbserver protocol. It stops waiting for
you to attach with 'target remote' it, then 'file vmlinux' to load the 
symbols...

The miniconfig and qemu invocation I use for arm64 are attached, tested with
2.11.0 on a 4.14 kernel. You should be able to just "qemu-aarch64.sh -s" and
then probably "target remote 127.0.0.1:1234"? (Been a while since I've used it,
don't have a cross-gdb for arm64 lying around...)

Sigh, I just tried -s and qemu 2.11.0 is _not_ waiting for gdb to attach on
arm64, despite what the docs say:

$ qemu-system-aarch64 --help | grep gdb
-gdb devwait for gdb connection on 'dev'
-s  shorthand for -gdb tcp::1234

Another random regression in qemu, gee what a surprise.

> It dies before bringing up the other CPUs, so it's a very early death.
> 
> I don't think other console types are available under ARM64.

I've often found useful the two line version of:

https://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/

Which is generally some variant of:

{char *XX = "blah"; while (*XX) {while (*SERIAL_STATUS_REGISTER & OUT_READY);
*SERIAL_OUT = *XX++;}}

(I.E. balu cheated not spinning checking the ready-for-next-byte bit, because
qemu's always angry.)

That trick lets you cut and paste a print statement into all sorts of early
hardware nonsense, on most architectures. You just have to look up
SERIAL_STATUS_REGISTER, OUT_OK_BIT, and SERIAL_OUT values for the serial port du
jour.

That said I've mostly used it in things like u-boot. I dunno at what point the
kernel's done enough setup that direct banging on registers would stop working.
(Works in the decompresion code, anyway.) And it assumes the port's set to the
right speed (usually left there by the bootloader)...

Rob
# make ARCH=arm64 allnoconfig KCONFIG_ALLCONFIG=aarch64.miniconf
# make ARCH=arm64 -j $(nproc)
# boot arch/arm64/boot/Image


CONFIG_MMU=y
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_VIRT=y
CONFIG_SOC_DRA7XX=y
CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
CONFIG_ARCH_ALPINE=y
CONFIG_ARM_THUMB=y
CONFIG_VDSO=y
CONFIG_CPU_IDLE=y
CONFIG_ARM_CPUIDLE=y
CONFIG_KERNEL_MODE_NEON=y

CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y

CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_DRV_PL031=y

CONFIG_NET_CORE=y
CONFIG_VIRTIO_NET=y

CONFIG_PCI=y
CONFIG_PCI_HOST_GENERIC=y
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_MMIO=y

CONFIG_ATA=y
CONFIG_ATA_SFF=y
CONFIG_ATA_BMDMA=y
CONFIG_ATA_PIIX=y

CONFIG_PATA_PLATFORM=y
CONFIG_PATA_OF_PLATFORM=y
CONFIG_ATA_GENERIC=y


# CONFIG_EMBEDDED is not set
CONFIG_EARLY_PRINTK=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y

CONFIG_BLK_DEV_LOOP=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_UTF8=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y

CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IPV6=y
CONFIG_NETDEVICES=y
#CONFIG_NET_CORE=y
#CONFIG_NETCONSOLE=y
CONFIG_ETHERNET=y



qemu-aarch64.sh
Description: application/shellscript
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] Extract initrd free logic from arch-specific code.

2018-03-29 Thread Marc Zyngier
On Thu, 29 Mar 2018 18:32:47 +0100,
Russell King - ARM Linux wrote:
> 
> On Thu, Mar 29, 2018 at 05:53:14PM +0100, Marc Zyngier wrote:
> > On Thu, 29 Mar 2018 16:58:27 +0100,
> > Russell King - ARM Linux wrote:

[...]

> > > I'm not aware of there being an emulated UART in the guest's address
> > > space, so serial based stuff doesn't work.
> > 
> > "earlycon=uart,mmio,0x3f8" is what you're looking for:
> 
> Does that also mean that we have a RTC at the standard PC IO addresses
> as well, but in mmio space?

There is one, together with an i8042. Not exposed in the DT though.

M.

-- 
Jazz is not dead, it just smell funny.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] Extract initrd free logic from arch-specific code.

2018-03-29 Thread kbuild test robot
Hi Shea,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.16-rc7]
[cannot apply to next-20180329]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Shea-Levy/Extract-initrd-free-logic-from-arch-specific-code/20180330-085507
config: ia64-allnoconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All warnings (new ones prefixed by >>):

warning: (IA64) selects HAVE_ARCH_FREE_INITRD_MEM which has unmet direct 
dependencies (BLK_DEV_INITRD)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] Extract initrd free logic from arch-specific code.

2018-03-29 Thread kbuild test robot
Hi Shea,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.16-rc7]
[cannot apply to next-20180329]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Shea-Levy/Extract-initrd-free-logic-from-arch-specific-code/20180330-085507
config: m32r-m32104ut_defconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All warnings (new ones prefixed by >>):

warning: (M32R) selects HAVE_ARCH_FREE_INITRD_MEM which has unmet direct 
dependencies (BLK_DEV_INITRD)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc