- Devel - libvirt List Archives

[libvirt] [PATCH] libxl_driver: Indent LIBXL_VBD_SECTOR_SIZE macro correctly
by Michal Privoznik 16 Aug '16

16 Aug '16

Because of change in caaa1bd357a99ad this macro is no under #ifdef block. That means it needs to be re-intended correctly. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed under build-breaker rule. src/libxl/libxl_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index 1170062..a573c82 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -5307,7 +5307,7 @@ libxlDiskPathToID(const char *virtpath) return id; } -#define LIBXL_VBD_SECTOR_SIZE 512 +# define LIBXL_VBD_SECTOR_SIZE 512 static int libxlDiskSectorSize(int domid, int devno) -- 2.8.4

1 0

[libvirt] [PATCH] tests: fix domaincapstest linking for libxl
by Roman Bogorodskiy 16 Aug '16

16 Aug '16

Commit 11567cf added some libxl tests into domaincapstest and added libvirt_driver_libxl_impl.la to domaincapstest_LDADD. This causes link fail on systems without GNU regex implementation: gmake[2]: Entering directory '/usr/home/novel/code/libvirt/tests' CCLD domaincapstest ../src/.libs/libvirt_driver_libxl_impl.a(libvirt_driver_libxl_impl_la-libxl_capabilities.o): In function `libxlMakeCapabilities': libxl/libxl_capabilities.c:(.text+0x6b2): undefined reference to `rpl_regcomp' libxl/libxl_capabilities.c:(.text+0x6d0): undefined reference to `rpl_regerror' libxl/libxl_capabilities.c:(.text+0x803): undefined reference to `rpl_regexec' libxl/libxl_capabilities.c:(.text+0xa58): undefined reference to `rpl_regfree' clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation) This happens because on these system it tries to use gnulib's builtin regex implementation, but doesn't link to gnulib. Fix by adding $(GNULIB_LIBS) along with libvirt_driver_libxl_impl.la to domaincapstest_LDADD. --- tests/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 5714d11..0cd8391 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -953,7 +953,7 @@ endif WITH_QEMU if WITH_LIBXL domaincapstest_SOURCES += testutilsxen.c testutilsxen.h -domaincapstest_LDADD += ../src/libvirt_driver_libxl_impl.la +domaincapstest_LDADD += ../src/libvirt_driver_libxl_impl.la $(GNULIB_LIBS) endif WITH_LIBXL virnetmessagetest_SOURCES = \ -- 2.7.4

2 2

[libvirt] [PATCH] libxl: fix unused functions
by Roman Bogorodskiy 16 Aug '16

16 Aug '16

Commit eee7bd4e introduced two functions: libxlDiskPathToID and libxlDiskSectorSize. However, as they're used only by code under #ifdef __linux__, on non-Linux platforms it results in errors similar to this: CC libxl/libvirt_driver_libxl_impl_la-libxl_driver.lo libxl/libxl_driver.c:5263:1: error: unused function 'libxlDiskPathToID' [-Werror,-Wunused-function] libxlDiskPathToID(const char *virtpath) ^ libxl/libxl_driver.c:5312:1: error: unused function 'libxlDiskSectorSize' [-Werror,-Wunused-function] libxlDiskSectorSize(int domid, int devno) ^ 2 errors generated. Fix that by moving these functions under the #ifdef __linux__ block. --- src/libxl/libxl_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index 4957072..1170062 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -5259,6 +5259,7 @@ libxlDomainGetJobStats(virDomainPtr dom, return ret; } +#ifdef __linux__ static int libxlDiskPathToID(const char *virtpath) { @@ -5348,7 +5349,6 @@ libxlDiskSectorSize(int domid, int devno) return ret; } -#ifdef __linux__ static int libxlDomainBlockStatsVBD(virDomainObjPtr vm, const char *dev, -- 2.7.4

2 2

[libvirt] [PATCH 0/3] Node device update lifecycle event as top level event
by Jovanka Gulicoska 15 Aug '16

15 Aug '16

