- Devel - libvirt List Archives

[libvirt] [PATCH 1/2] qemu: fix internal error: NUMA isn't available on this host
by Boris Fiuczynski 25 Nov '16

25 Nov '16

If libvirt is compiled without NUMACTL support starting libvirtd reports a libvirt internal error "NUMA isn't available on this host" without checking if NUMA support is compiled into the libvirt binaries. This patch adds the missing NUMA support check to prevent the internal error. It also includes a check if the cgroup controller cpuset is available before using it. The error was noticed when libvirtd was restarted with running domains and on libvirtd start the qemuConnectCgroup gets called during qemuProcessReconnect. Signed-off-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk(a)linux.vnet.ibm.com> --- src/qemu/qemu_cgroup.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c index 211d0b5..0baa2b3 100644 --- a/src/qemu/qemu_cgroup.c +++ b/src/qemu/qemu_cgroup.c @@ -939,6 +939,10 @@ qemuRestoreCgroupState(virDomainObjPtr vm) virBitmapPtr all_nodes; virCgroupPtr cgroup_temp = NULL; + if (!virNumaIsAvailable() || + !virCgroupHasController(priv->cgroup, VIR_CGROUP_CONTROLLER_CPUSET)) + return; + if (!(all_nodes = virNumaGetHostMemoryNodeset())) goto error; -- 2.5.5

2 2

[libvirt] [RFC 00/15] qmp: Report supported device types on 'query-machines'
by Eduardo Habkost 25 Nov '16

25 Nov '16

