- Devel - libvirt List Archives

[libvirt] [PATCH] conf: Fix initialization value of 'multi' in PCI address
by Xian Han Yu 12 Aug '16

12 Aug '16

Signed-off-by: Xian Han Yu <xhyubj(a)linux.vnet.ibm.com> --- src/conf/node_device_conf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c index a23d8ef..96fdb6f 100644 --- a/src/conf/node_device_conf.c +++ b/src/conf/node_device_conf.c @@ -1163,7 +1163,7 @@ virNodeDevCapPCIDevIommuGroupParseXML(xmlXPathContextPtr ctxt, goto cleanup; for (i = 0; i < nAddrNodes; i++) { - virPCIDeviceAddress addr = { 0, 0, 0, 0, 0 }; + virPCIDeviceAddress addr = { 0, 0, 0, 0, false }; if (virPCIDeviceAddressParseXML(addrNodes[i], &addr) < 0) goto cleanup; if (VIR_ALLOC(pciAddr) < 0) -- 2.5.5

6 12

[libvirt] [PATCH] schema: Allow spaces in paths
by Michal Privoznik 12 Aug '16

12 Aug '16

Since ages filesystems allowed to have space characters in filenames and even directory names. In fact, on all major filesystems out there you can have whatever character you like except NULL. There's no reason why we should forbid users to not have spaces in their filenames. Moreover, if we do that only on RNG schema level while our XML parser/formatter crunches that happily. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/schemas/basictypes.rng | 8 ++--- .../domainschemadata/domain-disk-source-space.xml | 36 ++++++++++++++++++++++ 2 files changed, 40 insertions(+), 4 deletions(-) create mode 100644 tests/domainschemadata/domain-disk-source-space.xml diff --git a/docs/schemas/basictypes.rng b/docs/schemas/basictypes.rng index 474ad77..f2b7930 100644 --- a/docs/schemas/basictypes.rng +++ b/docs/schemas/basictypes.rng @@ -247,25 +247,25 @@ <define name="filePath"> <data type="string"> - <param name="pattern">[a-zA-Z0-9_\.\+\-\\&"'<>/%]+</param> + <param name="pattern">[a-zA-Z0-9_\.\+\-\\&"'<>/% ]+</param> </data> </define> <define name="dirPath"> <data type="string"> - <param name="pattern">[a-zA-Z0-9_\.\+\-\\&"'<>/%]+</param> + <param name="pattern">[a-zA-Z0-9_\.\+\-\\&"'<>/% ]+</param> </data> </define> <define name="absFilePath"> <data type="string"> - <param name="pattern">/[a-zA-Z0-9_\.\+\-\\&"'<>/%,:]+</param> + <param name="pattern">/[a-zA-Z0-9_\.\+\-\\&"'<>/%,: ]+</param> </data> </define> <define name="absDirPath"> <data type="string"> - <param name="pattern">/[a-zA-Z0-9_\.\+\-\\&"'<>/%]*</param> + <param name="pattern">/[a-zA-Z0-9_\.\+\-\\&"'<>/% ]*</param> </data> </define> diff --git a/tests/domainschemadata/domain-disk-source-space.xml b/tests/domainschemadata/domain-disk-source-space.xml new file mode 100644 index 0000000..553b6c7 --- /dev/null +++ b/tests/domainschemadata/domain-disk-source-space.xml @@ -0,0 +1,36 @@ +<domain type='kvm'> + <name>dummy</name> + <uuid>aa86471a-e67b-41b1-8d7d-2dc37c2ac5ec</uuid> + <memory unit='KiB'>2097152</memory> + <currentMemory unit='KiB'>2097152</currentMemory> + <vcpu placement='static'>4</vcpu> + <os> + <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type> + </os> + <features> + <acpi/> + <apic/> + </features> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/a/path/with some space in it.iso'/> + <target dev='hda' bus='ide'/> + <readonly/> + <boot order='1'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + </devices> +</domain> -- 2.8.4

2 2

[libvirt] [PATCH 0/5] Introduce NVDIMM support
by Michal Privoznik 12 Aug '16

12 Aug '16

NVDIMM was introduced to qemu in v2.6.0-rc0~248^2~25. So it's been a while since then. It's not the next big thing, but it is very interesting feature enabling higher performance as reading/writing to the module (and subsequently to the file on the host) does not require a VMEXIT. It can be used to access host files directly bypassing page cache whilst doing so. How to test the feature? 1) you need PMEM enabled kernel: CONFIG_LIBNVDIMM=y CONFIG_BLK_DEV_PMEM=m CONFIG_ACPI_NFIT=m 2) Create a file in the host: truncate -s 512M /tmp/nvdimm 3) Add the following to the domain XML: <memory model='nvdimm' memAccess='shared'> <source> <path>/tmp/nvdimm</path> </source> <target> <size unit='KiB'>523264</size> <node>0</node> </target> </memory> 4) Start the domain and write something into the NVDIMM module: (guest) $ echo 'Hello world' > /dev/pmem0 5) From the host, check the file has changed: (host) $ hexdump -C /tmp/nvdimm Want to watch very interesting video while reviewing? https://youtu.be/Vit3-PjbN9M Michal Privoznik (5): Introduce NVDIMM memory model qemu: Introduce QEMU_CAPS_DEVICE_NVDIMM qemu: Implement NVDIMM conf: Introduce memAccess to <memory/> qemu: Implement memAccess for <memory/> banks docs/formatdomain.html.in | 41 ++++++-- docs/schemas/domaincommon.rng | 51 ++++++---- src/conf/domain_conf.c | 112 ++++++++++++++++----- src/conf/domain_conf.h | 4 + src/libvirt_private.syms | 2 + src/qemu/qemu_alias.c | 12 ++- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 87 +++++++++++----- src/qemu/qemu_command.h | 2 + src/qemu/qemu_domain.c | 29 ++++-- src/qemu/qemu_hotplug.c | 3 +- tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + .../qemuxml2argv-hugepages-numa.args | 5 +- .../qemuxml2argv-hugepages-pages.args | 24 ++--- .../qemuxml2argv-hugepages-pages2.args | 8 +- .../qemuxml2argv-hugepages-pages3.args | 4 +- .../qemuxml2argv-hugepages-shared.args | 22 ++-- .../qemuxml2argv-memory-hotplug-dimm-addr.args | 5 +- .../qemuxml2argv-memory-hotplug-dimm.args | 5 +- ...muxml2argv-memory-hotplug-nvdimm-memAccess.args | 26 +++++ ...emuxml2argv-memory-hotplug-nvdimm-memAccess.xml | 49 +++++++++ .../qemuxml2argv-memory-hotplug-nvdimm.args | 25 +++++ .../qemuxml2argv-memory-hotplug-nvdimm.xml | 49 +++++++++ tests/qemuxml2argvtest.c | 6 +- 25 files changed, 452 insertions(+), 123 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-memory-hotplug-nvdimm-memAccess.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-memory-hotplug-nvdimm-memAccess.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-memory-hotplug-nvdimm.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-memory-hotplug-nvdimm.xml -- 2.8.4

