November 2024 - Devel - libvirt List Archives

[PATCH v3 00/17] hw/microblaze: Allow running cross-endian vCPUs
by Philippe Mathieu-Daudé 05 Feb '25

05 Feb '25

Missing review: 4 (new) & 10 Since v2: - Addressed Richard's review comments Since v1: - Make device endianness configurable (Edgar) - Convert more Xilinx devices - Avoid preprocessor #if (Richard) - Add R-b tags Make machines endianness-agnostic, allowing to run a big-endian vCPU on the little-endian 'qemu-system-microblazeel' binary, and a little endian one on the big-endian 'qemu-system-microblaze' binary. Tests added, following combinations covered: - little-endian vCPU using little-endian binary (in-tree) - little-endian vCPU using big-endian binary (new) - big-endian vCPU using little-endian binary (new) - big-endian vCPU using big-endian binary (in-tree) To make a target endian-agnostic we need to remove the MO_TE uses. In order to do that, we propagate the MemOp from earlier in the call stack, or we extract it from the vCPU env (on MicroBlaze the CPU endianness is exposed by the 'ENDI' bit). Next step: Look at unifying binaries. Please review, Phil. Philippe Mathieu-Daudé (17): hw/microblaze: Restrict MemoryRegionOps are implemented as 32-bit hw/microblaze: Propagate CPU endianness to microblaze_load_kernel() hw/intc/xilinx_intc: Make device endianness configurable RFC hw/net/xilinx_ethlite: Simplify by having configurable endianness RFC hw/timer/xilinx_timer: Allow down to 8-bit memory access hw/timer/xilinx_timer: Make device endianness configurable hw/char/xilinx_uartlite: Make device endianness configurable hw/ssi/xilinx_spi: Make device endianness configurable hw/ssi/xilinx_spips: Make device endianness configurable hw/arm/xlnx-zynqmp: Use &error_abort for programming errors target/microblaze: Explode MO_TExx -> MO_TE | MO_xx target/microblaze: Set MO_TE once in do_load() / do_store() target/microblaze: Introduce mo_endian() helper target/microblaze: Consider endianness while translating code hw/microblaze: Support various endianness for s3adsp1800 machines tests/functional: Explicit endianness of microblaze assets tests/functional: Add microblaze cross-endianness tests hw/microblaze/boot.h | 4 +- include/hw/ssi/xilinx_spips.h | 1 + target/microblaze/cpu.h | 7 +++ hw/arm/xilinx_zynq.c | 1 + hw/arm/xlnx-zynqmp.c | 40 +++++-------- hw/char/xilinx_uartlite.c | 31 ++++++---- hw/intc/xilinx_intc.c | 50 ++++++++++++---- hw/microblaze/boot.c | 8 +-- hw/microblaze/petalogix_ml605_mmu.c | 4 +- hw/microblaze/petalogix_s3adsp1800_mmu.c | 58 ++++++++++++++++--- hw/microblaze/xlnx-zynqmp-pmu.c | 2 +- hw/net/xilinx_ethlite.c | 42 +++++++++----- hw/ppc/virtex_ml507.c | 1 + hw/ssi/xilinx_spi.c | 24 +++++--- hw/ssi/xilinx_spips.c | 36 +++++++----- hw/timer/xilinx_timer.c | 33 +++++++---- target/microblaze/translate.c | 49 ++++++++++------ .../functional/test_microblaze_s3adsp1800.py | 27 ++++++++- .../test_microblazeel_s3adsp1800.py | 25 +++++++- 19 files changed, 309 insertions(+), 134 deletions(-) -- 2.45.2

4 27

Re: [PATCH] Сheck snapshot disk is not NULL when searching it in the VM config
by Peter Krempa 29 Jan '25

29 Jan '25

