[PATCH 0/3] qemu: fix validation of 'fd' passing for backup job and improve debugability of passed FDs
by Peter Krempa
Peter Krempa (3):
qemuBackupPrepare: Actually allow 'VIR_STORAGE_NET_HOST_TRANS_FD'
docs: backup: Hint at proper selinux labelling of the FD-passed NBD
socket
qemu: fd: Log information about passed file descriptor
docs/formatbackup.rst | 4 +++
src/qemu/qemu_backup.c | 4 ++-
src/qemu/qemu_fd.c | 62 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 69 insertions(+), 1 deletion(-)
--
2.49.0
1 week, 5 days
[PATCH v1 0/2] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling
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 (2):
qemu: caps: add virCPUFeaturePolicy param to
virQEMUCapsUpdateCPUDeprecatedFeatures
qemu: caps: disable deprecated features for s390 models by default
src/qemu/qemu_capabilities.c | 10 +++++++---
src/qemu/qemu_capabilities.h | 3 ++-
src/qemu/qemu_driver.c | 3 ++-
src/qemu/qemu_process.c | 19 ++++++++++++-------
tests/domaincapsdata/qemu_10.0.0.s390x.xml | 8 ++++----
tests/domaincapsdata/qemu_9.1.0.s390x.xml | 8 ++++----
tests/domaincapsdata/qemu_9.2.0.s390x.xml | 8 ++++----
...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 +-
13 files changed, 41 insertions(+), 30 deletions(-)
--
2.47.1
1 week, 5 days
[libvirt PATCH 0/2] Remove 'inline' keyword from C files
by Ján Tomko
Ján Tomko (2):
build: prohibit inline functions in C files by syntax-check
build: do not use -Winline
build-aux/syntax-check.mk | 10 ++++++++++
meson.build | 6 ------
src/hyperv/hyperv_wmi.c | 2 +-
src/locking/lock_daemon.c | 4 ++--
src/qemu/qemu_block.c | 2 +-
src/qemu/qemu_command.c | 2 +-
src/qemu/qemu_saveimage.c | 2 +-
src/rpc/virnetserver.c | 8 ++++----
src/storage/storage_util.c | 4 ++--
src/util/virhashcode.c | 4 ++--
src/util/virthreadpool.c | 2 +-
src/util/virxml.c | 2 +-
tools/nss/libvirt_nss.c | 2 +-
13 files changed, 27 insertions(+), 23 deletions(-)
--
2.49.0
1 week, 6 days
[PATCH 0/1] virsh: Add option '--no-pkttyagent'
by Jens Schmidt
As discussed in https://gitlab.com/libvirt/libvirt/-/issues/757.
I'm not quite sure about using a long-only-option, since that's
a first in virsh. But OTOH this option seems too insignificant
to also use one of the precious short option characters for it.
Please check and let me know what you think.
Thanks!
Jens Schmidt (1):
virsh: Add option '--no-pkttyagent'
NEWS.rst | 4 ++++
docs/manpages/virsh.rst | 8 ++++++++
tools/virsh.c | 13 ++++++++++++-
tools/vsh.h | 1 +
4 files changed, 25 insertions(+), 1 deletion(-)
--
2.39.5
1 week, 6 days
[PATCH v3 0/3] Add virt machine support for configuring PCI high memory MMIO size
by Matthew R. Ochs
This patch series adds support for configuring the PCI high memory MMIO
window size for aarch64 virt machine types using the highmem-mmio-size
feature introduced in QEMU v10.0.0 [1]. It allows users to configure the
size of the high memory MMIO window above 4GB, which can be required to
support PCI passthrough with devices that have a large BARs.
The feature is exposed through the existing pcihole64 element associated
with the PCIe root controller:
<controller type='pci' index='0' model='pcie-root'>
<pcihole64 unit='GiB'>512</pcihole64>
</controller>
This existing schema supports the same semantics for the QEMU PC
machine pci-hole64-size parameter and is a natural fit for supporting
the highmem-mmio-size feature on the aarch64 virt machine.
This series is applied over master and depends on the recently merged
patch [2] that added support for QEMU v10.0.0 aarch64 capabilities.
For your convenience, this series is also available on Github [3].
[1] https://github.com/qemu/qemu/commit/f10104aeae3a17f181d5bb37b7fd7dad7fe86cba
[2] https://github.com/nvmochs/libvirt/commit/cea2ee1d28780808172911e5c586478...
[3] git fetch https://github.com/nvmochs/libvirt.git pci_highmem_mmio_size_pcihole64
Signed-off-by: Matthew R. Ochs <mochs(a)nvidia.com>
Changelog:
v3
- Patch 2 updates:
+ Use positive check in qemuBuildGlobalControllerCommandLine
+ Only allow pcihole64 for PCIe root controllers with arm virt
- Added review tags from Daniel P. Berrangé for patch 1 and 3
v2
- Use existing XML scmhema (pcihole64 element) instead of a new one
Matthew R. Ochs (3):
qemu: Add capability for PCI high memory MMIO size
qemu: Add command line support for PCI high memory MMIO size
tests: Add pcihole64 test for virt machine
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 14 ++++++++-
src/qemu/qemu_validate.c | 4 ++-
.../caps_10.0.0_aarch64.xml | 1 +
.../pcihole64-virt.aarch64-latest.args | 31 +++++++++++++++++++
.../pcihole64-virt.aarch64-latest.xml | 29 +++++++++++++++++
tests/qemuxmlconfdata/pcihole64-virt.xml | 17 ++++++++++
tests/qemuxmlconftest.c | 1 +
9 files changed, 98 insertions(+), 2 deletions(-)
create mode 100644 tests/qemuxmlconfdata/pcihole64-virt.aarch64-latest.args
create mode 100644 tests/qemuxmlconfdata/pcihole64-virt.aarch64-latest.xml
create mode 100644 tests/qemuxmlconfdata/pcihole64-virt.xml
--
2.46.0
2 weeks, 2 days
[PATCH] cpu_x86: Do not inline cpuidCall()
by Fabio Estevam
The following build error is observed with DEBUG_BUILD = 1:
src/cpu/cpu_x86.c: In function 'cpuidSetLeaf4':
src/cpu/cpu_x86.c:2563:1: error: inlining failed in call to 'cpuidCall': function not considered for inlining [-Werror=inline]
2563 | cpuidCall(virCPUx86CPUID *cpuid)
| ^~~~~~~~~
Remove the 'inline' specifier to avoid the problem.
Reported-by: Hongxu Jia <hongxu.jia(a)windriver.com>
Signed-off-by: Fabio Estevam <festevam(a)gmail.com>
---
src/cpu/cpu_x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
index 213af67ea478..0f7eb8f48b35 100644
--- a/src/cpu/cpu_x86.c
+++ b/src/cpu/cpu_x86.c
@@ -2564,7 +2564,7 @@ virCPUx86DataCheckFeature(const virCPUData *data,
#if defined(__i386__) || defined(__x86_64__)
-static inline void
+static void
cpuidCall(virCPUx86CPUID *cpuid)
{
virHostCPUX86GetCPUID(cpuid->eax_in,
--
2.34.1
2 weeks, 2 days
[PATCH v2] cpu_x86: Do not inline cpuidCall()
by Fabio Estevam
The following build error is observed when the DEBUG_BUILD variable
is enabled in OpenEmbedded:
src/cpu/cpu_x86.c: In function 'cpuidSetLeaf4':
src/cpu/cpu_x86.c:2563:1: error: inlining failed in call to 'cpuidCall': function not considered for inlining [-Werror=inline]
2563 | cpuidCall(virCPUx86CPUID *cpuid)
| ^~~~~~~~~
Remove the 'inline' specifier to avoid the problem.
Reported-by: Hongxu Jia <hongxu.jia(a)windriver.com>
Signed-off-by: Fabio Estevam <festevam(a)gmail.com>
Reviewed-by: Ján Tomko <jtomko(a)redhat.com>
---
Changes since v1:
- Improve the commit log by explaining where DEBUG_BUILD comes from. (Ján)
src/cpu/cpu_x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
index 213af67ea478..0f7eb8f48b35 100644
--- a/src/cpu/cpu_x86.c
+++ b/src/cpu/cpu_x86.c
@@ -2564,7 +2564,7 @@ virCPUx86DataCheckFeature(const virCPUData *data,
#if defined(__i386__) || defined(__x86_64__)
-static inline void
+static void
cpuidCall(virCPUx86CPUID *cpuid)
{
virHostCPUX86GetCPUID(cpuid->eax_in,
--
2.34.1
2 weeks, 2 days
[PATCH 0/2] spec: Bump min_rhel and min_fedora
by Michal Privoznik
Per our support policy [1], the minimal version we aim to support is
RHEL-9 and Fedora 41. Reflect this in the spec file.
1: https://libvirt.org/platforms.html
Michal Prívozník (2):
spec: Bump min_rhel
spec: Bump min_fedora
libvirt.spec.in | 38 ++++++++++++--------------------------
1 file changed, 12 insertions(+), 26 deletions(-)
--
2.49.0
2 weeks, 2 days
[PATCH] ch: Support RNG device
by Stefan Kober
Cloud Hypervisor supports virtio-rng devices and the configuration of
the randomness source (e.g. /dev/random or /dev/urandom).
This commit adds support for configuring the RNG device via libvirt for
the ch driver.
Signed-off-by: Stefan Kober <stefan.kober(a)cyberus-technology.de>
---
src/ch/ch_domain.c | 8 +++++++-
src/ch/ch_monitor.c | 41 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/src/ch/ch_domain.c b/src/ch/ch_domain.c
index c0c9acd85b..7231fdc49f 100644
--- a/src/ch/ch_domain.c
+++ b/src/ch/ch_domain.c
@@ -163,6 +163,7 @@ chValidateDomainDeviceDef(const virDomainDeviceDef *dev,
case VIR_DOMAIN_DEVICE_CONTROLLER:
case VIR_DOMAIN_DEVICE_CHR:
case VIR_DOMAIN_DEVICE_HOSTDEV:
+ case VIR_DOMAIN_DEVICE_RNG:
break;
case VIR_DOMAIN_DEVICE_LEASE:
@@ -177,7 +178,6 @@ chValidateDomainDeviceDef(const virDomainDeviceDef *dev,
case VIR_DOMAIN_DEVICE_SMARTCARD:
case VIR_DOMAIN_DEVICE_MEMBALLOON:
case VIR_DOMAIN_DEVICE_NVRAM:
- case VIR_DOMAIN_DEVICE_RNG:
case VIR_DOMAIN_DEVICE_SHMEM:
case VIR_DOMAIN_DEVICE_TPM:
case VIR_DOMAIN_DEVICE_PANIC:
@@ -218,6 +218,12 @@ chValidateDomainDeviceDef(const virDomainDeviceDef *dev,
return -1;
}
+ if (def->nrngs > 1) {
+ virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+ _("Only a single RNG device can be configured for this domain"));
+ return -1;
+ }
+
if (def->nserials > 1) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Only a single serial can be configured for this domain"));
diff --git a/src/ch/ch_monitor.c b/src/ch/ch_monitor.c
index 5a490b75f6..3d3b4cb87d 100644
--- a/src/ch/ch_monitor.c
+++ b/src/ch/ch_monitor.c
@@ -302,6 +302,44 @@ virCHMonitorBuildDisksJson(virJSONValue *content, virDomainDef *vmdef)
return 0;
}
+static int
+virCHMonitorBuildRngJson(virJSONValue *content, virDomainDef *vmdef)
+{
+ g_autoptr(virJSONValue) rng = virJSONValueNewObject();
+
+ if (vmdef->nrngs == 0) {
+ return 0;
+ }
+
+ if (vmdef->rngs[0]->model != VIR_DOMAIN_RNG_MODEL_VIRTIO) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("Only virtio model is supported for RNG devices"));
+ return -1;
+ }
+
+ switch (vmdef->rngs[0]->backend) {
+ case VIR_DOMAIN_RNG_BACKEND_RANDOM:
+ if (virJSONValueObjectAppendString(rng, "src", vmdef->rngs[0]->source.file) < 0)
+ return -1;
+
+ if (virJSONValueObjectAppend(content, "rng", &rng) < 0)
+ return -1;
+
+ break;
+
+ case VIR_DOMAIN_RNG_BACKEND_EGD:
+ case VIR_DOMAIN_RNG_BACKEND_BUILTIN:
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("Only RANDOM backend is supported for RNG devices"));
+ return -1;
+
+ case VIR_DOMAIN_RNG_BACKEND_LAST:
+ break;
+ }
+
+ return 0;
+}
+
/**
* virCHMonitorBuildNetJson:
* @net: pointer to a guest network definition
@@ -501,6 +539,9 @@ virCHMonitorBuildVMJson(virCHDriver *driver, virDomainDef *vmdef,
if (virCHMonitorBuildDisksJson(content, vmdef) < 0)
return -1;
+ if (virCHMonitorBuildRngJson(content, vmdef) < 0)
+ return -1;
+
if (virCHMonitorBuildDevicesJson(content, vmdef) < 0)
return -1;
--
2.49.0
2 weeks, 2 days
[PATCH 0/3] domain_capabilities: add console capabilities
by Roman Bogorodskiy
Motivation behind this series is to give management software possibility
to check whether the 'pty' console could be used,
or it should use something else, e.g. 'nmdm' for bhyve.
Because of the complex relationships between 'serial' and 'console',
I wasn't entirely sure whether I should report 'console' or 'serial'.
Also, I wasn't sure if I needed to report anything but 'type'.
Eventually I've decided to stay close to problem I'm trying to solve,
and report only console types.
I have updated only qemu and bhyve drivers for now, as I'm not sure if
the approach is correct. I'll update other drivers if that's ok.
Also, it was surprisingly tricky to get a list of supported console
types for qemu, as the model is heavily shared between console, serials,
parallel ports and channels, and sometimes it's not obvious if there's
any difference between these devices' supported types.
Interestingly, formatdomain.html doesn't provide much information about
'console type'. I was able to find the only occurrence of non-pty
console, which is type='stdio'. I was able to find more console types
used in the test data files though.
Roman Bogorodskiy (3):
domain_capabilities: add console capabilities
bhyve: capabilities: report NMDM console
qemu: 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/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 +++
.../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 +++++++++++
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 +++++++++++
68 files changed, 1119 insertions(+)
--
2.49.0
2 weeks, 2 days
