February 2023 - Devel - libvirt List Archives

[PATCH 0/4] qemu: Let virCommand report errors
by Michal Privoznik 03 Mar '23

03 Mar '23

In a lot of places we catch errors from qemuSecurityCommandRun() only to produce an error report. But we can let virCommand module do the same. Michal Prívozník (4): qemu_slirp: Don't set errfd when starting slirp helper qemu: Don't overwrite error from qemuSecurityCommandRun() qemu: Drop @cmdret argument from qemuSecurityCommandRun() qemu: Let virCommand module translate exitstatus src/qemu/qemu_dbus.c | 11 +---------- src/qemu/qemu_passt.c | 12 +----------- src/qemu/qemu_security.c | 13 ++++++------- src/qemu/qemu_security.h | 3 +-- src/qemu/qemu_slirp.c | 12 +----------- src/qemu/qemu_tpm.c | 9 +-------- src/qemu/qemu_vhost_user_gpu.c | 11 ++--------- 7 files changed, 13 insertions(+), 58 deletions(-) -- 2.39.2

2 6

[libvirt PATCH v6 0/8] Add support for 'blob' to virtio video device
by Jonathon Jongsma 03 Mar '23

03 Mar '23

Add support to libvirt for the 'blob' option for virtio video devices in qemu. Also do a little preparatory refactoring of the video device xml parsing code. This series was basically acked by Jan some time ago, but I made a couple changes and apparently I dropped the ball and forgot to send out the revised series. So here's a v6 after rebasing yet again to current master. changes in v6: - added two new patches: - conf: explicitly set VIR_DOMAIN_VIDEO_TYPE_DEFAULT to 0 - util: add virXMLPropUIntDefault() function - other minor fixes from Jan's review Jonathon Jongsma (8): conf: explicitly set VIR_DOMAIN_VIDEO_TYPE_DEFAULT to 0 conf: Refactor video model parsing util: add virXMLPropUIntDefault() function conf: switch to virXMLProp* functions for parsing video conf: use enum variable for video type conf: add support for 'blob' in virtio video device qemu: Add capability for virtio-gpu.blob qemu: Implement 'blob' support for virtio gpu docs/formatdomain.rst | 7 + src/conf/cpu_conf.c | 9 +- src/conf/domain_conf.c | 134 ++++++++---------- src/conf/domain_conf.h | 5 +- src/conf/domain_validate.c | 13 +- src/conf/numa_conf.c | 7 +- src/conf/schemas/domaincommon.rng | 5 + src/libxl/libxl_conf.c | 10 ++ src/libxl/libxl_domain.c | 11 ++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 22 ++- src/qemu/qemu_command.c | 3 + src/qemu/qemu_domain.h | 1 + src/qemu/qemu_monitor_json.c | 16 ++- src/qemu/qemu_namespace.c | 22 +++ src/qemu/qemu_process.c | 7 + src/qemu/qemu_validate.c | 9 ++ src/util/virxml.c | 29 +++- src/util/virxml.h | 9 ++ .../caps_6.1.0.x86_64.xml | 1 + .../caps_6.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 + .../caps_6.2.0.x86_64.xml | 1 + .../caps_7.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 1 + .../caps_7.0.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_7.1.0.ppc64.xml | 1 + .../caps_7.1.0.x86_64.xml | 1 + .../caps_7.2.0.x86_64.xml | 1 + .../caps_8.0.0.riscv64.xml | 1 + .../caps_8.0.0.x86_64.xml | 1 + .../video-virtio-blob-off.x86_64-latest.args | 39 +++++ .../video-virtio-blob-off.xml | 36 +++++ .../video-virtio-blob-on.x86_64-latest.args | 39 +++++ .../qemuxml2argvdata/video-virtio-blob-on.xml | 36 +++++ tests/qemuxml2argvtest.c | 2 + .../video-virtio-blob-off.x86_64-latest.xml | 48 +++++++ .../video-virtio-blob-on.x86_64-latest.xml | 48 +++++++ tests/qemuxml2xmltest.c | 2 + 40 files changed, 483 insertions(+), 101 deletions(-) create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-off.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-off.xml create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-on.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-on.xml create mode 100644 tests/qemuxml2xmloutdata/video-virtio-blob-off.x86_64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/video-virtio-blob-on.x86_64-latest.xml -- 2.39.0

2 10

[PATCH] security: Add support for SUSE edk2 firmware paths
by Jim Fehlig 03 Mar '23

03 Mar '23

