- Devel - libvirt List Archives

[libvirt] [PATCH] Fix spelling for macOS
by Andrea Bolognani 15 Apr '19

15 Apr '19

Though it used to be called "Mac OS X" and "OS X" in the past, it was never "MacOS X" nor "OS-X", and it's just "macOS" now. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed as trivial. configure.ac | 10 +++++----- m4/virt-driver-network.m4 | 4 ++-- m4/virt-driver-qemu.m4 | 2 +- tools/virsh.pod | 4 ++-- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/configure.ac b/configure.ac index 4afa4d4b78..dcd78f64bf 100644 --- a/configure.ac +++ b/configure.ac @@ -180,13 +180,13 @@ want_ifconfig=no dnl Make some notes about which OS we're compiling for, as the lxc and qemu dnl drivers require linux headers, and storage_mpath, dtrace, and nwfilter dnl are also linux specific. The "network" and storage_fs drivers are known -dnl to not work on MacOS X presently, so we also make a note if compiling +dnl to not work on macOS presently, so we also make a note if compiling dnl for that -with_linux=no with_osx=no with_freebsd=no with_win=no with_cygwin=no +with_linux=no with_macos=no with_freebsd=no with_win=no with_cygwin=no case $host in *-*-linux*) with_linux=yes ;; - *-*-darwin*) with_osx=yes ;; + *-*-darwin*) with_macos=yes ;; *-*-freebsd*) with_freebsd=yes ;; *-*-mingw* | *-*-msvc* ) with_win=yes ;; *-*-cygwin*) with_cygwin=yes ;; @@ -627,9 +627,9 @@ if test "$with_libvirtd" = "no"; then with_storage_vstorage=no fi -dnl storage-fs does not work on MacOS X +dnl storage-fs does not work on macOS -if test "$with_osx" = "yes"; then +if test "$with_macos" = "yes"; then with_storage_fs=no fi diff --git a/m4/virt-driver-network.m4 b/m4/virt-driver-network.m4 index 1fc9b204c6..b98ce07c9c 100644 --- a/m4/virt-driver-network.m4 +++ b/m4/virt-driver-network.m4 @@ -27,9 +27,9 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_NETWORK], [ AC_REQUIRE([LIBVIRT_DRIVER_CHECK_LXC]) dnl there's no use compiling the network driver without the libvirt - dnl daemon, nor compiling it for MacOS X, where it breaks the compile + dnl daemon, nor compiling it for macOS, where it breaks the compile - if test "$with_libvirtd" = "no" || test "$with_osx" = "yes"; then + if test "$with_libvirtd" = "no" || test "$with_macos" = "yes"; then with_network=no fi diff --git a/m4/virt-driver-qemu.m4 b/m4/virt-driver-qemu.m4 index 556599f1f3..a1d05bbd7f 100644 --- a/m4/virt-driver-qemu.m4 +++ b/m4/virt-driver-qemu.m4 @@ -40,7 +40,7 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_QEMU], [ fi AM_CONDITIONAL([WITH_QEMU], [test "$with_qemu" = "yes"]) - if test $with_freebsd = yes || test $with_osx = yes; then + if test $with_freebsd = yes || test $with_macos = yes; then default_qemu_user=root default_qemu_group=wheel else diff --git a/tools/virsh.pod b/tools/virsh.pod index b7ceba8d03..bb52de3eed 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -2389,8 +2389,8 @@ See L<virkeycode-atset3(7)> =item B<os_x> -The numeric values are those defined by the OS-X keyboard input -subsystem. The symbolic names match the corresponding OS-X key +The numeric values are those defined by the macOS keyboard input +subsystem. The symbolic names match the corresponding macOS key constant macro names See L<virkeycode-osx(7)> and L<virkeyname-osx(7)> -- 2.20.1

1 0

[libvirt] [PATCH 0/3] Couple of build fixes after latest cpu changes
by Michal Privoznik 14 Apr '19

14 Apr '19

I've successfully tested these on mingw, arm and x86_64. Almost trivial, but not pushed yet. I'll wait for review. Michal Prívozník (3): virhostcpu.c: Fix misalignment in virHostCPUGetMSRFromKVM comment virhostcpu: Make virHostCPUGetMSR() work only on x86 cpu_x86: Fix placement of *CheckFeature functions src/cpu/cpu_x86.c | 68 ++++++++++++++++++++++--------------------- src/util/virhostcpu.c | 34 ++++++++++++---------- 2 files changed, 54 insertions(+), 48 deletions(-) -- 2.21.0

3 6

[libvirt] [PATCH 00/36] CPU driver enhancements and MSR features
by Jiri Denemark 14 Apr '19

14 Apr '19

In addition to usual CPUID bits, some CPU features started to be reported in IA32_ARCH_CAPABILITIES MSR. This series adds support for such CPU features. However, the last patch which actually adds definitions for some MSR features to the cpu_map should not be pushed yet as the QEMU interface for MSR features is not complete yet. If a domain with some MSR features enabled would be started, all of them would be marked as disabled in the live domain configuration (even though they were actually enabled by QEMU) and they would disappear during migration. Jiri Denemark (36): domaincapstest: Test QEMU 3.1.0 cputest: Add data for Intel(R) Xeon(R) Platinum 8268 CPU cpu_map: Add Cascadelake-Server CPU model cpu_x86: Do not cache microcode version cpu_x86: Require <cpuid> within <feature> in CPU map cpu_x86: Introduce virCPUx86DataItem container struct cpu_x86: Rename virCPUx86Vendor.cpuid cpu_x86: Rename virCPUx86DataItem variables cpu_x86: Rename x86DataCpuidNext function cpu_x86: Rename x86DataCpuid cpu_x86: Rename virCPUx86CPUIDSorter cpu_x86: Rename virCPUx86DataAddCPUIDInt cpu_x86: Rename virCPUx86DataAddCPUID cpu_x86: Rename virCPUx86VendorToCPUID cpu_x86: Simplify x86DataAdd cpu_x86: Introduce virCPUx86DataCmp cpu_x86: Make x86cpuidSetBits more general cpu_x86: Make x86cpuidClearBits more general cpu_x86: Make x86cpuidAndBits more general cpu_x86: Make x86cpuidMatchMasked more general cpu_x86: Make x86cpuidMatch more general cpu_x86: Store virCPUx86DataItem content in union cpu_x86: Add support for storing MSR features in CPU map cpu_x86: Move *CheckFeature functions cputest: Drop support for old QEMU from cpu-parse.sh cputest: Generalize function names in cpu-cpuid.py cputest: Fix comparison in checkCPUIDFeature in cpu-cpuid.py cputest: Rename in_e[ac]x as e[ac]x_in in cpu-cpuid.py cputest: Prepare cpu-cpuid.py for MSR features cputest: Generalize feature parsing in cpu-cpuid.py cputest: Add support for MSR features to cpu-gather.sh cputest: Add support for MSR features to cpu-parse.sh cputest: Add support for MSR features to cpu-cpuid.py vircpuhost: Add support for reading MSRs cpu_x86: Read CPU features from IA32_ARCH_CAPABILITIES MSR cpu_map: Introduce IA32_ARCH_CAPABILITIES MSR features src/cpu/cpu_x86.c | 807 ++++++++++++------ src/cpu/cpu_x86.h | 4 +- src/cpu/cpu_x86_data.h | 27 +- src/cpu_map/index.xml | 1 + src/cpu_map/x86_Cascadelake-Server.xml | 82 ++ src/cpu_map/x86_features.xml | 17 + src/libvirt_private.syms | 3 +- src/libxl/libxl_capabilities.c | 9 +- src/qemu/qemu_monitor_json.c | 7 +- src/util/virhostcpu.c | 80 ++ src/util/virhostcpu.h | 3 + tests/cputest.c | 1 + tests/cputestdata/cpu-cpuid.py | 414 +++------ tests/cputestdata/cpu-gather.sh | 49 +- tests/cputestdata/cpu-parse.sh | 12 +- .../x86_64-cpuid-Core-i7-7600U-enabled.xml | 1 + .../x86_64-cpuid-Core-i7-7600U-json.xml | 1 + ...6_64-cpuid-Xeon-Platinum-8268-disabled.xml | 7 + ...86_64-cpuid-Xeon-Platinum-8268-enabled.xml | 9 + .../x86_64-cpuid-Xeon-Platinum-8268-guest.xml | 35 + .../x86_64-cpuid-Xeon-Platinum-8268-host.xml | 36 + .../x86_64-cpuid-Xeon-Platinum-8268-json.xml | 13 + .../x86_64-cpuid-Xeon-Platinum-8268.json | 702 +++++++++++++++ .../x86_64-cpuid-Xeon-Platinum-8268.sig | 4 + .../x86_64-cpuid-Xeon-Platinum-8268.xml | 55 ++ .../qemu_3.1.0.x86_64.xml | 155 ++++ .../qemu_4.0.0.x86_64.xml | 2 + tests/domaincapstest.c | 4 + 28 files changed, 1954 insertions(+), 586 deletions(-) create mode 100644 src/cpu_map/x86_Cascadelake-Server.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-Platinum-8268-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-Platinum-8268-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-Platinum-8268-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-Platinum-8268-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-Platinum-8268-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-Platinum-8268.json create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-Platinum-8268.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-Platinum-8268.xml create mode 100644 tests/domaincapsschemadata/qemu_3.1.0.x86_64.xml -- 2.21.0

6 79

[libvirt] [PATCH v5 0/2] PPC64 support for NVIDIA V100 GPU with NVLink2 passthrough
by Daniel Henrique Barboza 14 Apr '19

14 Apr '19

This series adds support for a new QEMU feature for the spapr (PPC64) machine, NVIDIA V100 + P9 passthrough. Refer to [1] for the version 7 of this feature (version accepted upstream). changes in v5: - patch1: * use ARRAY_CARDINALITY instead of hard coding the array size * fixed leak of 'file' string inside loop * added ATTRIBUTE_UNUSED in the static function to allow build to succeed without applying the second patch - patch 2: * added QEMU reference of the memory layout of NVLink2 support * fixed leak of 'pciAddrStr' string inside loop * added curly braces in multi-line statements Previous version can be found at [2]. [1] https://patchwork.kernel.org/patch/10848727/ [2] https://www.redhat.com/archives/libvir-list/2019-March/msg00801.html Daniel Henrique Barboza (2): qemu_domain: NVLink2 bridge detection function for PPC64 PPC64 support for NVIDIA V100 GPU with NVLink2 passthrough src/qemu/qemu_domain.c | 108 ++++++++++++++++++++++++++++++++++------- 1 file changed, 90 insertions(+), 18 deletions(-) -- 2.20.1

2 6

[libvirt] [PATCH] cpu_map: Distribute x86_Cascadelake-Server.xml
by Michal Privoznik 13 Apr '19

13 Apr '19

In 2878278c74cc4 we've added new cpu model but we've forgot to distribute the XML file it comes in. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed under build breaker and trivial rules. src/cpu_map/Makefile.inc.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/cpu_map/Makefile.inc.am b/src/cpu_map/Makefile.inc.am index 5634dd9348..ce8a311e22 100644 --- a/src/cpu_map/Makefile.inc.am +++ b/src/cpu_map/Makefile.inc.am @@ -18,6 +18,7 @@ cpumap_DATA = \ cpu_map/x86_Broadwell-IBRS.xml \ cpu_map/x86_Broadwell-noTSX.xml \ cpu_map/x86_Broadwell-noTSX-IBRS.xml \ + cpu_map/x86_Cascadelake-Server.xml \ cpu_map/x86_Conroe.xml \ cpu_map/x86_core2duo.xml \ cpu_map/x86_coreduo.xml \ -- 2.21.0

1 0

[libvirt] [PATCH for-4.1] hw/arm/nseries: Deprecate the n800 and n810 machines
by Thomas Huth 12 Apr '19

12 Apr '19

These machines depend on the deprecated bluetooth subsystem. In case we finally decide to remove the bluetooth subsystem, we likely need to remove the n800 and n810 machines, too, so mark them now as deprecated. Signed-off-by: Thomas Huth <thuth(a)redhat.com> --- hw/arm/nseries.c | 3 +++ qemu-deprecated.texi | 6 ++++++ 2 files changed, 9 insertions(+) diff --git a/hw/arm/nseries.c b/hw/arm/nseries.c index 906b7ca22d..66e50b850c 100644 --- a/hw/arm/nseries.c +++ b/hw/arm/nseries.c @@ -1309,6 +1309,9 @@ static void n8x0_init(MachineState *machine, struct n800_s *s = (struct n800_s *) g_malloc0(sizeof(*s)); int sdram_size = binfo->ram_size; + warn_report("The n800 and n810 machines are deprecated. Please use a " + "different Arm machine instead."); + s->mpu = omap2420_mpu_init(sysmem, sdram_size, machine->cpu_type); /* Setup peripherals diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 2219386769..4de7452fac 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -145,6 +145,12 @@ This machine type uses an unmaintained firmware, broken in lots of ways, and unable to start post-2004 operating systems. 40p machine type should be used instead. +@subsection n800 and n810 (Arm) (since 4.1) + +These machines depend on the deprecated bluetooth subsystem. When the +bluetooth subsystem will be removed, the n800 and n810 machines will be +deleted, too. If possible, use a different Arm board instead. + @section Device options @subsection Block device options -- 2.21.0

3 3

[libvirt] [PATCH] network: only reload firewall after firewalld is finished restarting
by Laine Stump 12 Apr '19

12 Apr '19

The network driver used to reload the firewall rules whenever a dbus NameOwnerChanged message for org.fedoraproject.FirewallD1 was received. Presumably at some point in the past this was successful at reloading our rules after a firewalld restart. Recently though I noticed that once firewalld was restarted, libvirt's logs would get this message: The name org.fedoraproject.FirewallD1 was not provided by any .service files After this point, no networks could be started until libvirtd itself was restarted. The problem is that the NameOwnerChanged message is sent twice during a firewalld restart - once when the old firewalld is stopped, and again when the new firewalld is started. If we try to reload at the point the old firewalld is stopped, none of the firewalld dbus calls will succeed. The solution is to check the new_owner field of the message - we should reload our firewall rules only if new_owner is non-empty (it is set to "" when firewalld is stopped, and some sort of epoch number when it is again started). Signed-off-by: Laine Stump <laine(a)laine.org> --- src/network/bridge_driver.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index 4d4ab0f375..167c142ae2 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -549,8 +549,23 @@ firewalld_dbus_filter_bridge(DBusConnection *connection ATTRIBUTE_UNUSED, dbus_message_is_signal(message, "org.fedoraproject.FirewallD1", "Reloaded")) { - VIR_DEBUG("Reload in bridge_driver because of firewalld."); - networkReloadFirewallRules(driver, false); + VIR_AUTOFREE(char *) name = NULL; + VIR_AUTOFREE(char *) old_owner = NULL; + VIR_AUTOFREE(char *) new_owner = NULL; + + if (virDBusMessageDecode(message, "sss", &name, &old_owner, &new_owner) < 0) { + VIR_WARN("Failed to decode DBus NameOwnerChanged message"); + return DBUS_HANDLER_RESULT_NOT_YET_HANDLED; + } + + /* + * if new_owner is empty, firewalld is shutting down. If it is + * non-empty, then it is starting + */ + if (new_owner && *new_owner) { + VIR_DEBUG("Reload in bridge_driver because of firewalld."); + networkReloadFirewallRules(driver, false); + } } return DBUS_HANDLER_RESULT_NOT_YET_HANDLED; -- 2.20.1

2 2

[libvirt] [PATCH] network: clear cached error if we successfully create firewall chains
by Daniel P. Berrangé 12 Apr '19

12 Apr '19

Since: commit 9f4e35dc73ec9e940aa61bc7c140c2b800218ef3 Author: Daniel P. Berrangé <berrange(a)redhat.com> Date: Mon Mar 18 17:31:21 2019 +0000 network: improve error report when firewall chain creation fails We cache an error when failing to create the top level firewall chains. This commit failed to account for fact that we may invoke networkPreReloadFirewallRules() many times while libvirtd is running. For example when firewalld is restarted. When this happens the original failure may no longer occurr and we'll successfully create our top level chains. We failed to clear the cached error resulting in us failing to start virtual networks. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/network/bridge_driver_linux.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/network/bridge_driver_linux.c b/src/network/bridge_driver_linux.c index 50fc197134..f2827543ca 100644 --- a/src/network/bridge_driver_linux.c +++ b/src/network/bridge_driver_linux.c @@ -55,6 +55,9 @@ void networkPreReloadFirewallRules(bool startup) if (rc < 0) { errInitV4 = virSaveLastError(); virResetLastError(); + } else { + virFreeError(errInitV4); + errInitV4 = NULL; } if (rc) created = true; @@ -63,6 +66,9 @@ void networkPreReloadFirewallRules(bool startup) if (rc < 0) { errInitV6 = virSaveLastError(); virResetLastError(); + } else { + virFreeError(errInitV6); + errInitV6 = NULL; } if (rc) created = true; -- 2.20.1

2 1

[libvirt] [PATCH] qemu: Label uniqDir when probing capabilities
by Martin Kletzander 12 Apr '19

12 Apr '19

This does not cause a problem in usual scenarios thanks to us allowing CAP_DAC_OVERRIDE for the qemu process, however in some scenarios this might be an issue because the directory is created with mkdtemp(3) which explicitly creates that with 0700 permissions and qemu running as non-root cannot access that. The scenarios include: - Builds without CAPNG - Running libvirtd in a container [1] - and possibly others. [1] https://github.com/kubevirt/kubevirt/pull/2181#issuecomment-481840304 Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- src/qemu/qemu_process.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 47d8ca2ff163..2e2c4812fef7 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -8447,6 +8447,19 @@ qemuProcessQMPNew(const char *binary, } +static int +qemuProcessQEMULabelUniqPath(qemuProcessQMPPtr proc) { + /* We cannot use the security driver here, but we should not need to. */ + if (chown(proc->uniqDir, proc->runUid, -1) < 0) { + virReportSystemError(errno, + "Cannot chown uniq path: %s", proc->uniqDir); + return -1; + } + + return 0; +} + + static int qemuProcessQMPInit(qemuProcessQMPPtr proc) { @@ -8466,6 +8479,9 @@ qemuProcessQMPInit(qemuProcessQMPPtr proc) goto cleanup; } + if (qemuProcessQEMULabelUniqPath(proc) < 0) + goto cleanup; + if (virAsprintf(&proc->monpath, "%s/%s", proc->uniqDir, "qmp.monitor") < 0) goto cleanup; -- 2.21.0

2 5

[libvirt] [jenkins-ci PATCH 0/2] guests: Remove readline symlink kludge
by Andrea Bolognani 12 Apr '19

12 Apr '19

The last remaining one! \o/ Andrea Bolognani (2): guests: Install ncurses for libvirt guests: Remove readline symlink kludge guests/playbooks/update/tasks/kludges.yml | 14 -------------- guests/vars/mappings.yml | 8 ++++++++ guests/vars/projects/libvirt.yml | 1 + 3 files changed, 9 insertions(+), 14 deletions(-) -- 2.20.1

2 5