[PATCH 00/22] testing/next: cirrus, docker, docs, ci, configs, gitlab

[PATCH 00/22] testing/next: cirrus, docker, docs, ci, configs, gitlab

[Alex Bennée]

This started as trying to un-wedge the FreeBSD 13 failure by running a
restricted build but then led down a rabbit hole of getting the
--without-default-devices build to pass. Fabiano had already been down
some of this road with ARM so I've nabbed his patches here but feel
free to cherry-pick into the arch tree if needed.

There are also patches to clean up the ansible configuration (driven
via lcitool) and prepare for upgrading the s390x runner to ubuntu
22.04.

Please review.

Alex Bennée (16):
  gitlab/cirrus: reduce scope of the FreeBSD testing matrix
  tests/docker: bump the xtensa base to debian:11-slim
  docs: document breakpoint and watchpoint support
  scripts/ci: add gitlab-runner to kvm group
  hw/alpha: make E1000_PCI a hard dependency for clipper
  hw/hppa: add TULIP as a dependency for HPPA_B160L
  hw/sparc: add a TCX dependency for SUN4M machines
  hw/loongarch: add VIRTIO as a dependency for LOONGARCH_VIRT
  hw/sh4: make RTL8139 a hard dependency for RD2
  hw/mips: add VIRTIO and USB dependencies for LOONGSON3V
  hw/xtensa: add VIRTIO as dependencies for XTENSA_VIRT
  scripts/ci: clean-up the 20.04/22.04 confusion in ansible
  gitlab: add ubuntu-22.04-aarch64-without-defaults
  gitlab: enable minimal device profoile for aarch64 --disable-tcg
  tests/avocado: use http for mipsdistros.mips.com
  tests/qtest: skip bcm2835-test if no raspi3b model

Fabiano Rosas (6):
  hw/arm: Select VIRTIO_NET for virt machine
  hw/arm: Select VIRTIO_BLK for virt machine
  hw/arm: Select XLNX_USB_SUBSYS for xlnx-zcu102 machine
  hw/arm: Select GICV3_TCG for sbsa-ref machine
  hw/arm: Select e1000e for sbsa-ref machine
  hw/arm: Select VGA_PCI for sbsa-ref machine

 docs/system/gdb.rst                           |  22 ++++
 tests/qtest/bcm2835-dma-test.c                |  11 +-
 .gitlab-ci.d/cirrus.yml                       |   1 +
 .../custom-runners/ubuntu-22.04-aarch32.yml   |   2 +-
 .../custom-runners/ubuntu-22.04-aarch64.yml   |  28 ++++-
 hw/alpha/Kconfig                              |   2 +-
 hw/arm/Kconfig                                |   7 ++
 hw/hppa/Kconfig                               |   1 +
 hw/loongarch/Kconfig                          |   2 +
 hw/mips/Kconfig                               |   3 +
 hw/sh4/Kconfig                                |   2 +-
 hw/sparc/Kconfig                              |   1 +
 hw/usb/Kconfig                                |   1 -
 hw/xtensa/Kconfig                             |   2 +
 scripts/ci/setup/build-environment.yml        | 111 ++++++++++++------
 scripts/ci/setup/gitlab-runner.yml            |   1 +
 tests/avocado/replay_kernel.py                |   6 +-
 .../dockerfiles/debian-xtensa-cross.docker    |   2 +-
 18 files changed, 154 insertions(+), 51 deletions(-)

-- 
2.39.2

[PATCH 01/22] gitlab/cirrus: reduce scope of the FreeBSD testing matrix

[Alex Bennée]

While the Cirrus build machines are quite beefy it looks like we are
still hitting timeouts. Lets reduce the testing matrix like we do for
the other BSDs to see if this brings us under the line. This is
however a pretty restricted set and I'm sure there are stalls
happening on FreeBSD which should be addresses.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Cc: Ed Maste <emaste@freebsd.org>
Cc: Li-Wen Hsu <lwhsu@freebsd.org>
---
 .gitlab-ci.d/cirrus.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
index 1507c928e5..7c93db4962 100644
--- a/.gitlab-ci.d/cirrus.yml
+++ b/.gitlab-ci.d/cirrus.yml
@@ -55,6 +55,7 @@ x64-freebsd-13-build:
     CIRRUS_VM_RAM: 8G
     UPDATE_COMMAND: pkg update; pkg upgrade -y
     INSTALL_COMMAND: pkg install -y
+    CONFIGURE_ARGS: --target-list=x86_64-softmmu,arm-bsd-user
     TEST_TARGETS: check
 
 aarch64-macos-12-base-build:
-- 
2.39.2

Re: [PATCH 01/22] gitlab/cirrus: reduce scope of the FreeBSD testing matrix

[Thomas Huth]

On 03/05/2023 11.12, Alex Bennée wrote:
> While the Cirrus build machines are quite beefy it looks like we are
> still hitting timeouts. Lets reduce the testing matrix like we do for
> the other BSDs to see if this brings us under the line. This is
> however a pretty restricted set and I'm sure there are stalls
> happening on FreeBSD which should be addresses.

My fix/workaround for the hanging FreeBSD job has been merged yesterday:

  https://gitlab.com/qemu-project/qemu/-/commit/01013d2c10a07bb49d

It seems like the test now finishes again in 23 minutes:

  https://cirrus-ci.com/task/5409701572116480

... so I hope you can drop this patch here now from your queue.

  Thomas

[PATCH 02/22] tests/docker: bump the xtensa base to debian:11-slim

[Alex Bennée]

Stretch is going out of support so things like security updates will
fail. As the toolchain itself is binary it hopefully won't mind the
underlying OS being updated.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reported-by: Richard Henderson <richard.henderson@linaro.org>
---
 tests/docker/dockerfiles/debian-xtensa-cross.docker | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/docker/dockerfiles/debian-xtensa-cross.docker b/tests/docker/dockerfiles/debian-xtensa-cross.docker
index 082b50da19..72c25d63d9 100644
--- a/tests/docker/dockerfiles/debian-xtensa-cross.docker
+++ b/tests/docker/dockerfiles/debian-xtensa-cross.docker
@@ -5,7 +5,7 @@
 # using a prebuilt toolchains for Xtensa cores from:
 # https://github.com/foss-xtensa/toolchain/releases
 #
-FROM docker.io/library/debian:stretch-slim
+FROM docker.io/library/debian:11-slim
 
 RUN apt-get update && \
     DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata && \
-- 
2.39.2

Re: [PATCH 02/22] tests/docker: bump the xtensa base to debian:11-slim

[Thomas Huth]

On 03/05/2023 11.12, Alex Bennée wrote:
> Stretch is going out of support so things like security updates will
> fail. As the toolchain itself is binary it hopefully won't mind the
> underlying OS being updated.

Let's hope there won't be any problems with dynamic libraries...

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH 02/22] tests/docker: bump the xtensa base to debian:11-slim

[Juan Quintela]

Alex Bennée <alex.bennee@linaro.org> wrote:
> Stretch is going out of support so things like security updates will
> fail. As the toolchain itself is binary it hopefully won't mind the
> underlying OS being updated.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Reported-by: Richard Henderson <richard.henderson@linaro.org>

Reviewed-by: Juan Quintela <quintela@redhat.com>

[PATCH 03/22] docs: document breakpoint and watchpoint support

[Alex Bennée]

This varies by accelerator. Also mention the modern bear trap that is
ASLR.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 docs/system/gdb.rst | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/docs/system/gdb.rst b/docs/system/gdb.rst
index 453eb73f6c..7d3718deef 100644
--- a/docs/system/gdb.rst
+++ b/docs/system/gdb.rst
@@ -46,6 +46,28 @@ Here are some useful tips in order to use gdb on system code:
 3. Use ``set architecture i8086`` to dump 16 bit code. Then use
    ``x/10i $cs*16+$eip`` to dump the code at the PC position.
 
+Breakpoint and Watchpoint support
+=================================
+
+While GDB can always fall back to inserting breakpoints into memory
+(if writable) other features are very much dependent on support of the
+accelerator. For TCG system emulation we advertise an infinite number
+of hardware assisted breakpoints and watchpoints. For other
+accelerators it will depend on if support has been added (see
+supports_guest_debug and related hooks in AccelOpsClass).
+
+As TCG cannot track all memory accesses in user-mode there is no
+support for watchpoints.
+
+Relocating code
+---------------
+
+On modern kernels confusion can be caused by code being relocated by
+features such as address space layout randomisation. To avoid
+confusion when debugging such things you either need to update gdb's
+view of where things are in memory or perhaps more trivially disable
+ASLR when booting the system.
+
 Debugging multicore machines
 ============================
 
-- 
2.39.2

Re: [PATCH 03/22] docs: document breakpoint and watchpoint support

[Juan Quintela]

Alex Bennée <alex.bennee@linaro.org> wrote:
> This varies by accelerator. Also mention the modern bear trap that is
> ASLR.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

Reviewed-by: Juan Quintela <quintela@redhat.com>

> +Relocating code
> +---------------
> +
> +On modern kernels confusion can be caused by code being relocated by
> +features such as address space layout randomisation. To avoid
> +confusion when debugging such things you either need to update gdb's
> +view of where things are in memory or perhaps more trivially disable
> +ASLR when booting the system.

Makes sense for everything except debugging ASLR O:-)

[PATCH 04/22] scripts/ci: add gitlab-runner to kvm group

[Alex Bennée]

One of the main reasons to have custom runners it so we can run KVM
tests. Enable the "kvm" additional group so we can access the feature
on the kernel.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
---
 scripts/ci/setup/gitlab-runner.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/ci/setup/gitlab-runner.yml b/scripts/ci/setup/gitlab-runner.yml
index 1a1b270ff2..7bdafab511 100644
--- a/scripts/ci/setup/gitlab-runner.yml
+++ b/scripts/ci/setup/gitlab-runner.yml
@@ -26,6 +26,7 @@
       user:
         user: gitlab-runner
         group: gitlab-runner
+        groups: kvm
         comment: GitLab Runner
         home: /home/gitlab-runner
         shell: /bin/bash
-- 
2.39.2

Re: [PATCH 04/22] scripts/ci: add gitlab-runner to kvm group

[Thomas Huth]

On 03/05/2023 11.12, Alex Bennée wrote:
> One of the main reasons to have custom runners it so we can run KVM
> tests. Enable the "kvm" additional group so we can access the feature
> on the kernel.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Reported-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>   scripts/ci/setup/gitlab-runner.yml | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/scripts/ci/setup/gitlab-runner.yml b/scripts/ci/setup/gitlab-runner.yml
> index 1a1b270ff2..7bdafab511 100644
> --- a/scripts/ci/setup/gitlab-runner.yml
> +++ b/scripts/ci/setup/gitlab-runner.yml
> @@ -26,6 +26,7 @@
>         user:
>           user: gitlab-runner
>           group: gitlab-runner
> +        groups: kvm
>           comment: GitLab Runner
>           home: /home/gitlab-runner
>           shell: /bin/bash

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH 04/22] scripts/ci: add gitlab-runner to kvm group

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> One of the main reasons to have custom runners it so we can run KVM
> tests. Enable the "kvm" additional group so we can access the feature
> on the kernel.
> 
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> Reported-by: Peter Maydell<peter.maydell@linaro.org>
> ---
>   scripts/ci/setup/gitlab-runner.yml | 1 +
>   1 file changed, 1 insertion(+)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

[PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Alex Bennée]

From: Fabiano Rosas <farosas@suse.de>

