- Devel - libvirt List Archives

[libvirt] [PATCH 0/7] Remove the last "no_memory" label
by Fabiano Fidêncio 02 Jan '20

02 Jan '20

This series touches virfirewall.c, the last place where a no_memory label can be found. The series: - Renames no_memory to cleanup; - Gets rid of ENOMEM error treatment; - Use g_auto / g_autofree in a few different places; - Add new macros as ADD_ARG heavily rely on a goto; - Remove no_memory mention from the hacking guide; I'm not totally sure whether the new macros addition are worth it. Fabiano Fidêncio (7): util: Rename 'no_memory' label to 'cleanup' util: Don't set/check for ENOMEM as a firewall error util: Use g_auto/g_autofree in virFirewallAddRuleFullV() util: Use g_auto in virFirewallStartTransaction() util: Add ADD_ARG_RETURN_ON_ERROR util: Add ADD_ARG_RETURN_VALUE_ON_ERROR docs: Remove mention to no_memory label docs/hacking.html.in | 1 - src/util/virfirewall.c | 94 +++++++++++++++++++----------------------- 2 files changed, 42 insertions(+), 53 deletions(-) -- 2.24.1

2 9

[libvirt] [tck PATCH 0/2] Enable the storage encryption test
by Erik Skultety 02 Jan '20

02 Jan '20

The test was present, but at the time the test was added libvirt (apparently) didn't fully support LUKS encryption with disks. Erik Skultety (2): scripts: qemu: Fix the disk encryption test description scripts: qemu: Enable disk encryption test scripts/qemu/100-disk-encryption.t | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) -- 2.23.0

2 5

[libvirt] [PATCH] maint: update to latest gnulib
by Ján Tomko 02 Jan '20

02 Jan '20

Update to: commit 7d069378921bfa0d7c7198ea177aac0a2440016f Author: Pádraig Brady <P(a)draigBrady.com> CommitDate: 2020-01-01 22:00:28 +0000 md5, sha1, sha256, sha512: support --with-openssl=auto-gpl-compat Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- .gnulib | 2 +- bootstrap | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) Pushed. diff --git a/.gnulib b/.gnulib index 1f6fb368c0..7d06937892 160000 --- a/.gnulib +++ b/.gnulib @@ -1 +1 @@ -Subproject commit 1f6fb368c04919243e2c70f2aa514a5f88e95309 +Subproject commit 7d069378921bfa0d7c7198ea177aac0a2440016f diff --git a/bootstrap b/bootstrap index 5b08e7e2d4..70fd73cc74 100755 --- a/bootstrap +++ b/bootstrap @@ -4,7 +4,7 @@ scriptversion=2019-01-04.17; # UTC # Bootstrap this package from checked-out sources. -# Copyright (C) 2003-2019 Free Software Foundation, Inc. +# Copyright (C) 2003-2020 Free Software Foundation, Inc. # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -166,7 +166,7 @@ bootstrap_epilogue() { :; } # specified directory. Fill in the first %s with the destination # directory and the second with the domain name. po_download_command_format=\ -"wget --mirror --level=1 -nd -q -A.po -P '%s' \ +"wget --mirror --level=1 -nd -nv -A.po -P '%s' \ https://translationproject.org/latest/%s/" # Prefer a non-empty tarname (4th argument of AC_INIT if given), else -- 2.19.2

1 0

[libvirt] [PATCH] storage: Fix volStorageBackendRBDRefreshVolInfo
by Yi Li 24 Dec '19

24 Dec '19

