- Devel - libvirt List Archives

[ruby PATCH] Fix cpumap allocation for virDomainGetVcpus and use return value
by Charlie Smurthwaite 21 Feb '20

21 Feb '20

This patch fixes a bug in which only enough memory for one cpumap is allocated for virDomainGetVcpus instead of one per virtual CPU. This Fixes an overflow. Additionally, it uses the return value of virDomainGetVcpus to determine how many cpuinfo structs were actually populated rather than assuming they all are. Finally, it uses the logical CPU number from the cpuinfo struct in the retrurn data instead of assuming CPU numbers are sequential. This should handle cases where arbitrary CPUs are offline. Signed-off-by: Charlie Smurthwaite <charlie(a)atechmedia.com> --- ext/libvirt/domain.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/ext/libvirt/domain.c b/ext/libvirt/domain.c index d665907..c6de1bf 100644 --- a/ext/libvirt/domain.c +++ b/ext/libvirt/domain.c @@ -803,7 +803,7 @@ static VALUE libvirt_domain_vcpus(VALUE d) cpumaplen = VIR_CPU_MAPLEN(maxcpus); - cpumap = alloca(sizeof(unsigned char) * cpumaplen); + cpumap = alloca(sizeof(unsigned char) * cpumaplen * dominfo.nrVirtCpu); r = virDomainGetVcpus(ruby_libvirt_domain_get(d), cpuinfo, dominfo.nrVirtCpu, cpumap, cpumaplen); @@ -832,15 +832,16 @@ static VALUE libvirt_domain_vcpus(VALUE d) result = rb_ary_new(); - for (i = 0; i < dominfo.nrVirtCpu; i++) { + for (i = 0; i < r; i++) { vcpuinfo = rb_class_new_instance(0, NULL, c_domain_vcpuinfo); - rb_iv_set(vcpuinfo, "@number", UINT2NUM(i)); if (cpuinfo != NULL) { + rb_iv_set(vcpuinfo, "@number", INT2NUM(cpuinfo[i].number)); rb_iv_set(vcpuinfo, "@state", INT2NUM(cpuinfo[i].state)); rb_iv_set(vcpuinfo, "@cpu_time", ULL2NUM(cpuinfo[i].cpuTime)); rb_iv_set(vcpuinfo, "@cpu", INT2NUM(cpuinfo[i].cpu)); } else { + rb_iv_set(vcpuinfo, "@number", Qnil); rb_iv_set(vcpuinfo, "@state", Qnil); rb_iv_set(vcpuinfo, "@cpu_time", Qnil); rb_iv_set(vcpuinfo, "@cpu", Qnil); -- 2.25.0

2 1

[PATCH 0/3] Couple of memleak fixes
by Michal Privoznik 21 Feb '20

21 Feb '20

*** BLURB HERE *** Michal Prívozník (3): virDomainFSDefFree: Unref private data virDomainNetDefClear: Free @persistent name qemuTestParseCapabilitiesArch: Free @binary src/conf/domain_conf.c | 2 ++ tests/testutilsqemu.c | 4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-) -- 2.24.1

2 6

[libvirt PATCH] docs: Expand documentation for the tickpolicy timer attribute
by Andrea Bolognani 21 Feb '20

21 Feb '20

The current documentation is fairly terse and not easy to decode for someone who's not intimately familiar with the inner workings of timer devices. Expand on it by providing a somewhat verbose description of what behavior each policy will result in, as seen from both the guest OS and host point of view. This is lifted directly from QEMU commit commit 2a7d957596786404c4ed16b089273de95a9580ad Author: Andrea Bolognani <abologna(a)redhat.com> Date: Tue Feb 11 19:37:44 2020 +0100 qapi: Expand documentation for LostTickPolicy v4.2.0-1442-g2a7d957596 The original text also matched word for word the documentation found in QEMU. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- docs/formatdomain.html.in | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index f4af65f13f..4fef2a0a97 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -2487,26 +2487,36 @@ <p> The <code>tickpolicy</code> attribute determines what happens when QEMU misses a deadline for injecting a - tick to the guest: + tick to the guest. This can happen, for example, because the + guest was paused. </p> <dl> <dt><code>delay</code></dt> - <dd>Continue to deliver ticks at the normal rate. - The guest time will be delayed due to the late - tick</dd> + <dd>Continue to deliver ticks at the normal rate. The guest OS + will not notice anything is amiss, as from its point of view + time will have continued to flow normally. The time in the + guest should now be behind the time in the host by exactly + the amount of time during which ticks have been missed.</dd> <dt><code>catchup</code></dt> - <dd>Deliver ticks at a higher rate to catch up - with the missed tick. The guest time should - not be delayed once catchup is complete.</dd> + <dd>Deliver ticks at a higher rate to catch up with the missed + ticks. The guest OS will not notice anything is amiss, as + from its point of view time will have continued to flow + normally. Once the timer has managed to catch up with all + the missing ticks, the time in the guest and in the host + should match.</dd> <dt><code>merge</code></dt> <dd>Merge the missed tick(s) into one tick and inject. The guest time may be delayed, depending on how the OS reacts to the merging of ticks</dd> <dt><code>discard</code></dt> - <dd>Throw away the missed tick(s) and continue - with future injection normally. The guest time - may be delayed, unless the OS has explicit - handling of lost ticks</dd> + <dd>Throw away the missed ticks and continue with future + injection normally. The guest OS will see the timer jump + ahead by a potentially quite significant amount all at once, + as if the intervening chunk of time had simply not existed; + needless to say, such a sudden jump can easily confuse a + guest OS which is not specifically prepared to deal with it. + Assuming the guest OS can deal correctly with the time jump, + the time in the guest and in the host should now match.</dd> </dl> <p>If the policy is "catchup", there can be further details in the <code>catchup</code> sub-element.</p> -- 2.24.1

2 1

[PATCH v1 0/3] qemumonitorjson tests for cpu compare and baseline
by Collin Walling 21 Feb '20

21 Feb '20

These patches implement tests for the libvirt qemu_monitor_json API for the hypervisor-cpu-compare and -baseline commands. The input and output data is mocked with arbitrary values. A prerequisite patch is included to load the capabilities schema for a specific architecture. Originally, only the x86 capabilities were loaded for the qemu_monitor_json tests. By accepting a string denoting which architecture's QEMU capabilities we'd like to load, we can now test the comparison and baseline code that is currently only supported on s390. Collin Walling (3): qemumonitorjsontest: load schema based on specified arch qemumonitorjsontest: add tests for cpu comparison qemumonitorjsontest: add test for cpu baseline tests/qemublocktest.c | 2 +- tests/qemuhotplugtest.c | 2 +- tests/qemumonitorjsontest.c | 131 +++++++++++++++++++++++++++++++++++++++++++- tests/testutilsqemuschema.c | 8 +-- tests/testutilsqemuschema.h | 4 +- 5 files changed, 137 insertions(+), 10 deletions(-) -- 2.7.4

2 4

[libvirt PATCH] m4: libxl: properly fail when libxl is required
by Ján Tomko 20 Feb '20

20 Feb '20

We specify "true" as the fail-action for LIBVIRT_CHECK_PKG. This was used when we had a fallback to non-pkg-config detection, then removed in commit 5bdcef13d13560512c7d6d8c9e8822e456889e0c later re-introduced in commit dc3d2c9f8c7678a950abedd227b1587ca62335c4 and then left in when removing the old detection again in commit 18981877d2e20390a79d068861a24e716f8ee422 Remove it to properly error out when libxl was requested but not detected. Signed-off-by: Ján Tomko <jtomko(a)redhat.com> Fixes: 18981877d2e20390a79d068861a24e716f8ee422 --- m4/virt-driver-libxl.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/m4/virt-driver-libxl.m4 b/m4/virt-driver-libxl.m4 index 2f3565f1d5..a958cb26fa 100644 --- a/m4/virt-driver-libxl.m4 +++ b/m4/virt-driver-libxl.m4 @@ -30,7 +30,7 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_LIBXL], [ dnl search for libxl, aka libxenlight old_with_libxl="$with_libxl" - LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0], [true]) + LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0]) if test "x$with_libxl" = "xyes" ; then LIBXL_FIRMWARE_DIR=$($PKG_CONFIG --variable xenfirmwaredir xenlight) LIBXL_EXECBIN_DIR=$($PKG_CONFIG --variable libexec_bin xenlight) -- 2.24.1

