July 2024 - Devel - libvirt List Archives

[PATCH] NEWS: Document features/improvements/bug fixes I've participated in
by Michal Privoznik 30 Jul '24

30 Jul '24

There are some features/improvements/bug fixes I've either contributed or reviewed/merged. Document them for upcoming release. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- NEWS.rst | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 17335b3f6e..1a320c5442 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -28,8 +28,42 @@ v10.6.0 (unreleased) * **Improvements** + * qemu: Set 'passt' net backend if 'default' is unsupported + + If QEMU is compiled without SLIRP support, and if domain XML allows it, + starting from this release libvirt will use passt as the default backend + instead. Also, supported backends are now reported in the domain + capabilities XML. + + * qemu: Require QEMU-5.2.0 or newer + + The minimal required version of QEMU was bumped to 5.2.0. + + * qemu: add a monitor to /proc/$pid when killing times out + + In cases when a QEMU process takes longer to be killed, libvirt might have + skipped cleaning up after it. But now a /proc/$pid watch is installed so + this does not happen ever again. + * **Bug fixes** + * virt-aa-helper: Allow RO access to /usr/share/edk2-ovmf + + When binary version of edk2 is distributed, the files reside under + /usr/share/edk2-ovmf. Allow virt-aa-helper to generate paths under that + directory. + + * virt-host-validate: Allow longer list of CPU flags + + During its run, virt-host-validate parses /proc/cpuinfo to learn about CPU + flags. But due to a bug it parsed only the first 1024 bytes worth of CPU + flags leading to unexpected results. The file is now parsed properly. + + * capabilities: Be more forgiving when decoding OEM strings + + On some systems, OEM strings are scattered in multiple sections. This + confused libvirt when generating capabilities XML. Not anymore. + v10.5.0 (2024-07-01) ==================== -- 2.44.2

3 2

Arm CCA instance creation fails
by Itaru Kitayama 30 Jul '24

30 Jul '24

Hi, With the below virt-install options, I am trying to import a Realm VM: […] export LIBVIRT_QEMU=/home/realm/qemu-system-aarch64 virt-install --machine=virt --arch=aarch64 --name=test8 --disk path=/var/lib/libvirt/images/jammy.qcow2,format=qcow2,device=disk,bus=virtio,cache=none --memory=2048 --vcpu=8 --nographic --check all=off --features acpi=off --import --os-variant=ubuntu22.04 --qemu-commandline="-M virt,confidential-guest-support=rme0,acpi=off,gic-version=3 -cpu host -object rme-guest,id=rme0,measurement-algo=sha512" --boot kernel=Image-cca,initrd=rootfs.cpio […] However, it fails with the messages: WARNING Disk /var/lib/libvirt/images/jammy.qcow2 is already in use by other guests ['test', 'tmp1', 'jammy']. Starting install... ERROR internal error: QEMU unexpectedly closed the monitor (vm='test8'): 2024-07-22T06:40:39.290847Z qemu-system-aarch64: could not load kernel '/home/realm/Image-cca' Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///system start test8 otherwise, please restart your installation. The libvirt packages are from Ubuntu 24.04 LTS, but QEMU is the one Linaro folk maintain. Am I using the opions wrong for kernel direct boot scenario? Thanks, Itaru.

2 2

Entering freeze for libvirt-10.6.0
by Jiri Denemark 29 Jul '24

29 Jul '24

I have just tagged v10.6.0-rc1 in the repository and pushed signed tarballs to https://download.libvirt.org/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Thanks, Jirka

1 0

[PATCH 0/2] qemuProcessStop: Don't unlock domain during cleanup
by Michal Privoznik 26 Jul '24

26 Jul '24

Technically, this is a v2 of: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/C6QP… but it implements completely different approach, so I'm starting a new thread. Michal Prívozník (2): vireventthread: Introduce virEventThreadStop qemu: Use virEventThreadStop() in qemuProcessStop() src/libvirt_private.syms | 1 + src/qemu/qemu_process.c | 14 ++++++++++---- src/util/vireventthread.c | 22 ++++++++++++++++++++++ src/util/vireventthread.h | 2 ++ 4 files changed, 35 insertions(+), 4 deletions(-) -- 2.44.2

5 12

[PATCH RESEND 0/5] Introduce pstore device
by Michal Privoznik 26 Jul '24

26 Jul '24

