diff mbox series

[RFC] kunit: tool: add 'mte=on' qemu arg on arm64

Message ID 20240214124131.990872-1-paul.heidekrueger@tum.de
State New
Headers
Series [RFC] kunit: tool: add 'mte=on' qemu arg on arm64 |

Commit Message

Paul Heidekrüger Feb. 14, 2024, 12:41 p.m. UTC 
  Hi!

I was running some KASan tests with kunit.py recently and noticed that
when KASan is run in hw tags mode, we manually have to add the required
`mte=on` option to kunit_tool's qemu invocation, as the tests will
otherwise crash.

To make life easier, I was looking into ways for kunit.py to recognise
when MTE support was required and set the option automatically.

All solutions I could come up with for having kunit_tool conditionally
pass `mte=on` to qemu, either entailed duplicate code or required
parsing of kernel's config file again. I was working under the
assumption that only after configuring the kernel we would know whether
the 'mte=on' option was necessary, as CONFIG_ARM64_MTE is not visible
before.

Only afterwads did I realise that the qemu arm64 config that kunit_tool
falls back on, uses the `virt` machine, which supports MTE in any case.
So, could it be as easy as just adding the `mte=on` option to
kunit_tool's arm64 config? Would this be a welcome addition? 

What do you think? 

Many thanks,
Paul

Signed-off-by: Paul Heidekrüger <paul.heidekrueger@tum.de>
---
 tools/testing/kunit/qemu_configs/arm64.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

David Gow Feb. 20, 2024, 12:46 a.m. UTC | #1 
On Wed, 14 Feb 2024 at 20:41, Paul Heidekrüger <paul.heidekrueger@tum.de> wrote:
>
> Hi!
>
> I was running some KASan tests with kunit.py recently and noticed that
> when KASan is run in hw tags mode, we manually have to add the required
> `mte=on` option to kunit_tool's qemu invocation, as the tests will
> otherwise crash.
>
> To make life easier, I was looking into ways for kunit.py to recognise
> when MTE support was required and set the option automatically.
>
> All solutions I could come up with for having kunit_tool conditionally
> pass `mte=on` to qemu, either entailed duplicate code or required
> parsing of kernel's config file again. I was working under the
> assumption that only after configuring the kernel we would know whether
> the 'mte=on' option was necessary, as CONFIG_ARM64_MTE is not visible
> before.
>
> Only afterwads did I realise that the qemu arm64 config that kunit_tool
> falls back on, uses the `virt` machine, which supports MTE in any case.
> So, could it be as easy as just adding the `mte=on` option to
> kunit_tool's arm64 config? Would this be a welcome addition?
>
> What do you think?
>
> Many thanks,
> Paul
>
> Signed-off-by: Paul Heidekrüger <paul.heidekrueger@tum.de>
> ---

I think this is fine. I'd be a little bit concerned if this were only
supported in newer qemu versions, but it seems to go back to 6.2, so
should be okay. I think it's better to just enable it unconditionally
by default rather than trying to parse the config.

The KASAN tests seemed to work fine with HW tags in my testing here. I
do wonder if there's a way to make the tests skip themselves if MTE
isn't available: is there a way of doing a runtime check for this?

Regardless, this is:
Reviewed-by: David Gow <davidgow@google.com>

-- David