4 9

Re: [libvirt] wiki accounts for GSOC submissions
by Tomasz Flendrich 11 Aug '16

11 Aug '16

Hello, please sign me up too. username: tflendrich email: t.flendrich gmail com

1 0

[libvirt] Failing build on rawhide
by Martin Kletzander 11 Aug '16

11 Aug '16

So after updating my fedora-rawhide machines, I started receiving an interesting error: In file included from /usr/include/features.h:397:0, from /usr/include/bits/libc-header-start.h:33, from /usr/include/stdio.h:28, from ../gnulib/lib/stdio.h:43, from util/vircgroup.c:26: /usr/include/sys/sysmacros.h:88:1: note: declared here __SYSMACROS_DEFINE_MINOR (__SYSMACROS_FST_IMPL_TEMPL) ^ util/vircgroup.c: In function 'virCgroupAllowDevicePath': util/vircgroup.c:2944:33: error: '__major_from_sys_types' is deprecated: In the GNU C Library, `major' is defined by <sys/sysmacros.h>. For historical compatibility, it is currently defined by <sys/types.h> as well, but we plan to remove this soon. To use `major', include <sys/sysmacros.h> directly. If you did not intend to use a system-defined macro `major', you should #undef it after including <sys/types.h>. [-Werror=deprecated-declarations] major(sb.st_rdev), ^~~~~ It looks like we might need to reorder the includes, but whatever I do, I still get the warning. Updating gnulib doesn't help, so either we need to #undef minor/major/makedev, or maybe gnulib needs to fix that (my guess inspired by the include stack above). So I figured I just post my findings here and let others continue the wondering so that I can do some more useful stuff. Have a nice day, Martin