On Mon, May 20, 2024 at 14:48:47 +0000, Efim Shevrin via Devel wrote: > Hello, > > > If vmdisk is NULL, shouldn't this function (qemuSnapshotDeleteValidate()) return an error? > > I think this qemuSnapshotDeleteValidate should not return an error. > > It seems to me that when vmdisk is NULL, this does not invalidate > the snapshot itself, but indicates that the config has changed since > the snapshot was done. And if the VM config has changed, this adds evidence that the snapshot should be deleted, > because the snapshot does not reflect the real vm config. > > Since we do not have an analogue of the --force option for deleting a snapshot, in the case when qemuSnapshotDeleteValidate returns > an error when vmdisk is NULL, we will never delete a snapshot which has invalid disk. Snapshot deletion does have something that can be considered force and that is the '--metadata' option that removes just the snapshot definition (metadata) and doesn't touch the disk images. > > Similarly, disk can be NULL too > Thank you for the comment regarding the disk variable. I`ve reworked patch. > > When creating a snapshot of a VM with multiple hard disks, > the snapshot takes into account the presence of all disks > in the system. If, over time, one of the disks is deleted, > the snapshot will continue to store knowledge of the deleted disk. > This results in the fact that at the moment of deleting the snapshot, > at the validation stage, a disk from the snapshot will be searched which > is not in the VM configuration. As a result, vmdisk variable will > be equal to NULL. Dereferencing a null pointer at the time of calling > virStorageSourceIsSameLocation(vmdisk->src, disk->src) > will result in SIGSEGV. Crashing is obviously not okay ... > Also, the disk variable can also be equal to NULL and this > requires to check that disk != NULL before calling the > virStorageSourceIsSameLocation function to avoid SIGSEGV. .. but going ahead with the snapshot deletion isn't always okay either. The disk isn't referenced by the VM so the disk state can't be merged, while the state would be merged for any other disk. When reverting back to a previous snapshot, which is still referencing the older state of the disk which was removed from the VM, the VM would see that the image state of disks that were present at deletion would contain the merged state, but only a partial state for the disk which was later removed.

3 3

[PATCH] qemuSnapshotDeleteValidate: Fix crash when disk is not found in VM definition
by kaihuan 29 Jan '25

29 Jan '25

qemuDomainDiskByName() can return a NULL pointer on failure. But this returned value in qemuSnapshotDeleteValidate is not checked.It will make libvirtd crash. Signed-off-by: kaihuan <jungleman759(a)gmail.com> --- src/qemu/qemu_snapshot.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c index 18b2e478f6..bcbd913073 100644 --- a/src/qemu/qemu_snapshot.c +++ b/src/qemu/qemu_snapshot.c @@ -4242,8 +4242,19 @@ qemuSnapshotDeleteValidate(virDomainObj *vm, virDomainDiskDef *vmdisk = NULL; virDomainDiskDef *disk = NULL; - vmdisk = qemuDomainDiskByName(vm->def, snapDisk->name); - disk = qemuDomainDiskByName(snapdef->parent.dom, snapDisk->name); + if (!(vmdisk = qemuDomainDiskByName(vm->def, snapDisk->name))) { + virReportError(VIR_ERR_OPERATION_FAILED, + _("disk '%1$s' referenced by snapshot '%2$s' not found in the current definition"), + snapDisk->name, snap->def->name); + return -1; + } + + if (!(disk = qemuDomainDiskByName(snapdef->parent.dom, snapDisk->name))) { + virReportError(VIR_ERR_OPERATION_FAILED, + _("disk '%1$s' referenced by snapshot '%2$s' not found in the VM definition of the deleted snapshot"), + snapDisk->name, snap->def->name); + return -1; + } if (!virStorageSourceIsSameLocation(vmdisk->src, disk->src)) { virReportError(VIR_ERR_OPERATION_UNSUPPORTED, -- 2.33.1.windows.1

3 3

[libvirt PATCH] qemu_snapshot: allow reverting to external disk only snapshot
by Pavel Hrdina 29 Jan '25

29 Jan '25

When snapshot is created with disk-only flag it is always external snapshot without memory state. Historically when there was not support to revert external snapshots this produced error message. error: Failed to revert snapshot s1 error: internal error: Invalid target domain state 'disk-snapshot'. Refusing snapshot reversion Now we can simply consider this as reverting to offline snapshot as the possible damage to file system is already done at the point of snapshot creation. Resolves: https://issues.redhat.com/browse/RHEL-21549 Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/qemu/qemu_snapshot.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c index 0cac0c4146..7964f70553 100644 --- a/src/qemu/qemu_snapshot.c +++ b/src/qemu/qemu_snapshot.c @@ -2606,6 +2606,7 @@ qemuSnapshotRevert(virDomainObj *vm, case VIR_DOMAIN_SNAPSHOT_SHUTDOWN: case VIR_DOMAIN_SNAPSHOT_SHUTOFF: case VIR_DOMAIN_SNAPSHOT_CRASHED: + case VIR_DOMAIN_SNAPSHOT_DISK_SNAPSHOT: ret = qemuSnapshotRevertInactive(vm, snapshot, snap, driver, cfg, &inactiveConfig, @@ -2617,8 +2618,6 @@ qemuSnapshotRevert(virDomainObj *vm, _("qemu doesn't support reversion of snapshot taken in PMSUSPENDED state")); goto endjob; - case VIR_DOMAIN_SNAPSHOT_DISK_SNAPSHOT: - /* Rejected earlier as an external snapshot */ case VIR_DOMAIN_SNAPSHOT_NOSTATE: case VIR_DOMAIN_SNAPSHOT_BLOCKED: case VIR_DOMAIN_SNAPSHOT_LAST: -- 2.43.0

2 1

[PATCH 0/3] conf,qemu: add AIA support for RISC-V 'virt'
by Daniel Henrique Barboza 22 Jan '25

22 Jan '25

Hi, This series adds official support for RISC-V AIA (Advanced Interrupt Architecture). AIA and has been supported by the 'virt' RISC-V board, as a machine property, since QEMU 7.0. Daniel Henrique Barboza (3): qemu: add capability for RISC-V AIA feature conf,qemu: implement RISC-V 'aia' virt domain feature qemu: add RISC-V 'aia' command line docs/formatdomain.rst | 8 ++++ src/conf/domain_conf.c | 39 +++++++++++++++++++ src/conf/domain_conf.h | 11 ++++++ src/conf/schemas/domaincommon.rng | 15 +++++++ src/libvirt_private.syms | 2 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 5 +++ src/qemu/qemu_validate.c | 15 +++++++ .../caps_8.0.0_riscv64.xml | 1 + .../caps_9.1.0_riscv64.xml | 1 + ...cv64-virt-features-aia.riscv64-latest.args | 31 +++++++++++++++ ...scv64-virt-features-aia.riscv64-latest.xml | 1 + .../riscv64-virt-features-aia.xml | 27 +++++++++++++ tests/qemuxmlconftest.c | 2 + 15 files changed, 161 insertions(+) create mode 100644 tests/qemuxmlconfdata/riscv64-virt-features-aia.riscv64-latest.args create mode 120000 tests/qemuxmlconfdata/riscv64-virt-features-aia.riscv64-latest.xml create mode 100644 tests/qemuxmlconfdata/riscv64-virt-features-aia.xml -- 2.45.2

2 8

[PATCH 00/12] Introduce SEV-SNP support
by Michal Privoznik 22 Jan '25

22 Jan '25

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

5 31

[PATCH 00/20] qemu: support mapped-ram+directio+mulitfd
by Jim Fehlig 15 Jan '25

15 Jan '25

This series is essentially V1 of a prior RFC [1] to support QEMU's mapped-ram stream format [2] and migration capability. Along with supporting mapped-ram, it implements a design approach we discussed for supporting parallel save/restore [3]. In summary, the approach is 1. Add mapped-ram migration capability 2. Steal an element from save header 'unused' for a 'features' variable and bump save version to 3. 3. Add /etc/libvirt/qemu.conf knob for the save format version, defaulting to latest v3 4. Use v3 (aka mapped-ram) by default 5. Use mapped-ram with BYPASS_CACHE for v3, old approach for v2 6. include: Define constants for parallel save/restore 7. qemu: Add support for parallel save. Implies mapped-ram, reject if v2 8. qemu: Add support for parallel restore. Implies mapped-ram. Reject if v2 9. tools: add parallel parameter to virsh save command 10. tools: add parallel parameter to virsh restore command With this series, saving and restoring using mapped-ram is enabled by default if the underlying QEMU advertises the mapped-ram migration capability. It can be disabled by changing the 'save_image_version' setting in qemu.conf. To use mapped-ram with QEMU: - The 'mapped-ram' migration capability must be set to true - The 'multifd' migration capability must be set to true and the 'multifd-channels' migration parameter must set to a value >= 1 - QEMU must be provided an fdset containing the migration fd(s) - The 'migrate' qmp command is invoked with a URI referencing the fdset and an offset where to start reading or writing the data stream, e.g. {"execute":"migrate", "arguments":{"detach":true,"resume":false, "uri":"file:/dev/fdset/0,offset=0x11921"}} The mapped-ram stream, in conjunction with direct IO and multifd, can significantly improve the time required to save VM memory state. The following tables compare mapped-ram with the existing, sequential save stream. In all cases, the save and restore operations are to/from a block device comprised of two NVMe disks in RAID0 configuration with xfs (~8600MiB/s). The values in the 'save time' and 'restore time' columns were scraped from the 'real' time reported by time(1). The 'Size' and 'Blocks' columns were provided by the corresponding outputs of stat(1). VM: 32G RAM, 1 vcpu, idle (shortly after boot) | save | restore | | time | time | Size | Blocks -----------------------+---------+---------+--------------+-------- legacy | 6.193s | 4.399s | 985744812 | 1925288 -----------------------+---------+---------+--------------+-------- mapped-ram | 5.109s | 1.176s | 34368554354 | 1774472 -----------------------+---------+---------+--------------+-------- legacy + direct IO | 5.725s | 4.512s | 985765251 | 1925328 -----------------------+---------+---------+--------------+-------- mapped-ram + direct IO | 4.627s | 1.490s | 34368554354 | 1774304 -----------------------+---------+---------+--------------+-------- mapped-ram + direct IO | | | | + multifd-channels=8 | 4.421s | 0.845s | 34368554318 | 1774312 ------------------------------------------------------------------- VM: 32G RAM, 30G dirty, 1 vcpu in tight loop dirtying memory | save | restore | | time | time | Size | Blocks -----------------------+---------+---------+--------------+--------- legacy | 25.800s | 14.332s | 33154309983 | 64754512 -----------------------+---------+---------+--------------+--------- mapped-ram | 18.742s | 15.027s | 34368559228 | 64617160 -----------------------+---------+---------+--------------+--------- legacy + direct IO | 13.115s | 18.050s | 33154310496 | 64754520 -----------------------+---------+---------+--------------+--------- mapped-ram + direct IO | 13.623s | 15.959s | 34368557392 | 64662040 -----------------------+-------- +---------+--------------+--------- mapped-ram + direct IO | | | | + multifd-channels=8 | 6.994s | 6.470s | 34368554980 | 64665776 -------------------------------------------------------------------- As can be seen from the tables, one caveat of mapped-ram is the logical file size of a saved image is basically equivalent to the VM memory size. Note however that mapped-ram typically uses fewer blocks on disk. Support for mapped-ram+direct-io only recently landed in upstream QEMU and will first appear in the 9.1 release, which may complicate merging support in libvirt. Specifically, I'm not sure how to detect if the combination is supported by QEMU. Suggestions welcomed. Similar to the RFC, V1 ignores compression. libvirt currently supports compression by connecting the output of QEMU's save stream to the specified compression program via a pipe. This approach is incompatible with mapped-ram since the fd provided to QEMU must be seekable. In general, we can consider mapped-ram and compression incompatible and document they cannot be used together. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/EF6… [2] https://gitlab.com/qemu-project/qemu/-/blob/master/docs/devel/migration/map… [3] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/K4B… Claudio Fontana (2): include: Define constants for parallel save/restore tools: add parallel parameter to virsh restore command Jim Fehlig (17): lib: virDomainSaveParams: Ensure absolute save path qemu_fd: Add function to retrieve fdset ID qemu: Add function to check capability in migration params qemu: Add function to get bool value from migration params qemu: Add mapped-ram migration capability qemu: Add function to get migration params for save qemu: QEMU_SAVE_VERSION: Bump to version 3 qemu: conf: Add setting for save image version qemu: Add helper function for creating save image fd qemu: Add support for mapped-ram on save qemu: Decompose qemuSaveImageOpen qemu: Move creation of qemuProcessIncomingDef struct qemu: Apply migration parameters in qemuMigrationDstRun qemu: Add support for mapped-ram on restore qemu: Support O_DIRECT with mapped-ram on save qemu: Support O_DIRECT with mapped-ram on restore qemu: Add support for parallel save and restore Li Zhang (1): tools: add parallel parameter to virsh save command docs/manpages/virsh.rst | 9 +- include/libvirt/libvirt-domain.h | 13 ++ src/libvirt-domain.c | 52 +++++-- src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf.in | 6 + src/qemu/qemu_conf.c | 16 +++ src/qemu/qemu_conf.h | 5 + src/qemu/qemu_driver.c | 104 +++++++++----- src/qemu/qemu_fd.c | 18 +++ src/qemu/qemu_fd.h | 3 + src/qemu/qemu_migration.c | 192 +++++++++++++++++-------- src/qemu/qemu_migration.h | 9 +- src/qemu/qemu_migration_params.c | 86 ++++++++++++ src/qemu/qemu_migration_params.h | 17 +++ src/qemu/qemu_monitor.c | 39 ++++++ src/qemu/qemu_monitor.h | 5 + src/qemu/qemu_process.c | 120 +++++++++++----- src/qemu/qemu_process.h | 19 ++- src/qemu/qemu_saveimage.c | 216 ++++++++++++++++++++--------- src/qemu/qemu_saveimage.h | 35 +++-- src/qemu/qemu_snapshot.c | 26 ++-- src/qemu/test_libvirtd_qemu.aug.in | 1 + tools/virsh-domain.c | 79 +++++++++-- 23 files changed, 827 insertions(+), 244 deletions(-) -- 2.35.3

4 47

[PATCH v2 0/4] fix AppArmor policy restore for runtime rules
by Georgia Garcia 07 Jan '25

07 Jan '25

Some rules are generated dynamically during boot and added to the AppArmor policy. An example of that is macvtap devices that call the AppArmorSetFDLabel hook to add a rule for the tap device path. Since this information is dynamic, it is not available in the xml config, therefore whenever a "Restore" hook is called, the entire profile is regenerated by virt-aa-helper based only the information from the VM definition, so the dynamic/runtime information is lost. This patchset fixes that by storing these rules in a different file called libvirt-uuid.runtime_files, which is included by libvirt-uuid.files that already exists. It also includes other fixes like memory leaks, adoption of the GLib API in the apparmor files and a fix on the AppArmor policy that incorrectly applies apparmor policy syntax. Georgia Garcia (4): security_apparmor: fix memleaks in AppArmorSetFDLabel security: replace uses of label and VIR_FREE by g_autofree apparmor: fix UUID specification virt-aa-helper: store dynamically generated rules .../usr.lib.libvirt.virt-aa-helper.in | 5 +- src/security/apparmor/usr.sbin.libvirtd.in | 7 +- src/security/security_apparmor.c | 83 +++++----- src/security/virt-aa-helper.c | 145 +++++++++--------- 4 files changed, 120 insertions(+), 120 deletions(-) -- 2.34.1

4 11

[PATCH 00/19] hw/microblaze: Allow running cross-endian vCPUs
by Philippe Mathieu-Daudé 02 Jan '25

02 Jan '25

Make machines endianness-agnostic, allowing to run a big-endian vCPU on the little-endian 'qemu-system-microblazeel' binary, and a little endian one on the big-endian 'qemu-system-microblaze' binary. Tests added, following combinations covered: - little-endian vCPU using little-endian binary (in-tree) - little-endian vCPU using big-endian binary (new) - big-endian vCPU using little-endian binary (new) - big-endian vCPU using big-endian binary (in-tree) Deprecate untested big-endian machines, likely build on the big endian binary by mistake: - petalogix-ml605 - xlnx-zynqmp-pmu To make a target endian-agnostic we need to remove the MO_TE uses. In order to do that, we propagate the MemOp from earlier in the call stack, or we extract it from the vCPU env (on MicroBlaze the CPU endianness is exposed by the 'ENDI' bit). Note, since vCPU can run in any endianness, the MemoryRegionOps::endianness should not be DEVICE_NATIVE_ENDIAN anymore, because this definition expand to the binary endianness, swapping data regardless how the vcpu access it. See adjust_endianness() -> devend_memop(). Something to keep in mind, possibly requiring further work and optimizations (avoid double-swap). Next step: Look at unifying binaries. Please review, Phil. Philippe Mathieu-Daudé (19): target/microblaze: Rename CPU endianness property as 'little-endian' hw/microblaze: Deprecate big-endian petalogix-ml605 & xlnx-zynqmp-pmu hw/microblaze/s3adsp1800: Explicit CPU endianness hw/microblaze/s3adsp1800: Rename unimplemented MMIO region as xps_gpio hw/microblaze/s3adsp1800: Declare machine type using DEFINE_TYPES macro hw/microblaze: Fix MemoryRegionOps coding style hw/microblaze: Restrict MemoryRegionOps are implemented as 32-bit hw/microblaze: Propagate CPU endianness to microblaze_load_kernel() hw/intc/xilinx_intc: Only expect big-endian accesses hw/timer/xilinx_timer: Only expect big-endian accesses hw/timer/xilinx_timer: Allow down to 8-bit memory access hw/net/xilinx_ethlite: Only expect big-endian accesses target/microblaze: Explode MO_TExx -> MO_TE | MO_xx target/microblaze: Set MO_TE once in do_load() / do_store() target/microblaze: Introduce mo_endian() helper target/microblaze: Consider endianness while translating code hw/microblaze: Support various endianness for s3adsp1800 machines tests/functional: Explicit endianness of microblaze assets tests/functional: Add microblaze cross-endianness tests docs/about/deprecated.rst | 6 ++ .../devices/microblaze-softmmu/default.mak | 2 - .../devices/microblazeel-softmmu/default.mak | 5 +- hw/microblaze/boot.h | 4 +- target/microblaze/cpu.h | 7 ++ hw/char/xilinx_uartlite.c | 8 ++- hw/intc/xilinx_intc.c | 23 +++++-- hw/microblaze/boot.c | 8 +-- hw/microblaze/petalogix_ml605_mmu.c | 11 ++- hw/microblaze/petalogix_s3adsp1800_mmu.c | 67 +++++++++++++++++-- hw/microblaze/xlnx-zynqmp-pmu.c | 12 ++-- hw/net/xilinx_ethlite.c | 28 ++++++-- hw/timer/xilinx_timer.c | 15 +++-- target/microblaze/cpu.c | 2 +- target/microblaze/translate.c | 49 ++++++++------ .../functional/test_microblaze_s3adsp1800.py | 27 +++++++- .../test_microblazeel_s3adsp1800.py | 25 ++++++- 17 files changed, 236 insertions(+), 63 deletions(-) -- 2.45.2

7 71

[PATCH] util: Change return type of functions that never fail to void
by Alexander Kuznetsov 16 Dec '24

16 Dec '24

These functions return value is invariant since 18f3771, so change its type and remove all dependent checks. Found by Linux Verification Center (linuxtesting.org) with Svace. Reported-by: Pavel Nekrasov <p.nekrasov(a)fobos-nt.ru> Signed-off-by: Alexander Kuznetsov <kuznetsovam(a)altlinux.org> --- src/hypervisor/virhostdev.c | 21 +++++++-------------- src/logging/log_daemon.c | 8 ++------ src/logging/log_daemon_config.c | 4 +--- src/logging/log_daemon_config.h | 2 +- src/util/virpci.c | 4 +--- src/util/virpci.h | 2 +- src/util/virscsi.c | 4 +--- src/util/virscsi.h | 2 +- src/util/virscsivhost.c | 6 ++---- src/util/virscsivhost.h | 2 +- tests/virscsitest.c | 6 ++---- 11 files changed, 20 insertions(+), 41 deletions(-) diff --git a/src/hypervisor/virhostdev.c b/src/hypervisor/virhostdev.c index db94a2e056..037842c8a1 100644 --- a/src/hypervisor/virhostdev.c +++ b/src/hypervisor/virhostdev.c @@ -1131,8 +1131,7 @@ virHostdevUpdateActivePCIDevices(virHostdevManager *mgr, if (!actual) continue; - if (virPCIDeviceSetUsedBy(actual, drv_name, dom_name) < 0) - goto cleanup; + virPCIDeviceSetUsedBy(actual, drv_name, dom_name); /* Setup the original states for the PCI device */ virPCIDeviceSetUnbindFromStub(actual, virBitmapIsBitSet(orig, VIR_DOMAIN_HOSTDEV_PCI_ORIGSTATE_UNBIND)); @@ -1213,11 +1212,9 @@ virHostdevUpdateActiveSCSIHostDevices(virHostdevManager *mgr, return -1; if ((tmp = virSCSIDeviceListFind(mgr->activeSCSIHostdevs, scsi))) { - if (virSCSIDeviceSetUsedBy(tmp, drv_name, dom_name) < 0) - return -1; + virSCSIDeviceSetUsedBy(tmp, drv_name, dom_name); } else { - if (virSCSIDeviceSetUsedBy(scsi, drv_name, dom_name) < 0 || - virSCSIDeviceListAdd(mgr->activeSCSIHostdevs, scsi) < 0) + if (virSCSIDeviceListAdd(mgr->activeSCSIHostdevs, scsi) < 0) return -1; scsi = NULL; } @@ -1598,11 +1595,9 @@ virHostdevPrepareSCSIDevices(virHostdevManager *mgr, goto error; } - if (virSCSIDeviceSetUsedBy(tmp, drv_name, dom_name) < 0) - goto error; + virSCSIDeviceSetUsedBy(tmp, drv_name, dom_name); } else { - if (virSCSIDeviceSetUsedBy(scsi, drv_name, dom_name) < 0) - goto error; + virSCSIDeviceSetUsedBy(scsi, drv_name, dom_name); VIR_DEBUG("Adding %s to activeSCSIHostdevs", virSCSIDeviceGetName(scsi)); @@ -1671,8 +1666,7 @@ virHostdevPrepareSCSIVHostDevices(virHostdevManager *mgr, if (!(host = virSCSIVHostDeviceNew(hostsrc->wwpn))) return -1; - if (virSCSIVHostDeviceSetUsedBy(host, drv_name, dom_name) < 0) - return -1; + virSCSIVHostDeviceSetUsedBy(host, drv_name, dom_name); if (virSCSIVHostDeviceListAdd(list, host) < 0) return -1; @@ -2480,8 +2474,7 @@ virHostdevUpdateActiveNVMeDevices(virHostdevManager *hostdev_mgr, /* We must restore some attributes that were lost on daemon restart. */ virPCIDeviceSetUnbindFromStub(actual, true); - if (virPCIDeviceSetUsedBy(actual, drv_name, dom_name) < 0) - goto rollback; + virPCIDeviceSetUsedBy(actual, drv_name, dom_name); if (virPCIDeviceListAddCopy(hostdev_mgr->activePCIHostdevs, actual) < 0) goto rollback; diff --git a/src/logging/log_daemon.c b/src/logging/log_daemon.c index daf7ef4b2f..5a9be4a44e 100644 --- a/src/logging/log_daemon.c +++ b/src/logging/log_daemon.c @@ -692,14 +692,10 @@ int main(int argc, char **argv) { exit(EXIT_FAILURE); } - /* No explicit config, so try and find a default one */ + /* No explicit config, so find a default one */ if (remote_config_file == NULL) { implicit_conf = true; - if (virLogDaemonConfigFilePath(privileged, - &remote_config_file) < 0) { - VIR_ERROR(_("Can't determine config path")); - exit(EXIT_FAILURE); - } + virLogDaemonConfigFilePath(privileged, &remote_config_file); } /* Read the config file if it exists */ diff --git a/src/logging/log_daemon_config.c b/src/logging/log_daemon_config.c index 248bd927d3..60c424ad84 100644 --- a/src/logging/log_daemon_config.c +++ b/src/logging/log_daemon_config.c @@ -33,7 +33,7 @@ VIR_LOG_INIT("logging.log_daemon_config"); -int +void virLogDaemonConfigFilePath(bool privileged, char **configfile) { if (privileged) { @@ -45,8 +45,6 @@ virLogDaemonConfigFilePath(bool privileged, char **configfile) *configfile = g_strdup_printf("%s/virtlogd.conf", configdir); } - - return 0; } diff --git a/src/logging/log_daemon_config.h b/src/logging/log_daemon_config.h index 43922feedf..5c10cc50d7 100644 --- a/src/logging/log_daemon_config.h +++ b/src/logging/log_daemon_config.h @@ -39,7 +39,7 @@ struct _virLogDaemonConfig { }; -int virLogDaemonConfigFilePath(bool privileged, char **configfile); +void virLogDaemonConfigFilePath(bool privileged, char **configfile); virLogDaemonConfig *virLogDaemonConfigNew(bool privileged); void virLogDaemonConfigFree(virLogDaemonConfig *data); int virLogDaemonConfigLoadFile(virLogDaemonConfig *data, diff --git a/src/util/virpci.c b/src/util/virpci.c index 289c0b330b..90617e69c6 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -2049,7 +2049,7 @@ virPCIDeviceSetReprobe(virPCIDevice *dev, bool reprobe) dev->reprobe = reprobe; } -int +void virPCIDeviceSetUsedBy(virPCIDevice *dev, const char *drv_name, const char *dom_name) @@ -2058,8 +2058,6 @@ virPCIDeviceSetUsedBy(virPCIDevice *dev, VIR_FREE(dev->used_by_domname); dev->used_by_drvname = g_strdup(drv_name); dev->used_by_domname = g_strdup(dom_name); - - return 0; } void diff --git a/src/util/virpci.h b/src/util/virpci.h index ba5e0ae6f1..c5dcf9d37f 100644 --- a/src/util/virpci.h +++ b/src/util/virpci.h @@ -136,7 +136,7 @@ void virPCIDeviceSetStubDriverName(virPCIDevice *dev, const char *driverName); const char *virPCIDeviceGetStubDriverName(virPCIDevice *dev); virPCIDeviceAddress *virPCIDeviceGetAddress(virPCIDevice *dev); -int virPCIDeviceSetUsedBy(virPCIDevice *dev, +void virPCIDeviceSetUsedBy(virPCIDevice *dev, const char *drv_name, const char *dom_name); void virPCIDeviceGetUsedBy(virPCIDevice *dev, diff --git a/src/util/virscsi.c b/src/util/virscsi.c index 3d2c77e3b8..6899958e21 100644 --- a/src/util/virscsi.c +++ b/src/util/virscsi.c @@ -243,7 +243,7 @@ virSCSIDeviceFree(virSCSIDevice *dev) g_free(dev); } -int +void virSCSIDeviceSetUsedBy(virSCSIDevice *dev, const char *drvname, const char *domname) @@ -255,8 +255,6 @@ virSCSIDeviceSetUsedBy(virSCSIDevice *dev, copy->domname = g_strdup(domname); VIR_APPEND_ELEMENT(dev->used_by, dev->n_used_by, copy); - - return 0; } bool diff --git a/src/util/virscsi.h b/src/util/virscsi.h index ec34303bdc..d76ee13bcc 100644 --- a/src/util/virscsi.h +++ b/src/util/virscsi.h @@ -50,7 +50,7 @@ virSCSIDevice *virSCSIDeviceNew(const char *sysfs_prefix, bool shareable); void virSCSIDeviceFree(virSCSIDevice *dev); -int virSCSIDeviceSetUsedBy(virSCSIDevice *dev, +void virSCSIDeviceSetUsedBy(virSCSIDevice *dev, const char *drvname, const char *domname); bool virSCSIDeviceIsAvailable(virSCSIDevice *dev); diff --git a/src/util/virscsivhost.c b/src/util/virscsivhost.c index 15024d7106..05b89e58d6 100644 --- a/src/util/virscsivhost.c +++ b/src/util/virscsivhost.c @@ -193,7 +193,7 @@ virSCSIVHostDeviceListNew(void) } -int +void virSCSIVHostDeviceSetUsedBy(virSCSIVHostDevice *dev, const char *drvname, const char *domname) @@ -202,8 +202,6 @@ virSCSIVHostDeviceSetUsedBy(virSCSIVHostDevice *dev, VIR_FREE(dev->used_by_domname); dev->used_by_drvname = g_strdup(drvname); dev->used_by_domname = g_strdup(domname); - - return 0; } @@ -214,7 +212,7 @@ virSCSIVHostDeviceGetUsedBy(virSCSIVHostDevice *dev, { *drv_name = dev->used_by_drvname; *dom_name = dev->used_by_domname; - } +} int diff --git a/src/util/virscsivhost.h b/src/util/virscsivhost.h index a7299382db..caaac26328 100644 --- a/src/util/virscsivhost.h +++ b/src/util/virscsivhost.h @@ -50,7 +50,7 @@ void virSCSIVHostDeviceListDel(virSCSIVHostDeviceList *list, virSCSIVHostDevice *dev); virSCSIVHostDeviceList *virSCSIVHostDeviceListNew(void); virSCSIVHostDevice *virSCSIVHostDeviceNew(const char *name); -int virSCSIVHostDeviceSetUsedBy(virSCSIVHostDevice *dev, +void virSCSIVHostDeviceSetUsedBy(virSCSIVHostDevice *dev, const char *drvname, const char *domname); void virSCSIVHostDeviceGetUsedBy(virSCSIVHostDevice *dev, diff --git a/tests/virscsitest.c b/tests/virscsitest.c index c96699e157..2c3b599c7a 100644 --- a/tests/virscsitest.c +++ b/tests/virscsitest.c @@ -87,14 +87,12 @@ test2(const void *data G_GNUC_UNUSED) if (!virSCSIDeviceIsAvailable(dev)) goto cleanup; - if (virSCSIDeviceSetUsedBy(dev, "QEMU", "fc18") < 0) - goto cleanup; + virSCSIDeviceSetUsedBy(dev, "QEMU", "fc18"); if (virSCSIDeviceIsAvailable(dev)) goto cleanup; - if (virSCSIDeviceSetUsedBy(dev, "QEMU", "fc20") < 0) - goto cleanup; + virSCSIDeviceSetUsedBy(dev, "QEMU", "fc20"); if (virSCSIDeviceIsAvailable(dev)) goto cleanup; -- 2.42.2

3 24