As noted in [0], SeaBIOS (QEMU default) makes a mess of the terminal,
qboot does not.

It turns out this is actually useful with kunit.py, since the user is
exposed to this issue if they set --raw_output=all.

qboot is also faster than SeaBIOS, but it's is marginal for this
usecase.

[0] https://lore.kernel.org/all/CA+i-1C0wYb-gZ8Mwh3WSVpbk-LF-Uo+njVbASJPe1WXDURoV7A@mail.gmail.com/

Both SeaBIOS and qboot are x86-specific.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 tools/testing/kunit/qemu_configs/x86_64.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/testing/kunit/qemu_configs/x86_64.py b/tools/testing/kunit/qemu_configs/x86_64.py
index dc794907686304b325dbe180149169dd79bcd44f..4a6bf4e048f5b05c889e3b9b03046f14cc9b0bcc 100644
--- a/tools/testing/kunit/qemu_configs/x86_64.py
+++ b/tools/testing/kunit/qemu_configs/x86_64.py
@@ -7,4 +7,6 @@ CONFIG_SERIAL_8250_CONSOLE=y''',
 			   qemu_arch='x86_64',
 			   kernel_path='arch/x86/boot/bzImage',
 			   kernel_command_line='console=ttyS0',
-			   extra_qemu_params=[])
+			   # qboot is faster than SeaBIOS and doesn't mess up
+			   # the terminal.
+			   extra_qemu_params=['-bios', 'qboot.rom'])

---
base-commit: 8ea24baaaa869adeb39c6b9ce7542657a7251b56
change-id: 20250124-kunit-qboot-5201945f7e86

Best regards,
-- 
Brendan Jackman <jackmanb@google.com>

On Fri, 24 Jan 2025 at 19:01, Brendan Jackman <jackmanb@google.com> wrote:
>
> As noted in [0], SeaBIOS (QEMU default) makes a mess of the terminal,
> qboot does not.
>
> It turns out this is actually useful with kunit.py, since the user is
> exposed to this issue if they set --raw_output=all.
>
> qboot is also faster than SeaBIOS, but it's is marginal for this
> usecase.
>
> [0] https://lore.kernel.org/all/CA+i-1C0wYb-gZ8Mwh3WSVpbk-LF-Uo+njVbASJPe1WXDURoV7A@mail.gmail.com/
>
> Both SeaBIOS and qboot are x86-specific.
>
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
> ---

This looks good to me, thanks. My only real concern is that qboot
might need a newer version of qemu, but it seems to have been around
for 10 years, and is working under Debian here, so it's probably fine.

One future idea would be to look into microvms, which might be even
faster. I'll give myself a TODO to experiment with those.

This'll go in post-rc1, but nevertheless, it's:
Reviewed-by: David Gow <davidgow@google.com>

Cheers,
-- David

>  tools/testing/kunit/qemu_configs/x86_64.py | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/kunit/qemu_configs/x86_64.py b/tools/testing/kunit/qemu_configs/x86_64.py
> index dc794907686304b325dbe180149169dd79bcd44f..4a6bf4e048f5b05c889e3b9b03046f14cc9b0bcc 100644
> --- a/tools/testing/kunit/qemu_configs/x86_64.py
> +++ b/tools/testing/kunit/qemu_configs/x86_64.py
> @@ -7,4 +7,6 @@ CONFIG_SERIAL_8250_CONSOLE=y''',
>                            qemu_arch='x86_64',
>                            kernel_path='arch/x86/boot/bzImage',
>                            kernel_command_line='console=ttyS0',
> -                          extra_qemu_params=[])
> +                          # qboot is faster than SeaBIOS and doesn't mess up
> +                          # the terminal.
> +                          extra_qemu_params=['-bios', 'qboot.rom'])
>
> ---
> base-commit: 8ea24baaaa869adeb39c6b9ce7542657a7251b56
> change-id: 20250124-kunit-qboot-5201945f7e86
>
> Best regards,
> --
> Brendan Jackman <jackmanb@google.com>
>

On Fri, 31 Jan 2025 at 09:45, David Gow <davidgow@google.com> wrote:
> One future idea would be to look into microvms, which might be even
> faster. I'll give myself a TODO to experiment with those.

Yeah, that would be cool although I think they require CONFIG_PARAVIRT
which isn't an entirely negligible constraint. Still, microvm doesn't
have to be mandatory.

Anyway, I don't personally think that startup speed is a big issue for
KUnit right now, I only mentioned it as a nice freebie for qboot, the
terminal garbage was my only real motivator.

> This'll go in post-rc1, but nevertheless, it's:
> Reviewed-by: David Gow <davidgow@google.com>

Thanks!