December 2024 - Devel - libvirt List Archives

[PATCH] apparmor: Allow running loongarch64 VMs on Debian 12
by Xianglai Li 06 Jan '25

06 Jan '25

Allows to load firmware in the qemu-efi-loongarch64 directory Allows the binary qemu-system-loongarch64 to be run This makes it impossible to run loongarch64 VMs when AppArmor is enabled Signed-off-by: Xianglai Li <lixianglai(a)loongson.cn> --- src/security/apparmor/libvirt-qemu.in | 1 + src/security/virt-aa-helper.c | 1 + 2 files changed, 2 insertions(+) diff --git a/src/security/apparmor/libvirt-qemu.in b/src/security/apparmor/libvirt-qemu.in index 694da26dea..c63077574e 100644 --- a/src/security/apparmor/libvirt-qemu.in +++ b/src/security/apparmor/libvirt-qemu.in @@ -144,6 +144,7 @@ /usr/bin/qemu-system-hppa rmix, /usr/bin/qemu-system-i386 rmix, /usr/bin/qemu-system-lm32 rmix, + /usr/bin/qemu-system-loongarch64 rmix, /usr/bin/qemu-system-m68k rmix, /usr/bin/qemu-system-microblaze rmix, /usr/bin/qemu-system-microblazeel rmix, diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index 1cf9d7ad3d..94a28bf331 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -481,6 +481,7 @@ valid_path(const char *path, const bool readonly) "/usr/share/AAVMF/", "/usr/share/qemu-efi/", /* for AAVMF images */ "/usr/share/qemu-efi-aarch64/", + "/usr/share/qemu-efi-loongarch64/", "/usr/share/qemu-efi-riscv64/", "/usr/share/qemu/", /* SUSE path for OVMF and AAVMF images */ "/usr/lib/u-boot/", -- 2.39.1

3 5

[PATCH] hyperv: Introduce and export 'facility' variable.
by Michal Privoznik 06 Jan '25

06 Jan '25

In its upstream commit [1] openwsman dropped 'facility' variable which is documented as: * all processes that use the libu must define a "facility" variable somewhere * to satisfy this external linkage reference. * * Such variable will be used as the syslog(3) facility argument. Well, prior to that commit, openwsman itself declared the variable (and set it to LOG_DAEMON). Now it's up to us. Yeah, the variable naming is terrible and also I we are not using libu directly, but apparently libwsman.so requires it anyway: $ objdump -T /usr/lib64/libwsman.so | grep facility 0000000000000000 D *UND* 0000000000000000 Base facility 1: https://github.com/Openwsman/openwsman/commit/d72c51f21b9c85a773b7955ac587d… Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/hyperv/hyperv_wmi.c | 3 +++ src/libvirt_hyperv.syms | 11 +++++++++++ src/meson.build | 6 ++++++ 3 files changed, 20 insertions(+) create mode 100644 src/libvirt_hyperv.syms diff --git a/src/hyperv/hyperv_wmi.c b/src/hyperv/hyperv_wmi.c index 0b82f1f131..040bcfec11 100644 --- a/src/hyperv/hyperv_wmi.c +++ b/src/hyperv/hyperv_wmi.c @@ -28,6 +28,7 @@ #include <wsman-soap.h> #include <wsman-xml.h> #include <wsman-xml-binding.h> +#include <u/syslog.h> #include "internal.h" #include "virerror.h" @@ -47,6 +48,8 @@ VIR_LOG_INIT("hyperv.hyperv_wmi"); +int facility = LOG_DAEMON; + int hypervGetWmiClassList(hypervPrivate *priv, hypervWmiClassInfo *wmiInfo, virBuffer *query, hypervObject **wmiClass) diff --git a/src/libvirt_hyperv.syms b/src/libvirt_hyperv.syms new file mode 100644 index 0000000000..60e98db473 --- /dev/null +++ b/src/libvirt_hyperv.syms @@ -0,0 +1,11 @@ +# +# HyperV-specific symbols +# + +# hyperv/hyperv_wmi.c +facility; + +# Let emacs know we want case-insensitive sorting +# Local Variables: +# sort-fold-case: t +# End: diff --git a/src/meson.build b/src/meson.build index b53ea2a71f..cce89fac27 100644 --- a/src/meson.build +++ b/src/meson.build @@ -125,6 +125,12 @@ else sym_files += 'libvirt_libssh2.syms' endif +if conf.has('WITH_HYPERV') + used_sym_files += 'libvirt_hyperv.syms' +else + sym_files += 'libvirt_hyperv.syms' +endif + # variables filled by subdirectories libvirt_libs = [] -- 2.45.2

2 1

