Add more arches to kernelci via QEMU devices (part2)

Add more arches to kernelci via QEMU devices (part2)

[Corentin Labbe]

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

Hello

My work of supporting all qemus in LAVA is nearly done.
It is now possible to create qemus job for lots of arch like
arm,arm64,sparc,sparc64,powerpc,ppc64,nios2,xtensa,mips,mips64,alpha,openrisc,etc...

You can find the project I use for generating qemu jobs here:
https://github.com/montjoie/bbci/
and boot results here http://kernel.montjoie.ovh/lava/

Now bringing qemu boot in kernelci rise some problems:
1) machine selection
Kernelci currently select boards to boot by checking the arch and presence
of dtb in a build.
This will be insufficient when booting some arches like ppc.
So we must add boot selection via CONFIGs presence in the builded .config.
Note that adding CONFIG requirements for each board will bring an extra new
magic randomconfig/boot way.
You can find in the template section of
https://github.com/montjoie/bbci/blob/master/all.yaml
for each board examples of CONFIGs needed
This will need to be copied in kernelci-core/test-configs.yaml

2) device aliases
I boot currently more than 20 qemu machines, so hiding all thoses different
machines under a single device-type will be bad.
So for displaying results on kernelci we will need device aliases.
But how to name them ?
qemu-arch-machine ? (ex: qemu-arm-cubieboard, qemu-sparc-ss10)
or just qemu-machine ?

3) qemu versions
Since each lab are different, we wiil hit the problem of qemu versions
divergences.
I have no easy way to handle it. Perhaps with LAVA tags ?

4) defconfig hacks
Some qemu machines can only be booted if defconfig are hacked.
Examples are
- need to disable cryptohw in exynos/cubieboard
- need to disable some CONFIG for omap1
Does kernelci want to build extra defconfig+hacks ?

My next move is to create a PR for adding CONFIGs selection and qemu arm64
boots as an example.

Regards

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

Re: Add more arches to kernelci via QEMU devices (part2)

[Mark Brown]

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

On Fri, Jun 21, 2019 at 11:24:16AM +0200, Corentin Labbe wrote:

> 4) defconfig hacks
> Some qemu machines can only be booted if defconfig are hacked.
> Examples are
> - need to disable cryptohw in exynos/cubieboard
> - need to disable some CONFIG for omap1
> Does kernelci want to build extra defconfig+hacks ?

These seem like bugs, we probably shouldn't be using those emulations if
they don't work - it's not like it's the only way to get coverage of 32
bit Arm or anything.

One question if we're going to start covering new architectures is where
are the builders coming from?

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

Re: Add more arches to kernelci via QEMU devices (part2)

[Kevin Hilman]

"Corentin Labbe" <clabbe@baylibre.com> writes:

> Hello
>
> My work of supporting all qemus in LAVA is nearly done.
> It is now possible to create qemus job for lots of arch like
> arm,arm64,sparc,sparc64,powerpc,ppc64,nios2,xtensa,mips,mips64,alpha,openrisc,etc...
>
> You can find the project I use for generating qemu jobs here:
> https://github.com/montjoie/bbci/
> and boot results here http://kernel.montjoie.ovh/lava/
>
> Now bringing qemu boot in kernelci rise some problems:
> 1) machine selection
> Kernelci currently select boards to boot by checking the arch and presence
> of dtb in a build.
> This will be insufficient when booting some arches like ppc.
> So we must add boot selection via CONFIGs presence in the builded .config.
> Note that adding CONFIG requirements for each board will bring an extra new
> magic randomconfig/boot way.
> You can find in the template section of
> https://github.com/montjoie/bbci/blob/master/all.yaml
> for each board examples of CONFIGs needed
> This will need to be copied in kernelci-core/test-configs.yaml

Yeah, you'll need to extend the logic around test-configs.yaml to check
for defconfig values.

> 2) device aliases
> I boot currently more than 20 qemu machines, so hiding all thoses different
> machines under a single device-type will be bad.
> So for displaying results on kernelci we will need device aliases.
> But how to name them ?
> qemu-arch-machine ? (ex: qemu-arm-cubieboard, qemu-sparc-ss10)
> or just qemu-machine ?

I suggest qemu-<arch>-<machine>

> 3) qemu versions
> Since each lab are different, we wiil hit the problem of qemu versions
> divergences.
> I have no easy way to handle it. Perhaps with LAVA tags ?

You should at least document the minimum qemu version required.  Are
there out-of-tree patches required still? or is everything available in
upstream qemu?

> 4) defconfig hacks
> Some qemu machines can only be booted if defconfig are hacked.
> Examples are
> - need to disable cryptohw in exynos/cubieboard
> - need to disable some CONFIG for omap1
> Does kernelci want to build extra defconfig+hacks ?

We cant, but it would be best to avoid that if possible.  Can you start
with ones that don't require defconfig hacking?

At least for those specific examples, I don't see the value in testing
those QEMU machines when we already have the physical hardware.

> My next move is to create a PR for adding CONFIGs selection and qemu arm64
> boots as an example.

Sounds good,

Kevin