2 1

[libvirt] [PATCHv2 00/11] qemu: allow disabling certain virtio revisions
by Ján Tomko 11 Aug '16

11 Aug '16

https://bugzilla.redhat.com/show_bug.cgi?id=1227354 v1: https://www.redhat.com/archives/libvir-list/2016-July/msg01235.html v2: * probe for the qemu capability * add the attribute to virtio1-only devices such as virtio-gpu and virtio-input devices * allow multiple revisions to be specified Ján Tomko (11): Use separate buffer for <input> subelements Add virtio revision attribute to memballoon Add virtio revision attribute to disks Add virtio revision attribute to controllers Add virtio revision attribute to filesystems Add virtio revision attribute to interfaces Add virtio revision to rng devices Add virtio revision attribute to video Add virtio revision attribute to input devices Introduce QEMU_CAPS_DEVICE_VIRTIO_REVISION qemu: format options for enforcing virtio revisions docs/formatdomain.html.in | 69 ++++++++++ docs/schemas/domaincommon.rng | 37 ++++++ src/conf/domain_conf.c | 148 +++++++++++++++++++-- src/conf/domain_conf.h | 16 +++ src/qemu/qemu_capabilities.c | 6 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 56 ++++++++ tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 1 + .../caps_2.6.0-gicv2.aarch64.xml | 1 + .../caps_2.6.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 + .../qemuxml2argv-virtio-revision.args | 62 +++++++++ .../qemuxml2argv-virtio-revision.xml | 113 ++++++++++++++++ tests/qemuxml2argvtest.c | 11 ++ .../qemuxml2xmlout-virtio-revision.xml | 113 ++++++++++++++++ tests/qemuxml2xmltest.c | 2 + 19 files changed, 630 insertions(+), 11 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-revision.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-revision.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-virtio-revision.xml -- 2.7.3

3 20

[libvirt] [PATCH 0/6] Use more PCIe, less legacy PCI slots
by Laine Stump 11 Aug '16

11 Aug '16

These patches use three methods to get more of the PCI devices onto PCIe slots on Q35 and aarch64/virt machinetypes: 1) When virtio devices can present themselves as PCIe if they're plugged into a PCIe controller, do that. (This capability is detected by looking for presence of the "disable-modern" option on the virtio-net device. If you have a better idea for how to detect it, please let me know.) 2) Any devices that aren't hotpluggable anyway will no longer request a hotplug-capable slot. This, along with a change to auto-assign legacy PCI devices to pcie-root (as long as they don't require hotplug) means the devices will now be assigned to pcie-root. 3) Also using the fact that devices that won't be hotplugged can be assigned to pcie-root, the devices that *do* support hotplug have a new optional subelement "<hotplug require='no'/>" (it defaults to "yes" for historical reasons). If hotplug require is set to 'no', even a PCI device can be auto-assigned to pcie-root. I haven't yet removed the dmi-to-pci-bridge that is added by default, and we still will only auto-add pci-bridge (so if you're adding a virtio device without <hostplug require='no'/> then you will also need to add a <controller type='pci' model='pcie-root-port'/> to plug it into). These 6 patches together resolve: https://bugzilla.redhat.com/show_bug.cgi?id=1330024 They need to be applied on top of the series I sent on Friday: https://www.redhat.com/archives/libvir-list/2016-August/msg00380.html Laine Stump (6): conf: restrict what type of buses will accept a pci-bridge conf: permit auto-assignment of *non-hotpluggable* PCI devices to pcie-root qemu: add capabilities bit for virtio-net "disable-modern" option conf: new <hotplug require='yes|no'/> element for hotpluggable devices qemu: don't require a hotpluggable slot for devices that can't be hotplugged qemu: auto-assign virtio devices to PCIe slots when appropriate docs/formatdomain.html.in | 37 +++++++ docs/schemas/domaincommon.rng | 17 +++ src/conf/device_conf.h | 15 +++ src/conf/domain_addr.c | 44 ++++++-- src/conf/domain_addr.h | 4 +- src/conf/domain_conf.c | 28 +++++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_domain_address.c | 94 ++++++++++++++-- tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 1 + .../caps_2.6.0-gicv2.aarch64.xml | 1 + .../caps_2.6.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-autoindex.args | 22 ++-- .../qemuxml2argv-bios-nvram-secure.args | 2 +- .../qemuxml2argv-machine-smm-opt.args | 2 +- .../qemuxml2argv-q35-hotpluggable.args | 50 +++++++++ .../qemuxml2argv-q35-hotpluggable.xml | 62 +++++++++++ .../qemuxml2argv-q35-pm-disable-fallback.args | 3 +- .../qemuxml2argv-q35-pm-disable.args | 3 +- .../qemuxml2argv-q35-usb2-multi.args | 10 +- .../qemuxml2argv-q35-usb2-reorder.args | 10 +- .../qemuxml2argv-q35-virtio-pcie.args | 54 +++++++++ .../qemuxml2argv-q35-virtio-pcie.xml | 69 ++++++++++++ tests/qemuxml2argvtest.c | 18 +++ .../qemuxml2xmlout-autoindex.xml | 18 +-- .../qemuxml2xmlout-q35-hotpluggable.xml | 103 +++++++++++++++++ .../qemuxml2xmlout-q35-usb2-multi.xml | 8 +- .../qemuxml2xmlout-q35-usb2-reorder.xml | 8 +- .../qemuxml2xmlout-q35-virtio-pcie.xml | 123 +++++++++++++++++++++ tests/qemuxml2xmltest.c | 15 +++ 34 files changed, 765 insertions(+), 64 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-hotpluggable.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-hotpluggable.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pcie.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pcie.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-hotpluggable.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-virtio-pcie.xml -- 2.7.4