This is a rebased version of: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/UAUK… which was a rebased version of: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/VWR6… Let's hope no more resends will be needed. Michal Prívozník (5): qemu_capabilities: Introduce QEMU_CAPS_DEVICE_ACPI_ERST conf: Introduce pstore device qemu: Build cmd line for pstore device security: Set seclabels for pstore device NEWS: Document pstore device addition NEWS.rst | 7 + docs/formatdomain.rst | 32 ++++ src/ch/ch_domain.c | 1 + src/conf/domain_conf.c | 153 ++++++++++++++++++ src/conf/domain_conf.h | 19 +++ src/conf/domain_postparse.c | 1 + src/conf/domain_validate.c | 30 ++++ src/conf/schemas/domaincommon.rng | 25 +++ src/conf/virconftypes.h | 2 + src/hyperv/hyperv_driver.c | 1 + src/libvirt_private.syms | 2 + src/libxl/libxl_driver.c | 6 + src/lxc/lxc_driver.c | 6 + src/qemu/qemu_alias.c | 10 ++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 52 ++++++ src/qemu/qemu_domain.c | 3 + src/qemu/qemu_domain_address.c | 11 ++ src/qemu/qemu_driver.c | 3 + src/qemu/qemu_hotplug.c | 5 + src/qemu/qemu_validate.c | 26 +++ src/security/security_dac.c | 10 ++ src/security/security_selinux.c | 9 ++ src/security/virt-aa-helper.c | 4 + src/test/test_driver.c | 1 + .../caps_7.0.0_aarch64+hvf.xml | 1 + .../caps_7.0.0_aarch64.xml | 1 + .../qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 1 + .../caps_7.0.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 1 + .../caps_7.1.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 1 + .../caps_7.2.0_x86_64+hvf.xml | 1 + .../caps_7.2.0_x86_64.xml | 1 + .../caps_8.0.0_x86_64.xml | 1 + .../caps_8.1.0_x86_64.xml | 1 + .../caps_8.2.0_aarch64.xml | 1 + .../caps_8.2.0_armv7l.xml | 1 + .../caps_8.2.0_loongarch64.xml | 1 + .../caps_8.2.0_x86_64.xml | 1 + .../caps_9.0.0_x86_64.xml | 1 + .../caps_9.1.0_x86_64.xml | 1 + .../pstore-acpi-erst.x86_64-latest.args | 38 +++++ .../pstore-acpi-erst.x86_64-latest.xml | 1 + tests/qemuxmlconfdata/pstore-acpi-erst.xml | 53 ++++++ tests/qemuxmlconftest.c | 1 + 47 files changed, 532 insertions(+) create mode 100644 tests/qemuxmlconfdata/pstore-acpi-erst.x86_64-latest.args create mode 120000 tests/qemuxmlconfdata/pstore-acpi-erst.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/pstore-acpi-erst.xml -- 2.44.2

3 9

[PATCH 0/4] Rework qemu internal active snapshots to use QMP
by Nikolai Barybin 26 Jul '24

26 Jul '24

These patches make use of QMP recently added snapshot-save/delete commands and reaps HMP savevm/deletevm. The usage of HMP commands are highly discouraged by QEMU. Nikolai Barybin (4): qemu monitor: add snaphot-save/delete QMP commands qemu blockjob: add snapshot-save/delete job types qemu snapshot: use QMP snapshot-save/delete for internal snapshots qemu monitor: reap qemu_monitor_text po/POTFILES | 1 - po/libvirt.pot | 18 ---- src/qemu/meson.build | 1 - src/qemu/qemu_block.c | 2 + src/qemu/qemu_blockjob.c | 6 +- src/qemu/qemu_blockjob.h | 2 + src/qemu/qemu_domain.c | 4 + src/qemu/qemu_monitor.c | 23 +++-- src/qemu/qemu_monitor.h | 16 +++- src/qemu/qemu_monitor_json.c | 66 +++++++++++++++ src/qemu/qemu_monitor_json.h | 13 +++ src/qemu/qemu_monitor_text.c | 88 ------------------- src/qemu/qemu_monitor_text.h | 29 ------- src/qemu/qemu_snapshot.c | 158 ++++++++++++++++++++++++++++++++--- 14 files changed, 267 insertions(+), 160 deletions(-) delete mode 100644 src/qemu/qemu_monitor_text.c delete mode 100644 src/qemu/qemu_monitor_text.h -- 2.43.5

4 12

