January 2025 - Devel - Libvirt List Archives

by Michal Privoznik

SEV-SNP support just landed in QEMU. Here is the first round of patches to incorporate support into libvirt. TODOs (aka problems of future me): - Teach tools/virt-qemu-sev-validate how to deal with SEV-SNP - Try to find a SEV-SNP machine a test these patches in real worl - Write a kbase article on attestation with SEV-SNP Michal Prívozník (12): qemu_monitor_json: Report error in error paths in SEV related code conf: Move some members of virDomainSEVDef into virDomainSEVCommonDef conf: Separate SEV formatting into a function Drop needless typecast to virDomainLaunchSecurity src: Convert some _virDomainSecDef::sectype checks to switch() qemu_monitor: Allow querying SEV-SNP state in 'query-sev' qemu: Report snp-policy in virDomainGetLaunchSecurityInfo() qemu_capabilities: Introduce QEMU_CAPS_SEV_SNP_GUEST conf: Introduce SEV-SNP support qemu: Build cmd line for SEV-SNP qemu: Allow setting launch security for SEV-SNP qemu_firmware: Pick the right firmware for SEV-SNP guests docs/formatdomain.rst | 108 ++++++++++++ include/libvirt/libvirt-domain.h | 10 ++ src/conf/domain_conf.c | 156 ++++++++++++++---- src/conf/domain_conf.h | 28 +++- src/conf/domain_validate.c | 44 +++++ src/conf/schemas/domaincommon.rng | 73 ++++++-- src/conf/virconftypes.h | 4 + src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_cgroup.c | 19 ++- src/qemu/qemu_command.c | 56 ++++++- src/qemu/qemu_driver.c | 60 +++++-- src/qemu/qemu_firmware.c | 20 ++- src/qemu/qemu_monitor.c | 7 +- src/qemu/qemu_monitor.h | 41 ++++- src/qemu/qemu_monitor_json.c | 67 ++++++-- src/qemu/qemu_monitor_json.h | 8 +- src/qemu/qemu_namespace.c | 3 +- src/qemu/qemu_process.c | 34 ++-- src/qemu/qemu_validate.c | 13 +- src/security/security_dac.c | 34 +++- .../caps_9.1.0_x86_64.xml | 1 + .../firmware/60-edk2-ovmf-x64-amdsev.json | 1 + tests/qemumonitorjsontest.c | 65 +++++++- ...launch-security-sev-snp.x86_64-latest.args | 35 ++++ .../launch-security-sev-snp.x86_64-latest.xml | 1 + .../launch-security-sev-snp.xml | 47 ++++++ tests/qemuxmlconftest.c | 2 + 28 files changed, 817 insertions(+), 127 deletions(-) create mode 100644 tests/qemuxmlconfdata/launch-security-sev-snp.x86_64-latest.args create mode 120000 tests/qemuxmlconfdata/launch-security-sev-snp.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/launch-security-sev-snp.xml -- 2.44.2

1 week, 6 days

5
31
0 / 0

[PATCH v1] tests: add capabilities for QEMU 10.0.0 on s390x

by Shalini Chellathurai Saroja