SUSE installs edk2 firmwares for both x86_64 and aarch64 in /usr/share/qemu. Add support for this path in virt-aa-helper and allow locking files within the path in the libvirt qemu abstraction. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- FYI, I'm fine maintaining this patch downstream if such distro-specific change is unwanted upstream. I've already maintained the virt-aa-helper hunk for several years. src/security/apparmor/libvirt-qemu | 2 +- src/security/virt-aa-helper.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/src/security/apparmor/libvirt-qemu b/src/security/apparmor/libvirt-qemu index d0289b8943..9af1333b22 100644 --- a/src/security/apparmor/libvirt-qemu +++ b/src/security/apparmor/libvirt-qemu @@ -91,7 +91,7 @@ /usr/share/proll/** r, /usr/share/qemu-efi/** r, /usr/share/qemu-kvm/** r, - /usr/share/qemu/** r, + /usr/share/qemu/** rk, /usr/share/seabios/** r, /usr/share/sgabios/** r, /usr/share/slof/** r, diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index f6c9703db6..d65d459850 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -481,6 +481,7 @@ valid_path(const char *path, const bool readonly) "/usr/share/AAVMF/", /* for AAVMF images */ "/usr/share/qemu-efi/", /* for AAVMF images */ "/usr/share/qemu-efi-aarch64/", /* for AAVMF images */ + "/usr/share/qemu/", /* SUSE path for OVMF and AAVMF images */ "/usr/lib/u-boot/", /* u-boot loaders for qemu */ "/usr/lib/riscv64-linux-gnu/opensbi" /* RISC-V SBI implementation */ }; -- 2.39.2

3 3

[libvirt PATCH] NEWS: Clarify limitations of passt support
by Andrea Bolognani 01 Mar '23

01 Mar '23

Let users know that we're working on lifting the limitations and that they should not use the feature in production until then. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- NEWS.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/NEWS.rst b/NEWS.rst index 683c147af0..b19c75ceac 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -79,7 +79,9 @@ v9.1.0 (unreleased) connectivity. (NB: On systems that use them, it is still necessary to disable - SELinux/AppArmor to start passt.) + SELinux/AppArmor to start passt. This is a temporary limitation, + and use of the feature in production is strongly discouraged + until it has been lifted.) * qemu: Fix error when attempting to change media in a CDROM drive -- 2.39.2

2 2

[PATCH 0/2] Deprecate support for 32-bit x86 and arm hosts
by Thomas Huth 01 Mar '23

01 Mar '23

We're struggling quite badly with our CI minutes on the shared gitlab runners, so we urgently need to think of ways to cut down our supported build and target environments. qemu-system-i386 and qemu-system-arm are not really required anymore, since nobody uses KVM on the corresponding systems for production anymore, and the -x86_64 and -arch64 variants are a proper superset of those binaries. So it's time to deprecate them and the corresponding 32-bit host environments now. This is a follow-up patch series from the previous discussion here: https://lore.kernel.org/qemu-devel/20230130114428.1297295-1-thuth@redhat.co… where people still mentioned that there is still interest in certain support for 32-bit host hardware. But as far as I could see, there is no real need for 32-bit host support for system emulation on x86 and arm anymore, so it should be fine if we drop these host environments now (these are also the two architectures that contribute the most to the long test times in our CI, so we would benefit a lot by dropping those). Thomas Huth (2): docs/about: Deprecate 32-bit x86 hosts and qemu-system-i386 docs/about: Deprecate 32-bit arm hosts and qemu-system-arm docs/about/deprecated.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) -- 2.31.1

7 36

[PATCH] NEWS: note new passt feature & bugfix for 9.1.0 release
by Laine Stump 01 Mar '23

01 Mar '23

At Stefano's suggestion, this also adds a sentence pointing out that SELinux must be disabled in order for passt support to work. I didn't think to put this info in the NEWS file last month. Signed-off-by: Laine Stump <laine(a)redhat.com> --- I've noticed that in some places, QEMU related points are marked with "QEMU:" and in other places they are marked with "qemu:". In the 9.1.0 sections, the new features all use "qemu:" while the bugfixes all use "QEMU:". I just went along with the flow in both cases, but we should probably do a patch to standardize on one or the other (and then try to stick to it). So which is more appropriate? using the capitalization the way the QEMU project prefers it? Or the capitalization the way the subdirectory in libvirt is named? NEWS.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 1180d75310..df613abc69 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -38,6 +38,13 @@ v9.1.0 (unreleased) A pvpanic device can be now defined as a PCI device (the original is an ISA device) with ``<panic model='pvpanic'/>``. + * qemu: support automatic restart of inadvertantly terminated passt process + + If the passt process that is serving as the backend of a -netdev + stream is terminated unexpectedly, libvirt now listens to QEMU's + notification of this, and starts up a new passt instance, thus + preserving network connectivity. + * **Improvements** * RPM packaging changes @@ -63,6 +70,15 @@ v9.1.0 (unreleased) snapshot when it existed. In addition when external memory only snapshot was created libvirt failed without producing any error. + * QEMU: properly report passt startup errors + + Due to how the child passt process was started, the initial + support for passt (added in 9.0.0) would not see errors + encountered during startup, so libvirt would continue to setup and + start the guest; this led to a running guest with no network + connectivity. This issue has be corrected. + + (NB: it is still necessary to disable SELinux to start passt.) v9.0.0 (2023-01-16) =================== -- 2.39.2

4 6

[PATCH] NEWS: strongly suggest that <backend type='passt'/> not yet be used in production
by Laine Stump 01 Mar '23

01 Mar '23

