| Message ID | 20230503091244.1450613-6-alex.bennee@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | testing/next: cirrus, docker, docs, ci, configs, gitlab | expand |
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~
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
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.
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.
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
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
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
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
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
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.
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. > >
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
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
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
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
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
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
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