- Devel - libvirt List Archives

[libvirt] Entering freeze for 2.5.0
by Daniel Veillard 01 Dec '16

01 Dec '16

With exception of the patch set of Laine which we will likely push in today or tomorrow. I have made the signed tarball and rpms available at the usual place: ftp://libvirt.org/libvirt/ and also tagged the RC1 in git. This seems to work fine with my minimal testing, but obviously others should give it a try and try it in more diverse environments. If all goes well, I will push an rc2 on Thursday and plan the final release over the w.e. thanks for givit it a try, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 1

[libvirt] Plan for next release(s)
by Daniel Veillard 01 Dec '16

01 Dec '16

I'm late <grin/> so I think that if we don't want to slip too much the best would be to enter freeze tomorrow (Tuesday) then have RC2 around Thursday and a release over the week-end. That said they are supposed to mess with my internet tomorrow morning and I'm travelling till the end of the week, but the above plan should be doable. Hope that's okay with everybody. Then usually December is a low productivity month, and Feb is short, so it is tempting to do like for previous years i.e. release mid-january and end of Feb, except the Jan release will be 3.0.0. Works for everybody ? Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

4 5

[libvirt] [PATCH 0/8] Make NSS module lookup by libvirt domain names too
by Michal Privoznik 01 Dec '16

01 Dec '16

So far, the NSS module relies on guests providing hostnames during DHCP transaction, because if they do it's recorded in a json file that NSS module consults when doing the hostname translation. But there are few cases where this is not enough: some system (e.g. old RHEL6) don't provide hostname at all. If that's the case we can maintain a separate file $bridge.macs where we would keep a list of pairs <domain, mac address list>. Thus next time when doing hostname translation we can look up MAC address list for given domain, and then lookup the MAC <-> IP mapping in $bridge.status. It's a bit clunky, but it's our best shot. Michal Privoznik (8): network: Don't unlock non-locked network driver nssmock: Prefer free() over VIR_FREE() virstring: Introduce virStringListAdd virstring: Introduce virStringListRemove util: Introduce virFileRewriteStr util: Introduce virMACMap module network: Track MAC address map nss: Lookup by libvirt domain names too cfg.mk | 2 +- docs/nss.html.in | 13 +- po/POTFILES.in | 1 + src/Makefile.am | 9 + src/conf/network_conf.h | 4 + src/conf/virsecretobj.c | 20 +- src/libvirt_private.syms | 12 ++ src/network/bridge_driver.c | 95 ++++++++- src/network/leaseshelper.c | 14 +- src/util/virfile.c | 24 ++- src/util/virfile.h | 7 +- src/util/virmacmap.c | 399 +++++++++++++++++++++++++++++++++++ src/util/virmacmap.h | 48 +++++ src/util/virstring.c | 87 ++++++++ src/util/virstring.h | 6 + src/util/virxml.c | 4 +- tests/Makefile.am | 14 ++ tests/nssdata/virbr0.macs | 23 ++ tests/nssdata/virbr0.status | 5 + tests/nssdata/virbr1.macs | 21 ++ tests/nssdata/virbr1.status | 5 + tests/nssmock.c | 25 ++- tests/nsstest.c | 2 + tests/virmacmapmock.c | 29 +++ tests/virmacmaptest.c | 232 ++++++++++++++++++++ tests/virmacmaptestdata/complex.json | 45 ++++ tests/virmacmaptestdata/empty.json | 3 + tests/virmacmaptestdata/simple.json | 8 + tests/virmacmaptestdata/simple2.json | 16 ++ tests/virstringtest.c | 80 +++++++ tools/nss/libvirt_nss.c | 173 +++++++++++---- 31 files changed, 1340 insertions(+), 86 deletions(-) create mode 100644 src/util/virmacmap.c create mode 100644 src/util/virmacmap.h create mode 100644 tests/nssdata/virbr0.macs create mode 100644 tests/nssdata/virbr1.macs create mode 100644 tests/virmacmapmock.c create mode 100644 tests/virmacmaptest.c create mode 100644 tests/virmacmaptestdata/complex.json create mode 100644 tests/virmacmaptestdata/empty.json create mode 100644 tests/virmacmaptestdata/simple.json create mode 100644 tests/virmacmaptestdata/simple2.json -- 2.8.4

