- Devel - libvirt List Archives

[libvirt] [PATCH 0/2] vnc: remove deprecated TLS related features
by Daniel P. Berrangé 21 Aug '18

21 Aug '18

Daniel P. Berrangé (2): doc: switch to modern syntax for VNC TLS setup vnc: remove support for deprecated tls, x509, x509verify options qemu-deprecated.texi | 20 ---------- qemu-doc.texi | 20 +++++++--- qemu-options.hx | 43 --------------------- ui/vnc.c | 91 -------------------------------------------- 4 files changed, 15 insertions(+), 159 deletions(-) -- 2.17.1

2 3

[libvirt] [RFC v3] x86 RDT Cache Monitoring Technology (CMT)
by Huaqiang,Wang 21 Aug '18

21 Aug '18

For the supporting of Intel x86 Cache Monitoring Technology (CMT) in libvirt, we have already discussed a couple of times, and I have raised two RFCs, you can find the discussion from the following links, and thanks to the people who participated in the discussion online and offline. RFCv2 links https://www.redhat.com/archives/libvir-list/2018-July/msg00409.html https://www.redhat.com/archives/libvir-list/2018-July/msg01241.html RFCv1 https://www.redhat.com/archives/libvir-list/2018-June/msg00674.html Nearly one month has passed since last online discussion, in this month, MBA (memory bandwidth allocation) feature has been introduced by Niu Bin, and some fundamental code for CMT feature has been changed. This change is not that significant, and I wrote my POC code for this RFC again upon the new virresctrl framework, I also made some changes for the CMT feature. I think it is better to summarize my thought about the enabling of CMT here before I submit my code. I'll try to keep consistent with the previous discussion. 1. What is the purpose of this RFC and later patches? Short answer: Introducing Kernel resctrlfs based x86 CMT feature to libvirt. Detail explanation: Latest kernel has removed the "cmt, mbmt, mbml" perf event, and libvirt relies on these kernel perf events to report the result of CMT/MBM through virperf interface. Libvirt will no longer support CMT/MBM feature for Linux distribution with the latest kernel, while there CPU features are vital to some software such as Openstack Nova. About the deprecation of cmt/mbm perf events, refer to the following link for details: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git /commit/?id=c39a0e2c8850f08249383f2425dbd8dbe4baad69 Latest kernel introduces the RDT feature, including CAT MBA CDP CMT and MBM, through resource control file system (resctrl fs), and libvirt already implemented the cache and memory bandwidth allocation through kernel resctrlfs interface. I'd like to add the cache and memory bandwidth monitoring feature to libvirt through kernel resctrlfs interface. Since CMT and MBM shares a very similar kernel interface, for simplicity, only discuss CMT here. MBM is the followup that will be implemented after CMT, which should be very straightforward once CMT is ready. It is planned to output the cache monitoring result through 'domstats' command, and create or delete monitoring groups with either domain's statical XML configuration file or a new 'virsh' runtime command. 2. How many stages scheduled to implement the libvirt CMT(MBM) feature? Short answer: 4 stages. Detail explanation: stage 1: Statical CMT feature. Implementing the libvirt interface for creating and deleting CMT groups for statically through domain's XML configuration file, changes only takes effect after a reboot. Stage 2: Statical MBM feature. Very similar to stage1 CMT. Stage 3: Dynamical CMT feature. In this stage, it is aimed to implement interfaces to change the CMT groups dynamically at runtime, with no requirement for a reboot. My basic thought is implementing a new 'virsh' sub-command providing all interfaces. I also hope to implement the functionality of dynamical cache allocation (CAT) with this command. Stage 4: Dynamical MBM feature. Depending on the implementation of stage3, should share many interfaces created at stage 3. This RFC mainly covers the discussion of stage1. 3. What is the interface for statical CMT feature (the output and input)? Short answer: output through command 'domstats'; input through XML file. Detail explanation: Output: Either CMT or MBM is Intel x86 CPU feature, so I put the statistical message under the result of 'cpu-total' subcommand. This is different with RFCv2, in RFCv2 a separate 'domstats' sub-command has been created, with the name 'cpu-resource', Martin and I were not very satisfied with the the naming. The output would be: virsh domstats --cpu--total Domain: 'ubuntu16.04-base' cpu.time=3143918715755 cpu.user=15320000000 cpu.system=235280000000 cpu.cache.monitor.count=3 cpu.cache.0.name=vcpus_2 cpu.cache.0.vcpus=2 cpu.cache.0.bank.count=2 cpu.cache.0.bank.0.bytes=5488 cpu.cache.0.bank.1.bytes =4410000 cpu.cache.1.name=vcpus_1 cpu.cache.1.vcpus=1 cpu.cache.1.bank.count=2 cpu.cache.1.bank.0.bytes =7839744 cpu.cache.1.bank.1.bytes =0 cpu.cache.2.name=vcpu_0,3 cpu.cache.2.vcpus=0,3 cpu.cache.2.bank.count=2 cpu.cache.2.bank.0.bytes=53796864 cpu.cache.2.bank.1.bytes=0 Comparing with RFCv2, the CMT information is slightly changed. Input: Comparing with RFC v2, this part has been changed. Now the resource monitoring group is considered as a resource monitor toward specific allocation. The main interface for creating monitoring group is through XML file. The proposed configuration is like: <cputune> <cachetune vcpus='0-1'> <cache id='0' level='3' type='code' size='7680' unit='KiB'/> <cache id='1' level='3' type='data' size='3840' unit='KiB'/> + <monitor vcpus='0-1'/> + <monitor vcpus='0'/> </cachetune> <cachetune vcpus='3'> + <monitor vcpus='3'/> </cachetune> </cputune> In above XML, created 2 cache resctrl allocation groups and 3 resctrl monitoring groups. For cache allocation group with vcpu 0 and vcpu 1, there are two monitors: one is monitoring the last level cache occupancy of two vcpus, while the other one only monitors the cache occupancy of vcpu 0. In another cache allocation, there is no explicit cache resource allocation, this cache allocation uses the resource of 'default' cache allocation group, and a cache monitor is created to monitor the cache occupancy. 4. Have emulator and io threads been considered for CMT? Short answer: No. Unsupport to allocate dedicated cache or memory bandwidth for emulator and io threads.

