May 2014 - Devel - libvirt List Archives

[libvirt] [PATCH v3] PCI: Introduce new device binding path using pci_dev.driver_override
by Alex Williamson 28 May '14

28 May '14

The driver_override field allows us to specify the driver for a device rather than relying on the driver to provide a positive match of the device. This shortcuts the existing process of looking up the vendor and device ID, adding them to the driver new_id, binding the device, then removing the ID, but it also provides a couple advantages. First, the above existing process allows the driver to bind to any device matching the new_id for the window where it's enabled. This is often not desired, such as the case of trying to bind a single device to a meta driver like pci-stub or vfio-pci. Using driver_override we can do this deterministically using: echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind echo 0000:03:00.0 > /sys/bus/pci/drivers_probe Previously we could not invoke drivers_probe after adding a device to new_id for a driver as we get non-deterministic behavior whether the driver we intend or the standard driver will claim the device. Now it becomes a deterministic process, only the driver matching driver_override will probe the device. To return the device to the standard driver, we simply clear the driver_override and reprobe the device: echo > /sys/bus/pci/devices/0000:03:00.0/driver_override echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind echo 0000:03:00.0 > /sys/bus/pci/drivers_probe Another advantage to this approach is that we can specify a driver override to force a specific binding or prevent any binding. For instance when an IOMMU group is exposed to userspace through VFIO we require that all devices within that group are owned by VFIO. However, devices can be hot-added into an IOMMU group, in which case we want to prevent the device from binding to any driver (override driver = "none") or perhaps have it automatically bind to vfio-pci. With driver_override it's a simple matter for this field to be set internally when the device is first discovered to prevent driver matches. Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- v3: kfree() override buffer on device release, noted by Alex Graf v2: Use strchr() as suggested by Guenter Roeck and adopted by the platform driver version of this same interface. Documentation/ABI/testing/sysfs-bus-pci | 21 ++++++++++++++++ drivers/pci/pci-driver.c | 25 +++++++++++++++++-- drivers/pci/pci-sysfs.c | 40 +++++++++++++++++++++++++++++++ drivers/pci/probe.c | 1 + include/linux/pci.h | 1 + 5 files changed, 85 insertions(+), 3 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index a3c5a66..898ddc4 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -250,3 +250,24 @@ Description: valid. For example, writing a 2 to this file when sriov_numvfs is not 0 and not 2 already will return an error. Writing a 10 when the value of sriov_totalvfs is 8 will return an error. + +What: /sys/bus/pci/devices/.../driver_override +Date: April 2014 +Contact: Alex Williamson <alex.williamson(a)redhat.com> +Description: + This file allows the driver for a device to be specified which + will override standard static and dynamic ID matching. When + specified, only a driver with a name matching the value written + to driver_override will have an opportunity to bind to the + device. The override is specified by writing a string to the + driver_override file (echo pci-stub > driver_override) and + may be cleared with an empty string (echo > driver_override). + This returns the device to standard matching rules binding. + Writing to driver_override does not automatically unbind the + device from its current driver or make any attempt to + automatically load the specified driver. If no driver with a + matching name is currently loaded in the kernel, the device + will not bind to any driver. This also allows devices to + opt-out of driver binding using a driver_override name such as + "none". Only a single driver may be specified in the override, + there is no support for parsing delimiters. diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index d911e0c..4393c12 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -216,6 +216,13 @@ const struct pci_device_id *pci_match_id(const struct pci_device_id *ids, return NULL; } +static const struct pci_device_id pci_device_id_any = { + .vendor = PCI_ANY_ID, + .device = PCI_ANY_ID, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, +}; + /** * pci_match_device - Tell if a PCI device structure has a matching PCI device id structure * @drv: the PCI driver to match against @@ -229,18 +236,30 @@ static const struct pci_device_id *pci_match_device(struct pci_driver *drv, struct pci_dev *dev) { struct pci_dynid *dynid; + const struct pci_device_id *found_id = NULL; + + /* When driver_override is set, only bind to the matching driver */ + if (dev->driver_override && strcmp(dev->driver_override, drv->name)) + return NULL; /* Look at the dynamic ids first, before the static ones */ spin_lock(&drv->dynids.lock); list_for_each_entry(dynid, &drv->dynids.list, node) { if (pci_match_one_device(&dynid->id, dev)) { - spin_unlock(&drv->dynids.lock); - return &dynid->id; + found_id = &dynid->id; + break; } } spin_unlock(&drv->dynids.lock); - return pci_match_id(drv->id_table, dev); + if (!found_id) + found_id = pci_match_id(drv->id_table, dev); + + /* driver_override will always match, send a dummy id */ + if (!found_id && dev->driver_override) + found_id = &pci_device_id_any; + + return found_id; } struct drv_dev_and_id { diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c index 4e0acef..faa4ab5 100644 --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -499,6 +499,45 @@ static struct device_attribute sriov_numvfs_attr = sriov_numvfs_show, sriov_numvfs_store); #endif /* CONFIG_PCI_IOV */ +static ssize_t driver_override_store(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t count) +{ + struct pci_dev *pdev = to_pci_dev(dev); + char *driver_override, *old = pdev->driver_override, *cp; + + if (count > PATH_MAX) + return -EINVAL; + + driver_override = kstrndup(buf, count, GFP_KERNEL); + if (!driver_override) + return -ENOMEM; + + cp = strchr(driver_override, '\n'); + if (cp) + *cp = '\0'; + + if (strlen(driver_override)) { + pdev->driver_override = driver_override; + } else { + kfree(driver_override); + pdev->driver_override = NULL; + } + + kfree(old); + + return count; +} + +static ssize_t driver_override_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct pci_dev *pdev = to_pci_dev(dev); + + return sprintf(buf, "%s\n", pdev->driver_override); +} +static DEVICE_ATTR_RW(driver_override); + static struct attribute *pci_dev_attrs[] = { &dev_attr_resource.attr, &dev_attr_vendor.attr, @@ -521,6 +560,7 @@ static struct attribute *pci_dev_attrs[] = { #if defined(CONFIG_PM_RUNTIME) && defined(CONFIG_ACPI) &dev_attr_d3cold_allowed.attr, #endif + &dev_attr_driver_override.attr, NULL, }; diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index ef09f5f..54268de 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1215,6 +1215,7 @@ static void pci_release_dev(struct device *dev) pci_release_of_node(pci_dev); pcibios_release_device(pci_dev); pci_bus_put(pci_dev->bus); + kfree(pci_dev->driver_override); kfree(pci_dev); } diff --git a/include/linux/pci.h b/include/linux/pci.h index aab57b4..b72af27 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -365,6 +365,7 @@ struct pci_dev { #endif phys_addr_t rom; /* Physical address of ROM if it's not from the BAR */ size_t romlen; /* Length of ROM if it's not from the BAR */ + char *driver_override; /* Driver name to force a match */ }; static inline struct pci_dev *pci_physfn(struct pci_dev *dev)