Introduce node device update lifecycle as top level event. Series include API implementation, udev driver implementation, event-test implementation and virsh nodedev-event changes. Jovanka Gulicoska (3): Introduce node device update event as top level event virsh: nodedev-event update callback support event-test: add support node device update event API daemon/remote.c | 29 +++++++++++++++++ examples/object-events/event-test.c | 12 +++++++ include/libvirt/libvirt-nodedev.h | 1 + src/conf/node_device_event.c | 55 ++++++++++++++++++++++++++++++++ src/conf/node_device_event.h | 3 ++ src/libvirt_private.syms | 1 + src/node_device/node_device_udev.c | 2 ++ src/remote/remote_driver.c | 30 ++++++++++++++++++ src/remote/remote_protocol.x | 13 +++++++- src/remote_protocol-structs | 5 +++ tools/virsh-nodedev.c | 62 ++++++++++++++++++++++++++++++++----- 11 files changed, 204 insertions(+), 9 deletions(-) -- 2.7.4

2 4

[libvirt] [PATCH] virsh: Fix core for cmdSecretGetValue
by John Ferlan 15 Aug '16

15 Aug '16

https://bugzilla.redhat.com/show_bug.cgi?id=1366611 When commit id 'cb2e3e50' reworked the cmdSecretGetValue call to use VIR_DISPOSE_STRING for base64, it neglected to initialize the base64 value to NULL since the cleanup: label could be reached prior to the base64 value being set or not. This resulted in a core dump, adding the initialization will avoid the issue. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- tools/virsh-secret.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/virsh-secret.c b/tools/virsh-secret.c index 8588f4c..537bdd7 100644 --- a/tools/virsh-secret.c +++ b/tools/virsh-secret.c @@ -253,7 +253,7 @@ static bool cmdSecretGetValue(vshControl *ctl, const vshCmd *cmd) { virSecretPtr secret; - char *base64; + char *base64 = NULL; unsigned char *value; size_t value_size; bool ret = false; -- 2.7.4

2 1

[libvirt] Drop support for old libvirt versions?
by Andrea Bolognani 15 Aug '16

15 Aug '16

A while ago, we agreed to drop support for QEMU versions older than 0.12.0, with the rationale that we should focus on operating systems that are still supported by the respective vendors, eg. RHEL/CentOS 6, Ubuntu 12.04 and SLES 11. Recently, when discussing how to ensure a certain change will not break migration with libvirt <= 0.9.4, I started wondering whether we should apply the same rationale to libvirt versions as well. Here's a quick run down of relevant libvirt versions: SLES 11 → ??? RHEL 6.0 → 0.8.1 Ubuntu 12.04 → 0.9.2 RHEL 6.8 → 0.10.2 Ubuntu 12.04.5 → 0.9.8 SLES 11 SP4 → 1.2.5 One thing I'm not clear about is whether or not SUSE, Red Hat and Canonical will support old minor releases or just the latest one. If the latter, we could safely drop support for anything older than 0.9.8, which incidentally would make the discussion referenced above entirely moot ;) In any case, having a well-defined cut-off point has been very useful when dealing with QEMU, so I think having one for libvirt itself would be beneficial too. Looking forward to your thoughts on this :) -- Andrea Bolognani / Red Hat / Virtualization

7 9

[libvirt] [PATCH] qemu_command: don't modify heads for graphics device
by Pavel Hrdina 13 Aug '16

13 Aug '16

Setting heads to 0 in case that *max_outputs* is not supported while building command line doesn't have any real effect. It only removes *heads* attribute from live XML, but after restarting libvirt the default value is restored. Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/qemu/qemu_command.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 55df23d..06f5091 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -4298,8 +4298,6 @@ qemuBuildDeviceVideoStr(const virDomainDef *def, virQEMUCapsGet(qemuCaps, QEMU_CAPS_QXL_MAX_OUTPUTS))) { if (video->heads) virBufferAsprintf(&buf, ",max_outputs=%u", video->heads); - } else { - video->heads = 0; } } else if (video->vram && ((video->type == VIR_DOMAIN_VIDEO_TYPE_VGA && -- 2.9.2

2 3

[libvirt] libvirtd crash with host cpu model qemu64
by Jim Fehlig 13 Aug '16

