- Devel - libvirt List Archives

[PATCH 0/3] virsh: Completers improvements
by Michal Privoznik 15 Mar '22

15 Mar '22

*** BLURB HERE *** Michal Prívozník (3): virsh: Properly terminate string list in virshDomainInterfaceSourceModeCompleter() virsh: Introduce virshEnumComplete() virsh: Don't open code virshEnumComplete() tools/virsh-completer-domain.c | 147 ++++++-------------------------- tools/virsh-completer-host.c | 11 +-- tools/virsh-completer-nodedev.c | 7 +- tools/virsh-completer-pool.c | 7 +- tools/virsh-completer-volume.c | 11 +-- tools/virsh-completer.c | 27 ++++++ tools/virsh-completer.h | 4 + 7 files changed, 67 insertions(+), 147 deletions(-) -- 2.34.1

2 4

REST service for libvirt to simplify SEV(ES) launch measurement
by Daniel P. Berrangé 14 Mar '22

14 Mar '22

Extending management apps using libvirt to support measured launch of QEMU guests with SEV/SEV-ES is unreasonably complicated today, both for the guest owner and for the cloud management apps. We have APIs for exposing info about the SEV host, the SEV guest, guest measurements and secret injections. This is a "bags of bits" solution. We expect apps to them turn this into a user facting solution. It is possible but we're heading to a place where every cloud mgmt app essentially needs to reinvent the same wheel and the guest owner will need to learn custom APIs for dealing with SEV/SEV-ES for each cloud mgmt app. This is pretty awful. We need to do a better job at providing a solution that is more general purpose IMHO. Consider a cloud mgmt app, right now the flow to use the bag of bits libvirt exposes, looks something like * Guest owner tells mgmt app they want to launch a VM * Mgmt app decides what host the VM will be launched on * Guest owner requests cert chain for the virt host from mgmt app * Guest owner validates cert chain for the virt host * Guest owner generates launch blob for the VM * Guest owner provides launch blob to the mgmt app * Management app tells libvirt to launch VM with blob, with CPUs in a paused state * Libvirt luanches QEMU with CPUs stopped * Guest owner requests launch measurement from mgmt app * Guest owner validates measurement * Guest owner generates secret blob * Guest owner sends secret blob to management app * Management app tells libvirt to inject secrets * Libvirt injects secrets to QEMU * Management app tells libvirt to start QEMU CPUs * Libvirt tells QEMU to start CPUs Compare to a non-confidental VM * Guest owner tells mgmt app they want to launch a VM * Mgmt app decides what host the VM will be launched on * Mgmt app tells libvirt to launch VM with CPUs in running state * Libvirt launches QEMU with CPUs running Now, of course the guest owner wouldn't be manually performing the earlier steps, they would want some kind of software to take care of this. No matter what, it still involves a large number of back and forth operations between the guest owner & mgmt app, and between the mgmt app and libvirt. One of libvirt's key jobs is to isolate mgmt apps from differences in behaviour of underlying hypervisor technologies, and we're failing at that job with SEV/SEV-ES, because the mgmt app needs to go through a multi-stage dance on every VM start, that is different from what they do with non-confidential VMs. It is especially unpleasant because there needs to be a "wait state" between when the app selects a host to deploy a VM on, and when it can actually start a VM. In essence the app needs to reserve capacity on a host ahead of time for a VM that will be created some arbitrary time later. This can have significant implications for the mgmt app architectural design that are not neccessarily easy to address, when they expect to just call virDomainCreate have the VM running in one step. It also harms interoperability to libvirt tools. For example if a mgmt tool like virt-manager/OpenStack created a VM using SEV, and you want to start it manually using a different tool like 'virsh', you enter a world of complexity and pain, due to the multi step dance required. AFAICT, in all of this, the mgmt app is really acting as a conduit and is not implementing any interesting logic. The clever stuff is all the responsibility of the guest owner, and/or whatever software for attestation they are using remotely. I think there is scope for enhancing libvirt, such that usage of SEV/SEV-ES has little-to-no burden for the management apps, and much less burden for guest owners. The key to achieving this is to define a protocol for libvirt to connect to a remote service to handle the launch measurements & secret acquisition. The guest owner can provide the address of a service they control (or trust), and libvirt can take care of all the interactions with it. This frees both the user and mgmt app from having to know much about SEV/SEV-ES, with VM startup process being essentially the same as it has always been. The sequence would look like * Guest owner tells attestation service they intend to create a VM with a given UUID, policy, and any other criteria such as cert of the cloud owner, valid OVMF firmware hashes, and providing any needed LUKS keys. * Guest owner tells mgmt app they want to launch a VM, using attestation service at https://somehost/and/url * Mgmt app decides what host the VM will be launched on * Mgmt app tells libvirt to launch VM with CPUs in running state The next steps involve solely libvirt & the attestation service. The mgmt app and guest owner have done their work. * Libvirt contacts the service providing certificate chain for the host to be used, the UUID of the guest, and any other required info about the host. * Attestation service validates the cert chain to ensure it belongs to the cloud owner that was identified previously * Attestation service generates a launch blob and puts it in the response back to libvirt * Libvirt launches QEMU with CPUs paused * Libvirt gets the launch measurement and sends it to the attestation server, with any other required info about the VM instance * Attestation service validates the measurement * Attestation builds the secret table with LUKS keys and puts it in the response back to libvirt * Libvirt injects the secret table to QEMU * Libvirt tells QEMU to start CPUs All the same exchanges of information are present, but the management app doesn't have to get involved. The guest owner also doesn't have to get involved except for a one-time setup step. The software the guest owner uses for attestation also doesn't have to be written to cope with talking to OpenStack, CNV and whatever other vendor specific cloud mgmt apps exist today. This will significantly reduce the burden if supporting SEV/SEV-ES launch measurement in libvirt based apps, and make SEV/SEV-ES guests more "normal" from a mgmt POV. What could this look like from POV of an attestation server API, if we assume HTTPS REST service with a simple JSON payload ... * Guest Owner: Register a new VM to be booted: POST /vm/<UUID> Request body: { "scheme": "amd-sev", "cloud-cert": "certificate of the cloud owner that signs the PEK", "policy": 0x3, "cpu-count": 3, "firmware-hashes": [ "xxxx", "yyyy", ], "kernel-hash": "aaaa", "initrd-hash": "bbbb", "cmdline-hash": "cccc", "secrets": [ { "type": "luks-passphrase", "passphrase": "<blah>" } ] } * Libvirt: Request permission to launch a VM on a host POST /vm/<UUID>/launch Request body: { "pdh": "<blah>", "cert-chain": "<blah>", "cpu-id": "<CPU ID>", ...other relevant bits... } Service decides if the proposed host is acceptable Response body (on success) { "session": "<blah>", "owner-cert": "<blah>", "policy": 3, } * Libvirt: Request secrets to inject to launched VM POST /vm/<UUID>/validate Request body: { "api-minor": 1, "api-major": 2, "build-id": 241, "policy": 3, "measurement": "<blah>", "firmware-hash": "xxxx", "cpu-count": 3, ....other relevant stuff.... } Service validates the measurement... Response body (on success): { "secret-header": "<blah>", "secret-table": "<blah>", } So we can see there are only a couple of REST API calls we need to be able to define. If we could do that then creating a SEV/SEV-ES enabled guest with libvirt would not involve anything more complicated for the mgmt app that providing the URI of the guest owner's attestation service and an identifier for the VM. ie. the XML config could be merely: <launchSecurity type="sev"> <attestation vmid="57f669c2-c427-4132-bc7a-26f56b6a718c" service="http://somehost/some/url"/> </launchSecurity> And then involve virDomainCreate as normal with any other libvirt / QEMU guest. No special workflow is required by the mgmt app. There is a small extra task for the guest owner to register existance of their VM with the attestation service. Aside from that the only change to the way they interact with the cloud mgmt app is to provide the VM ID and URI for the attestation service. No need to learn custom APIs for each different cloud vendor, for dealing with fetching launch measurements or injecting secrets. Finally this attestation service REST protocol doesn't have to be something controlled or defined by libvirt. I feel like it could be a protocol that is defined anywhere and libvirt merely be one consumer of it. Other apps that directly use QEMU may also wish to avail themselves of it. All that really matters from libvirt POV is: - The protocol definition exist to enable the above workflow, with a long term API stability guarantee that it isn't going to changed in incompatible ways - There exists a fully open source reference implementation of sufficient quality to deploy in the real world I know https://github.com/slp/sev-attestation-server exists, but its current design has assumptions about it being used with libkrun AFAICT. I have heard of others interested in writing similar servers, but I've not seen code. We are at a crucial stage where mgmt apps are looking to support measured boot with SEV/SEV-ES and if we delay they'll all go off and do their own thing, and it'll be too late, leading to https://xkcd.com/927/. Especially for apps using libvirt to manage QEMU, I feel we have got a few months window of opportunity to get such a service available, before they all end up building out APIs for the tedious manual workflow, reinventing the wheel. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