Let us introduce the xml and reply files for QEMU 10.0.0 on s390x. Notable changes: - new s390-ccw-virtio-10.0 machine type - old machine types (2.4 - 2.8) dropped - new CPU models - New devices: - virtio-mem-ccw - chardev now supports qemu-vdagent Signed-off-by: Shalini Chellathurai Saroja <shalini(a)linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> Suggested-by: Michal Privoznik <mprivozn(a)redhat.com> The replies and xml files are removed from this patch and are available in https://gitlab.com/shalinichellathurai/libvirt/-/commit/3e9df63925e2c86b8... --- tests/domaincapsdata/qemu_10.0.0.s390x.xml | 359 + .../caps_10.0.0_s390x.replies | 38002 ++++++++++++++++ .../caps_10.0.0_s390x.xml | 4216 ++ 3 files changed, 42577 insertions(+) create mode 100644 tests/domaincapsdata/qemu_10.0.0.s390x.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_s390x.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml diff --git a/tests/domaincapsdata/qemu_10.0.0.s390x.xml b/tests/domaincapsdata/qemu_10.0.0.s390x.xml new file mode 100644 index 0000000000..4af3c7ec53 --- /dev/null +++ b/tests/domaincapsdata/qemu_10.0.0.s390x.xml @@ -0,0 +1,359 @@ +<domainCapabilities> + <path>/usr/bin/qemu-system-s390x</path> + <domain>kvm</domain> + <machine>s390-ccw-virtio-10.0</machine> + <arch>s390x</arch> + <vcpu max='248'/> + <iothreads supported='yes'/> + <os supported='yes'> + <enum name='firmware'/> + <loader supported='yes'> + <value>/obviously/fake/firmware1.fd</value> + <value>/obviously/fake/firmware2.fd</value> + <enum name='type'> + <value>rom</value> + <value>pflash</value> + </enum> + <enum name='readonly'> + <value>yes</value> + <value>no</value> + </enum> + <enum name='secure'> + <value>no</value> + </enum> + </loader> + </os> + <cpu> + <mode name='host-passthrough' supported='yes'> + <enum name='hostPassthroughMigratable'> + <value>off</value> + </enum> + </mode> + <mode name='maximum' supported='yes'> + <enum name='maximumMigratable'> + <value>on</value> + <value>off</value> + </enum> + </mode> + <mode name='host-model' supported='yes'> + <model fallback='forbid'>gen16a-base</model> + <feature policy='require' name='nnpa'/> + <feature policy='require' name='aen'/> + <feature policy='require' name='cmmnt'/> + <feature policy='require' name='vxpdeh'/> + <feature policy='require' name='aefsi'/> + <feature policy='require' name='diag318'/> + <feature policy='require' name='csske'/> + <feature policy='require' name='mepoch'/> + <feature policy='require' name='msa9'/> + <feature policy='require' name='msa8'/> + <feature policy='require' name='msa7'/> + <feature policy='require' name='msa6'/> + <feature policy='require' name='msa5'/> + <feature policy='require' name='msa4'/> + <feature policy='require' name='msa3'/> + <feature policy='require' name='msa2'/> + <feature policy='require' name='msa1'/> + <feature policy='require' name='sthyi'/> + <feature policy='require' name='edat'/> + <feature policy='require' name='ri'/> + <feature policy='require' name='deflate'/> + <feature policy='require' name='edat2'/> + <feature policy='require' name='etoken'/> + <feature policy='require' name='vx'/> + <feature policy='require' name='ipter'/> + <feature policy='require' name='pai'/> + <feature policy='require' name='paie'/> + <feature policy='require' name='mepochptff'/> + <feature policy='require' name='ap'/> + <feature policy='require' name='vxeh'/> + <feature policy='require' name='vxpd'/> + <feature policy='require' name='esop'/> + <feature policy='require' name='msa9_pckmo'/> + <feature policy='require' name='vxeh2'/> + <feature policy='require' name='esort'/> + <feature policy='require' name='appv'/> + <feature policy='require' name='apqi'/> + <feature policy='require' name='apft'/> + <feature policy='require' name='els'/> + <feature policy='require' name='iep'/> + <feature policy='require' name='appvi'/> + <feature policy='require' name='apqci'/> + <feature policy='require' name='cte'/> + <feature policy='require' name='ais'/> + <feature policy='require' name='bpb'/> + <feature policy='require' name='ctop'/> + <feature policy='require' name='gs'/> + <feature policy='require' name='ppa15'/> + <feature policy='require' name='zpci'/> + <feature policy='require' name='rdp'/> + <feature policy='require' name='sea_esop2'/> + <feature policy='require' name='beareh'/> + <feature policy='require' name='te'/> + <feature policy='require' name='cmm'/> + <feature policy='require' name='vxpdeh2'/> + </mode> + <mode name='custom' supported='yes'> + <model usable='yes' vendor='IBM'>gen15a</model> + <model usable='yes' vendor='IBM'>gen15a-base</model> + <model usable='yes' vendor='IBM'>gen15b</model> + <model usable='yes' vendor='IBM'>gen15b-base</model> + <model usable='yes' vendor='IBM'>gen16a</model> + <model usable='yes' vendor='IBM'>gen16a-base</model> + <model usable='yes' vendor='IBM'>gen16b</model> + <model usable='yes' vendor='IBM'>gen16b-base</model> + <model usable='no' vendor='IBM'>gen17a</model> + <blockers model='gen17a'> + <feature name='minste4'/> + <feature name='msa10'/> + <feature name='msa10_pckmo'/> + <feature name='msa11'/> + <feature name='msa11_pckmo'/> + <feature name='msa12'/> + <feature name='msa13'/> + <feature name='msa13_pckmo'/> + <feature name='plo_ext'/> + <feature name='sif'/> + <feature name='type'/> + <feature name='vxeh3'/> + <feature name='vxpdeh3'/> + </blockers> + <model usable='no' vendor='IBM'>gen17a-base</model> + <blockers model='gen17a-base'> + <feature name='minste4'/> + <feature name='msa12'/> + <feature name='plo_ext'/> + <feature name='sif'/> + <feature name='type'/> + </blockers> + <model usable='no' vendor='IBM'>gen17b</model> + <blockers model='gen17b'> + <feature name='minste4'/> + <feature name='msa10'/> + <feature name='msa10_pckmo'/> + <feature name='msa11'/> + <feature name='msa11_pckmo'/> + <feature name='msa12'/> + <feature name='msa13'/> + <feature name='msa13_pckmo'/> + <feature name='plo_ext'/> + <feature name='sif'/> + <feature name='type'/> + <feature name='vxeh3'/> + <feature name='vxpdeh3'/> + </blockers> + <model usable='no' vendor='IBM'>gen17b-base</model> + <blockers model='gen17b-base'> + <feature name='minste4'/> + <feature name='msa12'/> + <feature name='plo_ext'/> + <feature name='sif'/> + <feature name='type'/> + </blockers> + <model usable='yes' vendor='unknown'>max</model> + <model usable='yes' vendor='unknown'>qemu</model> + <model usable='yes' vendor='IBM'>z10BC</model> + <model usable='yes' vendor='IBM'>z10BC-base</model> + <model usable='yes' vendor='IBM'>z10BC.2</model> + <model usable='yes' vendor='IBM'>z10BC.2-base</model> + <model usable='yes' vendor='IBM'>z10EC</model> + <model usable='yes' vendor='IBM'>z10EC-base</model> + <model usable='yes' vendor='IBM'>z10EC.2</model> + <model usable='yes' vendor='IBM'>z10EC.2-base</model> + <model usable='yes' vendor='IBM'>z10EC.3</model> + <model usable='yes' vendor='IBM'>z10EC.3-base</model> + <model usable='yes' vendor='IBM'>z114</model> + <model usable='yes' vendor='IBM'>z114-base</model> + <model usable='yes' vendor='IBM'>z13</model> + <model usable='yes' vendor='IBM'>z13-base</model> + <model usable='yes' vendor='IBM'>z13.2</model> + <model usable='yes' vendor='IBM'>z13.2-base</model> + <model usable='yes' vendor='IBM'>z13s</model> + <model usable='yes' vendor='IBM'>z13s-base</model> + <model usable='yes' vendor='IBM'>z14</model> + <model usable='yes' vendor='IBM'>z14-base</model> + <model usable='yes' vendor='IBM'>z14.2</model> + <model usable='yes' vendor='IBM'>z14.2-base</model> + <model usable='yes' vendor='IBM'>z14ZR1</model> + <model usable='yes' vendor='IBM'>z14ZR1-base</model> + <model usable='yes' vendor='IBM'>z196</model> + <model usable='yes' vendor='IBM'>z196-base</model> + <model usable='yes' vendor='IBM'>z196.2</model> + <model usable='yes' vendor='IBM'>z196.2-base</model> + <model usable='yes' vendor='IBM'>z800</model> + <model usable='yes' vendor='IBM'>z800-base</model> + <model usable='yes' vendor='IBM'>z890</model> + <model usable='yes' vendor='IBM'>z890-base</model> + <model usable='yes' vendor='IBM'>z890.2</model> + <model usable='yes' vendor='IBM'>z890.2-base</model> + <model usable='yes' vendor='IBM'>z890.3</model> + <model usable='yes' vendor='IBM'>z890.3-base</model> + <model usable='yes' vendor='IBM'>z900</model> + <model usable='yes' vendor='IBM'>z900-base</model> + <model usable='yes' vendor='IBM'>z900.2</model> + <model usable='yes' vendor='IBM'>z900.2-base</model> + <model usable='yes' vendor='IBM'>z900.3</model> + <model usable='yes' vendor='IBM'>z900.3-base</model> + <model usable='yes' vendor='IBM'>z990</model> + <model usable='yes' vendor='IBM'>z990-base</model> + <model usable='yes' vendor='IBM'>z990.2</model> + <model usable='yes' vendor='IBM'>z990.2-base</model> + <model usable='yes' vendor='IBM'>z990.3</model> + <model usable='yes' vendor='IBM'>z990.3-base</model> + <model usable='yes' vendor='IBM'>z990.4</model> + <model usable='yes' vendor='IBM'>z990.4-base</model> + <model usable='yes' vendor='IBM'>z990.5</model> + <model usable='yes' vendor='IBM'>z990.5-base</model> + <model usable='yes' vendor='IBM'>z9BC</model> + <model usable='yes' vendor='IBM'>z9BC-base</model> + <model usable='yes' vendor='IBM'>z9BC.2</model> + <model usable='yes' vendor='IBM'>z9BC.2-base</model> + <model usable='yes' vendor='IBM'>z9EC</model> + <model usable='yes' vendor='IBM'>z9EC-base</model> + <model usable='yes' vendor='IBM'>z9EC.2</model> + <model usable='yes' vendor='IBM'>z9EC.2-base</model> + <model usable='yes' vendor='IBM'>z9EC.3</model> + <model usable='yes' vendor='IBM'>z9EC.3-base</model> + <model usable='yes' vendor='IBM'>zBC12</model> + <model usable='yes' vendor='IBM'>zBC12-base</model> + <model usable='yes' vendor='IBM'>zEC12</model> + <model usable='yes' vendor='IBM'>zEC12-base</model> + <model usable='yes' vendor='IBM'>zEC12.2</model> + <model usable='yes' vendor='IBM'>zEC12.2-base</model> + </mode> + </cpu> + <memoryBacking supported='yes'> + <enum name='sourceType'> + <value>file</value> + <value>anonymous</value> + <value>memfd</value> + </enum> + </memoryBacking> + <devices> + <disk supported='yes'> + <enum name='diskDevice'> + <value>disk</value> + <value>cdrom</value> + <value>floppy</value> + <value>lun</value> + </enum> + <enum name='bus'> + <value>fdc</value> + <value>scsi</value> + <value>virtio</value> + <value>usb</value> + </enum> + <enum name='model'> + <value>virtio</value> + <value>virtio-transitional</value> + <value>virtio-non-transitional</value> + </enum> + </disk> + <graphics supported='yes'> + <enum name='type'> + <value>sdl</value> + <value>vnc</value> + <value>egl-headless</value> + <value>dbus</value> + </enum> + </graphics> + <video supported='yes'> + <enum name='modelType'> + <value>virtio</value> + <value>none</value> + </enum> + </video> + <hostdev supported='yes'> + <enum name='mode'> + <value>subsystem</value> + </enum> + <enum name='startupPolicy'> + <value>default</value> + <value>mandatory</value> + <value>requisite</value> + <value>optional</value> + </enum> + <enum name='subsysType'> + <value>usb</value> + <value>pci</value> + <value>scsi</value> + </enum> + <enum name='capsType'/> + <enum name='pciBackend'> + <value>default</value> + <value>vfio</value> + </enum> + </hostdev> + <rng supported='yes'> + <enum name='model'> + <value>virtio</value> + <value>virtio-transitional</value> + <value>virtio-non-transitional</value> + </enum> + <enum name='backendModel'> + <value>random</value> + <value>egd</value> + <value>builtin</value> + </enum> + </rng> + <filesystem supported='yes'> + <enum name='driverType'> + <value>path</value> + <value>handle</value> + <value>virtiofs</value> + </enum> + </filesystem> + <tpm supported='no'/> + <redirdev supported='yes'> + <enum name='bus'> + <value>usb</value> + </enum> + </redirdev> + <channel supported='yes'> + <enum name='type'> + <value>pty</value> + <value>unix</value> + </enum> + </channel> + <crypto supported='yes'> + <enum name='model'> + <value>virtio</value> + </enum> + <enum name='type'> + <value>qemu</value> + </enum> + <enum name='backendModel'> + <value>builtin</value> + <value>lkcf</value> + </enum> + </crypto> + <interface supported='yes'> + <enum name='backendType'> + <value>default</value> + <value>passt</value> + </enum> + </interface> + <panic supported='yes'> + <enum name='model'> + <value>s390</value> + </enum> + </panic> + </devices> + <features> + <gic supported='no'/> + <vmcoreinfo supported='no'/> + <genid supported='no'/> + <backingStoreInput supported='yes'/> + <backup supported='yes'/> + <async-teardown supported='yes'/> + <s390-pv supported='yes'/> + <ps2 supported='no'/> + <sev supported='no'/> + <sgx supported='no'/> + <launchSecurity supported='yes'> + <enum name='sectype'> + <value>s390-pv</value> + </enum> + </launchSecurity> + </features> +</domainCapabilities> diff --git a/tests/qemucapabilitiesdata/caps_10.0.0_s390x.replies b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.replies new file mode 100644 index 0000000000..5195489878 --- /dev/null +++ b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.replies @@ -0,0 +1,38002 @@ [...] diff --git a/tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml new file mode 100644 index 0000000000..242848d6ae --- /dev/null +++ b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml @@ -0,0 +1,4216 @@ [...]