[PATCH 0/2] po: handle translatin of polkit policy file strings
by Daniel P. Berrangé 04 Jan '25

04 Jan '25

There was a proposal https://gitlab.com/libvirt/libvirt/-/merge_requests/387 to add translations for the polkit files. In reviewing this we came to the conclusion the approach was undesirable. After getting misled by a Debian/Ubuntu specific downstream only patch to polkit which auto-translated polkit files at runtime, this implements the manual approach of merging translations into the polkit files at build time. Daniel P. Berrangé (2): po: add its rules for translating polkit file strings remote: apply translations to polkit files meson.build | 5 +++++ po/POTFILES | 2 ++ po/its/polkit.its | 8 ++++++++ po/its/polkit.loc | 6 ++++++ po/meson.build | 3 +-- src/access/meson.build | 18 ++++++++++++++---- .../{libvirtd.policy => libvirtd.policy.in} | 0 src/remote/meson.build | 13 ++++++++----- 8 files changed, 44 insertions(+), 11 deletions(-) create mode 100644 po/its/polkit.its create mode 100644 po/its/polkit.loc rename src/remote/{libvirtd.policy => libvirtd.policy.in} (100%) -- 2.46.0

2 4

[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] docs: Clarify what source and name attributes of TPM profile describe
by Stefan Berger 30 Dec '24

30 Dec '24

Clarify what source and name attributes of TPM profile describe and update the version placeholder to the libvirt version when profiles were first supported, v10.10. Also mention that profiles with prefix 'custom:' in their name can be modified. Signed-off-by: Stefan Berger <stefanb(a)linux.vnet.ibm.com> --- docs/formatdomain.rst | 29 +++++++++++++++++------------ 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 60bee8bd4f..0a56a96ea4 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -8303,27 +8303,32 @@ Example: usage of external TPM emulator :since:`Since 9.0.0` ``profile`` The ``profile`` node is used to set a profile for a TPM 2.0 given in the - source attribute. This profile will be set when the TPM is initially - created and after that cannot be changed anymore. Once a profile has been - set the name attribute will be updated with the name of the profile that - is running. If no profile is provided, then swtpm will use the latest - built-in 'default' profile or the default profile set in swtpm_setup.conf. - Otherwise swtpm_setup will search for a profile with the given name with - appended .json suffix in a configurable local and then in a distro - directory. If none could be found in either, it will fall back trying to - use a built-in one. + ``source`` attribute. This attribute describes the name of the file under + which the profile is stored, e.g. 'local:restricted' describes a locally + created profile with name 'restricted.json' that is found in the directory + pointed to by swtpm_setup.conf's local_profiles_dir. This profile will be set + when the TPM is initially created and after that the profile cannot be + changed anymore. Once a profile has been set, the ``name`` attribute will be + updated with the profile's name from its JSON description, for example + 'custom:restricted'. If no profile is provided, then swtpm will use the + latest built-in 'default' profile or the default profile set in + swtpm_setup.conf. Otherwise swtpm_setup will search for a profile with the + given name with appended .json suffix in a configurable local and then in a + distro directory. If none could be found in either, it will fall back trying + to use a built-in one. The built-in 'null' profile provides backwards compatibility with libtpms v0.9 but also restricts the user to use only TPM features that were - available at the time of libtpms v0.9. The built-in 'custom' profile is the - only profile that a user can modify and where the ``removeDisabled`` + available at the time of libtpms v0.9. The built-in 'custom' profile, or + those with the prefix 'custom:' in the name, are the + only profiles that a user can modify and where the ``removeDisabled`` attribute has any effect. This attribute is particularly useful when a host is running in FIPS mode and therefore some crypto algorithms (camellia, tdes, unpadded RSA encryption, 1024-bit RSA keys, and others) are disabled. When it is set to ``check`` (recommended) then only those algorithms that are currently disabled will automatically be removed from the 'custom' profile, while when it is set to ``fips-host`` then all - potentially disabled algorithms will be removed. :since:`Since 10.??.0` + potentially disabled algorithms will be removed. :since:`Since 10.10.0` TPM profiles provided by a distro can be referenced with the 'distro:' prefix. Locally created TPM profiles can be referenced with the -- 2.47.1

2 1

[PATCH 0/1] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Akio Kakuno 27 Dec '24

27 Dec '24