The Problem =========== Currently management software has no way to find out which device types can be plugged in a machine, unless the machine is already initialized. Even after the machine is initialized, there's no way to map existing bus types to supported device types unless management software hardcodes the mapping between bus types and device types. Example: floppy support on q35 vs i440fx ---------------------------------------- There's no way for libvirt to find out that there's no floppy controller on pc-q35-* machine-types by default. With this series, pc-i440fx-* will report "floppy" as a supported device type, but pc-q35-* will not. Example: Legacy PCI vs vs PCIe devices -------------------------------------- Some devices require a PCIe bus to be available, others work on both legacy PCI and PCIe, while others work only on a legacy PCI bus. Currently management software has no way to know which devices can be added to a given machine, unless it hardcodes machine-type names and device-types names. The Proposed Interface ====================== This series adds a new field to the output of 'query-machines': 'supported-device-types'. It will contain a list of QOM type names, that can be used to find the list of device types that can be plugged in the machine by default. The type names reported on the new field can then be used as the 'implements' argument on the 'qom-list-types' command, to find out which device types can be plugged on the machine. Example output -------------- (QEMU) query-machines { "return": [ [...] { "supported-device-types": [ "sys-bus-device" ], "cpu-max": 1, "hotpluggable-cpus": false, "name": "none" }, [...] { "supported-device-types": [ "sys-bus-device" ], "cpu-max": 1, "hotpluggable-cpus": false, "name": "xenpv" }, [...] { "supported-device-types": [ "sys-bus-device", "floppy", "i2c-slave", "pci-device", "isa-device", "ide-device" ], "name": "pc-i440fx-2.8", "alias": "pc", "is-default": true, "cpu-max": 255, "hotpluggable-cpus": true }, [...] { "supported-device-types": [ "sys-bus-device", "floppy", "isa-device", "ide-device" ], "cpu-max": 1, "hotpluggable-cpus": true, "name": "isapc" }, [...] { "supported-device-types": [ "sys-bus-device", "floppy", "i2c-slave", "pci-device", "isa-device", "ide-device" ], "cpu-max": 128, "hotpluggable-cpus": true, "name": "xenfv" }, [...] { "alias": "q35", "supported-device-types": [ "sys-bus-device", "i2c-slave", "PCIE-device", "isa-device", "ide-device" ], "cpu-max": 288, "hotpluggable-cpus": true, "name": "pc-q35-2.8" }, [...] ] } Considered alternatives ======================= Indirect mapping (machine => bus => device) ------------------------------------------- This RFC implements a mechanism to implement ax machine-type => supported-device-types mapping. An alternative solution I considered was to expose an indirect mapping: machine-type => default-bus-types followed by bus-type => supported-device-types. But exposing only the resulting supported device-types list imposes less restrictions on how the device and bus type hierarchy is implemented inside QEMU. There's still a machine-type => bus-type => device-type mapping implemented internally, but it is an implementation detail on the current version, and not part of the externally-visible interface. The Implementation ================== This add a new field to MachineClass: default_bus_types, and a new field to BusClass: supported_device_type. The two fields are used to build the list of supported device types for a given machine. On most cases, the normal QOM type hierarchy is used to define the set of supported devices for a bus. On the case of PCIe buses, a INTERFACE_PCIE_DEVICE interface name was introduced, to indicate PCIe-capable devices. This means we are duplicating information in some cases: * BusClass::supported_device_type duplicates knowlege that is already encoded in DeviceClass::bus_type. To make sure both fields agree with each other, a new device_class_set_bus_type() wrapper was added, to perform additional validation. * MachineClass::default_bus_type duplicates knowledge that is already encoded in the machine init function. To make sure the information is correct, a qmp-machine-info.py test case is added, that will validate the supported-device-types field based on the buses created by the machine. * PCIDeviceClass::is_express and INTERFACE_PCIE_DEVICE both encode the same information about a PCI device class. A future version of this series may include a class_base_post_init hook that will allow TYPE_PCI_DEVICE to validate/update is_express and the interface list to ensure both are always consistent. Test Code --------- qdev-based test code for the new field was implemented in a Python script. Some extra support was implemented in tests/Makefile.include, scripts/qemu.py and scripts/qtest.py to allow the test to be implemented. Limitations =========== TYPE_SYS_BUS_DEVICE is too generic ---------------------------------- Currently all machines have a TYPE_SYS_BUS bus, meaning all TYPE_SYS_BUS_DEVICE subclasses are reported as supported. The current solution in this series is to report TYPE_SYS_BUS_DEVICE as supported by all machines. But we could gradually add arch-specific or machine-family-specific interface names that can be used on devices that are meant to work with only a subset of TYPE_SYS_BUS_DEVICE subclasses. A future version of this series may remove TYPE_SYS_BUS_DEVICE from the supported-device-types output, and return a arch-specific or machine-family-specific interface name to restrict management software to a subset of TYPE_SYS_BUS_DEVICE subclasses. PCI vs PCIe ----------- Machines with PCIe buses will report INTERFACE_PCIE_DEVICE on supported-device-types. Machines with legacy PCI buses will report TYPE_PCI_DEVICE on supported-device-types. The problem with the current approach is that PCIe devices are TYPE_PCI_DEVICE subclasses. The allows PCI device classes to indicate they are PCIe-capable, but there's no obvious way to indicate that a device is PCIe-only. This needs to be addressed in a future version of this series. Suggestions are welcome. Incomplete bus lists on some machines ------------------------------------- With this series, not all machines classes are changed to add the full list of device types on the 'supported-device-types'. To allow the code to be updated gradually, qmp-machine-info.py has a STRICT_ARCHES variable, that will make the test code require a complete device type list only on some architectures. Out of scope: Configurable buses -------------------------------- There's no way to map machine options like "usb=on|off" to device-types or buses. I plan to propose a new interface that allows machine options to be mapped to buses/device-types later. Out of scope: Deciding where to plug devices -------------------------------------------- Once management software discovers which devices can be plugged to a machine, it still has to discover or define where devices can/should/will be plugged. This is out of the scope of this series. Out of scope: Hotplug --------------------- The proposed interface is supposed to help management software find which device types can be used when creating the VM. Device hotplug is out of the scope of this series. However, the new 'device-types' QOM property on bus objects could be used to find out which device types can be plugged on the existing buses. --- Cc: libvir-list(a)redhat.com Cc: Laine Stump <laine(a)redhat.com> Eduardo Habkost (15): qemu.py: Make logging optional qtest.py: Support QTEST_LOG environment variable qtest.py: make logging optional qtest.py: Make 'binary' parameter optional tests: Add rules to non-gtester qtest test cases qdev: Add device_type field to BusClass machine: Add MachineClass::default_buses field qmp: Add 'supported-device-types' field to 'query-machines' pci: Introduce INTERFACE_PCIE_DEVICE interface name pc: Initialize default bus lists s390x: Initialize default bus lists arm: Initialize default bus lists mips: Initialize default bus lists ppc: Initialize default bus lists qdev: Add device_class_set_bus_type() function hw/arm/aspeed.c | 2 + hw/arm/collie.c | 1 + hw/arm/cubieboard.c | 1 + hw/arm/exynos4_boards.c | 5 ++ hw/arm/gumstix.c | 7 ++ hw/arm/highbank.c | 4 ++ hw/arm/imx25_pdk.c | 1 + hw/arm/kzm.c | 1 + hw/arm/musicpal.c | 1 + hw/arm/nseries.c | 2 + hw/arm/palm.c | 1 + hw/arm/realview.c | 1 + hw/arm/spitz.c | 10 +++ hw/arm/stellaris.c | 4 ++ hw/audio/intel-hda.c | 9 ++- hw/block/fdc.c | 17 +++-- hw/block/nvme.c | 4 ++ hw/char/virtio-serial-bus.c | 3 +- hw/core/bus.c | 9 +++ hw/core/machine.c | 18 ++++- hw/core/qdev.c | 8 +++ hw/core/sysbus.c | 3 +- hw/i2c/core.c | 9 ++- hw/i386/pc_piix.c | 13 ++++ hw/i386/pc_q35.c | 4 ++ hw/ide/qdev.c | 3 +- hw/input/adb.c | 9 ++- hw/ipack/ipack.c | 9 ++- hw/isa/isa-bus.c | 3 +- hw/mips/mips_malta.c | 7 ++ hw/mips/mips_r4k.c | 2 + hw/misc/auxbus.c | 3 +- hw/net/e1000e.c | 4 ++ hw/net/vmxnet3.c | 4 ++ hw/pci-bridge/ioh3420.c | 4 ++ hw/pci-bridge/xio3130_downstream.c | 4 ++ hw/pci/pci.c | 16 ++++- hw/ppc/e500plat.c | 3 + hw/ppc/mac_newworld.c | 4 ++ hw/ppc/mac_oldworld.c | 3 + hw/ppc/mpc8544ds.c | 4 ++ hw/ppc/ppc440_bamboo.c | 1 + hw/ppc/prep.c | 4 ++ hw/ppc/spapr_vio.c | 3 +- hw/s390x/css-bridge.c | 2 + hw/s390x/event-facility.c | 3 +- hw/s390x/s390-pci-bus.c | 9 ++- hw/s390x/s390-virtio-ccw.c | 6 ++ hw/s390x/virtio-ccw.c | 2 +- hw/scsi/megasas.c | 7 ++ hw/scsi/scsi-bus.c | 3 +- hw/scsi/vmw_pvscsi.c | 1 + hw/sd/core.c | 7 ++ hw/sd/sd.c | 2 +- hw/ssi/ssi.c | 9 ++- hw/usb/bus.c | 3 +- hw/usb/dev-smartcard-reader.c | 9 ++- hw/usb/hcd-xhci.c | 4 ++ hw/vfio/pci.c | 4 ++ hw/virtio/virtio-bus.c | 1 + hw/virtio/virtio-pci.c | 4 ++ hw/virtio/virtio.c | 2 +- include/hw/boards.h | 5 ++ include/hw/pci/pci.h | 3 + include/hw/qdev-core.h | 4 ++ qapi-schema.json | 9 ++- scripts/qemu.py | 25 +++++-- scripts/qtest.py | 15 +++- tests/Makefile.include | 39 ++++++++++- tests/qmp-machine-info.py | 138 +++++++++++++++++++++++++++++++++++++ vl.c | 11 +++ 71 files changed, 518 insertions(+), 37 deletions(-) create mode 100755 tests/qmp-machine-info.py -- 2.7.4

