[RFC PATCH 0/3] Make allmodconfig boot in qemu-arm64

[RFC PATCH 0/3] Make allmodconfig boot in qemu-arm64

[Anders Roxell]

Hi,

With this patch set I've been able to get a allmodconfig kernel to boot
under qemu-system-aarch64.

The patch "config: provide a fragment to enable gdb for qemu" I found
useful when trying to figure out how it fall over. So when I have to
debug a kernel with gdb I just ran this:
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -skj$(getconf
_NPROCESSORS_ONLN) O=obj-arm64-next-20181213 allmodconfig
kvm_guest.config qemu-gdb.config
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -skj$(getconf
_NPROCESSORS_ONLN) O=obj-arm64-next-20181213 Image

Before we do the same job on other architectures we wanted to reach out
and ask to see if this seams a reasonable way forward ?

The end goal would be to be able to run test suites on a allmodconfig
kernel. We may end up with another fragment that turn off/on a lot of
debug options and selftests during boot up since that may cause issues
for other test suites like kseftest, LTP and so on.

Cheers,
Anders

Anders Roxell (3):
  config: provide a fragment to enable gdb for qemu
  lib/ubsan: default UBSAN_ALIGNMENT to not set
  arm64: add a new config option KTEST_RUNNABLE

 arch/arm64/Kconfig             |  8 ++++++++
 drivers/tty/hvc/Kconfig        |  1 +
 init/Kconfig                   |  1 +
 kernel/configs/qemu-gdb.config |  7 +++++++
 lib/Kconfig.ubsan              | 14 +++++++++-----
 5 files changed, 26 insertions(+), 5 deletions(-)
 create mode 100644 kernel/configs/qemu-gdb.config

-- 
2.19.2

[RFC PATCH 1/3] config: provide a fragment to enable gdb for qemu

[Anders Roxell]

Adding a fragment to make it easier to know what options is needed to
build a kernel to get the that you can debug in qemu.

First you need to start qemu with flags '-s -S' and then connect with
gdb like below:
$ gdb \
 ./obj-dir/vmlinux -iex 'add-auto-load-safe-path \
 ./obj-dir' -ex 'target remote localhost:1234'

Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
 kernel/configs/qemu-gdb.config | 7 +++++++
 1 file changed, 7 insertions(+)
 create mode 100644 kernel/configs/qemu-gdb.config

diff --git a/kernel/configs/qemu-gdb.config b/kernel/configs/qemu-gdb.config
new file mode 100644
index 000000000000..30465905ff93
--- /dev/null
+++ b/kernel/configs/qemu-gdb.config
@@ -0,0 +1,7 @@
+# Enable debug info for gdb
+# CONFIG_COMPILE_TEST is not set
+CONFIG_DEBUG_INFO=y
+CONFIG_GDB_SCRIPTS=y
+
+# Easier to debug
+# CONFIG_RANDOMIZE_BASE is not set
-- 
2.19.2

Re: [RFC PATCH 1/3] config: provide a fragment to enable gdb for qemu

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

On Thu, Dec 13, 2018 at 01:29:08PM +0100, Anders Roxell wrote:
> Adding a fragment to make it easier to know what options is needed to
> build a kernel to get the that you can debug in qemu.

> @@ -0,0 +1,7 @@
> +# Enable debug info for gdb
> +# CONFIG_COMPILE_TEST is not set
> +CONFIG_DEBUG_INFO=y
> +CONFIG_GDB_SCRIPTS=y

Is this specifically for qemu or is this just good for debugging with
GDB in general (eg, via JTAG)?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC PATCH 1/3] config: provide a fragment to enable gdb for qemu

[Anders Roxell]

On Thu, 13 Dec 2018 at 13:40, Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Dec 13, 2018 at 01:29:08PM +0100, Anders Roxell wrote:
> > Adding a fragment to make it easier to know what options is needed to
> > build a kernel to get the that you can debug in qemu.
>
> > @@ -0,0 +1,7 @@
> > +# Enable debug info for gdb
> > +# CONFIG_COMPILE_TEST is not set
> > +CONFIG_DEBUG_INFO=y
> > +CONFIG_GDB_SCRIPTS=y
>
> Is this specifically for qemu or is this just good for debugging with
> GDB in general (eg, via JTAG)?

I haven't tried, and I don't have a JTAG so I could test it =/

Cheers,
Anders

Re: [RFC PATCH 1/3] config: provide a fragment to enable gdb for qemu

[Arnd Bergmann]