5 12

[PATCH 0/2] qemu_namespace: Two simple improvements
by Michal Privoznik 14 Mar '22

14 Mar '22

These are inspired by Nikola's question here: https://listman.redhat.com/archives/libvir-list/2022-February/228812.html See my reply here: https://listman.redhat.com/archives/libvir-list/2022-March/229263.html Michal Prívozník (2): qemu_namespace: Don't unlink paths from cgroupDeviceACL qemu_namespace: Be less aggressive in removing /dev nodes from namespace src/qemu/qemu_namespace.c | 92 +++++++++++++++++++++++++++------------ 1 file changed, 63 insertions(+), 29 deletions(-) -- 2.34.1

2 3

[PATCH v3 00/29] ppc64 PowerNV machines support
by Daniel Henrique Barboza 14 Mar '22

14 Mar '22

Hi, This new version contains changes proposed by Jano. The most notable change is on patch 9, where pnv_pnv3/pnv_phb4 capabilities are now being probed and, if the QEMU version isn't high enough, they are cleared from qemuCaps. For convenience, the patches that are pending review/acks are patches 14, 17, 19, 20, 22, 23 and 24. v2 link: https://listman.redhat.com/archives/libvir-list/2022-January/msg01149.html Daniel Henrique Barboza (29): qemu_domain.c: add PowerNV machine helpers qemu_capabilities.c: use 'MachineIsPowerPC' in DeviceDiskCaps qemu_domain: turn qemuDomainMachineIsPSeries() static qemu_validate.c: use qemuDomainIsPowerPC() in qemuValidateDomainChrDef() qemu_domain.c: define ISA as default PowerNV serial qemu_validate.c: enhance 'machine type not supported' message qemu_domain.c: disable default devices for PowerNV machines tests: add basic PowerNV8 test qemu: introduce QEMU_CAPS_DEVICE_PNV_PHB3 conf, qemu: add 'pnv-phb3-root-port' PCI controller model name conf, qemu: add 'pnv-phb3' PCI controller model name domain_conf.c: fix identation in virDomainControllerDefParseXML() conf: parse and format <target chip-id='...'/> formatdomain.rst: add 'index' semantics for PowerNV domains conf: introduce virDomainControllerIsPowerNVPHB conf, qemu: add default 'chip-id' value for pnv-phb3 controllers conf, qemu: add default 'targetIndex' value for pnv-phb3 devs qemu_command.c: add command line for the pnv-phb3 device qemu_domain_address.c: change pnv-phb3 minimal downstream slot domain_conf: always format pnv-phb3-root-port address tests: add pnv-phb3-root-port test domain_validate.c: allow targetIndex 0 out of idx 0 for PowerNV PHBs domain_conf.c: reject duplicated pnv-phb3 devices qemu: introduce QEMU_CAPS_DEVICE_PNV_PHB4 conf, qemu: add 'pnv-phb4-root-port' PCI controller model name domain_conf.c: add phb4-root-port to IsPowerNVRootPort() conf, qemu: add 'pnv-phb4' controller model name domain_conf.c: add pnv-phb4 to ControllerIsPowerNVPHB() tests: add PowerNV9 tests docs/formatdomain.rst | 12 +- docs/schemas/domaincommon.rng | 10 ++ src/conf/domain_conf.c | 156 ++++++++++++++---- src/conf/domain_conf.h | 8 + src/conf/domain_validate.c | 5 +- src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 19 ++- src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_command.c | 21 ++- src/qemu/qemu_domain.c | 51 +++++- src/qemu/qemu_domain.h | 4 +- src/qemu/qemu_domain_address.c | 64 ++++++- src/qemu/qemu_validate.c | 62 ++++++- .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 2 + .../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 2 + .../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 2 + .../qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 2 + .../powernv8-basic.ppc64-latest.args | 34 ++++ tests/qemuxml2argvdata/powernv8-basic.xml | 16 ++ tests/qemuxml2argvdata/powernv8-dupPHBs.err | 1 + .../powernv8-dupPHBs.ppc64-latest.err | 1 + tests/qemuxml2argvdata/powernv8-dupPHBs.xml | 27 +++ .../powernv8-root-port.ppc64-latest.args | 35 ++++ tests/qemuxml2argvdata/powernv8-root-port.xml | 17 ++ .../powernv8-two-sockets.ppc64-latest.args | 35 ++++ .../qemuxml2argvdata/powernv8-two-sockets.xml | 26 +++ .../powernv9-dupPHBs.ppc64-latest.err | 1 + tests/qemuxml2argvdata/powernv9-dupPHBs.xml | 27 +++ .../powernv9-root-port.ppc64-latest.args | 35 ++++ tests/qemuxml2argvdata/powernv9-root-port.xml | 17 ++ tests/qemuxml2argvtest.c | 7 + .../powernv8-basic.ppc64-latest.xml | 34 ++++ .../powernv8-root-port.ppc64-latest.xml | 39 +++++ .../powernv8-two-sockets.ppc64-latest.xml | 39 +++++ .../powernv9-root-port.ppc64-latest.xml | 39 +++++ .../qemuxml2xmloutdata/powernv9-root-port.xml | 36 ++++ tests/qemuxml2xmltest.c | 5 + 37 files changed, 848 insertions(+), 48 deletions(-) create mode 100644 tests/qemuxml2argvdata/powernv8-basic.ppc64-latest.args create mode 100644 tests/qemuxml2argvdata/powernv8-basic.xml create mode 100644 tests/qemuxml2argvdata/powernv8-dupPHBs.err create mode 100644 tests/qemuxml2argvdata/powernv8-dupPHBs.ppc64-latest.err create mode 100644 tests/qemuxml2argvdata/powernv8-dupPHBs.xml create mode 100644 tests/qemuxml2argvdata/powernv8-root-port.ppc64-latest.args create mode 100644 tests/qemuxml2argvdata/powernv8-root-port.xml create mode 100644 tests/qemuxml2argvdata/powernv8-two-sockets.ppc64-latest.args create mode 100644 tests/qemuxml2argvdata/powernv8-two-sockets.xml create mode 100644 tests/qemuxml2argvdata/powernv9-dupPHBs.ppc64-latest.err create mode 100644 tests/qemuxml2argvdata/powernv9-dupPHBs.xml create mode 100644 tests/qemuxml2argvdata/powernv9-root-port.ppc64-latest.args create mode 100644 tests/qemuxml2argvdata/powernv9-root-port.xml create mode 100644 tests/qemuxml2xmloutdata/powernv8-basic.ppc64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/powernv8-root-port.ppc64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/powernv8-two-sockets.ppc64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/powernv9-root-port.ppc64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/powernv9-root-port.xml -- 2.35.1

1 30

