Adding default config options to the tuxrun baseline kernels and enabling sshd

Adding default config options to the tuxrun baseline kernels and enabling sshd

[Alex Bennée]

Hi guys,

I've been working with David on adding testing for the new KVM Xen guest
functionality and had a couple of questions. His original test is based
on fedora and is fairly comprehensive:

  https://git.infradead.org/users/dwmw2/qemu.git/commitdiff/48f78f9bb860dca446e20d6ed8db3aa9d857505f

but we did try building a scratch kernel and using the rest of the
baseline infrastructure which worked well enough:

  https://git.infradead.org/users/dwmw2/qemu.git/commitdiff/8b9e04d1c7c942f51b575b94fd280bd2353f76b6

but obviously the kernel there is pulling directly from tuxsuite so will
time out soon enough. They were built with the following tuxbuild
config:

  version: 1
  name: Xen Guest Kernels
  description: Build Xen Test Kernels
  jobs:
  - builds:
      - {target_arch: x86_64, toolchain: gcc-12, kconfig: [defconfig, "CONFIG_XEN=y", "CONFIG_XEN_PVHVM=y", "CONFIG_XEN_BLKDEV_FRONTEND=y", "CONFIG_XEN_PVHVM_GUEST=y"]}
      - {target_arch: i386, toolchain: gcc-12, kconfig: [defconfig, "CONFIG_XEN=y", "CONFIG_XEN_PVHVM=y", "CONFIG_XEN_BLKDEV_FRONTEND=y", "CONFIG_XEN_PVHVM_GUEST=y"]}
    test: {device: qemu-x86_64, tests: [ltp-smoke]}

The other nice thing about his original tests where using ssh which
avoids a) avoids some of the flakeness of using the serial port and b)
has an explicit success/fail for each command without having to scrape
pass/fail from the log.

So two questions:

  - is there a process for adding kernel options to the baseline kernels
    or should we build our own and store them somewhere?

  - what would it take to get dropbear added to the baseline ext4 images
    so we can enable sshd?

Thanks,

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Adding default config options to the tuxrun baseline kernels and enabling sshd

[Remi Duraffort]

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

Hello Alex,



Le ven. 24 mars 2023 à 12:02, Alex Bennée <alex.bennee@linaro.org> a écrit :

> Hi guys,
>
> I've been working with David on adding testing for the new KVM Xen guest
> functionality and had a couple of questions. His original test is based
> on fedora and is fairly comprehensive:
>
>
> https://git.infradead.org/users/dwmw2/qemu.git/commitdiff/48f78f9bb860dca446e20d6ed8db3aa9d857505f
>
> but we did try building a scratch kernel and using the rest of the
> baseline infrastructure which worked well enough:
>
>
> https://git.infradead.org/users/dwmw2/qemu.git/commitdiff/8b9e04d1c7c942f51b575b94fd280bd2353f76b6
>
> but obviously the kernel there is pulling directly from tuxsuite so will
> time out soon enough. They were built with the following tuxbuild
> config:
>
>   version: 1
>   name: Xen Guest Kernels
>   description: Build Xen Test Kernels
>   jobs:
>   - builds:
>       - {target_arch: x86_64, toolchain: gcc-12, kconfig: [defconfig,
> "CONFIG_XEN=y", "CONFIG_XEN_PVHVM=y", "CONFIG_XEN_BLKDEV_FRONTEND=y",
> "CONFIG_XEN_PVHVM_GUEST=y"]}
>       - {target_arch: i386, toolchain: gcc-12, kconfig: [defconfig,
> "CONFIG_XEN=y", "CONFIG_XEN_PVHVM=y", "CONFIG_XEN_BLKDEV_FRONTEND=y",
> "CONFIG_XEN_PVHVM_GUEST=y"]}
>     test: {device: qemu-x86_64, tests: [ltp-smoke]}
>
> The other nice thing about his original tests where using ssh which
> avoids a) avoids some of the flakeness of using the serial port and b)
> has an explicit success/fail for each command without having to scrape
> pass/fail from the log.
>
> So two questions:
>
>   - is there a process for adding kernel options to the baseline kernels
>     or should we build our own and store them somewhere?
>
>   - what would it take to get dropbear added to the baseline ext4 images
>     so we can enable sshd?
>

The kernels and rootfs are built by this gitlab project:
https://gitlab.com/LinaroLtd/tuxsuite.com/tuxtest/tuxtest-buildroot using
buildroot.
So for sure we can add sshd support quickly. Regarding the support for xen,
this can be added for arm64 if you want (only arm64 or something else)?




> Thanks,
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
>


-- 
Rémi Duraffort
Principal Tech Lead
Automation Software Team
Linaro