The 'virt' machine uses virtio-net-pci as a fallback when no other
network driver has been selected via command line. Select VIRTIO_NET
and VIRTIO_PCI from CONFIG_ARM_VIRT to avoid errors when PCI_DEVICES=n
(due to e.g. --without-default-devices):

$ ./qemu-system-aarch64 -M virt -accel tcg -cpu max
qemu-system-aarch64: Unsupported NIC model: virtio-net-pci

Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20230208192654.8854-6-farosas@suse.de>
---
 hw/arm/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 2d7c457955..4c23fbf800 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -32,6 +32,8 @@ config ARM_VIRT
     select VIRTIO_MEM_SUPPORTED
     select ACPI_CXL
     select ACPI_HMAT
+    select VIRTIO_PCI
+    select VIRTIO_NET
 
 config CHEETAH
     bool
-- 
2.39.2

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> From: Fabiano Rosas<farosas@suse.de>
> 
> The 'virt' machine uses virtio-net-pci as a fallback when no other
> network driver has been selected via command line. Select VIRTIO_NET
> and VIRTIO_PCI from CONFIG_ARM_VIRT to avoid errors when PCI_DEVICES=n
> (due to e.g. --without-default-devices):
> 
> $ ./qemu-system-aarch64 -M virt -accel tcg -cpu max
> qemu-system-aarch64: Unsupported NIC model: virtio-net-pci
> 
> Reviewed-by: Thomas Huth<thuth@redhat.com>
> Signed-off-by: Fabiano Rosas<farosas@suse.de>
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> Message-Id:<20230208192654.8854-6-farosas@suse.de>
> ---
>   hw/arm/Kconfig | 2 ++
>   1 file changed, 2 insertions(+)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Paolo Bonzini]

On 5/3/23 11:12, Alex Bennée wrote:
> From: Fabiano Rosas <farosas@suse.de>
> 
> The 'virt' machine uses virtio-net-pci as a fallback when no other
> network driver has been selected via command line. Select VIRTIO_NET
> and VIRTIO_PCI from CONFIG_ARM_VIRT to avoid errors when PCI_DEVICES=n
> (due to e.g. --without-default-devices):
> 
> $ ./qemu-system-aarch64 -M virt -accel tcg -cpu max
> qemu-system-aarch64: Unsupported NIC model: virtio-net-pci

With respect to patches 5-17, very few devices need to be present when 
configuring --without-default-devices, and thus need to be "select"ed by 
Kconfig.  You should select a device only if you cannot even start the 
machine without --nodefaults.

Anything else should be added by hand to configs/ if you use 
--nodefaults.  In particular, failures of "make check" when configured 
--without-default-devices are *test* bugs, not configuration bugs.

I didn't check if _all_ of the patches in this set should be dropped, 
but most probably do.

Paolo

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Fabiano Rosas]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 5/3/23 11:12, Alex Bennée wrote:
>> From: Fabiano Rosas <farosas@suse.de>
>> 
>> The 'virt' machine uses virtio-net-pci as a fallback when no other
>> network driver has been selected via command line. Select VIRTIO_NET
>> and VIRTIO_PCI from CONFIG_ARM_VIRT to avoid errors when PCI_DEVICES=n
>> (due to e.g. --without-default-devices):
>> 
>> $ ./qemu-system-aarch64 -M virt -accel tcg -cpu max
>> qemu-system-aarch64: Unsupported NIC model: virtio-net-pci
>
> With respect to patches 5-17, very few devices need to be present when 
> configuring --without-default-devices, and thus need to be "select"ed by 
> Kconfig.  You should select a device only if you cannot even start the 
> machine without --nodefaults.
>

There are some devices that are not explicitly under the scope of
-nodefaults, i.e. they are not part of the "default" logic at vl.c, but
still some code deep within QEMU uses them as fallback in some
situations.

> Anything else should be added by hand to configs/ if you use 
> --nodefaults.  In particular, failures of "make check" when configured 
> --without-default-devices are *test* bugs, not configuration bugs.
>

Yes, that makes sense, just keep in mind that this have lead to us not
testing the --without-default-devices build and people just assuming
some devices will always be present. So there's genuine scenarios of us
providing a CONFIG that can never be turned off because everything
breaks.

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Alex Bennée]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 5/3/23 11:12, Alex Bennée wrote:
>> From: Fabiano Rosas <farosas@suse.de>
>> The 'virt' machine uses virtio-net-pci as a fallback when no other
>> network driver has been selected via command line. Select VIRTIO_NET
>> and VIRTIO_PCI from CONFIG_ARM_VIRT to avoid errors when PCI_DEVICES=n
>> (due to e.g. --without-default-devices):
>> $ ./qemu-system-aarch64 -M virt -accel tcg -cpu max
>> qemu-system-aarch64: Unsupported NIC model: virtio-net-pci
>
> With respect to patches 5-17, very few devices need to be present when
> configuring --without-default-devices, and thus need to be "select"ed
> by Kconfig.  You should select a device only if you cannot even start
> the machine without --nodefaults.

Which is the case here right? We could skip tests that explicitly
instantiate a device but these are tests failing with default devices
the machine tries to instantiate.

> Anything else should be added by hand to configs/ if you use
> --nodefaults.  In particular, failures of "make check" when configured
> --without-default-devices are *test* bugs, not configuration bugs.
>
> I didn't check if _all_ of the patches in this set should be dropped,
> but most probably do.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Paolo Bonzini]

On 5/3/23 17:35, Alex Bennée wrote:
>> You should select a device only if you cannot even start
>> the machine without --nodefaults.
>
> Which is the case here right? We could skip tests that explicitly
> instantiate a device but these are tests failing with default devices
> the machine tries to instantiate.

I'm sorry, I meant "select" directives are needed if you cannot even 
start the machine *with* --nodefaults.

Devices that are added *without* --nodefaults should use "imply" 
directives instead, as is already the case.

Paolo

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Peter Maydell]

On Wed, 3 May 2023 at 18:06, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 5/3/23 17:35, Alex Bennée wrote:
> >> You should select a device only if you cannot even start
> >> the machine without --nodefaults.
> >
> > Which is the case here right? We could skip tests that explicitly
> > instantiate a device but these are tests failing with default devices
> > the machine tries to instantiate.
>
> I'm sorry, I meant "select" directives are needed if you cannot even
> start the machine *with* --nodefaults.
>
> Devices that are added *without* --nodefaults should use "imply"
> directives instead, as is already the case.

Do we really want to build a QEMU that then barfs unless
you pass -nodefaults, though ? That doesn't seem very useful.
Something somewhere ought to be saying "if you want the
virt board then you almost certainly want these". Or
alternatively we should fall back to "don't create a
network device we don't have", maybe ?

-- PMM

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Thomas Huth]

On 03/05/2023 20.32, Peter Maydell wrote:
> On Wed, 3 May 2023 at 18:06, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> On 5/3/23 17:35, Alex Bennée wrote:
>>>> You should select a device only if you cannot even start
>>>> the machine without --nodefaults.
>>>
>>> Which is the case here right? We could skip tests that explicitly
>>> instantiate a device but these are tests failing with default devices
>>> the machine tries to instantiate.
>>
>> I'm sorry, I meant "select" directives are needed if you cannot even
>> start the machine *with* --nodefaults.
>>
>> Devices that are added *without* --nodefaults should use "imply"
>> directives instead, as is already the case.
> 
> Do we really want to build a QEMU that then barfs unless
> you pass -nodefaults, though ? That doesn't seem very useful.
> Something somewhere ought to be saying "if you want the
> virt board then you almost certainly want these". Or
> alternatively we should fall back to "don't create a
> network device we don't have", maybe ?

I think we should do the latter. If you compiled without certain devices 
that are used only in the default mode, the board should not try to 
instantiate such devices (since it is also working fine without them). Just 
my 0.02 €.

  Thomas

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Alex Bennée]

Thomas Huth <thuth@redhat.com> writes:

> On 03/05/2023 20.32, Peter Maydell wrote:
>> On Wed, 3 May 2023 at 18:06, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>
>>> On 5/3/23 17:35, Alex Bennée wrote:
>>>>> You should select a device only if you cannot even start
>>>>> the machine without --nodefaults.
>>>>
>>>> Which is the case here right? We could skip tests that explicitly
>>>> instantiate a device but these are tests failing with default devices
>>>> the machine tries to instantiate.
>>>
>>> I'm sorry, I meant "select" directives are needed if you cannot even
>>> start the machine *with* --nodefaults.
>>>
>>> Devices that are added *without* --nodefaults should use "imply"
>>> directives instead, as is already the case.
>> Do we really want to build a QEMU that then barfs unless
>> you pass -nodefaults, though ? That doesn't seem very useful.
>> Something somewhere ought to be saying "if you want the
>> virt board then you almost certainly want these". Or
>> alternatively we should fall back to "don't create a
>> network device we don't have", maybe ?
>
> I think we should do the latter. If you compiled without certain
> devices that are used only in the default mode, the board should not
> try to instantiate such devices (since it is also working fine without
> them). Just my 0.02 €.

So I hand hacked qtest_spawn_qemu with:

    va_start(ap, fmt);
    g_string_append_printf(command, CMD_EXEC "%s %s -nodefaults ",qtest_qemu_binary(), tracearg);
    g_string_append_vprintf(command, fmt, ap);
    va_end(ap);                           

