[libvirt PATCH v6 0/8] Add support for 'blob' to virtio video device
by Jonathon Jongsma
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
1 year, 2 months
[PATCH] security: Add support for SUSE edk2 firmware paths
by Jim Fehlig
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
1 year, 2 months
[libvirt PATCH] NEWS: Clarify limitations of passt support
by Andrea Bolognani
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
1 year, 2 months
[PATCH 0/2] Deprecate support for 32-bit x86 and arm hosts
by Thomas Huth
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....
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
1 year, 2 months
[PATCH] NEWS: note new passt feature & bugfix for 9.1.0 release
by Laine Stump
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
1 year, 2 months
[PATCH] NEWS: strongly suggest that <backend type='passt'/> not yet be used in production
by Laine Stump
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 year, 2 months
[PATCH] NEWS: Mention two user-visible bug fixes
by Peter Krempa
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
1 year, 2 months
[PATCH 0/4] qemu: Fix regression wrt virtio-pmem
by Michal Privoznik
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
1 year, 2 months
Re: [PATCH v2 06.5/18] hw/ide/piix: Allow using PIIX3-IDE as standalone PCI function
by Philippe Mathieu-Daudé
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 year, 2 months
EPERM when hot plugging passthrough device to guest after having rebooted libvirt
by Thanos Makatos
On an older, patched libvirt version (8.0.0), I've run into an issue when attempting to hot plug a PCI device via virsh attach-device --live.
To repro:
1. start a guest and hot plug a device (works fine),
2. hot unplug the device
3. restart libvirt
4. attempt to hot plug the same device, it fails with EPERM, e.g.
error: internal error: unable to execute QEMU command 'device_add': vfio 0000:86:01.2: failed to open /dev/vfio/165: Operation not permitted
I'm not yet able to _attempt_ to reproduce on latest master (still working on that), however I've looked at the relevant piece of code and it looks the same so I would expect it to fail the same way.
I've tried to debug this (on libvirt 8.0.0) and see that In qemuSetupHostdevCgroup(), virCgroupHasController() returns 0 since priv->cgroup is NULL. This prevents it from calling virCgroupAllowDevicePath(), hence the failure. priv->cgroup is NULL because it doesn't get initialized in virCgroupV1ValidateMachineGroup():
for (i = 0; i < VIR_CGROUP_CONTROLLER_LAST; i++) {
if (STRNEQ(tmp, name) && ... ) {
VIR_DEBUG("Name '%s' for controller '%s' does not match "
"'%s', '%s', '%s', '%s' or '%s'",
tmp, virCgroupV1ControllerTypeToString(i),
name, machinename, partname,
scopename_old, scopename_new);
return false;
}
I've experimented replacing return false with continue and it works, however I don't know anything about this code so my hack might be completely wrong. Is this behaviour expected or is it a bug?
1 year, 2 months