2 weeks

2
1
0 / 0

[PATCH] qemu: Fix hang when migration is canceled at the last moment

by Jiri Denemark

When a migration is canceled very late once virtual CPUs are already stopped, QEMU will automatically resume them. If this happens after we exited a waiting loop in qemuMigrationSrcWaitForCompletion, but before a loop that tries to make sure CPUs are stopped by waiting for the appropriate event, we may end up waiting forever because the CPUs are running (they were resumed by migrate_cancel), but the STOP event is already gone. This is possible because we enter monitor for fetching migration statistics at which point other APIs can be processed and migration may change its state. We should recheck the state when we get back from the monitor code. https://issues.redhat.com/browse/RHEL-52493 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_migration.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index bb4d11e196..53bbbee629 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2169,6 +2169,13 @@ qemuMigrationSrcWaitForCompletion(virDomainObj *vm, ignore_value(qemuMigrationAnyFetchStats(vm, asyncJob, jobData, NULL)); + /* We need to recheck migration status here as it might have changed while + * we were fetching statistics. For example, the migration might have been + * canceled. + */ + if ((rv = qemuMigrationAnyCompleted(vm, asyncJob, dconn, flags)) < 0) + return rv; + qemuDomainJobDataUpdateTime(jobData); qemuDomainJobDataUpdateDowntime(jobData); g_clear_pointer(&vm->job->completed, virDomainJobDataFree); -- 2.48.1