2 1

[PATCH 0/3] Couple of almost trivial patches
by Michal Privoznik 20 Feb '20

20 Feb '20

These stem out from my review of Marc-André's patches: https://www.redhat.com/archives/libvir-list/2020-January/msg00648.html Michal Prívozník (3): virpidfile: Set correct retval in virPidFileReadPath() qemu: Don't explicitly remove pidfile after virPidFileForceCleanupPath() qemu_migration: Rearrange some checks in qemuMigrationSrcIsAllowed() src/qemu/qemu_migration.c | 66 +++++++++++++++++----------------- src/qemu/qemu_process.c | 9 +---- src/qemu/qemu_vhost_user_gpu.c | 10 +----- src/util/virpidfile.c | 2 +- 4 files changed, 36 insertions(+), 51 deletions(-) -- 2.24.1

2 4

[libvirt PATCH 00/10] support BR_ISOLATED flag for guest interfaces attached to a Linux host bridge
by Laine Stump 20 Feb '20

20 Feb '20

https://bugzilla.redhat.com/1727263 Since Linux kernel 4.18, the Linux host bridge has had a flag BR_ISOLATED that can be applied to individual ports. When this flag is set for a port, traffic is blocked between that port and any other port that also has the BR_ISOLATED flag set. libvirt domain interface config now supports setting this flag via the <portOptions isolated='yes'/> setting. It can also be set for all connections to a particular libvirt network by setting the same option in the network config - since the port for the host itself does not have BR_ISOLATED set, the guests can communicate with the host and the outside world, but guests on that network can't communicate with each other. This feature works for QEMU and LXC guests with interfaces attached to a Linux host bridge. (I had contemplated (and experimented with) putting this new flag in the <virtualport> element to avoid creating a new element, but that ended up creating lots of extra code since none of the existing virtualport types would support this new flag, Linux host bridges already work with *no* <virtualport> (much less a virtualport type), and there are some attributes in the <virtualport> parameters subelement that are always autogenerated if there is no virtualport type specified, so I would needed to add a new virtualport type for Linux host bridge, which seems redundant as that information is already implicit in the interface's connection type. etc. etc. It all just turned into a big mess, and starting over fresh with something generic (and hopefully expandable in a sensible way) seemed cleaner). (I am of course open to suggestions though!) Laine Stump (10): schema: trivial indentation fix schema: add missing vlan element to networkport RNG qemu: save/restore original error when recovering from failed bridge attach util: query/set BR_ISOLATED flag on netdevs attached to bridge conf: parse/format <portOptions isolated='yes|no'/> network: propagate <portOptions isolated='yes'/> between network and domain qemu/lxc: plumb isolatedPort from config down through bridge attachment qemu: support updating <portOptions isolated='yes|no'/> during device update conf: extra validation for <portOptions isolated='yes'/> docs: add info about <portOptions isolated='yes'/> to news file docs/news.xml | 21 +++++ docs/schemas/domaincommon.rng | 3 + docs/schemas/network.rng | 9 ++- docs/schemas/networkcommon.rng | 11 +++ docs/schemas/networkport.rng | 6 ++ src/bhyve/bhyve_command.c | 1 + src/conf/domain_conf.c | 79 +++++++++++++++++++ src/conf/domain_conf.h | 4 + src/conf/network_conf.c | 32 ++++++++ src/conf/network_conf.h | 9 +++ src/conf/virnetworkportdef.c | 3 + src/conf/virnetworkportdef.h | 1 + src/libvirt_private.syms | 3 + src/lxc/lxc_process.c | 10 +++ src/network/bridge_driver.c | 4 + src/qemu/qemu_hotplug.c | 47 +++++++++-- src/qemu/qemu_interface.c | 1 + src/util/virnetdevbridge.c | 46 +++++++++++ src/util/virnetdevbridge.h | 9 +++ src/util/virnetdevtap.c | 17 +++- src/util/virnetdevtap.h | 3 + tests/bhyvexml2argvmock.c | 1 + tests/networkxml2xmlin/isolated-ports.xml | 7 ++ tests/networkxml2xmlout/isolated-ports.xml | 7 ++ tests/networkxml2xmltest.c | 1 + tests/qemuxml2argvdata/net-isolated-port.xml | 34 ++++++++ .../net-isolated-port.x86_64-latest.xml | 63 +++++++++++++++ tests/qemuxml2xmltest.c | 1 + 28 files changed, 423 insertions(+), 10 deletions(-) create mode 100644 tests/networkxml2xmlin/isolated-ports.xml create mode 100644 tests/networkxml2xmlout/isolated-ports.xml create mode 100644 tests/qemuxml2argvdata/net-isolated-port.xml create mode 100644 tests/qemuxml2xmloutdata/net-isolated-port.x86_64-latest.xml -- 2.24.1