1 0

[libvirt] [jenkins-ci PATCH 0/5] Drop last use of ~/rpmbuild, other cleanups
by Andrea Bolognani 20 Aug '18

20 Aug '18

Patch 1/5 ensures ~/rpmbuild is no longer used, while the remaining ones increase consistency in the various rules used to build RPMs. Andrea Bolognani (5): jobs: Call rpmbuild explicitly for Python projects jobs: Call rpmbuild and sed consistently jobs: Introduce strip_buildrequires jobs: Minimize strip_buildrequires jobs: Don't remove non-existing archives jobs/autotools.yaml | 7 ++----- jobs/defaults.yaml | 5 +++++ jobs/perl-modulebuild.yaml | 5 +---- jobs/python-distutils.yaml | 5 +++-- projects/osinfo-db.yaml | 2 +- 5 files changed, 12 insertions(+), 12 deletions(-) -- 2.17.1

2 14

[libvirt] [PATCH] spec: Add support for RISC-V (riscv64)
by Richard W.M. Jones 20 Aug '18

20 Aug '18

From: David Abdurachmanov <david.abdurachmanov(a)gmail.com> --- libvirt.spec.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index e7196b7d3b..5cb995a6a4 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -101,7 +101,7 @@ %endif # Numactl is not available on s390[x] and ARM -%ifarch s390 s390x %{arm} +%ifarch s390 s390x %{arm} riscv64 %define with_numactl 0 %endif @@ -120,7 +120,7 @@ %endif # zfs-fuse is not available on some architectures -%ifarch s390 s390x aarch64 +%ifarch s390 s390x aarch64 riscv64 %define with_storage_zfs 0 %endif @@ -195,7 +195,7 @@ %if %{with_qemu} || %{with_lxc} || %{with_uml} # numad is used to manage the CPU and memory placement dynamically, # it's not available on s390[x] and ARM. - %ifnarch s390 s390x %{arm} + %ifnarch s390 s390x %{arm} riscv64 %define with_numad 0%{!?_without_numad:1} %endif %endif -- 2.18.0