[PATCH-for-9.1] target/riscv: Remove the deprecated 'any' CPU type
by Philippe Mathieu-Daudé 26 Jul '24

26 Jul '24

The 'any' CPU is deprecated since commit f57d5f8004b ("target/riscv: deprecate the 'any' CPU type"). Users are better off using the default CPUs or the 'max' CPU. Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org> --- docs/about/deprecated.rst | 13 ------------- docs/about/removed-features.rst | 8 ++++++++ target/riscv/cpu-qom.h | 1 - target/riscv/cpu.c | 28 ---------------------------- 4 files changed, 8 insertions(+), 42 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 88f0f037865..0ac49b15b44 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -347,19 +347,6 @@ QEMU's ``vhost`` feature, which would eliminate the high latency costs under which the 9p ``proxy`` backend currently suffers. However as of to date nobody has indicated plans for such kind of reimplementation unfortunately. -RISC-V 'any' CPU type ``-cpu any`` (since 8.2) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The 'any' CPU type was introduced back in 2018 and has been around since the -initial RISC-V QEMU port. Its usage has always been unclear: users don't know -what to expect from a CPU called 'any', and in fact the CPU does not do anything -special that isn't already done by the default CPUs rv32/rv64. - -After the introduction of the 'max' CPU type, RISC-V now has a good coverage -of generic CPUs: rv32 and rv64 as default CPUs and 'max' as a feature complete -CPU for both 32 and 64 bit builds. Users are then discouraged to use the 'any' -CPU type starting in 8.2. - RISC-V CPU properties which start with capital 'Z' (since 8.2) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst index fc7b28e6373..f3e9474a73e 100644 --- a/docs/about/removed-features.rst +++ b/docs/about/removed-features.rst @@ -850,6 +850,14 @@ The RISC-V no MMU cpus have been removed. The two CPUs: ``rv32imacu-nommu`` and ``rv64imacu-nommu`` can no longer be used. Instead the MMU status can be specified via the CPU ``mmu`` option when using the ``rv32`` or ``rv64`` CPUs. +RISC-V 'any' CPU type ``-cpu any`` (removed in 9.1) +''''''''''''''''''''''''''''''''''''''''''''''''''' + +The 'any' CPU type was introduced back in 2018 and was around since the +initial RISC-V QEMU port. Its usage was always been unclear: users don't know +what to expect from a CPU called 'any', and in fact the CPU does not do anything +special that isn't already done by the default CPUs rv32/rv64. + ``compat`` property of server class POWER CPUs (removed in 6.0) ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' diff --git a/target/riscv/cpu-qom.h b/target/riscv/cpu-qom.h index 3670cfe6d9a..4464c0fd7a3 100644 --- a/target/riscv/cpu-qom.h +++ b/target/riscv/cpu-qom.h @@ -29,7 +29,6 @@ #define RISCV_CPU_TYPE_SUFFIX "-" TYPE_RISCV_CPU #define RISCV_CPU_TYPE_NAME(name) (name RISCV_CPU_TYPE_SUFFIX) -#define TYPE_RISCV_CPU_ANY RISCV_CPU_TYPE_NAME("any") #define TYPE_RISCV_CPU_MAX RISCV_CPU_TYPE_NAME("max") #define TYPE_RISCV_CPU_BASE32 RISCV_CPU_TYPE_NAME("rv32") #define TYPE_RISCV_CPU_BASE64 RISCV_CPU_TYPE_NAME("rv64") diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index a90808a3bac..4bda754b013 100644 --- a/target/riscv/cpu.c +++ b/target/riscv/cpu.c @@ -438,27 +438,6 @@ static void set_satp_mode_default_map(RISCVCPU *cpu) } #endif -static void riscv_any_cpu_init(Object *obj) -{ - RISCVCPU *cpu = RISCV_CPU(obj); - CPURISCVState *env = &cpu->env; - riscv_cpu_set_misa_ext(env, RVI | RVM | RVA | RVF | RVD | RVC | RVU); - -#ifndef CONFIG_USER_ONLY - set_satp_mode_max_supported(RISCV_CPU(obj), - riscv_cpu_mxl(&RISCV_CPU(obj)->env) == MXL_RV32 ? - VM_1_10_SV32 : VM_1_10_SV57); -#endif - - env->priv_ver = PRIV_VERSION_LATEST; - - /* inherited from parent obj via riscv_cpu_init() */ - cpu->cfg.ext_zifencei = true; - cpu->cfg.ext_zicsr = true; - cpu->cfg.mmu = true; - cpu->cfg.pmp = true; -} - static void riscv_max_cpu_init(Object *obj) { RISCVCPU *cpu = RISCV_CPU(obj); @@ -1161,11 +1140,6 @@ static void riscv_cpu_realize(DeviceState *dev, Error **errp) RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(dev); Error *local_err = NULL; - if (object_dynamic_cast(OBJECT(dev), TYPE_RISCV_CPU_ANY) != NULL) { - warn_report("The 'any' CPU is deprecated and will be " - "removed in the future."); - } - cpu_exec_realizefn(cs, &local_err); if (local_err != NULL) { error_propagate(errp, local_err); @@ -2952,7 +2926,6 @@ static const TypeInfo riscv_cpu_type_infos[] = { .abstract = true, }, #if defined(TARGET_RISCV32) - DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_ANY, MXL_RV32, riscv_any_cpu_init), DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_MAX, MXL_RV32, riscv_max_cpu_init), DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_BASE32, MXL_RV32, rv32_base_cpu_init), DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_IBEX, MXL_RV32, rv32_ibex_cpu_init), @@ -2962,7 +2935,6 @@ static const TypeInfo riscv_cpu_type_infos[] = { DEFINE_BARE_CPU(TYPE_RISCV_CPU_RV32I, MXL_RV32, rv32i_bare_cpu_init), DEFINE_BARE_CPU(TYPE_RISCV_CPU_RV32E, MXL_RV32, rv32e_bare_cpu_init), #elif defined(TARGET_RISCV64) - DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_ANY, MXL_RV64, riscv_any_cpu_init), DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_MAX, MXL_RV64, riscv_max_cpu_init), DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_BASE64, MXL_RV64, rv64_base_cpu_init), DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_SIFIVE_E51, MXL_RV64, rv64_sifive_e_cpu_init), -- 2.45.2