13 Aug '16

I have an L1 nested VM with the following cpu # lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 2 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 6 Model: 2 Model name: QEMU Virtual CPU version 0.14 Stepping: 3 CPU MHz: 3092.210 BogoMIPS: 6184.42 Virtualization: AMD-V Hypervisor vendor: KVM Virtualization type: full L1d cache: 64K L1i cache: 64K L2 cache: 512K NUMA node0 CPU(s): 0,1 Flags: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm nopl pni cx16 popcnt hypervisor lahf_lm svm abm sse4a 3dnowprefetch vmmcall When starting an L2 VM with <cpu mode="host-model">, libvirtd in the L1 VM crashes Program received signal SIGSEGV, Segmentation fault. 0x00007ffff739bf33 in x86DataCpuid (cpuid=0x8, cpuid=0x8, data=data@entry=0x7fffb800ee78) at cpu/cpu_x86.c:287 287 for (i = 0; i < data->len; i++) { (gdb) bt f0 0x00007ffff739bf33 in x86DataCpuid (cpuid=0x8, cpuid=0x8, data=data@entry=0x7fffb800ee78) at cpu/cpu_x86.c:287 f1 virCPUx86DataAddCPUID (data=data@entry=0x7fffb800ee78, cpuid=0x8) at cpu/cpu_x86.c:355 f2 0x00007ffff739ef47 in x86Compute (host=<optimized out>, cpu=0x7fffb8000cc0, guest=0x7fffecca7348, message=<optimized out>) at cpu/cpu_x86.c:1580 f3 0x00007fffd2b38e53 in qemuBuildCpuModelArgStr (migrating=false, hasHwVirt=<synthetic pointer>, qemuCaps=0x7fffb8001040, buf=0x7fffecca7360, def=0x7fffc400ce20, driver=0x1c) at qemu/qemu_command.c:6283 f4 qemuBuildCpuCommandLine (cmd=cmd@entry=0x7fffb8002f60, driver=driver@entry=0x7fffc80882c0, def=def@entry=0x7fffc400ce20, qemuCaps=qemuCaps@entry=0x7fffb8001040, migrating=<optimized out>) at qemu/qemu_command.c:6445 In frame 2, &host_model->vendor->cpuid is passed to virCPUx86DataAddCPUID(), but (gdb) p *host_model $23 = {name = 0x7fffb800ec50 "qemu64", vendor = 0x0, signature = 0, data = { len = 2, data = 0x7fffb800e720}} With vendor = 0x0, &host_model->vendor->cpuid evaluates to 8, which is not a nice value to pass to virCPUx86DataAddCPUID(). I've hacked around the problem by checking for a non-null host->vendor before calling virCPUx86DataAddCPUID, but I get the feeling it is just that - a hack. Comments on the attached patch, or suggestions for an alternate fix, are kindly welcomed :-). Regards, Jim

2 3

[libvirt] [PATCH 0/9] qemu: Reflect USB controller model in guest XML
by Andrea Bolognani 12 Aug '16

12 Aug '16

Patches 1-3 take care of some tiny nits; patches 4-7 clean up the test suite and add some new test cases that cover the code changed by subsequent patches. Patch 8 implements the feature advertised in the subject :) Patch 9 gets rid of some code that's no longer necessary after the changes. Andrea Bolognani (9): tests: qemuxml2argv: Remove useless GIC flags tests: qemuxml2argv: Fix usb-too-long-port-path-invalid tests: qemuxml2xml: Fix disk-mirror tests: qemuxml2xml: Use WHEN_BOTH for most tests tests: qemuxml2xml: Pass capabilities to DO_TEST() tests: qemuxml2xml: Use DO_TEST() for most tests tests: qemuxml2xml: Add some USB test cases qemu: domain: Reflect USB controller model in guest XML qemu: command: Simplify USB controller model selection src/qemu/qemu_command.c | 60 +- src/qemu/qemu_domain.c | 20 + tests/qemuxml2argvtest.c | 16 +- .../qemuxml2xmlout-ppc64-usb-controller-legacy.xml | 31 + .../qemuxml2xmlout-ppc64-usb-controller.xml | 31 + .../qemuxml2xmlout-usb-controller-default-q35.xml | 37 + .../qemuxml2xmlout-usb-controller-explicit-q35.xml | 37 + .../qemuxml2xmlout-usb-controller.xml | 27 + .../qemuxml2xmloutdata/qemuxml2xmlout-usb-none.xml | 25 + .../qemuxml2xmlout-usb-piix3-controller.xml | 27 + tests/qemuxml2xmltest.c | 932 ++++++++++----------- 11 files changed, 728 insertions(+), 515 deletions(-) create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-ppc64-usb-controller-legacy.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-ppc64-usb-controller.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-usb-controller-default-q35.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-usb-controller-explicit-q35.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-usb-controller.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-usb-none.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-usb-piix3-controller.xml -- 2.7.4