[-- Attachment #2: Type: text/html, Size: 3844 bytes --]

Re: Adding default config options to the tuxrun baseline kernels and enabling sshd

[David Woodhouse]

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

On Fri, 2023-03-24 at 13:53 +0100, Remi Duraffort wrote:
> Le ven. 24 mars 2023 à 12:02, Alex Bennée <alex.bennee@linaro.org> a écrit :
> >   version: 1
> >   name: Xen Guest Kernels
> >   description: Build Xen Test Kernels
> >   jobs:
> >   - builds:
> >       - {target_arch: x86_64, toolchain: gcc-12, kconfig: [defconfig, "CONFIG_XEN=y", "CONFIG_XEN_PVHVM=y", "CONFIG_XEN_BLKDEV_FRONTEND=y", "CONFIG_XEN_PVHVM_GUEST=y"]}
> >       - {target_arch: i386, toolchain: gcc-12, kconfig: [defconfig, "CONFIG_XEN=y", "CONFIG_XEN_PVHVM=y", "CONFIG_XEN_BLKDEV_FRONTEND=y", "CONFIG_XEN_PVHVM_GUEST=y"]}
> >     test: {device: qemu-x86_64, tests: [ltp-smoke]}
> 
> 
> The kernels and rootfs are built by this gitlab
> project: https://gitlab.com/LinaroLtd/tuxsuite.com/tuxtest/tuxtest-bu
> ildroot using buildroot.
> So for sure we can add sshd support quickly. Regarding the support
> for xen, this can be added for arm64 if you want (only arm64 or
> something else)?

Thanks. This request was for x86_64 and i386 kernels, rather than
arm64.

I think arm64 Xen support is coming to qemu but it requires real Xen —
while what we're wanting to test here is *emulating* Xen on Linux/KVM,
which isn't something that we support on arm64. So I suspect there's
not a lot of benefit in adding it to the arm64 builds? Vikram, Stefano,
what do you think?

Adding CONFIG_XEN_NETDEV_FRONTEND=y in addition to the above options
would be appreciated too please; we haven't yet made that actually work
in the Xen emulation but we plan to fairly soon.




[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]

Re: Adding default config options to the tuxrun baseline kernels and enabling sshd

[Alex Bennée]

Remi Duraffort <remi.duraffort@linaro.org> writes:

> Hello Alex,
>
> Le ven. 24 mars 2023 à 12:02, Alex Bennée <alex.bennee@linaro.org> a écrit :
>
>  Hi guys,
>
>  I've been working with David on adding testing for the new KVM Xen guest
>  functionality and had a couple of questions. His original test is based
>  on fedora and is fairly comprehensive:

Just mentioning I posted an RFC:

  Subject: [RFC PATCH] tests/avocado: Test Xen guest support under KVM
  Date: Fri, 24 Mar 2023 16:07:19 +0000
  Message-Id: <20230324160719.1790792-1-alex.bennee@linaro.org>

which uses a custom kernel + hand built rootfs for now.

>  The other nice thing about his original tests where using ssh which
>  avoids a) avoids some of the flakeness of using the serial port and b)
>  has an explicit success/fail for each command without having to scrape
>  pass/fail from the log.
>
>  So two questions:
>
>    - is there a process for adding kernel options to the baseline kernels
>      or should we build our own and store them somewhere?
>
>    - what would it take to get dropbear added to the baseline ext4 images
>      so we can enable sshd?
>
> The kernels and rootfs are built by this gitlab project:
> https://gitlab.com/LinaroLtd/tuxsuite.com/tuxtest/tuxtest-buildroot
> using buildroot.

Erm that gives me a 404. I can see various tux* projects under:

  https://gitlab.com/Linaro

but nothing related to tuxtest-buildroot.

> So for sure we can add sshd support quickly.

I enabled dropbear and the following overlay:

  https://gitlab.com/stsquad/buildroot-overlays/-/tree/main/noauth-serial-and-ssh

Obviously this drops any pretence of security but I think the root has
no password anyway so adding /etc/dropbear/defaults with:

  # Allow empty password login
  DROPBEAR_ARGS=-B

is enough. Once pointed at the right place I shall have a go at tweaking
the build.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Adding default config options to the tuxrun baseline kernels and enabling sshd

[Stefano Stabellini]

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

On Fri, 24 Mar 2023, David Woodhouse wrote:
> On Fri, 2023-03-24 at 13:53 +0100, Remi Duraffort wrote:
> > Le ven. 24 mars 2023 à 12:02, Alex Bennée <alex.bennee@linaro.org> a écrit :
> > >   version: 1
> > >   name: Xen Guest Kernels
> > >   description: Build Xen Test Kernels
> > >   jobs:
> > >   - builds:
> > >       - {target_arch: x86_64, toolchain: gcc-12, kconfig: [defconfig, "CONFIG_XEN=y", "CONFIG_XEN_PVHVM=y", "CONFIG_XEN_BLKDEV_FRONTEND=y", "CONFIG_XEN_PVHVM_GUEST=y"]}
> > >       - {target_arch: i386, toolchain: gcc-12, kconfig: [defconfig, "CONFIG_XEN=y", "CONFIG_XEN_PVHVM=y", "CONFIG_XEN_BLKDEV_FRONTEND=y", "CONFIG_XEN_PVHVM_GUEST=y"]}
> > >     test: {device: qemu-x86_64, tests: [ltp-smoke]}
> > 
> > 
> > The kernels and rootfs are built by this gitlab
> > project: https://gitlab.com/LinaroLtd/tuxsuite.com/tuxtest/tuxtest-bu
> > ildroot using buildroot.
> > So for sure we can add sshd support quickly. Regarding the support
> > for xen, this can be added for arm64 if you want (only arm64 or
> > something else)?
> 
> Thanks. This request was for x86_64 and i386 kernels, rather than
> arm64.
> 
> I think arm64 Xen support is coming to qemu but it requires real Xen —
> while what we're wanting to test here is *emulating* Xen on Linux/KVM,
> which isn't something that we support on arm64. So I suspect there's
> not a lot of benefit in adding it to the arm64 builds? Vikram, Stefano,
> what do you think?

Yes, not useful for what we are trying to do.

From my point of view, it would be useful to run a test inside QEMU
(emulating a full aarch64 platform) running Xen, Linux and QEMU (QEMU
running on Linux, all inside QEMU) to test the new xenpvh machine in the
inner QEMU. Not asking, just FYI.