Re: [OSSTEST PATCH] ap-common: Switch to Linux 6.1 by default on x86 + drop dom0 i386

From: Anthony PERARD <anthony.perard@cloud.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Juergen Gross <jgross@suse.com>
Subject: Re: [OSSTEST PATCH] ap-common: Switch to Linux 6.1 by default on x86 + drop dom0 i386
Date: Wed, 13 Mar 2024 16:51:05 +0000	[thread overview]
Message-ID: <e6e2849d-dd44-4842-9c8a-d861df49ecff@perard> (raw)
In-Reply-To: <ZfGEa_u3VZv-CuTq@macbook>

On Wed, Mar 13, 2024 at 11:48:11AM +0100, Roger Pau Monné wrote:
> On Tue, Mar 12, 2024 at 05:19:46PM +0000, Anthony PERARD wrote:
> > On Mon, Mar 11, 2024 at 06:27:52PM +0100, Roger Pau Monné wrote:
> > > On Wed, Mar 06, 2024 at 11:47:41AM +0000, Anthony PERARD wrote:
> > > > Gone, but replaced by a new test-amd64-amd64-*:
> > > > - test-amd64-i386-libvirt-raw
> > > > - test-amd64-i386-xl-vhd
> > > > 
> > > > Some test-amd64-amd64-* are also changed:
> > > > - test-amd64-amd64-libvirt-vhd
> > > > - test-amd64-amd64-qemuu-freebsd11-amd64
> > > > - test-amd64-amd64-qemuu-freebsd12-amd64
> > > > - test-amd64-amd64-xl-qcow2
> > > > + test-amd64-amd64-freebsd11-amd64
> > > > + test-amd64-amd64-freebsd12-amd64
> > > > + test-amd64-amd64-libvirt-qcow2
> > > > + test-amd64-amd64-libvirt-raw
> > > > + test-amd64-amd64-xl-vhd
> > > 
> > > Is this purely a name change, or there's some kind of functional
> > > change?
> > 
> > For test-amd64-amd64-qemuu-freebsd1{1,2}-amd64, it looks like the
> > "-qemuu" is a bug. The freebsd jobs shouldn't have used $qemuu_suffix,
> > as it doesn't use $qemuu_runvar. So I'm guessing $qemuu_suffix was just
> > the value left from a previous call of test_matrix_do_one() with
> > dom0arch==i386. The new name is already used by "linux-linus" branch.
> 
> FTAOD, could you mention this in the commit message?
> 
> FreeBSD doesn't use `$qemuu_runvar` because it was always using QEMU
> upstream (when the FreeBSD test was added we decided to only test with
> QEMU upstream).  So there's indeed no `-qemut` variant, but by
> dropping the -qemuu prefix it could be confused with a PV guest
> based test.

I thought "-qemuu" just meant we were using the qemu-upstream as
device-model instead of the default one, but it seems that instead no
jobs are generated with "$qemuu_suffix==''", (or only for Xen 4.2 and
older). So now I guess that all HVM tests have either -qemut or -qemuu.

We that, I guess it makes sense to keep "-qemuu" for freebsd tests. That
would just change branch "linux-linus" and "linux-6.1". I'll prepare a
new patch with that.

> > As for the few changes in {xl,libvirt}-{raw,vhd,qcow2} tests, this is
> > because of
> > - f536e834f673 ("make-flight: Trim the matrix of disk format flights")
> > - 5c70735f177f ("fmtarches: Use dom0arches, not hardcoded arch list")
> 
> Probably a dummy question, but why haven't those commits changed the
> output of make-flight earlier?  I'm fine with the change, but I don't
> really get why we are seeing it only now.

Looking at the commit message, they did some changes.

But the second commit might have made changes in a way that wasn't
intended. For example, "xl-raw" test disappear.

First commit intended to have exactly 6 jobs spread across all arches.
It used as input "i386 armhf amd64 armhf" and just check that the arch
corresponded to the current "$dom0arch". The function is called several
time with different $dom0arch.

The second mention commit changes to use $dom0arches which takes
different values " i386 amd64", then " armhf" and " arm64". The extra
space at the beginning of the string is why there's no more "xl-raw"
tests, because now '' became one of the possible dom0arch which of course
it doesn't exist. Then we have the same exact list of 3 test on armhf
and arm64, which defeat the original intention of the first mention
commit.

So, now I feel like I need to rework do_pv_debian_tests() to at least
re-add "xl-raw" test, and maybe keep only 6 toolstack-disk_format tests
spread across all arches? That could maybe reduce the number of tests on
arm64 which is the current bottleneck.

Cheers,

-- 
Anthony PERARD