And the following tests fail on the --no-default-devices
--no-default-features build:

  18/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/qom-test                             ERROR          51.23s   killed by signal 6 SIGABRT                                         
   37/436 qemu:qtest+qtest-aarch64 / qtest-aarch64/bios-tables-test                 ERROR           0.20s   killed by signal 6 SIGABRT                                         
   55/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/test-hmp                             ERROR          50.24s   killed by signal 6 SIGABRT                                         
   94/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/qos-test                             ERROR          50.19s   killed by signal 6 SIGABRT                                         
  103/436 qemu:qtest+qtest-sparc64 / qtest-sparc64/prom-env-test                    ERROR          608.02s   killed by signal 6 SIGABRT                                        
  115/436 qemu:qtest+qtest-aarch64 / qtest-aarch64/cdrom-test                       ERROR           0.31s   killed by signal 6 SIGABRT                                         
  122/436 qemu:qtest+qtest-alpha / qtest-alpha/test-filter-mirror                   ERROR           0.16s   killed by signal 6 SIGABRT                                         
  123/436 qemu:qtest+qtest-alpha / qtest-alpha/test-filter-redirector               ERROR           0.16s   killed by signal 6 SIGABRT                                         
  132/436 qemu:qtest+qtest-arm / qtest-arm/pflash-cfi02-test                        ERROR          50.28s   killed by signal 6 SIGABRT                                         
  134/436 qemu:qtest+qtest-arm / qtest-arm/microbit-test                            ERROR          51.02s   killed by signal 6 SIGABRT                                         
  135/436 qemu:qtest+qtest-arm / qtest-arm/test-arm-mptimer                         ERROR          51.20s   killed by signal 6 SIGABRT                                         
  136/436 qemu:qtest+qtest-arm / qtest-arm/cdrom-test                               ERROR           0.31s   killed by signal 6 SIGABRT                                         
  157/436 qemu:qtest+qtest-hppa / qtest-hppa/test-filter-mirror                     ERROR           0.16s   killed by signal 6 SIGABRT                                         
  158/436 qemu:qtest+qtest-hppa / qtest-hppa/test-filter-redirector                 ERROR           0.26s   killed by signal 6 SIGABRT                                         
  167/436 qemu:qtest+qtest-i386 / qtest-i386/test-filter-mirror                     ERROR           0.17s   killed by signal 6 SIGABRT                                         
  168/436 qemu:qtest+qtest-i386 / qtest-i386/test-filter-redirector                 ERROR           0.17s   killed by signal 6 SIGABRT
  169/436 qemu:qtest+qtest-i386 / qtest-i386/ipmi-bt-test                           ERROR           0.17s   killed by signal 6 SIGABRT
  171/436 qemu:qtest+qtest-i386 / qtest-i386/usb-hcd-uhci-test                      ERROR           0.17s   killed by signal 6 SIGABRT
  172/436 qemu:qtest+qtest-i386 / qtest-i386/usb-hcd-ehci-test                      ERROR           0.17s   killed by signal 6 SIGABRT
  173/436 qemu:qtest+qtest-i386 / qtest-i386/rtl8139-test                           ERROR           0.17s   killed by signal 6 SIGABRT
  192/436 qemu:qtest+qtest-i386 / qtest-i386/cdrom-test                             ERROR           0.65s   killed by signal 6 SIGABRT
  197/436 qemu:qtest+qtest-i386 / qtest-i386/readconfig-test                        ERROR           0.41s   killed by signal 6 SIGABRT
  287/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/test-filter-mirror                   ERROR          51.44s   killed by signal 6 SIGABRT
  288/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/test-filter-redirector               ERROR          51.20s   killed by signal 6 SIGABRT
  289/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/m48t59-test                          ERROR          51.20s   killed by signal 6 SIGABRT
  290/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/boot-order-test                      ERROR          51.19s   killed by signal 6 SIGABRT
  291/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/device-plug-test                     ERROR          51.20s   killed by signal 6 SIGABRT
  292/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/pnv-xscom-test                       ERROR          51.20s   killed by signal 6 SIGABRT
  293/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/rtas-test                            ERROR          51.20s   killed by signal 6 SIGABRT
  294/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/usb-hcd-uhci-test                    ERROR          51.20s   killed by signal 6 SIGABRT
  295/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/display-vga-test                     ERROR          51.21s   killed by signal 6 SIGABRT
  296/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/numa-test                            ERROR          51.19s   killed by signal 6 SIGABRT
  297/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/cpu-plug-test                        ERROR          51.20s   killed by signal 6 SIGABRT
  298/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/drive_del-test                       ERROR          51.20s   killed by signal 6 SIGABRT
  299/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/cdrom-test                           ERROR          51.20s   killed by signal 6 SIGABRT
  300/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/device-introspect-test               ERROR          51.20s   killed by signal 6 SIGABRT
  301/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/machine-none-test                    ERROR          51.20s   killed by signal 6 SIGABRT
  302/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/qmp-test                             ERROR          51.20s   killed by signal 6 SIGABRT
  303/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/qmp-cmd-test                         ERROR          51.19s   killed by signal 6 SIGABRT
  304/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/readconfig-test                      ERROR          51.20s   killed by signal 6 SIGABRT
  305/436 qemu:qtest+qtest-ppc64 / qtest-ppc64/netdev-socket                        ERROR          51.20s   killed by signal 6 SIGABRT
  306/436 qemu:qtest+qtest-ppc / qtest-ppc/test-filter-mirror                       ERROR           0.17s   killed by signal 6 SIGABRT
  307/436 qemu:qtest+qtest-ppc / qtest-ppc/test-filter-redirector
   ERROR           0.17s   killed by signal 6 SIGABRT
   338/436 qemu:qtest+qtest-s390x / qtest-s390x/test-filter-mirror                   ERROR           0.32s   killed by signal 6 SIGABRT
  339/436 qemu:qtest+qtest-s390x / qtest-s390x/test-filter-redirector               ERROR           0.43s   killed by signal 6 SIGABRT
  341/436 qemu:qtest+qtest-s390x / qtest-s390x/device-plug-test                     ERROR           0.28s   killed by signal 6 SIGABRT
  342/436 qemu:qtest+qtest-s390x / qtest-s390x/virtio-ccw-test                      ERROR           0.16s   killed by signal 6 SIGABRT
  344/436 qemu:qtest+qtest-s390x / qtest-s390x/cdrom-test                           ERROR           0.30s   killed by signal 6 SIGABRT
  365/436 qemu:qtest+qtest-sparc64 / qtest-sparc64/test-filter-mirror               ERROR           0.33s   killed by signal 6 SIGABRT
  366/436 qemu:qtest+qtest-sparc64 / qtest-sparc64/test-filter-redirector           ERROR           0.32s   killed by signal 6 SIGABRT
  391/436 qemu:qtest+qtest-x86_64 / qtest-x86_64/test-filter-mirror                 ERROR           0.16s   killed by signal 6 SIGABRT
  392/436 qemu:qtest+qtest-x86_64 / qtest-x86_64/test-filter-redirector             ERROR           0.17s   killed by signal 6 SIGABRT
  393/436 qemu:qtest+qtest-x86_64 / qtest-x86_64/ipmi-bt-test                       ERROR           0.17s   killed by signal 6 SIGABRT
  395/436 qemu:qtest+qtest-x86_64 / qtest-x86_64/usb-hcd-uhci-test                  ERROR           0.18s   killed by signal 6 SIGABRT
  396/436 qemu:qtest+qtest-x86_64 / qtest-x86_64/usb-hcd-ehci-test                  ERROR           0.16s   killed by signal 6 SIGABRT
  397/436 qemu:qtest+qtest-x86_64 / qtest-x86_64/rtl8139-test                       ERROR           0.17s   killed by signal 6 SIGABRT
  416/436 qemu:qtest+qtest-x86_64 / qtest-x86_64/cdrom-test                         ERROR           0.66s   killed by signal 6 SIGABRT
  421/436 qemu:qtest+qtest-x86_64 / qtest-x86_64/readconfig-test                    ERROR           0.40s   killed by signal 6 SIGABRT

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Paolo Bonzini]

On 5/3/23 20:32, Peter Maydell wrote:
> Do we really want to build a QEMU that then barfs unless
> you pass -nodefaults, though ? That doesn't seem very useful.
> Something somewhere ought to be saying "if you want the
> virt board then you almost certainly want these".

Well, the point is that --without-default-devices is intended to be for 
people that write their device config by hand.

However, perhaps we can add to configs/devices/ enough lines that a 
--without-default-devices configuration is moderately useful.  For 
example, some of the changes in this series could be rewritten as:

diff --git a/configs/devices/aarch64-softmmu/default.mak 
b/configs/devices/aarch64-softmmu/default.mak
index cf43ac8da116..3aaca2770590 100644
--- a/configs/devices/aarch64-softmmu/default.mak
+++ b/configs/devices/aarch64-softmmu/default.mak
@@ -3,6 +3,20 @@
  # We support all the 32 bit boards so need all their config
  include ../arm-softmmu/default.mak

+# ------
+# Boards
+# ------
+
  CONFIG_XLNX_ZYNQMP_ARM=y
  CONFIG_XLNX_VERSAL=y
  CONFIG_SBSA_REF=y
+
+# ---------------------------------------------------------------------
+# Sample configuration for a --without-default-devices build.  These
+# devices already default to enabled; they are listed here so that
+# building without default devices 1) still results in a somewhat
+# useful emulator 2) does not fail "make check".
+# ---------------------------------------------------------------------
+
+# For CONFIG_SBSA_REF:
+CONFIG_VIRTIO_NET=y
diff --git a/configs/devices/arm-softmmu/default.mak 
b/configs/devices/arm-softmmu/default.mak
index 1b49a7830c7e..81057d146d1b 100644
--- a/configs/devices/arm-softmmu/default.mak
+++ b/configs/devices/arm-softmmu/default.mak
@@ -3,6 +3,10 @@
  # CONFIG_PCI_DEVICES=n
  # CONFIG_TEST_DEVICES=n

+# ------
+# Boards
+# ------
+
  CONFIG_ARM_VIRT=y
  CONFIG_CUBIEBOARD=y
  CONFIG_EXYNOS4=y
@@ -43,3 +47,13 @@ CONFIG_FSL_IMX6UL=y
  CONFIG_SEMIHOSTING=y
  CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
  CONFIG_ALLWINNER_H3=y
+
+# ---------------------------------------------------------------------
+# Sample configuration for a --without-default-devices build.  These
+# devices already default to enabled; they are listed here so that
+# building without default devices 1) still results in a somewhat
+# useful emulator 2) does not fail "make check".
+# ---------------------------------------------------------------------
+
+# For CONFIG_ARM_VIRT:
+CONFIG_VIRTIO_NET=y


And then we can progressively work towards removing "2) does not fail 
make check".

Paolo

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Fabiano Rosas]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 5/3/23 20:32, Peter Maydell wrote:
>> Do we really want to build a QEMU that then barfs unless
>> you pass -nodefaults, though ? That doesn't seem very useful.
>> Something somewhere ought to be saying "if you want the
>> virt board then you almost certainly want these".
>
> Well, the point is that --without-default-devices is intended to be for 
> people that write their device config by hand.
>

It's a bit hard to maintain the original intention with just
documentation. Couldn't we require that --without-default-devices always
be accompanied by --with-devices? And more to the point of Peter's
question, couldn't we just leave the defaults off unconditionally when
--without-default-devices is passed without --with-devices?

The coupling of -nodefaults with --without-default-devices is a bit
redundant. If we're choosing to not build some devices, then the QEMU
binary should already know that.

Just to be clear, -nodefaults by itself still makes sense because we can
have a simple command line for those using QEMU directly while allowing
the management layer to fine tune the devices.

In the long run, I think we need to add some configure option that gives
us pure allnoconfig so we can have that in the CI and catch these CONFIG
issues before merging. There's no reason to merge a new CONFIG if it
will then be impossible to turn it off.

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Paolo Bonzini]

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

Il gio 4 mag 2023, 14:56 Fabiano Rosas <farosas@suse.de> ha scritto:

>
> It's a bit hard to maintain the original intention with just
> documentation. Couldn't we require that --without-default-devices always
> be accompanied by --with-devices?


Maybe, but why would it be bad to just patch the default .mak file?

And more to the point of Peter's
> question, couldn't we just leave the defaults off unconditionally when
> --without-default-devices is passed without --with-devices?
>

No, for example RHEL adds a lot of devices and is perfectly usable without
--nodefaults, but we still use --without-default-devices because we want
any new config to be opt in, unless it's always needed.

The coupling of -nodefaults with --without-default-devices is a bit
> redundant. If we're choosing to not build some devices, then the QEMU
> binary should already know that.
>

--without-default-devices is not about choosing to not build some devices;
it is about making non-selected devices opt-in rather than opt-out.

Paolo


> Just to be clear, -nodefaults by itself still makes sense because we can
> have a simple command line for those using QEMU directly while allowing
> the management layer to fine tune the devices.
>
> In the long run, I think we need to add some configure option that gives
> us pure allnoconfig so we can have that in the CI and catch these CONFIG
> issues before merging. There's no reason to merge a new CONFIG if it
> will then be impossible to turn it off.
>
>

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

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Peter Maydell]

On Mon, 8 May 2023 at 23:24, Paolo Bonzini <pbonzini@redhat.com> wrote:
> --without-default-devices is not about choosing to not build
> some devices; it is about making non-selected devices opt-in
> rather than opt-out.

Hmm, so it's basically "the person doing the configuration needs
to know what they're doing, the Kconfig system will give them
no hints about what devices might or might not be needed to
make machine type M functional" ?