2 weeks

2
1
0 / 0

[PATCH] qemu monitor: Fix incorrect error message condition

by Fabian Leditzky

Fixes 'block_io_throttle inserted entry was not in expected format' error message spam. Without this patch, libvirtd writes an error message every time this function runs for a domain which has CD-ROM drives without a media attached. The 'inserted' key is not present when the drive is empty. The original code incorrectly assumes that the 'inserted' entry is not in the right format (wrong JSON value type, not an 'Object') when virJSONValueObjectGetObject(temp_dev, "inserted") returns NULL. However, NULL is also returned when the 'inserted' entry is simply not present. Signed-off-by: Fabian Leditzky <fabian(a)ldsoft.dev> --- src/qemu/qemu_monitor_json.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 9f417d27c6..baf934c2af 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -4581,8 +4581,16 @@ qemuMonitorJSONBlockIoThrottleInfo(virJSONValue *io_throttle, found = true; if (!(inserted = virJSONValueObjectGetObject(temp_dev, "inserted"))) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("block_io_throttle inserted entry was not in expected format")); + /* + * Ensure that we only print the error message when the 'inserted' key is actually the wrong type/format. + * Some device types (e.g. SATA CD-ROM) will have no 'inserted' key present if no media is present. + * Avoid spamming this error in such cases. + */ + if (virJSONValueObjectGet(temp_dev, "inserted")) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("block_io_throttle inserted entry was not in expected format")); + } + return -1; } GET_THROTTLE_STATS("bps", total_bytes_sec); -- 2.47.1

