- Devel - libvirt List Archives

[libvirt] [PATCH for-2.9 00/17] target-i386: Implement query-cpu-model-expansion
by Eduardo Habkost 13 Dec '16

13 Dec '16

This series implements query-cpu-model-expansion on target-i386. QAPI / interface changes ------------------------ When implementing this, I have noticed that the "host" CPU model in i386 includes some migration-unsafe features that can't be translated to any migration-safe representation: "pmu", and "host-cache-info". To be able to handle the migration-unsafe features, I have extended the query-cpu-model-expansion definition to be clear about what happens to those features when the CPU model is expanded (in short: static expansion removes them, full expansion keeps them). I also added "static" and "migration-safe" fields to the return value of query-cpu-model-expansion, so callers can know if the the expanded representation is static and migration-safe. Test code --------- I have added a Python test script for the feature, that will try multiple combinations of the expansion operation, and see if the returned data keeps matches some constratins. The test script works with the s390x query-cpu-model-expansion command, except that: 1) I couldn't test it with KVM; 2) qtest.py error handling when QEMU refuses to run is unreliable (so the script needs runnability information to be availble in TCG mode, too, to skip not-runnable CPU models and avoid problems). Future versions of the test script could run a arch-specific CPUID-dump guest binary, and validate data seen by the guest directly. While we don't do that, the script validates all QOM properties on the CPU objects looking for unexpected changes. At least in the case of x86, the QOM properties will include lots of the CPUID data seen by the guest, giving us decent coverage. Patches from other series ------------------------- This series includes patches from other series, just to help on the implementation of the test code: * "qmp: Report QOM type name on query-cpu-definitions", that was already submitted for 2.9 * qemu.py, qtest.py, and tests/Makefile.include changes --- Cc: Cornelia Huck <cornelia.huck(a)de.ibm.com> Cc: Christian Borntraeger <borntraeger(a)de.ibm.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: libvir-list(a)redhat.com Cc: Jiri Denemark <jdenemar(a)redhat.com> Cc: "Jason J. Herne" <jjherne(a)linux.vnet.ibm.com> Cc: Markus Armbruster <armbru(a)redhat.com> Cc: Richard Henderson <rth(a)twiddle.net> Cc: Igor Mammedov <imammedo(a)redhat.com> Cc: Eric Blake <eblake(a)redhat.com> Eduardo Habkost (17): qmp: Report QOM type name on query-cpu-definitions qemu.py: Make logging optional qtest.py: Support QTEST_LOG environment variable qtest.py: make logging optional qtest.py: Make 'binary' parameter optional tests: Add rules to non-gtester qtest test cases target-i386: Reorganize and document CPUID initialization steps target-i386: Support "-cpu host" on TCG too target-i386: Move "host" properties to base class target-i386: Allow short strings to be used as vendor ID target-i386: Remove AMD feature flag aliases from Opteron models target-i386: Return migration-safe field on query-cpu-definitions cpu: Support comma escaping when parsing -cpu qapi: add static/migration-safe info to query-cpu-model-expansion target-i386: Define static "base" CPU model tests: query-cpu-model-test.py test code target-i386: Implement query-cpu-model-expansion QMP command qapi-schema.json | 30 ++- scripts/qemu.py | 25 ++- scripts/qtest.py | 15 +- target-i386/cpu-qom.h | 8 +- tests/Makefile.include | 40 +++- tests/query-cpu-model-test.py | 421 ++++++++++++++++++++++++++++++++++++ tests/test-x86-cpuid-compat.c | 19 ++ monitor.c | 4 +- qom/cpu.c | 32 ++- target-arm/helper.c | 1 + target-i386/cpu.c | 481 +++++++++++++++++++++++++++++++----------- target-ppc/translate_init.c | 1 + target-s390x/cpu_models.c | 5 + 13 files changed, 928 insertions(+), 154 deletions(-) create mode 100755 tests/query-cpu-model-test.py -- 2.7.4

3 12

[libvirt] [PATCH] docs: Update formatstorage to match code for pool path
by John Ferlan 13 Dec '16

13 Dec '16