[PATCH] scripts: Fix the parameter of warning function
by luzhipeng 14 Mar '22

14 Mar '22

The parameter of self.warning is inconsistent with it's definition, So fix it. Signed-off-by: luzhipeng <luzhipeng(a)cestc.cn> --- scripts/apibuild.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/apibuild.py b/scripts/apibuild.py index bdd3077c48..99b16f47fa 100755 --- a/scripts/apibuild.py +++ b/scripts/apibuild.py @@ -317,7 +317,7 @@ class index: if type in type_map: type_map[type][name] = d else: - self.warning("Unable to register type ", type) + self.warning("Unable to register type %s" % type) if name == debugsym and not quiet: print("New symbol: %s" % (d)) -- 2.34.0.windows.1

1 0

[PATCH 0/1]scripts: Fix the parameter of warning function
by luzhipeng 14 Mar '22

14 Mar '22

luzhipeng (1): scripts: Fix the parameter of warning function scripts/apibuild.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.0.windows.1

2 2

[PATCH] scripts: Fix the parameter of warning function
by luzhipeng 14 Mar '22

14 Mar '22

--- scripts/apibuild.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/apibuild.py b/scripts/apibuild.py index bdd3077c48..99b16f47fa 100755 --- a/scripts/apibuild.py +++ b/scripts/apibuild.py @@ -317,7 +317,7 @@ class index: if type in type_map: type_map[type][name] = d else: - self.warning("Unable to register type ", type) + self.warning("Unable to register type %s" % type) if name == debugsym and not quiet: print("New symbol: %s" % (d)) -- 2.34.0.windows.1

1 0

[PATCH 0/3] qemu: Introduce 'manual' snapshot mode for storage providers not managed by libvirt
by Peter Krempa 14 Mar '22

14 Mar '22

Peter Krempa (3): conf: snapshot: Introduce 'manual' mode for snapshot of a disk qemuSnapshotCreateActiveExternal: Implement manual snapshot mode kbase: Introduce 'snapshots' page and describe the new 'manual' snapshot docs/formatdomain.rst | 15 +++++----- docs/formatsnapshot.rst | 9 ++++++ docs/kbase/index.rst | 3 ++ docs/kbase/meson.build | 1 + docs/kbase/snapshots.rst | 53 +++++++++++++++++++++++++++++++++ docs/schemas/domainsnapshot.rng | 3 ++ src/conf/domain_conf.c | 1 + src/conf/domain_conf.h | 1 + src/conf/snapshot_conf.c | 6 ++++ src/qemu/qemu_snapshot.c | 24 +++++++++++---- src/test/test_driver.c | 17 +++++++++++ 11 files changed, 121 insertions(+), 12 deletions(-) create mode 100644 docs/kbase/snapshots.rst -- 2.35.1

2 5

[libvirt PATCH] docs: downloads: fix link to libvirt GitLab group
by Ján Tomko 11 Mar '22

11 Mar '22

s/libvirt.org/libvirt/ Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- docs/downloads.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Pushed as trivial. diff --git a/docs/downloads.rst b/docs/downloads.rst index d438166b78..e32fd1ba99 100644 --- a/docs/downloads.rst +++ b/docs/downloads.rst @@ -314,7 +314,7 @@ GIT source repository --------------------- All modules maintained by the libvirt project have their primary source -available in the `libvirt group on GitLab <https://gitlab.com/libvirt.org/>`__. +available in the `libvirt group on GitLab <https://gitlab.com/libvirt/>`__. Each module can be cloned anonymously using: :: -- 2.35.1

1 0

[RFC patch 0/2] nwfilter: don't query netfilter inside transactions
by Nikolay Shirokovskiy 11 Mar '22

11 Mar '22

Hi, all. In the process of fixing a corner case in nwfilter in case of libvirtd crash I noticed the peculiar way it works for recursive removes/renames of chains. So I proposing a change which is described in the second patch. This is an RFC and as such is incomplete: - only recursive removing is patched and renaming is not - tests are not fixed Nikolay Shirokovskiy (2): utils: make virFirewallAddRuleFullV public nwfilter: don't query netfilter inside transactions src/libvirt_private.syms | 1 + src/nwfilter/nwfilter_ebiptables_driver.c | 154 +++++++++++----------- src/util/virfirewall.c | 2 +- src/util/virfirewall.h | 7 + 4 files changed, 84 insertions(+), 80 deletions(-) -- 2.31.1

2 4

[PATCH RESEND] virsh: Provide completer for vol-wipe algorithms
by Haonan Wang 11 Mar '22

11 Mar '22

Related issue: https://gitlab.com/libvirt/libvirt/-/issues/9 Signed-off-by: Haonan Wang <hnwanga1(a)gmail.com> --- tools/virsh-completer-volume.c | 19 +++++++++++++++++++ tools/virsh-completer-volume.h | 6 ++++++ tools/virsh-volume.c | 3 +-- tools/virsh-volume.h | 3 +++ 4 files changed, 29 insertions(+), 2 deletions(-) diff --git a/tools/virsh-completer-volume.c b/tools/virsh-completer-volume.c index ac3c472177..bed45fa1ca 100644 --- a/tools/virsh-completer-volume.c +++ b/tools/virsh-completer-volume.c @@ -26,6 +26,7 @@ #include "virsh-pool.h" #include "virsh.h" #include "virstring.h" +#include "virsh-volume.h" char ** virshStorageVolNameCompleter(vshControl *ctl, @@ -116,3 +117,21 @@ virshStorageVolKeyCompleter(vshControl *ctl, virshStoragePoolListFree(list); return ret; } + +char ** +virshStorageVolWipeAlgorithmCompleter(vshControl *ctl G_GNUC_UNUSED, + const vshCmd *cmd G_GNUC_UNUSED, + unsigned int flags) +{ + char **ret = NULL; + size_t i; + + virCheckFlags(0, NULL); + + ret = g_new0(char *, VIR_STORAGE_VOL_WIPE_ALG_LAST + 1); + + for (i = 0; i < VIR_STORAGE_VOL_WIPE_ALG_LAST; i++) + ret[i] = g_strdup(virshStorageVolWipeAlgorithmTypeToString(i)); + + return ret; +} diff --git a/tools/virsh-completer-volume.h b/tools/virsh-completer-volume.h index dc6eeb4b3c..17e50f450d 100644 --- a/tools/virsh-completer-volume.h +++ b/tools/virsh-completer-volume.h @@ -33,3 +33,9 @@ char ** virshStorageVolKeyCompleter(vshControl *ctl, const vshCmd *cmd, unsigned int flags); + + +char ** +virshStorageVolWipeAlgorithmCompleter(vshControl *ctl, + const vshCmd *cmd, + unsigned int flags); diff --git a/tools/virsh-volume.c b/tools/virsh-volume.c index d005602fe8..b6fa9555ad 100644 --- a/tools/virsh-volume.c +++ b/tools/virsh-volume.c @@ -902,12 +902,12 @@ static const vshCmdOptDef opts_vol_wipe[] = { VIRSH_COMMON_OPT_POOL_OPTIONAL, {.name = "algorithm", .type = VSH_OT_STRING, + .completer = virshStorageVolWipeAlgorithmCompleter, .help = N_("perform selected wiping algorithm") }, {.name = NULL} }; -VIR_ENUM_DECL(virshStorageVolWipeAlgorithm); VIR_ENUM_IMPL(virshStorageVolWipeAlgorithm, VIR_STORAGE_VOL_WIPE_ALG_LAST, "zero", "nnsa", "dod", "bsi", "gutmann", "schneier", @@ -950,7 +950,6 @@ cmdVolWipe(vshControl *ctl, const vshCmd *cmd) } -VIR_ENUM_DECL(virshStorageVol); VIR_ENUM_IMPL(virshStorageVol, VIR_STORAGE_VOL_LAST, N_("file"), diff --git a/tools/virsh-volume.h b/tools/virsh-volume.h index 15cab0fd8c..32e5394f5c 100644 --- a/tools/virsh-volume.h +++ b/tools/virsh-volume.h @@ -33,3 +33,6 @@ virStorageVolPtr virshCommandOptVolBy(vshControl *ctl, const vshCmd *cmd, VIRSH_BYUUID | VIRSH_BYNAME) extern const vshCmdDef storageVolCmds[]; + +VIR_ENUM_DECL(virshStorageVolWipeAlgorithm); +VIR_ENUM_DECL(virshStorageVol); -- 2.25.1