2 weeks

2
2
0 / 0

[PATCH] tools: ssh-proxy: Check for domain status before parsing its CID

by Michal Privoznik

Inactive domain XML can be wildly different to the live XML. For instance, it can have VSOCK CID of that from another (running) domain. Since domain status is not checked for, attempting to ssh into an inactive domain may in fact result in opening a connection to a different live domain that listens on said CID currently. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/737 Resolves: https://issues.redhat.com/browse/RHEL-75577 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- tools/ssh-proxy/ssh-proxy.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/ssh-proxy/ssh-proxy.c b/tools/ssh-proxy/ssh-proxy.c index e60c58d57f..22daffeb63 100644 --- a/tools/ssh-proxy/ssh-proxy.c +++ b/tools/ssh-proxy/ssh-proxy.c @@ -194,7 +194,10 @@ lookupDomainAndFetchCID(const char *uri, if (virStrToLong_i(domname, NULL, 10, &id) >= 0) dom = virDomainLookupByID(conn, id); } - if (!dom) + + /* If no domain is found, return an error. Similarly, inactive domain may + * contain CID of another (running) domain, yielding misleading results. */ + if (!dom || virDomainIsActive(dom) <= 0) return -1; return extractCID(dom, cid); -- 2.45.2

2 weeks

2
1
0 / 0