-- PMM

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Paolo Bonzini]

On 5/9/23 11:27, Peter Maydell wrote:
> On Mon, 8 May 2023 at 23:24, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> --without-default-devices is not about choosing to not build
>> some devices; it is about making non-selected devices opt-in
>> rather than opt-out.
> 
> Hmm, so it's basically "the person doing the configuration needs
> to know what they're doing, the Kconfig system will give them
> no hints about what devices might or might not be needed to
> make machine type M functional" ?

It depends on what you mean by functional.  I would say you do get what 
is needed to have a functional machine, but not what is needed to have a 
useful machine.

But typically the latter is the easier of the two, because you should 
have an idea of what -devices are useful *to you*.

Paolo

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Peter Maydell]

On Tue, 9 May 2023 at 10:42, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 5/9/23 11:27, Peter Maydell wrote:
> > On Mon, 8 May 2023 at 23:24, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >> --without-default-devices is not about choosing to not build
> >> some devices; it is about making non-selected devices opt-in
> >> rather than opt-out.
> >
> > Hmm, so it's basically "the person doing the configuration needs
> > to know what they're doing, the Kconfig system will give them
> > no hints about what devices might or might not be needed to
> > make machine type M functional" ?
>
> It depends on what you mean by functional.  I would say you do get what
> is needed to have a functional machine, but not what is needed to have a
> useful machine.

If you need to pass '-nodefaults' to get the thing to start up at
all, that seems to be stretching the definition of "functional"
to me.

thanks
-- PMM

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Paolo Bonzini]

On 5/9/23 12:00, Peter Maydell wrote:
> On Tue, 9 May 2023 at 10:42, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> On 5/9/23 11:27, Peter Maydell wrote:
>>> On Mon, 8 May 2023 at 23:24, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>> --without-default-devices is not about choosing to not build
>>>> some devices; it is about making non-selected devices opt-in
>>>> rather than opt-out.
>>>
>>> Hmm, so it's basically "the person doing the configuration needs
>>> to know what they're doing, the Kconfig system will give them
>>> no hints about what devices might or might not be needed to
>>> make machine type M functional" ?
>>
>> It depends on what you mean by functional.  I would say you do get what
>> is needed to have a functional machine, but not what is needed to have a
>> useful machine.
> 
> If you need to pass '-nodefaults' to get the thing to start up at
> all, that seems to be stretching the definition of "functional"
> to me.

Then, an accurate description that uses "functional" in that sense could 
be as follows:

The Kconfig system will include any devices and subsystems that are 
mandatory for a given machine type, and will flag any configuration 
conflicts. However, the person doing the configuration still needs to 
know which devices are needed (on top of the mandatory ones) to obtain a 
functional guest, and Kconfig will not provide any hints in this respect.

Paolo

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Alex Bennée]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 5/9/23 12:00, Peter Maydell wrote:
>> On Tue, 9 May 2023 at 10:42, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>
>>> On 5/9/23 11:27, Peter Maydell wrote:
>>>> On Mon, 8 May 2023 at 23:24, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>>> --without-default-devices is not about choosing to not build
>>>>> some devices; it is about making non-selected devices opt-in
>>>>> rather than opt-out.
>>>>
>>>> Hmm, so it's basically "the person doing the configuration needs
>>>> to know what they're doing, the Kconfig system will give them
>>>> no hints about what devices might or might not be needed to
>>>> make machine type M functional" ?
>>>
>>> It depends on what you mean by functional.  I would say you do get what
>>> is needed to have a functional machine, but not what is needed to have a
>>> useful machine.
>> If you need to pass '-nodefaults' to get the thing to start up at
>> all, that seems to be stretching the definition of "functional"
>> to me.
>
> Then, an accurate description that uses "functional" in that sense
> could be as follows:
>
> The Kconfig system will include any devices and subsystems that are
> mandatory for a given machine type, and will flag any configuration
> conflicts. However, the person doing the configuration still needs to
> know which devices are needed (on top of the mandatory ones) to obtain
> a functional guest, and Kconfig will not provide any hints in this
> respect.

So I thought that was the model I was following in adding devices but it
seems I don't understand the no-defaults behaviour. What is the
difference between a device that is added in the machine.c that makes it
required or expendable with -nodefaults?

>
> Paolo


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH 05/22] hw/arm: Select VIRTIO_NET for virt machine

[Paolo Bonzini]

On 5/9/23 13:37, Alex Bennée wrote:
>> Then, an accurate description that uses "functional" in that sense
>> could be as follows:
>>
>> The Kconfig system will include any devices and subsystems that are
>> mandatory for a given machine type, and will flag any configuration	
>> conflicts. However, the person doing the configuration still needs to
>> know which devices are needed (on top of the mandatory ones) to obtain
>> a functional guest, and Kconfig will not provide any hints in this
>> respect.
>
> So I thought that was the model I was following in adding devices but it
> seems I don't understand the no-defaults behaviour. What is the
> difference between a device that is added in the machine.c that makes it
> required or expendable with -nodefaults?

First of all let's look at softmmu/vl.c, which is what creates the 
backends of the default devices.  These backends are basically automatic 
command line options of the "old" kind that directs both the creation of 
a backend and how it's associated to a device.

For example, if you have neither a -serial option nor a "-device 
isa-serial" option, vl.c's qemu_create_default_devices() will create the 
machine as if you specified one of "-serial mon:stdio", "-serial stdio" 
or "-serial vc:80Cx24C"; if you have none of -netdev/nic/-net, it will 
literally add two "-net" command line options corresponding to "-net nic 
-net user"; and so on for many other devices unless the board opts out 
(CD-ROM, floppy, SD card, parallel).   There's also a default monitor 
which is a bit out of topic here.

In any case, the effect of these "old" command line options is to 
populate various arrays, for example serial_hds[] for serial ports and 
nd_table[] for NIC backends.

There are then two ways that a board can process these arrays.  It can 
either _always_ create the device and possibly leave it not connected to 
any backend, or it can create the device only if the backend exists. 
Looking at qemu-system-aarch64's "-M virt", pl011 is always created with 
create_uart(), i.e. even with "-nodefaults"; NICs instead are only 
created if the backend exists (search for "nd_table" in hw/arm/virt.c).

In the former case, the device will have to be select-ed in Kconfig.  In 
the latter case, instead, the device will have an "imply" directive, and 
will be left out by --without-default-devices.

Paolo

[PATCH 06/22] hw/arm: Select VIRTIO_BLK for virt machine

[Alex Bennée]

From: Fabiano Rosas <farosas@suse.de>

The virt machine has IF_VIRTIO as block_default_type, which causes the
generic code to try to create a virtio-blk-pci device pair at
configure_blockdev()/qemu_create_cli_devices().

Select VIRTIO_BLK and VIRTIO_PCI from CONFIG_ARM_VIRT to avoid errors
when PCI_DEVICES=n (due to e.g. --without-default-devices):

$ ./qemu-system-aarch64 -M virt -accel tcg -cpu max -nodefaults -cdrom foo.qcow2
qemu-system-aarch64: -cdrom foo.qcow2: 'virtio-blk' (alias
'virtio-blk-pci') is not a valid device model name

Signed-off-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20230208192654.8854-7-farosas@suse.de>
---
 hw/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 4c23fbf800..168c1e8089 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -34,6 +34,7 @@ config ARM_VIRT
     select ACPI_HMAT
     select VIRTIO_PCI
     select VIRTIO_NET
+    select VIRTIO_BLK
 
 config CHEETAH
     bool
-- 
2.39.2

Re: [PATCH 06/22] hw/arm: Select VIRTIO_BLK for virt machine

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> From: Fabiano Rosas<farosas@suse.de>
> 
> The virt machine has IF_VIRTIO as block_default_type, which causes the
> generic code to try to create a virtio-blk-pci device pair at
> configure_blockdev()/qemu_create_cli_devices().
> 
> Select VIRTIO_BLK and VIRTIO_PCI from CONFIG_ARM_VIRT to avoid errors
> when PCI_DEVICES=n (due to e.g. --without-default-devices):
> 
> $ ./qemu-system-aarch64 -M virt -accel tcg -cpu max -nodefaults -cdrom foo.qcow2
> qemu-system-aarch64: -cdrom foo.qcow2: 'virtio-blk' (alias
> 'virtio-blk-pci') is not a valid device model name
> 
> Signed-off-by: Fabiano Rosas<farosas@suse.de>
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> Message-Id:<20230208192654.8854-7-farosas@suse.de>
> ---
>   hw/arm/Kconfig | 1 +
>   1 file changed, 1 insertion(+)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 06/22] hw/arm: Select VIRTIO_BLK for virt machine

[Juan Quintela]

Alex Bennée <alex.bennee@linaro.org> wrote:
> From: Fabiano Rosas <farosas@suse.de>
>
> The virt machine has IF_VIRTIO as block_default_type, which causes the
> generic code to try to create a virtio-blk-pci device pair at
> configure_blockdev()/qemu_create_cli_devices().
>
> Select VIRTIO_BLK and VIRTIO_PCI from CONFIG_ARM_VIRT to avoid errors
> when PCI_DEVICES=n (due to e.g. --without-default-devices):
>
> $ ./qemu-system-aarch64 -M virt -accel tcg -cpu max -nodefaults -cdrom foo.qcow2
> qemu-system-aarch64: -cdrom foo.qcow2: 'virtio-blk' (alias
> 'virtio-blk-pci') is not a valid device model name
>
> Signed-off-by: Fabiano Rosas <farosas@suse.de>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Message-Id: <20230208192654.8854-7-farosas@suse.de>

Reviewed-by: Juan Quintela <quintela@redhat.com>

Re: [PATCH 06/22] hw/arm: Select VIRTIO_BLK for virt machine

[Paolo Bonzini]

On 5/3/23 11:12, Alex Bennée wrote:
> From: Fabiano Rosas<farosas@suse.de>
> 
> The virt machine has IF_VIRTIO as block_default_type, which causes the
> generic code to try to create a virtio-blk-pci device pair at
> configure_blockdev()/qemu_create_cli_devices().
> 
> Select VIRTIO_BLK and VIRTIO_PCI from CONFIG_ARM_VIRT to avoid errors
> when PCI_DEVICES=n (due to e.g. --without-default-devices):
> 
> $ ./qemu-system-aarch64 -M virt -accel tcg -cpu max -nodefaults -cdrom foo.qcow2
> qemu-system-aarch64: -cdrom foo.qcow2: 'virtio-blk' (alias
> 'virtio-blk-pci') is not a valid device model name

This is also not needed.  It doesn't matter what's the default - it's 
possible to create a machine without block devices at all, therefore 
VIRTIO_BLK should not be selected.

Paolo

[PATCH 07/22] hw/arm: Select XLNX_USB_SUBSYS for xlnx-zcu102 machine

[Alex Bennée]

From: Fabiano Rosas <farosas@suse.de>

This machine hardcodes initialization of the USB device, so select the
corresponding Kconfig. It is not enough to have it as "default y if
XLNX_VERSAL" at usb/Kconfig because building --without-default-devices
disables the default selection resulting in:

$ ./qemu-system-aarch64 -M xlnx-zcu102
qemu-system-aarch64: missing object type 'usb_dwc3'
Aborted (core dumped)