2 1

[libvirt] [sandbox PATCH 0/2] Remove all uses of g_type_class_add_private()
by Andrea Bolognani 20 Aug '18

20 Aug '18

This fixes build on Fedora Rawhide. Andrea Bolognani (2): configure: Use a single required version for GLib Remove all uses of g_type_class_add_private() configure.ac | 7 +++---- libvirt-sandbox/libvirt-sandbox-builder-container.c | 4 +--- libvirt-sandbox/libvirt-sandbox-builder-initrd.c | 4 +--- libvirt-sandbox/libvirt-sandbox-builder-machine.c | 4 +--- libvirt-sandbox/libvirt-sandbox-builder.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-disk.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-initrd.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-interactive.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-mount-file.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-mount-guest-bind.c | 5 ++--- libvirt-sandbox/libvirt-sandbox-config-mount-host-bind.c | 5 ++--- libvirt-sandbox/libvirt-sandbox-config-mount-host-image.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-mount-ram.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-mount.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-network-address.c | 4 +--- .../libvirt-sandbox-config-network-filterref-parameter.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-network-filterref.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-network-route.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-network.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-service-generic.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-service-systemd.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config-service.c | 4 +--- libvirt-sandbox/libvirt-sandbox-config.c | 4 +--- libvirt-sandbox/libvirt-sandbox-console-raw.c | 4 +--- libvirt-sandbox/libvirt-sandbox-console-rpc.c | 4 +--- libvirt-sandbox/libvirt-sandbox-console.c | 4 +--- libvirt-sandbox/libvirt-sandbox-context-interactive.c | 4 +--- libvirt-sandbox/libvirt-sandbox-context-service.c | 4 +--- libvirt-sandbox/libvirt-sandbox-context.c | 4 +--- 29 files changed, 33 insertions(+), 88 deletions(-) -- 2.17.1

2 4

[libvirt] [PATCH 0/2] Add .domainGetHostname() support for QEMU driver.
by Julio Faracco 20 Aug '18

20 Aug '18

This serie adds a new function into QEMU Guest Agent handlers to use the QEMU command 'guest-get-host-name' to retrieve the domain hostname. This approach requires QEMU-GA running inside the guest, but it is the fastest and easiest way to get this info. Julio Faracco (2): qemu: implementing qemuAgentGetHostname() function. qemu: adding domainGetHostname support for QEMU. src/qemu/qemu_agent.c | 39 +++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_agent.h | 4 ++++ src/qemu/qemu_driver.c | 41 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 84 insertions(+) -- 2.17.1

3 5

[libvirt] FYI: libvirt package on Fedora RISC-V
by Richard W.M. Jones 20 Aug '18

20 Aug '18

http://fedora-riscv.tranquillity.se/koji/taskinfo?taskID=95457 There were some minor changes to the spec file: https://src.fedoraproject.org/rpms/libvirt/c/18f7b8c79c2876b2d3a6ebe2279fd6… Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW

2 3

[libvirt] [PATCH v2 0/4] Fix a SIGSEGV in libvirtd when querying AMD SEV info
by Erik Skultety 20 Aug '18

20 Aug '18