6 19

[libvirt] [PATCH v3] storage_backend_rbd: check the return value of rados_conf_set
by Chen Hanxiao 25 Nov '16

25 Nov '16

From: Chen Hanxiao <chenhanxiao(a)gmail.com> We forget to check the return value of some rados_conf_set. Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- v2: add another missing return value check v3: fix a copy-paste error src/storage/storage_backend_rbd.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c index 718c4d6..a286af0 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -159,13 +159,28 @@ virStorageBackendRBDOpenRADOSConn(virStorageBackendRBDStatePtr ptr, * Operations in librados will return -ETIMEDOUT when the timeout is reached. */ VIR_DEBUG("Setting RADOS option client_mount_timeout to %s", client_mount_timeout); - rados_conf_set(ptr->cluster, "client_mount_timeout", client_mount_timeout); + if (rados_conf_set(ptr->cluster, "client_mount_timeout", client_mount_timeout) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("failed to set RADOS option: %s"), + "client_mount_timeout"); + goto cleanup; + } VIR_DEBUG("Setting RADOS option rados_mon_op_timeout to %s", mon_op_timeout); - rados_conf_set(ptr->cluster, "rados_mon_op_timeout", mon_op_timeout); + if (rados_conf_set(ptr->cluster, "rados_mon_op_timeout", mon_op_timeout) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("failed to set RADOS option: %s"), + "rados_mon_op_timeout"); + goto cleanup; + } VIR_DEBUG("Setting RADOS option rados_osd_op_timeout to %s", osd_op_timeout); - rados_conf_set(ptr->cluster, "rados_osd_op_timeout", osd_op_timeout); + if (rados_conf_set(ptr->cluster, "rados_osd_op_timeout", osd_op_timeout) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("failed to set RADOS option: %s"), + "rados_osd_op_timeout"); + goto cleanup; + } /* * Librbd supports creating RBD format 2 images. We no longer have to invoke @@ -173,7 +188,12 @@ virStorageBackendRBDOpenRADOSConn(virStorageBackendRBDStatePtr ptr, * This leaves us to simply use rbd_create() and use the default behavior of librbd */ VIR_DEBUG("Setting RADOS option rbd_default_format to %s", rbd_default_format); - rados_conf_set(ptr->cluster, "rbd_default_format", rbd_default_format); + if (rados_conf_set(ptr->cluster, "rbd_default_format", rbd_default_format) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("failed to set RADOS option: %s"), + "rbd_default_format"); + goto cleanup; + } ptr->starttime = time(0); if ((r = rados_connect(ptr->cluster)) < 0) { -- 1.8.3.1

2 3

[libvirt] [PATCH 0/2] fix build on macOS
by Roman Bogorodskiy 25 Nov '16

25 Nov '16

This series fixes too issues. - rpcgen issue. rpcgen(1) that comes with macOS is too old. I've grabbed rpcgen from FreeBSD and created a brew formula for it[1]. I configure it like: ./configure ac_cv_path_RPCGEN=/usr/local/bin/bsdrpcgen It still requires darwin to be added to the fixup list in genprotocol.pl - macOS doesn't support clock_gettime(3), so use its own routnes 1: https://gist.github.com/novel/0d74cdbc7b71f60640a42b52c9cc1459 Roman Bogorodskiy (2): genprotocol.pl: add darwing to fixup list tests: fix eventtest build on macOS configure.ac | 9 +++++++++ src/rpc/genprotocol.pl | 2 +- tests/Makefile.am | 2 +- tests/eventtest.c | 16 ++++++++++++++++ 4 files changed, 27 insertions(+), 2 deletions(-) -- 2.10.2

2 6

[libvirt] [PATCH 0/4] introduce virCheckControllerGoto to simplify cgroup controller check
by Chen Hanxiao 25 Nov '16

25 Nov '16

We had a lot of codes use the same style of cgroup controller check. This series introduce macro virCheckControllerGoto to simplify these kinds of check. Chen Hanxiao (4): internal: introduce macro virCheckControllerGoto lxc_driver: use virCheckControllerGoto to simplify cgroup controller check qemu_driver: use virCheckControllerGoto to simplify cgroup controller check qemu_process: use virCheckControllerGoto to simplify cgroup controller check src/internal.h | 19 ++++++++ src/lxc/lxc_driver.c | 115 ++++++++++++++---------------------------------- src/qemu/qemu_driver.c | 70 +++++++++-------------------- src/qemu/qemu_process.c | 9 ++-- 4 files changed, 77 insertions(+), 136 deletions(-) -- 1.8.3.1

4 15

[libvirt] [PATCH] qemu: Allow use of hot plugged host CPUs if no affinity set
by Viktor Mihajlovski 25 Nov '16

25 Nov '16

Running VMs couldn't use newly hot plugged host CPUs even if the VMs had no CPU pinning defined AND the cpuset controller was disabled in the libvirt qemu configuration. This was because in this case the process affinity was set by libvirt to all currently present host CPUs in order to avoid situations, where libvirtd was deliberately running on a CPU subset and thus the spawned VMs would be involuntarily restricted to the CPU subset inherited by libvirtd. That however prevents new host CPUs to be utilized when they show up. With this change we will NOT set the VM's affinity mask if it matches the online host CPU mask. There's still the chance that for some reason the deliberately chosen libvirtd affinity matches the online host CPU mask by accident. In this case the behavior remains as it was before (CPUs offline while setting the affinity will not be used if they show up later on). Signed-off-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com> Tested-by: Matthew Rosato <mjrosato(a)linux.vnet.ibm.com> --- src/qemu/qemu_process.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 1b67aee..76f9210 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2202,6 +2202,7 @@ qemuProcessInitCpuAffinity(virDomainObjPtr vm) int ret = -1; virBitmapPtr cpumap = NULL; virBitmapPtr cpumapToSet = NULL; + virBitmapPtr hostcpumap = NULL; qemuDomainObjPrivatePtr priv = vm->privateData; if (!vm->pid) { @@ -2223,6 +2224,16 @@ qemuProcessInitCpuAffinity(virDomainObjPtr vm) * the spawned QEMU instance to all pCPUs if no map is given in * its config file */ int hostcpus; + hostcpumap = virHostCPUGetOnlineBitmap(); + cpumap = virProcessGetAffinity(vm->pid); + + if (hostcpumap && cpumap && virBitmapEqual(hostcpumap, cpumap)) { + /* we're using all available CPUs, no reason to set + * mask. If libvirtd is running without explicit + * affinity, we can use hotplugged CPUs for this VM */ + ret = 0; + goto cleanup; + } /* setaffinity fails if you set bits for CPUs which * aren't present, so we have to limit ourselves */ @@ -2248,6 +2259,7 @@ qemuProcessInitCpuAffinity(virDomainObjPtr vm) cleanup: virBitmapFree(cpumap); + virBitmapFree(hostcpumap); return ret; } -- 1.9.1