Signed-off-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20230208192654.8854-8-farosas@suse.de>
---
 hw/arm/Kconfig | 1 +
 hw/usb/Kconfig | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 168c1e8089..cec7898bb7 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -439,6 +439,7 @@ config XLNX_VERSAL
     select OR_IRQ
     select XLNX_BBRAM
     select XLNX_EFUSE_VERSAL
+    select XLNX_USB_SUBSYS
 
 config NPCM7XX
     bool
diff --git a/hw/usb/Kconfig b/hw/usb/Kconfig
index ce4f433976..0ec6def4b8 100644
--- a/hw/usb/Kconfig
+++ b/hw/usb/Kconfig
@@ -136,5 +136,4 @@ config USB_DWC3
 
 config XLNX_USB_SUBSYS
     bool
-    default y if XLNX_VERSAL
     select USB_DWC3
-- 
2.39.2

Re: [PATCH 07/22] hw/arm: Select XLNX_USB_SUBSYS for xlnx-zcu102 machine

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> From: Fabiano Rosas<farosas@suse.de>
> 
> This machine hardcodes initialization of the USB device, so select the
> corresponding Kconfig. It is not enough to have it as "default y if
> XLNX_VERSAL" at usb/Kconfig because building --without-default-devices
> disables the default selection resulting in:
> 
> $ ./qemu-system-aarch64 -M xlnx-zcu102
> qemu-system-aarch64: missing object type 'usb_dwc3'
> Aborted (core dumped)
> 
> Signed-off-by: Fabiano Rosas<farosas@suse.de>
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> Message-Id:<20230208192654.8854-8-farosas@suse.de>
> ---
>   hw/arm/Kconfig | 1 +
>   hw/usb/Kconfig | 1 -
>   2 files changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 07/22] hw/arm: Select XLNX_USB_SUBSYS for xlnx-zcu102 machine

[Paolo Bonzini]

On 5/3/23 11:12, Alex Bennée wrote:
> From: Fabiano Rosas <farosas@suse.de>
> 
> This machine hardcodes initialization of the USB device, so select the
> corresponding Kconfig. It is not enough to have it as "default y if
> XLNX_VERSAL" at usb/Kconfig because building --without-default-devices
> disables the default selection resulting in:
> 
> $ ./qemu-system-aarch64 -M xlnx-zcu102
> qemu-system-aarch64: missing object type 'usb_dwc3'
> Aborted (core dumped)
> 
> Signed-off-by: Fabiano Rosas <farosas@suse.de>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Message-Id: <20230208192654.8854-8-farosas@suse.de>
> ---
>   hw/arm/Kconfig | 1 +
>   hw/usb/Kconfig | 1 -
>   2 files changed, 1 insertion(+), 1 deletion(-)

This one is correct: "-M xlnx-zcu102 -nodefaults" has a usb_dwc3 device.

Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo

> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index 168c1e8089..cec7898bb7 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -439,6 +439,7 @@ config XLNX_VERSAL
>       select OR_IRQ
>       select XLNX_BBRAM
>       select XLNX_EFUSE_VERSAL
> +    select XLNX_USB_SUBSYS
>   
>   config NPCM7XX
>       bool
> diff --git a/hw/usb/Kconfig b/hw/usb/Kconfig
> index ce4f433976..0ec6def4b8 100644
> --- a/hw/usb/Kconfig
> +++ b/hw/usb/Kconfig
> @@ -136,5 +136,4 @@ config USB_DWC3
>   
>   config XLNX_USB_SUBSYS
>       bool
> -    default y if XLNX_VERSAL
>       select USB_DWC3

[PATCH 08/22] hw/arm: Select GICV3_TCG for sbsa-ref machine

[Alex Bennée]

From: Fabiano Rosas <farosas@suse.de>

This machine hardcodes the creation of the interrupt controller, so
make sure the dependency is explicitly described in the Kconfig.

Signed-off-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20230208192654.8854-9-farosas@suse.de>
---
 hw/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index cec7898bb7..0cce0b8d5b 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -252,6 +252,7 @@ config SBSA_REF
     select PL061 # GPIO
     select USB_EHCI_SYSBUS
     select WDT_SBSA
+    select ARM_GICV3_TCG
 
 config SABRELITE
     bool
-- 
2.39.2

Re: [PATCH 08/22] hw/arm: Select GICV3_TCG for sbsa-ref machine

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> From: Fabiano Rosas<farosas@suse.de>
> 
> This machine hardcodes the creation of the interrupt controller, so
> make sure the dependency is explicitly described in the Kconfig.
> 
> Signed-off-by: Fabiano Rosas<farosas@suse.de>
> Reviewed-by: Peter Maydell<peter.maydell@linaro.org>
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> Message-Id:<20230208192654.8854-9-farosas@suse.de>
> ---
>   hw/arm/Kconfig | 1 +
>   1 file changed, 1 insertion(+)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 08/22] hw/arm: Select GICV3_TCG for sbsa-ref machine

[Paolo Bonzini]

On 5/3/23 11:12, Alex Bennée wrote:
> From: Fabiano Rosas<farosas@suse.de>
> 
> This machine hardcodes the creation of the interrupt controller, so
> make sure the dependency is explicitly described in the Kconfig.

gicv3_init_cpuif is used unconditionally by arm_gic_realize in 
hw/intc/arm_gicv3.c, so right now the separation between GICV3 and 
GICV3_TCG is useless.

That said, using "default y" is wrong.  The correct definition in 
hw/intc/Kconfig for these should be:

config ARM_GIC
     bool
     select MSI_NONBROKEN
     select ARM_GICV3_TCG # if TCG
     select ARM_GIC_KVM if KVM

config ARM_GICV3_TCG
     bool

config ARM_GIC_KVM
     bool

(where the "if TCG" is incorrect right now as explained above).

Paolo

> Signed-off-by: Fabiano Rosas<farosas@suse.de>
> Reviewed-by: Peter Maydell<peter.maydell@linaro.org>
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> Message-Id:<20230208192654.8854-9-farosas@suse.de>
> ---
>   hw/arm/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index cec7898bb7..0cce0b8d5b 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -252,6 +252,7 @@ config SBSA_REF
>       select PL061 # GPIO
>       select USB_EHCI_SYSBUS
>       select WDT_SBSA
> +    select ARM_GICV3_TCG
>   

[PATCH 09/22] hw/arm: Select e1000e for sbsa-ref machine

[Alex Bennée]

From: Fabiano Rosas <farosas@suse.de>

This machine explicitly selects the e1000e network adapter if no other
option was given in the command line. Make sure e1000e is present in
the build.

Signed-off-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20230208192654.8854-10-farosas@suse.de>
---
 hw/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 0cce0b8d5b..06f58d1a6f 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -253,6 +253,7 @@ config SBSA_REF
     select USB_EHCI_SYSBUS
     select WDT_SBSA
     select ARM_GICV3_TCG
+    select E1000E_PCI_EXPRESS
 
 config SABRELITE
     bool
-- 
2.39.2

Re: [PATCH 09/22] hw/arm: Select e1000e for sbsa-ref machine

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> From: Fabiano Rosas<farosas@suse.de>
> 
> This machine explicitly selects the e1000e network adapter if no other
> option was given in the command line. Make sure e1000e is present in
> the build.
> 
> Signed-off-by: Fabiano Rosas<farosas@suse.de>
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> Message-Id:<20230208192654.8854-10-farosas@suse.de>
> ---
>   hw/arm/Kconfig | 1 +
>   1 file changed, 1 insertion(+)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 09/22] hw/arm: Select e1000e for sbsa-ref machine

[Paolo Bonzini]

On 5/3/23 11:12, Alex Bennée wrote:
> From: Fabiano Rosas <farosas@suse.de>
> 
> This machine explicitly selects the e1000e network adapter if no other
> option was given in the command line. Make sure e1000e is present in
> the build.
> 
> Signed-off-by: Fabiano Rosas <farosas@suse.de>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Message-Id: <20230208192654.8854-10-farosas@suse.de>
> ---
>   hw/arm/Kconfig | 1 +
>   1 file changed, 1 insertion(+)

This is not necessary, and patch 10 is not as well, because neither VGA 
nor a NIC are added with --nodefaults.

Paolo

[PATCH 10/22] hw/arm: Select VGA_PCI for sbsa-ref machine

[Alex Bennée]

From: Fabiano Rosas <farosas@suse.de>

The sbsa-ref machine explicitly creates a VGA PCI device, so make sure
vga-pci.c is included in the build.

Signed-off-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20230208192654.8854-11-farosas@suse.de>
---
 hw/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 06f58d1a6f..9e6e7ababe 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -254,6 +254,7 @@ config SBSA_REF
     select WDT_SBSA
     select ARM_GICV3_TCG
     select E1000E_PCI_EXPRESS
+    select VGA_PCI
 
 config SABRELITE
     bool
-- 
2.39.2

Re: [PATCH 10/22] hw/arm: Select VGA_PCI for sbsa-ref machine

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> From: Fabiano Rosas<farosas@suse.de>
> 
> The sbsa-ref machine explicitly creates a VGA PCI device, so make sure
> vga-pci.c is included in the build.
> 
> Signed-off-by: Fabiano Rosas<farosas@suse.de>
> Reviewed-by: Peter Maydell<peter.maydell@linaro.org>
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> Message-Id:<20230208192654.8854-11-farosas@suse.de>
> ---
>   hw/arm/Kconfig | 1 +
>   1 file changed, 1 insertion(+)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

[PATCH 11/22] hw/alpha: make E1000_PCI a hard dependency for clipper

[Alex Bennée]

We can't just imply it as the board will fail to create otherwise.
This shows up as a "make check" failure with a
--without-default-devices build.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 hw/alpha/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/alpha/Kconfig b/hw/alpha/Kconfig
index 9af650c94e..4db7f84e9e 100644
--- a/hw/alpha/Kconfig
+++ b/hw/alpha/Kconfig
@@ -2,7 +2,7 @@ config DP264
     bool
     imply PCI_DEVICES
     imply TEST_DEVICES
-    imply E1000_PCI
+    select E1000_PCI
     select I82378
     select IDE_CMD646
     select MC146818RTC
-- 
2.39.2

Re: [PATCH 11/22] hw/alpha: make E1000_PCI a hard dependency for clipper

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> We can't just imply it as the board will fail to create otherwise.
> This shows up as a "make check" failure with a
> --without-default-devices build.
> 
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> ---
>   hw/alpha/Kconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 11/22] hw/alpha: make E1000_PCI a hard dependency for clipper

[Paolo Bonzini]

On 5/3/23 11:12, Alex Bennée wrote:
> We can't just imply it as the board will fail to create otherwise.
> This shows up as a "make check" failure with a
> --without-default-devices build.

Not needed and a test bug.

Paolo

[PATCH 12/22] hw/hppa: add TULIP as a dependency for HPPA_B160L

[Alex Bennée]

These are needed for board creation so fail under "make check" with a
--without-default-devices build.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 hw/hppa/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/hppa/Kconfig b/hw/hppa/Kconfig
index 5dd8b5b21e..f405663839 100644
--- a/hw/hppa/Kconfig
+++ b/hw/hppa/Kconfig
@@ -15,3 +15,4 @@ config HPPA_B160L
     select LASIPS2
     select PARALLEL
     select ARTIST
+    select TULIP
-- 
2.39.2