2 1

[libvirt PATCH 0/3] docs: downloads: mark GitLab as the primary source
by Ján Tomko 11 Mar '22

11 Mar '22

Also remove links to gitweb interface on libvirt.org which is no longer available. Ján Tomko (3): docs: downloads: remove links to libvirt.org mirrors docs: downloads: remove reference to git:// docs: downloads: mark GitLab as the primary source docs/downloads.rst | 106 +++++++++++++++++---------------------------- 1 file changed, 40 insertions(+), 66 deletions(-) -- 2.35.1

2 4

[libvirt] [PATCH RESEND v2 0/4] re-introduce <acpi-hotplug-bridge>
by Ani Sinha 11 Mar '22

11 Mar '22

Changelog: v2 - rebased the patch series to latest master. I am re-introducing the patchset for <acpi-hotplug-bridge> which got reverted here few months back: https://www.spinics.net/linux/fedora/libvir/msg224089.html The reason for the reversal was that there seemed to be some instability/issues around the use of the qemu commandline which this patchset tries to support. In particular, some guest operating systems did not like the way QEMU was trying to disable native hotplug on pcie root ports. Subsequently, in QEMU 6.2, we have changed our mechanism using which we disable native hotplug. As I understand, we do not have any reported issues so far in 6.2 around this area. QEMU will enter a soft feature freeze in the first week of march in prep for 7.0 release. Libvirt is also entering a new release cycle phaze. Hence, I am introducing this patchset early enough in the release cycles so that if we do see any issues on the qemu side during the rc0, rc1 cycles and if reversal of this patchset is again required, it can be done in time before the next libvirt release end of March. All the patches in this series had been previously reviewed. Some subsequent fixes were made after my initial patches were pushed. I have squashed all those fixes and consolidated them into four patches. I have also updated the documentation to reflect the new changes from the QEMU side and rebased my changes fixing the tests in the process. What changed in QEMU post version 6.1 ? ========================================= We have made basically two major changes in QEMU. First is this change: (1) commit 211afe5c69b597acf85fdd577eb497f5be1ffbd8 Author: Julia Suvorova <jusual(a)redhat.com> Date: Fri Nov 12 06:08:56 2021 -0500 hw/i386/acpi-build: Deny control on PCIe Native Hot-plug in _OSC There are two ways to enable ACPI PCI Hot-plug: * Disable the Hot-plug Capable bit on PCIe slots. This was the first approach which led to regression [1-2], as I/O space for a port is allocated only when it is hot-pluggable, which is determined by HPC bit. * Leave the HPC bit on and disable PCIe Native Hot-plug in _OSC method. This removes the (future) ability of hot-plugging switches with PCIe Native hotplug since ACPI PCI Hot-plug only works with cold-plugged bridges. If the user wants to explicitely use this feature, they can disable ACPI PCI Hot-plug with: --global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off Change the bit in _OSC method so that the OS selects ACPI PCI Hot-plug instead of PCIe Native. [1] https://gitlab.com/qemu-project/qemu/-/issues/641 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2006409 Signed-off-by: Julia Suvorova <jusual(a)redhat.com> Signed-off-by: Igor Mammedov <imammedo(a)redhat.com> Message-Id: <20211112110857.3116853-5-imammedo(a)redhat.com> Reviewed-by: Ani Sinha <ani(a)anisinha.ca> Reviewed-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> The patch description says it all. Instead of masking out the HPC bit in pcie slots, we keep them turned on. Instead, we do not advertize native hotplug capability for PCIE using _OSC control method. See section 6.2.11 in ACPI spec 6.2. At the same time, we turn on ACPI hotplug for these slots so now the guest OS can select ACPI hotplug instead. The second change is introduction of a property with which we keep the existing behavior for pc-q35-6.1 machines. This means HPC bit is masked and ACPI hotplug is enabled by default for pcie root ports. The QEMU commit is: (2) commit c318bef76206c2ecb6016e8e68c4ac6ff9a4c8cb Author: Julia Suvorova <jusual(a)redhat.com> Date: Fri Nov 12 06:08:54 2021 -0500 hw/acpi/ich9: Add compat prop to keep HPC bit set for 6.1 machine type To solve issues [1-2] the Hot Plug Capable bit in PCIe Slots will be turned on, while the switch to ACPI Hot-plug will be done in the DSDT table. Introducing 'x-keep-native-hpc' property disables the HPC bit only in 6.1 and as a result keeps the forced 'reserve-io' on pcie-root-ports in 6.1 too. [1] https://gitlab.com/qemu-project/qemu/-/issues/641 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2006409 Signed-off-by: Julia Suvorova <jusual(a)redhat.com> Signed-off-by: Igor Mammedov <imammedo(a)redhat.com> Message-Id: <20211112110857.3116853-3-imammedo(a)redhat.com> Reviewed-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Lastly, as a related side note, because from QEMU 6.2 onwards, we do not mask out HPC bit in PCIE, the work done by this patch is no longer needed: (3) commit e2a6290aab578b2170c1f5909fa556385dc0d820 Author: Marcel Apfelbaum <marcel.apfelbaum(a)gmail.com> Date: Mon Aug 2 12:00:57 2021 +0300 hw/pcie-root-port: Fix hotplug for PCI devices requiring IO Q35 has now ACPI hotplug enabled by default for PCI(e) devices. As opposed to native PCIe hotplug, guests like Fedora 34 will not assign IO range to pcie-root-ports not supporting native hotplug, resulting into a regression. Reproduce by: qemu-bin -M q35 -device pcie-root-port,id=p1 -monitor stdio device_add e1000,bus=p1 In the Guest OS the respective pcie-root-port will have the IO range disabled. Fix it by setting the "reserve-io" hint capability of the pcie-root-ports so the firmware will allocate the IO range instead. Acked-by: Igor Mammedov <imammedo(a)redhat.com> Signed-off-by: Marcel Apfelbaum <marcel(a)redhat.com> Message-Id: <20210802090057.1709775-1-marcel(a)redhat.com> Reviewed-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> This is what commit (2) alludes to. In pc-q35-6.1 machines we do need patch (3) since we mask out HPC bit from pcie ports. I know this is convoluted mess. In fairness I am trying all I can in my spare time to help from the QEMU side. I am determined to see this patchset through into libvirt. Thanks Ani Sinha (4): qemu: capablities: detect acpi-pci-hotplug-with-bridge-support conf: introduce support for acpi-bridge-hotplug feature qemu: command: add support for acpi-bridge-hotplug feature NEWS: document new acpi pci hotplug config option NEWS.rst | 8 ++ docs/formatdomain.rst | 32 +++++++ docs/schemas/domaincommon.rng | 15 ++++ src/conf/domain_conf.c | 89 ++++++++++++++++++- src/conf/domain_conf.h | 9 ++ src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 19 ++++ src/qemu/qemu_validate.c | 42 +++++++++ .../caps_6.1.0.x86_64.xml | 1 + .../caps_6.2.0.x86_64.xml | 1 + .../caps_7.0.0.x86_64.xml | 1 + ...-hotplug-bridge-disable.aarch64-latest.err | 1 + .../aarch64-acpi-hotplug-bridge-disable.xml | 13 +++ ...-hotplug-bridge-disable.x86_64-latest.args | 35 ++++++++ .../pc-i440fx-acpi-hotplug-bridge-disable.xml | 36 ++++++++ .../pc-i440fx-acpi-hotplug-bridge-enable.xml | 36 ++++++++ ...pi-hotplug-bridge-disable.x86_64-6.0.0.err | 1 + ...-hotplug-bridge-disable.x86_64-latest.args | 38 ++++++++ .../q35-acpi-hotplug-bridge-disable.xml | 53 +++++++++++ .../q35-acpi-hotplug-bridge-enable.xml | 53 +++++++++++ tests/qemuxml2argvtest.c | 7 ++ ...i-hotplug-bridge-disable.x86_64-latest.xml | 1 + ...pi-hotplug-bridge-enable.x86_64-latest.xml | 1 + ...i-hotplug-bridge-disable.x86_64-latest.xml | 1 + ...pi-hotplug-bridge-enable.x86_64-latest.xml | 1 + tests/qemuxml2xmltest.c | 4 + 27 files changed, 504 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/aarch64-acpi-hotplug-bridge-disable.aarch64-latest.err create mode 100644 tests/qemuxml2argvdata/aarch64-acpi-hotplug-bridge-disable.xml create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.xml create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-enable.xml create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.x86_64-6.0.0.err create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.xml create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-enable.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-hotplug-bridge-disable.x86_64-latest.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-hotplug-bridge-enable.x86_64-latest.xml create mode 120000 tests/qemuxml2xmloutdata/q35-acpi-hotplug-bridge-disable.x86_64-latest.xml create mode 120000 tests/qemuxml2xmloutdata/q35-acpi-hotplug-bridge-enable.x86_64-latest.xml -- 2.25.1