4 6

[libvirt] [PATCH V2] qemu: Allow use of hot plugged host CPUs if no affinity set
by Viktor Mihajlovski 25 Nov '16

25 Nov '16

If the cpuset cgroup controller is disabled in /etc/libvirt/qemu.conf QEMU virtual machines can in principle use all host CPUs, even if they are hot plugged, if they have no explicit CPU affinity defined. However, there's libvirt code supposed to handle the situation where the libvirt daemon itself is not using all host CPUs. The code in qemuProcessInitCpuAffinity attempts to set an affinity mask including all defined host CPUs. Unfortunately, the resulting affinity mask for the process will not contain the offline CPUs. See also the sched_setaffinity(2) man page. That means that even if the host CPUs come online again, they won't be used by the QEMU process anymore. The same is true for newly hot plugged CPUs. So we are effectively preventing that QEMU uses all processors instead of enabling it to use them. It only makes sense to set the QEMU process affinity if we're able to actually grow the set of usable CPUs, i.e. if the process affinity is a subset of the online host CPUs. There's still the chance that for some reason the deliberately chosen libvirtd affinity matches the online host CPU mask by accident. In this case the behavior remains as it was before (CPUs offline while setting the affinity will not be used if they show up later on). Signed-off-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com> Tested-by: Matthew Rosato <mjrosato(a)linux.vnet.ibm.com> --- V2: - Avoid memory leak by freeing cpumap if the affinity has to be set. - Made an attempt to better describe the issue at hand src/qemu/qemu_process.c | 33 +++++++++++++++++++++++---------- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 4758c49..7e55086 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2202,6 +2202,7 @@ qemuProcessInitCpuAffinity(virDomainObjPtr vm) int ret = -1; virBitmapPtr cpumap = NULL; virBitmapPtr cpumapToSet = NULL; + virBitmapPtr hostcpumap = NULL; qemuDomainObjPrivatePtr priv = vm->privateData; if (!vm->pid) { @@ -2223,21 +2224,32 @@ qemuProcessInitCpuAffinity(virDomainObjPtr vm) * the spawned QEMU instance to all pCPUs if no map is given in * its config file */ int hostcpus; - - /* setaffinity fails if you set bits for CPUs which - * aren't present, so we have to limit ourselves */ - if ((hostcpus = virHostCPUGetCount()) < 0) + hostcpumap = virHostCPUGetOnlineBitmap(); + cpumap = virProcessGetAffinity(vm->pid); + + if (hostcpumap && cpumap && virBitmapEqual(hostcpumap, cpumap)) { + /* we're using all available CPUs, no reason to set + * mask. If libvirtd is running without explicit + * affinity, we can use hotplugged CPUs for this VM */ + ret = 0; goto cleanup; + } else { + /* setaffinity fails if you set bits for CPUs which + * aren't present, so we have to limit ourselves */ + if ((hostcpus = virHostCPUGetCount()) < 0) + goto cleanup; - if (hostcpus > QEMUD_CPUMASK_LEN) - hostcpus = QEMUD_CPUMASK_LEN; + if (hostcpus > QEMUD_CPUMASK_LEN) + hostcpus = QEMUD_CPUMASK_LEN; - if (!(cpumap = virBitmapNew(hostcpus))) - goto cleanup; + virBitmapFree(cpumap); + if (!(cpumap = virBitmapNew(hostcpus))) + goto cleanup; - virBitmapSetAll(cpumap); + virBitmapSetAll(cpumap); - cpumapToSet = cpumap; + cpumapToSet = cpumap; + } } } @@ -2248,6 +2260,7 @@ qemuProcessInitCpuAffinity(virDomainObjPtr vm) cleanup: virBitmapFree(cpumap); + virBitmapFree(hostcpumap); return ret; } -- 1.9.1