Re: [PATCH 12/22] hw/hppa: add TULIP as a dependency for HPPA_B160L

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> These are needed for board creation so fail under "make check" with a
> --without-default-devices build.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>   hw/hppa/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/hw/hppa/Kconfig b/hw/hppa/Kconfig
> index 5dd8b5b21e..f405663839 100644
> --- a/hw/hppa/Kconfig
> +++ b/hw/hppa/Kconfig
> @@ -15,3 +15,4 @@ config HPPA_B160L
>       select LASIPS2
>       select PARALLEL
>       select ARTIST
> +    select TULIP

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 12/22] hw/hppa: add TULIP as a dependency for HPPA_B160L

[Paolo Bonzini]

On 5/3/23 11:12, Alex Bennée wrote:
> These are needed for board creation so fail under "make check" with a
> --without-default-devices build.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

Not needed.  Selecting "LSI_SCSI_PCI" however is correct:

bus: main-system-bus
   type System
   dev: ps2-mouse, id ""
   dev: ps2-kbd, id ""
   dev: lasips2, id ""
   dev: fw_cfg_mem, id ""
   dev: serial-mm, id ""
   dev: isabus-bridge, id ""
   dev: dino-pcihost, id ""
     bus: pci
       type PCI
       dev: lsi53c895a, id ""
   dev: lasi-chip, id ""


Paolo

[PATCH 13/22] hw/sparc: add a TCX dependency for SUN4M machines

[Alex Bennée]

This is the fallback VGA devices needed for board creation so will
otherwise fail under "make check" with a --without-default-devices
build.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 hw/sparc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/sparc/Kconfig b/hw/sparc/Kconfig
index 79d58beb7a..721b37a9ca 100644
--- a/hw/sparc/Kconfig
+++ b/hw/sparc/Kconfig
@@ -15,6 +15,7 @@ config SUN4M
     select STP2000
     select CHRP_NVRAM
     select OR_IRQ
+    select TCX
 
 config LEON3
     bool
-- 
2.39.2

Re: [PATCH 13/22] hw/sparc: add a TCX dependency for SUN4M machines

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> This is the fallback VGA devices needed for board creation so will
> otherwise fail under "make check" with a --without-default-devices
> build.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>   hw/sparc/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/hw/sparc/Kconfig b/hw/sparc/Kconfig
> index 79d58beb7a..721b37a9ca 100644
> --- a/hw/sparc/Kconfig
> +++ b/hw/sparc/Kconfig
> @@ -15,6 +15,7 @@ config SUN4M
>       select STP2000
>       select CHRP_NVRAM
>       select OR_IRQ
> +    select TCX
>   
>   config LEON3
>       bool

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 13/22] hw/sparc: add a TCX dependency for SUN4M machines

[Paolo Bonzini]

On 5/3/23 11:12, Alex Bennée wrote:
> This is the fallback VGA devices needed for board creation so will
> otherwise fail under "make check" with a --without-default-devices
> build.
> 
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>

Not needed:

info qtree
bus: main-system-bus
   dev: apc, id ""
   dev: empty_slot, id ""
   dev: escc, id ""
   dev: fw_cfg_mem, id ""
   dev: lance, id ""
   dev: macio_idreg, id ""
   dev: memory, id ""
   dev: openprom, id ""
   dev: slavio_intctl, id ""
   dev: slavio_misc, id ""
   dev: slavio_timer, id ""
   dev: sparc32-dma, id ""
   dev: sparc32-espdma, id ""
   dev: sparc32-ledma, id ""
   dev: sun4m-iommu, id ""
   dev: sun-CS4231, id ""
   dev: sun-fdtwo, id ""
   dev: sysbus-esp, id ""
   dev: sysbus-m48t08, id ""
   dev: tcx_afx, id ""

Paolo

> ---
>   hw/sparc/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/hw/sparc/Kconfig b/hw/sparc/Kconfig
> index 79d58beb7a..721b37a9ca 100644
> --- a/hw/sparc/Kconfig
> +++ b/hw/sparc/Kconfig
> @@ -15,6 +15,7 @@ config SUN4M
>       select STP2000
>       select CHRP_NVRAM
>       select OR_IRQ
> +    select TCX

[PATCH 14/22] hw/loongarch: add VIRTIO as a dependency for LOONGARCH_VIRT

[Alex Bennée]

These are needed for board creation so fail under "make check" with a
--without-default-devices build.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 hw/loongarch/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/loongarch/Kconfig b/hw/loongarch/Kconfig
index eb112af990..74d8449100 100644
--- a/hw/loongarch/Kconfig
+++ b/hw/loongarch/Kconfig
@@ -21,3 +21,5 @@ config LOONGARCH_VIRT
     select FW_CFG_DMA
     select DIMM
     select PFLASH_CFI01
+    select VIRTIO_PCI
+    select VIRTIO_NET
-- 
2.39.2

Re: [PATCH 14/22] hw/loongarch: add VIRTIO as a dependency for LOONGARCH_VIRT

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> These are needed for board creation so fail under "make check" with a
> --without-default-devices build.
> 
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> ---
>   hw/loongarch/Kconfig | 2 ++
>   1 file changed, 2 insertions(+)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 14/22] hw/loongarch: add VIRTIO as a dependency for LOONGARCH_VIRT

[Paolo Bonzini]

On 5/3/23 11:12, Alex Bennée wrote:
> These are needed for board creation so fail under "make check" with a
> --without-default-devices build.
> 
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>

Also not needed:

bus: main-system-bus
   type System
   dev: platform-bus-device, id "platform-bus-device"
   dev: acpi-ged, id ""
   dev: ls7a_rtc, id ""
   dev: unimplemented-device, id ""
   dev: serial-mm, id ""
   dev: gpex-pcihost, id ""
     bus: pcie.0
       type PCIE
       dev: gpex-root, id ""
   dev: loongarch_pch_msi, id ""
   dev: loongarch_pch_pic, id ""
   dev: loongarch.extioi, id ""
   dev: loongarch_ipi, id ""
   dev: fw_cfg_mem, id ""


Paolo

[PATCH 15/22] hw/sh4: make RTL8139 a hard dependency for RD2

[Alex Bennée]

We can't just imply it as the board will fail to create otherwise.
This shows up as a "make check" failure with a
--without-default-devices build.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 hw/sh4/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index ab733a3f76..03f3469ae1 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -2,7 +2,7 @@ config R2D
     bool
     imply PCI_DEVICES
     imply TEST_DEVICES
-    imply RTL8139_PCI
+    select RTL8139_PCI
     select I82378 if TEST_DEVICES
     select IDE_MMIO
     select PFLASH_CFI02
-- 
2.39.2

Re: [PATCH 15/22] hw/sh4: make RTL8139 a hard dependency for RD2

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> We can't just imply it as the board will fail to create otherwise.
> This shows up as a "make check" failure with a
> --without-default-devices build.
> 
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> ---
>   hw/sh4/Kconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 15/22] hw/sh4: make RTL8139 a hard dependency for RD2

[Paolo Bonzini]

On 5/3/23 11:12, Alex Bennée wrote:
> We can't just imply it as the board will fail to create otherwise.
> This shows up as a "make check" failure with a
> --without-default-devices build.

Not needed, also typo in subject (should be R2D rather than RD2).

Paolo

[PATCH 16/22] hw/mips: add VIRTIO and USB dependencies for LOONGSON3V

[Alex Bennée]

These are hardwired into the board so must be selected. This shows up
as a "make check" failure with a --without-default-devices build.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 hw/mips/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
index da3a37e215..0fcc3da41c 100644
--- a/hw/mips/Kconfig
+++ b/hw/mips/Kconfig
@@ -45,6 +45,9 @@ config LOONGSON3V
     select PCI_EXPRESS_GENERIC_BRIDGE
     select MSI_NONBROKEN
     select FW_CFG_MIPS
+    select VIRTIO_PCI
+    select VIRTIO_NET
+    select USB_OHCI_PCI
 
 config MIPS_CPS
     bool
-- 
2.39.2

Re: [PATCH 16/22] hw/mips: add VIRTIO and USB dependencies for LOONGSON3V

[Paolo Bonzini]

On 5/3/23 11:12, Alex Bennée wrote:
> These are hardwired into the board so must be selected. This shows up
> as a "make check" failure with a --without-default-devices build.
> 
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> ---
>   hw/mips/Kconfig | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
> index da3a37e215..0fcc3da41c 100644
> --- a/hw/mips/Kconfig
> +++ b/hw/mips/Kconfig
> @@ -45,6 +45,9 @@ config LOONGSON3V
>       select PCI_EXPRESS_GENERIC_BRIDGE
>       select MSI_NONBROKEN
>       select FW_CFG_MIPS
> +    select VIRTIO_PCI
> +    select VIRTIO_NET
> +    select USB_OHCI_PCI

Neither is needed by -nodefaults.

Paolo

[PATCH 17/22] hw/xtensa: add VIRTIO as dependencies for XTENSA_VIRT

[Alex Bennée]

These are needed for board creation so fail under "make check" with a
--without-default-devices build.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 hw/xtensa/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/xtensa/Kconfig b/hw/xtensa/Kconfig
index 0740657ea5..a54a9d395e 100644
--- a/hw/xtensa/Kconfig
+++ b/hw/xtensa/Kconfig
@@ -6,6 +6,8 @@ config XTENSA_VIRT
     select XTENSA_SIM
     select PCI_EXPRESS_GENERIC_BRIDGE
     select PCI_DEVICES
+    select VIRTIO_PCI
+    select VIRTIO_NET
 
 config XTENSA_XTFPGA
     bool
-- 
2.39.2

Re: [PATCH 17/22] hw/xtensa: add VIRTIO as dependencies for XTENSA_VIRT

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> These are needed for board creation so fail under "make check" with a
> --without-default-devices build.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>   hw/xtensa/Kconfig | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/hw/xtensa/Kconfig b/hw/xtensa/Kconfig
> index 0740657ea5..a54a9d395e 100644
> --- a/hw/xtensa/Kconfig
> +++ b/hw/xtensa/Kconfig
> @@ -6,6 +6,8 @@ config XTENSA_VIRT
>       select XTENSA_SIM
>       select PCI_EXPRESS_GENERIC_BRIDGE
>       select PCI_DEVICES
> +    select VIRTIO_PCI
> +    select VIRTIO_NET
>   
>   config XTENSA_XTFPGA
>       bool

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 17/22] hw/xtensa: add VIRTIO as dependencies for XTENSA_VIRT

[Max Filippov]

On Wed, May 3, 2023 at 2:12 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> These are needed for board creation so fail under "make check" with a
> --without-default-devices build.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  hw/xtensa/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Max Filippov <jcmvbkbc@gmail.com>

-- 
Thanks.
-- Max

Re: [PATCH 17/22] hw/xtensa: add VIRTIO as dependencies for XTENSA_VIRT

[Paolo Bonzini]

On 5/3/23 11:12, Alex Bennée wrote:
> These are needed for board creation so fail under "make check" with a
> --without-default-devices build.
> 
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> ---
>   hw/xtensa/Kconfig | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/hw/xtensa/Kconfig b/hw/xtensa/Kconfig
> index 0740657ea5..a54a9d395e 100644
> --- a/hw/xtensa/Kconfig
> +++ b/hw/xtensa/Kconfig
> @@ -6,6 +6,8 @@ config XTENSA_VIRT
>       select XTENSA_SIM
>       select PCI_EXPRESS_GENERIC_BRIDGE
>       select PCI_DEVICES
> +    select VIRTIO_PCI
> +    select VIRTIO_NET

Not needed.

Paolo

[PATCH 18/22] scripts/ci: clean-up the 20.04/22.04 confusion in ansible

[Alex Bennée]