Based on Stefano's suggestion that the NEWS should not seem to encourage disabling SELinux or AppArmor (which is a valid point) this replaces the "you need to disable SELinux/AppArmor" note with a "please do not use in production because that will require disabling SELinux/AppArmor". Signed-off-by: Laine Stump <laine(a)redhat.com> --- If this change seems okay, anyone who ACKs please push it so that it's in place before Jiri cuts the release (I may not yet be awake at that time of day). NEWS.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/NEWS.rst b/NEWS.rst index af7a3b2c76..b9fe73a747 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -78,8 +78,10 @@ v9.1.0 (unreleased) start the guest; this led to a running guest with no network connectivity. - (NB: On systems that use them, it is still necessary to disable - SELinux/AppArmor to start passt.) + (NB: Please do not use <backend type='passt'/> on production + systems with Linux Security Modules as it currently requires + setting SELinux to permissive mode or disabling selected AppArmor + profiles) v9.0.0 (2023-01-16) -- 2.39.2

1 0

[PATCH] NEWS: Mention two user-visible bug fixes
by Peter Krempa 01 Mar '23

01 Mar '23

Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- NEWS.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index d1f88b3d59..ca93c24150 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -80,6 +80,18 @@ v9.1.0 (unreleased) (NB: it is still necessary to disable SELinux to start passt.) + * qemu: Fix error when attempting to change media in a CDROM drive + + Due to a logic bug introduced in libvirt-9.0 attempts to change media in a + CDROM would previously fail with an error stating that the tray isn't open. + + * qemu: Properly handle block job transitions + + Starting with libvirt-9.0 the block job state machine improperly handled + some job transitions which resulted into some block jobs not being properly + terminated. This could cause problems such as errors when detaching a disk + after snapshot. + v9.0.0 (2023-01-16) =================== -- 2.39.2

2 1

[PATCH 0/4] qemu: Fix regression wrt virtio-pmem
by Michal Privoznik 28 Feb '23

28 Feb '23

The first one fixes a regression in which we're unable to start a domain with a virtio-pmem device. It should go into the release. The rest is just a cleanup because the function in question started looking disarranged. Michal Prívozník (4): qemu: Don't error out on 'unknown' memory model in qemuMonitorJSONGetMemoryDeviceInfo() libvirt_private.syms: Export virDomainMemoryModelTypeFromString() qemu_monitor: Switch to virDomainMemoryModel enum in qemuMonitorJSONGetMemoryDeviceInfo() qemu_monitor: Decouple switch()-es in qemuMonitorJSONGetMemoryDeviceInfo() src/libvirt_private.syms | 1 + src/qemu/qemu_monitor_json.c | 124 +++++++++++++++++++---------------- 2 files changed, 67 insertions(+), 58 deletions(-) -- 2.39.2

3 9

Re: [PATCH v2 06.5/18] hw/ide/piix: Allow using PIIX3-IDE as standalone PCI function
by Philippe Mathieu-Daudé 28 Feb '23

28 Feb '23

On 20/2/23 10:10, Gerd Hoffmann wrote: > On Mon, Feb 20, 2023 at 09:00:44AM +0100, Philippe Mathieu-Daudé wrote: >> In order to allow Frankenstein uses such plugging a PIIX3 >> IDE function on a ICH9 chipset (which already exposes AHCI >> ports...) as: >> >> $ qemu-system-x86_64 -M q35 -device piix3-ide >> >> add a kludge to automatically wires the IDE IRQs on an ISA >> bus exposed by a PCI-to-ISA bridge (usually function #0). >> Restrict this kludge to the PIIX3. > > Well. On physical hardware you have a config switch in the bios > setup which turns off sata and enables ide instead (i.e. the > chipset implements both and can be configured to expose the one > or the other). > > If we want support ide for q35 we should IMHO do something simliar > instead of making piix-ide user-pluggable. We already have -machine > q35,sata={on,off}. We could extend that somehow, by adding > ide={on,off}, or by using storage={sata,ide,off} instead. > > This has been discussed now and then in the past and the usual > conclusion was that there is little reason to implement that given > that you can just use the 'pc' machine type. For guests that old > that they can't handle sata storage this is usually the better fit > anyway ... I think we might not using the same words, but agree on the goal :) Since this has been discussed in the past, I suppose some users want this config available. Why are they using this convoluted config? Could it be due to lack of good documentation? Do we really need a storage={sata,ide,off} flag? I don't see its value. Help cloud users to have a sane config? (old) boards exist with both IDE/SATA and we might want to emulate some of them, but IMO such boards should be well modeled (Either in C or later in declarative language) but not automagically created from CLI. IOW: - using PIIX on Q35 (or any machine exposing a PCI bus) is acceptable, but the chipset should be instantiated as a whole. So to be clear I'm not against "-M q35 -device piix3", we should keep that working. - we shouldn't try to maintain such Frankenstein corner cases which force us to add complex hacks, hard to remove, which limit us in implementing new features and cost us a lot of maintenance / testing time. So I propose we deprecate this config so we can keep going forward. (More generally I'd like to not allow instantiating part of chipset).

1 1