5 6

[libvirt] [PATCH v2] build: fix build with libselinux 2.3
by Cédric Bosdonnat 28 May '14

28 May '14

Several function signatures changed in libselinux 2.3, now taking a 'const char *' instead of 'security_context_t'. The latter is defined in selinux/selinux.h as typedef char *security_context_t; --- m4/virt-selinux.m4 | 18 ++++++++++++++++++ tests/securityselinuxhelper.c | 16 ++++++++++++++++ 2 files changed, 34 insertions(+) diff --git a/m4/virt-selinux.m4 b/m4/virt-selinux.m4 index 003c2a8..c299793 100644 --- a/m4/virt-selinux.m4 +++ b/m4/virt-selinux.m4 @@ -28,6 +28,24 @@ AC_DEFUN([LIBVIRT_CHECK_SELINUX],[ [with_selinux_mount=check]) if test "$with_selinux" = "yes"; then + AC_CACHE_CHECK([for selinux setcon parameter type], [gt_cv_setcon_param], + [AC_COMPILE_IFELSE( + [AC_LANG_PROGRAM( + [[ +#include <selinux/selinux.h> + +int setcon(const security_context_t context) { + return 0; +} + ]], + [[]])], + [gt_cv_setcon_param='security_context'], + [gt_cv_setcon_param='const char*'])]) + if test "$gt_cv_setcon_param" = 'const char*'; then + AC_DEFINE_UNQUOTED([SELINUX_CTX_CHAR_PTR], 1, + [SELinux uses char * for security context]) + fi + AC_MSG_CHECKING([SELinux mount point]) if test "$with_selinux_mount" = "check" || test -z "$with_selinux_mount"; then if test -d /sys/fs/selinux ; then diff --git a/tests/securityselinuxhelper.c b/tests/securityselinuxhelper.c index dbc4c29..af4fae4 100644 --- a/tests/securityselinuxhelper.c +++ b/tests/securityselinuxhelper.c @@ -156,7 +156,11 @@ int getpidcon(pid_t pid, security_context_t *context) return getpidcon_raw(pid, context); } +#ifdef SELINUX_CTX_CHAR_PTR +int setcon_raw(const char *context) +#else int setcon_raw(security_context_t context) +#endif { if (!is_selinux_enabled()) { errno = EINVAL; @@ -165,13 +169,21 @@ int setcon_raw(security_context_t context) return setenv("FAKE_SELINUX_CONTEXT", context, 1); } +#ifdef SELINUX_CTX_CHAR_PTR +int setcon(const char *context) +#else int setcon(security_context_t context) +#endif { return setcon_raw(context); } +#ifdef SELINUX_CTX_CHAR_PTR +int setfilecon_raw(const char *path, const char *con) +#else int setfilecon_raw(const char *path, security_context_t con) +#endif { const char *constr = con; if (STRPREFIX(path, abs_builddir "/securityselinuxlabeldata/nfs/")) { @@ -182,7 +194,11 @@ int setfilecon_raw(const char *path, security_context_t con) constr, strlen(constr), 0); } +#ifdef SELINUX_CTX_CHAR_PTR +int setfilecon(const char *path, const char *con) +#else int setfilecon(const char *path, security_context_t con) +#endif { return setfilecon_raw(path, con); } -- 1.8.4.5

3 4

[libvirt] [PATCH] Managed-Save: False warning on successful managed save restoration
by Jason J. Herne 28 May '14

28 May '14

From: "Jason J. Herne" <jjherne(a)us.ibm.com> qemuDomainObjStart is checking the return code from qemuDomainObjRestore for errors even after determining that the return code is 0. This causes the following error message to appear even when the restore was successful. Unable to restore from managed state [path]. Maybe the file is corrupted? A simple conditional to handle the error case takes care of the problem. Signed-off-by: Jason J. Herne <jjherne(a)us.ibm.com> --- src/qemu/qemu_driver.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2b852eb..cec2b6c 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -6081,14 +6081,15 @@ qemuDomainObjStart(virConnectPtr conn, else vm->hasManagedSave = false; } - - if (ret > 0) { - VIR_WARN("Ignoring incomplete managed state %s", managed_save); - } else { - VIR_WARN("Unable to restore from managed state %s. " - "Maybe the file is corrupted?", managed_save); - goto cleanup; + else { + if (ret > 0) { + VIR_WARN("Ignoring incomplete managed state %s", managed_save); + } else { + VIR_WARN("Unable to restore from managed state %s. " + "Maybe the file is corrupted?", managed_save); + } } + goto cleanup; } } -- 1.8.3.2

3 5

[libvirt] [PATCH] qemu: managedsave: Don't spam logs with warnings about corrupted image
by Peter Krempa 28 May '14

28 May '14

Even successful start of a VM from a managed save image would spam the logs with the following message: Unable to restore from managed state [path]. Maybe the file is corrupted? Re-arrange the logic to output the warning only when the image is corrupted. The flaw was introduced in commit cfc28c66. --- src/qemu/qemu_driver.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2b852eb..7a29b82 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -6080,14 +6080,14 @@ qemuDomainObjStart(virConnectPtr conn, VIR_WARN("Failed to remove the managed state %s", managed_save); else vm->hasManagedSave = false; - } - if (ret > 0) { - VIR_WARN("Ignoring incomplete managed state %s", managed_save); - } else { + goto cleanup; + } else if (ret < 0) { VIR_WARN("Unable to restore from managed state %s. " "Maybe the file is corrupted?", managed_save); goto cleanup; + } else { + VIR_WARN("Ignoring incomplete managed state %s", managed_save); } } } -- 1.9.3

2 2

[libvirt] [PATCH 0/3] Fix startup of gluster pools
by Peter Krempa 28 May '14

28 May '14

Currently a gluster pool fails to start due to an attempt to canonicalize a path residing on gluster storage. This series rearranges things to avoid that. Peter Krempa (3): storage: Return backing format from virStorageFileGetMetadataFromFD storage: fs: Drop-in replace use of virStorageFileGetMetadataFromBuf utils: storage: Canonicalize paths only for local filesystems src/qemu/qemu_driver.c | 2 +- src/storage/storage_backend_fs.c | 20 +++++++------------- src/util/virstoragefile.c | 27 +++++++++++++++------------ src/util/virstoragefile.h | 3 ++- 4 files changed, 25 insertions(+), 27 deletions(-) -- 1.9.3

2 7

[libvirt] [PATCH] qemu: reject rather than hang on blockcommit of active layer
by Eric Blake 28 May '14

28 May '14

qemu 2.0 added the ability to commit the active layer, but slightly differently than what libvirt had been anticipating in its implementation of the virDomainBlockCommit call. As a result, if you attempt to do a 'virsh blockcommit $dom vda', qemu gets into a state where it is waiting on libvirt to end the job, while libvirt is waiting on qemu to end the job, and the guest is effectively hung with regards to further commands for that block device. I have patches coming down the pipeline that will add full support for blockcommit of the active layer when coupled with qemu 2.0 or later; but they depend on Peter's improvements to block job handling and form enough of a new feature that they are not ready for inclusion in the 1.2.5 release. So for now, just reject the attempt, rather than letting the user get stuck. This is no worse than the behavior of qemu 1.7 rejecting the job. * src/qemu/qemu_driver.c (qemuDomainBlockCommit): Reject active commit. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- This patch should be committed before the 1.2.5 release, while I continue to polish my full series for active commit support for inclusion after the release. src/qemu/qemu_driver.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2b852eb..f008763 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -15461,6 +15461,15 @@ qemuDomainBlockCommit(virDomainPtr dom, &top_parent))) goto endjob; + /* FIXME: qemu 2.0 supports active commit, but as a two-stage + * process; qemu 2.1 is further improving active commit. We need + * to start support it in libvirt. */ + if (topSource == &disk->src) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("committing the active layer not supported yet")); + goto endjob; + } + if (!topSource->backingStore) { virReportError(VIR_ERR_INVALID_ARG, _("top '%s' in chain for '%s' has no backing file"), -- 1.9.3

2 2

[libvirt] xl and libvirt.
by Alvin Starr 28 May '14

28 May '14

I have been trying do some simulations of an openstack environment on my workstation that is running xen and libvirt. I managed to create nested HVM environments under lx but found a number of shortfalls in libxl code. I have added a nestedhvm as a domain feature and was looking at inspecting the domain configuration when I realized that the persistant data is keept in config files in /var/lib/xen/userdata..... Libvirt and lx have incompatible file names and are using different config formats. Libvirt keeps the data as XML and xl keeps them as xm config files. This means that libvirt domains cannot be manged with xl or xl domains managed by libvirt. Part of me thinks that sticking with the XL file format would be nice from the point of view of being able to use xenlight tools once the domain is configured. At the very least it may make sense to keep an XL copy of the config file in a format that xenlight can use. To achieve my original goal of managing a nested HVM environment from libvirt I need to get the CPUID flags working but I do believe that it would be nice to have the various xen and libvirt tools being able to talk to each other. Any pearls of wisdom would be greatly appreciated. -- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin(a)netvel.net ||

3 6

[libvirt] Call for agenda for weekly meeting May 29th, 2014
by Daniel P. Berrange 28 May '14

28 May '14

Hi Folks, Tomorrow (thursday) at 1400 UTC is set for our next weekly meeting on #virt-meeting of irc.oftc.net If you have any agenda items to raise please add them to: https://public.pad.fsfe.org/p/libvirt-community-meeting NB, I will likely be offline tomorrow at the Xen Community Hackathon, so if any agenda items are added, I'll trust that someone else here will chair the meeting the meeting instead.... Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

1 0

[libvirt] [PATCH 0/5] [RFC] Add support for per-guest-node binding
by Martin Kletzander 28 May '14

28 May '14

Currently we are only able to bind the whole domain to some host nodes using the /domain/numatune/memory element. Numerous requests were made to support host<->guest numa node bindings, so this series tries to pinch an idea on how to do that using /domain/numatune/memnode elements. So here are few ideas I'd like to know others opinions on: For some reason, qemu wants to know what host nodes it can use to for allocation of the memory. While adding support for that, qemu added various memory objects (-object memory*) with different backends. There's 'memory-file' which is used for hugepages and 'memory-ram' which is used for standard allocation. Latest version of the qemu proposal is here: http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg02706.html Caveats: - I'm not sure how cpu hotplug is done with guest numa nodes, but if there is a possibility to increase the number of numa nodes (which does not make sense to me from (a) user point of view and (b) our XMLs and APIs), we need to be able to hotplug the ram as well, - virDomainGetNumaParameters() now reflects only the /domain/numatune/memory settings, not 'memnode' ones, - virDomainSetNumaParameters() is not allowed when there is some /domain/numatune/memnode parameter as we can query memdev info, but not change it (if I understood the QEMU side correctly), - when domain is started, cpuset.mems cgroup is not modified per for each vcpu, this will be fixed, but the question is how to handle it for non-strict settings [*], - automatic numad placement can be now used together with memnode settings which IMHO doesn't make any sense, but I was hesitant to disable that in case somebody has a constructive criticism in this area. - This series alone is broken when used with /domain/memoryBacking/hugepages, because it will still use the memory-ram object, but that will be fixed with Michal's patches on top of this series. One idea how to solve some of the problems is to say that /domain/numatune/memory is set for the whole domain regardless of what anyone puts in /domain/numatune/memnode. virDomainGetNumaParameters() could be extended to tell the info for all guest numa nodes, although it seems new API would suit better for this kind of information. But is it really neede when we are not able to modify it live and the information is available in the domain XML? *) does (or should) this: ... <numatune> <memory mode='strict' placement='static' nodeset='0-7'/> <memnode nodeid='0' mode='preferred' nodeset='7'/> </numatune> ... mean what it looks like it means, that is "in guest node 0, prefer allocating from host node 7 but feel free to allocate from 0-6 as well in case you can't use 7, but never try allocating from host nodes 8-15"? Martin Kletzander (5): conf, schema: add 'id' field for cells conf, schema: add support for numatune memnode element qemu: purely a code movement qemu: numa capability probing qemu: pass numa node binding preferences to qemu docs/formatdomain.html.in | 29 +++- docs/schemas/domaincommon.rng | 22 +++ src/conf/cpu_conf.c | 39 ++++- src/conf/domain_conf.c | 181 +++++++++++++++++---- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 160 ++++++++++++++++-- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_domain.c | 23 ++- src/qemu/qemu_driver.c | 14 +- src/qemu/qemu_process.c | 3 +- src/util/virnuma.h | 14 +- tests/qemuxml2argvdata/qemuxml2argv-cpu-numa1.xml | 6 +- tests/qemuxml2argvdata/qemuxml2argv-cpu-numa2.xml | 6 +- tests/qemuxml2argvdata/qemuxml2argv-cpu-numa3.xml | 25 +++ .../qemuxml2argv-numatune-auto-prefer.args | 6 + .../qemuxml2argv-numatune-auto-prefer.xml | 29 ++++ .../qemuxml2argv-numatune-auto.args | 6 + .../qemuxml2argv-numatune-auto.xml | 26 +++ .../qemuxml2argv-numatune-memnode-nocpu.xml | 25 +++ .../qemuxml2argv-numatune-memnodes-problematic.xml | 31 ++++ .../qemuxml2argv-numatune-memnodes.args | 8 + .../qemuxml2argv-numatune-memnodes.xml | 31 ++++ .../qemuxml2argv-numatune-prefer.args | 6 + .../qemuxml2argv-numatune-prefer.xml | 29 ++++ tests/qemuxml2argvtest.c | 51 ++++-- .../qemuxml2xmlout-cpu-numa1.xml | 28 ++++ .../qemuxml2xmlout-cpu-numa2.xml | 28 ++++ tests/qemuxml2xmltest.c | 4 + tests/qemuxmlnstest.c | 2 +- 31 files changed, 747 insertions(+), 93 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-numa3.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-auto-prefer.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-auto-prefer.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-auto.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-auto.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnode-nocpu.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnodes-problematic.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnodes.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnodes.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-prefer.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-prefer.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-numa1.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-numa2.xml -- 1.9.3

2 10

[libvirt] [PATCH] doc: fix documentation of virDomainSet(Get)Metadata
by Dan Kenigsberg 28 May '14

28 May '14

The documentation of the functions should match the argument name in the actual function signature. Signed-off-by: Dan Kenigsberg <danken(a)redhat.com> --- src/libvirt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index 72a9f6d..f01b6dd 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -10109,14 +10109,14 @@ virDomainGetSecurityLabelList(virDomainPtr domain, /** * virDomainSetMetadata: * @domain: a domain object - * @type: type of description, from virDomainMetadataType + * @type: type of metadata, from virDomainMetadataType * @metadata: new metadata text * @key: XML namespace key, or NULL * @uri: XML namespace URI, or NULL * @flags: bitwise-OR of virDomainModificationImpact * * Sets the appropriate domain element given by @type to the - * value of @description. A @type of VIR_DOMAIN_METADATA_DESCRIPTION + * value of @metadata. A @type of VIR_DOMAIN_METADATA_DESCRIPTION * is free-form text; VIR_DOMAIN_METADATA_TITLE is free-form, but no * newlines are permitted, and should be short (although the length is * not enforced). For these two options @key and @uri are irrelevant and @@ -10202,7 +10202,7 @@ virDomainSetMetadata(virDomainPtr domain, /** * virDomainGetMetadata: * @domain: a domain object - * @type: type of description, from virDomainMetadataType + * @type: type of metadata, from virDomainMetadataType * @uri: XML namespace identifier * @flags: bitwise-OR of virDomainModificationImpact * -- 1.9.3

2 1