2 19

[libvirt] [PATCH 0/2] Couple of virschematest fixes
by Michal Privoznik 12 Aug '16

12 Aug '16

It's true that rewriting this into C made this test run faster. But maybe too much to my taste. Michal Privoznik (2): virschematest: Initialize @data virschematest: Make sure that validator is initialized tests/virschematest.c | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) -- 2.8.4

2 4

[libvirt] [PATCH v2] schema: Don't validate paths
by Michal Privoznik 12 Aug '16

12 Aug '16

https://bugzilla.redhat.com/show_bug.cgi?id=1353296 On UNIX like systems there are no constraints on what characters can be in file/dir names (except for NULL, obviously). Moreover, some values that we think of as paths (e.g. disk source) are not necessarily paths at all. For instance, some hypervisors take that as an arbitrary identifier and corresponding file is then looked up by hypervisor in its table. Instead of trying to fix our regular expressions (and forgetting to include yet another character there), lets drop the validation completely. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- diff to v1: - Instead of adding some more chars to whitelist, drop it 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..1b4f980 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">.+</param> </data> </define> <define name="dirPath"> <data type="string"> - <param name="pattern">[a-zA-Z0-9_\.\+\-\\&"'<>/%]+</param> + <param name="pattern">.+</param> </data> </define> <define name="absFilePath"> <data type="string"> - <param name="pattern">/[a-zA-Z0-9_\.\+\-\\&"'<>/%,:]+</param> + <param name="pattern">/.+</param> </data> </define> <define name="absDirPath"> <data type="string"> - <param name="pattern">/[a-zA-Z0-9_\.\+\-\\&"'<>/%]*</param> + <param name="pattern">/.*</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 1