[PATCH] nss: Skip empty files and avoid use of uninitialized value

by Jiang XueQian

JSON parser isn't called when reading empty files so `jerr` will be used uninitialized in the original code. Empty files appear when a network has no dhcp clients. This patch checks for such files and skip them. Signed-off-by: Jiang XueQian <jiangxueqian(a)gmail.com> --- tools/nss/libvirt_nss_leases.c | 5 +++++ tools/nss/libvirt_nss_macs.c | 5 +++++ 2 files changed, 10 insertions(+) diff --git a/tools/nss/libvirt_nss_leases.c b/tools/nss/libvirt_nss_leases.c index aea81bb56e..7ffe4a8761 100644 --- a/tools/nss/libvirt_nss_leases.c +++ b/tools/nss/libvirt_nss_leases.c @@ -290,6 +290,11 @@ findLeases(const char *file, jerr = json_tokener_get_error(tok); } while (jerr == json_tokener_continue); + if (nreadTotal == 0) { + ret = 0; + goto cleanup; + } + if (jerr == json_tokener_continue) { ERROR("Cannot parse %s: incomplete json found", file); goto cleanup; diff --git a/tools/nss/libvirt_nss_macs.c b/tools/nss/libvirt_nss_macs.c index 23229a18f3..57c0f79fbb 100644 --- a/tools/nss/libvirt_nss_macs.c +++ b/tools/nss/libvirt_nss_macs.c @@ -152,6 +152,11 @@ findMACs(const char *file, jerr = json_tokener_get_error(tok); } while (jerr == json_tokener_continue); + if (nreadTotal == 0) { + ret = 0; + goto cleanup; + } + if (jerr == json_tokener_continue) { ERROR("Cannot parse %s: incomplete json found", file); goto cleanup; -- 2.48.1

2 weeks

2
2
0 / 0

[libvirt PATCH v2 0/2] meson: error out when ch driver is requested but unsupported

by Ján Tomko

v1 forgot to define the 'use_ch' variable in some corner case v2 also disables the build for mingw Ján Tomko (2): meson: error out when ch driver is requested but unsupported libvirt.spec: do not build ch driver on mingw libvirt.spec.in | 1 + meson.build | 11 +++++++++-- 2 files changed, 10 insertions(+), 2 deletions(-) -- 2.47.0

2 weeks, 1 day

2
3
0 / 0

[PATCH 0/2] Fix storage_file_backend_fs demodularization

by Peter Krempa