2 25

[PATCH 0/4] lxc: Add VCPU features for LXC
by Julio Faracco 19 Feb '20

19 Feb '20

This series cover a lots of functionalities to LXC VCPUs. It enables sharing some timer devices between host and LXC guest using `timer` settings. It still has other improvements related to VCPU and LXC such as virtual cpuinfo content based on VCPU settings and some better resource limits. Each patch has the description of the problem and what it is trying to fix. Julio Faracco (4): lxc: Add Real Time Clock device into allowed devices lxc: Add HPET device into allowed devices lxc: Implement virtual /proc/cpuinfo via LXC fuse lxc: Count max VCPUs based on cpuset.cpus in native config. docs/formatdomain.html.in | 4 +- src/lxc/lxc_cgroup.c | 76 ++++++++++++++ src/lxc/lxc_container.c | 38 +++++++ src/lxc/lxc_container.h | 2 + src/lxc/lxc_controller.c | 98 +++++++++++++++++++ src/lxc/lxc_fuse.c | 78 ++++++++++++++- src/lxc/lxc_native.c | 24 ++++- .../lxcconf2xml-cpusettune.xml | 2 +- 8 files changed, 313 insertions(+), 9 deletions(-) -- 2.20.1

2 8

Re: [PATCH v2 0/2] finish qemu-nbd --partition deprecation
by Eric Blake 19 Feb '20