Seems commit id '0257d06b' forgot to include formatstorage when updating the docs to describe allowing zfs as a pool type and to furthermore note that the pool's target path element will be generated rather than read. Similarly commit id 'efab27afb' neglected to indicate that the target path for a logical pool will now be generated by libvirt. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- Pushed as trivial docs/formatstorage.html.in | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/formatstorage.html.in b/docs/formatstorage.html.in index f1be511..47c8b0c 100644 --- a/docs/formatstorage.html.in +++ b/docs/formatstorage.html.in @@ -380,8 +380,8 @@ <code>pool</code> element for some types of pools (pool types <code>dir</code>, <code>fs</code>, <code>netfs</code>, <code>logical</code>, <code>disk</code>, <code>iscsi</code>, - <code>scsi</code>, <code>mpath</code>). This tag is used to - describe the mapping of + <code>scsi</code>, <code>mpath</code>, <code>zfs</code>). + This tag is used to describe the mapping of the storage pool into the host filesystem. It can contain the following child elements: @@ -411,6 +411,8 @@ guaranteed stable across reboots, since they are allocated on demand. It is preferable to use a stable location such as one of the <code>/dev/disk/by-{path|id|uuid|label}</code> locations. + For <code>logical</code> and <code>zfs</code> pool types, a + provided value is ignored and a default path generated. For a Multipath pool (type <code>mpath</code>), the provided value is ignored and the default value of "/dev/mapper" is used. Since 0.4.1 -- 2.7.4

1 0

[libvirt] [PATCH python] HACKING: fix grammar
by Cole Robinson 13 Dec '16

13 Dec '16

From: Prabodh Agarwal <prabodh1194(a)users.noreply.github.com> --- Pushed as trivial. This was submitted on github, and since it's trivial I just pushed it, but I pointed the user at the hacking guidelines for future submissions https://github.com/libvirt/libvirt-python/pull/1#issuecomment-266807394 HACKING | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HACKING b/HACKING index 7a6e150..6eeb9e6 100644 --- a/HACKING +++ b/HACKING @@ -3,7 +3,7 @@ Most of the libvirt python binding code is automatically generated using the script generator.py, and the API description that the -libvirt library installs the location shown by pkg-config, with +libvirt library installs at the location shown by pkg-config, with this command: $ pkg-config --variable libvirt_api libvirt -- 2.9.3

1 0

[libvirt] [PATCH RFC] libxl: reverse defaults on HVM net device attach
by Joao Martins 13 Dec '16

13 Dec '16