4 14

[PATCH 0/8] docs: Convert some pages to rST and clean up (part 2)
by Peter Krempa 10 Mar '22

10 Mar '22

Jano asked me to expedite the conversion of the 'downloads' page so he can do some modifications. Peter Krempa (8): docs: Convert 'downloads' page to rST https://pipo.sk.gitlab.io/-/libvirt/-/jobs/2188545131/artifacts/website/dow… docs: Convert 'contact' page to rST https://pipo.sk.gitlab.io/-/libvirt/-/jobs/2188545131/artifacts/website/con… docs: Convert 'testapi' page to rST https://pipo.sk.gitlab.io/-/libvirt/-/jobs/2188545131/artifacts/website/tes… syntax-check: Don't check for non-reentrant functions in '.rst' files docs: Convert 'nss' page to rST https://pipo.sk.gitlab.io/-/libvirt/-/jobs/2188545131/artifacts/website/nss… docs: Convert 'pci-hotplug' page to rST https://pipo.sk.gitlab.io/-/libvirt/-/jobs/2188545131/artifacts/website/pci… docs: Convert 'testtck' page to rST https://pipo.sk.gitlab.io/-/libvirt/-/jobs/2188545131/artifacts/website/tes… docs: Convert 'testsuites' page to rST https://pipo.sk.gitlab.io/-/libvirt/-/jobs/2188545131/artifacts/website/tes… build-aux/syntax-check.mk | 2 +- docs/contact.html.in | 116 ------- docs/contact.rst | 94 ++++++ docs/downloads.html.in | 661 -------------------------------------- docs/downloads.rst | 417 ++++++++++++++++++++++++ docs/meson.build | 14 +- docs/nss.html.in | 189 ----------- docs/nss.rst | 154 +++++++++ docs/pci-hotplug.html.in | 185 ----------- docs/pci-hotplug.rst | 146 +++++++++ docs/testapi.html.in | 35 -- docs/testapi.rst | 34 ++ docs/testsuites.html.in | 41 --- docs/testsuites.rst | 37 +++ docs/testtck.html.in | 40 --- docs/testtck.rst | 37 +++ 16 files changed, 927 insertions(+), 1275 deletions(-) delete mode 100644 docs/contact.html.in create mode 100644 docs/contact.rst delete mode 100644 docs/downloads.html.in create mode 100644 docs/downloads.rst delete mode 100644 docs/nss.html.in create mode 100644 docs/nss.rst delete mode 100644 docs/pci-hotplug.html.in create mode 100644 docs/pci-hotplug.rst delete mode 100644 docs/testapi.html.in create mode 100644 docs/testapi.rst delete mode 100644 docs/testsuites.html.in create mode 100644 docs/testsuites.rst delete mode 100644 docs/testtck.html.in create mode 100644 docs/testtck.rst -- 2.35.1

2 11

[PATCH] virsh: Provide completer for vol-wipe algorithms
by Haonan Wang 10 Mar '22

10 Mar '22

Related issue: https://gitlab.com/libvirt/libvirt/-/issues/9 Signed-off-by: Haonan Wang <hnwanga1(a)gmail.com> --- tools/virsh-completer-volume.c | 20 ++++++++++++++++++++ tools/virsh-completer-volume.h | 6 ++++++ tools/virsh-volume.c | 3 +-- tools/virsh-volume.h | 3 +++ 4 files changed, 30 insertions(+), 2 deletions(-) diff --git a/tools/virsh-completer-volume.c b/tools/virsh-completer-volume.c index ac3c472177..66b8828702 100644 --- a/tools/virsh-completer-volume.c +++ b/tools/virsh-completer-volume.c @@ -26,6 +26,7 @@ #include "virsh-pool.h" #include "virsh.h" #include "virstring.h" +#include "virsh-volume.h" char ** virshStorageVolNameCompleter(vshControl *ctl, @@ -116,3 +117,22 @@ virshStorageVolKeyCompleter(vshControl *ctl, virshStoragePoolListFree(list); return ret; } + +char** +virshStorageVolWipeAlgorithmCompleter(vshControl *ctl G_GNUC_UNUSED, + const vshCmd *cmd G_GNUC_UNUSED, + unsigned int completerflags G_GNUC_UNUSED) +{ + size_t nalgorithms = VIR_STORAGE_VOL_WIPE_ALG_LAST; + size_t i = 0; + char **ret = NULL; + g_auto(GStrv) tmp = g_new0(char *, nalgorithms); + + for (i = 0; i < nalgorithms; i++) { + const char *str = virshStorageVolWipeAlgorithmTypeToString(i); + tmp[i] = g_strdup(str); + } + + ret = g_steal_pointer(&tmp); + return ret; +} diff --git a/tools/virsh-completer-volume.h b/tools/virsh-completer-volume.h index dc6eeb4b3c..17e50f450d 100644 --- a/tools/virsh-completer-volume.h +++ b/tools/virsh-completer-volume.h @@ -33,3 +33,9 @@ char ** virshStorageVolKeyCompleter(vshControl *ctl, const vshCmd *cmd, unsigned int flags); + + +char ** +virshStorageVolWipeAlgorithmCompleter(vshControl *ctl, + const vshCmd *cmd, + unsigned int flags); diff --git a/tools/virsh-volume.c b/tools/virsh-volume.c index d005602fe8..b6fa9555ad 100644 --- a/tools/virsh-volume.c +++ b/tools/virsh-volume.c @@ -902,12 +902,12 @@ static const vshCmdOptDef opts_vol_wipe[] = { VIRSH_COMMON_OPT_POOL_OPTIONAL, {.name = "algorithm", .type = VSH_OT_STRING, + .completer = virshStorageVolWipeAlgorithmCompleter, .help = N_("perform selected wiping algorithm") }, {.name = NULL} }; -VIR_ENUM_DECL(virshStorageVolWipeAlgorithm); VIR_ENUM_IMPL(virshStorageVolWipeAlgorithm, VIR_STORAGE_VOL_WIPE_ALG_LAST, "zero", "nnsa", "dod", "bsi", "gutmann", "schneier", @@ -950,7 +950,6 @@ cmdVolWipe(vshControl *ctl, const vshCmd *cmd) } -VIR_ENUM_DECL(virshStorageVol); VIR_ENUM_IMPL(virshStorageVol, VIR_STORAGE_VOL_LAST, N_("file"), diff --git a/tools/virsh-volume.h b/tools/virsh-volume.h index 15cab0fd8c..32e5394f5c 100644 --- a/tools/virsh-volume.h +++ b/tools/virsh-volume.h @@ -33,3 +33,6 @@ virStorageVolPtr virshCommandOptVolBy(vshControl *ctl, const vshCmd *cmd, VIRSH_BYUUID | VIRSH_BYNAME) extern const vshCmdDef storageVolCmds[]; + +VIR_ENUM_DECL(virshStorageVolWipeAlgorithm); +VIR_ENUM_DECL(virshStorageVol); -- 2.25.1