Fix the return value status comparison checking for call to volStorageBackendRBDRefreshVolInfo introduced by commit id f46d137e. we only should fail when the return is < 0. -ENOENT, -ETIMEDOUT will ignore according commit id f46d137e. Signed-off-by: Yi Li <yili(a)winhong.com> --- src/storage/storage_backend_rbd.c | 40 ++++++++++++++++++++++++--------------- 1 file changed, 25 insertions(+), 15 deletions(-) diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c index 7ce26ed..1551cf4 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -411,6 +411,7 @@ volStorageBackendRBDGetFeatures(rbd_image_t image, int r, ret = -1; if ((r = rbd_get_features(image, features)) < 0) { + ret = r; virReportSystemError(-r, _("failed to get the features of RBD image " "%s"), volname); goto cleanup; @@ -427,16 +428,19 @@ volStorageBackendRBDGetFlags(rbd_image_t image, const char *volname, uint64_t *flags) { - int rc; + int r, ret = -1; - if ((rc = rbd_get_flags(image, flags)) < 0) { - virReportSystemError(-rc, + if ((r = rbd_get_flags(image, flags)) < 0) { + ret = r; + virReportSystemError(-r, _("failed to get the flags of RBD image %s"), volname); - return -1; + goto cleanup; } + ret = 0; - return 0; + cleanup: + return ret; } static bool @@ -470,6 +474,7 @@ virStorageBackendRBDSetAllocation(virStorageVolDefPtr vol, if ((r = rbd_diff_iterate2(image, NULL, 0, info->size, 0, 1, &virStorageBackendRBDRefreshVolInfoCb, &allocation)) < 0) { + ret = r; virReportSystemError(-r, _("failed to iterate RBD image '%s'"), vol->name); goto cleanup; @@ -525,24 +530,28 @@ volStorageBackendRBDRefreshVolInfo(virStorageVolDefPtr vol, uint64_t flags; if ((r = rbd_open_read_only(ptr->ioctx, vol->name, &image, NULL)) < 0) { - ret = -r; + ret = r; virReportSystemError(-r, _("failed to open the RBD image '%s'"), vol->name); goto cleanup; } if ((r = rbd_stat(image, &info, sizeof(info))) < 0) { - ret = -r; + ret = r; virReportSystemError(-r, _("failed to stat the RBD image '%s'"), vol->name); goto cleanup; } - if (volStorageBackendRBDGetFeatures(image, vol->name, &features) < 0) + if ((r = volStorageBackendRBDGetFeatures(image, vol->name, &features)) < 0) { + ret = r; goto cleanup; + } - if (volStorageBackendRBDGetFlags(image, vol->name, &flags) < 0) + if ((r = volStorageBackendRBDGetFlags(image, vol->name, &flags)) < 0) { + ret = r; goto cleanup; + } vol->target.capacity = info.size; vol->type = VIR_STORAGE_VOL_NETWORK; @@ -555,8 +564,11 @@ volStorageBackendRBDRefreshVolInfo(virStorageVolDefPtr vol, "Querying for actual allocation", def->source.name, vol->name); - if (virStorageBackendRBDSetAllocation(vol, image, &info) < 0) + if ((r = virStorageBackendRBDSetAllocation(vol, image, &info) < 0)) { + ret = r; goto cleanup; + } + } else { vol->target.allocation = info.obj_size * info.num_objs; } @@ -734,12 +746,10 @@ virStorageBackendRBDRefreshPool(virStoragePoolObjPtr pool) * * Do not error out and simply ignore the volume */ - if (r < 0) { - if (r == -ENOENT || r == -ETIMEDOUT) - continue; - + if (r == -ENOENT || r == -ETIMEDOUT) + continue; + else if (r < 0) goto cleanup; - } if (virStoragePoolObjAddVol(pool, vol) < 0) goto cleanup; -- 2.7.5

3 7

[libvirt] [go-xml PATCH 0/2] Fix libvirt-go-xml test CI
by Cole Robinson 23 Dec '19

23 Dec '19

Patch 1 is a nearby 'fix' Patch 2 fixes the CI for the new address type='unassigned' Cole Robinson (2): Fix virtio-s390 address lookup Support domain address type='unassigned' domain.go | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) -- 2.23.0

2 5

[libvirt] [jenkins-ci PATCH] guests: update FreeBSD to use py37 packages
by Daniel P. Berrangé 23 Dec '19

23 Dec '19

The base python3 package was updated to python 3.7.5, so we must update all the modules to match this version. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- guests/vars/mappings.yml | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml index ef4e17a..7b97546 100644 --- a/guests/vars/mappings.yml +++ b/guests/vars/mappings.yml @@ -160,7 +160,7 @@ mappings: flake8: deb: flake8 - pkg: py36-flake8 + pkg: py37-flake8 rpm: python3-flake8 CentOS7: @@ -824,14 +824,14 @@ mappings: python3-docutils: default: python3-docutils CentOS7: python36-docutils - FreeBSD: py36-docutils + FreeBSD: py37-docutils python3: default: python3 python3-dbus: default: python3-dbus - FreeBSD: py36-dbus + FreeBSD: py37-dbus CentOS7: python36-dbus python3-devel: @@ -843,24 +843,24 @@ mappings: python3-gi: deb: python3-gi - pkg: py36-gobject3 + pkg: py37-gobject3 rpm: python3-gobject CentOS7: python36-gobject python3-libxml2: default: python3-libxml2 - FreeBSD: py36-libxml2 + FreeBSD: py37-libxml2 CentOS7: Ubuntu1604: python3-lxml: default: python3-lxml - FreeBSD: py36-lxml + FreeBSD: py37-lxml CentOS7: python36-lxml python3-nose: default: python3-nose - FreeBSD: py36-nose + FreeBSD: py37-nose CentOS7: python36-nose python3-pip: @@ -871,17 +871,17 @@ mappings: python3-pytest: default: python3-pytest - FreeBSD: py36-pytest + FreeBSD: py37-pytest CentOS7: python36-pytest python3-requests: default: python3-requests - FreeBSD: py36-requests + FreeBSD: py37-requests CentOS7: python36-requests python3-setuptools: default: python3-setuptools - FreeBSD: py36-setuptools + FreeBSD: py37-setuptools qemu-img: default: qemu-utils -- 2.23.0

1 1

[libvirt] [PATCH] docs/auth.html.in: fixed typos
by Andrew Miloradovsky 23 Dec '19

23 Dec '19

Signed-off-by: Andrew Miloradovsky <andrew(a)interpretmath.pw> --- docs/auth.html.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/auth.html.in b/docs/auth.html.in index 62af43a915..c81c1e58ad 100644 --- a/docs/auth.html.in +++ b/docs/auth.html.in @@ -274,7 +274,7 @@ to turn on SASL auth in these listeners. Since the libvirt SASL config file defaults to using GSSAPI (Kerberos), a -config change is rquired to enable plain password auth. This is done by +config change is required to enable plain password auth. This is done by editting <code>/etc/sasl2/libvirt.conf</code> to set the <code>mech_list</code> parameter to <code>scram-sha-1</code>. @@ -317,7 +317,7 @@ in these scenarios - only the plain TCP listener needs encryption Some operating systems do not install the SASL kerberos plugin by default. It may be necessary to install a sub-package such as <code>cyrus-sasl-gssapi</code>. To check whether the Kerberos plugin is installed run the <code>pluginviewer</code> -program and verify that <code>gssapi</code> is listed,eg: +program and verify that <code>gssapi</code> is listed, e.g.: <pre> # pluginviewer @@ -359,7 +359,7 @@ kadmin.local: quit Any client application wishing to connect to a Kerberos enabled libvirt server merely needs to run <code>kinit</code> to gain a user principal. This may well -be done automatically when a user logs into a desktop session, if PAM is setup +be done automatically when a user logs into a desktop session, if PAM is set up to authenticate against Kerberos. </body> -- 2.24.0

2 1

[libvirt] [PATCH] gconfig: Add GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_QEMU_XHCI
by Felipe Borges 23 Dec '19

23 Dec '19

Modern operating systems support qemu-xhci and that's available since libvirt 3.3.x and qemu 2.9.x Signed-off-by: Felipe Borges <feborges(a)redhat.com> --- libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h b/libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h index d593764..3f93d7c 100644 --- a/libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h +++ b/libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h @@ -65,7 +65,8 @@ typedef enum { GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_ICH9_UHCI2, GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_ICH9_UHCI3, GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_VT82C686B_UHCI, - GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_PCI_OHCI + GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_PCI_OHCI, + GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_QEMU_XHCI } GVirConfigDomainControllerUsbModel; GType gvir_config_domain_controller_usb_get_type(void); -- 2.24.1

2 1

[libvirt] [PATCH 0/5] Get rid of "no_memory" labels
by Fabiano Fidêncio 23 Dec '19

23 Dec '19

As pointed out by Ján Tomko, "no_memory seems suspicious in the times of abort()". As libvirt decided to take the path to not report OOM and simply abort when it happens, let's get rid of the no_memory labels and simplify the code around them. The two exceptions are: - phyp code, as libvirt may end up dropping this code entirely; - virfirewall.c code, as it seems we heavily really on firewall->err being set to ENOMEM; If one thinks that virfirewall.c should also be converted, please, shout out and I'll work on that. Fabiano Fidêncio (5): conf: Get rid of "no_memory" labels openvz: Get rid of "no_memory" labels rpc: Get rid of "no_memory" labels util: Get rid of "no_memory" labels vbox: Get rid of "no_memory" labels src/conf/capabilities.c | 16 ++-------- src/conf/domain_audit.c | 40 +++++++------------------ src/openvz/openvz_conf.c | 18 +++++------ src/rpc/virnetclient.c | 42 ++++++++------------------ src/util/virsysinfo.c | 64 +++++++++++++++------------------------- src/util/virsysinfo.h | 2 ++ src/util/viruri.c | 28 +++++++----------- src/vbox/vbox_common.c | 20 +++++-------- 8 files changed, 75 insertions(+), 155 deletions(-) -- 2.24.1

3 7

[libvirt] [PATCH] storage: Fix daemon crash on lookup storagepool by targetpath
by Yi Li 22 Dec '19

22 Dec '19

Causing a crash when storagePoolLookupByTargetPath because of Some types of storage pool have no target elements. Core was generated by `/usr/sbin/libvirtd'. Program terminated with signal 11, Segmentation fault. (gdb) bt 0 0x0000ffff9e951388 in strcmp () from /lib64/libc.so.6 1 0x0000ffff92103e9c in storagePoolLookupByTargetPathCallback ( obj=0xffff7009aab0, opaque=0xffff801058b0) at storage/storage_driver.c:1649 2 0x0000ffff9f2c52a4 in virStoragePoolObjListSearchCb ( payload=0xffff801058b0, name=<optimized out>, opaque=<optimized out>) at conf/virstorageobj.c:476 3 0x0000ffff9f1f2f7c in virHashSearch (ctable=0xffff800f4f60, iter=iter@entry=0xffff9f2c5278 <virStoragePoolObjListSearchCb>, data=data@entry=0xffff95af7488, name=name@entry=0x0) at util/virhash.c:696 4 0x0000ffff9f2c64f0 in virStoragePoolObjListSearch (pools=0xffff800f2ce0, searcher=searcher@entry=0xffff92103e68 <storagePoolLookupByTargetPathCallback>, opaque=<optimized out>) at conf/virstorageobj.c:505 5 0x0000ffff92101f54 in storagePoolLookupByTargetPath (conn=0xffff5c0009f0, path=0xffff7009a850 "/vms/images") at storage/storage_driver.c:1672 Signed-off-by: Yi Li <yili(a)winhong.com> --- src/storage/storage_driver.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index a33328d..5863e1f 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -1713,6 +1713,12 @@ storagePoolLookupByTargetPathCallback(virStoragePoolObjPtr obj, return false; def = virStoragePoolObjGetDef(obj); + + /* Some Storage pool types have no Target elements, + * so we should check it. */ + if (def->target.path == NULL) + return false; + return STREQ(path, def->target.path); } -- 2.7.5

2 3

Re: [libvirt] Add support for vhost-user-scsi-pci/vhost-user-blk-pci
by Cole Robinson 22 Dec '19

22 Dec '19

FYI there's some more recent discussion over here: https://www.redhat.com/archives/libvir-list/2019-December/msg00817.html There isn't any objections to using <disk type='vhostuser'/> for vhost-user-blk, so maybe that's a good place to start. Thanks, Cole On 10/15/19 7:34 AM, Li Feng wrote: > Cole Robinson <crobinso(a)redhat.com> 于2019年10月15日周二上午1:48写道： >> >> On 10/14/19 3:12 AM, Li Feng wrote: >>> Hi Cole & Michal, >>> >>> I'm sorry for my late response, I just end my journey today. >>> Thank your response, your suggestion is very helpful to me. >>> >>> I have added Michal in this mail, Michal helps me review my initial patchset. >>> (https://www.spinics.net/linux/fedora/libvir/msg191339.html) >>> >> >> Whoops I missed that posting, I didn't realize you had sent patches! >> >>> All concern about this feature is the XML design. >>> My original XML design exposes more details of Qemu. >>> >>> <vhost-user-blk-pci type='unix'> >>> <source type='bind' path='/tmp/vhost-blk.sock'> >>> <reconnect enabled='yes' timeout='5' /> >>> </source> >>> <queue num='4'/> >>> </vhost-user-blk-pci> >>> >>> As Cole's suggestion, the better design with all vhost-user-scsi/blk >>> features would like this: >>> >>> vhost-user-blk: >>> >>> <disk type='vhostuser' device='disk'> >>> <source type='unix' path='/path/to/vhost-user-blk.sock' mode='client'> >>> <reconnect enabled='yes' timeout='5' /> >>> </source> >>> <target dev='vda' bus='virtio'/> >>> <queue num='4'/> >>> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> >>> </disk> >>> >>> vhost-user-scsi: >>> >>> <disk type='vhostuser' device='disk'> >>> <source type='unix' path='/path/to/vhost-user-scsi.sock' mode='client'> >>> <reconnect enabled='yes' timeout='5' /> >>> </source> >>> <target dev='sda' bus='scsi'/> >>> <queue num='4'/> >>> </disk> >>> >> >> I think my SCSI idea is wrong, sorry. vhost-user-scsi is for passing a >> scsi host adapter to the VM, correct? If so, then it's not really a >> <disk>, and so using the existing vhost-scsi support in <hostdev> is >> probably better. <hostdev> could possible be used for vhost-user-blk as well >> >> Can you provide some examples of full qemu command lines using >> vhost-user-blk and vhost-user-scsi? Just linking to examples else where >> is fine, but I'm wondering if there's more context > > You could check the vhost-user-scsi/blk examples from SPDK pages: > https://spdk.io/doc/vhost.html > >> >> Internally we already have an abstraction for vhost-scsi: >> >> <hostdev mode='subsystem' type='scsi_host'> >> <source protocol='vhost' wwpn='XXX'/> >> </hostdev> >> >> >> The obvious extension would be >> >> <hostdev mode='subsystem' type='scsi_host'> >> <source protocol='vhostuser' type='unix' >> path='/path/to/vhost-user-scsi.sock' mode='client'/> >> </hostdev> >> >> Internally implementing this will be weird. The <source> parameters are >> only dictated by the hostdev type= field, but in this case they would be >> dictated by the <source protocol=> field, and we would want to reuse the >> internal chardev abstraction. >> >> vhost-user-blk could be implemented similarly, but with type='storage' >> which is the way we pass through block devices to LXC guests, but it >> isn't currently supported in the qemu driver. >> >> I dunno. Maybe Michal or danpb can provide guidance >> > @Michal, @danpb, could you give some guidance? >> >>> Conclusion: >>> 1. Add new type(vhostuser) for disk label; >>> 2. Add queue sub-label for disk to support multiqueue(<queue >>> num='4'/>) or reusing the driver label >>> (<driver name='vhostuser' queues='4'), which one is better? >>> Qemu support multiqueue like this: >>> -device vhost-user-scsi-pci,id=scsi0,chardev=spdk_vhost_scsi0,num_queues=4 >>> -device vhost-user-blk-pci,chardev=spdk_vhost_blk0,num-queues=4 >>> >> >> num-queues is already supported by libvirt for both <disk> and <hostdev> >> with <driver queues=X/>, so whether we use <disk> or <hostdev> you won't >> need to add any new XML here. > Got it. > >> >>> Another question: >>> When qemu is connecting to a vhost-user-scsi controller[1], there may >>> exist multiple LUNs under one target, >>> then one disklabel(<disk/>) will represent multiple SCSI LUNs, >>> the 'dev' property(<target dev='sda' bus='scsi'/>) will be ignored, right? >>> In other words, for vhost-user-scsi disk, it more likes a controller, >>> maybe the controller label is suitable. >>> >> >> Yes you are right, and this was my understanding. But then its not >> really a <controller> in libvirt's sense because we can't attach >> emulated devices to it, so it's more a fit for the existing <hostdev> >> vhost-user support. Unfortunately it's not really a clean fit anywhere, >> there will have to be some kind of compromise. And I'm not sure if >> <disk> or <hostdev> is right for vhost-user-blk, but hopefully others >> have more clear opinions. > > I'm also confused about it. > Thanks for your reply. > > Thanks, > Feng Li > >> >> Thanks, >> Cole >> >>> I look forward to hearing from you as soon as possible. >>> >>> [1]: https://spdk.io/doc/vhost.html >>> >>> Feng Li >>> >>> Cole Robinson <crobinso(a)redhat.com> 于2019年10月10日周四上午6:48写道： >>>> >>>> Sorry for the late reply, and thanks Jano for pointing out elsewhere >>>> that this didn't receive a response. >>>> >>>> On 8/12/19 5:56 AM, Li Feng wrote: >>>>> Hi Guys, >>>>> >>>>> And I want to add the vhost-user-scsi-pci/vhost-user-blk-pci support >>>>> for libvirt. >>>>> >>>>> The usage in qemu like this: >>>>> >>>>> Vhost-SCSI >>>>> -chardev socket,id=char0,path=/var/tmp/vhost.0 >>>>> -device vhost-user-scsi-pci,id=scsi0,chardev=char0 >>>>> Vhost-BLK >>>>> -chardev socket,id=char1,path=/var/tmp/vhost.1 >>>>> -device vhost-user-blk-pci,id=blk0,chardev=char1 >>>>> >>>> >>>> Indeed that matches what I see for the qemu commits too: >>>> >>>> https://git.qemu.org/?p=qemu.git;a=commit;h=00343e4b54b >>>> https://git.qemu.org/?p=qemu.git;a=commit;h=f12c1ebddf7 >>>> >>>>> What type should I add for libvirt. >>>>> Type1: >>>>> <hostdev mode='subsystem' type='vhost-user'> >>>>> <source protocol='vhost-user-scsi' path='/tmp/vhost-scsi.sock'></source> >>>>> <alias name="vhost-user-scsi-disk1"/> >>>>> </hostdev> >>>>> >>>>> >>>>> Type2: >>>>> >>>>> <disk type='network' device='disk'> >>>>> <driver name='qemu' type='raw' cache='none' io='native'/> >>>>> <source protocol='vhost-user' path='/tmp/vhost-scsi.sock'> >>>>> </source> >>>>> <target dev='sdb' bus='vhost-user-scsi'/> >>>>> <boot order='3'/> >>>>> <alias name='scsi0-0-0-1'/> >>>>> <address type='drive' controller='0' bus='0' target='0' unit='1'/> >>>>> </disk> >>>>> >>>>> >>>>> <disk type='network' device='disk'> >>>>> <driver name='qemu' type='raw' cache='none' io='native'/> >>>>> <source protocol='vhost-user' path='/tmp/vhost-blk.sock'> >>>>> </source> >>>>> <target dev='vda' bus='vhost-user-blk'/> >>>>> <boot order='1'/> >>>>> <alias name='virtio-disk0'/> >>>>> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' >>>>> function='0x0'/> >>>>> </disk> >>>>> >>>> >>>> I think wiring this into <disk> makes more sense. <hostdev> is really an >>>> abstraction for assigning a (typically) physical host device to the VM, >>>> so it handles things like hiding a PCI device from the host, and passing >>>> that exact device to the VM. >>>> >>>> In the vhost-user-scsi/blk case, the host device is just a special >>>> process running on the other side of a socket, and the device >>>> represented to the guest is a typical virtio device. So to me it makes >>>> more sense as a <disk> with a <source> that points at that socket. >>>> >>>> target bus=virtio vs bus=scsi is already used to distinguish between >>>> virtio-blk and virtio-scsi, so I think we can keep that bit as is, with >>>> the <address type=drive|pci> to match. We just need to differentiate >>>> between plain virtio and vhost-user >>>> >>>> network devices already have vhostuser support: >>>> >>>> <interface type='vhostuser'> >>>> <source type='unix' path='/tmp/vhost1.sock' mode='server|client'/> >>>> <model type='virtio'/> >>>> </interface> >>>> >>>> Internally that <source> is a virDomainChrSourceDefPtr which is our >>>> internal representation of a chardev. So I think something akin to this >>>> is the way to go. It will likely require updating a LOT of places in the >>>> code that check disk type= field, probably most places that care about >>>> whether type=NETWORK or type=!NETWORK will need to be mirrored for the >>>> new type. >>>> >>>> <disk type='vhostuser' device='disk'> >>>> <source type='unix' path='/path/to/vhost-user-blk.sock' mode='client'/> >>>> <target dev='vda' bus='virtio'/> >>>> </disk> >>>> >>>> <disk type='vhostuser' device='disk'> >>>> <source type='unix' path='/path/to/vhost-user-scsi.sock' mode='client'/> >>>> <target dev='sda' bus='scsi'/> >>>> </disk> >>>> >>>> - Cole >>> >> >> >> - Cole > - Cole

1 0

[libvirt] libvirt API/design questions
by Cole Robinson 22 Dec '19

22 Dec '19

There's some pre-existing libvirt design questions I would like some feedback on, and one new one * `virsh blockresize` doesn't prevent shrink by default, couple users have blown their foot off and there's attempts at patches. https://www.redhat.com/archives/libvir-list/2019-October/msg00258.html https://www.redhat.com/archives/libvir-list/2019-November/msg00843.html Do we implement this as a protection in virsh, or change the API behavior and require a new API flag to allow shrinking? Or some other idea? * vhost-user-scsi and vhost-user-blk XML schema https://www.redhat.com/archives/libvirt-users/2019-October/msg00018.html Last proposal was using <hostdev> for this, which revisiting it now makes more sense than <disk>, because it vhost-user-X doesn't seem to use qemu's block layer at all. So vhost-user-scsi would be: <hostdev mode='subsystem' type='scsi_host'> <source protocol='vhostuser' type='unix' path='/path/to/vhost-user-scsi.sock' mode='client'/> </hostdev> vhost-user-blk maybe requires a new type='block' ? Otherwise it's unclear how to differentiate between the two. Regardless it would be nice to give the original patch author guidance here, they seemed motivated to get this working * Splitting domain_conf up. There's 30k lines in domain_conf.c and 3500 in domain_conf.h, it would be nice to unwind it a bit. Getting some sign off on this ahead of time is critical IMO so pieces can be posted and committed quickly because they will obviously go out of date fast. My thoughts: - domain_def.[ch]: DomainDefXXX and enum definitions. - probably New and Free functions too - domain_parse.[ch]: XML parsing - domain_format.[ch]: XML formatting - domain_validate.[ch]: validate and postparse handling - domain_util.[ch]: everything else, or keep it in domain_conf? domain_def should be easy but no idea how intertwined the rest are. If the domain_validate naming is acceptable for both validate and postparse functions, we could use that naming for qemu_domain.c split too. Also maybe it's worth considering if there's some way to sensibly split the conf/ directory. We could add a top level domain/ directory, but that's kinda ambiguously named as we already have network/ + storage/ + secret/ etc that have different meanings. Maybe sub dirs like conf/domain/ ? I'm curious if anyone has strong feelings either way. There's not really a clear place to dump shared DomainDef code at the moment, like possible domain_cgroup for sharing cgroup handling across lxc + qemu Thanks, Cole

4 5

[libvirt] virsh blockresize syntax is inconsistent with vol-resize and somewhat dangerous
by Tim Small 22 Dec '19

22 Dec '19

Hello, virsh has two commands which can be used to resize block devices - "blockresize" for volumes in use by and active guest, and "vol-resize" for volumes which are not in use. The vol-resize syntax allows to specify the size as a delta (increase or decrease vs. the current size), and also refuses to shrink a volume unless the "--shrink" argument is also passed. Most other tools which can be used for block device resizing (outside of libvirt) also have similar "--shrink" argument requirements when reducing the size of an existing block device. e.g. ceph requires "--allow-shrink" when using the "rbd resize" command. The lack of such a safety device makes "blockresize" a foot-gun (which I recently found to great effect when I typoed the domain name to another valid domain). It seems I am not alone in making this error e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902171 One possible solution would be to make a new command e.g. "domblkresize" or perhaps "live-resize", which implement the "--shrink" and "--delta" behaviour to make it consistent with "vol-resize" syntax, and mark the "blockresize" command as deprecated in the documentation and help (so that existing automation which depends on the current behaviour doesn't break). Any thoughts? Should I open this as an RFE? Thanks, Tim. -- South East Open Source Solutions Limited Registered in England and Wales with company number 06134732. Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309

3 3

[libvirt] [PATCH v5 0/5] qemu_process: Glib sponsored cleanup
by Daniel Henrique Barboza 20 Dec '19

20 Dec '19

changes from previous version 4 [1]: - patch 1: * moved 'dev' inside the for loop in qemuProcessHandleBlockThreshold() * moved 'id' inside the 'for' loop in qemuProcessLookupPTYs() * moved 'path' inside both conditionals in qemuProcessBuildDestroyMemoryPaths() * set 'template=NULL' in case g_mkdtemp() succeeds in qemuProcessQMPInit() - patch 2: new patch. add g_autoptr() support for qemuDomainLogContextPtr - patch 3: * using g_autoptr() on feasible virCommandPtr and * qemuDomainLogContextPtr [1] https://www.redhat.com/archives/libvir-list/2019-December/msg01311.html Daniel Henrique Barboza (5): qemu_process.c: use g_autofree qemu_domain.h: add G_DEFINE_AUTOPTR_CLEANUP_FUNC for qemuDomainLogContext qemu_process.c: use g_autoptr() qemu_process.c: remove cleanup labels after g_auto*() changes qemu_process.c: remove 'cleanup' label from qemuProcessCreatePretendCmd() src/qemu/qemu_domain.h | 1 + src/qemu/qemu_process.c | 445 +++++++++++++++------------------------- 2 files changed, 166 insertions(+), 280 deletions(-) -- 2.24.1

2 6

[libvirt] [PATCH v4 0/4] qemu_process: Glib sponsored cleanup
by Daniel Henrique Barboza 20 Dec '19

20 Dec '19

This series got buried a few months ago. Let's go onward unto the 20s with no one left behind. changes from version 3 [1]: - rebased to master at commit 330b556829 - removed former patch 4. The 'g_strdup_printf' change was made along the road - new patch 4: I am sending this one in separate to patch 3 because this unneeded label was already in the code, being unrelated to the changes of this series. The maintainer is welcome to squash it into patch 3. [1] https://www.redhat.com/archives/libvir-list/2019-October/msg01080.html Daniel Henrique Barboza (4): qemu_process.c: use g_autofree qemu_process.c: use g_autoptr() qemu_process.c: remove cleanup labels after g_auto*() changes qemu_process.c: remove 'cleanup' label from qemuProcessCreatePretendCmd() src/qemu/qemu_process.c | 429 +++++++++++++++------------------------- 1 file changed, 157 insertions(+), 272 deletions(-) -- 2.23.0

3 12

[libvirt] [PATCH] schemas: Allow additional qemu cmd line arguments/env variables and qemuCaps to be interleaved
by Michal Privoznik 20 Dec '19

20 Dec '19

While command line arguments are sort of positional (becasue you have to have two entries, one for "-arg" the other for "value"), it doesn't really matter whether env variables come before or after command line arguments. And it matter even less when playing with qemu capabilities. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/schemas/domaincommon.rng | 54 +++++++++++++++++++---------------- 1 file changed, 29 insertions(+), 25 deletions(-) diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 5f1d4a34a4..b87457382a 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -6295,37 +6295,41 @@ --> <define name="qemucmdline"> <element name="commandline" ns="http://libvirt.org/schemas/domain/qemu/1.0"> - <zeroOrMore> - <element name="arg"> - <attribute name='value'/> - </element> - </zeroOrMore> - <zeroOrMore> - <element name="env"> - <attribute name='name'> - <ref name="filter-param-name"/> - </attribute> - <optional> + <interleave> + <zeroOrMore> + <element name="arg"> <attribute name='value'/> - </optional> - <empty/> - </element> - </zeroOrMore> + </element> + </zeroOrMore> + <zeroOrMore> + <element name="env"> + <attribute name='name'> + <ref name="filter-param-name"/> + </attribute> + <optional> + <attribute name='value'/> + </optional> + <empty/> + </element> + </zeroOrMore> + </interleave> </element> </define> <define name="qemucapabilities"> <element name="capabilities" ns="http://libvirt.org/schemas/domain/qemu/1.0"> - <zeroOrMore> - <element name="add"> - <attribute name="capability"/> - </element> - </zeroOrMore> - <zeroOrMore> - <element name="del"> - <attribute name="capability"/> - </element> - </zeroOrMore> + <interleave> + <zeroOrMore> + <element name="add"> + <attribute name="capability"/> + </element> + </zeroOrMore> + <zeroOrMore> + <element name="del"> + <attribute name="capability"/> + </element> + </zeroOrMore> + </interleave> </element> </define> -- 2.24.1

3 2

[libvirt] [PATCH] util: add note about event file descriptors on Windows
by Daniel P. Berrangé 20 Dec '19

20 Dec '19

When using GNULIB with Winsock, libvirt will never see the normal HANDLE objects, instead GNULIB guarantees that libvirt gets a C runtime file descriptor. The GNULIB poll impl also expects to get C runtime file descriptors rather than HANDLE objects. Document this behaviour so that it is clear to applications providing event loop implementations if they need Windows portability. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- include/libvirt/libvirt-event.h | 4 ++++ src/util/virevent.c | 7 +++++++ 2 files changed, 11 insertions(+) diff --git a/include/libvirt/libvirt-event.h b/include/libvirt/libvirt-event.h index 734dbdcbc1..facdc3a3ec 100644 --- a/include/libvirt/libvirt-event.h +++ b/include/libvirt/libvirt-event.h @@ -67,6 +67,10 @@ typedef void (*virEventHandleCallback)(int watch, int fd, int events, void *opaq * listen for specific events. The same file handle can be registered * multiple times provided the requested event sets are non-overlapping * + * @fd will always be a C runtime file descriptor. On Windows + * the _get_osfhandle() method can be used if a HANDLE is required + * instead. + * * If the opaque user data requires free'ing when the handle * is unregistered, then a 2nd callback can be supplied for * this purpose. This callback needs to be invoked from a clean stack. diff --git a/src/util/virevent.c b/src/util/virevent.c index f6c797724e..fd5d8f5bf1 100644 --- a/src/util/virevent.c +++ b/src/util/virevent.c @@ -60,6 +60,13 @@ static virEventRemoveTimeoutFunc removeTimeoutImpl; * requires that an event loop has previously been registered with * virEventRegisterImpl() or virEventRegisterDefaultImpl(). * + * @fd must always always be a C runtime file descriptor. On Windows + * if the caller only has a HANDLE, the _open_osfhandle() method can + * be used to open an associated C runtime file descriptor for use + * with this API. After opening a runtime file descriptor, CloseHandle() + * must not be used, instead close() will close the runtime file + * descriptor and its original associated HANDLE. + * * Returns -1 if the file handle cannot be registered, otherwise a handle * watch number to be used for updating and unregistering for events. */ -- 2.21.0

2 1

[libvirt] [PATCH v2 0/2] Initialize host boot time global var upfront
by Michal Privoznik 20 Dec '19

20 Dec '19

This is a v2 for: https://www.redhat.com/archives/libvir-list/2019-December/msg01045.html While technically v1 was fixed I agree with Cole's suggestion, so I'm discarding v1 and sending another version which implements his suggestion. Michal Prívozník (2): virhostuptime: Introduce virHostBootTimeInit() remote_daemon: Initialize host boot time global variable src/libvirt_private.syms | 1 + src/remote/remote_daemon.c | 9 +++++++++ src/util/virhostuptime.c | 13 ++++++++++++- src/util/virhostuptime.h | 3 +++ 4 files changed, 25 insertions(+), 1 deletion(-) -- 2.24.1

3 4

[libvirt] [PATCH v2 0/3] store binary name in capabilities
by Daniel P. Berrangé 20 Dec '19

20 Dec '19

2 5

[libvirt] [PATCH] news: document phyp removal
by Cole Robinson 20 Dec '19

20 Dec '19

Signed-off-by: Cole Robinson <crobinso(a)redhat.com> --- docs/news.xml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index 055353b9a5..1af57f8af0 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -99,6 +99,16 @@ Python 2 binary. Python 3 must be used instead. </description> </change> + <change> + <summary> + 'phyp' Power Hypervisor driver removed + </summary> + <description> + The 'phyp' Power Hypervisor driver has not seen active development + since 2011 and does not seem to have any real world usage. It + has now been removed. + </description> + </change> </section> </release> <release version="v5.10.0" date="2019-12-02"> -- 2.23.0

2 1

[libvirt] i want to update the disk driver from ide to virtio, but fail , why ?
by thomas 20 Dec '19

20 Dec '19

hi, ALL: my question description as follow: virsh dumpxml root-vsys_v2 > v2.xml , in the v2.xml has the following information: <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/home/root-vsys_v2.qcow2'/> <backingStore/> <target dev='hda' bus='ide'/> // i want change the 'ide' to 'virtio', but fail <alias name='ide0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> so i create a new xml name v2-new.xml ,it content is: <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/home/root-vsys_v2.qcow2'/> <target dev='vda' bus='virtio'/> </disk> then run: virsh update-device root-vsys_v2 /root/v2-new.xml --live the result is: [root@NSG ~]# virsh update-device root-vsys_v2 /root/v2-new.xml --live error: Failed to update device from /root/v2-new.xml error: internal error: No device with bus 'virtio' and target 'vda' i read the source code for libvirt ,the log outprint at funcion: static int qemuDomainChangeDiskLive(virDomainObjPtr vm, virDomainDeviceDefPtr dev, virQEMUDriverPtr driver, bool force) { virDomainDiskDefPtr disk = dev->data.disk; virDomainDiskDefPtr orig_disk = NULL; virDomainDeviceDef oldDev = { .type = dev->type }; int ret = -1; if (!(orig_disk = virDomainDiskFindByBusAndDst(vm->def, disk->bus, disk->dst))) { virReportError(VIR_ERR_INTERNAL_ERROR, _("No device with bus '%s' and target '%s'"), virDomainDiskBusTypeToString(disk->bus), disk->dst); //the failure log is here, the vm->def has disk item :dev = hda, bus=ide ,and disk->bus = virtio disk->dst=vda, goto cleanup; } //the disk->bus and disk->dst can't in the vm->def ,so the api virDomainDiskFindByBusAndDst failed oldDev.data.disk = orig_disk; if (virDomainDefCompatibleDevice(vm->def, dev, &oldDev, VIR_DOMAIN_DEVICE_ACTION_UPDATE, true) < 0) goto cleanup; if (!qemuDomainDiskChangeSupported(disk, orig_disk)) goto cleanup; if (!virStorageSourceIsSameLocation(disk->src, orig_disk->src)) { /* Disk source can be changed only for removable devices */ if (disk->device != VIR_DOMAIN_DISK_DEVICE_CDROM && disk->device != VIR_DOMAIN_DISK_DEVICE_FLOPPY) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("disk source can be changed only in removable " "drives")); goto cleanup; } if (qemuDomainAttachDeviceDiskLive(driver, vm, dev, force) < 0) goto cleanup; } orig_disk->startupPolicy = dev->data.disk->startupPolicy; orig_disk->snapshot = dev->data.disk->snapshot; ret = 0; cleanup: return ret; } what reason lead the faiure ? is my v2-new.xml write error ? how to write the xml for virsh update-device ? i refer the link https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/ht… -------------------------- thanks ! thosmas.kuang

2 2

[libvirt] [PATCH 0/7] introduce support for an embedded driver mode
by Daniel P. Berrangé 20 Dec '19

20 Dec '19

This is a followup to: https://www.redhat.com/archives/libvir-list/2019-May/msg00467.html This series implements support for an embedded driver mode for libvirt, with initial support in the QEMU and secrets drivers. In this mode of operation, the driver stores all its config and state under a private directory tree. See the individual patches for the illustrated directory hierarchy used. The intent of this embedded mode is to suit cases where the application is using virtualization as a building block for some functionality, as opposed to running traditional "full OS" builds. The long time posterchild example would be libguestfs, while a more recent example could be Kata containers. The general principal in enabling this embedded mode is that the functionality available should be identical to that seen when the driver is running inside libvirtd. This is achieved by loading the exact same driver .so module as libvirtd would load, and simply configuring it with a different directory layout. The result of this is that when running in embedded mode, the driver can still talk to other secondary drivers running inside libvirtd if desired. This is useful, for example, to connect a VM to the default virtual network. The secondary drivers can be made to operate in embedded mode as well, however, this will require some careful consideration for each driver to ensure they don't clash with each other. Thus in this series only the secret driver is enabled for embedded mode. This is required to enable use of VMs with encrypted disks, or authenticated network block storage. In this series we introduce a new command line tool 'virt-qemu-run' which is a really simple tool for launching a VM in embedded mode. I'm not entirely sure whether we should provide this as an official supported tool in this way, or merely put it into the 'examples' directory as demo-ware. With testing of the virt-qemu-run tool we can immediately see what the next important thing to tackle is: performance. We have not really cared too much about the startup performance of libvirtd as this is a one time cost when the mgmt application connects. We did none the less cache capabilities because probing caps for 30 QEMU binaries takes a long time. Even with this caching it takes an unacceptably long time to start a VM in embedded mode. About 100 ms to open the embedded QEMU driver, assuming pre-cached capabilies - ~2 seconds if not cached and all 30 QEMU targets are present. Then about 300 ms to actually start the QEMU guest. IOW, about 400 ms to get QEMU running. NB this is measuring time from launching the virt-run-qemu program, to the point at which the API call 'virDomainCreate' returns control. This has both libvirt & QEMU overhead in & I don't have clear figures to distinguish, but I can see a 40 ms delay between issuing the 'qmp_capabilities' call and getting a reply, which is QEMU startup overead. This is a i440fx based QEMU with a general purpose virtio-pci config (disk, net, etc) tyupical for running a full OS. I've not tried any kind of optimized QEMU config with microvm. I've already started on measuring & optimizing & identified several key areas that can be addressed, but it is all ultimately about not doing work before we need the answers from that work (which often means we will never do the work at all). For example, we shouldn't probe all 30 QEMU's upfront. If the app is only going to create an x86_64 KVM guest we should only care about that 1 QEMU. This is painful because parsing any guest XML requires a virCapsPtr which in turn causes probing of every QEMU binary. I've got in progress patches to eliminate virCapsPtr almost entirely and work directly with the virQEMUCapsPtr instead. It is possible we'll want to use a different file format for storing the cached QEMU capabilities, and the CPU feature/model info. Parsing this XML is a non-negligible time sink. A binary format is likely way quicker, especially if its designed to be just mmap'able for direct read. To be investigated... We shouldn't probe for whether host PM suspend is possible unless someone wants that info, or tries to issue that API call. After starting QEMU we spend 150-200 ms issuing a massive number of qom-get calls to check whether QEMU enabled each individual CPU feature flag. We only need this info if someone asks for the live XML or we intend to live migrate etc. So we shouldn't issue these qom-get calls in the "hot path" of QEMU startup. It can be done later in a non-time critical point. Also the QEMU API for this is horribly inefficient to require so many qom-get calls. There's more but I won't talk about it now. Suffice to say that I think we can get libvirt overhead down to less than 100 ms fairly easily and probably even down to less than 50 ms without much effort. The exact figure will depend on what libvirt features you want enabled, and how much work we want/need to put into optimization. We'll want to fix the really gross mistakes & slow downs, but we'll want guidance from likely users as to their VM startup targets to decide how much work needs investing. This optimization will ultimately help non-embedded QEMU mode too, making it faster to respond & start. Changed in v2: - Use a simplified directory layout for embedded mode. Previously we just put a dir prefix onto the normal paths. This has the downside that the embedded drivers paths are needlessly different for privileged vs unprivileged user. It also results in very long paths which can be a problem for the UNIX socket name length limits. - Also ported the secret driver to support embedded mode - Check to validate that the event loop is registered. - Add virt-qemu-run tool for embedded usage. - Added docs for the qemu & secret driver explaining embedded mode Daniel P. Berrangé (7): access: report an error if no access manager is present libvirt: pass a directory path into drivers for embedded usage event: add API for requiring an event loop impl to be registered libvirt: support an "embed" URI path selector for opening drivers qemu: add support for running QEMU driver in embedded mode secrets: add support for running secret driver in embedded mode qemu: introduce a new "virt-qemu-run" program build-aux/syntax-check.mk | 2 +- docs/drivers.html.in | 1 + docs/drvqemu.html.in | 84 +++++++ docs/drvsecret.html.in | 82 +++++++ libvirt.spec.in | 2 + po/POTFILES.in | 1 + src/Makefile.am | 9 + src/access/viraccessmanager.c | 5 + src/driver-state.h | 2 + src/driver.h | 2 + src/interface/interface_backend_netcf.c | 7 + src/interface/interface_backend_udev.c | 7 + src/libvirt.c | 93 ++++++- src/libvirt_internal.h | 4 +- src/libxl/libxl_driver.c | 7 + src/lxc/lxc_driver.c | 8 + src/network/bridge_driver.c | 7 + src/node_device/node_device_hal.c | 7 + src/node_device/node_device_udev.c | 7 + src/nwfilter/nwfilter_driver.c | 7 + src/qemu/Makefile.inc.am | 26 ++ src/qemu/qemu_conf.c | 38 ++- src/qemu/qemu_conf.h | 6 +- src/qemu/qemu_driver.c | 21 +- src/qemu/qemu_process.c | 15 +- src/qemu/qemu_shim.c | 313 ++++++++++++++++++++++++ src/qemu/qemu_shim.pod | 94 +++++++ src/remote/remote_daemon.c | 1 + src/remote/remote_driver.c | 1 + src/secret/secret_driver.c | 41 +++- src/storage/storage_driver.c | 7 + src/util/virevent.c | 25 ++ src/util/virevent.h | 2 + src/vz/vz_driver.c | 7 + tests/domaincapstest.c | 2 +- tests/testutilsqemu.c | 2 +- 36 files changed, 920 insertions(+), 25 deletions(-) create mode 100644 docs/drvsecret.html.in create mode 100644 src/qemu/qemu_shim.c create mode 100644 src/qemu/qemu_shim.pod -- 2.23.0

3 16

[libvirt] [PATCH 00/42] Cleanups after adopting g_get_*_dir()
by Fabiano Fidêncio 20 Dec '19

20 Dec '19

After adopting g_get_*_dir(), internally, when implementing virGetUser*Dir(), the libvirt functions changed their behaviour as NULL is never ever returned by the GLib functions. Knowing that, let's cleanup the callers' code of those functions, removing the unnecessary checks. While doing the cleanup mentioned above, I've noticed that some other cleanups could be done, when touching the very same function, as using g_autofree. It's done as part of this series as well. phyp driver was not touched as there's some plan to just drop its code entirely: https://www.redhat.com/archives/libvir-list/2019-December/msg01162.html Fabiano Fidêncio (42): tools: Use g_autofree on cmdCd() vbox: Don't leak virGetUserDirectory()'s output rpc: Use g_autofree on virNetClientNewLibSSH2() rpc: Use g_autofree on virNetClientNewLibssh() rpc: Don't check the output of virGetUserDirectory() qemu: Don't check the output of virGetUserDirectory() util: Don't check the output of virGetUserConfigDirectory() storage: Don't check the output of virGetUserConfigDirectory() secret: Don't check the output of virGetUserConfigDirectory() tools: Don't check the output of virGetUserCacheDirectory() vbox: Use g_autofree on vboxDomainScreenshot() vbox: Don't check the output of virGetUserCacheDirectory() util: Use g_autofree on virLogSetDefaultOutputToFile() util: Don't check the output of virGetUserCacheDirectory() qemu: Don't check the output of virGetUserCacheDirectory() rpc: Don't check the output of virGetUserConfigDirectory() remote: Don't check the output of virGetUserConfigDirectory() qemu: Don't check the output of virGetUserConfigDirectory() network: Don't check the output of virGetUserConfigDirectory() logging: Use g_autofree on virLogDaemonConfigFilePath() logging: Don't check the output of virGetUserConfigDirectory() locking: Use g_autofree on virLockDaemonConfigFilePath() locking: Don't check the output of virGetUserConfigDirectory() util: Don't check the output of virGetUserRuntimeDirectory() storage: Don't check the output of virGetUserRuntimeDirectory() secret: Don't check the output of virGetUserRuntimeDirectory() rpc: Don't check the output of virGetUserRuntimeDirectory() remote: Don't check the output of virGetUserRuntimeDirectory() qemu: Don't check the output of virGetUserRuntimeDirectory() node_device: Don't check the output of virGetUserRuntimeDirectory() network: Don't check the output of virGetUserRuntimeDirectory() logging: Use g_autofree on virLogManagerDaemonPath() logging: Use g_autofree on virLogDaemonUnixSocketPaths() logging: Use g_autofree on virLogDaemonExecRestartStatePath() logging: Don't check the output of virGetUserRuntimeDirectory() locking: Use g_autofree on virLockManagerLockDaemonPath() locking: Use g_autofree on virLockDaemonUnixSocketPaths() locking: Use g_autofree on virLockDaemonExecRestartStatePath() locking: Don't check the output of virGetUserRuntimeDirectory() interface: Don't check the output of virGetUserRuntimeDirectory() admin: Use g_autofree on getSocketPath() admin: Don't check the output of virGetUserRuntimeDirectory() src/admin/libvirt-admin.c | 6 +-- src/interface/interface_backend_netcf.c | 3 +- src/interface/interface_backend_udev.c | 3 +- src/locking/lock_daemon.c | 31 +++---------- src/locking/lock_daemon_config.c | 9 +--- src/locking/lock_driver_lockd.c | 7 +-- src/logging/log_daemon.c | 31 +++---------- src/logging/log_daemon_config.c | 9 +--- src/logging/log_manager.c | 7 +-- src/network/bridge_driver.c | 2 - src/node_device/node_device_hal.c | 3 +- src/node_device/node_device_udev.c | 3 +- src/qemu/qemu_conf.c | 7 +-- src/qemu/qemu_interop_config.c | 3 -- src/remote/remote_daemon.c | 8 +--- src/remote/remote_daemon_config.c | 6 +-- src/remote/remote_driver.c | 3 +- src/rpc/virnetclient.c | 59 +++++++++---------------- src/rpc/virnetsocket.c | 3 +- src/rpc/virnettlscontext.c | 12 ----- src/secret/secret_driver.c | 6 +-- src/storage/storage_driver.c | 2 - src/util/virauth.c | 3 +- src/util/virconf.c | 2 - src/util/virhostdev.c | 3 +- src/util/virlog.c | 13 ++---- src/util/virpidfile.c | 3 +- src/vbox/vbox_common.c | 12 ++--- src/vbox/vbox_storage.c | 7 ++- tools/vsh.c | 13 ++---- 30 files changed, 73 insertions(+), 206 deletions(-) -- 2.24.1

5 100

[libvirt] [PATCH] cpu: add CLZERO CPUID support for AMD platforms
by Ani Sinha 20 Dec '19

20 Dec '19

Qemu commit e900135dcfb67 ("i386: Add CPUID bit for CLZERO and XSAVEERPTR") adds support for CLZERO CPUID bit. This commit extends support for this CPUID bit into libvirt. Signed-off-by: Ani Sinha <ani.sinha(a)nutanix.com> --- src/cpu_map/x86_EPYC-IBPB.xml | 1 + src/cpu_map/x86_EPYC.xml | 1 + src/cpu_map/x86_features.xml | 3 +++ 3 files changed, 5 insertions(+) diff --git a/src/cpu_map/x86_EPYC-IBPB.xml b/src/cpu_map/x86_EPYC-IBPB.xml index 283697e..a70fbd8 100644 --- a/src/cpu_map/x86_EPYC-IBPB.xml +++ b/src/cpu_map/x86_EPYC-IBPB.xml @@ -14,6 +14,7 @@ <feature name='bmi2'/> <feature name='clflush'/> <feature name='clflushopt'/> + <feature name='clzero'/> <feature name='cmov'/> <feature name='cr8legacy'/> <feature name='cx16'/> diff --git a/src/cpu_map/x86_EPYC.xml b/src/cpu_map/x86_EPYC.xml index f060139..6c11d82 100644 --- a/src/cpu_map/x86_EPYC.xml +++ b/src/cpu_map/x86_EPYC.xml @@ -14,6 +14,7 @@ <feature name='bmi2'/> <feature name='clflush'/> <feature name='clflushopt'/> + <feature name='clzero'/> <feature name='cmov'/> <feature name='cr8legacy'/> <feature name='cx16'/> diff --git a/src/cpu_map/x86_features.xml b/src/cpu_map/x86_features.xml index 2bed1e0..dd62755 100644 --- a/src/cpu_map/x86_features.xml +++ b/src/cpu_map/x86_features.xml @@ -473,6 +473,9 @@ <feature name='ibpb'> <cpuid eax_in='0x80000008' ebx='0x00001000'/> </feature> + <feature name='clzero'> + <cpuid eax_in='0x80000008' ebx='0x00000001'/> + </feature> <feature name='amd-ssbd'> <cpuid eax_in='0x80000008' ebx='0x01000000'/> </feature> -- 1.9.4

2 2

[libvirt] [PATCH] AUTHORS: Add Fabiano Fidêncio
by Ján Tomko 19 Dec '19

19 Dec '19

$ git log --committer=fidencio --pretty=oneline | wc -l 12 Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- Déjà vu from c379576dbc80a66820e256f9ce27595270d95ac2 except the mailmap entry is already set up. AUTHORS.in | 1 + 1 file changed, 1 insertion(+) diff --git a/AUTHORS.in b/AUTHORS.in index fbac54c48d..4ed8ceb858 100644 --- a/AUTHORS.in +++ b/AUTHORS.in @@ -19,6 +19,7 @@ Daniel Veillard <veillard(a)redhat.com> Doug Goldstein <cardoe(a)gentoo.org> Eric Blake <eblake(a)redhat.com> Erik Skultety <eskultet(a)redhat.com> +Fabiano Fidêncio <fidencio(a)redhat.com> Gao Feng <gaofeng(a)cn.fujitsu.com> Guido Günther <agx(a)sigxcpu.org> Ján Tomko <jtomko(a)redhat.com> -- 2.21.0

3 2