3 19

[libvirt] [PATCH] lxc: don't try to resolve a NULL path for filesystems
by Daniel P. Berrange 11 Aug '16

11 Aug '16

<filesystem type='ram' accessmode='passthrough'> <source usage='524288' units='KiB'/> <target dir='/dev/shm'/> </filesystem> would lead to lxcContainerResolveSymlinks calling access(NULL) because it failed to check if fs->src->path was non-NULL. This is a regression caused by commit da665fbd4858890fbb3bbf5da2a7b6ca37bb3220 Author: Olga Krishtal <okrishtal(a)virtuozzo.com> Date: Thu Jul 14 16:52:38 2016 +0300 filesystem: adds possibility to use storage pool as fs source Signed-off-by: Olga Krishtal <okrishtal(a)virtuozzo.com> Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/lxc/lxc_container.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 124b441..e1eb434 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -616,7 +616,7 @@ static int lxcContainerResolveSymlinks(virDomainFSDefPtr fs, bool gentle) { char *newroot; - if (!fs->src || fs->symlinksResolved) + if (!fs->src || !fs->src->path || fs->symlinksResolved) return 0; if (access(fs->src->path, F_OK)) { -- 2.7.4

2 1

[libvirt] [PATCH 0/7] qemu: Trivially add support for newer ivshmem
by Martin Kletzander 11 Aug '16

11 Aug '16

It's "trivially" because it's just about using different parameters. It is a series because I wanted to make some code paths saner and some output nicer, but I tried keeping every patch self-contained and as small as possible while keeping the readability. Also I wanted to make the series to be looked upon by more people by just using the word "trivial". Sorry for that =) Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1347049 Martin Kletzander (7): qemu: Add capabilities for ivshmem-{plain,doorbell} qemu: Save various defaults for shmem qemu: Make qemuBuildShmemDevStr static qemu: Rename qemuBuildShmemDevStr to qemuBuildShmemDevLegacyStr qemu: Move common checks outside qemuBuildShmemDevLegacyStr qemu: Reorder shmem params nicely qemu: Support newer ivshmem and prefer that over the legacy one src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 144 +++++++++++++++------ src/qemu/qemu_command.h | 4 - src/qemu/qemu_domain.c | 18 +++ .../caps_2.6.0-gicv2.aarch64.xml | 2 + .../caps_2.6.0-gicv3.aarch64.xml | 2 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 2 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 2 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 2 + .../qemuxml2argv-shmem-plain-doorbell.args | 42 ++++++ .../qemuxml2argv-shmem-plain-doorbell.xml} | 14 +- tests/qemuxml2argvdata/qemuxml2argv-shmem.args | 16 +-- tests/qemuxml2argvtest.c | 3 + tests/qemuxml2xmloutdata/qemuxml2xmlout-shmem.xml | 1 + 15 files changed, 193 insertions(+), 65 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-shmem-plain-doorbell.args copy tests/{qemuxml2xmloutdata/qemuxml2xmlout-shmem.xml => qemuxml2argvdata/qemuxml2argv-shmem-plain-doorbell.xml} (66%) -- 2.9.2

