[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
6 days, 5 hours
[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
6 days, 7 hours
[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
6 days, 8 hours
[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)
1 week, 2 days
[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
1 week, 3 days
[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
1 week, 3 days
[PATCH v5 0/5] Adding POWER11 CPU Support
by Narayana Murty N
This patch series introduces the necessary changes to
support the POWER11 CPU and POWER11 host in libvirt.
Additionally, it updates the QEMU capabilities with
the latest QEMU version v10.0.0 to include power11
in the capabilities tests.During testing of v2 patches
found a bug in qemu which sets wrong default cpu for
pre-9.0 machines, that was fixed in qemu v10.0.0.
Patch Summary:
Patch 0001: tests: Pin pseries-2.7 tests to the version 7.0.
Patch 0002: Fix: qemuhotplugtest Set the cpu version at source as POWER9.
Patch 0003: Add capabilities test support for QEMU 10.0.0 on PPC64.
Patch 0004: Add POWER11 CPU model support.
Patch 0005: Add POWER11 host model support.
The corresponding patches for the Linux kernel and QEMU
are already upstream. Relevant links are provided below:
Linux kernel patches:
1. Linux P11 support: commit c2ed087ed35c ("powerpc: Add Power11 architected and raw mode")
2. Linux P11 KVM support: commit 96e266e3bcd6 ("KVM: PPC: Book3S HV: Add Power11 capability support for Nested PAPR guests")
Qemu patches:
3. Qemu P11 support: commit 273db89bcaf4 ("ppc/pseries: Add Power11 cpu type")
4. Qemu P11 DD02.0 support: commit c0d964076c3e ("target/ppc: Add Power11 DD2.0 processor")
5. Qemu pre-9.0 pseries michines changing default cpu with Qemu commit 1490d0bcdfcb ("ppc/spapr: fix default cpu for pre-9.0 machines.").
Note on CPU model naming:
From the discussion in the community thread
(https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/IC...),
we will continue using the uppercase only for POWER11 for the CPU model name.
This is consistent with the naming convention used for existing POWER models
(e.g., POWER9, POWER10) in libvirt's CPU map and avoids compatibility issues
with existing tooling and test expectations.
Signed-off-by: Narayana Murty N <nnmlinux(a)linux.ibm.com>
----
Changelog:
-V4: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/IC...
*Continue to use POWER11 in uppercase, following feedback.
*Test data caps_10.0.0.ppc64.replies generated with QEMU v10.0.0.
-V3: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/PG...
*Rebased to top of the tree as I saw some tests were failing with
recent commits.
-V2:https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/JQ5UJFWJG35OFX54RQIDHFUSX3RIYIYP/?sort=thread
*Instead of removing pseries-2.7 related tests, they are now pinned to the latest available capabilities version 7.0.0.
*patch0003: description explained why the cpu version changed.
*change the cpu model name to lower case.
*Fixing the hotplugtest by setting the cpu version at source as POWER9
*default CPU change for pseries machines preior to pseries-9.0 tests cases for tcg fixed.
* Fixing the compat models check for host CPU names in both lowercase and uppercase.
-V1:https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/4A3IND2QP5CE654XE755ICRZKLUNYXAE/
*Addressed v2 patch readability issues.
Narayana Murty N (5):
tests: Pin pseries-2.7 tests to the version 7.0
tests: qemuhotplugtest: Set the cpu version at source for PPC64 tests
tests: Add capabilities for QEMU 10.0.0 on ppc64
cpu_map: Add POWER11 CPU model support
cpu_ppc64: Add POWER11 host-model support
src/cpu/cpu_ppc64.c | 8 +-
src/cpu_map/index.xml | 1 +
src/cpu_map/meson.build | 1 +
src/cpu_map/ppc64_POWER11.xml | 6 +
tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 191 +
.../caps_10.0.0_ppc64.replies | 39513 ++++++++++++++++
.../caps_10.0.0_ppc64.xml | 1088 +
.../ppc64-modern-bulk-domain.xml | 3 +-
.../ppc64-modern-individual-domain.xml | 3 +-
.../disk-floppy-pseries.ppc64-latest.xml | 2 +-
.../memory-hotplug-nvdimm-ppc64.xml | 3 +-
.../memory-hotplug-ppc64-nonuma.xml | 3 +
.../panic-pseries.ppc64-latest.args | 2 +-
.../panic-pseries.ppc64-latest.xml | 2 +-
...ault-cpu-kvm-pseries-2.7.ppc64-7.0.0.args} | 0
...fault-cpu-kvm-pseries-2.7.ppc64-7.0.0.xml} | 0
...ault-cpu-kvm-pseries-3.1.ppc64-latest.args | 2 +-
...fault-cpu-kvm-pseries-3.1.ppc64-latest.xml | 2 +-
...ault-cpu-kvm-pseries-4.2.ppc64-latest.args | 2 +-
...fault-cpu-kvm-pseries-4.2.ppc64-latest.xml | 2 +-
...ault-cpu-tcg-pseries-2.7.ppc64-7.0.0.args} | 0
...fault-cpu-tcg-pseries-2.7.ppc64-7.0.0.xml} | 0
...efault-models.ppc64-latest.abi-update.args | 4 +-
...default-models.ppc64-latest.abi-update.xml | 2 +-
...4-pseries-default-models.ppc64-latest.args | 4 +-
...64-pseries-default-models.ppc64-latest.xml | 2 +-
.../ppc64-pseries-graphics.ppc64-latest.args | 4 +-
.../ppc64-pseries-graphics.ppc64-latest.xml | 2 +-
.../ppc64-pseries-headless.ppc64-latest.args | 4 +-
.../ppc64-pseries-headless.ppc64-latest.xml | 2 +-
...eries-minimal.ppc64-latest.abi-update.args | 2 +-
...series-minimal.ppc64-latest.abi-update.xml | 2 +-
.../ppc64-pseries-minimal.ppc64-latest.args | 2 +-
.../ppc64-pseries-minimal.ppc64-latest.xml | 2 +-
.../ppc64-tpmproxy-single.ppc64-latest.args | 2 +-
.../ppc64-tpmproxy-single.ppc64-latest.xml | 2 +-
.../ppc64-tpmproxy-with-tpm.ppc64-latest.args | 2 +-
.../ppc64-tpmproxy-with-tpm.ppc64-latest.xml | 2 +-
.../pseries-basic.ppc64-latest.args | 2 +-
.../pseries-basic.ppc64-latest.xml | 2 +-
.../pseries-console-virtio.ppc64-latest.args | 2 +-
.../pseries-console-virtio.ppc64-latest.xml | 2 +-
...eries-cpu-compat-power11.ppc64-latest.args | 31 +
...series-cpu-compat-power11.ppc64-latest.err | 1 +
...series-cpu-compat-power11.ppc64-latest.xml | 29 +
.../pseries-cpu-compat-power11.xml | 19 +
.../pseries-cpu-le.ppc64-latest.args | 2 +-
.../pseries-cpu-le.ppc64-latest.xml | 2 +-
.../pseries-features.ppc64-latest.args | 2 +-
.../pseries-features.ppc64-latest.xml | 2 +-
.../pseries-hostdevs-1.ppc64-latest.args | 2 +-
.../pseries-hostdevs-1.ppc64-latest.xml | 2 +-
.../pseries-hostdevs-2.ppc64-latest.args | 2 +-
.../pseries-hostdevs-2.ppc64-latest.xml | 2 +-
.../pseries-hostdevs-3.ppc64-latest.args | 2 +-
.../pseries-hostdevs-3.ppc64-latest.xml | 2 +-
.../pseries-many-buses-1.ppc64-latest.args | 2 +-
.../pseries-many-buses-1.ppc64-latest.xml | 2 +-
.../pseries-many-buses-2.ppc64-latest.args | 2 +-
.../pseries-many-buses-2.ppc64-latest.xml | 2 +-
.../pseries-many-devices.ppc64-latest.args | 2 +-
.../pseries-many-devices.ppc64-latest.xml | 2 +-
.../pseries-nvram.ppc64-latest.args | 2 +-
.../pseries-nvram.ppc64-latest.xml | 2 +-
.../pseries-panic-missing.ppc64-latest.args | 2 +-
.../pseries-panic-missing.ppc64-latest.xml | 2 +-
...pseries-panic-no-address.ppc64-latest.args | 2 +-
.../pseries-panic-no-address.ppc64-latest.xml | 2 +-
...ries-phb-default-missing.ppc64-latest.args | 2 +-
...eries-phb-default-missing.ppc64-latest.xml | 2 +-
.../pseries-phb-numa-node.ppc64-latest.args | 2 +-
.../pseries-phb-numa-node.ppc64-latest.xml | 2 +-
.../pseries-phb-simple.ppc64-latest.args | 6 +-
.../pseries-phb-simple.ppc64-latest.xml | 2 +-
.../pseries-phb-user-alias.ppc64-latest.args | 6 +-
.../pseries-phb-user-alias.ppc64-latest.xml | 2 +-
.../pseries-serial-native.ppc64-latest.args | 2 +-
.../pseries-serial-native.ppc64-latest.xml | 2 +-
.../pseries-serial-pci.ppc64-latest.args | 2 +-
.../pseries-serial-pci.ppc64-latest.xml | 2 +-
.../pseries-serial-usb.ppc64-latest.args | 2 +-
.../pseries-serial-usb.ppc64-latest.xml | 2 +-
.../pseries-usb-default.ppc64-latest.args | 2 +-
.../pseries-usb-default.ppc64-latest.xml | 2 +-
.../pseries-usb-kbd.ppc64-latest.args | 2 +-
.../pseries-usb-kbd.ppc64-latest.xml | 2 +-
.../pseries-usb-multi.ppc64-latest.args | 2 +-
.../pseries-usb-multi.ppc64-latest.xml | 2 +-
...series-vio-user-assigned.ppc64-latest.args | 7 +-
...pseries-vio-user-assigned.ppc64-latest.xml | 2 +-
.../pseries-vio.ppc64-latest.args | 7 +-
.../pseries-vio.ppc64-latest.xml | 2 +-
...fault-pseries.ppc64-latest.abi-update.args | 2 +-
...efault-pseries.ppc64-latest.abi-update.xml | 2 +-
...ntroller-default-pseries.ppc64-latest.args | 2 +-
...ontroller-default-pseries.ppc64-latest.xml | 2 +-
...fault-unavailable-pseries.ppc64-latest.xml | 2 +-
tests/qemuxmlconftest.c | 8 +-
tests/testutilshostcpus.h | 11 +
tests/testutilsqemu.c | 4 +
tests/testutilsqemu.h | 1 +
101 files changed, 41005 insertions(+), 101 deletions(-)
create mode 100644 src/cpu_map/ppc64_POWER11.xml
create mode 100644 tests/domaincapsdata/qemu_10.0.0.ppc64.xml
create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_ppc64.replies
create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_ppc64.xml
rename tests/qemuxmlconfdata/{ppc64-default-cpu-kvm-pseries-2.7.ppc64-latest.args => ppc64-default-cpu-kvm-pseries-2.7.ppc64-7.0.0.args} (100%)
rename tests/qemuxmlconfdata/{ppc64-default-cpu-kvm-pseries-2.7.ppc64-latest.xml => ppc64-default-cpu-kvm-pseries-2.7.ppc64-7.0.0.xml} (100%)
rename tests/qemuxmlconfdata/{ppc64-default-cpu-tcg-pseries-2.7.ppc64-latest.args => ppc64-default-cpu-tcg-pseries-2.7.ppc64-7.0.0.args} (100%)
rename tests/qemuxmlconfdata/{ppc64-default-cpu-tcg-pseries-2.7.ppc64-latest.xml => ppc64-default-cpu-tcg-pseries-2.7.ppc64-7.0.0.xml} (100%)
create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.args
create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.err
create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.xml
create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.xml
--
2.48.1
1 week, 3 days
[PATCH] docs: domain: Explain supported options of 'error_policy'
by Peter Krempa
From: Peter Krempa <pkrempa(a)redhat.com>
Explain what the individual settings actually result in. The changes
are based on the paraprhase of qemu documentation which in
'qemu-options.hx' states:
``werror=action,rerror=action``
Specify which action to take on write and read errors. Valid
actions are: "ignore" (ignore the error and try to continue),
"stop" (pause QEMU), "report" (report the error to the guest),
"enospc" (pause QEMU only if the host disk is full; report the
error to the guest otherwise). The default setting is
``werror=enospc`` and ``rerror=report``.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/138
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
docs/formatdomain.rst | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index c7c75ae219..a23a746229 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -3451,8 +3451,12 @@ paravirtualized driver is specified via the ``disk`` element.
and sync requests from guest are ignored).
:since:`Since 0.6.0`
- The optional ``error_policy`` attribute controls how the hypervisor will
- behave on a disk read or write error, possible values are "stop",
- "report" (:since:`since 0.9.7`), "ignore", and "enospace".
+ behave on a disk read or write error, possible values are ``stop`` (
+ suspend/pause the domain on error), ``report`` (report the error to the
+ guest OS; :since:`since 0.9.7`), ``ignore`` (ignore the error and try to
+ continue), and ``enospace`` (suspend/pause the domain only if host storage
+ is full; report the error to the guest OS otherwise).
+
The default is left to the discretion of the hypervisor.
:since:`Since 0.8.0`.
- The optional ``rerror_policy`` attribute controls behavior for read
--
2.49.0
1 week, 3 days
[PATCH v2 0/3] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling
Changelog
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 | 30 ++++++++++++-----
...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, 108 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
1 week, 3 days
RFC: schemas: resolving path type inconsistency in XML schemas
by Kirill Shchetiniuk
Hello everyone,
Sometime ago I sent a patch changing the XML schema to add GTK support for libvirt. As the type for one path argument, I used the <text/> type, simply copying the similar approach from another place in the XML schema definition. I was told that it's not the best way to use the <text/> type for paths and that absFilePath, a defined basic type for paths, should be used instead.
After this, I decided to fix this in a place where I had seen the same approach, too. After further investigation, I found a lot more places where the <text/> type is used for paths. Moreover, I found out that we have at least 4 type definitions for paths (files and directories). Some of these types accept simply everything, others paths starting with "/" or even Windows-style disk names.
<define name="filePath">
<data type="string">
<param name="pattern">.+</param>
</data>
</define>
<define name="dirPath">
<data type="string">
<param name="pattern">.+</param>
</data>
</define>
<define name="absFilePath">
<data type="string">
<param name="pattern">(/|[a-zA-Z]:\\).+</param>
</data>
</define>
<define name="absDirPath">
<data type="string">
<param name="pattern">/.*</param>
</data>
</define>
According to this, I have the following questions:
1. Do we allow users to use relative paths, or MUST all paths be absolute?
2. Do we have to accept Windows-style paths everywhere?
3. Do we need to have different types for directories? For example, in some places, the filePath type is used for directory parameters.
And as a last question, do we want to unify the basic types related to paths to maintain the schemas more consistent?
Kirill
1 week, 4 days