>  tools/testing/kunit/qemu_configs/arm64.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/kunit/qemu_configs/arm64.py b/tools/testing/kunit/qemu_configs/arm64.py
> index d3ff27024755..a525f7e1093b 100644
> --- a/tools/testing/kunit/qemu_configs/arm64.py
> +++ b/tools/testing/kunit/qemu_configs/arm64.py
> @@ -9,4 +9,4 @@ CONFIG_SERIAL_AMBA_PL011_CONSOLE=y''',
>                            qemu_arch='aarch64',
>                            kernel_path='arch/arm64/boot/Image.gz',
>                            kernel_command_line='console=ttyAMA0',
> -                          extra_qemu_params=['-machine', 'virt', '-cpu', 'max,pauth-impdef=on'])
> +                          extra_qemu_params=['-machine', 'virt,mte=on', '-cpu', 'max,pauth-impdef=on'])
> --
> 2.40.1
>
Paul Heidekrüger Feb. 23, 2024, 8:52 p.m. UTC | #2 
On 20.02.2024 08:46, David Gow wrote:
> On Wed, 14 Feb 2024 at 20:41, Paul Heidekrüger <paul.heidekrueger@tum.de> wrote:
> >
> > Hi!
> >
> > I was running some KASan tests with kunit.py recently and noticed that
> > when KASan is run in hw tags mode, we manually have to add the required
> > `mte=on` option to kunit_tool's qemu invocation, as the tests will
> > otherwise crash.
> >
> > To make life easier, I was looking into ways for kunit.py to recognise
> > when MTE support was required and set the option automatically.
> >
> > All solutions I could come up with for having kunit_tool conditionally
> > pass `mte=on` to qemu, either entailed duplicate code or required
> > parsing of kernel's config file again. I was working under the
> > assumption that only after configuring the kernel we would know whether
> > the 'mte=on' option was necessary, as CONFIG_ARM64_MTE is not visible
> > before.
> >
> > Only afterwads did I realise that the qemu arm64 config that kunit_tool
> > falls back on, uses the `virt` machine, which supports MTE in any case.
> > So, could it be as easy as just adding the `mte=on` option to
> > kunit_tool's arm64 config? Would this be a welcome addition?
> >
> > What do you think?
> >
> > Many thanks,
> > Paul
> >
> > Signed-off-by: Paul Heidekrüger <paul.heidekrueger@tum.de>
> > ---
> 
> I think this is fine. I'd be a little bit concerned if this were only
> supported in newer qemu versions, but it seems to go back to 6.2, so
> should be okay. I think it's better to just enable it unconditionally
> by default rather than trying to parse the config.
> 
> The KASAN tests seemed to work fine with HW tags in my testing here. I
> do wonder if there's a way to make the tests skip themselves if MTE
> isn't available: is there a way of doing a runtime check for this?

Huh, interesting. Even though "mte=on" isn't set on your side?

I get the following output without the MTE patch.

	➜   ./tools/testing/kunit/kunit.py run --kunitconfig=mm/kasan/.kunitconfig --arch=arm64
	[14:08:11] Configuring KUnit Kernel ...
	[14:08:11] Building KUnit Kernel ...
	Populating config with:
	$ make ARCH=arm64 O=.kunit olddefconfig
	Building with:
	$ make ARCH=arm64 O=.kunit --jobs=8
	[14:08:23] Starting KUnit Kernel (1/1)...
	[14:08:23] ============================================================
	Running tests with:
	$ qemu-system-aarch64 -nodefaults -m 1024 -kernel .kunit/arch/arm64/boot/Image.gz -append 'kunit.enable=1 console=ttyAMA0 kunit_shutdown=reboot' -no-reboot -nographic -serial stdio -machine virt -cpu max,pauth-impdef=on
	[14:08:23] kasan: test: Can't run KASAN tests with KASAN disabled
	[14:08:23]     # kasan:     # failed to initialize (-1)
	[14:08:23] [FAILED] kasan
	[14:08:23] ============================================================
	[14:08:23] Testing complete. Ran 1 tests: failed: 1
	[14:08:24] Elapsed time: 12.374s total, 0.001s configuring, 11.937s building, 0.382s running

Where the mentioned .kunitconfig has the following options set for KASan.

	CONFIG_KUNIT=y
	CONFIG_KUNIT_ALL_TESTS=n

	CONFIG_FTRACE=y
	CONFIG_STACK_TRACER=y 

	CONFIG_KASAN=y
	CONFIG_KASAN_HW_TAGS=y
	CONFIG_KASAN_KUNIT_TEST=y

With the MTE patch from my previous email, everything works just fine.

Based on that, do you have a guess why it's working for you and why it isn't for 
me?

> Regardless, this is:
> Reviewed-by: David Gow <davidgow@google.com>

Thanks! I'll be sending a non-RFC patch shortly.

Many thanks,
Paul
diff mbox series

Patch

diff --git a/tools/testing/kunit/qemu_configs/arm64.py b/tools/testing/kunit/qemu_configs/arm64.py
index d3ff27024755..a525f7e1093b 100644
--- a/tools/testing/kunit/qemu_configs/arm64.py
+++ b/tools/testing/kunit/qemu_configs/arm64.py
@@ -9,4 +9,4 @@  CONFIG_SERIAL_AMBA_PL011_CONSOLE=y''',
 			   qemu_arch='aarch64',
 			   kernel_path='arch/arm64/boot/Image.gz',
 			   kernel_command_line='console=ttyAMA0',
-			   extra_qemu_params=['-machine', 'virt', '-cpu', 'max,pauth-impdef=on'])
+			   extra_qemu_params=['-machine', 'virt,mte=on', '-cpu', 'max,pauth-impdef=on'])