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
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 <[email protected]>
---
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
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 <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Anders Roxell <[email protected]>
---
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
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)?
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).
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 <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Anders Roxell <[email protected]>
---
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
On Thu, 13 Dec 2018 at 13:40, Mark Brown <[email protected]> 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
On Tue, Dec 18, 2018 at 9:45 AM Anders Roxell <[email protected]> wrote:
>
> On Thu, 13 Dec 2018 at 13:40, Mark Brown <[email protected]> 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
On Tue, Dec 18, 2018 at 10:07:21AM +0100, Arnd Bergmann wrote:
> On Tue, Dec 18, 2018 at 9:45 AM Anders Roxell <[email protected]> wrote:
> > On Thu, 13 Dec 2018 at 13:40, Mark Brown <[email protected]> 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.
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 <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Signed-off-by: Anders Roxell <[email protected]>
> ---
> 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.
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.
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.
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.