3 3

[PATCH 0/5] virsysinfo: Be more forgiving when decoding OEM strings
by Michal Privoznik 25 Jul '24

25 Jul '24

See 4/5 for explanation. Michal Prívozník (5): vircommand: Initialize dryRunStatus to portable EXIT_SUCCESS instead of 0 virsysinfo: Trim newline when decoding OEM strings tests: Add HPE Apollo test case to sysinfotest virsysinfo: Be more forgiving when decoding OEM strings virsysinfo: Calculate OEM string index better src/util/vircommand.c | 2 +- src/util/virsysinfo.c | 36 +++- .../aarch64-hpe-apollosysinfo.data | 162 ++++++++++++++++++ .../aarch64-hpe-apollosysinfo.expect | 88 ++++++++++ tests/sysinfotest.c | 9 +- 5 files changed, 285 insertions(+), 12 deletions(-) create mode 100644 tests/sysinfodata/aarch64-hpe-apollosysinfo.data create mode 100644 tests/sysinfodata/aarch64-hpe-apollosysinfo.expect -- 2.44.2

2 7

[PATCH] vmx: Ensure unique disk targets when parsing
by Adam Julis 24 Jul '24

24 Jul '24

Disk targets were generated in virVMXParseConfig() with virVMXGenerateDiskTarget(). It works on combination of controller, fix offset, unit and prefix. While SCSI and SATA have same prefix "sd", function virVMXGenerateDiskTarget() could returned in some cases same targets. In this patch, after loaded SCSI and SATA disks to the def, it checks if in array exists any SATA disks after SCSI. If not, nothing happened. If yes, targets of all SATA disks are changed. Disk target is calculated as: last SCSI target value + n, where n is position of disk in array after last SCSI (1,2,..). Because assigned addresses of disks are generated from their indexes, for every changed SATA disk is called virDomainDiskDefAssignAddress() with the updated value. The corresponding tests have been modified to match the index changes. Signed-off-by: Adam Julis <ajulis(a)redhat.com> --- src/vmx/vmx.c | 32 ++++++++++++++++++++++++ tests/vmx2xmldata/esx-in-the-wild-12.xml | 4 +-- tests/vmx2xmldata/esx-in-the-wild-8.xml | 4 +-- 3 files changed, 36 insertions(+), 4 deletions(-) diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c index 227744d062..9fdf0f1cd4 100644 --- a/src/vmx/vmx.c +++ b/src/vmx/vmx.c @@ -1389,6 +1389,9 @@ virVMXParseConfig(virVMXContext *ctx, bool smbios_reflecthost = false; int controller; int bus; + int ndisk; + int last_scsi; + int offset = -1; int port; bool present; int scsi_virtualDev[4] = { -1, -1, -1, -1 }; @@ -1805,6 +1808,35 @@ virVMXParseConfig(virVMXContext *ctx, } } + /* now disks contain only SCSI and SATA, SATA could have same index (dst) as SCSI + * find last SCSI index in array and use it as offset for all SATA indexes + * (overwrite old values) + * finally, regenerate correct addresses, while it depends on the index */ + for (ndisk = 0; ndisk < def->ndisks; ndisk++) { + virDomainDiskDef *dsc = def->disks[ndisk]; + + if (dsc->bus == VIR_DOMAIN_DISK_BUS_SCSI) { + offset = virDiskNameToIndex(dsc->dst); + last_scsi = ndisk; + continue; + } + + if (offset > -1) { + VIR_FREE(def->disks[ndisk]->dst); + def->disks[ndisk]->dst = virIndexToDiskName(offset + ndisk - last_scsi, "sd"); + + if (virDomainDiskDefAssignAddress(NULL, def->disks[ndisk], def) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Could not assign address to disk '%1$s'"), + virDomainDiskGetSource(dsc)); + goto cleanup; + } + } + + else + break; + } + /* def:disks (ide) */ for (bus = 0; bus < 2; ++bus) { for (unit = 0; unit < 2; ++unit) { diff --git a/tests/vmx2xmldata/esx-in-the-wild-12.xml b/tests/vmx2xmldata/esx-in-the-wild-12.xml index 42184501d0..a7730845ee 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-12.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-12.xml @@ -21,9 +21,9 @@ <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> - <target dev='sda' bus='sata'/> + <target dev='sdb' bus='sata'/> <readonly/> - <address type='drive' controller='0' bus='0' target='0' unit='0'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='scsi' index='0' model='vmpvscsi'/> <controller type='sata' index='0'/> diff --git a/tests/vmx2xmldata/esx-in-the-wild-8.xml b/tests/vmx2xmldata/esx-in-the-wild-8.xml index 47d22ced2a..d5356bda34 100644 --- a/tests/vmx2xmldata/esx-in-the-wild-8.xml +++ b/tests/vmx2xmldata/esx-in-the-wild-8.xml @@ -36,9 +36,9 @@ </disk> <disk type='file' device='cdrom'> <source file='[692eb778-2d4937fe] CentOS-4.7.ServerCD-x86_64.iso'/> - <target dev='sda' bus='sata'/> + <target dev='sdd' bus='sata'/> <readonly/> - <address type='drive' controller='0' bus='0' target='0' unit='0'/> + <address type='drive' controller='0' bus='0' target='0' unit='3'/> </disk> <controller type='scsi' index='0' model='vmpvscsi'/> <controller type='sata' index='0'/> -- 2.45.2

2 1

[libvirt PATCH] qemu: virtiofs: cache: use 'never' instead of 'none'
by Ján Tomko 24 Jul '24

24 Jul '24

The new option style renamed one of the cache modes. Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- src/qemu/qemu_virtiofs.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_virtiofs.c b/src/qemu/qemu_virtiofs.c index 703f1226a2..db987ddfe1 100644 --- a/src/qemu/qemu_virtiofs.c +++ b/src/qemu/qemu_virtiofs.c @@ -147,10 +147,19 @@ qemuVirtioFSBuildCommandLine(virQEMUDriverConfig *cfg, virCommandAddArg(cmd, "--shared-dir"); virCommandAddArg(cmd, fs->src->path); - if (fs->cache) { + switch (fs->cache) { + case VIR_DOMAIN_FS_CACHE_MODE_DEFAULT: + break; + case VIR_DOMAIN_FS_CACHE_MODE_NONE: + virCommandAddArg(cmd, "--cache"); + virCommandAddArg(cmd, "never"); + break; + case VIR_DOMAIN_FS_CACHE_MODE_ALWAYS: virCommandAddArg(cmd, "--cache"); virCommandAddArg(cmd, virDomainFSCacheModeTypeToString(fs->cache)); + break; } + if (fs->sandbox) { virCommandAddArg(cmd, "--sandbox"); virCommandAddArg(cmd, virDomainFSSandboxModeTypeToString(fs->sandbox)); -- 2.45.2

2 1