[PATCH 0/9] qemu: Move config validation out of qemu_process.c
by Peter Krempa
Some more cleanups for misplaced validation of config that I've noticed
when I was looking for the code validating floppies in my previous
series.
Peter Krempa (9):
qemuDomainValidateStorageSource: Rework protocol validation into a
switch statement
qemu: Move disk backend validation checks from
qemuProcessStartValidateDisks to qemuDomainValidateStorageSource
qemu: block: Drop code for 'vxhs' storage protocol
qemu.conf: Document options for VxHS block network protocol TLS config
as ignored
qemu: conf: Drop handling of 'vxhs' config options
qemu: Move logic from qemuProcessStartValidateShmem to
qemuValidateDomainDeviceDefShmem
qemu: Move checks for number of listening sockets of graphics to
validation code
qemuProcessStartValidateGraphics: Remove redundant checks for RDP
protocol features
qemuProcessStartValidateGraphics: Move RDP validation logic to
qemu_validate.c
src/qemu/libvirtd_qemu.aug | 2 +
src/qemu/qemu.conf.in | 42 +-----------
src/qemu/qemu_block.c | 41 +-----------
src/qemu/qemu_conf.c | 17 -----
src/qemu/qemu_conf.h | 4 --
src/qemu/qemu_domain.c | 112 +++++++++++++++----------------
src/qemu/qemu_process.c | 132 -------------------------------------
src/qemu/qemu_validate.c | 45 ++++++++++++-
tests/qemuxmlconftest.c | 4 --
tests/testutilsqemu.c | 2 -
10 files changed, 101 insertions(+), 300 deletions(-)
--
2.49.0
2 months
[PATCH v2 0/3] CH: Add support for a configuration file and log level configuration
by Stefan Kober
Similar to the qemu.conf file that allows QEMU specific configurations we add
the possibility to specify a ch.conf file for Cloud Hypervisor configuration.
The initial single config option is the log level, which sets the verbosity of
the Cloud Hypervisor process. This allows for simpler debugging when using
Cloud Hypervisor via libvirt.
Stefan Kober (3):
ch: Add config file support
ch: add log level configuration option
NEWS: ch: announce log_level config option
NEWS.rst | 5 +++++
src/ch/ch.conf | 11 ++++++++++
src/ch/ch_conf.c | 31 ++++++++++++++++++++++++++
src/ch/ch_conf.h | 18 +++++++++++++++
src/ch/ch_driver.c | 6 +++++
src/ch/ch_monitor.c | 6 +++++
src/ch/libvirtd_ch.aug | 40 ++++++++++++++++++++++++++++++++++
src/ch/meson.build | 12 ++++++++++
src/ch/test_libvirtd_ch.aug.in | 5 +++++
9 files changed, 134 insertions(+)
create mode 100644 src/ch/ch.conf
create mode 100644 src/ch/libvirtd_ch.aug
create mode 100644 src/ch/test_libvirtd_ch.aug.in
--
2.49.0
2 months
[PATCH v3 0/3] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling
Changelog
v3
- added qemu caps check to avoid breaking s390 guests trying to
default deprecated_features='off' on QEMU versions that
do not support reporting these features
v2
- changed behavior from disabling features on the host model to
instead flagging the guest CPU to disable deprecated features
- removed disabling deprecated features on host model in
virQEMUCapsInitCPUModelS390
- added flagging deprecated_feats in qemuProcessUpdateGuestCPU
- added tests for deprecated_features='on'
- split virQEMUCapsUpdateCPUDeprecatedFeatures update and
qemuProcessUpdateGuestCPU changes
The intention of reporting deprecated features and modifying the guest
CPU model was to alleviate the user from the burden of preparing a guest
with the necessary amendments to assure migration to newer hardware.
While that goal was met by way of the "deprecated_features='on|off'"
attribute, it still adds an extra step that the user must be aware to
prepare a guest for migration and the errors that stem from an
unsuccessful migration (due to feature incompatibility) is not always
clear how to resolve.
These patches make s390 CPU host models migration ready from the get-go
by disabling deprecated features by default. They may still be disabled
for other model types via the respective attribute, or reenabled if
desired.
Collin Walling (3):
qemu: caps: add virCPUFeaturePolicy param to
virQEMUCapsUpdateCPUDeprecatedFeatures
qemu: process: refactor deprecated features code
qemu: process: disable deprecated features for s390 models by default
src/qemu/qemu_capabilities.c | 6 ++--
src/qemu/qemu_capabilities.h | 3 +-
src/qemu/qemu_driver.c | 3 +-
src/qemu/qemu_process.c | 32 ++++++++++++++-----
...l-deprecated-features-on.s390x-latest.args | 32 +++++++++++++++++++
...el-deprecated-features-on.s390x-latest.xml | 25 +++++++++++++++
.../cpu-model-deprecated-features-on.xml | 15 +++++++++
...default-video-type-s390x.s390x-latest.args | 2 +-
...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +-
.../launch-security-s390-pv.s390x-latest.args | 2 +-
...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +-
.../s390-defaultconsole.s390x-latest.args | 2 +-
.../s390-panic.s390x-latest.args | 2 +-
tests/qemuxmlconftest.c | 1 +
14 files changed, 110 insertions(+), 19 deletions(-)
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.args
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.xml
--
2.47.1
2 months
[PATCH 0/4] qemu: Reflect support of floppy devices in capabilities XML
by Peter Krempa
Probe if qemu actually supports floppy controllers which can be compiled
out with custom configs and reflect that in the capability XML.
Peter Krempa (4):
qemu: domain: Introduce qemuDomainMachineSupportsFloppy
qemu: Move floppy device support validation to validation code
qemu: capabilities: Introduce QEMU_CAPS_BUS_FLOPPY
qemuDomainMachineSupportsFloppy: Check for QEMU_CAPS_BUS_FLOPPY
src/qemu/qemu_capabilities.c | 6 ++-
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_domain.c | 15 +++++++
src/qemu/qemu_domain.h | 4 ++
src/qemu/qemu_process.c | 8 ----
src/qemu/qemu_validate.c | 7 +++
.../qemu_10.0.0-virt.aarch64.xml | 2 -
tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 2 -
tests/domaincapsdata/qemu_10.0.0.s390x.xml | 2 -
tests/domaincapsdata/qemu_8.1.0.s390x.xml | 2 -
.../qemu_8.2.0-tcg-virt.loongarch64.xml | 2 -
.../qemu_8.2.0-virt.aarch64.xml | 2 -
.../qemu_8.2.0-virt.loongarch64.xml | 2 -
tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 2 -
tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 2 -
tests/domaincapsdata/qemu_8.2.0.s390x.xml | 2 -
.../qemu_9.1.0-tcg-virt.riscv64.xml | 2 -
.../qemu_9.1.0-virt.riscv64.xml | 2 -
tests/domaincapsdata/qemu_9.1.0.s390x.xml | 2 -
.../qemu_9.2.0-hvf.aarch64+hvf.xml | 2 -
tests/domaincapsdata/qemu_9.2.0.s390x.xml | 2 -
.../caps_10.0.0_ppc64.xml | 1 +
.../caps_10.0.0_x86_64+amdsev.xml | 1 +
.../caps_10.0.0_x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 1 +
.../caps_6.2.0_x86_64.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 +
tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 1 +
.../caps_7.2.0_x86_64+hvf.xml | 1 +
.../caps_7.2.0_x86_64.xml | 1 +
.../caps_8.0.0_x86_64.xml | 1 +
.../caps_8.1.0_x86_64.xml | 1 +
.../caps_8.2.0_x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_9.0.0_sparc.xml | 1 +
.../caps_9.0.0_x86_64.xml | 1 +
.../caps_9.1.0_x86_64.xml | 1 +
.../caps_9.2.0_x86_64+amdsev.xml | 1 +
.../caps_9.2.0_x86_64.xml | 1 +
.../disk-floppy-pseries.ppc64-latest.err | 2 +-
.../disk-floppy-pseries.ppc64-latest.xml | 44 -------------------
tests/qemuxmlconftest.c | 2 +-
44 files changed, 53 insertions(+), 86 deletions(-)
delete mode 100644 tests/qemuxmlconfdata/disk-floppy-pseries.ppc64-latest.xml
--
2.49.0
2 months
[RFC PATCH 0/2] schemas: path types refactor
by Kirill Shchetiniuk
This series of patches aims to introduce unification for path attributes
in schema definitions. Previously defined types used for schema definitions
are now unified into two main types: absolutePath and relativePath.
This change addresses previous inconsistencies where types were sometimes
used incorrectly (e.g., filePath for directory attributes).
Due to prior inconsistencies, some locations now accept relative paths
even if they were not explicitly intended to. To avoid such inconsistencies
in the future, better names for the path types have been selected.
Moreover, I suggest deprecating (with future patches) the use of relative paths
in places where they are not explicitly meant to be used. This will make the
schemas more consistent and, as a result, encourage users to write more
deterministic XML definitions. For now the relativePath is used in such places
to remain backward compatibility.
Kirill Shchetiniuk (2):
schemas: path types unification / refactor
schemas: path attributes type refactor
src/conf/schemas/basictypes.rng | 18 +---
src/conf/schemas/capability.rng | 4 +-
src/conf/schemas/domainbackup.rng | 10 +-
src/conf/schemas/domaincaps.rng | 2 +-
src/conf/schemas/domaincheckpoint.rng | 2 +-
src/conf/schemas/domaincommon.rng | 132 +++++++++++++-------------
src/conf/schemas/domainsnapshot.rng | 8 +-
src/conf/schemas/network.rng | 4 +-
src/conf/schemas/nodedev.rng | 4 +-
src/conf/schemas/secret.rng | 2 +-
src/conf/schemas/storagecommon.rng | 2 +-
src/conf/schemas/storagepool.rng | 10 +-
src/conf/schemas/storagevol.rng | 6 +-
13 files changed, 96 insertions(+), 108 deletions(-)
--
2.49.0
2 months
[PATCH 0/2] CH: Add support for a configuration file and log level configuration
by Stefan Kober
Similar to the qemu.conf file that allows QEMU specific configurations we add
the possibility to specify a ch.conf file for Cloud Hypervisor configuration.
The initial single config option is the log level, which sets the verbosity of
the Cloud Hypervisor process. This allows for simpler debugging when using
Cloud Hypervisor via libvirt.
Stefan Kober (2):
ch: Add config file support
ch: add log level configuration option
src/ch/ch_conf.c | 32 ++++++++++++++++++++++++++++++++
src/ch/ch_conf.h | 18 ++++++++++++++++++
src/ch/ch_driver.c | 6 ++++++
src/ch/ch_monitor.c | 6 ++++++
4 files changed, 62 insertions(+)
--
2.49.0
2 months
[PATCH v2 0/4] domain_capabilities: add console capabilities
by Roman Bogorodskiy
Main change since v1 is adding console capabilities reporting for the
libxl driver.
There's also a minor cosmetic change in the qemu part to alphabetically
sort VIR_DOMAIN_CHR_TYPE_* arguments for VIR_DOMAIN_CAPS_ENUM_SET().
Apparently, the only other driver reporting domain capabilities is the
test driver, so it looks like all drivers are covered by this series.
Roman Bogorodskiy (4):
domain_capabilities: add console capabilities
bhyve: capabilities: report NMDM console
qemu: capabilities: report supported console types
libxl: capabilities: report supported console types
src/bhyve/bhyve_capabilities.c | 5 +++
src/conf/domain_capabilities.c | 12 +++++++
src/conf/domain_capabilities.h | 8 +++++
src/conf/schemas/domaincaps.rng | 10 ++++++
src/libxl/libxl_capabilities.c | 23 ++++++++++++-
src/qemu/qemu_capabilities.c | 32 +++++++++++++++++++
src/qemu/qemu_capabilities.h | 3 ++
tests/domaincapsdata/bhyve_basic.x86_64.xml | 5 +++
tests/domaincapsdata/bhyve_fbuf.x86_64.xml | 5 +++
tests/domaincapsdata/bhyve_uefi.x86_64.xml | 5 +++
tests/domaincapsdata/libxl-xenfv.xml | 13 ++++++++
tests/domaincapsdata/libxl-xenpv.xml | 13 ++++++++
.../qemu_10.0.0-q35.x86_64+amdsev.xml | 18 +++++++++++
.../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 18 +++++++++++
.../qemu_10.0.0-tcg.x86_64+amdsev.xml | 18 +++++++++++
.../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 18 +++++++++++
.../qemu_10.0.0-virt.aarch64.xml | 15 +++++++++
tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 15 +++++++++
tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 16 ++++++++++
tests/domaincapsdata/qemu_10.0.0.s390x.xml | 15 +++++++++
.../qemu_10.0.0.x86_64+amdsev.xml | 18 +++++++++++
tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 15 +++++++++
tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 16 ++++++++++
tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_7.1.0.ppc64.xml | 16 ++++++++++
tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 18 +++++++++++
.../qemu_7.2.0-hvf.x86_64+hvf.xml | 18 +++++++++++
.../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 18 +++++++++++
.../qemu_7.2.0-tcg.x86_64+hvf.xml | 18 +++++++++++
.../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_7.2.0.ppc.xml | 18 +++++++++++
tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_8.1.0.s390x.xml | 15 +++++++++
tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 18 +++++++++++
.../qemu_8.2.0-tcg-virt.loongarch64.xml | 18 +++++++++++
.../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 18 +++++++++++
.../qemu_8.2.0-virt.aarch64.xml | 16 ++++++++++
.../qemu_8.2.0-virt.loongarch64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 16 ++++++++++
tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 18 +++++++++++
tests/domaincapsdata/qemu_8.2.0.s390x.xml | 15 +++++++++
tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_9.0.0.sparc.xml | 18 +++++++++++
tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 18 +++++++++++
.../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 18 +++++++++++
.../qemu_9.1.0-tcg-virt.riscv64.xml | 18 +++++++++++
.../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 18 +++++++++++
.../qemu_9.1.0-virt.riscv64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_9.1.0.s390x.xml | 15 +++++++++
tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 18 +++++++++++
.../qemu_9.2.0-hvf.aarch64+hvf.xml | 16 ++++++++++
.../qemu_9.2.0-q35.x86_64+amdsev.xml | 18 +++++++++++
.../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 18 +++++++++++
.../qemu_9.2.0-tcg.x86_64+amdsev.xml | 18 +++++++++++
.../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 18 +++++++++++
tests/domaincapsdata/qemu_9.2.0.s390x.xml | 15 +++++++++
.../qemu_9.2.0.x86_64+amdsev.xml | 18 +++++++++++
tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 18 +++++++++++
74 files changed, 1213 insertions(+), 1 deletion(-)
--
2.49.0
2 months
[PATCH v3 0/2] Fix virtio console port assignment issue
by Aaron M. Brown
Changelog:
---
v3:
- Added Reviewed-By
- Included CI Results Link
---
v2:
- Split patch into two commits
- Added fixes tag
---
This libvirt patch does the following:
1. fixes an issue with virtio console device port assignment on vioserial buses
2. updates console port reservation comment and changes the allowZero variable to allowPortZero for clarity
Currently in libvirt, a virtio console device cannot be assigned a port number greater than zero on a vioserial bus. This leads to port collision errors when adding more than 1 virtio console device on a single vioserial bus.
After applying this patch, one can add multiple console ports under a single vioserial bus.
Here is a link to CI results for this series: https://gitlab.com/aaronbmalik/libvirt/-/pipelines/1831901334
Aaron M. Brown (2):
Fix virtio console port assignment on vioserial bus
Updates console port reservation comment and changes the allowZero
variable to allowPortZero for clarity
src/conf/domain_addr.c | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
--
2.39.5 (Apple Git-154)
2 months
[PATCH 0/7] nss: Couple of fixes and small improvements
by Michal Privoznik
I've noticed most of these after I've turned on debugging for the NSS
plugin:
diff --git i/tools/nss/libvirt_nss.h w/tools/nss/libvirt_nss.h
index 54a0216013..f9c3136985 100644
--- i/tools/nss/libvirt_nss.h
+++ w/tools/nss/libvirt_nss.h
@@ -35 +35 @@
-#if 0
+#if 1
Michal Prívozník (7):
libvirt_nss_macs: Fix type of @len in findMACsFromJSON()
nss: Add missing includes for gai_strerror()
nss: Declare g_autofree and g_steal_pointer() macros
libvirt_nss: Use automatic memory freeing
libvirt_nss: Drop needless cleanup labels
libvirt_nss: Allocate buffer in ERROR() dynamically
libvirt_nss: Allocate buffer in aiforaf() dynamically
build-aux/syntax-check.mk | 2 +-
tools/nss/libvirt_nss.c | 52 +++++++++++++---------------------
tools/nss/libvirt_nss.h | 33 +++++++++++++++++++--
tools/nss/libvirt_nss_leases.c | 3 ++
tools/nss/libvirt_nss_macs.c | 2 +-
5 files changed, 55 insertions(+), 37 deletions(-)
--
2.49.0
2 months
[PATCH] virsh: Do not print warnings with "error:" prefix
by Jiri Denemark
From: Jiri Denemark <jdenemar(a)redhat.com>
Both vshWarn and vshError are just wrappers around vshPrintStderr which
properly propagates the message level to the log, but fails to honor it
when printing on stderr.
https://issues.redhat.com/browse/RHEL-79460
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
tools/vsh.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/vsh.c b/tools/vsh.c
index 05845e2c1e..e892cbca22 100644
--- a/tools/vsh.c
+++ b/tools/vsh.c
@@ -2123,7 +2123,11 @@ vshPrintStderr(vshControl *ctl,
* printing to stderr will not interleave correctly with stdout
* unless we flush between every transition between streams. */
fflush(stdout);
- fprintf(stderr, _("error: %1$s\n"), NULLSTR(str));
+
+ if (level == VSH_ERR_WARNING)
+ fprintf(stderr, _("warning: %1$s\n"), NULLSTR(str));
+ else
+ fprintf(stderr, _("error: %1$s\n"), NULLSTR(str));
fflush(stderr);
}
--
2.49.0
2 months