1 0

[PATCH 00/14] Snapshot definition cleanups
by Peter Krempa 10 Mar '22

10 Mar '22

Cleanup patches extracted from my upcoming series for handling snapshots with outsourced storage. Peter Krempa (14): virDomainDiskDefFormat: Refactor to virXMLFormatElement qemuSnapshotDiskPrepareActiveExternal: Handle only external snapshots qemuSnapshotCreateAlignDisks: Rewrite logic for selecting default memory snapshot mode virDomainSnapshotDiskDefParseXML: Automatically free temporary variables and remove cleanup virStorageSource: Convert 'type' to proper enum conf: Move definition of 'virDomainSnapshotLocation' Rename VIR_DOMAIN_SNAPSHOT_LOCATION_NONE to VIR_DOMAIN_SNAPSHOT_LOCATION_NO qemuDomainSnapshotForEachQcow2Raw: Act only on internal snapshots conf: snapshot: Remove VIR_DOMAIN_SNAPSHOT_PARSE_DISKS flag virDomainSnapshotDefParse: Refactor cleanup virDomainSnapshotDefParse: Avoid 'memoryfile' temporary variable virDomainSnapshotDefParse: Decouple parsing of memory snapshot config conf: snapshot: Use proper types for snapshot location qemuSnapshotCreateActiveExternal: Remove duplicit assignment src/ch/ch_monitor.c | 1 + src/conf/domain_conf.c | 122 ++++++------ src/conf/domain_conf.h | 14 +- src/conf/domain_validate.c | 2 +- src/conf/snapshot_conf.c | 255 ++++++++++++-------------- src/conf/snapshot_conf.h | 23 +-- src/conf/storage_source_conf.h | 2 +- src/libvirt_private.syms | 4 +- src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_driver.c | 1 - src/qemu/qemu_snapshot.c | 23 ++- src/test/test_driver.c | 7 +- src/vbox/vbox_common.c | 4 +- src/vz/vz_driver.c | 2 +- src/vz/vz_sdk.c | 2 +- tests/qemudomainsnapshotxml2xmltest.c | 2 +- 16 files changed, 221 insertions(+), 245 deletions(-) -- 2.35.1

2 15

[PATCH 00/10] qemu: Update capabilities and use 'tls-hostname' field for NBD
by Peter Krempa 10 Mar '22

10 Mar '22

Technically patch 7/10 is more of a RFC for now as my migration setup doesn't work properly so I could not test it. Peter Krempa (10): tests: qemucapabilities: Update caps_7.0.0.x86_64 qemu: capabilities: Introduce QEMU_CAPS_BLOCKDEV_NBD_TLS_HOSTNAME qemuMigrationSrcRun: Fix misleading comment about NBD with TLS support storage_source: Add 'tlsHostname' field to virStorageSource qemu: Add support for 'tlsHostname' setting of virStorageSource conf: Add support for setting expected TLS hostname for NBD disks qemu: migration: Use 'VIR_MIGRATE_PARAM_TLS_DESTINATION' for the NBD connection NEWS: Mention that VIR_MIGRATE_PARAM_TLS_DESTINATION works now for non-shared storage migration qemuMigrationSrcNBDStorageCopyOne: Refactor cleanup qemuBlockJobDiskNew: Remove misleading return value description NEWS.rst | 6 + docs/formatdomain.rst | 4 +- docs/schemas/domaincommon.rng | 3 + src/conf/domain_conf.c | 3 + src/conf/storage_source_conf.c | 2 + src/conf/storage_source_conf.h | 3 + src/qemu/qemu_block.c | 6 +- src/qemu/qemu_blockjob.c | 2 - src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_domain.c | 15 + src/qemu/qemu_migration.c | 46 +- src/qemu/qemu_migration_params.c | 17 + src/qemu/qemu_migration_params.h | 3 + .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 1 + .../caps_7.0.0.x86_64.replies | 2202 +++++++++-------- .../caps_7.0.0.x86_64.xml | 43 +- ...work-tlsx509-nbd-hostname.x86_64-6.2.0.err | 1 + ...rk-tlsx509-nbd-hostname.x86_64-latest.args | 38 + .../disk-network-tlsx509-nbd-hostname.xml | 31 + tests/qemuxml2argvtest.c | 2 + ...ork-tlsx509-nbd-hostname.x86_64-latest.xml | 37 + tests/qemuxml2xmltest.c | 1 + 23 files changed, 1390 insertions(+), 1083 deletions(-) create mode 100644 tests/qemuxml2argvdata/disk-network-tlsx509-nbd-hostname.x86_64-6.2.0.err create mode 100644 tests/qemuxml2argvdata/disk-network-tlsx509-nbd-hostname.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/disk-network-tlsx509-nbd-hostname.xml create mode 100644 tests/qemuxml2xmloutdata/disk-network-tlsx509-nbd-hostname.x86_64-latest.xml -- 2.35.1

2 12

[libvirt PATCH 0/2] nwfilter: switch nwfilter list from array to hash
by Daniel P. Berrangé 10 Mar '22

10 Mar '22

Currently the virNWFilterObjList has O(N) complexity for object lookup and requires taking locks on every object examined. This switches to as hash table which O(1) complexity and lockless lookup. Daniel P. Berrangé (2): nwfilter: update comment about locking filter updates conf: use a hash table for storing nwfilter object list src/conf/virnwfilterobj.c | 264 +++++++++++++++++-------- src/nwfilter/nwfilter_gentech_driver.c | 51 +++-- 2 files changed, 217 insertions(+), 98 deletions(-) -- 2.35.1

2 4

[PATCH] virsh: fflush(stdout) after fputs()
by Michal Privoznik 10 Mar '22

10 Mar '22

We are not guaranteed that the string we are printing onto stdout contains '\n' and thus that the stdout is flushed. In fact, I've met this problem when virsh asked me whether I want to edit the domain XML again (vshAskReedit()) but the prompt wasn't displayed (as it does not contain a newline character) and virsh just sat there waiting for my input, I sat there waiting for virsh's output. Flush stdout after all fputs()-s which do not flush stdout. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- tools/vsh.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/vsh.c b/tools/vsh.c index bbde594967..499794c8fc 100644 --- a/tools/vsh.c +++ b/tools/vsh.c @@ -1863,6 +1863,7 @@ vshDebug(vshControl *ctl, int level, const char *format, ...) str = g_strdup_vprintf(format, ap); va_end(ap); fputs(str, stdout); + fflush(stdout); } void @@ -1878,6 +1879,7 @@ vshPrintExtra(vshControl *ctl, const char *format, ...) str = g_strdup_vprintf(format, ap); va_end(ap); fputs(str, stdout); + fflush(stdout); } @@ -1891,6 +1893,7 @@ vshPrint(vshControl *ctl G_GNUC_UNUSED, const char *format, ...) str = g_strdup_vprintf(format, ap); va_end(ap); fputs(str, stdout); + fflush(stdout); } @@ -2938,6 +2941,7 @@ vshReadline(vshControl *ctl G_GNUC_UNUSED, int len; fputs(prompt, stdout); + fflush(stdout); r = fgets(line, sizeof(line), stdin); if (r == NULL) return NULL; /* EOF */ -- 2.34.1