2 10

[libvirt] an AB deadlock or libvirtd crash problem in virsh console and virsh destroy
by weifuqiang 11 Aug '16

11 Aug '16

Hi all: I encountered with an AB deadlock and libvirtd crash problem the other day. The process to generate the problems: 1 use the command "virsh create ***.xml" to create a vm 2 after vm is running , use the command "virsh console ***" to connect vm with console 3 after connection, use the command "virsh destroy ****" to destroy vm and delete it Then, an AB lock problem occurs, or libvirtd got crashed. AB LOCK stack: [Switching to thread 1 (Thread 0x7ff96bf3d7a0 (LWP 9772))] #0 0x00007ff967b49324 in __lll_lock_wait () from /lib64/libpthread.so.0 #0 0x00007ff967b49324 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007ff967b44669 in _L_lock_1008 () from /lib64/libpthread.so.0 #2 0x00007ff967b4447e in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007ff96b3bd96c in virChrdevFDStreamCloseCb () from /usr/lib64/libvirt.so.0 #4 0x00007ff96b3c9a34 in virFDStreamCloseInt () from /usr/lib64/libvirt.so.0 #5 0x00007ff96b40ac3e in virStreamAbort () from /usr/lib64/libvirt.so.0 #6 0x00007ff96bfa242a in daemonStreamHandleAbort () #7 0x00007ff96bfa2803 in daemonStreamEvent () #8 0x00007ff96b3c9bfc in virFDStreamEvent () from /usr/lib64/libvirt.so.0 #9 0x00007ff96b3083aa in virEventPollRunOnce () from /usr/lib64/libvirt.so.0 #10 0x00007ff96b307042 in virEventRunDefaultImpl () from /usr/lib64/libvirt.so.0 #11 0x00007ff96b4503dd in virNetDaemonRun () from /usr/lib64/libvirt.so.0 #12 0x00007ff96bf72528 in main () [Switching to thread 12 (Thread 0x7ff9640ff700 (LWP 9778))] #0 0x00007ff967b49324 in __lll_lock_wait () from /lib64/libpthread.so.0 #0 0x00007ff967b49324 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007ff967b44669 in _L_lock_1008 () from /lib64/libpthread.so.0 #2 0x00007ff967b4447e in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007ff96b3c8f26 in virFDStreamSetInternalCloseCb () from /usr/lib64/libvirt.so.0 #4 0x00007ff96b30f7b9 in virHashForEach () from /usr/lib64/libvirt.so.0 #5 0x00007ff96b3be1a2 in virChrdevFree () from /usr/lib64/libvirt.so.0 #6 0x00007ff96055980f in qemuDomainObjPrivateFree () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so #7 0x00007ff96b367014 in virDomainObjDispose () from /usr/lib64/libvirt.so.0 #8 0x00007ff96b330c33 in virObjectUnref () from /usr/lib64/libvirt.so.0 #9 0x00007ff96b35edb9 in virDomainObjEndAPI () from /usr/lib64/libvirt.so.0 #10 0x00007ff9605c6e89 in qemuDomainUndefineFlags () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so #11 0x00007ff96b3e35ac in virDomainUndefine () from /usr/lib64/libvirt.so.0 #12 0x00007ff96bf996db in remoteDispatchDomainUndefineHelper () #13 0x00007ff96b4537ef in virNetServerProgramDispatch () from /usr/lib64/libvirt.so.0 #14 0x00007ff96b45205e in virNetServerProcessMsg () from /usr/lib64/libvirt.so.0 #15 0x00007ff96b4520e8 in virNetServerHandleJob () from /usr/lib64/libvirt.so.0 #16 0x00007ff96b349f94 in virThreadPoolWorker () from /usr/lib64/libvirt.so.0 #17 0x00007ff96b3494a8 in virThreadHelper () from /usr/lib64/libvirt.so.0 #18 0x00007ff967b42806 in start_thread () from /lib64/libpthread.so.0 #19 0x00007ff96789d67d in clone () from /lib64/libc.so.6 #20 0x0000000000000000 in ?? () coredump stack (gdb) f 1 #1 0x00007f1672a7c73f in virMutexLock (m=0x68) at util/virthread.c:89 89 pthread_mutex_lock(&m->lock); (gdb) bt #0 0x00007f1670ace444 in pthread_mutex_lock () from /lib64/libpthread.so.0 #1 0x00007f1672a7c73f in virMutexLock (m=0x68) at util/virthread.c:89 #2 0x00007f1672b2fda2 in virFDStreamSetInternalCloseCb (st=0x7f1673a1a370, cb=0x0, opaque=0x0, fcb=0x0) at fdstream.c:796 #3 0x00007f1672b1f5ad in virChrdevFreeClearCallbacks (payload=0x7f1673a1a370, name=0x7f1673a12520, data=0x0) at conf/virchrdev.c:301 #4 0x00007f1672a36c9b in virHashForEach (table=0x7f1673a0ba20, iter=0x7f1672b1f567 <virChrdevFreeClearCallbacks>, data=0x0) at util/virhash.c:521 #5 0x00007f1672b1f626 in virChrdevFree (devs=0x7f1673a2f820) at conf/virchrdev.c:316 #6 0x00007f1669cca988 in qemuDomainObjPrivateFree (data=0x7f1673a1afa0) at qemu/qemu_domain.c:496 #7 0x00007f1672a9e293 in virDomainObjDispose (obj=0x7f1673a16400) at conf/domain_conf.c:2545 #8 0x00007f1672a5b326 in virObjectUnref (anyobj=0x7f1673a16400) at util/virobject.c:265 #9 0x00007f1672a9e7a5 in virDomainObjEndAPI (vm=0x7f166b07d8d0) at conf/domain_conf.c:2684 #10 0x00007f1669d3ff00 in qemuDomainDestroyFlags (dom=0x7f16600017f0, flags=0) at qemu/qemu_driver.c:2264 #11 0x00007f1669d3ff69 in qemuDomainDestroy (dom=0x7f16600017f0) at qemu/qemu_driver.c:2273 #12 0x00007f1672b39333 in virDomainDestroy (domain=0x7f16600017f0) at libvirt-domain.c:483 #13 0x00007f16737167a5 in remoteDispatchDomainDestroy (server=0x7f167398f4f0, client=0x7f1673a172f0, msg=0x7f1673a2fc70, rerr=0x7f166b07db50, args=0x7f1673a2f9b0) at remote_dispatch.h:4002 #14 0x00007f1673716648 in remoteDispatchDomainDestroyHelper (server=0x7f167398f4f0, client=0x7f1673a172f0, msg=0x7f1673a2fc70, rerr=0x7f166b07db50, args=0x7f1673a2f9b0, ret= 0x7f1673a10e10) at remote_dispatch.h:3977 #15 0x00007f1672bd8a9b in virNetServerProgramDispatchCall (prog=0x7f167399c610, server=0x7f167398f4f0, client=0x7f1673a172f0, msg=0x7f1673a2fc70) at rpc/virnetserverprogram.c:437 #16 0x00007f1672bd85fd in virNetServerProgramDispatch (prog=0x7f167399c610, server=0x7f167398f4f0, client=0x7f1673a172f0, msg=0x7f1673a2fc70) at rpc/virnetserverprogram.c:307 #17 0x00007f1672bd2a08 in virNetServerProcessMsg (srv=0x7f167398f4f0, client=0x7f1673a172f0, prog=0x7f167399c610, msg=0x7f1673a2fc70) at rpc/virnetserver.c:136 #18 0x00007f1672bd2aed in virNetServerHandleJob (jobOpaque=0x7f1673a1d780, opaque=0x7f167398f4f0) at rpc/virnetserver.c:157 #19 0x00007f1672a7d833 in virThreadPoolWorker (opaque=0x7f167399bad0) at util/virthreadpool.c:145 #20 0x00007f1672a7cbec in virThreadHelper (data=0x7f167399c980) at util/virthread.c:206 #21 0x00007f1670acc806 in start_thread () from /lib64/libpthread.so.0 #22 0x00007f167082767d in clone () from /lib64/libc.so.6 #23 0x0000000000000000 in ?? () (gdb) bt #0 0x00007f1670ad3324 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f1670ace669 in _L_lock_1008 () from /lib64/libpthread.so.0 #2 0x00007f1670ace47e in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007f1672a7c73f in virMutexLock (m=0x7f1673a2f820) at util/virthread.c:89 #4 0x00007f1672b1f3fe in virChrdevFDStreamCloseCb (st=0x7f1673a1a370, opaque=0x7f1673a149e0) at conf/virchrdev.c:254 #5 0x00007f1672b2e8a8 in virFDStreamCloseInt (st=0x7f1673a1a370, streamAbort=true) at fdstream.c:329 #6 0x00007f1672b2e9d5 in virFDStreamAbort (st=0x7f1673a1a370) at fdstream.c:355 #7 0x00007f1672b7d856 in virStreamAbort (stream=0x7f1673a1a370) at libvirt-stream.c:663 #8 0x00007f16737497e8 in daemonStreamHandleAbort (client=0x7f1673a1b1b0, stream=0x7f1673a1ec50, msg=0x7f1673a0d660) at stream.c:613 #9 0x00007f16737499fa in daemonStreamHandleWrite (client=0x7f1673a1b1b0, stream=0x7f1673a1ec50) at stream.c:662 #10 0x00007f167374866b in daemonStreamEvent (st=0x7f1673a1a370, events=14, opaque=0x7f1673a1b1b0) at stream.c:138 #11 0x00007f1672b2e17a in virFDStreamEvent (watch=18, fd=17, events=14, opaque=0x7f1673a1a370) at fdstream.c:173 #12 0x00007f1672a2c2cb in virEventPollDispatchHandles (nfds=12, fds=0x7f1673a2fda0) at util/vireventpoll.c:509 #13 0x00007f1672a2cb08 in virEventPollRunOnce () at util/vireventpoll.c:658 #14 0x00007f1672a2a9e0 in virEventRunDefaultImpl () at util/virevent.c:308 #15 0x00007f1672bd25d2 in virNetDaemonRun (dmn=0x7f1673990ed0) at rpc/virnetdaemon.c:707 #16 0x00007f167370cad4 in main (argc=3, argv=0x7ffd63276288) at libvirtd.c:1581 The reason of this problem is that fdstream abort event or close event occured at the same time, libvirtd doesn't deal with the synchronousness well enough. the flows about fdStream is bellow 1、qemuDomainDefineXMLFlags -> virDomainObjListAdd -> qemuDomainObjPrivateAlloc -> virChrdevAlloc -> virHashCreate 2、qemuDomainOpenConsole -> virChrdevOpen -> virHashAddEntry(devs->hash, path, st) 3、virDomainObjDispose -> privateDataFreeFunc (qemuDomainObjPrivateFree) - > virChrdevFree(*dev locked*) -> virChrdevFreeClearCallbacks - > virFDStreamSetInternalCloseCb(*fdst locked*) 4、virFDStreamCloseInt (*fdst locked*) -> icbFreeOpaque(virChrdevFDStreamCloseCb (*dev locked*)) -> virHashRemoveEntry The AB lock problem is obviouse: in step 3, it locks chardev before fdst, and in step 4, it's the opsite way. The reason of libvirtd crash is that: in virFDStreamCloseInt function we set fdst to NULL, while in virFDStreamSetInternalCloseCb we use fdst->lock, note that fdst has already been freed. another crash problem occurs because that when virChrdevFree was earlier finished, dev->hash freed and all date of hash is freed, but fdstream event flow use fdStream after hash free. Ahha~~， libvirtd coredump. All of those problem is because clear vm flow and fdStream flow concurs synchronously. then I fix this problem by modify virChrdevFree() void virChrdevFree(virChrdevsPtr devs) { if (!devs || !devs->hash) return; for (;;) { virMutexLock(&devs->lock); if (0 == virHashSize(devs->hash)) { virMutexUnlock(&devs->lock); break; } virMutexUnlock(&devs->lock); usleep(10 * 1000); } virMutexLock(&devs->lock); virHashFree(devs->hash); virMutexUnlock(&devs->lock); virMutexDestroy(&devs->lock); VIR_FREE(devs); } If the chardev is removed by fdStream close or fdStream abort when vm destroy or shutdown, the modification works well. But I'm not sure is that all chardev would be removed when we clear vm, if not, it would always sleep here. Another solution is as follows: virMutexLock(vm); virChrdevFree(); virMutexUnlock(vm); virMutexLock(vm); virFDStreamCloseInt(); virMutexUnlock(vm); I lock vm before calling these 2 functions, which makes them run sequently. Do you have other better idea to solve this problem. thanks in advance. Thanks in advance. Wei Fuqiang

2 1