March 2014 - Devel - libvirt List Archives

[libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM
by Marcelo Tosatti 28 Apr '14

28 Apr '14

Add an element named "strict-hugepages" to control whether to refuse guest initialization in case hugepage allocation cannot be performed. Signed-off-by: Marcelo Tosatti <mtosatti(a)redhat.com> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index ff50214..e79f5e6 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -632,6 +632,9 @@ <dt><code>hugepages</code></dt> <dd>This tells the hypervisor that the guest should have its memory allocated using hugepages instead of the normal native page size.</dd> + <dt><code>strict-hugepages</code></dt> + <dd>This tells the hypervisor that the guest should refuse to start + in case of failure to allocate guest memory with hugepages</dd> <dt><code>nosharepages</code></dt> <dd>Instructs hypervisor to disable shared pages (memory merge, KSM) for this domain. <span class="since">Since 1.0.6</span></dd> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 28e24f9..f16ef0b 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -11226,6 +11226,9 @@ virDomainDefParseXML(xmlDocPtr xml, if (virXPathBoolean("boolean(./memoryBacking/locked)", ctxt)) def->mem.locked = true; + if ((node = virXPathNode("./memoryBacking/stricthugepages", ctxt))) + def->mem.strict_hugepages = true; + /* Extract blkio cgroup tunables */ if (virXPathUInt("string(./blkiotune/weight)", ctxt, &def->blkio.weight) < 0) diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index d8f2e49..8ea5cf0 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1977,6 +1977,7 @@ struct _virDomainDef { unsigned long long max_balloon; /* in kibibytes */ unsigned long long cur_balloon; /* in kibibytes */ bool hugepage_backed; + bool strict_hugepages; bool nosharepages; bool locked; int dump_core; /* enum virDomainMemDump */ diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 96b8825..3f8d0a4 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -12133,10 +12133,9 @@ cleanup: return def; } - -static int qemuParseProcFileStrings(int pid_value, - const char *name, - char ***list) +int qemuParseProcFileStrings(int pid_value, + const char *name, + char ***list) { char *path = NULL; int ret = -1; diff --git a/src/qemu/qemu_command.h b/src/qemu/qemu_command.h index de7683d..bcdfefa 100644 --- a/src/qemu/qemu_command.h +++ b/src/qemu/qemu_command.h @@ -226,7 +226,9 @@ virDomainDefPtr qemuParseCommandLinePid(virCapsPtr qemuCaps, char **pidfile, virDomainChrSourceDefPtr *monConfig, bool *monJSON); - +int qemuParseProcFileStrings(int pid_value, + const char *name, + char ***list); int qemuDomainAssignAddresses(virDomainDefPtr def, virQEMUCapsPtr qemuCaps, virDomainObjPtr obj) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 8bcd98e..cb8298e 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -25,6 +25,7 @@ #include <unistd.h> #include <signal.h> #include <sys/stat.h> +#include <stdlib.h> #if defined(__linux__) # include <linux/capability.h> #elif defined(__FreeBSD__) @@ -3507,6 +3508,95 @@ error: } +/* + * Returns bool: whether to fail guest initialization. + * + */ +static bool qemuValidateStrictHugepage(virDomainObjPtr vm, virQEMUDriverConfigPtr cfg) +{ + bool ret = false; + char **maps = NULL; + int i; + char *buf; + + if (!vm->def->mem.strict_hugepages) + return ret; + + ret = true; + + if (!vm->def->mem.hugepage_backed || !cfg->hugepagePath) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("strict huge pages depends on huge pages")); + return ret; + } + + buf = malloc(strlen(cfg->hugepagePath) + 50); + + /* The parser requires /proc/pid, which only exists on platforms + * like Linux where pid_t fits in int. */ + if ((int) vm->pid != vm->pid || + qemuParseProcFileStrings(vm->pid, "maps", &maps) < 0) + goto cleanup; + + for (i = 0; maps && maps[i]; i++) { + char *endptr; + unsigned long start, end; + const char *map = maps[i]; + bool found = false; + + sprintf(buf, "%s/qemu_back_mem.pc.ram.", cfg->hugepagePath); + if (strstr(map,buf) != NULL) + found = true; + + sprintf(buf, "%s/kvm.", cfg->hugepagePath); + if (strstr(map,buf) != NULL) + found = true; + + if (!found) + continue; + + errno = 0; + start = strtol(map, &endptr, 16); + if ((errno == ERANGE && (start == LONG_MAX || start == LONG_MIN)) + || (errno != 0 && start == 0)) { + continue; + } + + if (endptr && *endptr == '-') + endptr++; + + if (!*endptr) + continue; + + errno = 0; + end = strtol(endptr, NULL, 16); + if ((errno == ERANGE && (end == LONG_MAX || end == LONG_MIN)) + || (errno != 0 && end == 0)) { + continue; + } + + if (end-start >= vm->def->mem.max_balloon * 1024) { + ret = false; + break; + } + } + + if (ret) { + /* FIXME: is VIR_ERR_NO_MEMORY to be used exclusively + * to reference libvirt allocation failures? + */ + virReportError(VIR_ERR_NO_MEMORY, "%s", + _("guest memory not hugetlbfs backed")); + } + +cleanup: + for (i = 0; maps && maps[i]; i++) + VIR_FREE(maps[i]); + free(buf); + return ret; +} + + static bool qemuValidateCpuMax(virDomainDefPtr def, virQEMUCapsPtr qemuCaps) { @@ -4071,6 +4161,13 @@ int qemuProcessStart(virConnectPtr conn, goto cleanup; } + /* enforce strict hugepage */ + if (qemuValidateStrictHugepage(vm, cfg)) { + VIR_WARN("Failure to allocate hugepage backing for %s, exiting", + vm->def->name); + goto cleanup; + } + /* set default link states */ /* qemu doesn't support setting this on the command line, so * enter the monitor */

4 21

[libvirt] [PATCHv2 0/6] Utility functions for storing uninstalled location
by Nehal J Wani 24 Apr '14

24 Apr '14

When libvirtd is run from a build directory without being installed, it should not depend on files from a libvirt package installed in the system. Currently, APIs defined in src/ don't know whether libvirtd is being run from the build dir or the installed dir. The following additions provide the functionality to do so: virSetUninstalledDir virGetUninstalledDir Example usage (utility = lxc|iohelper): char *path_tmp = virGetUninstalledDir(); if (path_tmp) /* do stuff with ("%s/../../src/libvirt_<utility>", path_tmp) */ else /* do stuff with (LIBEXECDIR "/libvirt_<utility>") */ v1: Refer: https://www.redhat.com/archives/libvir-list/2014-March/msg01427.html Nehal J Wani (6): Add utility functions for storing uninstalled location Use virGetUninstalledDir() in src/util/virfile.c Use virGetUninstalledDir() in src/lxc/lxc_conf.c Use virGetUninstalledDir() in src/storage/storage_backend_disk.c Use virGetUninstalledDir() in src/fdstream.c Remove obsolete function virFDStreamSetIOHelper()

3 19

[libvirt] Fwd: Start contributing with Libvirt (Finding a mentor or helpful tips)
by Julio Faracco 22 Apr '14

22 Apr '14

Hi everybody! I sent an e-mail to Daniel asking about contributing to the libvirt community for free. So, I copied the e-mail to the libvirt mailing list as Daniel suggested me. If anyone can help me I'd be pleased. Thanks very much! *--* *Julio Cesar Faracco* *University of São Paulo - Brazil* ---------- Forwarded message ---------- From: Julio Faracco <jcfaracco(a)gmail.com> Date: 2014-03-29 13:45 GMT-03:00 Subject: Start contributing with Libvirt (Finding a mentor or helpful tips) To: dan(a)berrange.com Hi Daniel. My name is Julio and I sent this e-mail because I would like to contribute with libvirt. Moreover, I follow the libvirt mailing list for a long time and have read the ideas page of libvirt, qemu and KVM of Google Summer of Code program. I thought the ideas very interesting but I didn't have time to propose my ideais or submit a patch. But I don't know a good way to start doing that. I want to contribute with libvirt for free (not like GSoC who pays a paycheck for it). I think that contributing with a project like libvirt enhances some of my programming skills. Today I work with Linux distribution management and not with programing itself. However, I'm finding some troubles to start. For example: - Can I fix a random open bug? - How to understand which bug can be easier to solve? - How to follow the conversation of the mailing list? Sometimes I feel so lost. I was looking for a mentor (if you know someone who could help me) or a person who can help me to follow the right way to start it. Thanks very much. *--* *Julio Cesar Faracco* *University of São Paulo - Brazil*

3 6

[libvirt] libvirt-php: 0.4.8 tag is missing
by Doug Goldstein 21 Apr '14

21 Apr '14

The libvirt-php 0.4.8 tar is missing from the git repo [1]. Hopefully someone who created the tarball can create the tag as well and push it. [1] http://libvirt.org/git/?p=libvirt-php.git Thanks. -- Doug Goldstein

1 1

[libvirt] RFC: Exposing backing chains in <domain> XML
by Eric Blake 15 Apr '14

15 Apr '14

tl;dr: I am working on a series of patches to expose backing chain information in <domain> XML. Comments are welcome, to make sure my XML design is on the right track. Purpose ======= Among other things, this will help us support Peter's proposal of enhancing the block-pull and block-commit actions to specify a destination by relative depth in the backing chain (where "vda[0]" represents the active image, "vda[1]" represents the backing file of the active image, and so on). It will also help debug situations where libvirt and qemu disagree on what constitutes a backing chain, and therefore causes sVirt labeling discrepancies or prohibits block-pull/block-commit actions. For example, given the chain "base <- mid <- top", if top forgot the backing_fmt attribute, and /etc/libvirt/qemu.conf allow_disk_format_probing=0 (which it is by default for security resasons), libvirt treats 'mid' as a raw file and refuses to acknowledge that 'base' is part of the chain, while qemu would happily treat mid as qcow2 and therefore use 'base' if permissions allow it to. I have helped debug this scenario several times on IRC or in bugzilla reports. This feature is being driven in part by https://bugzilla.redhat.com/show_bug.cgi?id=1069407 Existing design =============== Note that libvirt can already expose backing file details (but only one layer; it is not recursive) when using virStorageVolGetXMLDesc(); for example: # virsh vol-dumpxml --pool gluster img3 <volume type='network'> <name>img3</name> <key>vol1/img3</key> ... <target> <path>gluster://localhost/vol1/img3</path> <format type='qcow2'/> ... </target> <backingStore> <path>gluster://localhost/vol1/img2</path> <format type='qcow2'/> <permissions> <mode>00</mode> <owner>0</owner> <group>0</group> </permissions> </backingStore> </volume> In the current volume representation, if a <backingStore> element is present, it gives the <path> to the backing file. But this representation is a bit limited: it is rather hard-coded to the assumption that there is only one backing file, and does not do a good job when the backing image is not in the same storage pool as the volume it is describing. Some of the enhancements I'm proposing for <domain> should also be applied to the information output by <volume> XML, which means I have to be careful that the design I'm proposing will mesh well with the storage xml to maximize code reuse. The volume approach is a bit painful to users trying to track the backing chain of a disk tied to a <domain> because it necessitates creating a storage pool and making multiple calls to follow the chain, so we need to expose the backing chain directly in the <disk> element of a domain, and recursively show the entire chain. Furthermore, there are some formats that require multiple resources: for example, both qemu 2.0's new quorum driver and HyperV VHDX images can have multiple backing files, and where these files can in turn have more backing images. Thus, any proper representation of disk resources needs to show a full tree of relationships. Thankfully, circular references in backing files would form an invalid image (all known virtual disk image formats require a DAG of relationships). With existing API, we still have not fully implemented 'virsh snapshot-delete' of external snapshots. So our current advice is for people to manually use qemu-img to alter backing chains, then update libvirt to match. Once libvirt starts tracking backing chains, it becomes all the more important to provide two new actions in libvirt: we need a validation mode (check that what is recorded on disk matches what is recorded in XML and flag an error if they differ) and a correction mode (ignore what is recorded in XML and regenerate it to match what is actually on disk). Proposal ======== For each <disk> of a domain, I will be adding a new <backingStore> element. The element is optional on input, which allows libvirt to continue to understand input from older versions, but will always be present on output, to show what libvirt is tracking as the backing chain. For a file with no backing store (including raw file format), the usage is simple: <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/path/to/somewhere'/> <backingStore/> <target dev='vda' bus='virtio'/> </disk> The new explicit <backingStore/> makes it clear that there is no backing chain. A backing chain of 3 files (base <- mid <- top) in the local file system: <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/top.qcow2'/> <backingStore type='file'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/mid.qcow2'/> <backingStore type='file'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/base.qcow2'/> <backingStore/> </backingStore> </backingStore> <target dev='vda' bus='virtio'/> </disk> Note that this is intentionally nested, so that for file formats that support more than one backing resource, it can list parallel <backingStore> as siblings to describe those related resources (thus leaving the door open to expose a qemu quorum as a <disk type='quorum'> with no direct <source> but instead with three <backingStore> sibling elements for each member of the quorum, and where each member of the quorum can further have its own backing chain). Design wise, the <backingStore> element is either completely empty (end-of-chain), or has a mandatory type='...' attribute that mirrors the same type attribute of a <disk>. Then, within the backingStore element, there is a <source> or other appropriate sub-elements similar to what <disk> already uses for describing a single host resource. So, for an example, here would be the output for a 2-element chain on gluster: <disk type='network' device='disk'> <driver name='qemu' type='qcow2'/> <source protocol='gluster' name='vol1/img2'> <host name='red'/> </source> <backingStore type='network'> <driver name='qemu' type='qcow2'/> <source protocol='gluster' name='vol1/img1'> <host name='red'/> </source> <backingStore/> </backingStore> <target dev='vdb' bus='virtio'/> </disk> Or again, but this time using volume references to a storage pool (assuming 'glusterVol1' is the storage pool wrapping gluster://red/vol1): <disk type='volume' device='disk'> <driver name='qemu' type='qcow2'/> <source pool='glusterVol1' volume='img2'/> <backingStore type='volume'> <driver name='qemu' type='qcow2'/> <source pool='glusterVol1' volume='img1'/> <backingStore/> </backingStore> <target dev='vdb' bus='virtio'/> </disk> As can be seen, this design heavily reuses existing <disk type='...'> handling, which should make it easier to reuse blocks of code both in libvirt to handle the backing chains, and in clients when processing backing chains to hand to libvirt up front or in inspecting the dumpxml results. Management apps like vdsm that use transient domains should start supplying <backingStore> elements to fully describe chains. Implementation ============== The following APIs will be affected: defining domain XML (whether via define for persistent domains, or create for transient domains): parse the new element. If the element is already present, default to trusting the backing chain in that element instead of reading from the disk files. If the element is absent, read the disk files and populate the element. It is probably also worth adding a flag to trigger validation mode: read the disk files to ensure they match the xml, and refuse the operation if there is a mismatch (as for updating xml to match reality, the simplest is to edit the XML and delete the <backingStore> element then try the define again, so I don't see the need for a flag for that action). I may also need to figure out if it is worth tainting a domain any time where libvirt detects that the XML backing chain vs. the disk file read backing chain have diverged. Note that defining domain XML includes loading from saved state or from incoming migration. dumping domain XML: always output the new element, by default without consulting disk files. By tracking the chain in memory ever since the guest is defined, it should already be available for output. I'm debating whether we need a flag (similar to virsh dumpxml --update-cpu) that can force libvirt to re-read the disk files at the time of the dump and regenerate the chain to match reality of any changes made behind libvirt's back. creating external snapshots: the <domainsnapshot> XMl will continue to be the picture of the domain prior to the creation of the snapshot (but this picture will now include any <backingStore> elements already present in the chain), but after the snapshot is taken, the <domain> XML will also be modified to record the updated chain (the old disk source is now the <backingStore> of the new disk source). deleting external snapshots is not yet implemented, but the implementation will have to shrink the backingStore chain to match reality. block-pull (block-rebase in pull mode), block-commit: at the completion of the pull, the <backingStore> needs to be updated to reflect the new shorter state of the chain block-copy (block-rebase in copy mode): the operation starts out by creating a mirror, but during the first phase, the mirror is not usable as an accurate copy of what the guest sees. Right now we fudge by saying that block copy can only be done on transient domains; but even with that, we still track a <mirror> element in the <disk> XML to track that a block copy is underway (so that the operation survives a libvirtd restart). The <mirror> element will now need to be taught a <backingStore>, particularly if the user passes in a pre-existing file to be reused as the copy destination. Then, when the second phase is complete and the mirroring is ended, the <disk> will need another update to select which side of the backing chain is now in force virsh domblklist: should be taught a new flag to show the backing chain in a tree format, since the command already exists to extract <disk> information from a domain into a nicer human format sVirt security labeling: right now, we are read the disk files to both label and remove labels on a backing chain - obviously, once the chain is tracked natively as part of the <disk>, we should be labeling without having to read disk files storage volumes - investigate how much of the backing chain code can be reused in enhancing storage volume xml output anything else you can think of in the code base that will be impacted? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

4 17

[libvirt] [PATCH] cpu: Properly check input parameters
by Jiri Denemark 11 Apr '14

11 Apr '14

Most of the APIs in CPU driver do not expect to get NULL for input parameters. Let's mark them with ATTRIBUTE_NONNULL and also check for some members of virCPUDef when the APIs expect them have some specific values. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/cpu/cpu.c | 48 +++++++++++++++++++++++++++++++++++++----------- src/cpu/cpu.h | 36 ++++++++++++++++++++++++------------ 2 files changed, 61 insertions(+), 23 deletions(-) diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c index 9cd2300..528e1a7 100644 --- a/src/cpu/cpu.c +++ b/src/cpu/cpu.c @@ -108,12 +108,6 @@ cpuCompareXML(virCPUDefPtr host, if (cpu == NULL) goto cleanup; - if (!cpu->model) { - virReportError(VIR_ERR_OPERATION_INVALID, - "%s", _("no CPU model specified")); - goto cleanup; - } - ret = cpuCompare(host, cpu); cleanup: @@ -146,6 +140,12 @@ cpuCompare(virCPUDefPtr host, VIR_DEBUG("host=%p, cpu=%p", host, cpu); + if (!cpu->model) { + virReportError(VIR_ERR_INVALID_ARG, "%s", + _("no guest CPU model specified")); + return VIR_CPU_COMPARE_ERROR; + } + if ((driver = cpuGetSubDriver(host->arch)) == NULL) return VIR_CPU_COMPARE_ERROR; @@ -203,14 +203,15 @@ cpuDecode(virCPUDefPtr cpu, } if (models == NULL && nmodels != 0) { - virReportError(VIR_ERR_INTERNAL_ERROR, - "%s", _("nonzero nmodels doesn't match with NULL models")); + virReportError(VIR_ERR_INVALID_ARG, "%s", + _("nonzero nmodels doesn't match with NULL models")); return -1; } - if (cpu == NULL) { - virReportError(VIR_ERR_INTERNAL_ERROR, - "%s", _("invalid CPU definition")); + if (cpu->type > VIR_CPU_TYPE_GUEST || + cpu->mode != VIR_CPU_MODE_CUSTOM) { + virReportError(VIR_ERR_INVALID_ARG, "%s", + _("invalid CPU definition stub")); return -1; } @@ -264,6 +265,12 @@ cpuEncode(virArch arch, virArchToString(arch), cpu, forced, required, optional, disabled, forbidden, vendor); + if (!cpu->model) { + virReportError(VIR_ERR_INVALID_ARG, "%s", + _("no guest CPU model specified")); + return -1; + } + if ((driver = cpuGetSubDriver(arch)) == NULL) return -1; @@ -367,6 +374,12 @@ cpuGuestData(virCPUDefPtr host, VIR_DEBUG("host=%p, guest=%p, data=%p, msg=%p", host, guest, data, msg); + if (!guest->model) { + virReportError(VIR_ERR_INVALID_ARG, "%s", + _("no guest CPU model specified")); + return VIR_CPU_COMPARE_ERROR; + } + if ((driver = cpuGetSubDriver(host->arch)) == NULL) return VIR_CPU_COMPARE_ERROR; @@ -529,6 +542,19 @@ cpuBaseline(virCPUDefPtr *cpus, return NULL; } + for (i = 0; i < ncpus; i++) { + if (!cpus[i]) { + virReportError(VIR_ERR_INVALID_ARG, + _("invalid CPU definition at index %zu"), i); + return NULL; + } + if (!cpus[i]->model) { + virReportError(VIR_ERR_INVALID_ARG, + _("no CPU model specified at index %zu"), i); + return NULL; + } + } + if (models == NULL && nmodels != 0) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nonzero nmodels doesn't match with NULL models")); diff --git a/src/cpu/cpu.h b/src/cpu/cpu.h index 27169fe..e9f2713 100644 --- a/src/cpu/cpu.h +++ b/src/cpu/cpu.h @@ -119,18 +119,21 @@ struct cpuArchDriver { extern virCPUCompareResult cpuCompareXML(virCPUDefPtr host, - const char *xml); + const char *xml) + ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2); extern virCPUCompareResult cpuCompare (virCPUDefPtr host, - virCPUDefPtr cpu); + virCPUDefPtr cpu) + ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2); extern int cpuDecode (virCPUDefPtr cpu, const virCPUData *data, const char **models, unsigned int nmodels, - const char *preferred); + const char *preferred) + ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2); extern int cpuEncode (virArch arch, @@ -140,7 +143,8 @@ cpuEncode (virArch arch, virCPUDataPtr *optional, virCPUDataPtr *disabled, virCPUDataPtr *forbidden, - virCPUDataPtr *vendor); + virCPUDataPtr *vendor) + ATTRIBUTE_NONNULL(2); extern void cpuDataFree (virCPUDataPtr data); @@ -152,7 +156,8 @@ extern virCPUCompareResult cpuGuestData(virCPUDefPtr host, virCPUDefPtr guest, virCPUDataPtr *data, - char **msg); + char **msg) + ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2); extern char * cpuBaselineXML(const char **xmlCPUs, @@ -166,30 +171,37 @@ cpuBaseline (virCPUDefPtr *cpus, unsigned int ncpus, const char **models, unsigned int nmodels, - unsigned int flags); + unsigned int flags) + ATTRIBUTE_NONNULL(1); extern int cpuUpdate (virCPUDefPtr guest, - const virCPUDef *host); + const virCPUDef *host) + ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2); extern int cpuHasFeature(const virCPUData *data, - const char *feature); + const char *feature) + ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2); bool cpuModelIsAllowed(const char *model, const char **models, - unsigned int nmodels); + unsigned int nmodels) + ATTRIBUTE_NONNULL(1); extern int -cpuGetModels(const char *arch, char ***models); +cpuGetModels(const char *arch, char ***models) + ATTRIBUTE_NONNULL(1); /* cpuDataFormat and cpuDataParse are implemented for unit tests only and * have no real-life usage */ -char *cpuDataFormat(const virCPUData *data); +char *cpuDataFormat(const virCPUData *data) + ATTRIBUTE_NONNULL(1); virCPUDataPtr cpuDataParse(virArch arch, - const char *xmlStr); + const char *xmlStr) + ATTRIBUTE_NONNULL(2); #endif /* __VIR_CPU_H__ */ -- 1.9.1

2 2

[libvirt] [PATCH] cpu: Add documentation for CPU driver APIs
by Jiri Denemark 11 Apr '14

11 Apr '14

Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/cpu/cpu.c | 202 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 202 insertions(+) diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c index e91f5bb..9cd2300 100644 --- a/src/cpu/cpu.c +++ b/src/cpu/cpu.c @@ -77,6 +77,19 @@ cpuGetSubDriver(virArch arch) } +/** + * cpuCompareXML: + * + * @host: host CPU definition + * @xml: XML description of either guest or host CPU to be compared with @host + * + * Compares the CPU described by @xml with @host CPU. + * + * Returns VIR_CPU_COMPARE_ERROR on error, VIR_CPU_COMPARE_INCOMPATIBLE when + * the two CPUs are incompatible, VIR_CPU_COMPARE_IDENTICAL when the two CPUs + * are identical, VIR_CPU_COMPARE_SUPERSET when the @xml CPU is a superset of + * the @host CPU. + */ virCPUCompareResult cpuCompareXML(virCPUDefPtr host, const char *xml) @@ -112,6 +125,19 @@ cpuCompareXML(virCPUDefPtr host, } +/** + * cpuCompare: + * + * @host: host CPU definition + * @cpu: either guest or host CPU to be compared with @host + * + * Compares the CPU described by @cpu with @host CPU. + * + * Returns VIR_CPU_COMPARE_ERROR on error, VIR_CPU_COMPARE_INCOMPATIBLE when + * the two CPUs are incompatible, VIR_CPU_COMPARE_IDENTICAL when the two CPUs + * are identical, VIR_CPU_COMPARE_SUPERSET when the @cpu CPU is a superset of + * the @host CPU. + */ virCPUCompareResult cpuCompare(virCPUDefPtr host, virCPUDefPtr cpu) @@ -134,6 +160,31 @@ cpuCompare(virCPUDefPtr host, } +/** + * cpuDecode: + * + * @cpu: CPU definition stub to be filled in + * @data: internal CPU data to be decoded into @cpu definition + * @models: list of CPU models that can be considered when decoding @data + * @nmodels: number of CPU models in @models + * @preferred: CPU models that should be used if possible + * + * Decodes internal CPU data into a CPU definition consisting of a CPU model + * and a list of CPU features. The @cpu model stub is supposed to have arch, + * type, match and fallback members set, this function will add the rest. If + * @models list is NULL, all models supported by libvirt will be considered + * when decoding the data. In general, this function will select the model + * closest to the CPU specified by @data unless @preferred is non-NULL, in + * which case the @preferred model will be used as long as it is compatible + * with @data. + * + * For VIR_ARCH_I686 and VIR_ARCH_X86_64 architectures this means the computed + * CPU definition will have the shortest possible list of additional features. + * When @preferred is non-NULL, the @preferred model will be used even if + * other models would result in a shorter list of additional features. + * + * Returns 0 on success, -1 on error. + */ int cpuDecode(virCPUDefPtr cpu, const virCPUData *data, @@ -177,6 +228,25 @@ cpuDecode(virCPUDefPtr cpu, } +/** + * cpuEncode: + * + * @arch: CPU architecture + * @cpu: CPU definition to be encoded into internal CPU driver representation + * @forced: where to store CPU data corresponding to forced features + * @required: where to store CPU data corresponding to required features + * @optional: where to store CPU data corresponding to optional features + * @disabled: where to store CPU data corresponding to disabled features + * @forbidden: where to store CPU data corresponding to forbidden features + * @vendor: where to store CPU data corresponding to CPU vendor + * + * Encode CPU definition from @cpu into internal CPU driver representation. + * Any of @forced, @required, @optional, @disabled, @forbidden and @vendor + * arguments can be NULL in case the caller is not interested in the + * corresponding data. + * + * Returns 0 on success, -1 on error. + */ int cpuEncode(virArch arch, const virCPUDef *cpu, @@ -209,6 +279,15 @@ cpuEncode(virArch arch, } +/** + * cpuDataFree: + * + * @data: CPU data structure to be freed + * + * Free internal CPU data. + * + * Returns nothing. + */ void cpuDataFree(virCPUDataPtr data) { @@ -233,6 +312,13 @@ cpuDataFree(virCPUDataPtr data) } +/** + * cpuNodeData: + * + * @arch: CPU architecture + * + * Returns CPU data for host CPU or NULL on error. + */ virCPUDataPtr cpuNodeData(virArch arch) { @@ -254,6 +340,23 @@ cpuNodeData(virArch arch) } +/** + * cpuGuestData: + * + * @host: host CPU definition + * @guest: guest CPU definition + * @data: computed guest CPU data + * @msg: error message describing why the @guest and @host CPUs are considered + * incompatible + * + * Computes guest CPU data for the @guest CPU definition when run on the @host + * CPU. + * + * Returns VIR_CPU_COMPARE_ERROR on error, VIR_CPU_COMPARE_INCOMPATIBLE when + * the two CPUs are incompatible (@msg will describe the incompatibility), + * VIR_CPU_COMPARE_IDENTICAL when the two CPUs are identical, + * VIR_CPU_COMPARE_SUPERSET when the @guest CPU is a superset of the @host CPU. + */ virCPUCompareResult cpuGuestData(virCPUDefPtr host, virCPUDefPtr guest, @@ -278,6 +381,27 @@ cpuGuestData(virCPUDefPtr host, } +/** + * cpuBaselineXML: + * + * @xmlCPUs: list of host CPU XML descriptions + * @ncpus: number of CPUs in @xmlCPUs + * @models: list of CPU models that can be considered for the baseline CPU + * @nmodels: number of CPU models in @models + * @flags: bitwise-OR of virConnectBaselineCPUFlags + * + * Computes the most feature-rich CPU which is compatible with all given + * host CPUs. If @models array is NULL, all models supported by libvirt will + * be considered when computing the baseline CPU model, otherwise the baseline + * CPU model will be one of the provided CPU @models. + * + * If @flags includes VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES then libvirt + * will explicitly list all CPU features that are part of the host CPU, + * without this flag features that are part of the CPU model will not be + * listed. + * + * Returns XML description of the baseline CPU or NULL on error. + */ char * cpuBaselineXML(const char **xmlCPUs, unsigned int ncpus, @@ -353,6 +477,27 @@ cpuBaselineXML(const char **xmlCPUs, } +/** + * cpuBaseline: + * + * @cpus: list of host CPU definitions + * @ncpus: number of CPUs in @cpus + * @models: list of CPU models that can be considered for the baseline CPU + * @nmodels: number of CPU models in @models + * @flags: bitwise-OR of virConnectBaselineCPUFlags + * + * Computes the most feature-rich CPU which is compatible with all given + * host CPUs. If @models array is NULL, all models supported by libvirt will + * be considered when computing the baseline CPU model, otherwise the baseline + * CPU model will be one of the provided CPU @models. + * + * If @flags includes VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES then libvirt + * will explicitly list all CPU features that are part of the host CPU, + * without this flag features that are part of the CPU model will not be + * listed. + * + * Returns baseline CPU definition or NULL on error. + */ virCPUDefPtr cpuBaseline(virCPUDefPtr *cpus, unsigned int ncpus, @@ -404,6 +549,20 @@ cpuBaseline(virCPUDefPtr *cpus, } +/** + * cpuUpdate: + * + * @guest: guest CPU definition + * @host: host CPU definition + * + * Updates @guest CPU definition according to @host CPU. This is required to + * support guest CPU definition which are relative to host CPU, such as CPUs + * with VIR_CPU_MODE_CUSTOM and optional features or VIR_CPU_MATCH_MINIMUM, or + * CPUs with non-custom mode (VIR_CPU_MODE_HOST_MODEL, + * VIR_CPU_MODE_HOST_PASSTHROUGH). + * + * Returns 0 on success, -1 on error. + */ int cpuUpdate(virCPUDefPtr guest, const virCPUDef *host) @@ -425,6 +584,18 @@ cpuUpdate(virCPUDefPtr guest, return driver->update(guest, host); } + +/** + * cpuHasFeature: + * + * @data: internal CPU representation + * @feature: feature to be checked for + * + * Checks whether @feature is supported by the CPU described by @data. + * + * Returns 1 if the feature is supported, 0 if it's not supported, or + * -1 on error. + */ int cpuHasFeature(const virCPUData *data, const char *feature) @@ -446,6 +617,16 @@ cpuHasFeature(const virCPUData *data, return driver->hasFeature(data, feature); } + +/** + * cpuDataFormat: + * + * @data: internal CPU representation + * + * Formats @data into XML for test purposes. + * + * Returns string representation of the XML describing @data or NULL on error. + */ char * cpuDataFormat(const virCPUData *data) { @@ -466,6 +647,17 @@ cpuDataFormat(const virCPUData *data) return driver->dataFormat(data); } + +/** + * cpuDataParse: + * + * @arch: CPU architecture + * @xmlStr: XML string produced by cpuDataFormat + * + * Parses XML representation of virCPUData structure for test purposes. + * + * Returns internal CPU data structure parsed from the XML or NULL on error. + */ virCPUDataPtr cpuDataParse(virArch arch, const char *xmlStr) @@ -541,6 +733,16 @@ cpuGetArchModels(const char *arch, struct cpuGetModelsData *data) } +/** + * cpuGetModels: + * + * @archName: CPU architecture string + * @models: where to store the list of supported models + * + * Fetches all CPU models supported by libvirt on @archName. + * + * Returns number of supported CPU models or -1 on error. + */ int cpuGetModels(const char *archName, char ***models) { -- 1.9.1

2 2

[libvirt] [PATCH 00/13] Add multiple trace backend function and add new ftrace backend for libvirt
by yangzy.fnst＠cn.fujitsu.com 10 Apr '14

10 Apr '14

From: Xinghai Yu <yuxinghai(a)cn.fujitsu.com> This patch set will let libvirt to support multiple trace backend function and add a new 'ftrace' backend at the same time. Then, libvirt would have 2 trace backend: dtrace, ftrace.They can be used alone or together. Patchs 1,2,3,4,5 are used for supporting multiple trace backend function. Patch 6 are used for adding ftrace as a new trace backend for libvirt. Patchs 7,8,9,10,11,12,13 add ftrace initial code in programs who use it. Thanks very much for Stefan Hajnoczi for I have used his scripts in patch 4 which commited in qemu. Thanks very much for Eiichi Tsukata for I have used his ftrace codes in patch 6 which commited in qemu. Backgroud: The existing trace mechanism in libvirt is dtrace. Although the dtrace can work, it's not work well enough. Every time we want get information from the trace point we must write a systemtap script and run it together with libvirt. That's really unpractical on some occasion, especially on production server since the systemtap script can't be executed automatically. And some problems may be not easy to reproduce, then it will cost a lot of time to get the trace information again. So I think it is essential to add supporting for record the trace information automatically in libvirt to satisfy the user's requirement. That's why I implemented multiple trace backend function and ftrace support in libvirt. Xinghai Yu (13): configure.ac: Define new macro 'WITH_TRACE_PROBES' to indicate trace function are available Makefile.am: Add new multiple trace backend supporting framework src: Use new tracepoint declaration files to replace the old dtrace declaration files to support multiple trace function src: Add scripts 'tracetool' to supporting the translation from tracepoint files to multiple trace backend supporting files daemon,src: Use new tracepoint function calls to replace old PROBE macro calls to support multiple trace function configure.ac, Makefile.am, src: Add new ftrace backend src/libvirt.c: Init ftrace backend in libvirt library so that programs containing it can use ftrace src/qemu/qemu_driver.c: Init ftrace backend in qemu driver so that qemu driver can support ftrace src/locking/lock_daemon.c: Init ftrace backend in program 'virtlockd' src/util/iohelper.c: Init ftrace backend in program 'libvirt_iohelper' src/storage/parthelper.c: Init ftrace backend in program 'libvirt_parthelper' src/lxc/lxc_controller.c: Init ftrace backend in program 'libvirt_lxc' src/security/virt-aa-helper.c: Init ftrace backend in program 'virt-aa-helper' config-post.h | 2 +- configure.ac | 24 ++++ daemon/Makefile.am | 13 +- daemon/remote.c | 77 +++++------ src/Makefile.am | 179 +++++++++++++++++++------ src/ftrace.c | 91 +++++++++++++ src/ftrace.h | 14 ++ src/internal.h | 69 +---------- src/libvirt.c | 9 ++ src/libvirt_probes.d | 82 ------------ src/libvirt_qemu_probes.d | 22 ---- src/libvirt_qemu_trace_events | 15 +++ src/libvirt_trace_events | 70 ++++++++++ src/locking/lock_daemon.c | 9 ++ src/lxc/lxc_controller.c | 9 ++ src/qemu/qemu_driver.c | 10 ++ src/qemu/qemu_monitor.c | 42 +++--- src/qemu/qemu_monitor_json.c | 12 +- src/qemu/qemu_monitor_text.c | 8 +- src/rpc/virkeepalive.c | 42 +++--- src/rpc/virnetclient.c | 43 +++--- src/rpc/virnetserverclient.c | 31 ++--- src/rpc/virnetsocket.c | 22 ++-- src/rpc/virnettlscontext.c | 42 +++--- src/security/virt-aa-helper.c | 9 ++ src/storage/parthelper.c | 9 ++ src/tracetool.py | 103 +++++++++++++++ src/tracetool/__init__.py | 268 ++++++++++++++++++++++++++++++++++++++ src/tracetool/backend/__init__.py | 120 +++++++++++++++++ src/tracetool/backend/trace.py | 112 ++++++++++++++++ src/tracetool/format/__init__.py | 103 +++++++++++++++ src/tracetool/format/c.py | 22 ++++ src/tracetool/format/d.py | 20 +++ src/tracetool/format/h.py | 22 ++++ src/util/iohelper.c | 9 ++ src/util/vireventpoll.c | 66 +++++----- src/util/virobject.c | 16 ++- tests/Makefile.am | 13 +- tools/virsh.c | 3 + 39 files changed, 1429 insertions(+), 401 deletions(-) create mode 100644 src/ftrace.c create mode 100644 src/ftrace.h delete mode 100644 src/libvirt_probes.d delete mode 100644 src/libvirt_qemu_probes.d create mode 100644 src/libvirt_qemu_trace_events create mode 100644 src/libvirt_trace_events create mode 100644 src/tracetool.py create mode 100644 src/tracetool/__init__.py create mode 100644 src/tracetool/backend/__init__.py create mode 100644 src/tracetool/backend/trace.py create mode 100644 src/tracetool/format/__init__.py create mode 100644 src/tracetool/format/c.py create mode 100644 src/tracetool/format/d.py create mode 100644 src/tracetool/format/h.py -- 1.8.3.1

4 20

[libvirt] [PATCH v1 0/2] Keep original file label
by Michal Privoznik 08 Apr '14

08 Apr '14

This creates a new file to store the original file labels. Or do we want the whole functionality to reside in virtlockd? Michal Privoznik (2): security_dac: Keep original file label security_dac: Lock label store file src/Makefile.am | 3 +- src/locking/lock_driver.h | 2 + src/locking/lock_driver_lockd.c | 25 +++ src/lxc/lxc_controller.c | 2 +- src/lxc/lxc_driver.c | 3 +- src/qemu/qemu_driver.c | 9 +- src/security/security_dac.c | 412 +++++++++++++++++++++++++++++++++++---- src/security/security_manager.c | 24 ++- src/security/security_manager.h | 7 +- tests/qemuhotplugtest.c | 2 +- tests/seclabeltest.c | 2 +- tests/securityselinuxlabeltest.c | 3 +- tests/securityselinuxtest.c | 2 +- 13 files changed, 438 insertions(+), 58 deletions(-) -- 1.9.0

1 4

[libvirt] [PATCH 0/3] bhyve: capabilities and CPU-capabilities support
by Wojciech Macek 06 Apr '14

06 Apr '14

Add following changes: - support for connectBaselineCPU (required by OpenStack) - move capabilites functions to separate file + API change - implement connectCompareCPU Wojciech Macek (3): bhyve: support for connectBaselineCPU bhyve: create capabilities submodule bhyve: connectCompareCPU support src/Makefile.am | 2 + src/bhyve/bhyve_capabilities.c | 105 ++++++++++++++++++++++++++++++++++++++++ src/bhyve/bhyve_capabilities.h | 30 ++++++++++++ src/bhyve/bhyve_driver.c | 107 ++++++++++++++++++++++++++++++++--------- 4 files changed, 222 insertions(+), 22 deletions(-) create mode 100644 src/bhyve/bhyve_capabilities.c create mode 100644 src/bhyve/bhyve_capabilities.h -- 1.9.0

3 7