2 1

[PATCH] conf: remove misleading comments about access being 'lockless'
by Daniel P. Berrangé 10 Mar '22

10 Mar '22

For the various structs storing lists of objects, the access to the hash tables is not lockless. The mutex on the object owning the hash table must be held. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/conf/virdomainobjlist.c | 4 ++-- src/conf/virinterfaceobj.c | 2 +- src/conf/virnodedeviceobj.c | 2 +- src/conf/virnwfilterbindingobjlist.c | 2 +- src/conf/virsecretobj.c | 2 +- src/conf/virstorageobj.c | 10 +++++----- 6 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/conf/virdomainobjlist.c b/src/conf/virdomainobjlist.c index 70b73e87ec..66bd4bcba7 100644 --- a/src/conf/virdomainobjlist.c +++ b/src/conf/virdomainobjlist.c @@ -46,11 +46,11 @@ struct _virDomainObjList { virObjectRWLockable parent; /* uuid string -> virDomainObj mapping - * for O(1), lockless lookup-by-uuid */ + * for O(1), lookup-by-uuid */ GHashTable *objs; /* name -> virDomainObj mapping for O(1), - * lockless lookup-by-name */ + * lookup-by-name */ GHashTable *objsName; }; diff --git a/src/conf/virinterfaceobj.c b/src/conf/virinterfaceobj.c index 62b21b5e5f..95279d5b1c 100644 --- a/src/conf/virinterfaceobj.c +++ b/src/conf/virinterfaceobj.c @@ -44,7 +44,7 @@ struct _virInterfaceObjList { virObjectRWLockable parent; /* name string -> virInterfaceObj mapping - * for O(1), lockless lookup-by-name */ + * for O(1), lookup-by-name */ GHashTable *objsName; }; diff --git a/src/conf/virnodedeviceobj.c b/src/conf/virnodedeviceobj.c index ba84dce82b..fd23ea5fc7 100644 --- a/src/conf/virnodedeviceobj.c +++ b/src/conf/virnodedeviceobj.c @@ -48,7 +48,7 @@ struct _virNodeDeviceObjList { virObjectRWLockable parent; /* name string -> virNodeDeviceObj mapping - * for O(1), lockless lookup-by-name */ + * for O(1), lookup-by-name */ GHashTable *objs; }; diff --git a/src/conf/virnwfilterbindingobjlist.c b/src/conf/virnwfilterbindingobjlist.c index 03441c9c1b..53713d815a 100644 --- a/src/conf/virnwfilterbindingobjlist.c +++ b/src/conf/virnwfilterbindingobjlist.c @@ -39,7 +39,7 @@ struct _virNWFilterBindingObjList { virObjectRWLockable parent; /* port dev name -> virNWFilterBindingObj mapping - * for O(1), lockless lookup-by-port dev */ + * for O(1), lookup-by-port dev */ GHashTable *objs; }; diff --git a/src/conf/virsecretobj.c b/src/conf/virsecretobj.c index ed62856d61..92985c4b63 100644 --- a/src/conf/virsecretobj.c +++ b/src/conf/virsecretobj.c @@ -54,7 +54,7 @@ struct _virSecretObjList { virObjectRWLockable parent; /* uuid string -> virSecretObj mapping - * for O(1), lockless lookup-by-uuid */ + * for O(1), lookup-by-uuid */ GHashTable *objs; }; diff --git a/src/conf/virstorageobj.c b/src/conf/virstorageobj.c index d527132184..b57c1cb8b2 100644 --- a/src/conf/virstorageobj.c +++ b/src/conf/virstorageobj.c @@ -66,15 +66,15 @@ struct _virStorageVolObjList { virObjectRWLockable parent; /* key string -> virStorageVolObj mapping - * for (1), lockless lookup-by-key */ + * for (1), lookup-by-key */ GHashTable *objsKey; /* name string -> virStorageVolObj mapping - * for (1), lockless lookup-by-name */ + * for (1), lookup-by-name */ GHashTable *objsName; /* path string -> virStorageVolObj mapping - * for (1), lockless lookup-by-path */ + * for (1), lookup-by-path */ GHashTable *objsPath; }; @@ -98,11 +98,11 @@ struct _virStoragePoolObjList { virObjectRWLockable parent; /* uuid string -> virStoragePoolObj mapping - * for (1), lockless lookup-by-uuid */ + * for (1), lookup-by-uuid */ GHashTable *objs; /* name string -> virStoragePoolObj mapping - * for (1), lockless lookup-by-name */ + * for (1), lookup-by-name */ GHashTable *objsName; }; -- 2.35.1

2 1

[PATCH] run: include 'src' in $PATH for the daemons
by Daniel P. Berrangé 10 Mar '22

10 Mar '22

Currently the 'run' script modifies $PATH to add the 'tools' directly to pick up client programs. It fails to add the 'src' directory to pick up the daemons. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- run.in | 1 + 1 file changed, 1 insertion(+) diff --git a/run.in b/run.in index 174b191675..3be7818d32 100644 --- a/run.in +++ b/run.in @@ -70,6 +70,7 @@ env = os.environ prepend(env, "LD_LIBRARY_PATH", os.path.join(here, "src")) prepend(env, "PKG_CONFIG_PATH", os.path.join(here, "src")) prepend(env, "PATH", os.path.join(here, "tools")) +prepend(env, "PATH", os.path.join(here, "src")) # Ensure that any 3rd party apps using libvirt.so from the build tree get # files resolved to the build/source tree too. Typically useful for language -- 2.35.1

2 1

[PATCH] run: gracefully handle SIGHUP, SIGQUIT, SIGTERM
by Daniel P. Berrangé 10 Mar '22

10 Mar '22

When using thue 'run' script to launch a daemon, it is intended to temporarily stop the systemd units and re-start them again after. When using this script over an SSH connection, it will get SIGHUP if the connection goes away, and in this case it fails to re-start the systemd units. We need to catch SIGHUP and turn it into a normal python exception. For good measure we do the same for SIGQUIT and SIGTERM too. SIGINT already gets turned into an exception by default which we handle. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- run.in | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/run.in b/run.in index 3be7818d32..c6d3411082 100644 --- a/run.in +++ b/run.in @@ -43,6 +43,7 @@ import os import os.path import random +import signal import sys import subprocess @@ -155,6 +156,13 @@ else: print("Temporarily stopping systemd units...") stopped_units = [] + def sighandler(signum, frame): + raise OSError("Signal %d received, terminating" % signum) + + signal.signal(signal.SIGHUP, sighandler) + signal.signal(signal.SIGTERM, sighandler) + signal.signal(signal.SIGQUIT, sighandler) + try: for unit in try_stop_units: print(" > %s" % unit) @@ -167,6 +175,8 @@ else: ret = subprocess.call(args, env=env) except KeyboardInterrupt: pass + except Exception as e: + print("%s" % e, file=sys.stderr) finally: print("Re-starting original systemd units...") stopped_units.reverse() -- 2.35.1

2 1

[libvirt PATCH] news: Document that we build with musl
by Martin Kletzander 09 Mar '22

09 Mar '22

A bit of effort by me and Michal helped make this the case, and it helped us uncover some potential issues. I am not documenting it as supported or adding an Alpine container into the CI, but since there were some distribution bugs mentioning libvirt issues I thing it would be nice of us to notify those distribution maintainers that read our release news. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- NEWS.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index a5b6106bc2c2..f0270b9bb159 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -21,6 +21,9 @@ v8.2.0 (unreleased) * **Bug fixes** + * Both build and tests should now pass on Alpine Linux or any other + distribution with musl libc. + v8.1.0 (2022-03-01) =================== -- 2.35.1

3 7

[libvirt PATCH 00/12] Automatic mutex management - part 4
by Tim Wiederhake 09 Mar '22

09 Mar '22