We have a bunch of references to 20.04 (which s390x is still on)
although we are basically building on 22.04 now. Clean up the textual
references and use lcitool to generate the full package list to be
consistent.

We can drop "Install packages to build QEMU on Ubuntu on non-s390x" as
when we upgrade the s390x builder to 22.04 it won't need this
workaround.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 .../custom-runners/ubuntu-22.04-aarch32.yml   |   2 +-
 .../custom-runners/ubuntu-22.04-aarch64.yml   |   4 +-
 scripts/ci/setup/build-environment.yml        | 111 ++++++++++++------
 3 files changed, 80 insertions(+), 37 deletions(-)

diff --git a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch32.yml b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch32.yml
index 50e5646a44..b8a0d75162 100644
--- a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch32.yml
+++ b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch32.yml
@@ -1,6 +1,6 @@
 # All ubuntu-22.04 jobs should run successfully in an environment
 # setup by the scripts/ci/setup/qemu/build-environment.yml task
-# "Install basic packages to build QEMU on Ubuntu 20.04"
+# "Install basic packages to build QEMU on Ubuntu 22.04"
 
 ubuntu-22.04-aarch32-all:
  extends: .custom_runner_template
diff --git a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
index 13e14a0f87..57303c12e1 100644
--- a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
+++ b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
@@ -1,6 +1,6 @@
-# All ubuntu-20.04 jobs should run successfully in an environment
+# All ubuntu-22.04 jobs should run successfully in an environment
 # setup by the scripts/ci/setup/qemu/build-environment.yml task
-# "Install basic packages to build QEMU on Ubuntu 20.04"
+# "Install basic packages to build QEMU on Ubuntu 22.04"
 
 ubuntu-22.04-aarch64-all-linux-static:
  extends: .custom_runner_template
diff --git a/scripts/ci/setup/build-environment.yml b/scripts/ci/setup/build-environment.yml
index 78b1021cd4..f344d1a850 100644
--- a/scripts/ci/setup/build-environment.yml
+++ b/scripts/ci/setup/build-environment.yml
@@ -24,7 +24,6 @@
       when:
         - ansible_facts['distribution'] == 'Ubuntu'
         - ansible_facts['architecture'] == 'aarch64'
-        - ansible_facts['distribution_version'] == '20.04'
 
     - name: Update apt cache / upgrade packages via apt
       apt:
@@ -33,87 +32,131 @@
       when:
         - ansible_facts['distribution'] == 'Ubuntu'
 
-    - name: Install basic packages to build QEMU on Ubuntu 20.04
+    # lcitool variables -f json ubuntu-2204 qemu | jq -r '.pkgs[]' | xargs -n 1 echo "-"
+    - name: Install basic packages to build QEMU on Ubuntu 22.04
       package:
         name:
+          - bash
+          - bc
+          - bison
+          - bsdextrautils
+          - bzip2
+          - ca-certificates
           - ccache
+          - clang
+          - dbus
+          - debianutils
+          - diffutils
+          - exuberant-ctags
+          - findutils
+          - flex
+          - g++
           - gcc
+          - gcovr
+          - genisoimage
           - gettext
           - git
-          - glusterfs-common
+          - hostname
           - libaio-dev
+          - libasan5
+          - libasound2-dev
           - libattr1-dev
+          - libbpf-dev
           - libbrlapi-dev
           - libbz2-dev
+          - libc6-dev
           - libcacard-dev
-          - libcapstone-dev
           - libcap-ng-dev
+          - libcapstone-dev
+          - libcmocka-dev
           - libcurl4-gnutls-dev
+          - libdaxctl-dev
           - libdrm-dev
           - libepoxy-dev
           - libfdt-dev
+          - libffi-dev
           - libgbm-dev
+          - libgcrypt20-dev
+          - libglib2.0-dev
+          - libglusterfs-dev
+          - libgnutls28-dev
           - libgtk-3-dev
+          - libibumad-dev
           - libibverbs-dev
           - libiscsi-dev
           - libjemalloc-dev
           - libjpeg-turbo8-dev
+          - libjson-c-dev
+          - liblttng-ust-dev
           - liblzo2-dev
-          - libncurses5-dev
           - libncursesw5-dev
           - libnfs-dev
-          - libnss3-dev
           - libnuma-dev
+          - libpam0g-dev
+          - libpcre2-dev
           - libpixman-1-dev
-          - librados-dev
+          - libpmem-dev
+          - libpng-dev
+          - libpulse-dev
           - librbd-dev
           - librdmacm-dev
           - libsasl2-dev
           - libsdl2-dev
+          - libsdl2-image-dev
           - libseccomp-dev
+          - libslirp-dev
           - libsnappy-dev
           - libspice-protocol-dev
+          - libspice-server-dev
           - libssh-dev
+          - libsystemd-dev
+          - libtasn1-6-dev
+          - libubsan1
+          - libudev-dev
+          - liburing-dev
           - libusb-1.0-0-dev
           - libusbredirhost-dev
           - libvdeplug-dev
+          - libvirglrenderer-dev
           - libvte-2.91-dev
+          - libxen-dev
+          - libxml2-dev
           - libzstd-dev
+          - llvm
+          - locales
           - make
-          - python3-yaml
+          - meson
+          - multipath-tools
+          - ncat
+          - nettle-dev
+          - ninja-build
+          - openssh-client
+          - pkgconf
+          - python3
+          - python3-numpy
+          - python3-opencv
+          - python3-pillow
+          - python3-pip
           - python3-sphinx
           - python3-sphinx-rtd-theme
-          - ninja-build
+          - python3-venv
+          - python3-yaml
+          - rpm2cpio
+          - sed
           - sparse
+          - systemtap-sdt-dev
+          - tar
+          - tesseract-ocr
+          - tesseract-ocr-eng
+          - texinfo
           - xfslibs-dev
+          - zlib1g-dev
         state: present
       when:
         - ansible_facts['distribution'] == 'Ubuntu'
+        - ansible_facts['distribution_version'] == '22.04'
 
-    - name: Install packages to build QEMU on Ubuntu 20.04 on non-s390x
-      package:
-        name:
-          - libspice-server-dev
-          - libxen-dev
-        state: present
-      when:
-        - ansible_facts['distribution'] == 'Ubuntu'
-        - ansible_facts['architecture'] == 'aarch64' or ansible_facts['architecture'] == 'x86_64'
-
-    - name: Install basic packages to build QEMU on Ubuntu 20.04
-      package:
-        name:
-        # Originally from tests/docker/dockerfiles/ubuntu2004.docker
-          - clang-10
-          - genisoimage
-          - liblttng-ust-dev
-          - libslirp-dev
-          - netcat-openbsd
-      when:
-        - ansible_facts['distribution'] == 'Ubuntu'
-        - ansible_facts['distribution_version'] == '20.04'
-
-    - name: Install armhf cross-compile packages to build QEMU on AArch64 Ubuntu 20.04
+    - name: Install armhf cross-compile packages to build QEMU on AArch64 Ubuntu 22.04
       package:
         name:
           - binutils-arm-linux-gnueabihf
@@ -128,7 +171,7 @@
           - zlib1g-dev:armhf
       when:
         - ansible_facts['distribution'] == 'Ubuntu'
-        - ansible_facts['distribution_version'] == '20.04'
+        - ansible_facts['distribution_version'] == '22.04'
         - ansible_facts['architecture'] == 'aarch64'
 
     - name: Enable EPEL repo on EL8
-- 
2.39.2

[PATCH 19/22] gitlab: add ubuntu-22.04-aarch64-without-defaults

[Alex Bennée]

This does a very minimal build without default devices or features. I
chose the aarch64 runner as it doesn't count towards CI minutes and is
a fairly under-utilised builder.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 .../custom-runners/ubuntu-22.04-aarch64.yml   | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
index 57303c12e1..f8489dd3fc 100644
--- a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
+++ b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
@@ -45,6 +45,28 @@ ubuntu-22.04-aarch64-all:
  - make --output-sync -j`nproc --ignore=40`
  - make --output-sync -j`nproc --ignore=40` check
 
+ubuntu-22.04-aarch64-without-defaults:
+ extends: .custom_runner_template
+ needs: []
+ stage: build
+ tags:
+ - ubuntu_22.04
+ - aarch64
+ rules:
+ - if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ /^staging/'
+   when: manual
+   allow_failure: true
+ - if: "$AARCH64_RUNNER_AVAILABLE"
+   when: manual
+   allow_failure: true
+ script:
+ - mkdir build
+ - cd build
+ - ../configure --disable-user --without-default-devices --without-default-features
+   || { cat config.log meson-logs/meson-log.txt; exit 1; }
+ - make --output-sync -j`nproc --ignore=40`
+ - make --output-sync -j`nproc --ignore=40` check
+
 ubuntu-22.04-aarch64-alldbg:
  extends: .custom_runner_template
  needs: []
-- 
2.39.2

Re: [PATCH 19/22] gitlab: add ubuntu-22.04-aarch64-without-defaults

[Thomas Huth]

On 03/05/2023 11.12, Alex Bennée wrote:
> This does a very minimal build without default devices or features. I
> chose the aarch64 runner as it doesn't count towards CI minutes and is
> a fairly under-utilised builder.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>   .../custom-runners/ubuntu-22.04-aarch64.yml   | 22 +++++++++++++++++++
>   1 file changed, 22 insertions(+)
> 
> diff --git a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
> index 57303c12e1..f8489dd3fc 100644
> --- a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
> +++ b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
> @@ -45,6 +45,28 @@ ubuntu-22.04-aarch64-all:
>    - make --output-sync -j`nproc --ignore=40`
>    - make --output-sync -j`nproc --ignore=40` check
>   
> +ubuntu-22.04-aarch64-without-defaults:
> + extends: .custom_runner_template
> + needs: []
> + stage: build
> + tags:
> + - ubuntu_22.04
> + - aarch64
> + rules:
> + - if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ /^staging/'
> +   when: manual
> +   allow_failure: true
> + - if: "$AARCH64_RUNNER_AVAILABLE"
> +   when: manual
> +   allow_failure: true
> + script:
> + - mkdir build
> + - cd build
> + - ../configure --disable-user --without-default-devices --without-default-features
> +   || { cat config.log meson-logs/meson-log.txt; exit 1; }
> + - make --output-sync -j`nproc --ignore=40`
> + - make --output-sync -j`nproc --ignore=40` check

Reviewed-by: Thomas Huth <thuth@redhat.com>

Maybe you could also enable "check-qtest" for the "build-without-defaults" 
job in builtest.yml now?

  Thomas

Re: [PATCH 19/22] gitlab: add ubuntu-22.04-aarch64-without-defaults

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> This does a very minimal build without default devices or features. I
> chose the aarch64 runner as it doesn't count towards CI minutes and is
> a fairly under-utilised builder.
> 
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> ---
>   .../custom-runners/ubuntu-22.04-aarch64.yml   | 22 +++++++++++++++++++
>   1 file changed, 22 insertions(+)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

[PATCH 20/22] gitlab: enable minimal device profoile for aarch64 --disable-tcg

[Alex Bennée]

As this is likely the most common configuration people will want once
the --disable-tcg patches land.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Cc: Fabiano Rosas <farosas@suse.de>
---
 .gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
index f8489dd3fc..374b0956c3 100644
--- a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
+++ b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
@@ -145,7 +145,7 @@ ubuntu-22.04-aarch64-notcg:
  script:
  - mkdir build
  - cd build