On Tue, Dec 18, 2018 at 9:45 AM Anders Roxell <anders.roxell@linaro.org> wrote:
>
> On Thu, 13 Dec 2018 at 13:40, Mark Brown <broonie@kernel.org> wrote:
> >
> > On Thu, Dec 13, 2018 at 01:29:08PM +0100, Anders Roxell wrote:
> > > Adding a fragment to make it easier to know what options is needed to
> > > build a kernel to get the that you can debug in qemu.
> >
> > > @@ -0,0 +1,7 @@
> > > +# Enable debug info for gdb
> > > +# CONFIG_COMPILE_TEST is not set
> > > +CONFIG_DEBUG_INFO=y
> > > +CONFIG_GDB_SCRIPTS=y
> >
> > Is this specifically for qemu or is this just good for debugging with
> > GDB in general (eg, via JTAG)?
>
> I haven't tried, and I don't have a JTAG so I could test it =/

The DEBUG_INFO=y and (as a dependency for that) CONFIG_COMPILE_TEST
are definitely needed for all GDB operation. I would assume that
the scripts also work with any other gdb environment, but haven't tried either.

For CONFIG_RANDOMIZE_BASE, I'm not actually sure if that helps or
not. I think I originally suggested to Anders to turn that off when he
was analyzing a bug, but I don't know if it helped or if it works just
as well without that.

        Arnd

Re: [RFC PATCH 1/3] config: provide a fragment to enable gdb for qemu

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

On Tue, Dec 18, 2018 at 10:07:21AM +0100, Arnd Bergmann wrote:
> On Tue, Dec 18, 2018 at 9:45 AM Anders Roxell <anders.roxell@linaro.org> wrote:
> > On Thu, 13 Dec 2018 at 13:40, Mark Brown <broonie@kernel.org> wrote:

> > > Is this specifically for qemu or is this just good for debugging with
> > > GDB in general (eg, via JTAG)?

> > I haven't tried, and I don't have a JTAG so I could test it =/

> The DEBUG_INFO=y and (as a dependency for that) CONFIG_COMPILE_TEST
> are definitely needed for all GDB operation. I would assume that
> the scripts also work with any other gdb environment, but haven't tried either.

I'm fairly sure the requirements are identical, though it has been quite
some time since I tried and I don't have relevant hardware any more so
can't confirm.

> For CONFIG_RANDOMIZE_BASE, I'm not actually sure if that helps or
> not. I think I originally suggested to Anders to turn that off when he
> was analyzing a bug, but I don't know if it helped or if it works just
> as well without that.

Yeah, I'd think it'd be helpful to turn that off.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[RFC PATCH 2/3] lib/ubsan: default UBSAN_ALIGNMENT to not set

[Anders Roxell]

When booting an allmodconfig kernel, there are a lot of false-positives.
With a message like this 'UBSAN: Undefined behaviour in...' with a call
trace that follows.

Reworked so that when building a allmodconfig kernel that turns
everything into '=m' or '=y' will turn off UBSAN_ALIGNMENT.

Co-developed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
 lib/Kconfig.ubsan | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index 98fa559ebd80..a2ae4a8e4fa6 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -27,15 +27,19 @@ config UBSAN_SANITIZE_ALL
 	  Enabling this option will get kernel image size increased
 	  significantly.
 
-config UBSAN_ALIGNMENT
-	bool "Enable checking of pointers alignment"
+config UBSAN_NO_ALIGNMENT
+	bool "Disable checking of pointers alignment"
 	depends on UBSAN
-	default y if !HAVE_EFFICIENT_UNALIGNED_ACCESS
+	default y if HAVE_EFFICIENT_UNALIGNED_ACCESS
 	help
-	  This option enables detection of unaligned memory accesses.
-	  Enabling this option on architectures that support unaligned
+	  This option disables the check of unaligned memory accesses.
+	  This option should be used when building allmodconfig.
+	  Disabling this option on architectures that support unaligned
 	  accesses may produce a lot of false positives.
 
+config UBSAN_ALIGNMENT
+	def_bool !UBSAN_NO_ALIGNMENT
+
 config TEST_UBSAN
 	tristate "Module for testing for undefined behavior detection"
 	depends on m && UBSAN
-- 
2.19.2

[RFC PATCH 3/3] arm64: add a new config option KTEST_RUNNABLE

[Anders Roxell]