19 Feb '20

ping On 1/23/20 10:46 AM, Eric Blake wrote: > Based-on: <20200116141511.16849-1-peter.maydell(a)linaro.org> > (0/3 convert qemu-nbd, qemu-block-drivers to rST) > > In v2: > - rebased on top of rST doc changes > - patch 1 added > > Eric Blake (2): > docs: Fix typo in qemu-nbd -P replacement > qemu-nbd: Removed deprecated --partition option > > docs/interop/qemu-nbd.rst | 15 ++--- > qemu-deprecated.texi | 49 ++++++-------- > qemu-nbd.c | 133 +------------------------------------- > 3 files changed, 24 insertions(+), 173 deletions(-) > -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

2 2

[libvirt PATCH 0/2] cpu_conf: Format vendor_id for host-model CPUs
by Jiri Denemark 19 Feb '20

19 Feb '20

In commit v5.9.0-400-gaf8e39921a I removed printing model's fallback and vendor_id attributes when no model is specified. However, vendor_id makes sense even without a specific CPU model (for host-model CPUs). https://bugzilla.redhat.com/show_bug.cgi?id=1804549 Jiri Denemark (2): qemuxml2xmltest: Add case for host-model vendor_id cpu_conf: Format vendor_id for host-model CPUs src/conf/cpu_conf.c | 14 +++++---- .../cpu-host-model-vendor.xml | 30 +++++++++++++++++++ tests/qemuxml2xmltest.c | 1 + 3 files changed, 40 insertions(+), 5 deletions(-) create mode 100644 tests/qemuxml2xmloutdata/cpu-host-model-vendor.xml -- 2.25.0

2 4