- Devel - libvirt List Archives

[libvirt PATCH 0/2] network: Drop UUID handling for default network
by Andrea Bolognani 18 Nov '20

18 Nov '20

<blurb>cc30b49f-6084-48da-879e-55645459f2a0</blurb> Andrea Bolognani (2): network: Drop UUID handling for default network spec: Drop UUID handling for default network libvirt.spec.in | 4 ---- src/network/meson.build | 32 +++++++------------------------- 2 files changed, 7 insertions(+), 29 deletions(-) -- 2.26.2

4 13

[libvirt PATCH 0/4] nodedev: cleanup some historical baggage
by Daniel P. Berrangé 17 Nov '20

17 Nov '20

Daniel P. Berrangé (4): nodedev: improve debugging logs from udev device/event processing nodedev: dont rely on ignoring errors on missing properties nodedev: drop DKD_MEDIA_AVAILABLE property check nodedev: report errors about missing integer properties src/node_device/node_device_udev.c | 70 +++++++++++++----------------- 1 file changed, 30 insertions(+), 40 deletions(-) -- 2.28.0

3 7

[PATCH] add phytium FT-2000+ and Tengyun-S2500 support on arm architecture.
by yangshaojun19＠163.com 17 Nov '20

17 Nov '20

From: yangshaojun <yangshaojun(a)phytium.com.cn> Signed-off-by: yangshaojun <yangshaojun(a)phytium.com.cn> --- src/cpu_map/arm_Phytium.xml | 10 ++++++++++ src/cpu_map/arm_vendors.xml | 1 + src/cpu_map/index.xml | 3 +++ 3 files changed, 14 insertions(+) create mode 100644 src/cpu_map/arm_Phytium.xml diff --git a/src/cpu_map/arm_Phytium.xml b/src/cpu_map/arm_Phytium.xml new file mode 100644 index 0000000..f8b4852 --- /dev/null +++ b/src/cpu_map/arm_Phytium.xml @@ -0,0 +1,10 @@ +<cpus> + <model name='FT-2000+'> + <vendor name='Phytium'/> + <pvr value='0x662'/> + </model> + <model name='Tengyun-S2500'> + <vendor name='Phytium'/> + <pvr value='0x663'/> + </model> +</cpus> diff --git a/src/cpu_map/arm_vendors.xml b/src/cpu_map/arm_vendors.xml index ff799ef..4465463 100644 --- a/src/cpu_map/arm_vendors.xml +++ b/src/cpu_map/arm_vendors.xml @@ -11,4 +11,5 @@ <vendor name='Qualcomm' value='0x51'/> <vendor name='Marvell' value='0x56'/> <vendor name='Intel' value='0x69'/> + <vendor name='Phytium' value='0x70'/> </cpus> diff --git a/src/cpu_map/index.xml b/src/cpu_map/index.xml index 08f052e..e2c454b 100644 --- a/src/cpu_map/index.xml +++ b/src/cpu_map/index.xml @@ -103,5 +103,8 @@  <include filename='arm_Kunpeng-920.xml'/> + +  + <include filename='arm_Phytium.xml'/> </arch> </cpus> -- 2.7.4

2 1

[PATCH 0/5] qemu: Don't cache domCaps
by Michal Privoznik 17 Nov '20

17 Nov '20

See 4/5 for explanation. Michal Prívozník (5): qemu: Validate RNG model qemu: Validate video model conf: Drop virDomainCapsDeviceDefValidate() qemu: Don't cache domCaps in virQEMUDriverGetDomainCapabilities() qemu: Remove virQEMUDomainCapsCache code src/conf/domain_capabilities.c | 88 ------------ src/conf/domain_capabilities.h | 4 - src/libvirt_private.syms | 1 - src/qemu/qemu_capabilities.c | 129 ------------------ src/qemu/qemu_capabilities.h | 10 -- src/qemu/qemu_conf.c | 27 ++-- src/qemu/qemu_validate.c | 77 +++++++++-- .../default-video-type-x86_64-caps-test-0.err | 2 +- .../video-invalid-multiple-devices.err | 2 +- 9 files changed, 83 insertions(+), 257 deletions(-) -- 2.26.2

3 9

[libvirt PATCH 0/2] qemu: support kvm-poll-control performance hint
by Tim Wiederhake 17 Nov '20

17 Nov '20