libvirt libxl picks its own default with respect to the default NIC to use. libxlMakeNic is the one responsible for this and on boot it picks LIBXL_NIC_TYPE_VIF_IOEMU such that it accomodates both PV and emulated one. The good behaving guest at boot will then select the pv and unplug the emulated device. Now, on HVM when attaching an interface it will pick the same default that is LIBXL_NIC_TYPE_VIF_IOEMU which as a result will fail the attach (see xen commit 32e9d0f ("libxl: nic type defaults to vif in hotplug for hvm guest"). Xen doesn't yet support the hotplug of emulated devices, but we don't want to rule out that case either, which might get support in the future. Hence we simply reverse the defaults when we are attaching the interface which allows libvirt to prefer the PV nic first without adding "model='netfront'" following the same pattern as above commit. Also to avoid ruling out the emulated one we set to LIBXL_NIC_TYPE_IOEMU when setting a model type that is not 'netfront'. Signed-off-by: Joao Martins <joao.m.martins(a)oracle.com> --- This allows Openstack to attach network interfaces, which currently is broken on libxl if it doesn't set model 'netfront'. I am not sure whether this is the best way (hence RFC) or if users should really be setting the model='netfront' when attaching devices. But sounds to me that it would be better to have by default the supported, and if users want emulated attach to specify a nic model. Thoughts? --- src/libxl/libxl_conf.c | 9 ++++++--- src/libxl/libxl_conf.h | 3 ++- src/libxl/libxl_driver.c | 2 +- 3 files changed, 9 insertions(+), 5 deletions(-) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index dcf8e7e..50aa958 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -881,9 +881,10 @@ libxlMakeDiskList(virDomainDefPtr def, libxl_domain_config *d_config) int libxlMakeNic(virDomainDefPtr def, virDomainNetDefPtr l_nic, - libxl_device_nic *x_nic) + libxl_device_nic *x_nic, + bool attach) { - bool ioemu_nic = def->os.type == VIR_DOMAIN_OSTYPE_HVM; + bool ioemu_nic = def->os.type == VIR_DOMAIN_OSTYPE_HVM && !attach; virDomainNetType actual_type = virDomainNetGetActualType(l_nic); virNetworkPtr network = NULL; virConnectPtr conn = NULL; @@ -917,6 +918,8 @@ libxlMakeNic(virDomainDefPtr def, goto cleanup; if (STREQ(l_nic->model, "netfront")) x_nic->nictype = LIBXL_NIC_TYPE_VIF; + else + x_nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU; } if (VIR_STRDUP(x_nic->ifname, l_nic->ifname) < 0) @@ -1047,7 +1050,7 @@ libxlMakeNicList(virDomainDefPtr def, libxl_domain_config *d_config) if (virDomainNetGetActualType(l_nics[i]) == VIR_DOMAIN_NET_TYPE_HOSTDEV) continue; - if (libxlMakeNic(def, l_nics[i], &x_nics[nvnics])) + if (libxlMakeNic(def, l_nics[i], &x_nics[nvnics], false)) goto error; /* * The devid (at least right now) will not get initialized by diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h index 0ea76b4..851f3af 100644 --- a/src/libxl/libxl_conf.h +++ b/src/libxl/libxl_conf.h @@ -178,7 +178,8 @@ libxlMakeDisk(virDomainDiskDefPtr l_dev, libxl_device_disk *x_dev); int libxlMakeNic(virDomainDefPtr def, virDomainNetDefPtr l_nic, - libxl_device_nic *x_nic); + libxl_device_nic *x_nic, + bool attach); int libxlMakeVfb(virPortAllocatorPtr graphicsports, virDomainGraphicsDefPtr l_vfb, libxl_device_vfb *x_vfb); diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index b19b17e..7e5d9b6 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -3379,7 +3379,7 @@ libxlDomainAttachNetDevice(libxlDriverPrivatePtr driver, goto cleanup; } - if (libxlMakeNic(vm->def, net, &nic) < 0) + if (libxlMakeNic(vm->def, net, &nic, true) < 0) goto cleanup; if (libxl_device_nic_add(cfg->ctx, vm->def->id, &nic, 0)) { -- 2.1.4

2 4

[libvirt] [PATCH 0/3] network: Add support for local PTR domains
by Jiri Denemark 13 Dec '16

13 Dec '16

I run a system dnsmasq to be able to forward specific DNS requests to specific servers. And I have it configured for both forward and reverse lookups. Another dnsmasq is started for a virtual network with domain "virt". The system dnsmasq knows it needs to forward any requests for the "virt" domain and corresponding PTR domain to the dnsmasq started by libvirt. The problem is dnsmasq forwards queries for unknown names to the upstream name server (which is the system instance in my case). One can get nice endless loops of DNS requests pretty easily. Forward loops can be avoided by specifying localOnly='yes', but there was no way to avoid reverse lookup loops. And this is what I'm trying to address in the following patches. Jiri Denemark (3): conf: Make virNetworkIPDefParseXML a little bit saner util: Introduce virSocketAddrPTRDomain network: Add support for local PTR domains docs/formatnetwork.html.in | 37 ++++++-- src/conf/network_conf.c | 108 +++++++++++++++++++----- src/conf/network_conf.h | 4 + src/libvirt_private.syms | 1 + src/network/bridge_driver.c | 47 +++++++++++ src/util/virsocketaddr.c | 85 +++++++++++++++++++ src/util/virsocketaddr.h | 9 ++ tests/networkxml2confdata/ptr-domains-auto.conf | 20 +++++ tests/networkxml2confdata/ptr-domains-auto.xml | 21 +++++ tests/networkxml2confdata/ptr-domains.conf | 24 ++++++ tests/networkxml2confdata/ptr-domains.xml | 24 ++++++ tests/networkxml2conftest.c | 2 + 12 files changed, 353 insertions(+), 29 deletions(-) create mode 100644 tests/networkxml2confdata/ptr-domains-auto.conf create mode 100644 tests/networkxml2confdata/ptr-domains-auto.xml create mode 100644 tests/networkxml2confdata/ptr-domains.conf create mode 100644 tests/networkxml2confdata/ptr-domains.xml -- 2.11.0

1 4

[libvirt] [libvirt-ci][PATCH] Remove builders for Centos 6
by Michal Privoznik 13 Dec '16

13 Dec '16

These builds often fails with false positives due to ancient compiler found on this system. For instance it fails to see when symbol is used as a variable and when it is used as a function producing the following warnings: ../../src/qemu/qemu_monitor_text.c: In function 'parseMemoryStat': ../../src/qemu/qemu_monitor_text.c:604: error: declaration of 'stat' shadows a global declaration [-Wshadow] /usr/include/sys/stat.h:455: error: shadowed declaration is here [-Wshadow] Users trying to use libvirt from git on stable system are doomed to fix it themselves. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- projects/libvirt-cim.yaml | 1 - projects/libvirt-python.yaml | 1 - projects/libvirt.yaml | 3 --- 3 files changed, 5 deletions(-) diff --git a/projects/libvirt-cim.yaml b/projects/libvirt-cim.yaml index d1705af..dd40eb1 100644 --- a/projects/libvirt-cim.yaml +++ b/projects/libvirt-cim.yaml @@ -2,7 +2,6 @@ - project: name: libvirt-cim machines: - - libvirt-centos-6 - libvirt-centos-7 - libvirt-fedora-23 - libvirt-fedora-24 diff --git a/projects/libvirt-python.yaml b/projects/libvirt-python.yaml index baca308..adf22f4 100644 --- a/projects/libvirt-python.yaml +++ b/projects/libvirt-python.yaml @@ -2,7 +2,6 @@ - project: name: libvirt-python machines: - - libvirt-centos-6 - libvirt-centos-7 - libvirt-fedora-23 - libvirt-fedora-24 diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml index 20de27c..2b4e5d3 100644 --- a/projects/libvirt.yaml +++ b/projects/libvirt.yaml @@ -2,7 +2,6 @@ - project: name: libvirt machines: - - libvirt-centos-6 - libvirt-centos-7 - libvirt-fedora-23 - libvirt-fedora-24 @@ -13,7 +12,6 @@ - autotools-build-job: parent_jobs: machines: - - libvirt-centos-6 - libvirt-centos-7 - libvirt-debian - libvirt-fedora-23 @@ -23,7 +21,6 @@ - autotools-syntax-check-job: parent_jobs: 'libvirt-master-build' machines: - - libvirt-centos-6 - libvirt-centos-7 - libvirt-debian - libvirt-fedora-23 -- 2.11.0

2 3

[libvirt] [libvirt-perl][PATCH] Add PERF_PARAM_BRANCH_MISSES constant
by Michal Privoznik 13 Dec '16

13 Dec '16

Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Changes | 1 + Virt.xs | 1 + lib/Sys/Virt/Domain.pm | 7 +++++++ 3 files changed, 9 insertions(+) diff --git a/Changes b/Changes index b1248c9..ffb1911 100644 --- a/Changes +++ b/Changes @@ -4,6 +4,7 @@ Revision history for perl module Sys::Virt - Add group_name for block iotune - Add new branch instructions perf event + - Add PERF_PARAM_BRANCH_MISSES constant 2.5.0 2016-12-05 diff --git a/Virt.xs b/Virt.xs index b081793..65f4975 100644 --- a/Virt.xs +++ b/Virt.xs @@ -8302,6 +8302,7 @@ BOOT: REGISTER_CONSTANT_STR(VIR_PERF_PARAM_CPU_CYCLES, PERF_PARAM_CPU_CYCLES); REGISTER_CONSTANT_STR(VIR_PERF_PARAM_INSTRUCTIONS, PERF_PARAM_INSTRUCTIONS); REGISTER_CONSTANT_STR(VIR_PERF_PARAM_BRANCH_INSTRUCTIONS, PERF_PARAM_BRANCH_INSTRUCTIONS); + REGISTER_CONSTANT_STR(VIR_PERF_PARAM_BRANCH_MISSES, PERF_PARAM_BRANCH_MISSES); REGISTER_CONSTANT_STR(VIR_DOMAIN_BANDWIDTH_IN_AVERAGE, BANDWIDTH_IN_AVERAGE); REGISTER_CONSTANT_STR(VIR_DOMAIN_BANDWIDTH_IN_PEAK, BANDWIDTH_IN_PEAK); diff --git a/lib/Sys/Virt/Domain.pm b/lib/Sys/Virt/Domain.pm index faacc0a..3d9b106 100644 --- a/lib/Sys/Virt/Domain.pm +++ b/lib/Sys/Virt/Domain.pm @@ -2776,6 +2776,13 @@ the count of instructions by applications running on the platform. It corresponds to the "perf.branch_instructions" field in the *Stats APIs. +=item Sys::Virt::Domain::PERF_PARAM_BRANCH_MISSES + +The branch_misses perf event which can be used to measure the +count of branch misses by applications running on the platform. +It corresponds to the "perf.branch_misses" field in the *Stats +APIs. + =back =head2 VCPU FLAGS -- 2.11.0

2 1

[libvirt] [PATCH] formatnetwork: Cleanup /network/ip documentation
by Jiri Denemark 13 Dec '16

13 Dec '16

Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- docs/formatnetwork.html.in | 125 ++++++++++++++++++++++----------------------- 1 file changed, 60 insertions(+), 65 deletions(-) diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index cc7d7c7e7..9cf940052 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -968,49 +968,44 @@ </dd> <dt><code>ip</code></dt> <dd>The <code>address</code> attribute defines an IPv4 address in - dotted-decimal format, or an IPv6 address in standard - colon-separated hexadecimal format, that will be configured on - the bridge - device associated with the virtual network. To the guests this IPv4 - address will be their IPv4 default route. For IPv6, the default route is - established via Router Advertisement. - For IPv4 addresses, the <code>netmask</code> - attribute defines the significant bits of the network address, - again specified in dotted-decimal format. For IPv6 addresses, - and as an alternate method for IPv4 addresses, you can specify - the significant bits of the network address with the <code>prefix</code> - attribute, which is an integer (for example, <code>netmask='255.255.255.0'</code> - could also be given as <code>prefix='24'</code>. The <code>family</code> - attribute is used to specify the type of address - 'ipv4' or 'ipv6'; if no - <code>family</code> is given, 'ipv4' is assumed. A network can have more than - one of each family of address defined, but only a single IPv4 address can have a - <code>dhcp</code> or <code>tftp</code> element. Since 0.3.0 - IPv6, multiple addresses on a single network, <code>family</code>, and - <code>prefix</code> are support Since 0.8.7. - Similar to IPv4, one IPv6 address per network can also have - a <code>dhcp</code> definition. Since 1.0.1 + dotted-decimal format, or an IPv6 address in standard colon-separated + hexadecimal format, that will be configured on the bridge device + associated with the virtual network. To the guests this IPv4 address + will be their IPv4 default route. For IPv6, the default route is + established via Router Advertisement. For IPv4 addresses, the + <code>netmask</code> attribute defines the significant bits of the + network address, again specified in dotted-decimal format. For IPv6 + addresses, and as an alternate method for IPv4 addresses, the + significant bits of the network address can be specified with the + <code>prefix</code> attribute, which is an integer (for example, + <code>netmask='255.255.255.0'</code> could also be given as + <code>prefix='24'</code>). The <code>family</code> attribute is used + to specify the type of address — <code>ipv4</code> or + <code>ipv6</code>; if no <code>family</code> is given, + <code>ipv4</code> is assumed. More than one address of each family can + be defined for a network. The <code>ip</code> element is supported + since 0.3.0. IPv6, multiple addresses on a + single network, <code>family</code>, and <code>prefix</code> are + supported since 0.8.7. The <code>ip</code> + element may contain the following elements: <dl> <dt><code>tftp</code></dt> - <dd>Immediately within - the <code>ip</code> element there is an optional <code>tftp</code> - element. The presence of this element and of its attribute - <code>root</code> enables TFTP services. The attribute specifies - the path to the root directory served via TFTP. <code>tftp</code> is not - supported for IPv6 addresses, and can only be specified on a single IPv4 address - per network. + <dd>The optional <code>tftp</code> element and its mandatory + <code>root</code> attribute enable TFTP services. The attribute + specifies the path to the root directory served via TFTP. The + <code>tftp</code> element is not supported for IPv6 addresses, + and can only be specified on a single IPv4 address per network. Since 0.7.1 </dd> <dt><code>dhcp</code></dt> - <dd>Also within the <code>ip</code> element there is an - optional <code>dhcp</code> element. The presence of this element - enables DHCP services on the virtual network. It will further - contain one or more <code>range</code> elements. The - <code>dhcp</code> element supported for both - IPv4 Since 0.3.0 - and IPv6 Since 1.0.1, but - only for one IP address of each type per network. + <dd>The presence of this element enables DHCP services on the + virtual network. The <code>dhcp</code> element is supported for + both IPv4 (since 0.3.0) and IPv6 + (since 1.0.1), but only for one IP + address of each type per network. The following sub-elements are + supported: <dl> <dt><code>range</code></dt> <dd>The <code>start</code> and <code>end</code> attributes on the @@ -1020,39 +1015,39 @@ <code>ip</code> element. There may be zero or more <code>range</code> elements specified. Since 0.3.0 - <code>range</code> can be specified for one IPv4 address, - one IPv6 address, or both. Since 1.0.1 </dd> <dt><code>host</code></dt> - <dd>Within the <code>dhcp</code> element there may be zero or more - <code>host</code> elements. These specify hosts which will be given - names and predefined IP addresses by the built-in DHCP server. Any - IPv4 <code>host</code> element must specify the MAC address of the host to be assigned - a given name (via the <code>mac</code> attribute), the IP to be - assigned to that host (via the <code>ip</code> attribute), and the - name to be given that host by the DHCP server (via the - <code>name</code> attribute). Since 0.4.5 - An IPv6 <code>host</code> element differs slightly from that for IPv4: - there is no <code>mac</code> attribute since a MAC address has no - defined meaning in IPv6. Instead, the <code>name</code> attribute is - used to identify the host to be assigned the IPv6 address. For DHCPv6, - the name is the plain name of the client host sent by the - client to the server. Note that this method of assigning a - specific IP address can also be used instead of the <code>mac</code> - attribute for IPv4. Since 1.0.1 + <dd>Within the <code>dhcp</code> element there may be zero or + more <code>host</code> elements. These specify hosts which will + be given names and predefined IP addresses by the built-in DHCP + server. Any IPv4 <code>host</code> element must specify the MAC + address of the host to be assigned a given name (via the + <code>mac</code> attribute), the IP to be assigned to that host + (via the <code>ip</code> attribute), and the name itself (the + <code>name</code> attribute). The IPv6 <code>host</code> + element differs slightly from that for IPv4: there is no + <code>mac</code> attribute since a MAC address has no defined + meaning in IPv6. Instead, the <code>name</code> attribute is + used to identify the host to be assigned the IPv6 address. For + DHCPv6, the name is the plain name of the client host sent by the + client to the server. Note that this method of assigning a + specific IP address can also be used for IPv4 instead of the + <code>mac</code> attribute. + Since 0.4.5 </dd> <dt><code>bootp</code></dt> - <dd>The optional <code>bootp</code> - element specifies BOOTP options to be provided by the DHCP - server for IPv4 only. - Two attributes are supported: <code>file</code> is mandatory and - gives the file to be used for the boot image; <code>server</code> is - optional and gives the address of the TFTP server from which the boot - image will be fetched. <code>server</code> defaults to the same host - that runs the DHCP server, as is the case when the <code>tftp</code> - element is used. The BOOTP options currently have to be the same - for all address ranges and statically assigned addresses.Since 0.7.1 (<code>server</code> since 0.7.3). + <dd>The optional <code>bootp</code> element specifies BOOTP + options to be provided by the DHCP server for IPv4 only. Two + attributes are supported: <code>file</code> is mandatory and + gives the file to be used for the boot image; + <code>server</code> is optional and gives the address of the + TFTP server from which the boot image will be fetched. + <code>server</code> defaults to the same host that runs the + DHCP server, as is the case when the <code>tftp</code> element + is used. The BOOTP options currently have to be the same for + all address ranges and statically assigned addresses. Since 0.7.1 (<code>server</code> + since 0.7.3) </dd> </dl> </dd> -- 2.11.0

2 1

[libvirt] [PATCH v2 0/3] qemu: fix racy paths in agent related code
by Nikolay Shirokovskiy 13 Dec '16

13 Dec '16

Changes from v1: 1. patch 2: make vm def copy instead of making qemuAgentGetFSInfo independent of domain conf. 2. patch 3: provide more relevant commit message Nikolay Shirokovskiy (3): qemu: agent: fix uninitialized var case in qemuAgentGetFSInfo qemu: don't use vm when lock is dropped in qemuDomainGetFSInfo qemu: agent: take monitor lock in qemuAgentNotifyEvent src/qemu/qemu_agent.c | 5 +++++ src/qemu/qemu_driver.c | 12 +++++++++++- 2 files changed, 16 insertions(+), 1 deletion(-) -- 1.8.3.1

2 5

[libvirt] [PATCH] perf: add branch_misses perf event support
by Nitesh Konkar 13 Dec '16

13 Dec '16

This patch adds support and documentation for the branch_misses perf event. Signed-off-by: Nitesh Konkar <nitkon12(a)linux.vnet.ibm.com> --- docs/formatdomain.html.in | 6 ++++++ docs/schemas/domaincommon.rng | 1 + include/libvirt/libvirt-domain.h | 10 ++++++++++ src/libvirt-domain.c | 4 ++++ src/qemu/qemu_driver.c | 1 + src/util/virperf.c | 5 ++++- src/util/virperf.h | 1 + tests/genericxml2xmlindata/generic-perf.xml | 1 + tools/virsh.pod | 5 ++++- 9 files changed, 32 insertions(+), 2 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 9218eec..086af55 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1928,6 +1928,7 @@ <event name='cache_references' enabled='no'/> <event name='cache_misses' enabled='no'/> <event name='branch_instructions' enabled='no'/> + <event name='branch_misses' enabled='no'/> </perf> ... </pre> @@ -1978,6 +1979,11 @@ <td>the count of branch instructions by applications running on the platform</td> <td><code>perf.branch_instructions</code></td> </tr> + <tr> + <td><code>branch_misses</code></td> + <td>the count of branch misses by applications running on the platform</td> + <td><code>perf.branch_misses</code></td> + </tr> </table> <h3><a name="elementsDevices">Devices</a></h3> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index c004233..bf8818d 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -428,6 +428,7 @@ <value>cache_references</value> <value>cache_misses</value> <value>branch_instructions</value> + <value>branch_misses</value> </choice> </attribute> <attribute name="enabled"> diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h index f43c976..3290b10 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -2135,6 +2135,16 @@ void virDomainStatsRecordListFree(virDomainStatsRecordPtr *stats); */ # define VIR_PERF_PARAM_BRANCH_INSTRUCTIONS "branch_instructions" +/** + * VIR_PERF_PARAM_BRANCH_MISSES: + * + * Macro for typed parameter name that represents branch_misses + * perf event which can be used to measure the count of branch misses + * by applications running on the platform. It corresponds to the + * "perf.branch_misses" field in the *Stats APIs. + */ +# define VIR_PERF_PARAM_BRANCH_MISSES "branch_misses" + int virDomainGetPerfEvents(virDomainPtr dom, virTypedParameterPtr *params, int *nparams, diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index 6481abf..a91f432 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -11229,6 +11229,10 @@ virConnectGetDomainCapabilities(virConnectPtr conn, * "perf.branch_instructions" - The count of branch instructions as * unsigned long long. It is produced by * branch_instructions perf event. + * "perf.branch_misses" - The count of branch misses as + * unsigned long long. It is produced by + * branch_misses perf event. + * * * Note that entire stats groups or individual stat fields may be missing from * the output in case they are not supported by the given hypervisor, are not diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 842de0a..0f3a283 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -9853,6 +9853,7 @@ qemuDomainSetPerfEvents(virDomainPtr dom, VIR_PERF_PARAM_CACHE_REFERENCES, VIR_TYPED_PARAM_BOOLEAN, VIR_PERF_PARAM_CACHE_MISSES, VIR_TYPED_PARAM_BOOLEAN, VIR_PERF_PARAM_BRANCH_INSTRUCTIONS, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_BRANCH_MISSES, VIR_TYPED_PARAM_BOOLEAN, NULL) < 0) return -1; diff --git a/src/util/virperf.c b/src/util/virperf.c index 635faf1..7f630da 100644 --- a/src/util/virperf.c +++ b/src/util/virperf.c @@ -41,7 +41,7 @@ VIR_ENUM_IMPL(virPerfEvent, VIR_PERF_EVENT_LAST, "cmt", "mbmt", "mbml", "cpu_cycles", "instructions", "cache_references", "cache_misses", - "branch_instructions"); + "branch_instructions", "branch_misses"); struct virPerfEvent { int type; @@ -89,6 +89,9 @@ static struct virPerfEventAttr attrs[] = { {.type = VIR_PERF_EVENT_BRANCH_INSTRUCTIONS, .attrType = PERF_TYPE_HARDWARE, .attrConfig = PERF_COUNT_HW_BRANCH_INSTRUCTIONS}, + {.type = VIR_PERF_EVENT_BRANCH_MISSES, + .attrType = PERF_TYPE_HARDWARE, + .attrConfig = PERF_COUNT_HW_BRANCH_MISSES}, }; typedef struct virPerfEventAttr *virPerfEventAttrPtr; diff --git a/src/util/virperf.h b/src/util/virperf.h index 8ebc03c..7049a5b 100644 --- a/src/util/virperf.h +++ b/src/util/virperf.h @@ -38,6 +38,7 @@ typedef enum { VIR_PERF_EVENT_CACHE_MISSES, /* Cache misses by applications */ VIR_PERF_EVENT_BRANCH_INSTRUCTIONS, /* Count of branch instructions for applications */ + VIR_PERF_EVENT_BRANCH_MISSES, /* Count of branch misses for applications */ VIR_PERF_EVENT_LAST } virPerfEventType; diff --git a/tests/genericxml2xmlindata/generic-perf.xml b/tests/genericxml2xmlindata/generic-perf.xml index 92e5847..a1e4e1c 100644 --- a/tests/genericxml2xmlindata/generic-perf.xml +++ b/tests/genericxml2xmlindata/generic-perf.xml @@ -21,6 +21,7 @@ <event name='cache_references' enabled='no'/> <event name='cache_misses' enabled='no'/> <event name='branch_instructions' enabled='yes'/> + <event name='branch_misses' enabled='yes'/> </perf> <devices> </devices> diff --git a/tools/virsh.pod b/tools/virsh.pod index 869062a..74c05c9 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -946,7 +946,8 @@ I<--perf> returns the statistics of all enabled perf events: "perf.instructions" - the count of instructions, "perf.cache_references" - the count of cache hits, "perf.cache_misses" - the count of caches misses, -"perf.branch_instructions" - the count of application branch instructions +"perf.branch_instructions" - the count of branch instructions, +"perf.branch_misses" - the count of branch misses See the B<perf> command for more details about each event. @@ -2296,6 +2297,8 @@ B<Valid perf event names> branch_instructions - Provides the count of branch instructions executed by applications running on the platform. + branch_misses - Provides the count of branch misses executed + by applications running on the platform. B<Note>: The statistics can be retrieved using the B<domstats> command using the I<--perf> flag. -- 1.9.3

2 1