This series fixes the following BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1612009 TL;DR: We don't format SEV platform data (PDH, certificate chain,...) into our qemu caps cache which poses a problem after libvirtd restart when we restore from the cache and get a segfault upon issuing virNodeGetSEVInfo. Since v1: - reworked patch 3 so that qemuMonitorJSONGetSEVCapabilities returns more values in order to distinguish between error and whether SEV is actually supported - added the missing backtrace to patch 4 - no other patches were changed apart from patch 3 Erik Skultety (4): tests: sev: Test launch-security with specific QEMU version qemu: Define and use a auto cleanup function with virSEVCapability qemu: Fix probing of AMD SEV support qemu: caps: Format SEV platform data into qemuCaps cache src/conf/domain_capabilities.h | 4 + src/qemu/qemu_capabilities.c | 127 +++++++++++++++++++-- src/qemu/qemu_monitor_json.c | 31 +++-- tests/domaincapsschemadata/qemu_2.12.0.x86_64.xml | 5 +- tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 6 + tests/qemucapabilitiesdata/caps_3.0.0.x86_64.xml | 1 - ...args => launch-security-sev.x86_64-2.12.0.args} | 19 +-- tests/qemuxml2argvtest.c | 4 +- 8 files changed, 164 insertions(+), 33 deletions(-) rename tests/qemuxml2argvdata/{launch-security-sev.args => launch-security-sev.x86_64-2.12.0.args} (54%) -- 2.14.4

2 6

[libvirt] X86CPU "feature-words" property on QEMU (was Re: [PATCH v3 1/3] x86: Data structure changes to support MSR based) features
by Eduardo Habkost 17 Aug '18

17 Aug '18

On Fri, Aug 17, 2018 at 07:34:13PM +0200, Paolo Bonzini wrote: > On 17/08/2018 17:55, Eduardo Habkost wrote: > >> The names will be X86_CPU_FEATURE_WORD_TYPE_CPUID and > >> X86_CPU_FEATURE_WORD_TYPE_MSR. > > I wouldn't like to make this an external API unless really > > necessary. I would rather deprecate the "feature-words" property > > because nobody ended up using it. > > I think we should either remove it directly, or extend it to support MSR > features. Deprecating and only supporting CPUID features is the worst > of both worlds... So let's do what's necessary to remove it. But I don't think the removal of "feature-words" should block the inclusion of this series. Now, should QOM properties follow our feature deprecation policy, or they were never a supported external API and we can remove it immediately? CCing Jiri and libvir-list, because I just found that there's code on libvirt that uses it, but I don't know exactly it does with that info. -- Eduardo

2 2

[libvirt] [PATCHv2 00/11] BaselineHypervisorCPU using QEMU QMP exchanges
by Chris Venteicher 17 Aug '18

17 Aug '18

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 Version 2 address all issues raised by Collin as well as all other issues identified with additional testing. Chris Venteicher (11): qemu_monitor_json: Introduce qemuMonitorCPUModelInfo / JSON conversion qemu_monitor: Introduce qemuMonitorGetCPUModelBaseline (query-cpu-model-baseline) qemu_monitor: Indicate when CPUModelInfo props report migratablity qemu_monitor: Introduce qemuMonitorCPUModelInfoInit and qemuMonitorCPUModelInfoFreeContents qemu_monitor: CPUModelExpansion on both model name and properties qemu_monitor: Introduce qemuMonitorCPUModelInfoRemovePropByBoolValue qemu_capabilities: Introduce virCPUDef / qemuMonitorCPUModelInfo conversions qemu_capabilities: QMPCommandPtr without maintaining shadow qmperr qemu_capabilities: Persist QEMU instance over multiple QMP Cmds qemu_capabilities: Introduce virQEMUCapsQMPBaselineCPUModel (baseline using QEMU) qemu_driver: BaselineHypervisorCPU supports S390 using QEMU/QMP src/qemu/qemu_capabilities.c | 349 +++++++++++++++++++++++++++++------ src/qemu/qemu_capabilities.h | 33 ++++ src/qemu/qemu_driver.c | 74 +++++++- src/qemu/qemu_monitor.c | 117 +++++++++++- src/qemu/qemu_monitor.h | 21 ++- src/qemu/qemu_monitor_json.c | 232 +++++++++++++++++++---- src/qemu/qemu_monitor_json.h | 14 +- tests/cputest.c | 7 +- 8 files changed, 724 insertions(+), 123 deletions(-) -- 2.17.1

4 41