Re: [PATCH 1/2] tests/acceptance: Add PVH boot test
On Fri, Dec 6, 2019 at 11:00 AM Wainer dos Santos Moschetta
wrote:
>
> QEMU 4.0 onward is able to boot an uncompressed kernel
> image by using the x86/HVM direct boot ABI. It needs
> Linux >= 4.21 built with CONFIG_PVH=y.
>
> This introduces an acceptance test which checks an
> uncompressed Linux kernel image boots properly.
>
> Signed-off-by: Wainer dos Santos Moschetta
> ---
> tests/acceptance/pvh.py | 48 +
> 1 file changed, 48 insertions(+)
> create mode 100644 tests/acceptance/pvh.py
>
> diff --git a/tests/acceptance/pvh.py b/tests/acceptance/pvh.py
> new file mode 100644
> index 00..c68489c273
> --- /dev/null
> +++ b/tests/acceptance/pvh.py
> @@ -0,0 +1,48 @@
> +# Copyright (c) 2019 Red Hat, Inc.
> +#
> +# Author:
> +# Wainer dos Santos Moschetta
> +#
> +# This work is licensed under the terms of the GNU GPL, version 2 or
> +# later. See the COPYING file in the top-level directory.
> +
> +"""
> +x86/HVM direct boot acceptance tests.
> +"""
> +
> +from avocado.utils.kernel import KernelBuild
> +from avocado_qemu import Test
> +from avocado_qemu import wait_for_console_pattern
> +
> +
> +class Pvh(Test):
> +"""
> +Test suite for x86/HVM direct boot feature.
> +
> +:avocado: tags=slow,arch=x86_64,machine=q35
> +"""
> +def test_boot_vmlinux(self):
> +"""
> +Boot uncompressed kernel image.
> +"""
> +# QEMU can boot a vmlinux image for kernel >= 4.21 built
> +# with CONFIG_PVH=y
> +kernel_version = '5.4.1'
> +kbuild = KernelBuild(kernel_version, work_dir=self.workdir)
> +try:
> +kbuild.download()
> +kbuild.uncompress()
> +kbuild.configure(targets=['defconfig', 'kvmconfig'],
> + extra_configs=['CONFIG_PVH=y'])
> +kbuild.build()
> +except:
> +self.cancel("Unable to build vanilla kernel %s" % kernel_version)
> +
> +self.vm.set_machine('q35')
> +self.vm.set_console()
> +kernel_command_line = 'printk.time=0 console=ttyS0'
> +self.vm.add_args('-kernel', kbuild.vmlinux,
> + '-append', kernel_command_line)
> +self.vm.launch()
> +wait_for_console_pattern(self, 'Kernel command line: %s' %
> + kernel_command_line)
> --
> 2.21.0
>
Tested-by: Willian Rampazzo
Re: Avocado notes from KVM forum 2019
On Mon, Nov 25, 2019 at 3:10 PM Cleber Rosa wrote: > > On Mon, Nov 25, 2019 at 10:58:02AM -0300, Eduardo Habkost wrote: > > Thank you, Philippe, those are great ideas. I have copied them > > to the Avocado+QEMU Trello board so we don't forget about them: > > https://trello.com/b/6Qi1pxVn/avocado-qemu > > > > Additional comments below: > > > > On Mon, Nov 25, 2019 at 01:35:13PM +0100, Philippe Mathieu-Daudé wrote: > > > Hi Cleber, > > > > > > Here are my notes from talking about Avocado with various people during > > > the > > > KVM forum in Lyon last month. > > > > > > All comments are QEMU oriented. > > > > > > > > > 1) Working offline > > > > > > Various people complained Avocado requires online access, and they would > > > like to use it offline. > > > > > > Maintainer workflow example is: > > > > > > - run avocado > > > - hack QEMU, build > > > - git pull > > > - build > > > - hack QEMU > > > (go offline) > > > - hack QEMU > > > - build > > > - run avocado <- FAILS > > > > > > > Ouch. This shouldn't happen even with no explicit --offline > > option. Failure to download artifacts shouldn't make tests > > report failure. > > > > > > Agreed. There are a number of work items already to cover this. One > is a more generic test metadata collection system: > >https://trello.com/c/lumR8u8Y/1526-rfc-nrunner-extended-metadata > > We already have code that can find the required assets, and with that, > we can let the job (not the test) attempt to fulfill those > requirements, skipping the tests if they can not be fulfilled. > > Until this is available, we can wrap the "fetch_asset()" calls and > cancel the test if it fails. > > > > Failure is because mainstream added new tests, which got pulled in, and > > > the > > > user only notice when running avocado again, but offline. > > > Test example is boot_linux_console.py, which added various tests from > > > other > > > subsystems, so the maintainer has to disable the new tests manually to be > > > able to run his previous tests. > > > > > > Expected solution: skip tests when artifact is not available, eventually > > > when the --offline option is used > > > > > > > > > 2) Add artifacts manually to the cache > > > > > > Not all artifacts can be easily downloadable, some are public but require > > > the user to accept an End User License Agreement. > > > Users would like to share their tests with the documentation about > > > where/how > > > to download the requisite files (accepting the EULA) to run the tests. > > > > > > > > > 2b) Add reference to artifact to the cache > > > > > > Group of users might share group of files (like NFS storage) and would > > > like > > > to use directly their remote read-only files, instead of copying it to > > > their > > > home directory. > > > > This sounds nice and useful, but I don't know how to make the > > interface for this usable. > > > > > > I guess this would require an Avocado installation-wide configuration > entry for the available cache directories. IMO given that > configuration is applied, the tests should transparently find assets > in the configured locations. > > > > > > > > > > 3) Provide qemu/avocado-qemu Python packages > > > > > > The mainstream project uses Avocado to test QEMU. Others projects use QEMU > > > to test their code, and would like to automatize that using Avocado. They > > > usually not rebuild QEMU but use a stable binary from distributions. The > > > python classes are not available, so they have to clone QEMU to use > > > Avocado > > > (I guess they only need 5 python files). > > > When running on Continuous Integration, this is overkill, because when you > > > clone QEMU you also clone various other submodules. > > > > I only have one concern, here: I don't think we have the > > bandwidth to start maintaining a stable external Python API. > > Users of those packages will need to be aware that future > > versions of the modules might have incompatible APIs. > > > > My understanding is that we would publish those files as a Python > module with versions matching QEMU. No stability would be promised. > Users can always require a specific version of the Python module that > matches the QEMU version they expect/want to use. > > > > > > > > > > 4) Warn the user when Avocado is too old for the tests > > > > > > Some users tried Avocado following the examples on the mailing list and > > > the > > > one in some commit's descriptions where we simply show "avocado run ...". > > > > Oops. > > > > > They installed the distribution Avocado package and tried and it fails for > > > few of them with no obvious reason (the .log file is hard to read when you > > > are not custom to). IIUC their distribution provides a older Avocado (69?) > > > while we use recent features (72). > > > > > > We never noticed it because we use 'make check-venv' and do not test the > > > distrib Avocado. While we can not test all distribs, we could add a > > > version > > > test if the Avocado
Re: [PATCH-for-4.2? v2 1/2] tests/boot_linux_console: Fetch assets from Debian snapshot archives
On Tue, Nov 26, 2019 at 7:38 PM Philippe Mathieu-Daudé
wrote:
>
> The kernel packaged was fetched from an unstable repository.
> Use the stable snapshot archive instead.
>
> Reviewed-by: Alex Bennée
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> v2:
> - Rebased
> - Dropped Alex's Tested-by tag, since commit 2ecde8b2fb got merged
> since and it changed the tested kernel version.
> ---
> tests/acceptance/boot_linux_console.py | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tests/acceptance/boot_linux_console.py
> b/tests/acceptance/boot_linux_console.py
> index 7e41cebd47..752f776f68 100644
> --- a/tests/acceptance/boot_linux_console.py
> +++ b/tests/acceptance/boot_linux_console.py
> @@ -479,7 +479,8 @@ class BootLinuxConsole(Test):
> :avocado: tags=arch:m68k
> :avocado: tags=machine:q800
> """
> -deb_url = ('http://ftp.ports.debian.org/debian-ports/pool-m68k/main'
> +deb_url = ('https://snapshot.debian.org/archive/debian-ports'
> + '/20191021T083923Z/pool-m68k/main'
> '/l/linux/kernel-image-5.3.0-1-m68k-di_5.3.7-1_m68k.udeb')
> deb_hash = '044954bb9be4160a3ce81f8bc1b5e856b75cccd1'
> try:
Tested-by: Willian Rampazzo
The code was tested and works as expected.
---
Willian
Re: [PATCH-for-5.0? v2 2/2] Revert "Acceptance test: cancel test if m68k kernel packages goes missing"
On Tue, Nov 26, 2019 at 7:38 PM Philippe Mathieu-Daudé wrote: > > Now than we use the stable snapshot archive, we can remove this check. > > This reverts commit d2499aca4bac613d837e2720e7bbe3378bc91245. > > Signed-off-by: Philippe Mathieu-Daudé > --- > tests/acceptance/boot_linux_console.py | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/tests/acceptance/boot_linux_console.py > b/tests/acceptance/boot_linux_console.py > index 752f776f68..ab4c8a5e5a 100644 > --- a/tests/acceptance/boot_linux_console.py > +++ b/tests/acceptance/boot_linux_console.py > @@ -483,10 +483,7 @@ class BootLinuxConsole(Test): > '/20191021T083923Z/pool-m68k/main' > '/l/linux/kernel-image-5.3.0-1-m68k-di_5.3.7-1_m68k.udeb') > deb_hash = '044954bb9be4160a3ce81f8bc1b5e856b75cccd1' > -try: > -deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > -except OSError as exp: > -self.cancel(exp) > +deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > kernel_path = self.extract_from_deb(deb_path, > '/boot/vmlinux-5.3.0-1-m68k') > Tested-by: Willian Rampazzo Although I prefer to be on the safe side and keep the verification, the code works as expected. --- Willian
[Bug 1855002] [NEW] Cannot boot arm kernel images on s390x
Public bug reported: While running the acceptance tests on s390x, the arm tests under qemu/tests/acceptance/boot_linux_console.py will timeout, except the test using u-boot. All the arm tests run without problems on x86 and ppc. This test boots the kernel and wait for a kernel panic to make sure it can boot that kind of kernel on the host running the test. The URL for the kernels are available inside the python test code, but I'm listing them here: Fail: https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/29/Everything/armhfp/os/images/pxeboot/vmlinuz Fail: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20190215-1_armhf.deb Fail: https://snapshot.debian.org/archive/debian/20190928T224601Z/pool/main/l/linux/linux-image-4.19.0-6-armmp_4.19.67-2+deb10u1_armhf.deb Pass: https://raw.githubusercontent.com/Subbaraya-Sundeep/qemu-test-binaries/fa030bd77a014a0b8e360d3b7011df89283a2f0b/spi.bin I tried to manually investigate the problem with the first kernel of the list. The command I used to try to boot it was: /home/linux1/src/v4.2.0-rc3/bin/qemu-system-arm -serial stdio -machine virt -kernel /home/linux1/venv/python3/data/cache/by_location/1d5fdf8018e79b806aa982600c0866b199946efc/vmlinuz -append "printk.time=0 console=ttyAMA0" On an x86 machine, I can see it boots and ends with a kernel panic as expected. On s390x, it just hangs. I also tried to debug with gdb, redirecting the monitor and the serial console to other terminal sessions without success. QEMU version is the latest as of today,tag v4.2.0-rc4, commit 1bdc319ab5d289ce6b822e06fb2b13666fd9278e. s390x system is a Red Hat Enterprise Linux Server 7.7 running as a z/VM 6.4.0 guest at IBM LinuxONE Community Cloud. x86 system is a Fedora 31 running on Intel i7-8650U. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1855002 Title: Cannot boot arm kernel images on s390x Status in QEMU: New Bug description: While running the acceptance tests on s390x, the arm tests under qemu/tests/acceptance/boot_linux_console.py will timeout, except the test using u-boot. All the arm tests run without problems on x86 and ppc. This test boots the kernel and wait for a kernel panic to make sure it can boot that kind of kernel on the host running the test. The URL for the kernels are available inside the python test code, but I'm listing them here: Fail: https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/29/Everything/armhfp/os/images/pxeboot/vmlinuz Fail: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20190215-1_armhf.deb Fail: https://snapshot.debian.org/archive/debian/20190928T224601Z/pool/main/l/linux/linux-image-4.19.0-6-armmp_4.19.67-2+deb10u1_armhf.deb Pass: https://raw.githubusercontent.com/Subbaraya-Sundeep/qemu-test-binaries/fa030bd77a014a0b8e360d3b7011df89283a2f0b/spi.bin I tried to manually investigate the problem with the first kernel of the list. The command I used to try to boot it was: /home/linux1/src/v4.2.0-rc3/bin/qemu-system-arm -serial stdio -machine virt -kernel /home/linux1/venv/python3/data/cache/by_location/1d5fdf8018e79b806aa982600c0866b199946efc/vmlinuz -append "printk.time=0 console=ttyAMA0" On an x86 machine, I can see it boots and ends with a kernel panic as expected. On s390x, it just hangs. I also tried to debug with gdb, redirecting the monitor and the serial console to other terminal sessions without success. QEMU version is the latest as of today,tag v4.2.0-rc4, commit 1bdc319ab5d289ce6b822e06fb2b13666fd9278e. s390x system is a Red Hat Enterprise Linux Server 7.7 running as a z/VM 6.4.0 guest at IBM LinuxONE Community Cloud. x86 system is a Fedora 31 running on Intel i7-8650U. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1855002/+subscriptions
Re: [PATCH v2 1/1] Jobs based on custom runners: add CentOS Stream 8
On Thu, Nov 11, 2021 at 1:06 PM Cleber Rosa wrote: > > This introduces three different parts of a job designed to run > on a custom runner managed by Red Hat. The goals include: > > a) propose a model for other organizations that want to onboard > their own runners, with their specific platforms, build > configuration and tests. > > b) bring awareness to the differences between upstream QEMU and the > version available under CentOS Stream, which is "A preview of > upcoming Red Hat Enterprise Linux minor and major releases". > > c) because of b), it should be easier to identify and reduce the gap > between Red Hat's downstream and upstream QEMU. > > The components of this custom job are: > > I) OS build environment setup code: > > - additions to the existing "build-environment.yml" playbook >that can be used to set up CentOS/EL 8 systems. > > - a CentOS Stream 8 specific "build-environment.yml" playbook >that adds to the generic one. > > II) QEMU build configuration: a script that will produce binaries with > features as similar as possible to the ones built and packaged on > CentOS stream 8. > > III) Scripts that define the minimum amount of testing that the > binaries built with the given configuration (point II) under the > given OS build environment (point I) should be subjected to. > > IV) Job definition: GitLab CI jobs that will dispatch the build/test > jobs (see points #II and #III) to the machine specifically > configured according to #I. > > Signed-off-by: Cleber Rosa > --- > .gitlab-ci.d/custom-runners.yml | 29 +++ > docs/devel/ci-jobs.rst.inc| 7 + > .../org.centos/stream/8/build-environment.yml | 51 + > .../ci/org.centos/stream/8/x86_64/configure | 208 ++ > .../org.centos/stream/8/x86_64/test-avocado | 70 ++ > scripts/ci/org.centos/stream/README | 17 ++ > scripts/ci/setup/build-environment.yml| 38 > 7 files changed, 420 insertions(+) > create mode 100644 scripts/ci/org.centos/stream/8/build-environment.yml > create mode 100755 scripts/ci/org.centos/stream/8/x86_64/configure > create mode 100755 scripts/ci/org.centos/stream/8/x86_64/test-avocado > create mode 100644 scripts/ci/org.centos/stream/README > Maybe it is too late, but just for the records: Reviewed-by: Willian Rampazzo Tested-by: Willian Rampazzo CI job on a custom VM runner: https://gitlab.com/willianrampazzo/qemu/-/jobs/1778451942
Re: [PATCH] gitlab: skip cirrus jobs on master and stable branches
On Tue, Nov 16, 2021 at 8:28 AM Daniel P. Berrangé wrote: > > On the primary QEMU repository we want the CI jobs to run on the staging > branch as a gating CI test. > > Cirrus CI has very limited job concurrency, so if there are too many > jobs triggered they'll queue up and hit the GitLab CI job timeout before > they complete on Cirrus. > > If we let Cirrus jobs run again on the master branch immediately after > merging from staging, that just increases the chances jobs will get > queued and subsequently timeout. > > The same applies for merges to the stable branches. > > User forks meanwhile should be allowed to run Cirrus CI jobs freely. > > Signed-off-by: Daniel P. Berrangé > --- > .gitlab-ci.d/cirrus.yml | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Willian Rampazzo
Re: [PATCH v1 2/6] tests/vm: sort the special variable list
On Mon, Nov 15, 2021 at 11:29 AM Alex Bennée wrote: > > Making the list alphabetical makes it easier to find the config option > you are looking for. > > Signed-off-by: Alex Bennée > --- > tests/vm/Makefile.include | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH v1 3/6] tests/vm: don't build using TCG by default
On Mon, Nov 15, 2021 at 11:29 AM Alex Bennée wrote: > > While it is useful to run these images using TCG their performance > will not be anything like the native guests. Don't do it by default. > > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/393 > Signed-off-by: Alex Bennée > --- > tests/vm/Makefile.include | 17 + > 1 file changed, 13 insertions(+), 4 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH v1 6/6] gitlab-ci: Split custom-runners.yml in one file per runner
On Mon, Nov 15, 2021 at 11:29 AM Alex Bennée wrote: > > From: Philippe Mathieu-Daudé > > To ease maintenance, add the custom-runners/ directory and > split custom-runners.yml in 3 files, all included by the > current custom-runners.yml: > - ubuntu-18.04-s390x.yml > - ubuntu-20.04-aarch64.yml > - centos-stream-8-x86_64.yml > > Signed-off-by: Philippe Mathieu-Daudé > Signed-off-by: Alex Bennée > Message-Id: <2025095608.2436223-1-phi...@redhat.com> > --- > .gitlab-ci.d/custom-runners.yml | 268 +- > .../custom-runners/centos-stream-8-x86_64.yml | 28 ++ > .../custom-runners/ubuntu-18.04-s390x.yml | 118 > .../custom-runners/ubuntu-20.04-aarch64.yml | 118 > 4 files changed, 268 insertions(+), 264 deletions(-) > create mode 100644 .gitlab-ci.d/custom-runners/centos-stream-8-x86_64.yml > create mode 100644 .gitlab-ci.d/custom-runners/ubuntu-18.04-s390x.yml > create mode 100644 .gitlab-ci.d/custom-runners/ubuntu-20.04-aarch64.yml > Reviewed-by: Willian Rampazzo
Re: [PATCH] gitlab-ci/cirrus: Increase timeout to 80 minutes
On Tue, Nov 16, 2021 at 1:33 PM Thomas Huth wrote: > > The jobs on Cirrus-CI sometimes get delayed quite a bit, waiting to > be scheduled, so while the build test itself finishes within 60 minutes, > the total run time of the jobs can be longer due to this waiting time. > Thus let's increase the timeout on the gitlab side a little bit, so > that these jobs are not marked as failing just because of the delay. > > Signed-off-by: Thomas Huth > --- > .gitlab-ci.d/cirrus.yml | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Willian Rampazzo
Re: [qemu-web PATCH] remove deployment phase from CI
On Thu, Nov 18, 2021 at 4:50 AM Paolo Bonzini wrote: > > qemu.org is now served via a reverse proxy from qemu-project.gitlab.io; it > does > not need anymore the rsync step to the QEMU project's shell server. > Remove it from the CI. > > Signed-off-by: Paolo Bonzini > --- > .gitlab-ci.yml | 24 > 1 file changed, 24 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 1/7] python/machine: add @sock_dir property
On Thu, Nov 18, 2021 at 5:50 PM John Snow wrote: > > Analogous to temp_dir and log_dir, add a sock_dir property that defaults > to @temp_dir -- instead of base_temp_dir -- when the user hasn't > overridden the sock dir value in the initializer. > > This gives us a much more unique directory to put sockfiles in by default. > > Signed-off-by: John Snow > --- > python/qemu/machine/machine.py | 17 + > 1 file changed, 13 insertions(+), 4 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 2/7] python/machine: remove _remove_monitor_sockfile property
On Thu, Nov 18, 2021 at 5:49 PM John Snow wrote: > > It doesn't matter if it was the user or the class itself that specified > where the sockfile should be created; the fact is that if we are using a > sockfile here, we created it and we can clean it up. > > Signed-off-by: John Snow > --- > python/qemu/machine/machine.py | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 3/7] python/machine: add instance disambiguator to default nickname
On Thu, Nov 18, 2021 at 5:49 PM John Snow wrote: > > If you create two instances of QEMUMachine(), they'll both create the > same nickname by default -- which is not that helpful. > > Luckily, they'll both create unique temporary directories ... but due to > user configuration, they may share logging and sockfile directories, > meaning two instances can collide. The Python logging will also be quite > confusing, with no differentiation between the two instances. > > Add an instance disambiguator (The memory address of the instance) to > the default nickname to foolproof this in all cases. > > Signed-off-by: John Snow > --- > python/qemu/machine/machine.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 4/7] python/machine: move more variable initializations to _pre_launch
On Thu, Nov 18, 2021 at 5:51 PM John Snow wrote: > > No need to clear them only to set them later. > > Signed-off-by: John Snow > --- > python/qemu/machine/machine.py | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH] tests/avocado: ppc: Add smoke tests for MPC7400 and MPC7450 families
On Fri, Nov 19, 2021 at 10:54 AM Fabiano Rosas wrote: > > These tests ensure that our emulation for these cpus is not completely > broken and we can at least run OpenBIOS on them. > > $ make check-avocado AVOCADO_TESTS=../tests/avocado/ppc_74xx.py > > Signed-off-by: Fabiano Rosas > > --- > Note that the 7450s are currently broken, depending on the fix for > https://gitlab.com/qemu-project/qemu/-/issues/86 that is being > discussed in the thread: > > https://lists.nongnu.org/archive/html/qemu-ppc/2021-11/msg00289.html > --- > tests/avocado/ppc_74xx.py | 134 ++ > 1 file changed, 134 insertions(+) > create mode 100644 tests/avocado/ppc_74xx.py > > diff --git a/tests/avocado/ppc_74xx.py b/tests/avocado/ppc_74xx.py > new file mode 100644 > index 00..72b99d39c0 > --- /dev/null > +++ b/tests/avocado/ppc_74xx.py > @@ -0,0 +1,134 @@ > +# Smoke tests for 74xx cpus (aka G4). > +# > +# Copyright (c) 2021, IBM Corp. > +# > +# This work is licensed under the terms of the GNU GPL, version 2 or > +# later. See the COPYING file in the top-level directory. > + > +from avocado import skip You are not using this import in the file. No need to import it here. Removing the unused import, the code looks good to me, so: Reviewed-by: Willian Rampazzo
Re: [PATCH] tests/avocado: ppc: Add smoke tests for MPC7400 and MPC7450 families
One more comment, sorry. On Fri, Nov 19, 2021 at 10:54 AM Fabiano Rosas wrote: > > These tests ensure that our emulation for these cpus is not completely > broken and we can at least run OpenBIOS on them. > > $ make check-avocado AVOCADO_TESTS=../tests/avocado/ppc_74xx.py > > Signed-off-by: Fabiano Rosas > > --- > Note that the 7450s are currently broken, depending on the fix for > https://gitlab.com/qemu-project/qemu/-/issues/86 that is being > discussed in the thread: > > https://lists.nongnu.org/archive/html/qemu-ppc/2021-11/msg00289.html > --- > tests/avocado/ppc_74xx.py | 134 ++ > 1 file changed, 134 insertions(+) > create mode 100644 tests/avocado/ppc_74xx.py > > diff --git a/tests/avocado/ppc_74xx.py b/tests/avocado/ppc_74xx.py > new file mode 100644 > index 00..72b99d39c0 > --- /dev/null > +++ b/tests/avocado/ppc_74xx.py > @@ -0,0 +1,134 @@ > +# Smoke tests for 74xx cpus (aka G4). > +# > +# Copyright (c) 2021, IBM Corp. > +# > +# This work is licensed under the terms of the GNU GPL, version 2 or > +# later. See the COPYING file in the top-level directory. > + > +from avocado import skip > +from avocado_qemu import QemuSystemTest > +from avocado_qemu import wait_for_console_pattern > + > +class ppc74xxCpu(QemuSystemTest): > + > +timeout = 5 > + > +def test_ppc_7400(self): > +""" > +:avocado: tags=arch:ppc All your tests are using the same "arch" tag, so you can define it in the class and avoid duplication. This is more aesthetic, so it is up to you.
Re: [PATCH 7/7] python/aqmp: fix send_fd_scm for python 3.6.x
On Thu, Nov 18, 2021 at 5:53 PM John Snow wrote: > > 3.6 doesn't play keepaway with the socket object, so we don't need to go > fishing for it on this version. In fact, so long as 'sendmsg' is still > available, it's probably preferable to just use that method and only go > fishing for forbidden details when we absolutely have to. > > Reported-by: Thomas Huth > Signed-off-by: John Snow > --- > python/qemu/aqmp/qmp_client.py | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 5/7] python/machine: handle "fast" QEMU terminations
On Thu, Nov 18, 2021 at 5:49 PM John Snow wrote: > > In the case that the QEMU process actually launches -- but then dies so > quickly that we can't establish a QMP connection to it -- QEMUMachine > currently calls _post_shutdown() assuming that it never launched the VM > process. > > This isn't true, though: it "merely" may have failed to establish a QMP > connection and the process is in the middle of its own exit path. > > If we don't wait for the subprocess, the caller may get a bogus `None` > return for .exitcode(). This behavior was observed from > device-crash-test; after the switch to Async QMP, the timings were > changed such that it was now seemingly possible to witness the failure > of "vm.launch()" *prior* to the exitcode becoming available. > > The semantic of the `_launched` property is changed in this > patch. Instead of representing the condition "launch() executed > successfully", it will now represent "has forked a child process > successfully". This way, wait() when called in the exit path won't > become a no-op. > Signed-off-by: John Snow Nitpick: double signed-off-by > > Signed-off-by: John Snow > --- > python/qemu/machine/machine.py | 19 --- > 1 file changed, 12 insertions(+), 7 deletions(-) > Reviewed-by: Willian Rampazzo
[PATCH] MAINTAINERS: Remove me as a reviewer for the build and test/avocado
Remove me as a reviewer for the Build and test automation and the Integration Testing with the Avocado Framework and add Beraldo Leal. Signed-off-by: Willian Rampazzo --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d3879aa3c1..8f5156bfa7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3469,7 +3469,7 @@ M: Alex Bennée M: Philippe Mathieu-Daudé M: Thomas Huth R: Wainer dos Santos Moschetta -R: Willian Rampazzo +R: Beraldo Leal S: Maintained F: .github/lockdown.yml F: .gitlab-ci.yml @@ -3507,7 +3507,7 @@ W: https://trello.com/b/6Qi1pxVn/avocado-qemu R: Cleber Rosa R: Philippe Mathieu-Daudé R: Wainer dos Santos Moschetta -R: Willian Rampazzo +R: Beraldo Leal S: Odd Fixes F: tests/avocado/ -- 2.33.1
Re: [NOTFORMERGE PATCH 5/5] tests/avocado: Test NetBSD 9.2 on the Jazz Magnum machine
ies to handle files
needed by the tests. You can create a folder called
'test_name.py.data' and put your files there. Then, just use the
'get_data()' to get your file location without the need to handle the
paths.
The documentation about the data folder is here:
https://avocado-framework.readthedocs.io/en/latest/guides/writer/chapters/writing.html?highlight=data#accessing-test-data-files
> +nvram_xz_path = self.fetch_asset('file://' + nvram_xz_path,
> + asset_hash=nvram_xz_hash,
> + algorithm='sha1')
> +mac = '00:00:00:02:03:04'
> +
> +with lzma.open(nvram_xz_path, 'rb') as f_in:
> +with open(nvram_path, 'wb') as f_out:
> +shutil.copyfileobj(f_in, f_out)
> +f_out.seek(nvram_size)
> +f_out.write(b'\0')
> +
> +self.vm.set_console()
> +self.vm.add_args('-bios', ntprom_path,
> + '-drive',
> 'if=scsi,unit=2,media=cdrom,format=raw,file='
> + + drive_path,
> + '-global', 'ds1225y.filename=' + nvram_path,
> + '-nic', 'user,model=dp83932,mac=' + mac)
> +self.vm.launch()
> +
> +console_pattern = 'ARC Multiboot Version 174 (SGI Version 2.6)'
> +wait_for_console_pattern(self, console_pattern)
> +
> +wait_for_console_pattern(self, 'Use the arrow keys to select.')
> +
> +# Press cursor control 'Down' to select the "Run a program" menu
> +exec_command(self, '\x1b[B')
> +
> +program = 'scsi(0)cdrom(2)fdisk(0)boot scsi(0)cdrom(2)fdisk(0)netbsd'
> +exec_command(self, program)
> +wait_for_console_pattern(self, 'NetBSD/arc Bootstrap, Revision 1.1')
> +
> +# Terminal type? [vt100]
> +console_pattern = 'erase ^H, werase ^W, kill ^U, intr ^C, status ^T'
> +wait_for_console_pattern(self, console_pattern)
> +
> +# (I)nstall, (S)hell or (H)alt
> +exec_command_and_wait_for_pattern(self, '', 'Erase is backspace.')
> +exec_command(self, 'S')
> +interrupt_interactive_console_until_pattern(self, '#')
> +
> +exec_command_and_wait_for_pattern(self, 'ifconfig', 'address: ' +
> mac)
> +interrupt_interactive_console_until_pattern(self, '#')
> +
> +exec_command(self, 'ifconfig sn0 10.0.2.3/24')
> +interrupt_interactive_console_until_pattern(self, '#')
> +
> +exec_command_and_wait_for_pattern(self, 'ping -c 3 10.0.2.2',
> +'3 packets transmitted, 3 packets received, 0.0% packet
> loss')
> +
> +exec_command_and_wait_for_pattern(self, 'shutdown -r now',
> + 'rebooting...')
Nice!
Except for the nvram.bin.xz,
Reviewed-by: Willian Rampazzo
Re: [PATCH] MAINTAINERS: Remove me as a reviewer for the build and test/avocado
On Tue, Nov 23, 2021 at 7:37 AM Philippe Mathieu-Daudé wrote: > > On 11/22/21 20:11, Willian Rampazzo wrote: > > Remove me as a reviewer for the Build and test automation and the > > Integration Testing with the Avocado Framework and add Beraldo > > Leal. > > Thank you Willian for your QEMU contributions and reviews, > they helped the community in having a better idea of what > integration testing is and is not, and how to use the > Avocado framework, having a better idea what Avocado can > not do for QEMU needs. Also thank you for improving the > documentation :) My pleasure! Thanks for taking the time to help me understand the basics of QEMU. > > Beraldo, thank you for replacing Willian as an upstream > Avocado <-> QEMU projects bridge :) > > Reviewed-by: Philippe Mathieu-Daudé > > > Signed-off-by: Willian Rampazzo > > --- > > MAINTAINERS | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index d3879aa3c1..8f5156bfa7 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -3469,7 +3469,7 @@ M: Alex Bennée > > M: Philippe Mathieu-Daudé > > M: Thomas Huth > > R: Wainer dos Santos Moschetta > > -R: Willian Rampazzo > > +R: Beraldo Leal > > S: Maintained > > F: .github/lockdown.yml > > F: .gitlab-ci.yml > > @@ -3507,7 +3507,7 @@ W: https://trello.com/b/6Qi1pxVn/avocado-qemu > > R: Cleber Rosa > > R: Philippe Mathieu-Daudé > > R: Wainer dos Santos Moschetta > > -R: Willian Rampazzo > > +R: Beraldo Leal > > S: Odd Fixes > > F: tests/avocado/ > > > > >
[PATCH v3 0/3] tests/Makefile: improvements on make check-acceptance
Improve the documentation about how to run a single test within a file or all the tests from a file using the standalone avocado command. Add a way to run tests based on tags using the `make check-acceptance` command. Add a way to run specific tests using the `make check-acceptance` command. GitLab pipeline: https://gitlab.com/willianrampazzo/qemu/-/pipelines/376122402 Changes from V2: - Rename the environment variable to AVOCADO_TESTS - Adjust the documentation to mention `make check-venv` - Adjust the documentation to mention `avocado list` command - Add the AVOCADO_TAGS implementation patch to the series. Changes from V1: - Rename TESTFILES to AVOCADO_TEST_FILES on patch 2 - Add Suggested-by tag on patch 2 Willian Rampazzo (3): tests/Makefile: allow control over tags during check-acceptance docs/devel/testing: add instruction to run a single acceptance test tests/Makefile: add AVOCADO_TESTS option to make check-acceptance docs/devel/testing.rst | 69 ++ tests/Makefile.include | 17 --- 2 files changed, 82 insertions(+), 4 deletions(-) -- 2.31.1
[PATCH v3 2/3] docs/devel/testing: add instruction to run a single acceptance test
Add instructions to the Acceptance tests section about running a single test file or a test within the test file. Signed-off-by: Willian Rampazzo --- docs/devel/testing.rst | 28 1 file changed, 28 insertions(+) diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst index d1841e35d5..c9f6b97f87 100644 --- a/docs/devel/testing.rst +++ b/docs/devel/testing.rst @@ -754,6 +754,34 @@ may be invoked by running: tests/venv/bin/avocado run $OPTION1 $OPTION2 tests/acceptance/ +Note that if ``make check-acceptance`` was not executed before, it is +possible to create the Python virtual environment with the dependencies +needed running: + + .. code:: + + make check-venv + +It is also possible to run tests from a single file or a single test within +a test file. To run tests from a single file within the build tree, use: + + .. code:: + + tests/venv/bin/avocado run tests/acceptance/$TESTFILE + +To run a single test within a test file, use: + + .. code:: + + tests/venv/bin/avocado run tests/acceptance/$TESTFILE:$TESTCLASS.$TESTNAME + +Valid test names are visible in the output from any previous execution +of Avocado or ``make check-acceptance``, and can also be queried using: + + .. code:: + + tests/venv/bin/avocado list tests/acceptance + Manual Installation --- -- 2.31.1
[PATCH v3 3/3] tests/Makefile: add AVOCADO_TESTS option to make check-acceptance
Add the possibility of running all the tests from a single file, or multiple files, running a single test within a file or multiple tests within multiple files using `make check-acceptance` and the AVOCADO_TESTS environment variable. Suggested-by: Daniel P. Berrangé Signed-off-by: Willian Rampazzo --- docs/devel/testing.rst | 27 +++ tests/Makefile.include | 5 - 2 files changed, 31 insertions(+), 1 deletion(-) diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst index c9f6b97f87..64c9744795 100644 --- a/docs/devel/testing.rst +++ b/docs/devel/testing.rst @@ -746,6 +746,33 @@ tags, see: https://avocado-framework.readthedocs.io/en/latest/guides/user/chapters/tags.html +To run a single test file, a couple of them, or a test within a file +using the ``make check-acceptance`` command, set the ``AVOCADO_TESTS`` +environment variable with the test files or test names. To run all +tests from a single file, use: + + .. code:: + + make check-acceptance AVOCADO_TESTS=$FILEPATH + +The same is valid to run tests from multiple test files: + + .. code:: + + make check-acceptance AVOCADO_TESTS='$FILEPATH1 $FILEPATH2' + +To run a single test within a file, use: + + .. code:: + + make check-acceptance AVOCADO_TESTS=$FILEPATH:$TESTCLASS.$TESTNAME + +The same is valid to run single tests from multiple test files: + + .. code:: + + make check-acceptance AVOCADO_TESTS='$FILEPATH1:$TESTCLASS1.$TESTNAME1 $FILEPATH2:$TESTCLASS2.$TESTNAME2' + The scripts installed inside the virtual environment may be used without an "activation". For instance, the Avocado test runner may be invoked by running: diff --git a/tests/Makefile.include b/tests/Makefile.include index f6484e5b31..e69c4fae53 100644 --- a/tests/Makefile.include +++ b/tests/Makefile.include @@ -88,6 +88,9 @@ clean-tcg: $(CLEAN_TCG_TARGET_RULES) TESTS_VENV_DIR=$(BUILD_DIR)/tests/venv TESTS_VENV_REQ=$(SRC_PATH)/tests/requirements.txt TESTS_RESULTS_DIR=$(BUILD_DIR)/tests/results +ifndef AVOCADO_TESTS + AVOCADO_TESTS=tests/acceptance +endif # Controls the output generated by Avocado when running tests. # Any number of command separated loggers are accepted. For more # information please refer to "avocado --help". @@ -136,7 +139,7 @@ check-acceptance: check-venv $(TESTS_RESULTS_DIR) get-vm-images $(if $(AVOCADO_TAGS),, --filter-by-tags-include-empty \ --filter-by-tags-include-empty-key) \ $(AVOCADO_CMDLINE_TAGS) \ -$(if $(GITLAB_CI),,--failfast) tests/acceptance, \ +$(if $(GITLAB_CI),,--failfast) $(AVOCADO_TESTS), \ "AVOCADO", "tests/acceptance") # Consolidated targets -- 2.31.1
[PATCH v3 1/3] tests/Makefile: allow control over tags during check-acceptance
Although it is possible to run a specific test using the avocado command-line, a user may want to use a specific tag while running the ``make check-acceptance`` during the development or debugging. This allows using the AVOCADO_TAGS environment variable where the user takes total control of which tests should run based on the tags defined. This also makes the check-acceptance command flexible to restrict tests based on tags while running on CI. e.g.: AVOCADO_TAGS="foo bar baz" make check-acceptance Signed-off-by: Willian Rampazzo Tested-by: Wainer dos Santos Moschetta Reviewed-by: Wainer dos Santos Moschetta Reviewed-by: Thomas Huth --- docs/devel/testing.rst | 14 ++ tests/Makefile.include | 12 +--- 2 files changed, 23 insertions(+), 3 deletions(-) diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst index 4a0abbf23d..d1841e35d5 100644 --- a/docs/devel/testing.rst +++ b/docs/devel/testing.rst @@ -732,6 +732,20 @@ available. On Debian and Ubuntu based systems, depending on the specific version, they may be on packages named ``python3-venv`` and ``python3-pip``. +It is also possible to run tests based on tags using the +``make check-acceptance`` command and the ``AVOCADO_TAGS`` environment +variable: + +.. code:: + + make check-acceptance AVOCADO_TAGS=quick + +Note that tags separated with commas have an AND behavior, while tags +separated by spaces have an OR behavior. For more information on Avocado +tags, see: + + https://avocado-framework.readthedocs.io/en/latest/guides/user/chapters/tags.html + The scripts installed inside the virtual environment may be used without an "activation". For instance, the Avocado test runner may be invoked by running: diff --git a/tests/Makefile.include b/tests/Makefile.include index 6e16c05f10..f6484e5b31 100644 --- a/tests/Makefile.include +++ b/tests/Makefile.include @@ -92,7 +92,12 @@ TESTS_RESULTS_DIR=$(BUILD_DIR)/tests/results # Any number of command separated loggers are accepted. For more # information please refer to "avocado --help". AVOCADO_SHOW=app -AVOCADO_TAGS=$(patsubst %-softmmu,-t arch:%, $(filter %-softmmu,$(TARGETS))) +ifndef AVOCADO_TAGS + AVOCADO_CMDLINE_TAGS=$(patsubst %-softmmu,-t arch:%, \ +$(filter %-softmmu,$(TARGETS))) +else + AVOCADO_CMDLINE_TAGS=$(addprefix -t , $(AVOCADO_TAGS)) +endif $(TESTS_VENV_DIR): $(TESTS_VENV_REQ) $(call quiet-command, \ @@ -128,8 +133,9 @@ check-acceptance: check-venv $(TESTS_RESULTS_DIR) get-vm-images $(call quiet-command, \ $(TESTS_VENV_DIR)/bin/python -m avocado \ --show=$(AVOCADO_SHOW) run --job-results-dir=$(TESTS_RESULTS_DIR) \ ---filter-by-tags-include-empty --filter-by-tags-include-empty-key \ -$(AVOCADO_TAGS) \ +$(if $(AVOCADO_TAGS),, --filter-by-tags-include-empty \ + --filter-by-tags-include-empty-key) \ +$(AVOCADO_CMDLINE_TAGS) \ $(if $(GITLAB_CI),,--failfast) tests/acceptance, \ "AVOCADO", "tests/acceptance") -- 2.31.1
Re: [PATCH 05/16] Acceptance Tests: add standard clean up at test tearDown()
Hi, Cleber, On Fri, Sep 24, 2021 at 3:57 PM Cleber Rosa wrote: > > The avocado.Test class, used as the basis of the avocado_qemu.Test > class, performs a clean of temporary directories up as part of its own > tearDown() implementation. > > But the avocado_qemu.Test class is currently missing the same clean > up, as it implemented its own tearDown() method without resorting to > the upper class behavior. > > This brings avocado_qemu.Test behavior in sync with the standard > avocado.Test behavior and prevents temporary directories from > cluttering the test results directory (unless instructed to do so with > Avocado's "--keep-tmp" option). > > Reported-by: Peter Maydell > Signed-off-by: Cleber Rosa > --- > tests/acceptance/avocado_qemu/__init__.py | 1 + > 1 file changed, 1 insertion(+) > There was a comment from Wainer in the original patch and as you were on vacation I submitted a respin last Monday: https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg05117.html I also did some refactoring/fixes to the avocado_qemu here: https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg05212.html
Re: [PATCH 4/6] avocado_qemu: tweak ssh connect method
On Mon, Sep 27, 2021 at 11:12 AM Philippe Mathieu-Daudé
wrote:
>
> On 9/20/21 22:49, Willian Rampazzo wrote:
> > The current implementation will crash if the connection fails as the
> > `time` module is not imported. This fixes the import problem and tweaks
> > the connection to wait progressively when the connection fails.
> >
> > Signed-off-by: Willian Rampazzo
> > ---
> > tests/acceptance/avocado_qemu/__init__.py | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tests/acceptance/avocado_qemu/__init__.py
> > b/tests/acceptance/avocado_qemu/__init__.py
> > index edb9ed7485..c3613f9262 100644
> > --- a/tests/acceptance/avocado_qemu/__init__.py
> > +++ b/tests/acceptance/avocado_qemu/__init__.py
> > @@ -13,6 +13,7 @@
> > import shutil
> > import sys
> > import tempfile
> > +import time
> > import uuid
> >
> > import avocado
> > @@ -305,8 +306,7 @@ def ssh_connect(self, username, credential,
> > credential_is_key=True):
> > self.ssh_session.connect()
> > return
> > except:
> > -time.sleep(4)
>
> 10 * 4 = 40
>
> > -pass
> > +time.sleep(i)
>
> sum([0..10[) = 45
>
> The described tweak. Almost the same, OK.
>
The idea is that, hopefully, the connection will complete in one of
the first tries, so the overall wait time will be less than using a
fixed number. In the worst case, it will wait 5 seconds more than the
original code.
> > self.fail('ssh connection timeout')
> >
> > def ssh_command(self, command):
> >
>
Re: [PATCH v3] nbd/server: Add --selinux-label option
On Thu, Sep 30, 2021 at 5:55 AM Vladimir Sementsov-Ogievskiy wrote: > > 9/30/21 11:47, Richard W.M. Jones wrote: > > Under SELinux, Unix domain sockets have two labels. One is on the > > disk and can be set with commands such as chcon(1). There is a > > different label stored in memory (called the process label). This can > > only be set by the process creating the socket. When using SELinux + > > SVirt and wanting qemu to be able to connect to a qemu-nbd instance, > > you must set both labels correctly first. > > > > For qemu-nbd the options to set the second label are awkward. You can > > create the socket in a wrapper program and then exec into qemu-nbd. > > Or you could try something with LD_PRELOAD. > > > > This commit adds the ability to set the label straightforwardly on the > > command line, via the new --selinux-label flag. (The name of the flag > > is the same as the equivalent nbdkit option.) > > > > A worked example showing how to use the new option can be found in > > this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1984938 > > > > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1984938 > > Signed-off-by: Richard W.M. Jones > > Reviewed-by: Daniel P. Berrangé > > Signed-off-by: Eric Blake > > this should be Reviewed-by? Maybe, because of this: https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg07081.html I got confused with this v3.
Re: [RFC PATCH] .github: move repo lockdown to the v2 configuration
On Mon, Oct 4, 2021 at 12:45 PM Alex Bennée wrote: > > I was getting prompted by GitHub for new permissions but it turns out > per https://github.com/dessant/repo-lockdown/issues/6: > > Repo Lockdown has been rewritten for GitHub Actions, offering new > features and better control over your automation presets. The legacy > GitHub App has been deprecated, and the public instance of the app > has been shut down. > > So this is what I've done. > > Signed-off-by: Alex Bennée > --- > .github/lockdown.yml | 34 > .github/workflows/lockdown.yml | 47 ++ > 2 files changed, 47 insertions(+), 34 deletions(-) > delete mode 100644 .github/lockdown.yml > create mode 100644 .github/workflows/lockdown.yml > > diff --git a/.github/lockdown.yml b/.github/lockdown.yml > deleted file mode 100644 > index d3546bd2bc..00 > --- a/.github/lockdown.yml > +++ /dev/null > @@ -1,34 +0,0 @@ > -# Configuration for Repo Lockdown - https://github.com/dessant/repo-lockdown > - > -# Close issues and pull requests > -close: true > - > -# Lock issues and pull requests > -lock: true > - > -issues: > - comment: | > -Thank you for your interest in the QEMU project. > - > -This repository is a read-only mirror of the project's repostories hosted > -at https://gitlab.com/qemu-project/qemu.git. > -The project does not process issues filed on GitHub. > - > -The project issues are tracked on GitLab: > -https://gitlab.com/qemu-project/qemu/-/issues > - > -QEMU welcomes bug report contributions. You can file new ones on: > -https://gitlab.com/qemu-project/qemu/-/issues/new > - > -pulls: > - comment: | > -Thank you for your interest in the QEMU project. > - > -This repository is a read-only mirror of the project's repostories hosted > -on https://gitlab.com/qemu-project/qemu.git. > -The project does not process merge requests filed on GitHub. > - > -QEMU welcomes contributions of code (either fixing bugs or adding new > -functionality). However, we get a lot of patches, and so we have some > -guidelines about contributing on the project website: > -https://www.qemu.org/contribute/ > diff --git a/.github/workflows/lockdown.yml b/.github/workflows/lockdown.yml > new file mode 100644 > index 00..20e6208487 > --- /dev/null > +++ b/.github/workflows/lockdown.yml > @@ -0,0 +1,47 @@ > +# Configuration for Repo Lockdown - https://github.com/dessant/repo-lockdown > + > +name: 'Repo Lockdown' > + > +on: > + issues: > +types: opened I see the "issues" tab is already disabled on the QEMU repository at GitHub. Maybe we don't need an action for that. > + pull_request_target: > +types: opened > + > +permissions: > + issues: write > + pull-requests: write > + > +jobs: > + action: > +runs-on: ubuntu-latest > +steps: > + - uses: dessant/repo-lockdown@v2 > +with: > + issue-comment: | > +Thank you for your interest in the QEMU project. > + > +This repository is a read-only mirror of the project's > repostories hosted > +at https://gitlab.com/qemu-project/qemu.git. > +The project does not process issues filed on GitHub. > + > +The project issues are tracked on GitLab: > +https://gitlab.com/qemu-project/qemu/-/issues > + > +QEMU welcomes bug report contributions. You can file new ones on: > +https://gitlab.com/qemu-project/qemu/-/issues/new > + lock-issue: true > + close-issue: true > + pull-comment: | > +Thank you for your interest in the QEMU project. > + > +This repository is a read-only mirror of the project's > repostories hosted > +on https://gitlab.com/qemu-project/qemu.git. > +The project does not process merge requests filed on GitHub. > + > +QEMU welcomes contributions of code (either fixing bugs or > adding new > +functionality). However, we get a lot of patches, and so we have > some > +guidelines about contributing on the project website: > +https://www.qemu.org/contribute/ > + lock-pull: true > + close-pull: true > -- > 2.30.2 > > Besides the "issues" comment, it looks good to me. Reviewed-by: Willian Rampazzo
Re: [PATCH 01/16] Acceptance Tests: bump Avocado requirement to 91.0
On Fri, Sep 24, 2021 at 3:57 PM Cleber Rosa wrote: > > Avocado 91.0, brings, among other changes, a switch to a new runner > implementation, known as "nrunner". While my personal testing shows > that it's suitable for running the QEMU tests, there are some > considerations that should be addressed before the change. > > For instance, the "nrunner" implementation will run tests in parallel > by default. With more tests running, and resources shared, some tests > may fail with timeouts on some environments. > > So, for now, let's bump the Avocado version to allow for the other > features to be used. And the "nrunner" implementation to be used by > those that choose to do so. > > More information can be found at the release notes at: >https://avocado-framework.readthedocs.io/en/latest/releases/91_0.html > > Signed-off-by: Cleber Rosa > --- > docs/devel/testing.rst | 12 > tests/Makefile.include | 2 ++ > tests/requirements.txt | 2 +- > 3 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst > index 4a0abbf23d..2818c58ff8 100644 > --- a/docs/devel/testing.rst > +++ b/docs/devel/testing.rst > @@ -740,6 +740,18 @@ may be invoked by running: > >tests/venv/bin/avocado run $OPTION1 $OPTION2 tests/acceptance/ > > +Running tests in parallel > +- > + > +The current ``make check-acceptance`` target continues to use the > +Avocado runner implementation simply known as "runner". But, it's now > +possible to opt-in and choose the "nrunner" implementation, which, > +among other things, allows for parallel execution of tests: > + > +.. code:: > + > + make AVOCADO_RUNNER=nrunner check-acceptance The examples in the documentation are all setting the environment variable at the end of the `make` command. For consistency, I would move the definition of the AVOCADO_RUNNER to the end of the command. > + > Manual Installation > --- > > diff --git a/tests/Makefile.include b/tests/Makefile.include > index 6e16c05f10..ac289a2e41 100644 > --- a/tests/Makefile.include > +++ b/tests/Makefile.include > @@ -92,6 +92,7 @@ TESTS_RESULTS_DIR=$(BUILD_DIR)/tests/results > # Any number of command separated loggers are accepted. For more > # information please refer to "avocado --help". > AVOCADO_SHOW=app > +AVOCADO_RUNNER=runner > AVOCADO_TAGS=$(patsubst %-softmmu,-t arch:%, $(filter %-softmmu,$(TARGETS))) > > $(TESTS_VENV_DIR): $(TESTS_VENV_REQ) > @@ -128,6 +129,7 @@ check-acceptance: check-venv $(TESTS_RESULTS_DIR) > get-vm-images > $(call quiet-command, \ > $(TESTS_VENV_DIR)/bin/python -m avocado \ > --show=$(AVOCADO_SHOW) run > --job-results-dir=$(TESTS_RESULTS_DIR) \ > +--test-runner=$(AVOCADO_RUNNER) \ > --filter-by-tags-include-empty > --filter-by-tags-include-empty-key \ > $(AVOCADO_TAGS) \ > $(if $(GITLAB_CI),,--failfast) tests/acceptance, \ > diff --git a/tests/requirements.txt b/tests/requirements.txt > index a21b59b443..40af24c664 100644 > --- a/tests/requirements.txt > +++ b/tests/requirements.txt > @@ -1,5 +1,5 @@ > # Add Python module requirements, one per line, to be installed > # in the tests/venv Python virtual environment. For more info, > # refer to: https://pip.pypa.io/en/stable/user_guide/#id1 > -avocado-framework==88.1 > +avocado-framework==91.0 > pycdlib==1.11.0 > -- > 2.31.1 > Apart from a tiny documentation change, the code is welcome as it allows using the new Avocado runner. Reviewed-by: Willian Rampazzo
Re: [PATCH 03/16] Acceptance Tests: add mechanism for listing tests
On Fri, Sep 24, 2021 at 3:57 PM Cleber Rosa wrote: > > It is helpful to know the tests that would be executed with a "make > check-acceptance" without executing them. Let's introduce a "make > list-acceptance" rule for that purpose. > > Signed-off-by: Cleber Rosa > --- > tests/Makefile.include | 8 > 1 file changed, 8 insertions(+) > > diff --git a/tests/Makefile.include b/tests/Makefile.include > index 2c03256ae8..d1f90572a7 100644 > --- a/tests/Makefile.include > +++ b/tests/Makefile.include > @@ -17,6 +17,7 @@ ifneq ($(filter $(all-check-targets), check-softfloat),) > @echo " $(MAKE) check-softfloat Run FPU emulation tests" > endif > @echo " $(MAKE) check-acceptance Run acceptance (functional) > tests for currently configured targets" > + @echo " $(MAKE) check-acceptance List acceptance (functional) > tests for currently configured targets" s/check-acceptance/list-acceptance/ > @echo > @echo " $(MAKE) check-report.tap Generates an aggregated TAP test > report" > @echo " $(MAKE) check-venv Creates a Python venv for tests" > @@ -135,6 +136,13 @@ check-acceptance: check-venv $(TESTS_RESULTS_DIR) > get-vm-images > $(if $(GITLAB_CI),,--failfast) tests/acceptance, \ > "AVOCADO", "tests/acceptance") > > +list-acceptance: check-venv > + $(call quiet-command, \ > +$(TESTS_VENV_DIR)/bin/python -m avocado list \ > +--filter-by-tags-include-empty > --filter-by-tags-include-empty-key \ > +$(AVOCADO_TAGS) tests/acceptance, \ It would be interesting to adjust the command to use the $(AVOCADO_CMDLINE_TAGS) and allow users to restrict the tests listed by its tags. > +"AVOCADO", "list tests/acceptance") > + > # Consolidated targets > > .PHONY: check-block check check-clean get-vm-images > -- > 2.31.1 >
Re: [PATCH 11/16] tests/acceptance/boot_xen.py: fetch kernel during test setUp()
On Fri, Sep 24, 2021 at 3:59 PM Cleber Rosa wrote: > > The kernel is a common blob used in all tests. By moving it to the > setUp() method, the "fetch asset" plugin will recognize the kernel and > attempt to fetch it and cache it before the tests are started. > > Signed-off-by: Cleber Rosa > --- > tests/acceptance/boot_xen.py | 13 ++--- > 1 file changed, 6 insertions(+), 7 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 10/16] tests/acceptance/boot_xen.py: unify tags
On Fri, Sep 24, 2021 at 3:58 PM Cleber Rosa wrote: > > Because all tests share the same tags, it's possible to have all of > them at the class level. > > Signed-off-by: Cleber Rosa > --- > tests/acceptance/boot_xen.py | 26 +- > 1 file changed, 5 insertions(+), 21 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 09/16] tests/acceptance/boot_xen.py: merge base classes
On Fri, Sep 24, 2021 at 3:58 PM Cleber Rosa wrote: > > While it's a good practice to have reusable base classes, in this > specific case there's no other user of the BootXenBase class. > > By unifying the class used in this test, we can improve readability > and have the opportunity to add some future improvements in a clearer > fashion. > > Signed-off-by: Cleber Rosa > --- > tests/acceptance/boot_xen.py | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 13/16] tests/acceptance/boot_xen.py: use class attribute
On Fri, Sep 24, 2021 at 3:59 PM Cleber Rosa wrote: > > Rather than defining a single use variable, let's just use the class > attribute directly. > > Signed-off-by: Cleber Rosa > --- > tests/acceptance/boot_xen.py | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 16/16] tests/acceptance/ppc_prep_40p.py: unify tags
On Fri, Sep 24, 2021 at 4:01 PM Cleber Rosa wrote: > > The arch and machine tags apply to all tests, so let's define them > only once. > > Signed-off-by: Cleber Rosa > --- > tests/acceptance/ppc_prep_40p.py | 12 > 1 file changed, 4 insertions(+), 8 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 16/16] tests/acceptance/ppc_prep_40p.py: unify tags
On Wed, Oct 6, 2021 at 4:17 PM Willian Rampazzo wrote: > > On Fri, Sep 24, 2021 at 4:01 PM Cleber Rosa wrote: > > > > The arch and machine tags apply to all tests, so let's define them > > only once. > > > > Signed-off-by: Cleber Rosa > > --- > > tests/acceptance/ppc_prep_40p.py | 12 > > 1 file changed, 4 insertions(+), 8 deletions(-) > > > > Reviewed-by: Willian Rampazzo Also: Tested-by: Willian Rampazzo
Re: [PATCH v4 5/6] tests/acceptance: Add bFLT loader linux-user test
Hi, Phill,
On Mon, Sep 27, 2021 at 1:31 PM Philippe Mathieu-Daudé wrote:
>
> Add a very quick test that runs a busybox binary in bFLT format:
>
> $ AVOCADO_ALLOW_UNTRUSTED_CODE=1 \
> avocado --show=app run -t linux_user tests/acceptance/load_bflt.py
> JOB ID : db94d5960ce564c50904d666a7e259148c27e88f
> JOB LOG: ~/avocado/job-results/job-2019-06-25T10.52-db94d59/job.log
>(1/1) tests/acceptance/load_bflt.py:LoadBFLT.test_stm32: PASS (0.15 s)
> RESULTS: PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 |
> CANCEL 0
> JOB TIME : 0.54 s
>
> Reviewed-by: Willian Rampazzo
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> tests/acceptance/load_bflt.py | 54 +++
> 1 file changed, 54 insertions(+)
> create mode 100644 tests/acceptance/load_bflt.py
>
> diff --git a/tests/acceptance/load_bflt.py b/tests/acceptance/load_bflt.py
> new file mode 100644
> index 000..f071a979d8e
> --- /dev/null
> +++ b/tests/acceptance/load_bflt.py
> @@ -0,0 +1,54 @@
> +# Test the bFLT loader format
> +#
> +# Copyright (C) 2019 Philippe Mathieu-Daudé
> +#
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +
> +import os
> +import bz2
> +import subprocess
> +
> +from avocado import skipUnless
> +from avocado_qemu import QemuUserTest
> +from avocado_qemu import has_cmd
> +
> +
> +class LoadBFLT(QemuUserTest):
> +
> +def extract_cpio(self, cpio_path):
> +"""
> +Extracts a cpio archive into the test workdir
> +
> +:param cpio_path: path to the cpio archive
> +"""
> +cwd = os.getcwd()
> +os.chdir(self.workdir)
> +with bz2.open(cpio_path, 'rb') as archive_cpio:
> +subprocess.run(['cpio', '-i'], input=archive_cpio.read(),
> + stderr=subprocess.DEVNULL)
> +os.chdir(cwd)
> +
> +@skipUnless(*has_cmd('cpio'))
> +@skipUnless(os.getenv('AVOCADO_ALLOW_UNTRUSTED_CODE'), 'untrusted code')
> +def test_stm32(self):
> +"""
> +:avocado: tags=arch:arm
> +:avocado: tags=linux_user
> +:avocado: tags=quick
> +"""
> +# See https://elinux.org/STM32#User_Space
> +rootfs_url = ('https://elinux.org/images/5/51/'
> + 'Stm32_mini_rootfs.cpio.bz2')
> +rootfs_hash = '9f065e6ba40cce7411ba757f924f30fcc57951e6'
> +rootfs_path_bz2 = self.fetch_asset(rootfs_url,
> asset_hash=rootfs_hash)
> +busybox_path = self.workdir + "/bin/busybox"
If there are other changes to this patch, also, change this to use the
`os` library:
busybox_path = os.path.join(self.workdir, "/bin/busybox")
Sorry for not catching this before.
> +
> +self.extract_cpio(rootfs_path_bz2)
> +
> +res = self.run(busybox_path)
> +ver = 'BusyBox v1.24.0.git (2015-02-03 22:17:13 CET) multi-call
> binary.'
> +self.assertIn(ver, res.stdout_text)
> +
> +res = self.run(busybox_path, ['uname', '-a'])
> +unm = 'armv7l GNU/Linux'
> +self.assertIn(unm, res.stdout_text)
> --
> 2.31.1
>
Re: [PATCH v4 1/6] tests/acceptance: Extract QemuBaseTest from Test
@@ def tearDown(self): > vm.shutdown() > self._sd = None > > -def fetch_asset(self, name, > -asset_hash=None, algorithm=None, > -locations=None, expire=None, > -find_only=False, cancel_on_missing=True): > -return super(Test, self).fetch_asset(name, > -asset_hash=asset_hash, > -algorithm=algorithm, > -locations=locations, > -expire=expire, > -find_only=find_only, > -cancel_on_missing=cancel_on_missing) > - > > class LinuxSSHMixIn: > """Contains utility methods for interacting with a guest via SSH.""" > -- > 2.31.1 > Except for one (or two, if you consider the first) small comment, looks good to me, so Reviewed-by: Willian Rampazzo
Re: [PATCH v4 3/6] tests/acceptance: Introduce QemuUserTest base class
On Mon, Sep 27, 2021 at 1:31 PM Philippe Mathieu-Daudé wrote:
>
> Similarly to the 'System' Test base class with methods for testing
> system emulation, the QemuUserTest class contains methods useful to
> test user-mode emulation.
>
> Reviewed-by: Wainer dos Santos Moschetta
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> tests/acceptance/avocado_qemu/__init__.py | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/tests/acceptance/avocado_qemu/__init__.py
> b/tests/acceptance/avocado_qemu/__init__.py
> index 2b9b5dd27fe..2f59e171e49 100644
> --- a/tests/acceptance/avocado_qemu/__init__.py
> +++ b/tests/acceptance/avocado_qemu/__init__.py
> @@ -20,6 +20,7 @@
> from avocado.utils import cloudinit
> from avocado.utils import datadrainer
> from avocado.utils import network
> +from avocado.utils import process
> from avocado.utils import ssh
> from avocado.utils import vmimage
> from avocado.utils.path import find_command
> @@ -300,6 +301,23 @@ def tearDown(self):
> self._sd = None
>
>
> +class QemuUserTest(QemuBaseTest):
> +"""Facilitates user-mode emulation tests."""
> +
> +def setUp(self):
> +self._ldpath = []
> +super(QemuUserTest, self).setUp('qemu-')
Consider using PEP3135,
super().setUp('qemu-')
> +
> +def add_ldpath(self, ldpath):
> +self._ldpath += [os.path.abspath(ldpath)]
The use of the append method is more common here:
self._ldpath.append(os.path.abspath(ldpath))
> +
> +def run(self, bin_path, args=[]):
> +qemu_args = " ".join(["-L %s" % ldpath for ldpath in self._ldpath])
> +bin_args = " ".join(args)
> +return process.run("%s %s %s %s" % (self.qemu_bin, qemu_args,
> + bin_path, bin_args))
> +
> +
> class LinuxSSHMixIn:
> """Contains utility methods for interacting with a guest via SSH."""
Besides some Python related suggestions, the code looks good.
Reviewed-by: Willian Rampazzo
>
> --
> 2.31.1
>
Re: [PATCH v4 6/6] tests/acceptance: Rename avocado_qemu.Test -> QemuSystemTest
"""
> +class QemuSystemTest(QemuBaseTest):
> +"""Facilitates system emulation tests."""
>
> def setUp(self):
> self._vms = {}
>
> -super(Test, self).setUp('qemu-system-')
> +super(QemuSystemTest, self).setUp('qemu-system-')
If you take my suggestion in one of the previous patches, you don't
need this change here.
>
> self.machine = self.params.get('machine',
>
> default=self._get_unique_tag_val('machine'))
> @@ -515,11 +512,11 @@ def default_kernel_params(self):
> return self._info.get('kernel_params', None)
>
>
> -class LinuxTest(Test, LinuxSSHMixIn):
> +class LinuxTest(QemuSystemTest, LinuxSSHMixIn):
> """Facilitates having a cloud-image Linux based available.
>
> For tests that indend to interact with guests, this is a better choice
If you touch this patch again, please, s/indend/intend/
So far, looks good to me
Reviewed-by: Willian Rampazzo
Re: [PATCH v4 4/6] tests/acceptance: Share useful helpers from virtiofs_submounts test
On Mon, Sep 27, 2021 at 1:31 PM Philippe Mathieu-Daudé wrote: > > Move the useful has_cmd()/has_cmds() helpers from the virtiofs > test to the avocado_qemu public class. > > Reviewed-by: Wainer dos Santos Moschetta > Signed-off-by: Philippe Mathieu-Daudé > --- > tests/acceptance/avocado_qemu/__init__.py | 57 ++ > tests/acceptance/virtiofs_submounts.py| 59 +-- > 2 files changed, 59 insertions(+), 57 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH v4 2/6] tests/acceptance: Make pick_default_qemu_bin() more generic
On Mon, Sep 27, 2021 at 1:31 PM Philippe Mathieu-Daudé wrote:
>
> Make pick_default_qemu_bin() generic to find qemu-system or
> qemu-user binaries.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> tests/acceptance/avocado_qemu/__init__.py | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tests/acceptance/avocado_qemu/__init__.py
> b/tests/acceptance/avocado_qemu/__init__.py
> index 8fcbed74849..2b9b5dd27fe 100644
> --- a/tests/acceptance/avocado_qemu/__init__.py
> +++ b/tests/acceptance/avocado_qemu/__init__.py
> @@ -52,7 +52,7 @@ def is_readable_executable_file(path):
> return os.path.isfile(path) and os.access(path, os.R_OK | os.X_OK)
>
>
> -def pick_default_qemu_bin(arch=None):
> +def pick_default_qemu_bin(bin_prefix='qemu-system-', arch=None):
> """
> Picks the path of a QEMU binary, starting either in the current working
> directory or in the source tree root directory.
> @@ -71,7 +71,7 @@ def pick_default_qemu_bin(arch=None):
> # qemu binary path does not match arch for powerpc, handle it
> if 'ppc64le' in arch:
> arch = 'ppc64'
> -qemu_bin_relative_path = "./qemu-system-%s" % arch
> +qemu_bin_relative_path = os.path.join(".", bin_prefix + arch)
> if is_readable_executable_file(qemu_bin_relative_path):
> return qemu_bin_relative_path
>
> @@ -185,14 +185,14 @@ def _get_unique_tag_val(self, tag_name):
> return vals.pop()
> return None
>
> -def setUp(self):
> +def setUp(self, bin_prefix):
> self.arch = self.params.get('arch',
> default=self._get_unique_tag_val('arch'))
>
> self.cpu = self.params.get('cpu',
> default=self._get_unique_tag_val('cpu'))
>
> -default_qemu_bin = pick_default_qemu_bin(arch=self.arch)
> +default_qemu_bin = pick_default_qemu_bin(bin_prefix, arch=self.arch)
> self.qemu_bin = self.params.get('qemu_bin',
> default=default_qemu_bin)
> if self.qemu_bin is None:
> @@ -220,7 +220,7 @@ class Test(QemuBaseTest):
> def setUp(self):
> self._vms = {}
>
> -super(Test, self).setUp()
> +super(Test, self).setUp('qemu-system-')
If you need to change something else in this patch, consider using PEP3135:
super().setUp('qemu-system-')
Anyway,
Reviewed-by: Willian Rampazzo
>
> self.machine = self.params.get('machine',
>
> default=self._get_unique_tag_val('machine'))
> --
> 2.31.1
>
Re: [PATCH 3/6] docker: update fedora container to Fedora 34
On Wed, Nov 3, 2021 at 11:50 AM John Snow wrote: > > Fedora 33 will be EOL 2021-11-23, before QEMU 6.2 will release. Upgrade > the version we're testing as our minimum now. > > Signed-off-by: John Snow > --- > tests/docker/dockerfiles/fedora.docker | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 4/6] docker: update Fedora-based cross-compiler containers to Fedora 34
On Wed, Nov 3, 2021 at 11:50 AM John Snow wrote: > > Similarly to the last patch, Fedora 33 will be EOL by the time QEMU 6.2 > releases, so bump the version for all of the other Fedora containers, > too. > > Signed-off-by: John Snow > --- > tests/docker/dockerfiles/fedora-cris-cross.docker | 2 +- > tests/docker/dockerfiles/fedora-win32-cross.docker | 2 +- > tests/docker/dockerfiles/fedora-win64-cross.docker | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 5/6] docker: update 'python' dockerfile to use Fedora registry
On Wed, Nov 3, 2021 at 11:50 AM John Snow wrote: > > Following the lead of 102cd5c294dc, switch from using Docker hub to the > Fedora registry itself. > > Signed-off-by: John Snow > --- > tests/docker/dockerfiles/python.docker | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Willian Rampazzo
Re: [qemu-web PATCH] remove deployment phase from CI
On Wed, Nov 3, 2021 at 5:16 AM Paolo Bonzini wrote: > > qemu.org is now served via a reverse proxy from qemu-project.gitlab.io; it > does > not need anymore the rsync step to the QEMU project\s shell server. > Remove it from the CI. > > Signed-off-by: Paolo Bonzini > --- > .gitlab-ci.yml | 24 > 1 file changed, 24 deletions(-) > Reviewed-by: Willian Rampazzo
[PATCH 0/1] tests/acceptance: rename tests acceptance to tests avocado
In the discussion about renaming the `tests/acceptance` [1], the
conclusion was that the folders inside `tests` are related to the
framework running the tests and not directly related to the type of
the tests.
This changes the folder to `tests/avocado` and adjusts the MAKEFILE, the
CI related files and the documentation.
[1] https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg06553.html
GitLab pipeline with new naming:
https://gitlab.com/willianrampazzo/qemu/-/pipelines/401431592
Signed-off-by: Willian Rampazzo
Willian Rampazzo (1):
tests/acceptance: rename tests acceptance to tests avocado
.gitlab-ci.d/buildtest-template.yml | 2 +-
.gitlab-ci.d/buildtest.yml| 56 +--
MAINTAINERS | 52 -
configure | 2 +-
docs/devel/build-system.rst | 2 +-
docs/devel/ci-definitions.rst.inc | 2 +-
docs/devel/testing.rst| 49
docs/system/arm/orangepi.rst | 8 +--
python/qemu/machine/README.rst| 2 +-
python/qemu/qmp/README.rst| 2 +-
python/qemu/utils/README.rst | 2 +-
tests/Makefile.include| 14 ++---
tests/acceptance/README.rst | 10
tests/avocado/README.rst | 10
.../avocado_qemu/__init__.py | 2 +-
tests/{acceptance => avocado}/boot_linux.py | 0
.../boot_linux_console.py | 0
tests/{acceptance => avocado}/boot_xen.py | 0
tests/{acceptance => avocado}/cpu_queries.py | 0
.../empty_cpu_model.py| 0
tests/{acceptance => avocado}/hotplug_cpu.py | 0
tests/{acceptance => avocado}/info_usernet.py | 0
tests/{acceptance => avocado}/intel_iommu.py | 0
tests/{acceptance => avocado}/linux_initrd.py | 2 +-
.../linux_ssh_mips_malta.py | 0
.../machine_arm_canona1100.py | 0
.../machine_arm_integratorcp.py | 0
.../machine_arm_n8x0.py | 0
tests/{acceptance => avocado}/machine_avr6.py | 2 +-
.../machine_m68k_nextcube.py | 0
.../machine_microblaze.py | 0
.../machine_mips_fuloong2e.py | 0
.../machine_mips_loongson3v.py| 0
.../machine_mips_malta.py | 0
.../machine_rx_gdbsim.py | 0
.../machine_s390_ccw_virtio.py| 0
.../machine_sparc64_sun4u.py | 0
.../machine_sparc_leon3.py| 0
tests/{acceptance => avocado}/migration.py| 0
tests/{acceptance => avocado}/multiprocess.py | 0
.../pc_cpu_hotplug_props.py | 0
tests/{acceptance => avocado}/ppc_405.py | 0
tests/{acceptance => avocado}/ppc_bamboo.py | 0
.../{acceptance => avocado}/ppc_mpc8544ds.py | 0
tests/{acceptance => avocado}/ppc_prep_40p.py | 12 ++--
tests/{acceptance => avocado}/ppc_pseries.py | 0
.../ppc_virtex_ml507.py | 0
.../{acceptance => avocado}/replay_kernel.py | 0
tests/{acceptance => avocado}/replay_linux.py | 0
.../reverse_debugging.py | 0
tests/{acceptance => avocado}/smmu.py | 0
tests/{acceptance => avocado}/tcg_plugins.py | 0
.../tesseract_utils.py| 0
tests/{acceptance => avocado}/version.py | 0
tests/{acceptance => avocado}/virtio-gpu.py | 0
.../virtio_check_params.py| 0
.../{acceptance => avocado}/virtio_version.py | 0
.../virtiofs_submounts.py | 0
.../virtiofs_submounts.py.data/cleanup.sh | 0
.../guest-cleanup.sh | 0
.../virtiofs_submounts.py.data/guest.sh | 0
.../virtiofs_submounts.py.data/host.sh| 0
tests/{acceptance => avocado}/vnc.py | 0
.../x86_cpu_model_versions.py | 0
64 files changed, 113 insertions(+), 118 deletions(-)
delete mode 100644 tests/acceptance/README.rst
create mode 100644 tests/avocado/README.rst
rename tests/{acceptance => avocado}/avocado_qemu/__init__.py (99%)
rename tests/{acceptance => avocado}/boot_linux.py (100%)
rename tests/{acceptance => avocado}/boot_linux_console.py (100%)
rename tests/{acceptance => avocado}/boot_xen.py (100%)
rename tests/{acceptance => avocado}/cpu_queries.py (100%)
rename tests/{acceptance => avocado}/empty_cpu_model.py (100%)
rename tests/{acceptance => avocado}/hotplug_cpu.py (100%)
rename tests/{acceptance => avocado}/info_usernet.py (100%)
rename tests/{acceptance => avocado}/intel_iommu.py (100%)
rename tests/{acceptance => avocado}/linux_initrd.py (99%)
rename tests/{acceptance => avocado}/linux_ssh_mips_malta.py (100%)
rena
[PATCH 1/1] tests/acceptance: rename tests acceptance to tests avocado
In the discussion about renaming the `tests/acceptance` [1], the
conclusion was that the folders inside `tests` are related to the
framework running the tests and not directly related to the type of
the tests.
This changes the folder to `tests/avocado` and adjusts the MAKEFILE, the
CI related files and the documentation.
[1] https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg06553.html
Signed-off-by: Willian Rampazzo
---
.gitlab-ci.d/buildtest-template.yml | 2 +-
.gitlab-ci.d/buildtest.yml| 56 +--
MAINTAINERS | 52 -
configure | 2 +-
docs/devel/build-system.rst | 2 +-
docs/devel/ci-definitions.rst.inc | 2 +-
docs/devel/testing.rst| 49
docs/system/arm/orangepi.rst | 8 +--
python/qemu/machine/README.rst| 2 +-
python/qemu/qmp/README.rst| 2 +-
python/qemu/utils/README.rst | 2 +-
tests/Makefile.include| 14 ++---
tests/acceptance/README.rst | 10
tests/avocado/README.rst | 10
.../avocado_qemu/__init__.py | 2 +-
tests/{acceptance => avocado}/boot_linux.py | 0
.../boot_linux_console.py | 0
tests/{acceptance => avocado}/boot_xen.py | 0
tests/{acceptance => avocado}/cpu_queries.py | 0
.../empty_cpu_model.py| 0
tests/{acceptance => avocado}/hotplug_cpu.py | 0
tests/{acceptance => avocado}/info_usernet.py | 0
tests/{acceptance => avocado}/intel_iommu.py | 0
tests/{acceptance => avocado}/linux_initrd.py | 2 +-
.../linux_ssh_mips_malta.py | 0
.../machine_arm_canona1100.py | 0
.../machine_arm_integratorcp.py | 0
.../machine_arm_n8x0.py | 0
tests/{acceptance => avocado}/machine_avr6.py | 2 +-
.../machine_m68k_nextcube.py | 0
.../machine_microblaze.py | 0
.../machine_mips_fuloong2e.py | 0
.../machine_mips_loongson3v.py| 0
.../machine_mips_malta.py | 0
.../machine_rx_gdbsim.py | 0
.../machine_s390_ccw_virtio.py| 0
.../machine_sparc64_sun4u.py | 0
.../machine_sparc_leon3.py| 0
tests/{acceptance => avocado}/migration.py| 0
tests/{acceptance => avocado}/multiprocess.py | 0
.../pc_cpu_hotplug_props.py | 0
tests/{acceptance => avocado}/ppc_405.py | 0
tests/{acceptance => avocado}/ppc_bamboo.py | 0
.../{acceptance => avocado}/ppc_mpc8544ds.py | 0
tests/{acceptance => avocado}/ppc_prep_40p.py | 12 ++--
tests/{acceptance => avocado}/ppc_pseries.py | 0
.../ppc_virtex_ml507.py | 0
.../{acceptance => avocado}/replay_kernel.py | 0
tests/{acceptance => avocado}/replay_linux.py | 0
.../reverse_debugging.py | 0
tests/{acceptance => avocado}/smmu.py | 0
tests/{acceptance => avocado}/tcg_plugins.py | 0
.../tesseract_utils.py| 0
tests/{acceptance => avocado}/version.py | 0
tests/{acceptance => avocado}/virtio-gpu.py | 0
.../virtio_check_params.py| 0
.../{acceptance => avocado}/virtio_version.py | 0
.../virtiofs_submounts.py | 0
.../virtiofs_submounts.py.data/cleanup.sh | 0
.../guest-cleanup.sh | 0
.../virtiofs_submounts.py.data/guest.sh | 0
.../virtiofs_submounts.py.data/host.sh| 0
tests/{acceptance => avocado}/vnc.py | 0
.../x86_cpu_model_versions.py | 0
64 files changed, 113 insertions(+), 118 deletions(-)
delete mode 100644 tests/acceptance/README.rst
create mode 100644 tests/avocado/README.rst
rename tests/{acceptance => avocado}/avocado_qemu/__init__.py (99%)
rename tests/{acceptance => avocado}/boot_linux.py (100%)
rename tests/{acceptance => avocado}/boot_linux_console.py (100%)
rename tests/{acceptance => avocado}/boot_xen.py (100%)
rename tests/{acceptance => avocado}/cpu_queries.py (100%)
rename tests/{acceptance => avocado}/empty_cpu_model.py (100%)
rename tests/{acceptance => avocado}/hotplug_cpu.py (100%)
rename tests/{acceptance => avocado}/info_usernet.py (100%)
rename tests/{acceptance => avocado}/intel_iommu.py (100%)
rename tests/{acceptance => avocado}/linux_initrd.py (99%)
rename tests/{acceptance => avocado}/linux_ssh_mips_malta.py (100%)
rename tests/{acceptance => avocado}/machine_arm_canona1100.py (100%)
rename tests/{acceptance => avocado}/machine_arm_integratorcp.py (100%)
rename tests/{acceptance =>
Re: [PATCH 1/1] tests/acceptance: rename tests acceptance to tests avocado
On Thu, Nov 4, 2021 at 9:50 AM Philippe Mathieu-Daudé wrote:
>
> On 11/3/21 22:14, Willian Rampazzo wrote:
> > In the discussion about renaming the `tests/acceptance` [1], the
> > conclusion was that the folders inside `tests` are related to the
> > framework running the tests and not directly related to the type of
> > the tests.
> >
> > This changes the folder to `tests/avocado` and adjusts the MAKEFILE, the
> > CI related files and the documentation.
> >
> > [1] https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg06553.html
> >
> > Signed-off-by: Willian Rampazzo
> > ---
> > 64 files changed, 113 insertions(+), 118 deletions(-)
>
> > --- a/tests/Makefile.include
> > +++ b/tests/Makefile.include
>
> > -.PHONY: check-venv check-acceptance
> > +.PHONY: check-venv check-avocado
>
> > -check-acceptance: check-venv $(TESTS_RESULTS_DIR) get-vm-images
> > +check-avocado: check-venv $(TESTS_RESULTS_DIR) get-vm-images
> > $(call quiet-command, \
> > $(TESTS_VENV_DIR)/bin/python -m avocado \
> > --show=$(AVOCADO_SHOW) run
> > --job-results-dir=$(TESTS_RESULTS_DIR) \
>
> We should keep check-acceptance, eventually printing a deprecation
> message. Smth like:
>
> check-acceptance: check-avocado a
> @echo "Note 'make $@' is deprecated, use 'make $<' instead" >&2
>
I agree.
> > --- a/tests/acceptance/ppc_prep_40p.py
> > +++ b/tests/avocado/ppc_prep_40p.py
> > @@ -13,6 +13,10 @@
> >
> >
> > class IbmPrep40pMachine(Test):
> > +"""
> > +:avocado: tags=arch:ppc
> > +:avocado: tags=machine:40p
> > +"""
> >
> > timeout = 60
> >
> > @@ -24,8 +28,6 @@ class IbmPrep40pMachine(Test):
> > @skipUnless(os.getenv('AVOCADO_ALLOW_UNTRUSTED_CODE'), 'untrusted
> > code')
> > def test_factory_firmware_and_netbsd(self):
> > """
> > -:avocado: tags=arch:ppc
> > -:avocado: tags=machine:40p
> > :avocado: tags=os:netbsd
> > :avocado: tags=slowness:high
> > """
> > @@ -48,10 +50,6 @@ def test_factory_firmware_and_netbsd(self):
> > wait_for_console_pattern(self, 'Model: IBM PPS Model 6015')
> >
> > def test_openbios_192m(self):
> > -"""
> > -:avocado: tags=arch:ppc
> > -:avocado: tags=machine:40p
> > -"""
> > self.vm.set_console()
> > self.vm.add_args('-m', '192') # test fw_cfg
> >
> > @@ -62,8 +60,6 @@ def test_openbios_192m(self):
> >
> > def test_openbios_and_netbsd(self):
> > """
> > -:avocado: tags=arch:ppc
> > -:avocado: tags=machine:40p
> > :avocado: tags=os:netbsd
> > """
> > drive_url = ('https://archive.netbsd.org/pub/NetBSD-archive/'
>
> Unrelated change, otherwise:
Ouch, looks like I took one of my test changes. I'll wait for some
more comments and remove this change on a v2.
>
> Reviewed-by: Philippe Mathieu-Daudé
> Tested-by: Philippe Mathieu-Daudé
>
Thanks!
[PATCH v2 1/2] tests/acceptance: introduce new check-avocado tartget
This introduces a new `make` target, `check-avocado`, and adds a deprecation message about the `check-acceptance` target. This is a preparation for renaming the `tests/acceptance` folder to `tests/avocado`. The plan is to remove the call to the `check-avocado` target one or two months after the release and leave the warning to force people to move to the new `check-avocado` target. Later, the `check-acceptance` target can be removed. The intent is to avoid a direct impact during the current soft freeze. Suggested-by: Philippe Mathieu-Daudé Signed-off-by: Willian Rampazzo --- docs/about/deprecated.rst | 13 + tests/Makefile.include| 17 - 2 files changed, 25 insertions(+), 5 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 56f9ad15ab..7bf8da8325 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -410,3 +410,16 @@ nanoMIPS ISA The ``nanoMIPS`` ISA has never been upstreamed to any compiler toolchain. As it is hard to generate binaries for it, declare it deprecated. + +Testing +--- + +Renaming of the acceptance folder to avocado +'''''''''''''''''''''''''''''''''''''''''''' + +The ``tests/acceptance`` folder was never used to store acceptance tests +in terms of software engineering. This naming can confuse developers +adding tests using the Avocado Framework to this folder. The folder +name change to ``tests/avocado`` also changed the ``make`` target from +``check-acceptance`` to ``check-avocado``. In this case, the use of the +``check-acceptance`` target is deprecated. diff --git a/tests/Makefile.include b/tests/Makefile.include index 8434a33fe6..8e8ee58493 100644 --- a/tests/Makefile.include +++ b/tests/Makefile.include @@ -16,7 +16,7 @@ ifneq ($(filter $(all-check-targets), check-softfloat),) @echo " $(MAKE) check-tcgRun TCG tests" @echo " $(MAKE) check-softfloat Run FPU emulation tests" endif - @echo " $(MAKE) check-acceptance Run acceptance (functional) tests for currently configured targets" + @echo " $(MAKE) check-avocadoRun avocado (integration) tests for currently configured targets" @echo @echo " $(MAKE) check-report.tap Generates an aggregated TAP test report" @echo " $(MAKE) check-venv Creates a Python venv for tests" @@ -24,7 +24,7 @@ endif @echo @echo "The following are useful for CI builds" @echo " $(MAKE) check-build Build most test binaris" - @echo " $(MAKE) get-vm-imagesDownloads all images used by acceptance tests, according to configured targets (~350 MB each, 1.5 GB max)" + @echo " $(MAKE) get-vm-imagesDownloads all images used by avocado tests, according to configured targets (~350 MB each, 1.5 GB max)" @echo @echo @echo "The variable SPEED can be set to control the gtester speed setting." @@ -83,7 +83,7 @@ clean-tcg: $(CLEAN_TCG_TARGET_RULES) # Python venv for running tests -.PHONY: check-venv check-acceptance +.PHONY: check-venv check-avocado check-acceptance check-acceptance-deprecated-warning TESTS_VENV_DIR=$(BUILD_DIR)/tests/venv TESTS_VENV_REQ=$(SRC_PATH)/tests/requirements.txt @@ -127,12 +127,12 @@ get-vm-image-fedora-31-%: check-venv $(call quiet-command, \ $(TESTS_VENV_DIR)/bin/python -m avocado vmimage get \ --distro=fedora --distro-version=31 --arch=$*, \ - "AVOCADO", "Downloading acceptance tests VM image for $*") + "AVOCADO", "Downloading avocado tests VM image for $*") # download all vm images, according to defined targets get-vm-images: check-venv $(patsubst %,get-vm-image-fedora-31-%, $(FEDORA_31_DOWNLOAD)) -check-acceptance: check-venv $(TESTS_RESULTS_DIR) get-vm-images +check-avocado: check-venv $(TESTS_RESULTS_DIR) get-vm-images $(call quiet-command, \ $(TESTS_VENV_DIR)/bin/python -m avocado \ --show=$(AVOCADO_SHOW) run --job-results-dir=$(TESTS_RESULTS_DIR) \ @@ -142,6 +142,13 @@ check-acceptance: check-venv $(TESTS_RESULTS_DIR) get-vm-images $(if $(GITLAB_CI),,--failfast) $(AVOCADO_TESTS), \ "AVOCADO", "tests/acceptance") +check-acceptance-deprecated-warning: + @echo + @echo "Note '$(MAKE) check-acceptance' is deprecated, use '$(MAKE) check-avocado' instead." + @echo + +check-acceptance: check-acceptance-deprecated-warning | check-avocado + # Consolidated targets .PHONY: check-block check check-clean get-vm-images -- 2.33.1
[PATCH v2 2/2] tests/acceptance: rename tests acceptance to tests avocado
In the discussion about renaming the `tests/acceptance` [1], the
conclusion was that the folders inside `tests` are related to the
framework running the tests and not directly related to the type of
the tests.
This changes the folder to `tests/avocado` and adjusts the MAKEFILE, the
CI related files and the documentation.
[1] https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg06553.html
For the Orange Pi PC documentation:
Reviewed-by: Niek Linnenbank
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: Willian Rampazzo
---
.gitlab-ci.d/buildtest-template.yml | 2 +-
.gitlab-ci.d/buildtest.yml| 56 +--
MAINTAINERS | 52 -
configure | 2 +-
docs/devel/build-system.rst | 2 +-
docs/devel/ci-definitions.rst.inc | 2 +-
docs/devel/testing.rst| 49
docs/system/arm/orangepi.rst | 8 +--
python/qemu/machine/README.rst| 2 +-
python/qemu/qmp/README.rst| 2 +-
python/qemu/utils/README.rst | 2 +-
tests/Makefile.include| 4 +-
tests/acceptance/README.rst | 10
tests/avocado/README.rst | 10
.../avocado_qemu/__init__.py | 2 +-
tests/{acceptance => avocado}/boot_linux.py | 0
.../boot_linux_console.py | 0
tests/{acceptance => avocado}/boot_xen.py | 0
tests/{acceptance => avocado}/cpu_queries.py | 0
.../empty_cpu_model.py| 0
tests/{acceptance => avocado}/hotplug_cpu.py | 0
tests/{acceptance => avocado}/info_usernet.py | 0
tests/{acceptance => avocado}/intel_iommu.py | 0
tests/{acceptance => avocado}/linux_initrd.py | 2 +-
.../linux_ssh_mips_malta.py | 0
.../machine_arm_canona1100.py | 0
.../machine_arm_integratorcp.py | 0
.../machine_arm_n8x0.py | 0
tests/{acceptance => avocado}/machine_avr6.py | 2 +-
.../machine_m68k_nextcube.py | 0
.../machine_microblaze.py | 0
.../machine_mips_fuloong2e.py | 0
.../machine_mips_loongson3v.py| 0
.../machine_mips_malta.py | 0
.../machine_rx_gdbsim.py | 0
.../machine_s390_ccw_virtio.py| 0
.../machine_sparc64_sun4u.py | 0
.../machine_sparc_leon3.py| 0
tests/{acceptance => avocado}/migration.py| 0
tests/{acceptance => avocado}/multiprocess.py | 0
.../pc_cpu_hotplug_props.py | 0
tests/{acceptance => avocado}/ppc_405.py | 0
tests/{acceptance => avocado}/ppc_bamboo.py | 0
.../{acceptance => avocado}/ppc_mpc8544ds.py | 0
tests/{acceptance => avocado}/ppc_prep_40p.py | 0
tests/{acceptance => avocado}/ppc_pseries.py | 0
.../ppc_virtex_ml507.py | 0
.../{acceptance => avocado}/replay_kernel.py | 0
tests/{acceptance => avocado}/replay_linux.py | 0
.../reverse_debugging.py | 0
tests/{acceptance => avocado}/smmu.py | 0
tests/{acceptance => avocado}/tcg_plugins.py | 0
.../tesseract_utils.py| 0
tests/{acceptance => avocado}/version.py | 0
tests/{acceptance => avocado}/virtio-gpu.py | 0
.../virtio_check_params.py| 0
.../{acceptance => avocado}/virtio_version.py | 0
.../virtiofs_submounts.py | 0
.../virtiofs_submounts.py.data/cleanup.sh | 0
.../guest-cleanup.sh | 0
.../virtiofs_submounts.py.data/guest.sh | 0
.../virtiofs_submounts.py.data/host.sh| 0
tests/{acceptance => avocado}/vnc.py | 0
.../x86_cpu_model_versions.py | 0
64 files changed, 104 insertions(+), 105 deletions(-)
delete mode 100644 tests/acceptance/README.rst
create mode 100644 tests/avocado/README.rst
rename tests/{acceptance => avocado}/avocado_qemu/__init__.py (99%)
rename tests/{acceptance => avocado}/boot_linux.py (100%)
rename tests/{acceptance => avocado}/boot_linux_console.py (100%)
rename tests/{acceptance => avocado}/boot_xen.py (100%)
rename tests/{acceptance => avocado}/cpu_queries.py (100%)
rename tests/{acceptance => avocado}/empty_cpu_model.py (100%)
rename tests/{acceptance => avocado}/hotplug_cpu.py (100%)
rename tests/{acceptance => avocado}/info_usernet.py (100%)
rename tests/{acceptance => avocado}/intel_iommu.py (100%)
rename tests/{acceptance => avocado}/linux_initrd.py (99%)
rename tests/{acceptance => avocado}/linux_ssh_mips_malta.py (100%)
rename tests/{acceptance => avocado}/machine_arm_ca
Re: [PATCH] docs/about/deprecated: Remove empty 'related binaries' section
On Fri, Nov 5, 2021 at 11:31 AM Philippe Mathieu-Daudé
wrote:
>
> Commit 497a30dbb06 ("qemu-img: Require -F with -b backing image")
> removed the content of the "Related binaries" section but forgot
> to remove the section title. Since it is now empty, remove it too.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> docs/about/deprecated.rst | 3 ---
> 1 file changed, 3 deletions(-)
>
Reviewed-by: Willian Rampazzo
[PATCH v2 0/2] tests/acceptance: rename tests acceptance to tests avocado
In the discussion about renaming the `tests/acceptance` [1], the
conclusion was that the folders inside `tests` are related to the
framework running the tests and not directly related to the type of
the tests.
This changes the folder to `tests/avocado` and adjusts the MAKEFILE, the
CI related files and the documentation.
[1] https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg06553.html
GitLab pipeline with new naming:
https://gitlab.com/willianrampazzo/qemu/-/pipelines/403056475
Changes from v1:
- Split changes on Makefile leaving `check-acceptance` available and
adding a deprecate warning message when it is used.
(Suggested-by: Philippe Mathieu-Daudé)
- Remove unrelated changes.
Signed-off-by: Willian Rampazzo
Willian Rampazzo (2):
tests/acceptance: introduce new check-avocado tartget
tests/acceptance: rename tests acceptance to tests avocado
.gitlab-ci.d/buildtest-template.yml | 2 +-
.gitlab-ci.d/buildtest.yml| 56 +--
MAINTAINERS | 52 -
configure | 2 +-
docs/about/deprecated.rst | 13 +
docs/devel/build-system.rst | 2 +-
docs/devel/ci-definitions.rst.inc | 2 +-
docs/devel/testing.rst| 49
docs/system/arm/orangepi.rst | 8 +--
python/qemu/machine/README.rst| 2 +-
python/qemu/qmp/README.rst| 2 +-
python/qemu/utils/README.rst | 2 +-
tests/Makefile.include| 21 ---
tests/acceptance/README.rst | 10
tests/avocado/README.rst | 10
.../avocado_qemu/__init__.py | 2 +-
tests/{acceptance => avocado}/boot_linux.py | 0
.../boot_linux_console.py | 0
tests/{acceptance => avocado}/boot_xen.py | 0
tests/{acceptance => avocado}/cpu_queries.py | 0
.../empty_cpu_model.py| 0
tests/{acceptance => avocado}/hotplug_cpu.py | 0
tests/{acceptance => avocado}/info_usernet.py | 0
tests/{acceptance => avocado}/intel_iommu.py | 0
tests/{acceptance => avocado}/linux_initrd.py | 2 +-
.../linux_ssh_mips_malta.py | 0
.../machine_arm_canona1100.py | 0
.../machine_arm_integratorcp.py | 0
.../machine_arm_n8x0.py | 0
tests/{acceptance => avocado}/machine_avr6.py | 2 +-
.../machine_m68k_nextcube.py | 0
.../machine_microblaze.py | 0
.../machine_mips_fuloong2e.py | 0
.../machine_mips_loongson3v.py| 0
.../machine_mips_malta.py | 0
.../machine_rx_gdbsim.py | 0
.../machine_s390_ccw_virtio.py| 0
.../machine_sparc64_sun4u.py | 0
.../machine_sparc_leon3.py| 0
tests/{acceptance => avocado}/migration.py| 0
tests/{acceptance => avocado}/multiprocess.py | 0
.../pc_cpu_hotplug_props.py | 0
tests/{acceptance => avocado}/ppc_405.py | 0
tests/{acceptance => avocado}/ppc_bamboo.py | 0
.../{acceptance => avocado}/ppc_mpc8544ds.py | 0
tests/{acceptance => avocado}/ppc_prep_40p.py | 0
tests/{acceptance => avocado}/ppc_pseries.py | 0
.../ppc_virtex_ml507.py | 0
.../{acceptance => avocado}/replay_kernel.py | 0
tests/{acceptance => avocado}/replay_linux.py | 0
.../reverse_debugging.py | 0
tests/{acceptance => avocado}/smmu.py | 0
tests/{acceptance => avocado}/tcg_plugins.py | 0
.../tesseract_utils.py| 0
tests/{acceptance => avocado}/version.py | 0
tests/{acceptance => avocado}/virtio-gpu.py | 0
.../virtio_check_params.py| 0
.../{acceptance => avocado}/virtio_version.py | 0
.../virtiofs_submounts.py | 0
.../virtiofs_submounts.py.data/cleanup.sh | 0
.../guest-cleanup.sh | 0
.../virtiofs_submounts.py.data/guest.sh | 0
.../virtiofs_submounts.py.data/host.sh| 0
tests/{acceptance => avocado}/vnc.py | 0
.../x86_cpu_model_versions.py | 0
65 files changed, 129 insertions(+), 110 deletions(-)
delete mode 100644 tests/acceptance/README.rst
create mode 100644 tests/avocado/README.rst
rename tests/{acceptance => avocado}/avocado_qemu/__init__.py (99%)
rename tests/{acceptance => avocado}/boot_linux.py (100%)
rename tests/{acceptance => avocado}/boot_linux_console.py (100%)
rename tests/{acceptance => avocado}/boot_xen.py (100%)
rename tests/{acceptance => avocado}/cpu_queries.py (100%)
rename tests/{acceptance => avocado}/empty_cpu_model.py (100%)
rename t
Re: [PATCH v2 1/2] tests/acceptance: introduce new check-avocado tartget
On Mon, Nov 8, 2021 at 6:49 AM Philippe Mathieu-Daudé wrote: > > On 11/8/21 10:24, Daniel P. Berrangé wrote: > > On Mon, Nov 08, 2021 at 08:59:51AM +0100, Thomas Huth wrote: > >> On 05/11/2021 16.53, Willian Rampazzo wrote: > >>> This introduces a new `make` target, `check-avocado`, and adds a > >>> deprecation message about the `check-acceptance` target. This is > >>> a preparation for renaming the `tests/acceptance` folder to > >>> `tests/avocado`. > >>> > >>> The plan is to remove the call to the `check-avocado` target one > >>> or two months after the release and leave the warning to force > >>> people to move to the new `check-avocado` target. > >>> > >>> Later, the `check-acceptance` target can be removed. The intent > >>> is to avoid a direct impact during the current soft freeze. > >>> > >>> Suggested-by: Philippe Mathieu-Daudé > >>> Signed-off-by: Willian Rampazzo > >>> --- > >>> docs/about/deprecated.rst | 13 + > >>> tests/Makefile.include| 17 - > >>> 2 files changed, 25 insertions(+), 5 deletions(-) > >>> > >>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst > >>> index 56f9ad15ab..7bf8da8325 100644 > >>> --- a/docs/about/deprecated.rst > >>> +++ b/docs/about/deprecated.rst > >>> @@ -410,3 +410,16 @@ nanoMIPS ISA > >>> The ``nanoMIPS`` ISA has never been upstreamed to any compiler > >>> toolchain. > >>> As it is hard to generate binaries for it, declare it deprecated. > >>> + > >>> +Testing > >>> +--- > >>> + > >>> +Renaming of the acceptance folder to avocado > >>> +'''''''''''''''''''''''''''''''''''''''''''' > >>> + > >>> +The ``tests/acceptance`` folder was never used to store acceptance tests > >>> +in terms of software engineering. This naming can confuse developers > >>> +adding tests using the Avocado Framework to this folder. The folder > >>> +name change to ``tests/avocado`` also changed the ``make`` target from > >>> +``check-acceptance`` to ``check-avocado``. In this case, the use of the > >>> +``check-acceptance`` target is deprecated. > >> > >> Not sure whether we need to document this in deprecated.rst, too, since > >> we're normally only listing the things here that affect the users of the > >> qemu binaries, not the people who want to recompile and run the tests... > >> OTOH, I don't mind too much either if we list it here... Anybody else got > >> an > >> opinion on this? > > > > Deprecations are only things for user facing changes in the apps. > > OK. > > > For build system changes we don't bother with any deprecation cycle. > > Just make the change immediately and document it in the release notes. > > Understood. > > Willian, do you mind updating the release notes? > https://wiki.qemu.org/ChangeLog/6.2#Testing_and_CI > Sure, I can do that, but I think I need to wait for the patch to be merged, right?
Re: [PATCH] tests/avocado: Remove p7zip binary availability check
On Sat, Nov 6, 2021 at 3:14 PM Philippe Mathieu-Daudé wrote:
>
> The single use of the 7z binary has been removed in commit a30e114f3
> ("tests/acceptance: remove Armbian 19.11.3 test for orangepi-pc"),
> we don't need to check for this binary availability anymore.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> Based-on: <20211105155354.154864-1-willi...@redhat.com>
> ---
> tests/avocado/boot_linux_console.py | 7 ---
> 1 file changed, 7 deletions(-)
>
Reviewed-by: Willian Rampazzo
Re: [PATCH v1 04/28] gitlab-ci: Remove special casing for hexagon testing
On Tue, Oct 26, 2021 at 7:22 AM Alex Bennée wrote: > > From: Richard Henderson > > Now that the hexagon container is using a pre-built > toolchain, we do not need to make the build optional. > > Signed-off-by: Richard Henderson > Signed-off-by: Alex Bennée > Message-Id: <20211014224435.2539547-5-richard.hender...@linaro.org> > --- > .gitlab-ci.d/buildtest.yml | 4 > .gitlab-ci.d/container-cross.yml | 27 +++ > 2 files changed, 3 insertions(+), 28 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH v1 06/28] tests/docker: Add debian-microblaze-cross image
On Tue, Oct 26, 2021 at 7:22 AM Alex Bennée wrote: > > From: Richard Henderson > > Build the entire cross tool chain from source. > For this reason, default to caching. > > Signed-off-by: Richard Henderson > [AJB: Update MAINTAINERS] > Signed-off-by: Alex Bennée > Message-Id: <20211014224435.2539547-7-richard.hender...@linaro.org> > --- > MAINTAINERS | 1 + > tests/docker/Makefile.include | 6 ++ > .../build-toolchain.sh| 88 +++ > 3 files changed, 95 insertions(+) > create mode 100755 > tests/docker/dockerfiles/debian-microblaze-cross.d/build-toolchain.sh > Reviewed-by: Willian Rampazzo
Re: [PATCH v1 05/28] tests/docker: Add debian-nios2-cross image
On Tue, Oct 26, 2021 at 7:22 AM Alex Bennée wrote: > > From: Richard Henderson > > Build the entire cross tool chain from source. > For this reason, default to caching. > > Signed-off-by: Richard Henderson > [AJB: honour NOUSER in cached fetch and build, update MAINTAINERS] > Signed-off-by: Alex Bennée > Message-Id: <20211014224435.2539547-6-richard.hender...@linaro.org> > --- > MAINTAINERS | 1 + > tests/docker/Makefile.include | 25 ++ > .../debian-nios2-cross.d/build-toolchain.sh | 87 +++ > .../dockerfiles/debian-toolchain.docker | 36 > 4 files changed, 149 insertions(+) > create mode 100755 > tests/docker/dockerfiles/debian-nios2-cross.d/build-toolchain.sh > create mode 100644 tests/docker/dockerfiles/debian-toolchain.docker > Reviewed-by: Willian Rampazzo
Re: [PATCH v1 09/28] tests/docker: split PARTIAL into PARTIAL and VIRTUAL images
On Tue, Oct 26, 2021 at 7:22 AM Alex Bennée wrote: > > This is mostly to ensure we don't include the toolchain and bootstrap > builds in DOCKER_IMAGES which is useful when verifying all images > still build. > > Signed-off-by: Alex Bennée > --- > tests/docker/Makefile.include | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 1/1] gitlab-ci: Only push docker images to registry from /master branch
On Tue, Oct 26, 2021 at 11:55 AM Philippe Mathieu-Daudé wrote: > > Users expect images pulled from registry.gitlab.com/qemu-project/qemu/ > to be stable. QEMU repository workflow pushes merge candidates to > the /staging branch, and on success the same commit is pushed as > /master. If /staging fails, we do not want to push the built images > to the registry. Therefore limit the 'docker push' command to the > /master branch on the mainstream CI. The fork behavior is unchanged. > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/container-template.yml | 11 ++- > .gitlab-ci.d/edk2.yml | 11 ++- > .gitlab-ci.d/opensbi.yml| 11 ++- > 3 files changed, 30 insertions(+), 3 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH v2 01/10] gitlab-ci: Replace YAML anchors by extends (acceptance_test_job)
On Tue, May 11, 2021 at 4:30 AM Philippe Mathieu-Daudé wrote: > > From: Philippe Mathieu-Daudé > > 'extends' is an alternative to using YAML anchors > and is a little more flexible and readable. See: > https://docs.gitlab.com/ee/ci/yaml/#extends > > Reviewed-by: Wainer dos Santos Moschetta > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.yml | 30 +++--- > 1 file changed, 11 insertions(+), 19 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH v2 03/10] gitlab-ci: Extract container job template to container-template.yml
On Tue, May 11, 2021 at 4:30 AM Philippe Mathieu-Daudé wrote: > > Extract the container job template to a new file > (container-template.yml) to be able to reuse it > without having to run all the jobs included, which > are mainly useful for mainstream CI. > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/container-template.yml | 22 ++ > .gitlab-ci.d/containers.yml | 24 ++-- > 2 files changed, 24 insertions(+), 22 deletions(-) > create mode 100644 .gitlab-ci.d/container-template.yml > Reviewed-by: Willian Rampazzo
Re: [PATCH v2 04/10] gitlab-ci: Extract crossbuild job templates to crossbuild-template.yml
On Tue, May 11, 2021 at 4:30 AM Philippe Mathieu-Daudé wrote: > > Extract the crossbuild job templates to a new file > (crossbuild-template.yml) to be able to reuse them > without having to run all the jobs included, which > are mainly useful for mainstream CI. > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/crossbuild-template.yml | 41 ++ > .gitlab-ci.d/crossbuilds.yml | 43 ++-- > 2 files changed, 43 insertions(+), 41 deletions(-) > create mode 100644 .gitlab-ci.d/crossbuild-template.yml > Reviewed-by: Willian Rampazzo
Re: [PATCH v2 05/10] gitlab-ci: Extract DCO/style check jobs to static_checks.yml
On Tue, May 11, 2021 at 4:30 AM Philippe Mathieu-Daudé wrote: > > Extract the DCO / checkpatch jobs to a new file (static_checks.yml) > to be able to run them without having to run all the jobs included > in the default .gitlab-ci.yml, which are mainly useful for the > mainstream CI. > > Signed-off-by: Philippe Mathieu-Daudé > --- > v2: > - renamed static_checks.yml (Wainer) > - removed moved jobs (Thomas) > --- > .gitlab-ci.d/static_checks.yml | 24 > .gitlab-ci.yml | 26 +- > 2 files changed, 25 insertions(+), 25 deletions(-) > create mode 100644 .gitlab-ci.d/static_checks.yml > Reviewed-by: Willian Rampazzo
Re: [PATCH v2 06/10] gitlab-ci: Extract build stages to stages.yml
On Tue, May 11, 2021 at 4:30 AM Philippe Mathieu-Daudé wrote: > > Extract the build stages used by our job templates to a new file > (stages.yml) to be able to include it with the other templates, > without having to run all the jobs included in the default > .gitlab-ci.yml, which are mainly useful for mainstream CI. > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/stages.yml | 8 > .gitlab-ci.yml | 10 +- > 2 files changed, 9 insertions(+), 9 deletions(-) > create mode 100644 .gitlab-ci.d/stages.yml > Reviewed-by: Willian Rampazzo
Re: [PATCH v2 07/10] gitlab-ci: Extract default build/test jobs templates
On Tue, May 11, 2021 at 4:30 AM Philippe Mathieu-Daudé wrote: > > To be able to reuse the mainstream build/test jobs templates, > extract them into a new file (buildtest-template.yml). > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/buildtest-template.yml | 69 > .gitlab-ci.yml | 71 + > 2 files changed, 70 insertions(+), 70 deletions(-) > create mode 100644 .gitlab-ci.d/buildtest-template.yml > Reviewed-by: Willian Rampazzo
Re: [PATCH v2 08/10] gitlab-ci: Extract all default build/test jobs to buildtest.yml
On Tue, May 11, 2021 at 4:30 AM Philippe Mathieu-Daudé wrote: > > Extract the build/test jobs run by default on the mainstream > CI into a new file (buildtest.yml). > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/buildtest.yml | 726 + > .gitlab-ci.yml | 726 + > 2 files changed, 727 insertions(+), 725 deletions(-) > create mode 100644 .gitlab-ci.d/buildtest.yml > Reviewed-by: Willian Rampazzo
Re: [PATCH v2 09/10] gitlab-ci: Extract core container jobs to container-core.yml
On Tue, May 11, 2021 at 4:30 AM Philippe Mathieu-Daudé wrote: > > It is not possible to use the previously extracted templates > without this set of core containers. Extract them into a new > file (container-core.yml) to be able to build them without > having to build all the other containers by default. > > Reviewed-by: Thomas Huth > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/container-core.yml | 17 + > .gitlab-ci.d/containers.yml | 17 + > 2 files changed, 18 insertions(+), 16 deletions(-) > create mode 100644 .gitlab-ci.d/container-core.yml > Reviewed-by: Willian Rampazzo
Re: [PATCH v2 10/10] gitlab-ci: Move current job set to qemu-project.yml
On Tue, May 11, 2021 at 4:30 AM Philippe Mathieu-Daudé wrote: > > To allow forks to easily decide which jobs they want to run, > but without disrupting the current default, move the current > set of jobs to a new file corresponding to the jobs run by > the mainstream project CI: > https://gitlab.com/qemu-project/qemu/-/pipelines > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/qemu-project.yml | 11 +++ > .gitlab-ci.yml| 8 +--- > 2 files changed, 12 insertions(+), 7 deletions(-) > create mode 100644 .gitlab-ci.d/qemu-project.yml > Reviewed-by: Willian Rampazzo
Re: [PATCH 09/12] tests/docker: drop CentOS 7 container
On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé wrote: > > It has been over two years since RHEL-8 was released, and thus per the > platform build policy, we no longer need to support RHEL-7 as a build > target. > > Signed-off-by: Daniel P. Berrangé > --- > .gitlab-ci.d/containers.yml | 5 --- > tests/docker/dockerfiles/centos7.docker | 43 - > 2 files changed, 48 deletions(-) > delete mode 100644 tests/docker/dockerfiles/centos7.docker > Reviewed-by: Willian Rampazzo
Re: [PATCH 03/12] crypto: bump min nettle to 3.3, dropping RHEL-7 support
On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé wrote: > > It has been over two years since RHEL-8 was released, and thus per the > platform build policy, we no longer need to support RHEL-7 as a build > target. This lets us increment the minimum required nettle version and > drop a lot of backwards compatibility code for 2.x series of nettle. > > Per repology, current shipping versions are: > > RHEL-8: 3.4.1 > Debian Stretch: 3.3 > Debian Buster: 3.4.1 > openSUSE Leap 15.2: 3.4.1 >Ubuntu LTS 18.04: 3.4 >Ubuntu LTS 20.04: 3.5.1 > FreeBSD: 3.7.2 > Fedora 33: 3.5.1 > Fedora 34: 3.7.2 > OpenBSD: 3.7.2 > macOS HomeBrew: 3.7.2 > > Debian Stretch has the oldest version and so 3.3 is the new minimum. > > Signed-off-by: Daniel P. Berrangé > --- > .gitlab-ci.yml | 10 -- > configure | 4 +--- > crypto/cipher-nettle.c.inc | 31 --- > crypto/hash-nettle.c | 4 > crypto/hmac-nettle.c | 4 ---- > 5 files changed, 1 insertion(+), 52 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 05/12] crypto: bump min gcrypt to 1.7.6, dropping RHEL-7 support
On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé wrote: > > It has been over two years since RHEL-8 was released, and thus per the > platform build policy, we no longer need to support RHEL-7 as a build > target. This lets us increment the minimum required gcrypt version and > assume that HMAC is always supported > > Per repology, current shipping versions are: > > RHEL-8: 1.8.5 > Debian Stretch: 1.7.6 > Debian Buster: 1.8.4 > openSUSE Leap 15.2: 1.8.2 >Ubuntu LTS 18.04: 1.8.1 >Ubuntu LTS 20.04: 1.8.5 > FreeBSD: 1.9.2 > Fedora 33: 1.8.6 > Fedora 34: 1.9.3 > OpenBSD: 1.9.3 > macOS HomeBrew: 1.9.3 > > Debian Stretch has the oldest version and so 1.7.6 is the new minimum. > > Signed-off-by: Daniel P. Berrangé > --- > .gitlab-ci.yml | 10 -- > configure | 18 +- > crypto/meson.build | 6 +----- > 3 files changed, 2 insertions(+), 32 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 06/12] crypto: bump min gnutls to 3.5.8, dropping RHEL-7 support
On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé wrote: > > It has been over two years since RHEL-8 was released, and thus per the > platform build policy, we no longer need to support RHEL-7 as a build > target. This lets us increment the minimum required gnutls version > > Per repology, current shipping versions are: > > RHEL-8: 3.6.14 > Debian Stretch: 3.5.8 > Debian Buster: 3.6.7 > openSUSE Leap 15.2: 3.6.7 >Ubuntu LTS 18.04: 3.5.18 >Ubuntu LTS 20.04: 3.6.13 > FreeBSD: 3.6.15 > Fedora 33: 3.6.16 > Fedora 34: 3.7.1 > OpenBSD: 3.6.15 > macOS HomeBrew: 3.6.15 > > Debian Stretch has the oldest version and so 1.7.6 is the new minimum. > > Signed-off-by: Daniel P. Berrangé > --- > .gitlab-ci.yml | 15 --- > configure | 2 +- > 2 files changed, 1 insertion(+), 16 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 10/12] bump min required glib version to 2.50
On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé wrote: > > The glib version was not previously constrained by RHEL-7 since it > rebases fairly often. Instead SLES 12 and Ubuntu 16.04 were the > constraints in 00f2cfbbec63fb6f5a7789797a62ccedd22466ea. Both of > these are old enough that they are outside our platform support > matrix now. > > Per repology, current shipping versions are: > > RHEL-8: 2.56.4 > Debian Stretch: 2.50.3 > Debian Buster: 2.58.3 > openSUSE Leap 15.2: 2.62.6 >Ubuntu LTS 18.04: 2.56.4 >Ubuntu LTS 20.04: 2.64.6 > FreeBSD: 2.66.7 > Fedora 33: 2.66.8 > Fedora 34: 2.68.1 > OpenBSD: 2.68.1 > macOS HomeBrew: 2.68.1 > > Thus Debian Stretch is the constraint for GLib version now. > > Signed-off-by: Daniel P. Berrangé > --- > configure | 2 +- > include/glib-compat.h | 9 -- > util/oslib-win32.c| 204 ------ > 3 files changed, 1 insertion(+), 214 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 07/12] crypto: drop used conditional check
On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé wrote: > > The condition being tested has never been set since the day the code was > first introduced. > > Signed-off-by: Daniel P. Berrangé > --- > crypto/tlscredsx509.c | 2 -- > 1 file changed, 2 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 11/12] configure: bump min required GCC to 6.3.0
On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé wrote: > > Several distros have been dropped since the last time we bumped the > minimum required GCC version. > > Per repology, currently shipping versions are: > > RHEL-8: 8.3.1 > Debian Stretch: 6.3.0 > Debian Buster: 8.3.0 > openSUSE Leap 15.2: 7.5.0 >Ubuntu LTS 18.04: 7.5.0 >Ubuntu LTS 20.04: 9.3.0 > FreeBSD: 10.3.0 > Fedora 33: 9.2.0 > Fedora 34: 11.0.1 > OpenBSD: 8.4.0 > macOS HomeBrew: 11.1.0 > > With this list Debian Stretch is the constraint at 6.3.0 > > Signed-off-by: Daniel P. Berrangé > --- > configure | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2
On Tue, May 11, 2021 at 10:28 AM Daniel P. Berrangé wrote: > > Several distros have been dropped since the last time we bumped the > minimum required CLang version. > > Per repology, currently shipping versions are: > > RHEL-8: 10.0.1 > Debian Stretch: 7.0.1 > Debian Buster: 7.0.1 > openSUSE Leap 15.2: 9.0.1 >Ubuntu LTS 18.04: 10.0.0 >Ubuntu LTS 20.04: 11.0.0 > FreeBSD 12: 8.0.1 > Fedora 33: 11.0.0 > Fedora 34: 11.1.0 > > With this list Debian Stretch is the constraint at 7.0.1 > > An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2 > which dates from March 2019. > > Signed-off-by: Daniel P. Berrangé > --- > configure | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > Reviewed-by: Willian Rampazzo
Re: non-x86 runners in the Gitlab-CI (was: Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2)
Hi Thomas, On Wed, May 12, 2021 at 8:54 AM Thomas Huth wrote: > > On 12/05/2021 13.44, Philippe Mathieu-Daudé wrote: > > On 5/11/21 3:26 PM, Daniel P. Berrangé wrote: > >> Several distros have been dropped since the last time we bumped the > >> minimum required CLang version. > >> > >> Per repology, currently shipping versions are: > >> > >> RHEL-8: 10.0.1 > >> Debian Stretch: 7.0.1 > >>Debian Buster: 7.0.1 > >> openSUSE Leap 15.2: 9.0.1 > >> Ubuntu LTS 18.04: 10.0.0 > >> Ubuntu LTS 20.04: 11.0.0 > >> FreeBSD 12: 8.0.1 > >>Fedora 33: 11.0.0 > >>Fedora 34: 11.1.0 > >> > >> With this list Debian Stretch is the constraint at 7.0.1 > >> > >> An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2 > >> which dates from March 2019. > > > > But we still rely on Travis-CI (Ubuntu Bionic 18.04 LTS) > > for non-x86 targets until we have figured out who is willing > > to share/maintain such non-x86 native runners on Gitlab. > > Hi Cleber, > > by the way, what's the status of your patch series to get the dedicated CI > machines (s390x, aarch64, ...) running in our Gitlab-CI? AFAIK the last > iteration of your patches has been weeks ago, so I wonder whether you could > finally send a new version with the requested fixes included? ... this topic > slowly gets more and more urgent now that our Travis-CI is in process of > dying... I don't know if you saw this: https://docs.travis-ci.com/user/billing-overview/#partner-queue-solution. tl;dr, Travis now has support from partners to run non-x86 arch. It is always good to have a plan B, like qemu own CI runners, but, at least, with these non-x86 arch available on Travis, we will have some time to breathe. > > Thomas >
Re: non-x86 runners in the Gitlab-CI (was: Re: [PATCH 12/12] configure: bump min required CLang to 7.0.0 / XCode 10.2)
On Wed, May 12, 2021 at 10:56 AM Thomas Huth wrote: > > On 12/05/2021 15.47, Willian Rampazzo wrote: > > Hi Thomas, > > > > On Wed, May 12, 2021 at 8:54 AM Thomas Huth wrote: > >> > >> On 12/05/2021 13.44, Philippe Mathieu-Daudé wrote: > >>> On 5/11/21 3:26 PM, Daniel P. Berrangé wrote: > >>>> Several distros have been dropped since the last time we bumped the > >>>> minimum required CLang version. > >>>> > >>>> Per repology, currently shipping versions are: > >>>> > >>>>RHEL-8: 10.0.1 > >>>>Debian Stretch: 7.0.1 > >>>> Debian Buster: 7.0.1 > >>>>openSUSE Leap 15.2: 9.0.1 > >>>> Ubuntu LTS 18.04: 10.0.0 > >>>> Ubuntu LTS 20.04: 11.0.0 > >>>>FreeBSD 12: 8.0.1 > >>>> Fedora 33: 11.0.0 > >>>> Fedora 34: 11.1.0 > >>>> > >>>> With this list Debian Stretch is the constraint at 7.0.1 > >>>> > >>>> An LLVM version of 7.0.1 corresponds to macOS XCode version of 10.2 > >>>> which dates from March 2019. > >>> > >>> But we still rely on Travis-CI (Ubuntu Bionic 18.04 LTS) > >>> for non-x86 targets until we have figured out who is willing > >>> to share/maintain such non-x86 native runners on Gitlab. > >> > >>Hi Cleber, > >> > >> by the way, what's the status of your patch series to get the dedicated CI > >> machines (s390x, aarch64, ...) running in our Gitlab-CI? AFAIK the last > >> iteration of your patches has been weeks ago, so I wonder whether you could > >> finally send a new version with the requested fixes included? ... this > >> topic > >> slowly gets more and more urgent now that our Travis-CI is in process of > >> dying... > > > > I don't know if you saw this: > > https://docs.travis-ci.com/user/billing-overview/#partner-queue-solution. > > > > tl;dr, Travis now has support from partners to run non-x86 arch. It is > > always good to have a plan B, like qemu own CI runners, but, at least, > > with these non-x86 arch available on Travis, we will have some time to > > breathe. > > Uh, that's what we're already using in our travis.yml ... but I guess you've > rather missed: > > https://blog.travis-ci.com/2021-05-07-orgshutdown > > and on travis-ci.com, the CI minutes are not for free anymore. At least not > for the QEMU project. Or do you know of a sponsor who is going to pay the CI > minutes for us there? > The link I posted tells arm and s390x will still be free for OSS projects. >From that page: IBM CPU builds in IBM Cloud (sponsored by IBM) ARM64 CPU builds in Equinix Metal (former Packet) infrastructure (sponsored by ARM) Willian > Thomas >
Re: [PATCH v4 1/3] Acceptance test: adds param 'address' in _get_free_port
On Mon, Mar 23, 2020 at 7:30 AM Oksana Vohchana wrote:
>
> In the migration test function _get_free_port works only for localhost,
> but in the case to use migration through an RDMA we need to get a free port
> on the configured network RDMA-interface.
> This patch is the start for another migration option
>
> Signed-off-by: Oksana Vohchana
> ---
> tests/acceptance/migration.py | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/acceptance/migration.py b/tests/acceptance/migration.py
> index a8367ca023..e4c39b85a1 100644
> --- a/tests/acceptance/migration.py
> +++ b/tests/acceptance/migration.py
> @@ -52,8 +52,8 @@ class Migration(Test):
> source_vm.qmp('migrate', uri=src_uri)
> self.assert_migration(source_vm, dest_vm)
>
> -def _get_free_port(self):
> -port = network.find_free_port()
> +def _get_free_port(self, address='localhost'):
> +port = network.find_free_port(address=address)
> if port is None:
> self.cancel('Failed to find a free port')
> return port
> --
> 2.21.1
>
Just confirming,
Reviewed-by: Willian Rampazzo
Re: [PATCH-for-5.0 1/7] tests/acceptance/machine_sparc_leon3: Disable HelenOS test
On Tue, Mar 31, 2020 at 5:07 PM Philippe Mathieu-Daudé wrote: > > First job failed by timeout, 2nd succeeded: > https://travis-ci.org/github/philmd/qemu/jobs/669265466 > > However "Ran for 46 min 48 sec" > > From the log: > > Fetching asset from > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_mips64el_malta_5KEc_cpio > Fetching asset from > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_mips64el_malta_5KEc_cpio > Fetching asset from > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi > Fetching asset from > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_initrd > Fetching asset from > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_initrd > Fetching asset from > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_sd > Fetching asset from > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_sd > Fetching asset from > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_bionic > Fetching asset from > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_uboot_netbsd9 > Fetching asset from > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_uboot_netbsd9 > Fetching asset from > tests/acceptance/ppc_prep_40p.py:IbmPrep40pMachine.test_openbios_and_netbsd > ... > (13/82) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_mips64el_malta_5KEc_cpio: > SKIP: untrusted code > (24/82) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_bionic: > SKIP: storage limited > ... > (25/82) > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_uboot_netbsd9: > SKIP: storage limited > ... > (63/82) > tests/acceptance/ppc_prep_40p.py:IbmPrep40pMachine.test_openbios_and_netbsd: > SKIP: Running on Travis-CI > > Is it possible that we are now fetching assets for tests we are not > running? In particular the one marked @skip because the downloading time > was too long on Travis? Yes, your assumption is correct, this execution of Avocado downloaded assets for tests that were skipped. Let me try to explain how the asset feature works today on Avocado. Avocado has two basic ways to work with assets: 1. Parse limited use cases of `fetch_asset` call in the test file and execute them. This operation can happen in two different scenarios. First, when using the command line `avocado assets fetch `. In this case, it is a standalone execution of each fetch call and the test is not executed at all. Second, by running the test. The, enabled by default, plugin FetchAssetJob will do the same operation of parsing the test file and executing occurrences of `fetch_asset` call before the tests start to run. Again, the fetch time is not computed in the job time. 2. Execute the `fetch_asset` call from each test during the test execution. In this case, the FetchAssetJob plugin should be disabled. The fetch time is added to the job time as the asset download occurs during the test execution. The acceptance tests which make use of `fetch_asset` are all using the first method with FetchAssetJob plugin enabled. As Avocado is parsing the test file before it starts to run the tests, it is not aware of possible skips that may occur during a test execution due to possible dynamic dependency. This is not the desired behavior, as you mentioned, Avocado is downloading an asset that will not be used because its test will be skipped. To minimize the damage on the download side, the Travis job is holding the avocado cache. It means the download should happen just once. This does not minimize the damage to space usage. One possible workaround here is to temporarily disable the FetchAssetJob plugin, now that the needed assets are on Travis Avocado cache. The downside is that when an asset is not available in the cache, it will be downloaded during the test execution and the download time will be added to the job time. I don't know if it is possible to manually remove an asset from Travis Avocado cache. If so, this can be done for the tests that should be skipped because of space usage. We have been trying to make the Asset feature as flexible as possible to accommodate the use cases we have been identifying. Thanks for reporting this! > > RESULTS: PASS 65 | ERROR 0 | FAIL 0 | SKIP 14 | WARN 0 | INTERRUPT 0 > | CANCEL 3 > JOB TIME : 1480.72 s > > Does this "JOB TIME" sums the 'Fetching asset' part? Answered in the comments above. > > Thanks, > > Phil. > Willian
Re: [PATCH-for-5.0 1/7] tests/acceptance/machine_sparc_leon3: Disable HelenOS test
On Wed, Apr 1, 2020 at 5:21 PM Philippe Mathieu-Daudé wrote: > Odd, with avocado-framework==76.0 I get: > > https://travis-ci.org/github/philmd/qemu/jobs/669851870#L4908 > > Traceback (most recent call last): >File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main > "__main__", mod_spec) >File "/usr/lib/python3.6/runpy.py", line 85, in _run_code > exec(code, run_globals) >File > "/home/travis/build/philmd/qemu/build/tests/venv/lib/python3.6zsite-packages/avocado/__main__.py", > line 11, in > sys.exit(main.run()) >File > "/home/travis/build/philmd/qemu/build/tests/venv/lib/python3.6/site-packages/avocado/core/app.py", > line 91, in run > return method(self.parser.config) >File > "/home/travis/build/philmd/qemu/build/tests/venv/lib/python3.6/site-packages/avocado/plugins/assets.py", > line 291, in run > success, fail = fetch_assets(test_file) >File > "/home/travis/build/philmd/qemu/build/tests/venv/lib/python3.6/site-packages/avocado/plugins/assets.py", > line 200, in fetch_assets > handler = FetchAssetHandler(test_file, klass, method) >File > "/home/travis/build/philmd/qemu/build/tests/venv/lib/python3.6/site-packages/avocado/plugins/assets.py", > line 65, in __init__ > self.visit(self.tree) >File "/usr/lib/python3.6/ast.py", line 253, in visit > return visitor(node) >File "/usr/lib/python3.6/ast.py", line 261, in generic_visit > self.visit(item) >File "/usr/lib/python3.6/ast.py", line 253, in visit > return visitor(node) >File > "/home/travis/build/philmd/qemu/build/tests/venv/lib/python3.6/site-packages/avocado/plugins/assets.py", > line 139, in visit_ClassDef > self.generic_visit(node) >File "/usr/lib/python3.6/ast.py", line 261, in generic_visit > self.visit(item) >File "/usr/lib/python3.6/ast.py", line 253, in visit > return visitor(node) >File > "/home/travis/build/philmd/qemu/build/tests/venv/lib/python3.6/site-packages/avocado/plugins/assets.py", > line 171, in visit_Assign > self.asgmts[cur_klass][cur_method][name] = node.value.s > KeyError: 'launch_and_wait' > /home/travis/build/philmd/qemu/tests/Makefile.include:910: recipe for > target 'fetch-acceptance-assets' failed > > This launch_and_wait comes from: > > tests/acceptance/boot_linux.py:88:def launch_and_wait(self): Sorry about that. This is a known bug, see https://github.com/avocado-framework/avocado/issues/3661. It is fixed upstream and will be available in the next release of Avocado. Willian
Re: [PATCH-for-5.0 1/7] tests/acceptance/machine_sparc_leon3: Disable HelenOS test
On Thu, Apr 2, 2020 at 8:08 AM Philippe Mathieu-Daudé wrote: > > This issue persists, OTOH the good news is caching is working: > > https://travis-ci.org/github/philmd/qemu/builds/670078763#L1626 > Philippe, do you have a way to clean up the Travis cache and try it again? Last week, when I was investigating the previous problem you reported, I had the same issue as you are having now. The problem just disappeared without any action. I could not reproduce the problem now on an empty cache using the same command you used. I suspect the previous bug left some inconsistencies in the cache. [wrampazz@wrampazz qemu.philippe]$ avocado --config ../avocado.conf assets fetch tests/acceptance/*.py Fetching assets from tests/acceptance/boot_linux_console.py. File https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/29/Everything/x86_64/os/images/pxeboot/vmlinuz fetched or already on cache. File http://snapshot.debian.org/archive/debian/20130217T032700Z/pool/main/l/linux-2.6/linux-image-2.6.32-5-4kc-malta_2.6.32-48_mips.deb fetched or already on cache. File http://snapshot.debian.org/archive/debian/20130217T032700Z/pool/main/l/linux-2.6/linux-image-2.6.32-5-5kc-malta_2.6.32-48_mipsel.deb fetched or already on cache. File http://snapshot.debian.org/archive/debian/20160601T041800Z/pool/main/l/linux/linux-image-4.5.0-2-4kc-malta_4.5.5-1_mips.deb fetched or already on cache. File https://github.com/groeck/linux-build-test/raw/8584a59ed9e5eb5ee7ca91f6d74bbb06619205b8/rootfs/mips/rootfs.cpio.gz fetched or already on cache. File https://github.com/philmd/qemu-testing-blob/raw/9ad2df38/mips/malta/mips64el/vmlinux-3.19.3.mtoman.20150408 fetched or already on cache. File https://github.com/groeck/linux-build-test/raw/8584a59e/rootfs/mipsel64/rootfs.mipsel64r1.cpio.gz fetched or already on cache. File https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/29/Everything/aarch64/os/images/pxeboot/vmlinuz fetched or already on cache. File https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/29/Everything/armhfp/os/images/pxeboot/vmlinuz fetched or already on cache. File https://raw.githubusercontent.com/Subbaraya-Sundeep/qemu-test-binaries/fa030bd77a014a0b8e360d3b7011df89283a2f0b/u-boot fetched or already on cache. File https://raw.githubusercontent.com/Subbaraya-Sundeep/qemu-test-binaries/fa030bd77a014a0b8e360d3b7011df89283a2f0b/spi.bin fetched or already on cache. File http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20190215-1_armhf.deb fetched or already on cache. File https://snapshot.debian.org/archive/debian/20190928T224601Z/pool/main/l/linux/linux-image-4.19.0-6-armmp_4.19.67-2+deb10u1_armhf.deb fetched or already on cache. File https://github.com/groeck/linux-build-test/raw/2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/arm/rootfs-armv5.cpio.gz fetched or already on cache. File https://apt.armbian.com/pool/main/l/linux-4.20.7-sunxi/linux-image-dev-sunxi_5.75_armhf.deb fetched or already on cache. File https://github.com/groeck/linux-build-test/raw/2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/arm/rootfs-armv5.cpio.gz fetched or already on cache. File https://apt.armbian.com/pool/main/l/linux-4.20.7-sunxi/linux-image-dev-sunxi_5.75_armhf.deb fetched or already on cache. File https://github.com/groeck/linux-build-test/raw/2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/arm/rootfs-armv5.ext2.gz fetched or already on cache. File https://apt.armbian.com/pool/main/l/linux-4.20.7-sunxi/linux-image-dev-sunxi_5.75_armhf.deb fetched or already on cache. File https://apt.armbian.com/pool/main/l/linux-4.20.7-sunxi/linux-image-dev-sunxi_5.75_armhf.deb fetched or already on cache. File https://github.com/groeck/linux-build-test/raw/2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/arm/rootfs-armv7a.cpio.gz fetched or already on cache. File https://apt.armbian.com/pool/main/l/linux-4.20.7-sunxi/linux-image-dev-sunxi_5.75_armhf.deb fetched or already on cache. File http://storage.kernelci.org/images/rootfs/buildroot/kci-2019.02/armel/base/rootfs.ext2.xz fetched or already on cache. File https://dl.armbian.com/orangepipc/archive/Armbian_19.11.3_Orangepipc_bionic_current_5.3.9.7z fetched or already on cache. File http://snapshot.debian.org/archive/debian/20200108T145233Z/pool/main/u/u-boot/u-boot-sunxi_2020.01%2Bdfsg-1_armhf.deb fetched or already on cache. File https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/evbarm-earmv7hf/binary/gzimg/armv7.img.gz fetched or already on cache. File https://archives.fedoraproject.org/pub/archive/fedora-secondary/releases/29/Everything/s390x/os/images/kernel.img fetched or already on cache. File http://archive.debian.org/debian/dists/lenny/main/installer-alpha/current/images/cdrom/vmlinuz fetched or already on cache. File https://archives.fedoraproject.org/pub/archive/fedora-secondary/releases/29/Everything/ppc64le/os/ppc/ppc64/vmlinu
Re: [PATCH] tests/acceptance/ppc_prep_40p: Use cdn.netbsd.org hostname
> That certainly sounds like an improvement. I still don't love the > idea that the test results will vary based on something outside of the > tested code, even if a cancel is definitely better than a fail. During the development of Avocado release 76.0, we have discussed how to implement a new resolver that gathers requirements listed for a test and fulfills them before the test starts. The discussion resulted in blueprint BP002 [1]. We are in the last development week of release 77.0, so the development of this new feature should start during the next release cycle. > > > +Willian can explain how it works, and if found to be suitable, and work > > on a patch. > > Ok. That would be good to know - will there be some command to run in > advance to attempt to download all the necessary images? Would that > run without a timeout - or at least a much longer timeout than the > testcase itself has. In the current release development (77.0), we are adding a feature that makes it possible to cancel a test if an asset is not available in the cache. It should be as simple as setting two parameters during the fetch call, like: bios_path = self.fetch_asset(bios_url, asset_hash=bios_hash, find_only=True, cancel_on_missing=True) Release 77.0 of Avocado is scheduled for the beginning of next week. As soon as it is available, I can send a patch to bump the Avocado version for qemu tests and a patch to this test enabling this new feature. Since avocado 73.0, it is possible to fetch the assets from a test without actually running the test. It is a feature that parses the test code looking for the fetch_asset call and its parameters defined as variables, at a limited depth. I have tested it on ppc_prep_40p.py, and it works as expected. This command does not have a timeout for fetching the assets and is as follows: avocado assets fetch ppc_prep_40p.py The upcoming feature to cancel the test when an asset is not available used in conjunction with the command line fetch should give some flexibility to people running this test while the resolver is under development. [1] https://avocado-framework.readthedocs.io/en/latest/blueprints/BP002.html
Re: [PATCH 2/2] tests: Exclude 'boot_linux.py' from fetch-acceptance rule
On Fri, Jul 24, 2020 at 3:26 PM Wainer dos Santos Moschetta wrote: > > Hi Philippe, > > On 7/24/20 4:35 AM, Philippe Mathieu-Daudé wrote: > > The boot_linux.py file triggers an exception: > > > >$ make fetch-acceptance > >AVOCADO tests/acceptance > >Fetching assets from tests/acceptance/empty_cpu_model.py. > >Fetching assets from tests/acceptance/vnc.py. > >Fetching assets from tests/acceptance/boot_linux_console.py. > >Fetching assets from tests/acceptance/boot_linux.py. > >Traceback (most recent call last): > > File > > "/var/tmp/qemu-builddir/tests/venv/lib64/python3.7/site-packages/avocado/__main__.py", > > line 11, in > >sys.exit(main.run()) > > File > > "/var/tmp/qemu-builddir/tests/venv/lib64/python3.7/site-packages/avocado/core/app.py", > > line 91, in run > >return method(self.parser.config) > > File > > "/var/tmp/qemu-builddir/tests/venv/lib64/python3.7/site-packages/avocado/plugins/assets.py", > > line 291, in run > >success, fail = fetch_assets(test_file) > > File > > "/var/tmp/qemu-builddir/tests/venv/lib64/python3.7/site-packages/avocado/plugins/assets.py", > > line 200, in fetch_assets > >handler = FetchAssetHandler(test_file, klass, method) > > File > > "/var/tmp/qemu-builddir/tests/venv/lib64/python3.7/site-packages/avocado/plugins/assets.py", > > line 65, in __init__ > >self.visit(self.tree) > > File "/usr/lib64/python3.7/ast.py", line 271, in visit > >return visitor(node) > > File "/usr/lib64/python3.7/ast.py", line 279, in generic_visit > >self.visit(item) > > File "/usr/lib64/python3.7/ast.py", line 271, in visit > >return visitor(node) > > File > > "/var/tmp/qemu-builddir/tests/venv/lib64/python3.7/site-packages/avocado/plugins/assets.py", > > line 139, in visit_ClassDef > >self.generic_visit(node) > > File "/usr/lib64/python3.7/ast.py", line 279, in generic_visit > >self.visit(item) > > File "/usr/lib64/python3.7/ast.py", line 271, in visit > >return visitor(node) > > File > > "/var/tmp/qemu-builddir/tests/venv/lib64/python3.7/site-packages/avocado/plugins/assets.py", > > line 171, in visit_Assign > >self.asgmts[cur_klass][cur_method][name] = node.value.s > >KeyError: 'launch_and_wait' > >make: *** [tests/Makefile.include:949: fetch-acceptance] Error 1 > > Currently the acceptance tests use Avocado 7.6. I bumped to 80.0 (latest > released) here and that error is gone. Could you double check? > > Regards, > > Wainer Hi Wainer, thanks for looking at this problem. This bug was fixed here https://github.com/avocado-framework/avocado/pull/3665, on release 78 of Avocado. It was reported by Philippe at that time. I think we forgot to bump the Avocado version here. > > > > > Exclude it for now. We will revert this commit once the script is > > fixed. > > > > Signed-off-by: Philippe Mathieu-Daudé > > --- > > tests/Makefile.include | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tests/Makefile.include b/tests/Makefile.include > > index 238974d8da..7c9cf7a818 100644 > > --- a/tests/Makefile.include > > +++ b/tests/Makefile.include > > @@ -950,7 +950,7 @@ fetch-acceptance: check-venv > > $(TESTS_VENV_DIR)/bin/python -m avocado \ > > $(if $(V),--show=$(AVOCADO_SHOW)) \ > > assets fetch \ > > -$(wildcard tests/acceptance/*.py), \ > > +$(filter-out tests/acceptance/boot_linux.py,$(wildcard > > tests/acceptance/*.py)), \ > > "AVOCADO", "tests/acceptance") > > > > check-acceptance: check-venv $(TESTS_RESULTS_DIR) get-vm-images >
Re: [PATCH v2] docs/devel/testing.rst: Fix references to unit tests
On Thu, Mar 18, 2021 at 2:49 PM Wainer dos Santos Moschetta
wrote:
>
> With the recent move of the unit tests to tests/unit directory some
> instructions under the "Unit tests" section became imprecise, which
> are fixed by this change.
>
> Fixes: da668aa15b99 ("tests: Move unit tests into a separate directory")
> Signed-off-by: Wainer dos Santos Moschetta
> Reviewed-by: Thomas Huth
> ---
> v1->v2:
> * Fixed typo on subject [jsnow]
> * Replaced Related-to with Fixes [jsnow]
>
> docs/devel/testing.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Reviewed-by: Willian Rampazzo
Re: [RFC PATCH] gitlab: default to not building the documentation
On Mon, Mar 22, 2021 at 11:41 AM Alex Bennée wrote:
>
> In d0f26e68a0 ("gitlab: force enable docs build in Fedora, Ubuntu,
> Debian") we made sure we can build the documents on more than one
> system. However we don't want to build documents all the time as it's
> a waste of cycles (and energy). So lets reduce the total amount of
> documentation we build while still keeping some coverage.
>
> Fixes: a8a3abe0b3 ("gitlab: move docs and tools build across from Travis")
> Signed-off-by: Alex Bennée
> ---
> .gitlab-ci.yml | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
Reviewed-by: Willian Rampazzo
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 9ffbaa7ffb..7714c7cac8 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -23,9 +23,9 @@ include:
> - cd build
> - if test -n "$TARGETS";
>then
> -../configure --enable-werror $CONFIGURE_ARGS
> --target-list="$TARGETS" ;
> +../configure --enable-werror --disable-docs $CONFIGURE_ARGS
> --target-list="$TARGETS" ;
>else
> -../configure --enable-werror $CONFIGURE_ARGS ;
> +../configure --enable-werror --disable-docs $CONFIGURE_ARGS ;
>fi || { cat config.log meson-logs/meson-log.txt && exit 1; }
> - if test -n "$LD_JOBS";
>then
> @@ -119,7 +119,7 @@ build-system-ubuntu:
> job: amd64-ubuntu2004-container
>variables:
> IMAGE: ubuntu2004
> -CONFIGURE_ARGS: --enable-fdt=system --enable-slirp=system
> +CONFIGURE_ARGS: --enable-docs --enable-fdt=system --enable-slirp=system
> TARGETS: aarch64-softmmu alpha-softmmu cris-softmmu hppa-softmmu
>moxie-softmmu microblazeel-softmmu mips64el-softmmu
> MAKE_CHECK_ARGS: check-build
> @@ -443,7 +443,7 @@ build-user-centos7:
> job: amd64-centos7-container
>variables:
> IMAGE: centos7
> -CONFIGURE_ARGS: --disable-system --disable-tools --disable-docs
> +CONFIGURE_ARGS: --disable-system --disable-tools
> MAKE_CHECK_ARGS: check-tcg
>
> build-some-softmmu-plugins:
> @@ -607,7 +607,7 @@ tsan-build:
> job: amd64-ubuntu2004-container
>variables:
> IMAGE: ubuntu2004
> -CONFIGURE_ARGS: --enable-tsan --cc=clang-10 --cxx=clang++-10
> --disable-docs
> +CONFIGURE_ARGS: --enable-tsan --cc=clang-10 --cxx=clang++-10
>--enable-trace-backends=ust --enable-fdt=system
> --enable-slirp=system
> TARGETS: x86_64-softmmu ppc64-softmmu riscv64-softmmu x86_64-linux-user
> MAKE_CHECK_ARGS: bench V=1
> @@ -619,7 +619,7 @@ build-deprecated:
> job: amd64-debian-user-cross-container
>variables:
> IMAGE: debian-all-test-cross
> -CONFIGURE_ARGS: --disable-docs --disable-tools
> +CONFIGURE_ARGS: --disable-tools
> MAKE_CHECK_ARGS: build-tcg
> TARGETS: ppc64abi32-linux-user lm32-softmmu unicore32-softmmu
>artifacts:
> --
> 2.20.1
>
Re: [RFC PATCH] gitlab: extend timeouts for CFI builds
On Mon, Mar 22, 2021 at 11:21 AM Alex Bennée wrote: > > These builds are running very close to the default build limit and as > they are already pared down the only other option is to extend the > timeout a little to give some breathing room. > > Signed-off-by: Alex Bennée > --- > .gitlab-ci.yml | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Willian Rampazzo
Re: [PATCH v1 10/14] gitlab-ci.yml: Merge the trace-backend testing into other jobs
On Sat, Mar 20, 2021 at 10:37 AM Alex Bennée wrote: > > From: Thomas Huth > > Our gitlab-ci got quite slow in the past weeks, due to the immense amount > of jobs that we have, so we should try to reduce the number of jobs. > There is no real good reason for having separate jobs just to test the > trace backends, we can do this just fine in other jobs, too. > > Signed-off-by: Thomas Huth > Message-Id: <20210319095726.45965-1-th...@redhat.com> > Reviewed-by: Wainer dos Santos Moschetta > Signed-off-by: Alex Bennée > --- > .gitlab-ci.yml | 30 +++--- > 1 file changed, 3 insertions(+), 27 deletions(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH v3 2/5] tests/acceptance/boot_linux_console: remove Armbian 19.11.3 bionic test for orangepi-pc machine
Hi Philippe,
On Mon, Mar 22, 2021 at 1:59 PM Philippe Mathieu-Daudé wrote:
>
> On Mon, Mar 22, 2021 at 5:54 PM Philippe Mathieu-Daudé
> wrote:
> >
> > Hi Willian,
> >
> > On 3/8/21 9:44 PM, Willian Rampazzo wrote:
> > > On Mon, Mar 8, 2021 at 5:41 PM Willian Rampazzo
> > > wrote:
> > >>
>
> > >>>>>> -def do_test_arm_orangepi_uboot_armbian(self, image_path):
> > >>>>>> +@skipUnless(os.getenv('ARMBIAN_ARTIFACTS_CACHED'),
> > >>>>>> +'Test artifacts fetched from unreliable
> > >>>>>> apt.armbian.com')
> > >>>>>> +@skipUnless(os.getenv('AVOCADO_ALLOW_LARGE_STORAGE'), 'storage
> > >>>>>> limited')
> > >>>>>> +def test_arm_orangepi_bionic_20_08(self):
> > >>>>>> +"""
> > >>>>>> +:avocado: tags=arch:arm
> > >>>>>> +:avocado: tags=machine:orangepi-pc
> > >>>>>> +:avocado: tags=device:sd
> > >>>>>> +"""
> > >>>>>> +
> > >>>>>> +# This test download a 275 MiB compressed image and expand
> > >>>>>> it
> > >>>>>> +# to 1036 MiB, but the underlying filesystem is 1552 MiB...
> > >>>>>> +# As we expand it to 2 GiB we are safe.
> > >>>>>> +
> > >>>>>> +image_url = ('https://dl.armbian.com/orangepipc/archive/'
> > >>>>>> +
> > >>>>>> 'Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz')
> > >>>>>
> > >>>>> The Armbian 20 is not available on this link anymore. I can browse
> > >>>>> just 21.
> > >>>>
> > >>>> Cat-and-mouse game *sigh*.
> >
> > 2021-03-22 17:18:10,701 download L0067 INFO | Fetching
> > https://archive.armbian.com/orangepipc/archive/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz
> > -> /home/phil/avocado/da
> > ta/cache/by_location/f2eb27a12b81ce15e93f340fabbced2136af1caa/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz.nfwdzivg
> > 2021-03-22 17:18:11,263 assetL0136 INFO | Temporary asset
> > file unavailable due to failed download attempt.
> > 2021-03-22 17:18:11,263 assetL0368 ERROR| URLError: > error [Errno 113] No route to host>
> >
> > It might be a temporary problem, but looking long term the
> > current setup doesn't scale IMHO.
>
> Also I just noticed I *do* have the image cached, even twice:
>
> $ find /home/phil/avocado/data/cache/by_location/ -name
> Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz -ls
> 131661 280768 -rw-rw-r-- 1 phil phil 287501560 Oct 23
> 12:45
> /home/phil/avocado/data/cache/by_location/cac379e6a4480624b000dfde1b5d935454254ce2/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz
> 131761 280776 -rw-rw-r-- 1 phil phil 287501560 Feb 20
> 00:39
> /home/phil/avocado/data/cache/by_location/aac619d9e7ea3726ebc86c159fddfb9d3f6274a5/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz
>
> But the hash is different.
>
You have 2 images because you fetched them from different locations.
When you fetch by location, the assets go to the directory
representing the hash of the location, This allows, for example, the
fetch of multiple initrd or vmlinuz files from different locations,
representing different files, but with the same name. Also, this was
one of your requests some time ago :)
What Beraldo worked on in the last week was a way to remove "unused"
files. Your cache is a good example of files that are not necessary
anymore because now you are using a different location to fetch them.
> Cleber, why not use the blob hash as a cache key? It is supposed to be
> constant...
>
You can do that by setting the test to download the file by name, and
not by location.
> Cc'ing Beraldo because I guess remember he worked on improving Avocado cache.
>
> > >>> Just to clarify here: in this patch I wanted to only make the change to
> > >>> remove the test for the 19.11.3 image.
> > >>> And in the 3rd patch (tests/acceptance/boot_linux_console: change URL
> > >>> for test_arm_orangepi_bionic_20_08)
> > >>> do the update for to correct the 20.08 link. So each patch fixes one
> > >>> problem at a time.
>
Re: [PATCH v3 2/5] tests/acceptance/boot_linux_console: remove Armbian 19.11.3 bionic test for orangepi-pc machine
Hi Philippe,
On Mon, Mar 22, 2021 at 1:54 PM Philippe Mathieu-Daudé wrote:
>
> Hi Willian,
>
> On 3/8/21 9:44 PM, Willian Rampazzo wrote:
> > On Mon, Mar 8, 2021 at 5:41 PM Willian Rampazzo wrote:
> >>
> >> On Mon, Mar 8, 2021 at 5:32 PM Niek Linnenbank
> >> wrote:
> >>>
> >>> Hi Philippe, Willian,
> >>>
> >>> On Mon, Mar 8, 2021 at 8:52 AM Philippe Mathieu-Daudé
> >>> wrote:
> >>>>
> >>>> On 3/5/21 4:16 PM, Willian Rampazzo wrote:
> >>>>> On Thu, Mar 4, 2021 at 5:44 PM Niek Linnenbank
> >>>>> wrote:
> >>>>>>
> >>>>>> The image for Armbian 19.11.3 bionic has been removed from the armbian
> >>>>>> server.
> >>>>>> Without the image as input the test arm_orangepi_bionic_19_11 cannot
> >>>>>> run.
> >>>>>>
> >>>>>> This commit removes the test completely and merges the code of the
> >>>>>> generic function
> >>>>>> do_test_arm_orangepi_uboot_armbian back with the 20.08 test.
> >>>>>>
> >>>>>> Signed-off-by: Niek Linnenbank
> >>>>>> ---
> >>>>>> tests/acceptance/boot_linux_console.py | 72 --
> >>>>>> 1 file changed, 23 insertions(+), 49 deletions(-)
> >>>>>>
> >>>>>> diff --git a/tests/acceptance/boot_linux_console.py
> >>>>>> b/tests/acceptance/boot_linux_console.py
> >>>>>> index eb01286799..9fadea9958 100644
> >>>>>> --- a/tests/acceptance/boot_linux_console.py
> >>>>>> +++ b/tests/acceptance/boot_linux_console.py
> >>>>>> @@ -802,7 +802,29 @@ def test_arm_orangepi_sd(self):
> >>>>>> # Wait for VM to shut down gracefully
> >>>>>> self.vm.wait()
> >>>>>>
> >>>>>> -def do_test_arm_orangepi_uboot_armbian(self, image_path):
> >>>>>> +@skipUnless(os.getenv('ARMBIAN_ARTIFACTS_CACHED'),
> >>>>>> +'Test artifacts fetched from unreliable
> >>>>>> apt.armbian.com')
> >>>>>> +@skipUnless(os.getenv('AVOCADO_ALLOW_LARGE_STORAGE'), 'storage
> >>>>>> limited')
> >>>>>> +def test_arm_orangepi_bionic_20_08(self):
> >>>>>> +"""
> >>>>>> +:avocado: tags=arch:arm
> >>>>>> +:avocado: tags=machine:orangepi-pc
> >>>>>> +:avocado: tags=device:sd
> >>>>>> +"""
> >>>>>> +
> >>>>>> +# This test download a 275 MiB compressed image and expand it
> >>>>>> +# to 1036 MiB, but the underlying filesystem is 1552 MiB...
> >>>>>> +# As we expand it to 2 GiB we are safe.
> >>>>>> +
> >>>>>> +image_url = ('https://dl.armbian.com/orangepipc/archive/'
> >>>>>> +
> >>>>>> 'Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz')
> >>>>>
> >>>>> The Armbian 20 is not available on this link anymore. I can browse just
> >>>>> 21.
> >>>>
> >>>> Cat-and-mouse game *sigh*.
>
> 2021-03-22 17:18:10,701 download L0067 INFO | Fetching
> https://archive.armbian.com/orangepipc/archive/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz
> -> /home/phil/avocado/da
> ta/cache/by_location/f2eb27a12b81ce15e93f340fabbced2136af1caa/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz.nfwdzivg
> 2021-03-22 17:18:11,263 assetL0136 INFO | Temporary asset
> file unavailable due to failed download attempt.
> 2021-03-22 17:18:11,263 assetL0368 ERROR| URLError: error [Errno 113] No route to host>
>
> It might be a temporary problem, but looking long term the
> current setup doesn't scale IMHO.
>
Have you changed something in the test? The test is supposed to skip
when the asset is not available in the cache. What was the result of
this test execution? Skip, fail, or error? If it was not Skip, we need
to investigate what happened.
> >>> Just to clarify here: in this patch I wanted to only make the change to
> >>> remove the test for the 19.11.3 image.
> >>> And in the 3rd patch (tests/acceptance/boot_linux_console: change URL for
> >>> test_arm_orangepi_bionic_20_08)
> >>> do the update for to correct the 20.08 link. So each patch fixes one
> >>> problem at a time.
> >>>
> >>> Does that make sense, or do you prefer that I combine them in a single
> >>> patch instead?
> >>
> >> Ops, I forgot about the 3rd patch in this series. That makes sense to
> >> me, sorry for the mess.
> >>
> >
> > And, in this case,
> >
> > Reviewed-by: Willian Rampazzo
> >
> >>>
> >>> Regards,
> >>> Niek
> >>>
> >>> --
> >>> Niek Linnenbank
> >>>
> >
>
Re: [PATCH v3 2/5] tests/acceptance/boot_linux_console: remove Armbian 19.11.3 bionic test for orangepi-pc machine
On Mon, Mar 22, 2021 at 2:24 PM Philippe Mathieu-Daudé wrote:
>
> On 3/22/21 6:12 PM, Willian Rampazzo wrote:
> > Hi Philippe,
> >
> > On Mon, Mar 22, 2021 at 1:59 PM Philippe Mathieu-Daudé
> > wrote:
> >>
> >> On Mon, Mar 22, 2021 at 5:54 PM Philippe Mathieu-Daudé
> >> wrote:
> >>>
> >>> Hi Willian,
> >>>
> >>> On 3/8/21 9:44 PM, Willian Rampazzo wrote:
> >>>> On Mon, Mar 8, 2021 at 5:41 PM Willian Rampazzo
> >>>> wrote:
> >>>>>
> >>
> >>>>>>>>> -def do_test_arm_orangepi_uboot_armbian(self, image_path):
> >>>>>>>>> +@skipUnless(os.getenv('ARMBIAN_ARTIFACTS_CACHED'),
> >>>>>>>>> +'Test artifacts fetched from unreliable
> >>>>>>>>> apt.armbian.com')
> >>>>>>>>> +@skipUnless(os.getenv('AVOCADO_ALLOW_LARGE_STORAGE'), 'storage
> >>>>>>>>> limited')
> >>>>>>>>> +def test_arm_orangepi_bionic_20_08(self):
> >>>>>>>>> +"""
> >>>>>>>>> +:avocado: tags=arch:arm
> >>>>>>>>> +:avocado: tags=machine:orangepi-pc
> >>>>>>>>> +:avocado: tags=device:sd
> >>>>>>>>> +"""
> >>>>>>>>> +
> >>>>>>>>> +# This test download a 275 MiB compressed image and expand
> >>>>>>>>> it
> >>>>>>>>> +# to 1036 MiB, but the underlying filesystem is 1552 MiB...
> >>>>>>>>> +# As we expand it to 2 GiB we are safe.
> >>>>>>>>> +
> >>>>>>>>> +image_url = ('https://dl.armbian.com/orangepipc/archive/'
> >>>>>>>>> +
> >>>>>>>>> 'Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz')
> >>>>>>>>
> >>>>>>>> The Armbian 20 is not available on this link anymore. I can browse
> >>>>>>>> just 21.
> >>>>>>>
> >>>>>>> Cat-and-mouse game *sigh*.
> >>>
> >>> 2021-03-22 17:18:10,701 download L0067 INFO | Fetching
> >>> https://archive.armbian.com/orangepipc/archive/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz
> >>> -> /home/phil/avocado/da
> >>> ta/cache/by_location/f2eb27a12b81ce15e93f340fabbced2136af1caa/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz.nfwdzivg
> >>> 2021-03-22 17:18:11,263 assetL0136 INFO | Temporary asset
> >>> file unavailable due to failed download attempt.
> >>> 2021-03-22 17:18:11,263 assetL0368 ERROR| URLError: >>> error [Errno 113] No route to host>
> >>>
> >>> It might be a temporary problem, but looking long term the
> >>> current setup doesn't scale IMHO.
> >>
> >> Also I just noticed I *do* have the image cached, even twice:
> >>
> >> $ find /home/phil/avocado/data/cache/by_location/ -name
> >> Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz -ls
> >> 131661 280768 -rw-rw-r-- 1 phil phil 287501560 Oct 23
> >> 12:45
> >> /home/phil/avocado/data/cache/by_location/cac379e6a4480624b000dfde1b5d935454254ce2/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz
> >> 131761 280776 -rw-rw-r-- 1 phil phil 287501560 Feb 20
> >> 00:39
> >> /home/phil/avocado/data/cache/by_location/aac619d9e7ea3726ebc86c159fddfb9d3f6274a5/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz
> >>
> >> But the hash is different.
> >>
> >
> > You have 2 images because you fetched them from different locations.
> > When you fetch by location, the assets go to the directory
> > representing the hash of the location, This allows, for example, the
> > fetch of multiple initrd or vmlinuz files from different locations,
> > representing different files, but with the same name. Also, this was
> > one of your requests some time ago :)
>
> My request because we were fetching different artifacts for different
> tests but all files had the same filename, i.e.:
>
> url1://path1/to/vmlinux
> url2://path2/to/vmlinux
> url3://yet/anot
Re: [PATCH v3 2/5] tests/acceptance/boot_linux_console: remove Armbian 19.11.3 bionic test for orangepi-pc machine
On Mon, Mar 22, 2021 at 3:47 PM Philippe Mathieu-Daudé wrote:
>
> On 3/22/21 6:18 PM, Willian Rampazzo wrote:
> > Hi Philippe,
> >
> > On Mon, Mar 22, 2021 at 1:54 PM Philippe Mathieu-Daudé
> > wrote:
> >>
> >> Hi Willian,
> >>
> >> On 3/8/21 9:44 PM, Willian Rampazzo wrote:
> >>> On Mon, Mar 8, 2021 at 5:41 PM Willian Rampazzo
> >>> wrote:
> >>>>
> >>>> On Mon, Mar 8, 2021 at 5:32 PM Niek Linnenbank
> >>>> wrote:
> >>>>>
> >>>>> Hi Philippe, Willian,
> >>>>>
> >>>>> On Mon, Mar 8, 2021 at 8:52 AM Philippe Mathieu-Daudé
> >>>>> wrote:
> >>>>>>
> >>>>>> On 3/5/21 4:16 PM, Willian Rampazzo wrote:
> >>>>>>> On Thu, Mar 4, 2021 at 5:44 PM Niek Linnenbank
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> The image for Armbian 19.11.3 bionic has been removed from the
> >>>>>>>> armbian server.
> >>>>>>>> Without the image as input the test arm_orangepi_bionic_19_11 cannot
> >>>>>>>> run.
> >>>>>>>>
> >>>>>>>> This commit removes the test completely and merges the code of the
> >>>>>>>> generic function
> >>>>>>>> do_test_arm_orangepi_uboot_armbian back with the 20.08 test.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Niek Linnenbank
> >>>>>>>> ---
> >>>>>>>> tests/acceptance/boot_linux_console.py | 72
> >>>>>>>> --
> >>>>>>>> 1 file changed, 23 insertions(+), 49 deletions(-)
> >>>>>>>>
> >>>>>>>> diff --git a/tests/acceptance/boot_linux_console.py
> >>>>>>>> b/tests/acceptance/boot_linux_console.py
> >>>>>>>> index eb01286799..9fadea9958 100644
> >>>>>>>> --- a/tests/acceptance/boot_linux_console.py
> >>>>>>>> +++ b/tests/acceptance/boot_linux_console.py
> >>>>>>>> @@ -802,7 +802,29 @@ def test_arm_orangepi_sd(self):
> >>>>>>>> # Wait for VM to shut down gracefully
> >>>>>>>> self.vm.wait()
> >>>>>>>>
> >>>>>>>> -def do_test_arm_orangepi_uboot_armbian(self, image_path):
> >>>>>>>> +@skipUnless(os.getenv('ARMBIAN_ARTIFACTS_CACHED'),
> >>>>>>>> +'Test artifacts fetched from unreliable
> >>>>>>>> apt.armbian.com')
> >>>>>>>> +@skipUnless(os.getenv('AVOCADO_ALLOW_LARGE_STORAGE'), 'storage
> >>>>>>>> limited')
> >>>>>>>> +def test_arm_orangepi_bionic_20_08(self):
> >>>>>>>> +"""
> >>>>>>>> +:avocado: tags=arch:arm
> >>>>>>>> +:avocado: tags=machine:orangepi-pc
> >>>>>>>> +:avocado: tags=device:sd
> >>>>>>>> +"""
> >>>>>>>> +
> >>>>>>>> +# This test download a 275 MiB compressed image and expand
> >>>>>>>> it
> >>>>>>>> +# to 1036 MiB, but the underlying filesystem is 1552 MiB...
> >>>>>>>> +# As we expand it to 2 GiB we are safe.
> >>>>>>>> +
> >>>>>>>> +image_url = ('https://dl.armbian.com/orangepipc/archive/'
> >>>>>>>> +
> >>>>>>>> 'Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz')
> >>>>>>>
> >>>>>>> The Armbian 20 is not available on this link anymore. I can browse
> >>>>>>> just 21.
> >>>>>>
> >>>>>> Cat-and-mouse game *sigh*.
> >>
> >> 2021-03-22 17:18:10,701 download L0067 INFO | Fetching
> >> https://archive.armbian.com/orangepipc/archive/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz
> >> -> /home/phil/avocado/da
> >> ta/cache/by_location/f2eb27a12b81ce15e93f340fabbced2136af1caa/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz.nfwdzivg
> >> 2021-03-22 17:18:11,263 assetL0136 INFO | Temporary asset
> >> file unavailable due to failed download attempt.
> >> 2021-03-22 17:18:11,263 assetL0368 ERROR| URLError: >> error [Errno 113] No route to host>
> >>
> >> It might be a temporary problem, but looking long term the
> >> current setup doesn't scale IMHO.
> >>
> >
> > Have you changed something in the test? The test is supposed to skip
> > when the asset is not available in the cache. What was the result of
> > this test execution? Skip, fail, or error? If it was not Skip, we need
> > to investigate what happened.
>
> No change, on commit b1847509268.
>
> The result was all good but 1 "Cancelled" so I looked at the job.log.
>
> All good IMO.
>
Okay, good! Unfortunately, I don't think there is much more we can do
on the qemu side or on Avocado side to handle network glitches.
Re: 'make check-acceptance' odd error: "'bytes' object has no attribute 'encode'"
Hi Peter, On Tue, Mar 23, 2021 at 12:28 PM Peter Maydell wrote: > > I just got this running 'make check-acceptance': does it > ring a bell with anybody? > > [etc] > Fetching asset from > tests/acceptance/replay_kernel.py:ReplayKernelSlow.test_mips64el_malta_5KEc_cpio > Fetching asset from > tests/acceptance/replay_kernel.py:ReplayKernelSlow.test_mips64el_malta_5KEc_cpio > Fetching asset from > tests/acceptance/replay_kernel.py:ReplayKernelSlow.test_mips_malta32el_nanomips_4k > Fetching asset from > tests/acceptance/replay_kernel.py:ReplayKernelSlow.test_mips_malta32el_nanomips_16k_up > Fetching asset from > tests/acceptance/replay_kernel.py:ReplayKernelSlow.test_mips_malta32el_nanomips_64k_dbg > Fetching asset from > tests/acceptance/reverse_debugging.py:ReverseDebugging_AArch64.test_aarch64_virt > Fetching asset from > tests/acceptance/virtio-gpu.py:VirtioGPUx86.test_virtio_vga_virgl > Error running method "pre_tests" of plugin "fetchasset": 'bytes' > object has no attribute 'encode' The side effect of this bug is that when you run check-acceptance for the first time, it won't download this specific image before the test starts, but during the test execution. After the first run, the asset is already on cache and will not be downloaded again, working as expected. This bug is fixed here https://github.com/avocado-framework/avocado/pull/4416 and already available on release 86.0 of Avocado. It will reach the QEMU side as soon as we bump the version here. > JOB ID : 71b2d5569d9ccc8b68957d3ad2b2026bea437d66 > JOB LOG: > /home/petmay01/linaro/qemu-from-laptop/qemu/build/clang/tests/results/job-2021-03-23T15.09-71b2d55/job.log > (001/142) tests/acceptance/boot_linux.py:BootLinuxX8664.test_pc_i440fx_tcg: > PASS (465.84 s) > (002/142) tests/acceptance/boot_linux.py:BootLinuxX8664.test_pc_i440fx_kvm: > PASS (27.46 s) > (003/142) tests/acceptance/boot_linux.py:BootLinuxX8664.test_pc_q35_tcg: > PASS (99.43 s) > [etc] > > thanks > -- PMM >
Re: [PATCH v2 02/10] tests/acceptance/virtiofs_submounts.py: evaluate string not length
On Tue, Mar 23, 2021 at 7:15 PM Cleber Rosa wrote: > > If the vmlinuz variable is set to anything that evaluates to True, > then the respective arguments should be set. If the variable contains > an empty string, than it will evaluate to False, and the extra > arguments will not be set. > > This keeps the same logic, but improves readability a bit. > > Signed-off-by: Cleber Rosa > Reviewed-by: Beraldo Leal > --- > tests/acceptance/virtiofs_submounts.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Willian Rampazzo
Re: [PATCH v2 03/10] Python: add utility function for retrieving port redirection
logging.getLogger('ssh')
> res = self.vm.command('human-monitor-command',
>command_line='info usernet')
> -line = res.split('\r\n')[2]
> -port = re.split(r'.*TCP.HOST_FORWARD.*127\.0\.0\.1 (\d+)\s+10\..*',
> -line)[1]
> +port = get_info_usernet_hostfwd_port(res)
> +if not port:
> +self.cancel("Failed to retrieve SSH port")
> self.log.debug("sshd listening on port:" + port)
> -return port
> -
> -def ssh_connect(self, username, password):
> -self.ssh_logger = logging.getLogger('ssh')
> -port = self.get_portfwd()
> self.ssh_session = ssh.Session(self.VM_IP, port=int(port),
> user=username, password=password)
> for i in range(10):
> diff --git a/tests/acceptance/virtiofs_submounts.py
> b/tests/acceptance/virtiofs_submounts.py
> index ca64b76301..57a7047342 100644
> --- a/tests/acceptance/virtiofs_submounts.py
> +++ b/tests/acceptance/virtiofs_submounts.py
> @@ -9,6 +9,8 @@
> from avocado_qemu import wait_for_console_pattern
> from avocado.utils import ssh
>
> +from qemu.utils import get_info_usernet_hostfwd_port
> +
>
> def run_cmd(args):
> subp = subprocess.Popen(args,
> @@ -73,27 +75,14 @@ class VirtiofsSubmountsTest(LinuxTest):
> :avocado: tags=accel:kvm
> """
>
> -def get_portfwd(self):
> -port = None
> -
> +def ssh_connect(self, username, keyfile):
> +self.ssh_logger = logging.getLogger('ssh')
> res = self.vm.command('human-monitor-command',
>command_line='info usernet')
> -for line in res.split('\r\n'):
> -match = \
> -re.search(r'TCP.HOST_FORWARD.*127\.0\.0\.1\s+(\d+)\s+10\.',
> - line)
> -if match is not None:
> -port = int(match[1])
> -break
> -
> +port = get_info_usernet_hostfwd_port(res)
> self.assertIsNotNone(port)
> self.assertGreater(port, 0)
> self.log.debug('sshd listening on port: %d', port)
> -return port
> -
> -def ssh_connect(self, username, keyfile):
> -self.ssh_logger = logging.getLogger('ssh')
> -port = self.get_portfwd()
> self.ssh_session = ssh.Session('127.0.0.1', port=port,
> user=username, key=keyfile)
> for i in range(10):
> diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
> index 00f1d5ca8d..75ce07df36 100644
> --- a/tests/vm/basevm.py
> +++ b/tests/vm/basevm.py
> @@ -21,6 +21,7 @@
> sys.path.append(os.path.join(os.path.dirname(__file__), '..', '..',
> 'python'))
> from qemu.accel import kvm_available
> from qemu.machine import QEMUMachine
> +from qemu.utils import get_info_usernet_hostfwd_port
> import subprocess
> import hashlib
> import argparse
> @@ -306,11 +307,7 @@ def boot(self, img, extra_args=[]):
> self.console_init()
> usernet_info = guest.qmp("human-monitor-command",
> command_line="info usernet")
> -self.ssh_port = None
> -for l in usernet_info["return"].splitlines():
> -fields = l.split()
> -if "TCP[HOST_FORWARD]" in fields and "22" in fields:
> -self.ssh_port = l.split()[3]
> +self.ssh_port = get_info_usernet_hostfwd_port(usernet_info)
> if not self.ssh_port:
> raise Exception("Cannot find ssh port from 'info usernet':\n%s"
> % \
> usernet_info)
> --
> 2.25.4
>
Other than maybe a small adjustment to the
get_info_usernet_hostfwd_port function:
Reviewed-by: Willian Rampazzo
Re: [PATCH v2 05/10] Acceptance Tests: add port redirection for ssh by default
On Tue, Mar 23, 2021 at 7:16 PM Cleber Rosa wrote: > > For users of the LinuxTest class, let's set up the VM with the port > redirection for SSH, instead of requiring each test to set the same > arguments. > > Signed-off-by: Cleber Rosa > --- > tests/acceptance/avocado_qemu/__init__.py | 4 +++- > tests/acceptance/virtiofs_submounts.py| 4 > 2 files changed, 3 insertions(+), 5 deletions(-) > Reviewed-by: Willian Rampazzo