Hi, all. - This patch adds Arm CCA support to qemu driver for aarch64 system. CCA is an abbreviation for Arm Confidential Compute Architecture feature, it enhances the virtualization capabilities of the platform by separating the management of resources from access to those resources. - We are not yet at the stage where we can merge this patch as host linux/qemu suppor is no yet merged, but I would like to receive reviews and comments on the overall direction. [summary] - At this stage, all you can do is getting the CCA capability with the virsh domcapabilities command and start the CCA VM with the virsh create command. - capability info uses qemu QMP to query qemu options. The option that exists now is for selecting a hash algorithm. [Capability example] - Execution results of 'virsh domcapability" on qemu <domaincapabilities> ... <features> ... </sgx> <cca supported='yes'> <enum name='measurement-algo'> <value>sha256</value> <value>sha512</value> </enum> </cca> <hyperv supported='yes'> ... </features> </domaincapabilities> [XML example] <domain> ... <launchsecurity type='cca'> <measurement-algo>sha256</measurement-algo> </launchsecurity> ... </domain> [limitations/tests] - To obtain capability info, it is necessary to support the qemu QMP command, which qemu does not yet support. Therefore, I put a hack in the code at hand and only confirmed the communication. Also, I think we should check whether CPUFW supports CCA or not in qemu_firmware.c, but it is not yet implemented. - Verified that the CCA VM can be started from virsh create command. [software version] - I followed the steps in Linaro's blog below. https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+an… - The Qemu used was based on Linaro's qemu(9.1.91). https://git.codelinaro.org/linaro/dcap/qemu/-/tree/cca/v3?ref_type=heads Signed-off-by: Akio Kakuno <fj3333bs(a)fujitsu.com> Best Regards. Akio Kakuno (1): RFC: Add Arm CCA support for getting capability information and running Realm VM docs/formatdomain.rst | 28 ++++++ docs/formatdomaincaps.rst | 26 ++++- src/conf/domain_capabilities.c | 41 ++++++++ src/conf/domain_capabilities.h | 12 +++ src/conf/domain_conf.c | 13 +++ src/conf/domain_conf.h | 7 ++ src/conf/schemas/domaincaps.rng | 14 +++ src/conf/schemas/domaincommon.rng | 14 +++ src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 156 ++++++++++++++++++++++++++++++ src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 32 ++++++ src/qemu/qemu_driver.c | 2 + src/qemu/qemu_monitor.c | 10 ++ src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 104 ++++++++++++++++++++ src/qemu/qemu_monitor_json.h | 4 + src/qemu/qemu_namespace.c | 2 + src/qemu/qemu_process.c | 4 + src/qemu/qemu_validate.c | 7 ++ 22 files changed, 487 insertions(+), 1 deletion(-) -- I previously posted this on the 25th, but it appears it didn't reach the mailing list. Apologies for any duplication. 2.34.1

1 1

[PATCH 0/3] docs: Trivial cleanups
by Philippe Mathieu-Daudé 22 Dec '24

22 Dec '24

Philippe Mathieu-Daudé (3): docs: Correct '-runas' and '-fsdev/-virtfs proxy' indentation docs: Correct release of TCG trace-events removal docs: Replace 'since' -> 'removed in' in removed-features.rst docs/about/deprecated.rst | 2 +- docs/about/removed-features.rst | 24 ++++++++++++------------ 2 files changed, 13 insertions(+), 13 deletions(-) -- 2.47.1

3 7

[RFC v2 PATCH 0/4] iproute2 bridge vlan support
by Leigh Brown 22 Dec '24

22 Dec '24