5 21

[libvirt] [PATCH] xen: Fix build when with xen disabled and libxl enabled
by Peter Krempa 01 Dec '16

01 Dec '16

xen_common.c does not get compiled in such case which breaks the build due to xenDomainDefAddImplicitInputDevice not being available. Move the function to a different place to resolve the issue. Caused by commit 36785c7e --- src/Makefile.am | 4 ++-- src/conf/domain_conf.c | 22 ++++++++++++++++++++++ src/conf/domain_conf.h | 3 +++ src/libxl/libxl_domain.c | 3 +-- src/xen/xen_driver.c | 2 +- src/xenapi/xenapi_driver.c | 3 +-- src/xenconfig/xen_common.c | 22 ---------------------- src/xenconfig/xen_common.h | 3 --- 8 files changed, 30 insertions(+), 32 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index d440548..eaf7b59 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1250,7 +1250,7 @@ libvirt_driver_xen_impl_la_CFLAGS = \ -I$(srcdir)/xenconfig \ $(AM_CFLAGS) libvirt_driver_xen_impl_la_LDFLAGS = $(AM_LDFLAGS) -libvirt_driver_xen_impl_la_LIBADD = $(XEN_LIBS) libvirt_xenconfig.la +libvirt_driver_xen_impl_la_LIBADD = $(XEN_LIBS) libvirt_driver_xen_impl_la_SOURCES = $(XEN_DRIVER_SOURCES) endif WITH_XEN @@ -1311,7 +1311,7 @@ if WITH_XENAPI noinst_LTLIBRARIES += libvirt_driver_xenapi.la libvirt_la_BUILT_LIBADD += libvirt_driver_xenapi.la libvirt_driver_xenapi_la_CFLAGS = $(LIBXENSERVER_CFLAGS) $(CURL_CFLAGS) \ - -I$(srcdir)/conf -I$(srcdir)/xenconfig $(AM_CFLAGS) + -I$(srcdir)/conf $(AM_CFLAGS) libvirt_driver_xenapi_la_LDFLAGS = $(AM_LDFLAGS) libvirt_driver_xenapi_la_LIBADD = $(LIBXENSERVER_LIBS) $(CURL_LIBS) libvirt_driver_xenapi_la_SOURCES = $(XENAPI_DRIVER_SOURCES) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index b001efc..64665fa 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -25786,3 +25786,25 @@ virDomainDefVcpuOrderClear(virDomainDefPtr def) for (i = 0; i < def->maxvcpus; i++) def->vcpus[i]->order = 0; } + + +int +virDomainDefXenAddImplicitInputDevice(virDomainDefPtr def) +{ + virDomainInputBus implicitInputBus = VIR_DOMAIN_INPUT_BUS_XEN; + + if (def->os.type == VIR_DOMAIN_OSTYPE_HVM) + implicitInputBus = VIR_DOMAIN_INPUT_BUS_PS2; + + if (virDomainDefMaybeAddInput(def, + VIR_DOMAIN_INPUT_TYPE_MOUSE, + implicitInputBus) < 0) + return -1; + + if (virDomainDefMaybeAddInput(def, + VIR_DOMAIN_INPUT_TYPE_KBD, + implicitInputBus) < 0) + return -1; + + return 0; +} diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 4447b03..00e833d 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -3211,4 +3211,7 @@ virDomainGetBlkioParametersAssignFromDef(virDomainDefPtr def, virTypedParameterPtr params, int *nparams, int maxparams); + +int virDomainDefXenAddImplicitInputDevice(virDomainDefPtr def); + #endif /* __DOMAIN_CONF_H */ diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c index 5cde576..557a408 100644 --- a/src/libxl/libxl_domain.c +++ b/src/libxl/libxl_domain.c @@ -37,7 +37,6 @@ #include "virstring.h" #include "virtime.h" #include "locking/domain_lock.h" -#include "xen_common.h" #include "network/bridge_driver.h" #define VIR_FROM_THIS VIR_FROM_LIBXL @@ -407,7 +406,7 @@ libxlDomainDefPostParse(virDomainDefPtr def, } /* add implicit input devices */ - if (xenDomainDefAddImplicitInputDevice(def) < 0) + if (virDomainDefXenAddImplicitInputDevice(def) < 0) return -1; return 0; diff --git a/src/xen/xen_driver.c b/src/xen/xen_driver.c index 3f9bfa7..55c3eb4 100644 --- a/src/xen/xen_driver.c +++ b/src/xen/xen_driver.c @@ -384,7 +384,7 @@ xenDomainDefPostParse(virDomainDefPtr def, } /* add implicit input device */ - if (xenDomainDefAddImplicitInputDevice(def) <0) + if (virDomainDefXenAddImplicitInputDevice(def) <0) return -1; return 0; diff --git a/src/xenapi/xenapi_driver.c b/src/xenapi/xenapi_driver.c index a9ed407..0949192 100644 --- a/src/xenapi/xenapi_driver.c +++ b/src/xenapi/xenapi_driver.c @@ -39,7 +39,6 @@ #include "xenapi_driver_private.h" #include "xenapi_utils.h" #include "virstring.h" -#include "xen_common.h" #define VIR_FROM_THIS VIR_FROM_XENAPI @@ -80,7 +79,7 @@ xenapiDomainDefPostParse(virDomainDefPtr def, void *parseOpaque ATTRIBUTE_UNUSED) { /* add implicit input device */ - if (xenDomainDefAddImplicitInputDevice(def) < 0) + if (virDomainDefXenAddImplicitInputDevice(def) < 0) return -1; return 0; diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c index 7968d40..b129f5e 100644 --- a/src/xenconfig/xen_common.c +++ b/src/xenconfig/xen_common.c @@ -1870,25 +1870,3 @@ xenFormatConfigCommon(virConfPtr conf, return 0; } - - -int -xenDomainDefAddImplicitInputDevice(virDomainDefPtr def) -{ - virDomainInputBus implicitInputBus = VIR_DOMAIN_INPUT_BUS_XEN; - - if (def->os.type == VIR_DOMAIN_OSTYPE_HVM) - implicitInputBus = VIR_DOMAIN_INPUT_BUS_PS2; - - if (virDomainDefMaybeAddInput(def, - VIR_DOMAIN_INPUT_TYPE_MOUSE, - implicitInputBus) < 0) - return -1; - - if (virDomainDefMaybeAddInput(def, - VIR_DOMAIN_INPUT_TYPE_KBD, - implicitInputBus) < 0) - return -1; - - return 0; -} diff --git a/src/xenconfig/xen_common.h b/src/xenconfig/xen_common.h index 9055692..de981ba 100644 --- a/src/xenconfig/xen_common.h +++ b/src/xenconfig/xen_common.h @@ -67,7 +67,4 @@ int xenFormatConfigCommon(virConfPtr conf, virConnectPtr conn, const char *nativeFormat); - -int xenDomainDefAddImplicitInputDevice(virDomainDefPtr def); - #endif /* __VIR_XEN_COMMON_H__ */ -- 2.10.1