See the commit message of the first patch and https://bugzilla.redhat.com/show_bug.cgi?id=1895204 Tim Wiederhake (2): qemu: support kvm-poll-control performance hint tests: Add tests for kvm-poll-control feature docs/formatdomain.rst | 14 ++++++++------ docs/schemas/domaincommon.rng | 5 +++++ src/conf/domain_conf.c | 4 ++++ src/conf/domain_conf.h | 1 + src/qemu/qemu_command.c | 5 +++++ tests/qemuxml2argvdata/kvm-features-off.xml | 1 + tests/qemuxml2argvdata/kvm-features.args | 2 +- tests/qemuxml2argvdata/kvm-features.xml | 1 + tests/qemuxml2xmloutdata/kvm-features-off.xml | 1 + tests/qemuxml2xmloutdata/kvm-features.xml | 1 + 10 files changed, 28 insertions(+), 7 deletions(-) -- 2.26.2

2 7

[PATCH] node_device: Use "udev" monitor source
by Michal Privoznik 17 Nov '20

17 Nov '20

In v6.3.0-rc1~67 I've made a switch: instead of listening on udev events the nodedev driver started listening for kernel events. This was because when a device changes its name (e.g. NICs) we will get "move" event with DEVPATH_OLD property set, which we can then use to remove the old device and thus keep our internal list up to date. The switch to "kernel" source was made because if the old NICs naming (eth0, eth1, ...) is enabled (e.g. via net.ifnames=0 on the kernel cmd line) then udev overwrites the property with the new name making our internal list go out of sync. Interestingly, when the od NICs naming is not enabled then the DEVPATH_OLD contains the correct value. But as it turns out, "kernel" source might be missing some other important properties, e.g. USB vendor/product IDs. Therefore, switch back to "udev" source and wish the best of luck to users using the old NICs naming. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1897625 Fixes: 9a13704818e4a018723e0ec5b9e97b176f1c8584 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/node_device/node_device_udev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 65f312d8f4..dec19a3166 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1983,7 +1983,7 @@ nodeStateInitialize(bool privileged, virObjectLock(priv); - priv->udev_monitor = udev_monitor_new_from_netlink(udev, "kernel"); + priv->udev_monitor = udev_monitor_new_from_netlink(udev, "udev"); if (!priv->udev_monitor) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("udev_monitor_new_from_netlink returned NULL")); -- 2.26.2

2 3

[Question] sg_persist failed when using qemu-pr-helper
by Zihao Chang 17 Nov '20

17 Nov '20

Hi all, When using qemu-pr-helper，"sg_persist" in guest return Aborted Command after iscsiadm logout & login. My confusion: Is this problem caused by bugs of libvirt/qemu-pr-helper? Or iscsiadm logout & login should be forbidden when using qemu-pr-helper? Or There is something wrong with my config. Steps to Reproduce: 1. setup multipath env 1) set /etc/iscsi/initiatorname.iscsi 2) iscsiadm discovery & login 3) start multipathd 2. add the following xml to guest <disk type='block' device='lun'> <driver name='qemu' type='raw' cache='none' io='native'/> <source dev='/dev/mapper/XXXXXXXXXXXXXXXXX'> **<reservations managed='yes'/>** </source> <target dev='sdc' bus='scsi'/> </disk> 3. start the guest 1) "sg_persist -v -i -n -k -d /dev/sdc" works well in the guest 2) here /dev/sdc(guest) -> /dev/sdht(host) 4. iscsiadm logout & login on host 1) iscsiadm -m node -u (host) 2) iscsiadm -m node -l (host) 3) here /dev/sdc(guest) -(change)-> /dev/sdfo(host) 5. exec "sg_persist -v -i -n -k -d /dev/sdc" in the guest 1) command return: Persistent Reservation In cmd: 5e 00 00 00 00 00 00 20 00 00 persistent reservation in: Fixed format, current; Sense key: Aborted Command Additional sense: Logical unit communication failure PR in (Read keys): Aborted command sense key, other than protection related (asc=0x10) 2) strace qemu-pr-helper show: openat(AT_FDCWD, "/dev/sdht", O_RDONLY) = -1 ENOENT (No such file or directory) Additional info: 1. strace qemu-pr-helper show: openat(AT_FDCWD, "/dev/sdht", O_RDONLY) = -1 ENOENT (No such file or directory) 2. This problem may be related to mnt(namespace). I try to set mnt of qemu-pr-helper as pid 1, sg_persist works well after logout & login.

2 3

[libvirt PATCH 0/3] Define and enable Snowridge model
by Tim Wiederhake 17 Nov '20

17 Nov '20

This series adds a CPU model for Snowridge to libvirt. Snowridge was added to QEMU in v4.1.0. Tim Wiederhake (3): cpu_map: Add support for core-capability CPU feature cpu_map: Add support for split-lock-detect CPU feature cpu_map: Define and enable Snowridge model src/cpu_map/index.xml | 1 + src/cpu_map/meson.build | 1 + src/cpu_map/x86_Snowridge.xml | 71 +++++++++++++++++++ src/cpu_map/x86_features.xml | 8 +++ .../domaincapsdata/qemu_4.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_4.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_4.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 1 + 19 files changed, 96 insertions(+) create mode 100644 src/cpu_map/x86_Snowridge.xml -- 2.26.2

1 3

[libvirt PATCH v3] Do not disable incompatible-pointer-types-discards-qualifiers
by Martin Kletzander 17 Nov '20

17 Nov '20

This reverts commit b3710e9a2af402a2b620de570b062294e11190eb. That check is very valuable for our code, but it causes issue with glib >= 2.67.0 when building with clang. The reason is a combination of two commits in glib, firstly fdda405b6b1b which adds a g_atomic_pointer_{set,get} variants that enforce stricter type checking (by removing an extra cast) for compilers that support __typeof__, and commit dce24dc4492d which effectively enabled the new variant of glib's atomic code for clang. This will not be necessary when glib's issue #600 [0] (8 years old) is fixed. Thankfully, MR #1719 [1], which is supposed to deal with this issue was opened 3 weeks ago, so there is a slight sliver of hope. [0] https://gitlab.gnome.org/GNOME/glib/-/issues/600 [1] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1719 Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- v3: - added check for glib version v2: - override _G_DEFINE_TYPE_EXTENDED_BEGIN in gcompat.h meson.build | 3 --- src/util/glibcompat.h | 24 ++++++++++++++++++++++++ 2 files changed, 24 insertions(+), 3 deletions(-) diff --git a/meson.build b/meson.build index cecaad199d4c..04646e3a078c 100644 --- a/meson.build +++ b/meson.build @@ -405,9 +405,6 @@ cc_flags += [ # so use this Clang-specific arg to keep it quiet '-Wno-typedef-redefinition', - # Clang complains about casts in G_DEFINE_TYPE(...) - '-Wno-incompatible-pointer-types-discards-qualifiers', - # We don't use -Wc++-compat so we have to enable it explicitly '-Wjump-misses-init', diff --git a/src/util/glibcompat.h b/src/util/glibcompat.h index 6f50a76f3c2b..457f6ba797f3 100644 --- a/src/util/glibcompat.h +++ b/src/util/glibcompat.h @@ -20,6 +20,30 @@ #include <glib.h> #include <glib/gstdio.h> +#include <glib-object.h> + +#if defined(__clang__) && GLIB_CHECK_VERSION(2, 67, 0) +/* + * Clang detects (valid) issue in G_DEFINE_TYPE and derivatives starting with + * glib >= 2.67.0. See https://gitlab.gnome.org/GNOME/glib/-/issues/600 + * + * For that we need to disable the one check that produces an error in our + * builds when using any G_DEFINE_TYPE* macro. Thankfully all those macros end + * up using _G_DEFINE_TYPE_EXTENDED_BEGIN. Because with that we can redefine + * this one macro to cover all use cases. The macro is defined the same way it + * is defined in glib (with a very low probability of being changed thanks to a + * comment above it). + */ +# undef _G_DEFINE_TYPE_EXTENDED_BEGIN + +# define _G_DEFINE_TYPE_EXTENDED_BEGIN(TypeName, type_name, TYPE_PARENT, flags) \ + _Pragma("GCC diagnostic push") \ + _Pragma("GCC diagnostic ignored \"-Wincompatible-pointer-types-discards-qualifiers\"") \ + _G_DEFINE_TYPE_EXTENDED_BEGIN_PRE(TypeName, type_name, TYPE_PARENT) \ + _G_DEFINE_TYPE_EXTENDED_BEGIN_REGISTER(TypeName, type_name, TYPE_PARENT, flags) \ + _Pragma("GCC diagnostic pop") + +#endif /* __clang__ */ gchar * vir_g_canonicalize_filename(const gchar *filename, const gchar *relative_to); -- 2.29.2

2 1

[libvirt] improve security by adjusting the privileges of libvirtd processes
by yebiaoxiang 17 Nov '20

17 Nov '20

Hi Team The daemon libvirtd runs as root user, which against the least privilege security model. root 567642 1.2 0.0 2856020 47576 ? Ssl 15:49 0:02 /usr/sbin/libvirtd --listen In addition, the "--listen" parameter exposes TCP or TLS ports on the network, it increasing the attack surface. tcp 0 0 0.0.0.0:16509 0.0.0.0:* LISTEN 647824/libvirtd tcp 0 0 0.0.0.0:16514 0.0.0.0:* LISTEN 647824/libvirtd I have the following puzzles: 1. Whether root is the least privilege required for libvirtd to manage virtualization platforms, it's possible to run libvirtd as a non-root user? 2. Is there any plan to resolve this security weaknesses? (like move the function of "--listen" to an independent non-root process, or other good idea) Regards, BiaoXiang

2 2