[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

[libvirt] [PATCH v2] libxl: support serial list
by Bob Liu 11 Aug '16

11 Aug '16

Add support for multi serial devices, after this patch virsh can be used to connect different serial devices of running domains. E.g. vish # console <xxx> --devname serial<xxx> Note: This depends on a xen/libxl bug fix to have libxl_console_get_tty(...) correctly returning the tty path (as opposed to always returning the first one). [0] https://lists.xen.org/archives/html/xen-devel/2016-08/msg00438.html Signed-off-by: Bob Liu <bob.liu(a)oracle.com> --- v2: Add #ifdef LIBXL_HAVE_BUILDINFO_SERIAL_LIST --- src/libxl/libxl_conf.c | 24 +++++++++++++++++++++--- src/libxl/libxl_domain.c | 23 +++++++++++++++++++++++ src/libxl/libxl_driver.c | 17 +++++++++-------- 3 files changed, 53 insertions(+), 11 deletions(-) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index 146e08a..26c704d 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -431,14 +431,32 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, } if (def->nserials) { - if (def->nserials > 1) { + if (def->nserials == 1) { + if (libxlMakeChrdevStr(def->serials[0], &b_info->u.hvm.serial) < + 0) + return -1; + } else { +#ifdef LIBXL_HAVE_BUILDINFO_SERIAL_LIST + if (VIR_ALLOC_N(b_info->u.hvm.serial_list, def->nserials + 1) < + 0) + return -1; + + for (i = 0; i < def->nserials; i++) { + if (libxlMakeChrdevStr(def->serials[i], + &b_info->u.hvm.serial_list[i]) < 0) + { + libxl_string_list_dispose(&b_info->u.hvm.serial_list); + return -1; + } + } + b_info->u.hvm.serial_list[i] = NULL; +#else virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("Only one serial device is supported by libxl")); return -1; +#endif } - if (libxlMakeChrdevStr(def->serials[0], &b_info->u.hvm.serial) < 0) - return -1; } if (def->nparallels) { diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c index 0e26b91..5d8c9c1 100644 --- a/src/libxl/libxl_domain.c +++ b/src/libxl/libxl_domain.c @@ -989,6 +989,29 @@ libxlConsoleCallback(libxl_ctx *ctx, libxl_event *ev, void *for_callback) VIR_FREE(console); } } + for (i = 0; i < vm->def->nserials; i++) { + virDomainChrDefPtr chr = vm->def->serials[i]; + char *console = NULL; + int ret; + + ignore_value(virAsprintf(&chr->info.alias, "serial%zd", i)); + if (chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) { + if (chr->source.data.file.path) + continue; + ret = libxl_console_get_tty(ctx, ev->domid, + chr->target.port, + LIBXL_CONSOLE_TYPE_SERIAL, + &console); + if (!ret) { + VIR_FREE(chr->source.data.file.path); + if (console && console[0] != '\0') { + ignore_value(VIR_STRDUP(chr->source.data.file.path, + console)); + } + } + VIR_FREE(console); + } + } virObjectUnlock(vm); libxl_event_free(ctx, ev); } diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index f153f69..a34eb02 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -4450,13 +4450,6 @@ libxlDomainOpenConsole(virDomainPtr dom, virCheckFlags(VIR_DOMAIN_CONSOLE_FORCE, -1); - if (dev_name) { - /* XXX support device aliases in future */ - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", - _("Named device aliases are not supported")); - goto cleanup; - } - if (!(vm = libxlDomObjFromDomain(dom))) goto cleanup; @@ -4472,8 +4465,16 @@ libxlDomainOpenConsole(virDomainPtr dom, } priv = vm->privateData; + if (dev_name) { + size_t i; - if (vm->def->nconsoles) { + for (i = 0; !chr && i < vm->def->nserials; i++) { + if (STREQ(dev_name, vm->def->serials[i]->info.alias)) { + chr = vm->def->serials[i]; + break; + } + } + } else if (vm->def->nconsoles) { chr = vm->def->consoles[0]; if (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL) chr = vm->def->serials[0]; -- 2.6.5

2 1

[libvirt] [PATCH 0/2] libxl USB vendor/product support
by Cédric Bosdonnat 10 Aug '16

10 Aug '16

Hi all, Libxl API only allows providing bus/dev for USB hostdevs. If libvirt libxl driver users provide vendor/product they get an error, instead search for the corresponding bus/dev pair and feed them to libxl. Cédric Bosdonnat (2): Add virHostdevFindUSBDevice to private symbols libxl: allow vendor/product addressing for USB hostdevs src/libvirt_private.syms | 1 + src/libxl/libxl_conf.c | 25 +++++++++++++++++-------- src/util/virhostdev.c | 2 +- src/util/virhostdev.h | 6 ++++++ 4 files changed, 25 insertions(+), 9 deletions(-) -- 2.6.6

2 4

[libvirt] [PATCH jenkins-ci 00/19] Use jenkins-job-builder for CI
by Daniel P. Berrange 10 Aug '16

10 Aug '16

We are using the CentOS Jenkins server for running CI tasks. Currently those tasks are maintained by people manually updating the Jenkins web UI. This is a horrible interface that requires 100's of mouse clicks to achieve even the simplest things. It is also incredibly hard to compare the config of different jobs to make sure they are working in a consistent manner. Fortunately there are tools which can help - OpenStack created the jenkins-job-builder tool which uses the Jenkins REST API to create/update jobs from a simple YAML file definition. This series thus creates a set of YAML files which will (almost) replicate our current manually create config. I've used jenkins-job-builder in offline test mode to generate Jenkins XML files and then compared them to what we currently have and they are mostly the same. So there should not be too many suprises lurking, but I do still expect some accidental breakage in places. As such I have not actually uploaded the new auto-generated job configs to ci.centos.org at this time. The intention is that these configs will all live in the libvirt GIT server in a new 'libvirt-jenkins-ci' repository Daniel P. Berrange (19): jobs: add global default variables jobs: add a template for generic build process jobs: add a template for GNU autotools jobs: add a template for Python distutils jobs: add a template for Perl ExtUtils::MakeMaker jobs: add a template for Perl Module::Build projects: add the libvirt package projects: add the libvirt-python package projects: add the libvirt-perl package projects: add the libvirt-tck package projects: add the libvirt-glib package projects: add the libvirt-sandbox package projects: add the osinfo-db-tools package projects: add the osinfo-db package projects: add the libvirt-cim package projects: add the virt-viewer package projects: add the virt-manager package projects: add the libosinfo package Add README explaining how to use it README | 34 ++++++++ jobs/autotools.yaml | 198 ++++++++++++++++++++++++++++++++++++++++++ jobs/defaults.yaml | 11 +++ jobs/generic.yaml | 124 ++++++++++++++++++++++++++ jobs/perl-makemaker.yaml | 105 ++++++++++++++++++++++ jobs/perl-modulebuild.yaml | 104 ++++++++++++++++++++++ jobs/python-distutils.yaml | 99 +++++++++++++++++++++ projects/libosinfo.yaml | 20 +++++ projects/libvirt-cim.yaml | 24 +++++ projects/libvirt-glib.yaml | 20 +++++ projects/libvirt-perl.yaml | 18 ++++ projects/libvirt-python.yaml | 18 ++++ projects/libvirt-sandbox.yaml | 19 ++++ projects/libvirt-tck.yaml | 16 ++++ projects/libvirt.yaml | 44 ++++++++++ projects/osinfo-db-tools.yaml | 19 ++++ projects/osinfo-db.yaml | 24 +++++ projects/virt-manager.yaml | 19 ++++ projects/virt-viewer.yaml | 19 ++++ 19 files changed, 935 insertions(+) create mode 100644 README create mode 100644 jobs/autotools.yaml create mode 100644 jobs/defaults.yaml create mode 100644 jobs/generic.yaml create mode 100644 jobs/perl-makemaker.yaml create mode 100644 jobs/perl-modulebuild.yaml create mode 100644 jobs/python-distutils.yaml create mode 100644 projects/libosinfo.yaml create mode 100644 projects/libvirt-cim.yaml create mode 100644 projects/libvirt-glib.yaml create mode 100644 projects/libvirt-perl.yaml create mode 100644 projects/libvirt-python.yaml create mode 100644 projects/libvirt-sandbox.yaml create mode 100644 projects/libvirt-tck.yaml create mode 100644 projects/libvirt.yaml create mode 100644 projects/osinfo-db-tools.yaml create mode 100644 projects/osinfo-db.yaml create mode 100644 projects/virt-manager.yaml create mode 100644 projects/virt-viewer.yaml -- 2.7.4

3 38

[libvirt] [PATCH] qemu: fix qemu.conf security_driver
by Cole Robinson 10 Aug '16

10 Aug '16

Since a9331394 (first release v2.1.0), specifying a manual security_driver setting in qemu.conf causes the daemon to fail to start, erroring with 'Duplicate security driver X'. The duplicate checking was incorrectly comparing every entry against itself, guaranteeing a false positive. https://bugzilla.redhat.com/show_bug.cgi?id=1365607 --- src/qemu/qemu_conf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index b51f36f..7b971f1 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -436,7 +436,7 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr cfg, goto cleanup; for (i = 0; cfg->securityDriverNames && cfg->securityDriverNames[i] != NULL; i++) { - for (j = i; cfg->securityDriverNames[j] != NULL; j++) { + for (j = i + 1; cfg->securityDriverNames[j] != NULL; j++) { if (STREQ(cfg->securityDriverNames[i], cfg->securityDriverNames[j])) { virReportError(VIR_ERR_CONF_SYNTAX, -- 2.7.4

2 1