Use the recently implemented VIR_LOCK_GUARD and VIR_WITH_MUTEX_LOCK_GUARD to simplify mutex management. Tim Wiederhake (12): nwfilter_driver: Statically initialize mutex nwfilter_driver: Split up nwfilterStateCleanup nwfilter_driver: Use automatic mutex management nwfilter_gentech: Use automatic mutex management nwfilter_dhcpsnoop: Replace virNWFilterSnoopActiveLock macros nwfilter_dhcpsnoop: Replace virNWFilterSnoopLock macros nwfilter_dhcpsnoop: Replace virNWFilterSnoopReqLock functions nwfilter_learnipaddr: Use automatic mutex management nwfilter_ipaddrmap: Use automatic mutex management virnetlink: Use automatic memory management remote_daemon_stream: Use automatic memory management qemu_conf: Use automatic memory management src/conf/nwfilter_ipaddrmap.c | 80 ++--- src/conf/virnwfilterobj.h | 1 - src/nwfilter/nwfilter_dhcpsnoop.c | 393 ++++++++----------------- src/nwfilter/nwfilter_driver.c | 175 +++++------ src/nwfilter/nwfilter_gentech_driver.c | 34 +-- src/nwfilter/nwfilter_learnipaddr.c | 83 ++---- src/qemu/qemu_conf.c | 70 ++--- src/remote/remote_daemon_stream.c | 34 +-- src/util/virnetlink.c | 101 +++---- 9 files changed, 357 insertions(+), 614 deletions(-) -- 2.31.1

2 14

[libvirt PATCH v3] qemu: support multiqueue for vdpa net device
by Jonathon Jongsma 09 Mar '22

09 Mar '22

The vdpa device supports multiqueue, so remove the restriction from qemuDomainValidateActualNetDef() that prevents us from using this functionality. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2024406 Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com> --- Changes in v3: - Do not set the model type in virDomainNetDefParseXML(). Other virtio devices require the model to be explicitly set to 'virtio' in the xml definition in order to parse the virtio driver options, and it doesn't make sense to treat the vdpa device differently. If we want this behavior to change, it should probably be changed so that it applies to all devices that default to a virtio device model. Changes in v2: - remove error message in virDomainNetDefParseXML(). The model is already checked in the post parse validation step. src/qemu/qemu_domain.c | 3 +- .../net-vdpa-multiqueue.x86_64-latest.args | 36 +++++++++++++++++++ .../qemuxml2argvdata/net-vdpa-multiqueue.xml | 30 ++++++++++++++++ tests/qemuxml2argvtest.c | 1 + .../net-vdpa-multiqueue.xml | 36 +++++++++++++++++++ tests/qemuxml2xmltest.c | 1 + 6 files changed, 106 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/net-vdpa-multiqueue.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/net-vdpa-multiqueue.xml create mode 100644 tests/qemuxml2xmloutdata/net-vdpa-multiqueue.xml diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index acc76c1cd6..6b61fefb8f 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -4523,7 +4523,8 @@ qemuDomainValidateActualNetDef(const virDomainNetDef *net, actualType == VIR_DOMAIN_NET_TYPE_BRIDGE || actualType == VIR_DOMAIN_NET_TYPE_DIRECT || actualType == VIR_DOMAIN_NET_TYPE_ETHERNET || - actualType == VIR_DOMAIN_NET_TYPE_VHOSTUSER)) { + actualType == VIR_DOMAIN_NET_TYPE_VHOSTUSER || + actualType == VIR_DOMAIN_NET_TYPE_VDPA)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("interface %s - multiqueue is not supported for network interfaces of type %s"), macstr, virDomainNetTypeToString(actualType)); diff --git a/tests/qemuxml2argvdata/net-vdpa-multiqueue.x86_64-latest.args b/tests/qemuxml2argvdata/net-vdpa-multiqueue.x86_64-latest.args new file mode 100644 index 0000000000..26ef666036 --- /dev/null +++ b/tests/qemuxml2argvdata/net-vdpa-multiqueue.x86_64-latest.args @@ -0,0 +1,36 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/tmp/lib/domain--1-QEMUGuest1 \ +USER=test \ +LOGNAME=test \ +XDG_DATA_HOME=/tmp/lib/domain--1-QEMUGuest1/.local/share \ +XDG_CACHE_HOME=/tmp/lib/domain--1-QEMUGuest1/.cache \ +XDG_CONFIG_HOME=/tmp/lib/domain--1-QEMUGuest1/.config \ +/usr/bin/qemu-system-x86_64 \ +-name guest=QEMUGuest1,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/tmp/lib/domain--1-QEMUGuest1/master-key.aes"}' \ +-machine pc,usb=off,dump-guest-core=off,memory-backend=pc.ram \ +-accel tcg \ +-cpu qemu64 \ +-m 214 \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":224395264}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-no-acpi \ +-boot strict=on \ +-device '{"driver":"piix3-usb-uhci","id":"usb","bus":"pci.0","addr":"0x1.0x2"}' \ +-add-fd set=0,fd=1732,opaque=net0-vdpa \ +-netdev vhost-vdpa,vhostdev=/dev/fdset/0,id=hostnet0 \ +-device '{"driver":"virtio-net-pci","mq":true,"vectors":6,"netdev":"hostnet0","id":"net0","mac":"52:54:00:95:db:c0","bus":"pci.0","addr":"0x2"}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on diff --git a/tests/qemuxml2argvdata/net-vdpa-multiqueue.xml b/tests/qemuxml2argvdata/net-vdpa-multiqueue.xml new file mode 100644 index 0000000000..6e369c1916 --- /dev/null +++ b/tests/qemuxml2argvdata/net-vdpa-multiqueue.xml @@ -0,0 +1,30 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <controller type='usb' index='0'/> + <controller type='ide' index='0'/> + <controller type='pci' index='0' model='pci-root'/> + <interface type='vdpa'> + <mac address='52:54:00:95:db:c0'/> + <source dev='/dev/vhost-vdpa-0'/> + <model type='virtio'/> + <driver queues='2'/> + </interface> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <memballoon model='none'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index ce475df466..7e1167e60e 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -1609,6 +1609,7 @@ mymain(void) DO_TEST_FAILURE("net-hostdev-fail", QEMU_CAPS_DEVICE_VFIO_PCI); DO_TEST_CAPS_LATEST("net-vdpa"); + DO_TEST_CAPS_LATEST("net-vdpa-multiqueue"); DO_TEST("hostdev-pci-multifunction", QEMU_CAPS_KVM, diff --git a/tests/qemuxml2xmloutdata/net-vdpa-multiqueue.xml b/tests/qemuxml2xmloutdata/net-vdpa-multiqueue.xml new file mode 100644 index 0000000000..0876d5df62 --- /dev/null +++ b/tests/qemuxml2xmloutdata/net-vdpa-multiqueue.xml @@ -0,0 +1,36 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <controller type='usb' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <interface type='vdpa'> + <mac address='52:54:00:95:db:c0'/> + <source dev='/dev/vhost-vdpa-0'/> + <model type='virtio'/> + <driver queues='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </interface> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <audio id='1' type='none'/> + <memballoon model='none'/> + </devices> +</domain> diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c index 052950b86f..2174965784 100644 --- a/tests/qemuxml2xmltest.c +++ b/tests/qemuxml2xmltest.c @@ -485,6 +485,7 @@ mymain(void) DO_TEST_NOCAPS("net-coalesce"); DO_TEST_NOCAPS("net-many-models"); DO_TEST("net-vdpa", QEMU_CAPS_NETDEV_VHOST_VDPA); + DO_TEST("net-vdpa-multiqueue", QEMU_CAPS_NETDEV_VHOST_VDPA); DO_TEST_NOCAPS("serial-tcp-tlsx509-chardev"); DO_TEST_NOCAPS("serial-tcp-tlsx509-chardev-notls"); -- 2.35.1

2 1