- - ../configure --disable-tcg
+ - ../configure --disable-tcg --with-devices-aarch64=minimal
    || { cat config.log meson-logs/meson-log.txt; exit 1; }
  - make --output-sync -j`nproc --ignore=40`
  - make --output-sync -j`nproc --ignore=40` check
-- 
2.39.2

Re: [PATCH 20/22] gitlab: enable minimal device profoile for aarch64 --disable-tcg

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> As this is likely the most common configuration people will want once
> the --disable-tcg patches land.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Fabiano Rosas <farosas@suse.de>
> ---
>   .gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

Typo in $SUBJECT.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 20/22] gitlab: enable minimal device profoile for aarch64 --disable-tcg

[Juan Quintela]

Alex Bennée <alex.bennee@linaro.org> wrote:
> As this is likely the most common configuration people will want once
> the --disable-tcg patches land.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Fabiano Rosas <farosas@suse.de>

s/profoile/profile/ on $subject

> ---
>  .gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
> index f8489dd3fc..374b0956c3 100644
> --- a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
> +++ b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
> @@ -145,7 +145,7 @@ ubuntu-22.04-aarch64-notcg:
>   script:
>   - mkdir build
>   - cd build
> - - ../configure --disable-tcg
> + - ../configure --disable-tcg --with-devices-aarch64=minimal
>     || { cat config.log meson-logs/meson-log.txt; exit 1; }
>   - make --output-sync -j`nproc --ignore=40`
>   - make --output-sync -j`nproc --ignore=40` check

I have no clue about what arm users want or not.

Later, Juan.

Re: [PATCH 20/22] gitlab: enable minimal device profoile for aarch64 --disable-tcg

[Fabiano Rosas]

Alex Bennée <alex.bennee@linaro.org> writes:

> As this is likely the most common configuration people will want once
> the --disable-tcg patches land.

I don't think sbsa-ref works with KVM, sbsa_ref_init has:

    if (kvm_enabled()) {
        error_report("sbsa-ref: KVM is not supported for this machine");
        exit(1);
    }

[PATCH 21/22] tests/avocado: use http for mipsdistros.mips.com

[Alex Bennée]

As the cached assets have fallen out of our cache new attempts to
fetch these binaries fail hard due to certificate expirty. It's hard
to find a contact email for the domain as the root page of mipsdistros
throws up some random XML. I suspect Amazon are merely the hosts.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 tests/avocado/replay_kernel.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/avocado/replay_kernel.py b/tests/avocado/replay_kernel.py
index f13456e1ec..fe1e901f4b 100644
--- a/tests/avocado/replay_kernel.py
+++ b/tests/avocado/replay_kernel.py
@@ -493,7 +493,7 @@ def test_mips_malta32el_nanomips_4k(self):
         :avocado: tags=endian:little
         :avocado: tags=cpu:I7200
         """
-        kernel_url = ('https://mipsdistros.mips.com/LinuxDistro/nanomips/'
+        kernel_url = ('http://mipsdistros.mips.com/LinuxDistro/nanomips/'
                       'kernels/v4.15.18-432-gb2eb9a8b07a1-20180627102142/'
                       'generic_nano32r6el_page4k.xz')
         kernel_hash = '477456aafd2a0f1ddc9482727f20fe9575565dd6'
@@ -507,7 +507,7 @@ def test_mips_malta32el_nanomips_16k_up(self):
         :avocado: tags=endian:little
         :avocado: tags=cpu:I7200
         """
-        kernel_url = ('https://mipsdistros.mips.com/LinuxDistro/nanomips/'
+        kernel_url = ('http://mipsdistros.mips.com/LinuxDistro/nanomips/'
                       'kernels/v4.15.18-432-gb2eb9a8b07a1-20180627102142/'
                       'generic_nano32r6el_page16k_up.xz')
         kernel_hash = 'e882868f944c71c816e832e2303b7874d044a7bc'
@@ -521,7 +521,7 @@ def test_mips_malta32el_nanomips_64k_dbg(self):
         :avocado: tags=endian:little
         :avocado: tags=cpu:I7200
         """
-        kernel_url = ('https://mipsdistros.mips.com/LinuxDistro/nanomips/'
+        kernel_url = ('http://mipsdistros.mips.com/LinuxDistro/nanomips/'
                       'kernels/v4.15.18-432-gb2eb9a8b07a1-20180627102142/'
                       'generic_nano32r6el_page64k_dbg.xz')
         kernel_hash = '18d1c68f2e23429e266ca39ba5349ccd0aeb7180'
-- 
2.39.2

Re: [PATCH 21/22] tests/avocado: use http for mipsdistros.mips.com

[Thomas Huth]

On 03/05/2023 11.12, Alex Bennée wrote:
> As the cached assets have fallen out of our cache new attempts to
> fetch these binaries fail hard due to certificate expirty. It's hard

s/expirty/expiry/

With that typo fixed:

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH 21/22] tests/avocado: use http for mipsdistros.mips.com

[Richard Henderson]

On 5/3/23 10:12, Alex Bennée wrote:
> As the cached assets have fallen out of our cache new attempts to
> fetch these binaries fail hard due to certificate expirty. It's hard
> to find a contact email for the domain as the root page of mipsdistros
> throws up some random XML. I suspect Amazon are merely the hosts.
> 
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> Cc: Philippe Mathieu-Daudé<philmd@linaro.org>
> ---
>   tests/avocado/replay_kernel.py | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)

Might also mention that our saved hash prevents mucking about with non-secure download.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~

Re: [PATCH 21/22] tests/avocado: use http for mipsdistros.mips.com

[Jiaxun Yang]

> 2023年5月3日 10:12，Alex Bennée <alex.bennee@linaro.org> 写道：
> 
> As the cached assets have fallen out of our cache new attempts to
> fetch these binaries fail hard due to certificate expirty. It's hard
> to find a contact email for the domain as the root page of mipsdistros
> throws up some random XML. I suspect Amazon are merely the hosts.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Philippe Mathieu-Daudé <philmd@linaro.org>

Hi  all,

Just reached MIPS to get certification fixed.

Thanks
- Jiaxun

[PATCH 22/22] tests/qtest: skip bcm2835-test if no raspi3b model

[Alex Bennée]

We can't assume the machine exists and should gracefully skip the test
if we haven't built the model. This is ostensibly fixed by
db2237c459 (tests/qtest: Restrict bcm2835-dma-test to CONFIG_RASPI)
but I still hit it during my tests. Other qtests seem to use this
pattern to gracefully skip stuff.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 tests/qtest/bcm2835-dma-test.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/tests/qtest/bcm2835-dma-test.c b/tests/qtest/bcm2835-dma-test.c
index 8293d822b9..2e6245e9e2 100644
--- a/tests/qtest/bcm2835-dma-test.c
+++ b/tests/qtest/bcm2835-dma-test.c
@@ -107,12 +107,11 @@ static void bcm2835_dma_test_interrupts(void)
 
 int main(int argc, char **argv)
 {
-    int ret;
     g_test_init(&argc, &argv, NULL);
-    qtest_add_func("/bcm2835/dma/test_interrupts",
+    if (qtest_has_machine("raspi3b")) {
+        qtest_add_func("/bcm2835/dma/test_interrupts",
                    bcm2835_dma_test_interrupts);
-    qtest_start("-machine raspi3b");
-    ret = g_test_run();
-    qtest_end();
-    return ret;
+        qtest_start("-machine raspi3b");
+    }
+    return g_test_run();
 }
-- 
2.39.2

Re: [PATCH 22/22] tests/qtest: skip bcm2835-test if no raspi3b model

[Thomas Huth]

On 03/05/2023 11.12, Alex Bennée wrote:
> We can't assume the machine exists and should gracefully skip the test
> if we haven't built the model. This is ostensibly fixed by
> db2237c459 (tests/qtest: Restrict bcm2835-dma-test to CONFIG_RASPI)
> but I still hit it during my tests.

The problem is likely that you build aarch64-softmmu with the minimal 
config, but still keep arm-softmmu around with the full config? Then 
CONFIG_RASPI will still be set at the meson.build level since it is taken 
from config-all-devices.mak here.

> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>   tests/qtest/bcm2835-dma-test.c | 11 +++++------
>   1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/tests/qtest/bcm2835-dma-test.c b/tests/qtest/bcm2835-dma-test.c
> index 8293d822b9..2e6245e9e2 100644
> --- a/tests/qtest/bcm2835-dma-test.c
> +++ b/tests/qtest/bcm2835-dma-test.c
> @@ -107,12 +107,11 @@ static void bcm2835_dma_test_interrupts(void)
>   
>   int main(int argc, char **argv)
>   {
> -    int ret;
>       g_test_init(&argc, &argv, NULL);
> -    qtest_add_func("/bcm2835/dma/test_interrupts",
> +    if (qtest_has_machine("raspi3b")) {
> +        qtest_add_func("/bcm2835/dma/test_interrupts",
>                      bcm2835_dma_test_interrupts);
> -    qtest_start("-machine raspi3b");
> -    ret = g_test_run();
> -    qtest_end();

Where did the qtest_end() go?

It's maybe cleaner if you move the qtest_start() and qtest_end() calls into 
the bcm2835_dma_test_interrupts() function instead.

  Thomas


> -    return ret;
> +        qtest_start("-machine raspi3b");
> +    }
> +    return g_test_run();
>   }

Re: [PATCH 22/22] tests/qtest: skip bcm2835-test if no raspi3b model

[Alex Bennée]

Thomas Huth <thuth@redhat.com> writes:

> On 03/05/2023 11.12, Alex Bennée wrote:
>> We can't assume the machine exists and should gracefully skip the test
>> if we haven't built the model. This is ostensibly fixed by
>> db2237c459 (tests/qtest: Restrict bcm2835-dma-test to CONFIG_RASPI)
>> but I still hit it during my tests.
>
> The problem is likely that you build aarch64-softmmu with the minimal
> config, but still keep arm-softmmu around with the full config? Then
> CONFIG_RASPI will still be set at the meson.build level since it is
> taken from config-all-devices.mak here.
>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>>   tests/qtest/bcm2835-dma-test.c | 11 +++++------
>>   1 file changed, 5 insertions(+), 6 deletions(-)
>> diff --git a/tests/qtest/bcm2835-dma-test.c
>> b/tests/qtest/bcm2835-dma-test.c
>> index 8293d822b9..2e6245e9e2 100644
>> --- a/tests/qtest/bcm2835-dma-test.c
>> +++ b/tests/qtest/bcm2835-dma-test.c
>> @@ -107,12 +107,11 @@ static void bcm2835_dma_test_interrupts(void)
>>     int main(int argc, char **argv)
>>   {
>> -    int ret;
>>       g_test_init(&argc, &argv, NULL);
>> -    qtest_add_func("/bcm2835/dma/test_interrupts",
>> +    if (qtest_has_machine("raspi3b")) {
>> +        qtest_add_func("/bcm2835/dma/test_interrupts",
>>                      bcm2835_dma_test_interrupts);
>> -    qtest_start("-machine raspi3b");
>> -    ret = g_test_run();
>> -    qtest_end();
>
> Where did the qtest_end() go?

Yeah I dropped it because other tests seem to use the return
g_test_run() pattern. Maybe they are wrong?

>
> It's maybe cleaner if you move the qtest_start() and qtest_end() calls
> into the bcm2835_dma_test_interrupts() function instead.
>
>  Thomas
>
>
>> -    return ret;
>> +        qtest_start("-machine raspi3b");
>> +    }
>> +    return g_test_run();
>>   }


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro