- Devel - libvirt List Archives

[libvirt] [PATCH] util: make forgotten changes suggested during review of commit d40b820c
by Laine Stump 14 Jan '19

14 Jan '19

I had intended to make these changes to commit d40b820c before pushing, but forgot about it during the day between the initial review and ACK. Neither change is significant - just returning immediately when virNetDevGetName() faills (instead of logging a debug message first) and eliminating a comment that adds to confusion rather than eliminating it. Still, the changes should be made to be more consistent with nearly identical code just a few lines up (added in commit 7282f455) Signed-off-by: Laine Stump <laine(a)laine.org> --- src/util/virnetdevip.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/util/virnetdevip.c b/src/util/virnetdevip.c index 8c960ceeac..b6df422cd1 100644 --- a/src/util/virnetdevip.c +++ b/src/util/virnetdevip.c @@ -584,18 +584,18 @@ virNetDevIPCheckIPv6ForwardingCallback(struct nlmsghdr *resp, ifname = virNetDevGetName(nh->rtnh_ifindex); - if (ifname) - accept_ra = virNetDevIPGetAcceptRA(ifname); + if (!ifname) + return -1; + + accept_ra = virNetDevIPGetAcceptRA(ifname); VIR_DEBUG("Checking multipath route nexthop device %s (%d), accept_ra: %d", ifname, nh->rtnh_ifindex, accept_ra); - if (!ifname || - (accept_ra != 2 && virNetDevIPCheckIPv6ForwardingAddIF(data, &ifname) < 0)) { + if (accept_ra != 2 && virNetDevIPCheckIPv6ForwardingAddIF(data, &ifname) < 0) return -1; - } - VIR_FREE(ifname); /* in case it wasn't added to the array */ + VIR_FREE(ifname); data->hasRARoutes = true; len -= NLMSG_ALIGN(nh->rtnh_len); -- 2.20.1

2 1

[libvirt] Entering freeze for libvirt-5.0.0
by Daniel Veillard 13 Jan '19

13 Jan '19

As planned I tagged the RC1 in git and pushed signed tarball and rpms to the usual place: ftp://libvirt.org/libvirt/ I didn't see the 5 patches from Laine in git at that point but those seems to be bug + portability fixes anyway so it should still be possible to have them in say before rc2. Seems to be working fine in my limited testing, and CI seems to be mostly green excepot a few edge cases https://ci.centos.org/view/libvirt/ so that's looking good to me, but as usual it's good to exercice the RCs in various condition to make sure we didn't introdue regressions on some platforms. I plan on RC2 release during the week-end and then if everything goes well push 5.0.0 out on Tuesday for Jan 15 deadline, thanks in advance for giving it some testing ! Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 1

[libvirt] [PATCH v5 00/36] BaselineHypervisorCPU using QEMU QMP exchanges
by Chris Venteicher 12 Jan '19

12 Jan '19

Some architectures (S390) depend on QEMU to compute baseline CPU model and expand a models feature set. Interacting with QEMU requires starting the QEMU process and completing one or more query-cpu-model-baseline QMP exchanges with QEMU in addition to a query-cpu-model-expansion QMP exchange to expand all features in the model. See "s390x CPU models: exposing features" patch set on Qemu-devel for discussion of QEMU aspects. This is part of resolution of: https://bugzilla.redhat.com/show_bug.cgi?id=1511999 ----- This patch set fixes all process code issues identified here: https://www.redhat.com/archives/libvir-list/2018-November/msg00349.html in patches 1-22 of the series. The remaining patches implement the BaselineHypervisorCPU changes using the non-domain qemu process code. The process changes (patches 1-22)... - Make the process code generic (not capabilities specific) for use by BaselineHypervisorCPU - Many of the process patches are simple code moves with implementation changes in other distinct patches - A thread safe library function creates a unique directory under libDir for each QEMU process (for QMP messaging) to decouple processes in terms of sockets and file system footprint. The BaselineHypervisorCPU changes (patches 22-36)... - Fix all issues raised in patch sets 1-4. Thanks, Chris Chris Venteicher (36): qemu_process: Move process code from qemu_capabilities to qemu_process qemu_process: Use qemuProcessQmp prefix qemu_process: Limit qemuProcessQmpNew to const input strings qemu_process: Refer to proc not cmd in process code qemu_process: Use consistent name for stop process function qemu_capabilities: Stop QEMU process before freeing qemu_process: Use qemuProcessQmp struct for a single process qemu_process: All ProcessQMP errors are fatal qemu_process: Persist stderr in qemuProcessQmp struct qemu_process: Introduce qemuProcessQmpStart qemu_process: Collect monitor code in single function qemu_process: Store libDir in qemuProcessQmp struct qemu_process: Setup paths within qemuProcessQmpInit qemu_process: Stop retaining Monitor config in qemuProcessQmp qemu_process: Don't open monitor if process failed qemu_process: Cleanup qemuProcessQmp alloc function qemu_process: Cleanup qemuProcessQmpStop function qemu_process: Catch process free before process stop qemu_monitor: Make monitor callbacks optional qemu_process: Enter QMP command mode when starting QEMU Process qemu_process: Use unique directories for QMP processes qemu_process: Stop locking QMP process monitor immediately qemu_monitor: Introduce qemuMonitorCPUModelInfoNew qemu_monitor: Introduce qemuMonitorCPUModelInfo / JSON conversion qemu_capabilities: Introduce virQEMuCapsMigratablePropsDiff qemu_monitor: qemuMonitorGetCPUModelExpansion inputs and outputs CPUModelInfo qemu_capabilities: Introduce CPUModelInfo to virCPUDef function qemu_capabilities: Introduce virCPUDef to CPUModelInfo function qemu_monitor: Support query-cpu-model-baseline QMP command qemu_driver: Consolidate code to baseline using libvirt qemu_driver: Decouple code for baseline using libvirt qemu_driver: Identify using libvirt as a distinct way to compute baseline qemu_driver: Support baseline calculation using QEMU qemu_driver: Support feature expansion via QEMU when baselining cpu qemu_driver: Remove unsupported props in expanded hypervisor baseline output qemu_monitor: Default props to migratable when expanding cpu model src/qemu/qemu_capabilities.c | 617 ++++++++---------- src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_driver.c | 216 +++++- src/qemu/qemu_monitor.c | 184 +++++- src/qemu/qemu_monitor.h | 29 +- src/qemu/qemu_monitor_json.c | 226 +++++-- src/qemu/qemu_monitor_json.h | 12 +- src/qemu/qemu_process.c | 356 ++++++++++ src/qemu/qemu_process.h | 32 + tests/cputest.c | 11 +- .../caps_2.10.0.s390x.xml | 60 +- .../caps_2.11.0.s390x.xml | 58 +- .../caps_2.12.0.s390x.xml | 56 +- .../qemucapabilitiesdata/caps_2.8.0.s390x.xml | 32 +- .../qemucapabilitiesdata/caps_2.9.0.s390x.xml | 34 +- .../qemucapabilitiesdata/caps_3.0.0.s390x.xml | 64 +- tests/qemucapabilitiestest.c | 7 + 17 files changed, 1396 insertions(+), 602 deletions(-) -- 2.17.1

2 66

[libvirt] [PATCH 0/4] Fix check for accept_ra when starting an IPv6 network
by Laine Stump 12 Jan '19

12 Jan '19

These patches fix the crash described in: https://bugzilla.redhat.com/1583131 They also fix a deficiency revealed by that crash - we weren't checking the accept_ra value of interfaces in the "nexthop" elements of multipath RA routes. Laine Stump (4): util: remove const specifier from nlmsghdr arg to virNetlinkDumpCallback() util: add a function to insert new interfaces to IPv6CheckForwarding list util: use nlmsg_find_attr() instead of an open-coded loop util: check accept_ra for all nexthop interfaces of multipath routes src/util/virnetdevip.c | 115 ++++++++++++++++++++++++++++------------- src/util/virnetlink.h | 2 +- 2 files changed, 79 insertions(+), 38 deletions(-) -- 2.20.1

2 15

[libvirt] [PATCH 0/2] Fix a couple of SCSI hostdev issues
by John Ferlan 11 Jan '19

11 Jan '19

See patches for details John Ferlan (2): qemu: Filter non SCSI hostdevs in qemuHostdevPrepareSCSIDevices qemu: Remove virHostdevIsSCSIDevice from qemuIsSharedHostdev src/qemu/qemu_conf.c | 3 +-- src/qemu/qemu_hostdev.c | 3 +++ 2 files changed, 4 insertions(+), 2 deletions(-) -- 2.20.1

2 6

[libvirt] [PATCH] src: Don't use double-colon rules
by Andrea Bolognani 11 Jan '19

11 Jan '19

According to the GNU Make manual, "double-colon rules are somewhat obscure and not often very useful". Looking at the few instances we have in libvirt, that certainly seems to be the case, so just drop them. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- src/Makefile.am | 6 +++--- src/remote/Makefile.inc.am | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index cd386297ed..8c8dfe3dcf 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -816,14 +816,14 @@ if WITH_LIBVIRTD if LIBVIRT_INIT_SCRIPT_RED_HAT initdir = $(sysconfdir)/rc.d/init.d -install-init:: $(SYSVINIT_FILES) install-sysconfig +install-init: $(SYSVINIT_FILES) install-sysconfig $(MKDIR_P) $(DESTDIR)$(initdir) for f in $(SYSVINIT_FILES:%.init=%) ; \ do \ $(INSTALL_SCRIPT) $$f.init $(DESTDIR)$(initdir)/$$f; \ done -uninstall-init:: uninstall-sysconfig +uninstall-init: uninstall-sysconfig rm -f $(SYSVINIT_FILES:%.init=$(DESTDIR)$(initdir)/%) rmdir $(DESTDIR)$(initdir) || : @@ -1010,7 +1010,7 @@ install-data-local: $(INSTALL_DATA_LOCAL) \ $(MKDIR_P) "$(DESTDIR)$(localstatedir)/lib/libvirt/filesystems" $(MKDIR_P) "$(DESTDIR)$(localstatedir)/lib/libvirt/boot" -uninstall-local:: $(UNINSTALL_LOCAL) \ +uninstall-local: $(UNINSTALL_LOCAL) \ $(INSTALL_DATA_DIRS:%=uninstall-data-%) rmdir "$(DESTDIR)$(localstatedir)/cache/libvirt" ||: rmdir "$(DESTDIR)$(localstatedir)/lib/libvirt/images" ||: diff --git a/src/remote/Makefile.inc.am b/src/remote/Makefile.inc.am index 0988435eed..3d0ff29548 100644 --- a/src/remote/Makefile.inc.am +++ b/src/remote/Makefile.inc.am @@ -213,7 +213,7 @@ polkitdir = $(datadir)/polkit-1 polkitactionsdir = $(polkitdir)/actions polkitrulesdir = $(polkitdir)/rules.d -install-polkit:: +install-polkit: $(MKDIR_P) $(DESTDIR)$(polkitactionsdir) $(INSTALL_DATA) $(srcdir)/remote/libvirtd.policy \ $(DESTDIR)$(polkitactionsdir)/org.libvirt.unix.policy @@ -221,7 +221,7 @@ install-polkit:: $(INSTALL_DATA) $(srcdir)/remote/libvirtd.rules \ $(DESTDIR)$(polkitrulesdir)/50-libvirt.rules -uninstall-polkit:: +uninstall-polkit: rm -f $(DESTDIR)$(polkitactionsdir)/org.libvirt.unix.policy rmdir $(DESTDIR)$(polkitactionsdir) || : rm -f $(DESTDIR)$(polkitrulesdir)/50-libvirt.rules -- 2.20.1

2 1

[libvirt] [PATCH] util: Remove unnecessary ATTRIBUTE_NONNULL for virCommandAddArg[Pair]
by John Ferlan 10 Jan '19

10 Jan '19

Commit 912c6b22 modified the virCommandAddArg and virCommandAddArgPair to perform NULL argument checking; however, no corresponding change to the prototypes was made to remove the ATTRIBUTE_NONNULL, so the Coverity build failed. Adjust the prototypes accordingly. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- It's a build breaker for Coverity or anything that enables STATIC_ANALYSIS so I'll push under that rule. src/util/vircommand.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/util/vircommand.h b/src/util/vircommand.h index dbf5041890..100f7a06e0 100644 --- a/src/util/vircommand.h +++ b/src/util/vircommand.h @@ -123,7 +123,7 @@ void virCommandAddEnvPassAllowSUID(virCommandPtr cmd, void virCommandAddEnvPassCommon(virCommandPtr cmd); void virCommandAddArg(virCommandPtr cmd, - const char *val) ATTRIBUTE_NONNULL(2); + const char *val); void virCommandAddArgBuffer(virCommandPtr cmd, virBufferPtr buf); @@ -134,8 +134,7 @@ void virCommandAddArgFormat(virCommandPtr cmd, void virCommandAddArgPair(virCommandPtr cmd, const char *name, - const char *val) - ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3); + const char *val); void virCommandAddArgSet(virCommandPtr cmd, const char *const*vals) ATTRIBUTE_NONNULL(2); -- 2.17.2

4 12

[libvirt] [PATCH v2 0/3] Various cleanups to the build system
by Andrea Bolognani 10 Jan '19

10 Jan '19

Changes from [v1]: * patches 1-4 from v1 have been pushed; * patches 1 and 2 are new; * patch 3 (which was patch 5 in v1) no longer drops the various WITH_LIBVIRTD conditionals. [v1] https://www.redhat.com/archives/libvir-list/2019-January/msg00212.html Andrea Bolognani (3): src: Define initdir src: Only install SysV init scripts when libvirtd is built src: Simplify installing/uninstalling data src/Makefile.am | 66 ++++++++++++++++++-------------------- src/remote/Makefile.inc.am | 30 +++++++---------- 2 files changed, 44 insertions(+), 52 deletions(-) -- 2.20.1

2 6

[libvirt] [PATCH] qemu: require reply from guest agent in qemuAgentGetInterfaces
by Ján Tomko 10 Jan '19

10 Jan '19

Since its introduction in commit 0977b8aa071 (released in v1.2.14) qemuAgentGetInterfaces calls qemuAgentCommand with needReply=false, which allows qemuAgentCommand to return 0 even when it did not get any reply from the agent. Set needReply to true, since we dereference it right after. This can be hit if libvirt is waiting for an event from the agent (e.g. shutdown) and the agent cannot reply in time (e.g. due to the guest being shut down), as reported in: https://bugzilla.redhat.com/show_bug.cgi?id=1663051 Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- src/qemu/qemu_agent.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c index 0f4dae37e3..80b789b5e0 100644 --- a/src/qemu/qemu_agent.c +++ b/src/qemu/qemu_agent.c @@ -2043,7 +2043,7 @@ qemuAgentGetInterfaces(qemuAgentPtr mon, if (!(cmd = qemuAgentMakeCommand("guest-network-get-interfaces", NULL))) goto cleanup; - if (qemuAgentCommand(mon, cmd, &reply, false, + if (qemuAgentCommand(mon, cmd, &reply, true, VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK) < 0) goto cleanup; -- 2.20.1

3 2

[libvirt] [PATCH] cpu_map: Add support for arch-capabilities feature
by Jiri Denemark 10 Jan '19

10 Jan '19

The feature was added to QEMU in 3.1.0 and it is currently blocking migration, which is expected to change in the future. Luckily 3.1.0 is new enough to give us migratability hints on each feature via query-cpu-model-expension, which means we don't need to use the "migratable" attribute on the CPU map XML. The kernel calls this feature arch_capabilities and RHEL/CentOS 7.* use arch-facilities. Apparently some CPU test files were gathered with the RHEL version of QEMU. Let's update the test files to avoid possible confusion about the correct naming. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/cpu_map/x86_features.xml | 3 +++ tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core-ibpb.json | 2 +- tests/cputestdata/x86_64-cpuid-Xeon-E5-2609-v3.json | 2 +- tests/cputestdata/x86_64-cpuid-Xeon-E5-2623-v4.json | 2 +- tests/cputestdata/x86_64-cpuid-Xeon-Gold-5115.json | 2 +- 5 files changed, 7 insertions(+), 4 deletions(-) diff --git a/src/cpu_map/x86_features.xml b/src/cpu_map/x86_features.xml index 59236456d6..02431bea29 100644 --- a/src/cpu_map/x86_features.xml +++ b/src/cpu_map/x86_features.xml @@ -326,6 +326,9 @@ <feature name='stibp'> <cpuid eax_in='0x07' ecx_in='0x00' edx='0x08000000'/> </feature> + <feature name='arch-capabilities'>  + <cpuid eax_in='0x07' ecx_in='0x00' edx='0x20000000'/> + </feature> <feature name='ssbd'> <cpuid eax_in='0x07' ecx_in='0x00' edx='0x80000000'/> </feature> diff --git a/tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core-ibpb.json b/tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core-ibpb.json index 94a60fcc8f..1f53bb8bf3 100644 --- a/tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core-ibpb.json +++ b/tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core-ibpb.json @@ -232,7 +232,7 @@ "avx512vbmi": false, "kvm-asyncpf": true, "spec-ctrl": false, - "arch-facilities": false, + "arch-capabilities": false, "model": 1, "node-id": -1 } diff --git a/tests/cputestdata/x86_64-cpuid-Xeon-E5-2609-v3.json b/tests/cputestdata/x86_64-cpuid-Xeon-E5-2609-v3.json index 10c5434263..6bdaf6e83a 100644 --- a/tests/cputestdata/x86_64-cpuid-Xeon-E5-2609-v3.json +++ b/tests/cputestdata/x86_64-cpuid-Xeon-E5-2609-v3.json @@ -232,7 +232,7 @@ "avx512vbmi": false, "kvm-asyncpf": true, "spec-ctrl": true, - "arch-facilities": false, + "arch-capabilities": false, "model": 63, "node-id": -1 } diff --git a/tests/cputestdata/x86_64-cpuid-Xeon-E5-2623-v4.json b/tests/cputestdata/x86_64-cpuid-Xeon-E5-2623-v4.json index 0506dec0a7..2c6be20768 100644 --- a/tests/cputestdata/x86_64-cpuid-Xeon-E5-2623-v4.json +++ b/tests/cputestdata/x86_64-cpuid-Xeon-E5-2623-v4.json @@ -232,7 +232,7 @@ "avx512vbmi": false, "kvm-asyncpf": true, "spec-ctrl": true, - "arch-facilities": false, + "arch-capabilities": false, "model": 79, "node-id": -1 } diff --git a/tests/cputestdata/x86_64-cpuid-Xeon-Gold-5115.json b/tests/cputestdata/x86_64-cpuid-Xeon-Gold-5115.json index 79f3580219..79b47a56fb 100644 --- a/tests/cputestdata/x86_64-cpuid-Xeon-Gold-5115.json +++ b/tests/cputestdata/x86_64-cpuid-Xeon-Gold-5115.json @@ -232,7 +232,7 @@ "avx512vbmi": false, "kvm-asyncpf": true, "spec-ctrl": true, - "arch-facilities": false, + "arch-capabilities": false, "model": 85, "node-id": -1 } -- 2.20.1

2 1