With this new config option, we can boot a allmodconfig kernel in qemu.
Config options SERIAL_AMBA_PL011, SERIAL_AMBA_PL011_CONSOLE, UNIX needs
to be enabled in order to get a console. Options like CPU_BIG_ENDIAN,
CMDLINE_FORCE, CMDLINE_OVERRIDE and HVC_DCC needs to be disabled.

Co-developed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
 arch/arm64/Kconfig      | 8 ++++++++
 drivers/tty/hvc/Kconfig | 1 +
 init/Kconfig            | 1 +
 3 files changed, 10 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1f52362f8d99..bb17ccb7bab2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -292,6 +292,12 @@ config ARCH_SUPPORTS_UPROBES
 config ARCH_PROC_KCORE_TEXT
 	def_bool y
 
+config KTEST_RUNNABLE
+	bool "Test build kernels that run in qemu for ktest"
+	select SERIAL_AMBA_PL011
+	select SERIAL_AMBA_PL011_CONSOLE
+	select UNIX
+
 source "arch/arm64/Kconfig.platforms"
 
 menu "Kernel Features"
@@ -773,6 +779,7 @@ config ARM64_PA_BITS
 
 config CPU_BIG_ENDIAN
        bool "Build big-endian kernel"
+	depends on !KTEST_RUNNABLE
        help
          Say Y if you plan on running a kernel in big-endian mode.
 
@@ -1381,6 +1388,7 @@ config CMDLINE
 
 config CMDLINE_FORCE
 	bool "Always use the default kernel command string"
+	depends on !KTEST_RUNNABLE
 	help
 	  Always use the default kernel command string, even if the boot
 	  loader passes other arguments to the kernel.
diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
index 4293c172e120..44e23c2388bd 100644
--- a/drivers/tty/hvc/Kconfig
+++ b/drivers/tty/hvc/Kconfig
@@ -82,6 +82,7 @@ config HVC_UDBG
 config HVC_DCC
        bool "ARM JTAG DCC console"
        depends on ARM || ARM64
+	depends on !KTEST_RUNNABLE
        select HVC_DRIVER
        help
          This console uses the JTAG DCC on ARM to create a console under the HVC
diff --git a/init/Kconfig b/init/Kconfig
index b633716e48f5..3ea5297b7305 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1844,6 +1844,7 @@ config CMDLINE_PREPEND
 config CMDLINE_OVERRIDE
 	bool "Built-in command line overrides boot loader arguments"
 	depends on CMDLINE_BOOL
+	depends on !KTEST_RUNNABLE
 	help
 	  Set this option to 'Y' to have the kernel ignore the boot loader
 	  command line, and use ONLY the built-in command line. In this case
-- 
2.19.2

Re: [RFC PATCH 3/3] arm64: add a new config option KTEST_RUNNABLE

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Thu, Dec 13, 2018 at 01:29:10PM +0100, Anders Roxell wrote:

> With this new config option, we can boot a allmodconfig kernel in qemu.
> Config options SERIAL_AMBA_PL011, SERIAL_AMBA_PL011_CONSOLE, UNIX needs
> to be enabled in order to get a console. Options like CPU_BIG_ENDIAN,
> CMDLINE_FORCE, CMDLINE_OVERRIDE and HVC_DCC needs to be disabled.

Does ktest really not run with BIG_ENDIAN?  

> +config KTEST_RUNNABLE
> +	bool "Test build kernels that run in qemu for ktest"
> +	select SERIAL_AMBA_PL011
> +	select SERIAL_AMBA_PL011_CONSOLE
> +	select UNIX

The opposite angle for my question on patch 1 I guess but is this really
a generic thing for running ktest?  It seems like it's specific to qemu
(and other systems which have the PL011 as the console serial port).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC PATCH 3/3] arm64: add a new config option KTEST_RUNNABLE

[Mark Rutland]

On Thu, Dec 13, 2018 at 03:18:23PM +0000, Mark Brown wrote:
> On Thu, Dec 13, 2018 at 01:29:10PM +0100, Anders Roxell wrote:
> 
> > With this new config option, we can boot a allmodconfig kernel in qemu.
> > Config options SERIAL_AMBA_PL011, SERIAL_AMBA_PL011_CONSOLE, UNIX needs
> > to be enabled in order to get a console. Options like CPU_BIG_ENDIAN,
> > CMDLINE_FORCE, CMDLINE_OVERRIDE and HVC_DCC needs to be disabled.
> 
> Does ktest really not run with BIG_ENDIAN?  
> 
> > +config KTEST_RUNNABLE
> > +	bool "Test build kernels that run in qemu for ktest"
> > +	select SERIAL_AMBA_PL011
> > +	select SERIAL_AMBA_PL011_CONSOLE
> > +	select UNIX
> 
> The opposite angle for my question on patch 1 I guess but is this really
> a generic thing for running ktest?  It seems like it's specific to qemu
> (and other systems which have the PL011 as the console serial port).