1 0

[libvirt] [PATCH 0/2] Fix probing for no-overwrite on fs storage
by John Ferlan 24 Nov '16

24 Nov '16

Details in the patches, especially #2. I'm not 100% certain the blkid_probe_filter_superblocks_type is really necessary, but left it there with a fixed list of probe'd types rather than removing and finding some corner issue later. John Ferlan (2): fs: Remove virStoragePoolProbeResult and FILESYSTEM_PROBE_ values fs: Fix probing on no-overwrite of target device src/storage/storage_backend_fs.c | 42 +++++++++++++++++++--------------------- src/storage/storage_backend_fs.h | 5 ----- 2 files changed, 20 insertions(+), 27 deletions(-) -- 2.7.4

2 7

[libvirt] [PATCH v4 0/2] List only online cpus for vcpupin/emulatorpin when vcpu placement static
by Nitesh Konkar 24 Nov '16

24 Nov '16

Currently when the vcpu placement is static and cpuset is not specified, CPU Affinity shows 0.. CPUMAX. This patchset will result in display of only online CPU's under CPU Affinity on linux. Fixes the following Bug: virsh dumpxml Fedora <domain type='kvm' id='4'> <name>Fedora</name> <uuid>aecf3e5e-6f9a-42a3-9d6a-223a75569a66</uuid> <maxMemory slots='32' unit='KiB'>3145728</maxMemory> <memory unit='KiB'>524288</memory> <currentMemory unit='KiB'>524288</currentMemory> <vcpu placement='static' current='8'>160</vcpu> <resource> <partition>/machine</partition> </resource> ..................... ....................... ......................... <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </memballoon> </devices> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+0:+0</label> <imagelabel>+0:+0</imagelabel> </seclabel> </domain> lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-2,4-7 Off-line CPU(s) list: 3 Thread(s) per core: 1 Core(s) per socket: 7 Socket(s): 1 .......... .......... NUMA node0 CPU(s): 0-2,4-7 NUMA node1 CPU(s): cat /sys/devices/system/cpu/online 0-2,4-7 Before Patch virsh vcpupin Fedora VCPU: CPU Affinity ---------------------------------- 0: 0-7 1: 0-7 ... ... 158: 0-7 159: 0-7 virsh emulatorpin Fedora emulator: CPU Affinity ---------------------------------- *: 0-7 After Patch virsh vcpupin Fedora VCPU: CPU Affinity ---------------------------------- 0: 0-2,4-7 1: 0-2,4-7 ... ... 158: 0-2,4-7 159: 0-2,4-7 virsh emulatorpin Fedora emulator: CPU Affinity ---------------------------------- *: 0-2,4-7 Nitesh Konkar (2): conf: List only online cpus for virsh vcpupin conf: List only online cpus for virsh emulatorpin src/conf/domain_conf.c | 6 ++++++ src/qemu/qemu_driver.c | 5 +++++ 2 files changed, 11 insertions(+) -- 2.1.0