I have not had any feedback, but have been using this myself and it works very nicely for me. I have updated the patch series to allow vlans to be specified in network/portgroup definitions and that functionality is working well. All feedback gratefully received. Description ----------- The iproute2 bridge command supports the capability for VLAN filtering that allows each interface connected to a standard linux bridge to be configured to use one or more VLANs. For simple setups, this capability is enough to allow virtual machines or containers to be put onto separate VLANs without creating multiple bridges and VLANs on the host. The first patch adds a new function virNetDevBridgeSetupVlans() that will, given a virNetDevVlan structure, execute the required bridge vlan commands to configure the given interface accordingly. The second patch updates the virNetDevBridgeAddPort() function to allow a virNetDevVlan parameter to be passed, and to call the virNetDevBridgeSetupVlans() function. The third patch updates the lxc and tap code to pass the virNetDevLan parameter from the configuration and to update the XML domain and network validation to permit the VLAN-related tags for standard bridges. The fourth patch updates documentation to match the new capability. Changes since v1 ---------------- - Fix bug in virNetDevSetupVlans where bridge port has no native vlan. - Update bridge network validation to permit vlan configuration. - Update documentation to match the functionality. - Tweak some of the commit descriptions for clarity. Usage example ------------- Configure the host with systemd-networkd as follows: /etc/systemd/network/br0.netdev (br0.network not shown) [NetDev] Name=br0 Kind=bridge MACAddress=xx:xx:xx:xx:xx:xx [Bridge] VLANFiltering=on /etc/systemd/network/eno1.network [Match] Name=eno1 [Network] Bridge=br0 [Link] MTUBytes=9000 [BridgeVLAN] VLAN=40 [BridgeVLAN] VLAN=60 Then add <vlan> tags into the lxc or qemu config: lxc interface definition: <interface type='bridge'> <mac address='xx:xx:xx:xx:xx:xx'/> <source bridge='br0'/> <vlan> <tag id='40'/> </vlan> </interface> qemu interface definition: <interface type='network'> <mac address='xx:xx:xx:xx:xx:xx'/> <source network='br0'/> <vlan> <tag id='60'/> </vlan> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> Then, after starting them, you will see the following $ sudo bridge vlan port vlan-id eno1 1 PVID Egress Untagged 40 60 br0 1 PVID Egress Untagged vnet0 60 PVID Egress Untagged vnet1 40 PVID Egress Untagged Regards, Leigh Brown (4): util: Add virNetDevBridgeSetupVlans function util: Add vlan support to virNetDevBridgeAddPort Enable vlan support for standard linux bridges docs: standard linux bridges now support vlans docs/formatdomain.rst | 37 ++++++++++---------- docs/formatnetwork.rst | 45 ++++++++++++------------ meson.build | 1 + src/conf/domain_validate.c | 3 +- src/lxc/lxc_process.c | 3 +- src/network/bridge_driver.c | 13 ++++--- src/util/virnetdevbridge.c | 68 ++++++++++++++++++++++++++++++++++--- src/util/virnetdevbridge.h | 4 ++- src/util/virnetdevtap.c | 2 +- 9 files changed, 123 insertions(+), 53 deletions(-) -- 2.39.5

2 5

[PATCH 00/10] Enabling logging for ch guests
by Praveen K Paladugu 21 Dec '24

21 Dec '24

LogContext management is now moved from Qemu driver to hypervisor. After migrating Qemu to use domain_logcontext, I extended ch driver to use also use domain_logcontext to capture early boot failures within domain specific log files. Changes in V2: * refactored the patches to ensure all of them build. Praveen K Paladugu (10): hypervisor: copy qemu log context mgmt to hypervisor hypervisor: rename reference to qemu in domain_logcontext hypervisor: drop qemu specific args in domainLogContextNew hypervisor: Build domain_logcontext libvirt_private: export symbols from domain_logcontext qemu: Modify qemu driver to use domainLogContext qemu: delete qemu_logcontext files ch: Enable logging for ch domains ch: move curl_data and curl_callback definitions ch: Enable logging curl responses from ch po/POTFILES | 2 +- src/ch/ch_conf.h | 2 + src/ch/ch_monitor.c | 84 ++++++++++++------- src/ch/ch_monitor.h | 6 +- src/ch/ch_process.c | 36 ++++++-- .../domain_logcontext.c} | 78 +++++++++-------- src/hypervisor/domain_logcontext.h | 45 ++++++++++ src/hypervisor/meson.build | 1 + src/libvirt_private.syms | 6 ++ src/qemu/meson.build | 1 - src/qemu/qemu_domain.c | 28 +++---- src/qemu/qemu_domain.h | 12 +-- src/qemu/qemu_logcontext.h | 41 --------- src/qemu/qemu_nbdkit.c | 12 ++- src/qemu/qemu_process.c | 45 +++++----- 15 files changed, 235 insertions(+), 164 deletions(-) rename src/{qemu/qemu_logcontext.c => hypervisor/domain_logcontext.c} (79%) create mode 100644 src/hypervisor/domain_logcontext.h delete mode 100644 src/qemu/qemu_logcontext.h -- 2.47.0

2 12

[PATCH 0/2] Add more hyperv tlbflush features
by Martin Kletzander 21 Dec '24

21 Dec '24

That's about it... Martin Kletzander (2): conf, docs: Add support for direct and extended tlbflush features qemu: Add support for direct and extended tlbflush features docs/formatdomain.rst | 13 ++++++---- src/conf/domain_conf.c | 26 ++++++++++++++++++- src/conf/domain_conf.h | 2 ++ src/conf/schemas/domaincommon.rng | 21 ++++++++++++++- src/cpu/cpu_x86.c | 7 +++++ src/cpu/cpu_x86_data.h | 2 ++ src/qemu/qemu_command.c | 6 +++++ src/qemu/qemu_process.c | 24 +++++++++++++++++ .../qemuxmlconfdata/hyperv.x86_64-latest.args | 2 +- tests/qemuxmlconfdata/hyperv.xml | 5 +++- 10 files changed, 99 insertions(+), 9 deletions(-) -- 2.47.1

2 3