This is definitely platform-specific rather than ktest specific.

If I wanted to run ktest in a kvmtool VM, I would not need PL011 at all,
since that uses 8250 and virtio-console.

Thanks,
Mark.

Re: [RFC PATCH 3/3] arm64: add a new config option KTEST_RUNNABLE

[Mark Rutland]

Hi,

As a general thing, please Cc LAKML on patches for arm64.

On Thu, Dec 13, 2018 at 01:29:10PM +0100, Anders Roxell wrote:
> With this new config option, we can boot a allmodconfig kernel in qemu.
> Config options SERIAL_AMBA_PL011, SERIAL_AMBA_PL011_CONSOLE, UNIX needs
> to be enabled in order to get a console. Options like CPU_BIG_ENDIAN,
> CMDLINE_FORCE, CMDLINE_OVERRIDE and HVC_DCC needs to be disabled.
> 
> Co-developed-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
> ---
>  arch/arm64/Kconfig      | 8 ++++++++
>  drivers/tty/hvc/Kconfig | 1 +
>  init/Kconfig            | 1 +
>  3 files changed, 10 insertions(+)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 1f52362f8d99..bb17ccb7bab2 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -292,6 +292,12 @@ config ARCH_SUPPORTS_UPROBES
>  config ARCH_PROC_KCORE_TEXT
>  	def_bool y
>  
> +config KTEST_RUNNABLE
> +	bool "Test build kernels that run in qemu for ktest"
> +	select SERIAL_AMBA_PL011
> +	select SERIAL_AMBA_PL011_CONSOLE
> +	select UNIX
> +

As Mark Brown points out, the PL011 bits are platform-specific, and
don't directly relate to ktest.

The UNIX part is simply because that can be built as a module.

Is it possible to use an allyesconfig rather than an allmodconfig? That
would leave all relevant options built-in.

> diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
> index 4293c172e120..44e23c2388bd 100644
> --- a/drivers/tty/hvc/Kconfig
> +++ b/drivers/tty/hvc/Kconfig
> @@ -82,6 +82,7 @@ config HVC_UDBG
>  config HVC_DCC
>         bool "ARM JTAG DCC console"
>         depends on ARM || ARM64
> +	depends on !KTEST_RUNNABLE
>         select HVC_DRIVER
>         help
>           This console uses the JTAG DCC on ARM to create a console under the HVC

... this is just a hack around the DCC driver being dodgy.

We should fix that to only probe if explicitly requested at run-time via
a command line argument.

Thanks,
Mark.

Re: [RFC PATCH 3/3] arm64: add a new config option KTEST_RUNNABLE

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

On Mon, Jan 07, 2019 at 02:43:57PM +0000, Mark Rutland wrote:

> Is it possible to use an allyesconfig rather than an allmodconfig? That
> would leave all relevant options built-in.

The allyesconfig would make it more difficult to apply this approach to
real hardware which is part of the goal here - the idea was to come up
with a way of making runnable configurations which are likely to be
usable with random userspace testsuites in order to avoid needing ever
expanding combinations of builds.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC PATCH 3/3] arm64: add a new config option KTEST_RUNNABLE

[Mark Rutland]

On Mon, Jan 07, 2019 at 05:55:31PM +0000, Mark Brown wrote:
> On Mon, Jan 07, 2019 at 02:43:57PM +0000, Mark Rutland wrote:
> 
> > Is it possible to use an allyesconfig rather than an allmodconfig? That
> > would leave all relevant options built-in.
> 
> The allyesconfig would make it more difficult to apply this approach to
> real hardware which is part of the goal here - the idea was to come up
> with a way of making runnable configurations which are likely to be
> usable with random userspace testsuites in order to avoid needing ever
> expanding combinations of builds.

Ok.

Is it somehow possible to fuse defconfig with an allmodconfig, with
defconfig's CONFIG_FOO=y taking precedence over allmodconfig's
CONFIG_FOO=m?

IIUC, that would give you the necessary platform bits, at least for
anything supported by defconfig. That would also happen to get
CONFIG_UNIX=y, too.

Thanks,
Mark.