2 2

[libvirt] [Question] vhost-user hotplug: multiqueue hotplug seems doesn't pass mq and vectors
by Gaohaifeng (A) 01 Dec '16

01 Dec '16

Hi ALL: Recently I review the vhost-user hotplug codes, when attach a vhost-user nic with multiqueue, it seems that it doesn't pass mq=on and vectors num to qemu. Is there any special consideration or just a small mistake? Parts of codes: qemuDomainAttachNetDevice(vhostfdSize is 0 when type is vhost-user) qemuBuildNicDevStr: if (usingVirtio && vhostfdSize > 1) { if (net->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW) { /* ccw provides a one to one relation of fds to queues and * does not support the vectors option */ virBufferAddLit(&buf, ",mq=on"); } else { /* As advised at http://www.linux-kvm.org/page/Multiqueue * we should add vectors=2*N+2 where N is the vhostfdSize */ virBufferAsprintf(&buf, ",mq=on,vectors=%zu", 2 * vhostfdSize + 2); } } Thanks. Haifeng Gao

2 4

[libvirt] [PATCH] qemu: Prevent detaching SCSI controller used by hostdev
by Eric Farman 01 Dec '16

01 Dec '16

Consider a guest started with the following XML snippet: <controller type='scsi' model='virtio-scsi' index='0'/> <hostdev mode='subsystem' type='scsi'> <source> <adapter name='scsi_host0'/> <address bus='0' target='8' unit='1074151456'/> </source> </hostdev> If we attach/create a virtio-scsi hostdev device but forget to include a virtio-scsi controller, one is silently created for us. (See qemuDomainFindOrCreateSCSIDiskController for context.) Detaching the hostdev, followed by the controller, works well and the guest behaves appropriately. If we detach the virtio-scsi controller device first, Libvirt silently detaches any associated hostdevs for us too. But all is not well, as the guest is unable to receive new virtio-scsi devices (the attach commands succeed, but devices never appear within the guest), nor even be shutdown, after this point. It appears that something is tied up in the host virtio layer. While I investigate this, we can see if a controller is being used by any hostdevs, and prevent the detach if it would lead us down this path. $ virsh detach-device guest_one_virtio_scsi scsicontroller.xml error: Failed to detach device from scsicontroller.xml error: operation failed: device cannot be detached: device is busy $ virsh detach-device guest_one_virtio_scsi scsidisk.xml Device detached successfully $ virsh detach-device guest_one_virtio_scsi scsicontroller.xml Device detached successfully Signed-off-by: Eric Farman <farman(a)linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk(a)linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com> --- src/qemu/qemu_hotplug.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index b03e618..5db7abf 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -4443,6 +4443,7 @@ static bool qemuDomainDiskControllerIsBusy(virDomainObjPtr vm, { size_t i; virDomainDiskDefPtr disk; + virDomainHostdevDefPtr hostdev; for (i = 0; i < vm->def->ndisks; i++) { disk = vm->def->disks[i]; @@ -4465,6 +4466,15 @@ static bool qemuDomainDiskControllerIsBusy(virDomainObjPtr vm, return true; } + for (i = 0; i < vm->def->nhostdevs; i++) { + hostdev = vm->def->hostdevs[i]; + if (!virHostdevIsSCSIDevice(hostdev) || + detach->type != VIR_DOMAIN_CONTROLLER_TYPE_SCSI) + continue; + if (hostdev->info->addr.drive.controller == detach->idx) + return true; + } + return false; } -- 2.8.4

2 5

[libvirt] [PATCH] loopback is not always just lo
by Pavel Timofeev 01 Dec '16

01 Dec '16

On BSD family OSes (Free/Net/Open/DragonFlyBSD, Mac OS) and Solaris loopback interface is called 'lo0' instead of just 'lo'. --- src/network/bridge_driver.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index a3ee3f3..9d94d65 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -1002,7 +1002,12 @@ networkDnsmasqConfContents(virNetworkObjPtr network, virBufferAsprintf(&configbuf, "pid-file=%s\n", pidfile); /* dnsmasq will *always* listen on localhost unless told otherwise */ +#ifdef __linux__ virBufferAddLit(&configbuf, "except-interface=lo\n"); +#else + /* BSD family OSes and Solaris call loopback interface as lo0 */ + virBufferAddLit(&configbuf, "except-interface=lo0\n"); +#endif if (dnsmasqCapsGet(caps, DNSMASQ_CAPS_BIND_DYNAMIC)) { /* using --bind-dynamic with only --interface (no -- 2.9.2

5 7

[libvirt] [PATCH v2] cgroup: Use system reported "unlimited" value for comparison
by Viktor Mihajlovski 01 Dec '16

01 Dec '16

With kernel 3.18 (since commit 3e32cb2e0a12b6915056ff04601cf1bb9b44f967) the "unlimited" value for cgroup memory limits has changed once again as its byte value is now computed from a page counter. The new "unlimited" value reported by the cgroup fs is therefore 2**51-1 pages which is (VIR_DOMAIN_MEMORY_PARAM_UNLIMITED - 3072). This results e.g. in virsh memtune displaying 9007199254740988 instead of unlimited for the limits. This patch uses the value of memory.limit_in_bytes from the cgroup memory root which is the system's "real" unlimited value for comparison. See also libvirt commit 231656bbeb9e4d3bedc44362784c35eee21cf0f4 for the history for kernel 3.12 and before. Signed-off-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com> --- v2: - removed RFC verbiage from commit message - per Martin's review comment, cache the cgroup memory.limit_in_bytes - used the cgroup detection logic proposed by Martin, much nicer now indeed - other than initially planned, fall back to VIR_DOMAIN_MEMORY_PARAM_UNLIMITED in case of cgroup read failure, since the usual paranoia fits in nicely with the "already initialized" check. With the current code structure this will never be called when the memory controller is not configured or mounted anyway... - while at it, replaced the goto cleanups with direct returns as there's really no cleanup to be done in the GetMemoryxxxLimit functions src/util/vircgroup.c | 67 ++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 49 insertions(+), 18 deletions(-) diff --git a/src/util/vircgroup.c b/src/util/vircgroup.c index f151193..76d9738 100644 --- a/src/util/vircgroup.c +++ b/src/util/vircgroup.c @@ -2452,6 +2452,46 @@ virCgroupGetBlkioDeviceWeight(virCgroupPtr group, } +/* + * Retrieve the "memory.limit_in_bytes" value from the memory controller + * root dir. This value cannot be modified by userspace and therefore + * is the maximum limit value supported by cgroups on the local system. + * Returns this value scaled to KB or falls back to the original + * VIR_DOMAIN_MEMORY_PARAM_UNLIMITED. Either way, remember the return + * value to avoid unnecessary cgroup filesystem access. + */ +static unsigned long long int virCgroupMemoryUnlimitedKB; + +static unsigned long long int +virCgroupGetMemoryUnlimitedKB(void) +{ + virCgroupPtr group; + unsigned long long int mem_unlimited; + + if (virCgroupMemoryUnlimitedKB) { + return virCgroupMemoryUnlimitedKB; + } else { + mem_unlimited = VIR_DOMAIN_MEMORY_PARAM_UNLIMITED << 10; + + if (virCgroupNew(-1, "/", NULL, -1, &group) < 0) + goto cleanup; + + if (!virCgroupHasController(group, VIR_CGROUP_CONTROLLER_MEMORY)) + goto cleanup; + + ignore_value(virCgroupGetValueU64(group, + VIR_CGROUP_CONTROLLER_MEMORY, + "memory.limit_in_bytes", + &mem_unlimited)); + } + + cleanup: + virCgroupFree(&group); + virCgroupMemoryUnlimitedKB = mem_unlimited >> 10; + return virCgroupMemoryUnlimitedKB; +} + + /** * virCgroupSetMemory: * @@ -2534,20 +2574,17 @@ int virCgroupGetMemoryHardLimit(virCgroupPtr group, unsigned long long *kb) { long long unsigned int limit_in_bytes; - int ret = -1; if (virCgroupGetValueU64(group, VIR_CGROUP_CONTROLLER_MEMORY, "memory.limit_in_bytes", &limit_in_bytes) < 0) - goto cleanup; + return -1; *kb = limit_in_bytes >> 10; - if (*kb > VIR_DOMAIN_MEMORY_PARAM_UNLIMITED) + if (*kb >= virCgroupGetMemoryUnlimitedKB()) *kb = VIR_DOMAIN_MEMORY_PARAM_UNLIMITED; - ret = 0; - cleanup: - return ret; + return 0; } @@ -2596,20 +2633,17 @@ int virCgroupGetMemorySoftLimit(virCgroupPtr group, unsigned long long *kb) { long long unsigned int limit_in_bytes; - int ret = -1; if (virCgroupGetValueU64(group, VIR_CGROUP_CONTROLLER_MEMORY, "memory.soft_limit_in_bytes", &limit_in_bytes) < 0) - goto cleanup; + return -1; *kb = limit_in_bytes >> 10; - if (*kb > VIR_DOMAIN_MEMORY_PARAM_UNLIMITED) + if (*kb >= virCgroupGetMemoryUnlimitedKB()) *kb = VIR_DOMAIN_MEMORY_PARAM_UNLIMITED; - ret = 0; - cleanup: - return ret; + return 0; } @@ -2658,20 +2692,17 @@ int virCgroupGetMemSwapHardLimit(virCgroupPtr group, unsigned long long *kb) { long long unsigned int limit_in_bytes; - int ret = -1; if (virCgroupGetValueU64(group, VIR_CGROUP_CONTROLLER_MEMORY, "memory.memsw.limit_in_bytes", &limit_in_bytes) < 0) - goto cleanup; + return -1; *kb = limit_in_bytes >> 10; - if (*kb > VIR_DOMAIN_MEMORY_PARAM_UNLIMITED) + if (*kb >= virCgroupGetMemoryUnlimitedKB()) *kb = VIR_DOMAIN_MEMORY_PARAM_UNLIMITED; - ret = 0; - cleanup: - return ret; + return 0; } -- 1.9.1

1 0

[libvirt] [PATCH 0/2] cpu: Add alternative feature spellings to CPU map
by Jiri Denemark 01 Dec '16

01 Dec '16

Jiri Denemark (2): cpu: Remove useless comments from CPU map cpu: Add alternative feature spellings to CPU map src/cpu/cpu_map.xml | 154 ++++++++++++++++++++++++++-------------------------- 1 file changed, 77 insertions(+), 77 deletions(-) -- 2.11.0.rc2

3 5

[libvirt] [PATCH v2 0/4] qemu: assign vfio devices to PCIe addresses when appropriate
by Laine Stump 01 Dec '16

01 Dec '16

Patches 1 and 4 were originally added to the end of the "more PCIe less legacy PCI" patchset in its final incarnation, but all the other patches were ACKed and pushed, while this needed a bit more work, resulting in this "faux V2" - although it's the 2nd time I've posted these patches, their "V1" was really inside the "V11666" of a larger series. In order to implement Alex's suggestion of checking the length of a PCI device's config file to determine if it's an Express device, I first made a utility function to return the length of a file, and then another to return the name of the config file of a virPCIDevice - those are the new patches 2 and 3. I'm open to suggestions about additional checks to put in virFileLength(), as long as they don't involve opening the file. For now I've kept it as simple as possible. (Just keep in mind that I'll be away from my keyboard from Wednesday through Sunday this week). Laine Stump (4): util: new function virFileLength() util: new function virPCIDeviceGetConfigPath() qemu: propagate virQEMUDriver object to qemuDomainDeviceCalculatePCIConnectFlags qemu: assign vfio devices to PCIe addresses when appropriate src/libvirt_private.syms | 2 + src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_domain_address.c | 117 ++++++++++++++++++++++++++++++++++++----- src/qemu/qemu_domain_address.h | 7 ++- src/qemu/qemu_hotplug.c | 19 +++---- src/qemu/qemu_process.c | 13 +++-- src/util/virfile.c | 13 +++++ src/util/virfile.h | 2 + src/util/virpci.c | 6 +++ src/util/virpci.h | 1 + tests/qemuhotplugtest.c | 4 +- 11 files changed, 157 insertions(+), 29 deletions(-) -- 2.9.3

3 16