2 3

[libvirt] [PATCH] util: fix domain object leaks on closecallbacks
by Wang King 24 Nov '16

24 Nov '16

From: wangjing <king.wang(a)huawei.com> The virCloseCallbacksSet method increase object reference for VM, and decrease object reference in virCloseCallbacksUnset. But VM UUID will be deleted from closecallbacks list in virCloseCallbacksRun when connection disconnected, and then object reference cannot be decreased by virCloseCallbacksUnset in callback functions. Signed-off-by: Wang King <king.wang(a)huawei.com> --- src/util/virclosecallbacks.c | 29 +++++++++++++++++------------ 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/src/util/virclosecallbacks.c b/src/util/virclosecallbacks.c index 891a92b..26d5075 100644 --- a/src/util/virclosecallbacks.c +++ b/src/util/virclosecallbacks.c @@ -300,7 +300,9 @@ virCloseCallbacksGetForConn(virCloseCallbacksPtr closeCallbacks, data.list = list; data.oom = false; + virObjectLock(closeCallbacks); virHashForEach(closeCallbacks->list, virCloseCallbacksGetOne, &data); + virObjectUnlock(closeCallbacks); if (data.oom) { VIR_FREE(list->entries); @@ -329,22 +331,15 @@ virCloseCallbacksRun(virCloseCallbacksPtr closeCallbacks, * them all from the hash. At that point we can release * the lock and run the callbacks safely. */ - virObjectLock(closeCallbacks); list = virCloseCallbacksGetForConn(closeCallbacks, conn); if (!list) return; for (i = 0; i < list->nentries; i++) { - char uuidstr[VIR_UUID_STRING_BUFLEN]; - virUUIDFormat(list->entries[i].uuid, uuidstr); - virHashRemoveEntry(closeCallbacks->list, uuidstr); - } - virObjectUnlock(closeCallbacks); - - for (i = 0; i < list->nentries; i++) { virDomainObjPtr vm; + virDomainObjPtr dom; - if (!(vm = virDomainObjListFindByUUID(domains, + if (!(vm = virDomainObjListFindByUUIDRef(domains, list->entries[i].uuid))) { char uuidstr[VIR_UUID_STRING_BUFLEN]; virUUIDFormat(list->entries[i].uuid, uuidstr); @@ -352,10 +347,20 @@ virCloseCallbacksRun(virCloseCallbacksPtr closeCallbacks, continue; } - vm = list->entries[i].callback(vm, conn, opaque); - if (vm) - virObjectUnlock(vm); + dom = list->entries[i].callback(vm, conn, opaque); + if (dom) + virObjectUnlock(dom); + virObjectUnref(vm); } + + virObjectLock(closeCallbacks); + for (i = 0; i < list->nentries; i++) { + char uuidstr[VIR_UUID_STRING_BUFLEN]; + virUUIDFormat(list->entries[i].uuid, uuidstr); + virHashRemoveEntry(closeCallbacks->list, uuidstr); + } + virObjectUnlock(closeCallbacks); + VIR_FREE(list->entries); VIR_FREE(list); } -- 2.8.3

1 0