2 bugs were missed; brown paper bag was installed Peter Krempa (2): libvirt.spec: Move ownership of 'storage-file' backends directory to gluster storage_file_backend_fs: Compile out 'chown' backend on mingw libvirt.spec.in | 2 +- src/storage_file/storage_file_backend_fs.c | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletion(-) -- 2.48.1

2 weeks, 1 day

2
3
0 / 0

[PATCH v2 0/2] tests: Add qemu-9.2 dev cycle caps on s390x

by Michal Privoznik

v2 of: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/WA... diff to v1: - instead of switching test case from 2.7 machine type to something newer, just drop the test case. Michal Prívozník (2): qemuxmlconftest: Drop s390-default-cpu-...ccw-virtio-2.7 test cases tests: qemucapabilities: Add test data for the qemu-9.2 dev cycle on s390x tests/domaincapsdata/qemu_9.3.0.s390x.xml | 436 + .../caps_9.3.0_s390x.replies | 38101 ++++++++++++++++ .../qemucapabilitiesdata/caps_9.3.0_s390x.xml | 4268 ++ ...-deprecated-features-off.s390x-latest.args | 2 +- ...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-2.7.s390x-latest.args | 32 - ...lt-cpu-kvm-ccw-virtio-2.7.s390x-latest.xml | 25 - .../s390-default-cpu-kvm-ccw-virtio-2.7.xml | 16 - ...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +- ...t-cpu-tcg-ccw-virtio-2.7.s390x-latest.args | 32 - ...lt-cpu-tcg-ccw-virtio-2.7.s390x-latest.xml | 27 - .../s390-default-cpu-tcg-ccw-virtio-2.7.xml | 16 - .../s390-defaultconsole.s390x-latest.args | 2 +- .../s390-panic.s390x-latest.args | 2 +- tests/qemuxmlconftest.c | 2 - 17 files changed, 42812 insertions(+), 157 deletions(-) create mode 100644 tests/domaincapsdata/qemu_9.3.0.s390x.xml create mode 100644 tests/qemucapabilitiesdata/caps_9.3.0_s390x.replies create mode 100644 tests/qemucapabilitiesdata/caps_9.3.0_s390x.xml delete mode 100644 tests/qemuxmlconfdata/s390-default-cpu-kvm-ccw-virtio-2.7.s390x-latest.args delete mode 100644 tests/qemuxmlconfdata/s390-default-cpu-kvm-ccw-virtio-2.7.s390x-latest.xml delete mode 100644 tests/qemuxmlconfdata/s390-default-cpu-kvm-ccw-virtio-2.7.xml delete mode 100644 tests/qemuxmlconfdata/s390-default-cpu-tcg-ccw-virtio-2.7.s390x-latest.args delete mode 100644 tests/qemuxmlconfdata/s390-default-cpu-tcg-ccw-virtio-2.7.s390x-latest.xml delete mode 100644 tests/qemuxmlconfdata/s390-default-cpu-tcg-ccw-virtio-2.7.xml -- 2.45.2

2 weeks, 1 day

4
6
0 / 0

[PATCH] util: avoid overflow in hextable buffer

by Daniel P. Berrangé

The assigned string is 17 chars long once the trailing nul is taken into account. This triggers a warning with GCC 15 src/util/virsystemd.c: In function ‘virSystemdEscapeName’: src/util/virsystemd.c:59:38: error: initializer-string for array of ‘char’ is too long [-Werror=unterminated-string-initialization] 59 | static const char hextable[16] = "0123456789abcdef"; | ^~~~~~~~~~~~~~~~~~ Switch to a dynamically sized array as used in all the other places we have a hextable array. See also: https://gcc.gnu.org/PR115185 Reported-by: Yaakov Selkowitz <yselkowi(a)redhat.com> Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/util/virsystemd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/virsystemd.c b/src/util/virsystemd.c index 5b772e29dd..d46e5f74fc 100644 --- a/src/util/virsystemd.c +++ b/src/util/virsystemd.c @@ -56,7 +56,7 @@ struct _virSystemdActivationEntry { static void virSystemdEscapeName(virBuffer *buf, const char *name) { - static const char hextable[16] = "0123456789abcdef"; + static const char hextable[] = "0123456789abcdef"; #define ESCAPE(c) \ do { \ -- 2.47.1

2 weeks, 1 day

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Devel January 2025