October 2021 - Devel - libvirt List Archives

[PATCH v3 0/4] Add qemu support setting qos via ovs on ovs interface
by zhangjl02 29 Oct '21

29 Oct '21

--- diff to v2: - Remove passing "actualType" argument, get it inside funtion - Format code. diff to v1: - Move qemuDomainDefIsOvsport from src/qemu/qemu_domain.c to src/conf/domain_conf.c - Call virCommandFree(cmd)free cmd before reusing it. - Ddd g_autofree to variables. - Reduce usage of virReportError(), and coupled it with return -1. - Fix remove port qos error. - Optimise code structure. Thanks to Michal Privoznik for helping reviewing these patches and solving problems. Really sorry to bring extra work to review them. I will continue to learn and become familiar with submission process. Now libvirt use tc rules to manage interface's qos. But when an interface is created by ovs, there is no qos setting result in ovs database. Therefore, qos of ovs port should be set via ovs management command. We add a function to tell whether a port definition is an ovs managed virtual port. Change default qdisc rules, which return 0 directly if the port is ovs managed(When the ovs port is set noqueue, qos config on this port will not work). Add ovs management function of setting and cleaning qos. Then check if the port is an ovs managed port during its life cycle, and call the ovs management function to set or clean qos settings. zhangjl02 (4): virDomain: interface: add virDomainNetDefIsOvsport virDomain: interface: add virNetDevOpenvswitchInterfaceSetQos and virNetDevOpenvswitchInterfaceClearQos qemu: interface: remove setting noqueue for ovs port qemu: interface: check and use ovs command to set qos of ovs managed port src/conf/domain_conf.c | 11 ++ src/conf/domain_conf.h | 2 + src/libvirt_private.syms | 3 + src/qemu/qemu_command.c | 10 +- src/qemu/qemu_domain.c | 3 +- src/qemu/qemu_driver.c | 23 ++- src/qemu/qemu_hotplug.c | 35 ++-- src/qemu/qemu_process.c | 7 +- src/util/virnetdevopenvswitch.c | 274 ++++++++++++++++++++++++++++++++ src/util/virnetdevopenvswitch.h | 11 ++ 10 files changed, 364 insertions(+), 15 deletions(-) -- 2.30.2.windows.1

4 14

[PATCH 0/3] Docs and news update for v7.8.0
by Han Han 29 Oct '21

29 Oct '21

Han Han (3): docs: Mention QEMU version requirement for queue-size news: Add queue_size option to virtio disk news: Add validation flags for creating of net, nwfilter-binding, net port NEWS.rst | 16 ++++++++++++++++ docs/formatdomain.rst | 2 +- 2 files changed, 17 insertions(+), 1 deletion(-) -- 2.33.1

2 4

[PATCH] news: Support vhostuser in virsh attach-interface since v7.7.0
by Han Han 29 Oct '21

29 Oct '21

Signed-off-by: Han Han <hhan(a)redhat.com> --- NEWS.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 5f1cf19940..694c506cad 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -162,6 +162,8 @@ v7.7.0 (2021-09-01) forbidden for older qemus which don't support the update API as the guest could still reboot and execute some instructions until it was terminated. + * virsh: Support vhostuser in attach-interface + * **Bug fixes** * qemu: Open chardev logfile on behalf of QEMU -- 2.33.1

1 0

[RFC] Allowing SEV attestation
by Michal Prívozník 28 Oct '21

28 Oct '21

Dear list, in the light of recent development of secure virtualization (for instance AMD SEV-SNP [1]) I'd like us to be prepared for when QEMU adopts these new technologies and thus would like to discuss our options. So far, I've came across AMD SEV-SNP [2]. While it's true that we do support SEV, we need to adopt its newer version too. Consider the following example: you loan a VM on a public cloud and you want to process some private data there. Of course, the data has to be stored on an encrypted disk/partition. But encrypting guest memory (confidentiality) prevents you only from finding the key in a memory dump. It doesn't help if the guest image, initial guest memory, hypervisor or firmware were tampered with. This is where attestation comes to help - it enables the guest owner (which in this example is different to the one running it) verify - with cryptographic level of confidence - that data confidentiality and integrity can be ensured. Depending on the technology, attestation will be done at different times in the VM lifecycle. When it's done before starting guest vCPUs, it's called pre-attestation and when it's done after the guest has launched, it's called post-attestation. For example, AMD SEV and SEV-ES require pre-attestation. SEV-SNP allows for post attestation. The crux of the issue here is that *when* and *how* the guest owner will interact with the VM for attestation will be different depending on which technology is being used. It looks like QEMU will expose commands needed for attestation via QMP [3]. But question then is, how to expose those at Libvirt level? Should we allow users to bypass Libvirt and communicate to QEMU directly or wrap those QMPs in public APIs, or something completely different? Will those APIs be generic enough to serve other technologies too? For instance, given set of APIs in given order works for SEV but might not work for Intel's TDX. 1: https://kvmforum2019.sched.com/event/Tmwl/improving-and-expanding-sev-suppo… 2: https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolatio… 3: https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03689.html Michal

5 13

[PATCH v5 0/5] Add support for librbd encryption
by Or Ozeri 28 Oct '21

28 Oct '21

v5: rebased + nit fixes suggested by Peter v4: - added disk post parse to image creation flow in qemublocktest (since more tests failed after adding engine validation) - removed symlink changes - added luks2 and engine documentation - switched to using enum engine instead of int - added validation for encryption engine and formats v3: rebased on master v2: addressed (hopefully) all of Peter's v1 comments (thanks Peter!) Feel free to make any other changes before pushing. Thanks! Or Ozeri (5): qemu: add disk post parse to qemublocktest qemu: capablities: Detect presence of 'rbd-encryption' as QEMU_CAPS_RBD_ENCRYPTION conf: add encryption engine property qemu: add librbd encryption engine conf: add luks2 encryption format docs/formatstorageencryption.html.in | 29 ++++++- docs/schemas/domainbackup.rng | 7 ++ docs/schemas/storagecommon.rng | 9 ++ src/conf/storage_encryption_conf.c | 28 ++++++- src/conf/storage_encryption_conf.h | 11 +++ src/qemu/qemu_block.c | 41 +++++++++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_domain.c | 69 ++++++++++++++- src/qemu/qemu_domain.h | 3 + tests/qemublocktest.c | 29 +++---- .../caps_6.1.0.x86_64.xml | 1 + .../caps_6.2.0.x86_64.xml | 1 + tests/qemustatusxml2xmldata/upgrade-out.xml | 6 +- ...sk-network-rbd-encryption.x86_64-6.0.0.err | 1 + ...-network-rbd-encryption.x86_64-latest.args | 49 +++++++++++ .../disk-network-rbd-encryption.xml | 75 +++++++++++++++++ tests/qemuxml2argvdata/disk-nvme.xml | 2 +- .../qemuxml2argvdata/encrypted-disk-usage.xml | 2 +- tests/qemuxml2argvdata/luks-disks.xml | 4 +- tests/qemuxml2argvdata/user-aliases.xml | 2 +- tests/qemuxml2argvtest.c | 2 + ...k-network-rbd-encryption.x86_64-latest.xml | 83 +++++++++++++++++++ .../disk-slices.x86_64-latest.xml | 4 +- tests/qemuxml2xmloutdata/encrypted-disk.xml | 2 +- .../luks-disks-source-qcow2.x86_64-latest.xml | 14 ++-- .../qemuxml2xmloutdata/luks-disks-source.xml | 10 +-- tests/qemuxml2xmltest.c | 1 + 28 files changed, 443 insertions(+), 45 deletions(-) create mode 100644 tests/qemuxml2argvdata/disk-network-rbd-encryption.x86_64-6.0.0.err create mode 100644 tests/qemuxml2argvdata/disk-network-rbd-encryption.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/disk-network-rbd-encryption.xml create mode 100644 tests/qemuxml2xmloutdata/disk-network-rbd-encryption.x86_64-latest.xml -- 2.25.1

4 8

[libvirt][PATCH v7 0/5] Support query and use SGX
by Haibin Huang 27 Oct '21

27 Oct '21

This patch series provides support for enabling Intel's Software Guard Extensions (SGX) feature in guest VM. Giving the SGX support in QEMU be accepted and will be merged in two days Intel Software Guard Extensions (Intel�� SGX) is a set of instructions that increases the security of application code and data, giving them more protection from disclosure or modification. Developers can partition sensitive information into enclaves, which are areas of execution in memory with more security protection. The typical flow looks below at very high level: 1. Calls virConnectGetDomainCapabilities API to domain capabilities that includes the following SGX information. <feature> ... <sgx supported='yes'> <epc_size unit=��KiB��>N</epc_size> </sgx> </feature> 2. User requests to start a guest calling virCreateXML() with SGX requirement. It should contain <devices> ... <memory model='sgx-epc'> <target> <size unit='KiB'>N</size> </target> </memory> ... </devices> Haibin Huang (2): Support to query SGX capability Add get domaincaps unit test Lin Yang (3): conf: Introduce SGX EPC element into device memory xml qemu: Add command-line to generate SGX EPC memory backend Add unit tests for guest VM creation command with SGX EPC docs/schemas/domaincaps.rng | 19 ++- docs/schemas/domaincommon.rng | 1 + src/conf/domain_capabilities.c | 29 ++++ src/conf/domain_capabilities.h | 13 ++ src/conf/domain_conf.c | 5 + src/conf/domain_conf.h | 1 + src/conf/domain_validate.c | 1 + src/libvirt_private.syms | 2 +- src/qemu/qemu_alias.c | 6 +- src/qemu/qemu_capabilities.c | 142 ++++++++++++++++++ src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_command.c | 39 ++++- src/qemu/qemu_domain.c | 10 +- src/qemu/qemu_domain_address.c | 4 + src/qemu/qemu_monitor.c | 10 ++ src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 89 +++++++++++ src/qemu/qemu_monitor_json.h | 3 + src/qemu/qemu_process.c | 2 + src/qemu/qemu_validate.c | 8 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 2 + src/security/security_selinux.c | 2 + tests/domaincapsdata/bhyve_basic.x86_64.xml | 1 + tests/domaincapsdata/bhyve_fbuf.x86_64.xml | 1 + tests/domaincapsdata/bhyve_uefi.x86_64.xml | 1 + tests/domaincapsdata/empty.xml | 1 + tests/domaincapsdata/libxl-xenfv.xml | 1 + tests/domaincapsdata/libxl-xenpv.xml | 1 + .../domaincapsdata/qemu_2.11.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_2.11.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_2.11.0.s390x.xml | 1 + tests/domaincapsdata/qemu_2.11.0.x86_64.xml | 1 + .../domaincapsdata/qemu_2.12.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_2.12.0-tcg.x86_64.xml | 1 + .../qemu_2.12.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_2.12.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_2.12.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_2.12.0.s390x.xml | 1 + tests/domaincapsdata/qemu_2.12.0.x86_64.xml | 1 + .../domaincapsdata/qemu_2.4.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_2.4.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_2.4.0.x86_64.xml | 1 + .../domaincapsdata/qemu_2.5.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_2.5.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_2.5.0.x86_64.xml | 1 + .../domaincapsdata/qemu_2.6.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_2.6.0-tcg.x86_64.xml | 1 + .../qemu_2.6.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_2.6.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_2.6.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_2.6.0.x86_64.xml | 1 + .../domaincapsdata/qemu_2.7.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_2.7.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_2.7.0.s390x.xml | 1 + tests/domaincapsdata/qemu_2.7.0.x86_64.xml | 1 + .../domaincapsdata/qemu_2.8.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_2.8.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_2.8.0.s390x.xml | 1 + tests/domaincapsdata/qemu_2.8.0.x86_64.xml | 1 + .../domaincapsdata/qemu_2.9.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_2.9.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_2.9.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_2.9.0.s390x.xml | 1 + tests/domaincapsdata/qemu_2.9.0.x86_64.xml | 1 + .../domaincapsdata/qemu_3.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_3.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_3.0.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_3.0.0.s390x.xml | 1 + tests/domaincapsdata/qemu_3.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_3.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_3.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_3.1.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_3.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_4.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_4.0.0-tcg.x86_64.xml | 1 + .../qemu_4.0.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_4.0.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_4.0.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_4.0.0.s390x.xml | 1 + tests/domaincapsdata/qemu_4.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_4.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_4.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_4.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 1 + .../qemu_4.2.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_4.2.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_4.2.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_4.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml | 1 + .../qemu_5.0.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_5.0.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_5.0.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_5.1.0.sparc.xml | 1 + tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 1 + .../qemu_5.2.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_5.2.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_5.2.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_5.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 1 + .../qemu_6.0.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_6.0.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_6.0.0.s390x.xml | 1 + tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 1 + .../sgx-epc.x86_64-5.1.0.args | 37 +++++ tests/qemuxml2argvdata/sgx-epc.xml | 40 +++++ tests/qemuxml2argvtest.c | 1 + 120 files changed, 560 insertions(+), 8 deletions(-) create mode 100644 tests/qemuxml2argvdata/sgx-epc.x86_64-5.1.0.args create mode 100644 tests/qemuxml2argvdata/sgx-epc.xml -- 2.17.1

3 14

[libvirt PATCH 0/4] PCI VPD: Handle More Edge Cases
by Dmitrii Shcherbakov 27 Oct '21

27 Oct '21

This patch set improves edge case testing: * The parser is now more strict about checking boundary conditions when parsing fields: an invalid field length is a possibility which is now being accounted for; * The parser will now make sure that RV and RW fields are the last in their section by making sure that no more data is left to read after those; * RW field presence was already checked for but there was no test case for it. This was prompted by a real-world hardware example where this field was not present. Invalid field values are now skipped instead of halting further parsing completely. It turns out that some vendors use values like "N/A" if fields were not populated in VPD-R and 0xFF as placeholders in VPD-W. While this data is not valid, other data might be and it should be possible to retrieve it. Dmitrii Shcherbakov (4): PCI VPD: handle additional edge cases PCI VPD: Add a test case for the absence of RW PCI VPD: Skip fields with invalid values PCI VPD: Fix a wrong return code in a test case src/util/virpcivpd.c | 37 ++++++-- tests/virpcivpdtest.c | 207 ++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 225 insertions(+), 19 deletions(-) -- 2.32.0

2 9

[PATCH 0/3] qemu: Set "qemu-event" thread identity
by Michal Privoznik 27 Oct '21

27 Oct '21

I propose to merge only the first two patches. The third one is just an alternative to the first two, but honestly, I view it as a terrible hack. Nevertheless, a hack worth discussion. Michal Prívozník (3): virthreadpool: Allow setting identity for workers qemu: Set "qemu-event" thread identity *** DO NOT MERGE *** src/nwfilter/nwfilter_dhcpsnoop.c | 1 + src/qemu/qemu_driver.c | 5 ++++- src/qemu/qemu_process.c | 4 ++++ src/rpc/virnetserver.c | 1 + src/util/virthreadpool.c | 12 ++++++++++++ src/util/virthreadpool.h | 12 +++++++----- 6 files changed, 29 insertions(+), 6 deletions(-) -- 2.32.0

3 9

[PATCH] qemu_agent: remove unused code
by Kristina Hanicova 27 Oct '21

27 Oct '21

Signed-off-by: Kristina Hanicova <khanicov(a)redhat.com> --- src/qemu/qemu_agent.c | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c index 5f421be6f6..f7feadd5eb 100644 --- a/src/qemu/qemu_agent.c +++ b/src/qemu/qemu_agent.c @@ -237,17 +237,6 @@ qemuAgentIOProcessEvent(qemuAgent *agent, return -1; } -/* - for (i = 0; i < G_N_ELEMENTS(eventHandlers); i++) { - if (STREQ(eventHandlers[i].type, type)) { - virJSONValue *data = virJSONValueObjectGet(obj, "data"); - VIR_DEBUG("handle %s handler=%p data=%p", type, - eventHandlers[i].handler, data); - (eventHandlers[i].handler)(agent, data); - break; - } - } -*/ return 0; } -- 2.31.1

2 1

[PATCH] qemu_block: Refactor qemuBlockExportAddNBD()
by Kristina Hanicova 26 Oct '21

26 Oct '21

I think this patch improves readability of the function by removing unnecessary 'else' branches after 'return' and reworking the code a bit. Signed-off-by: Kristina Hanicova <khanicov(a)redhat.com> --- src/qemu/qemu_block.c | 33 +++++++++++++-------------------- 1 file changed, 13 insertions(+), 20 deletions(-) diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c index 34fdec2c4b..4e532d29c0 100644 --- a/src/qemu/qemu_block.c +++ b/src/qemu/qemu_block.c @@ -3592,28 +3592,21 @@ qemuBlockExportAddNBD(virDomainObj *vm, const char *bitmap) { qemuDomainObjPrivate *priv = vm->privateData; + g_autoptr(virJSONValue) nbdprops = NULL; + const char *bitmaps[2] = { bitmap, NULL }; - if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_BLOCKDEV)) { - if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_BLOCK_EXPORT_ADD)) { - g_autoptr(virJSONValue) nbdprops = NULL; - const char *bitmaps[2] = { bitmap, NULL }; + /* older qemu versions didn't support configuring the exportname and + * took the 'drivealias' as the export name */ + if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_BLOCKDEV)) + return qemuMonitorNBDServerAdd(priv->mon, drivealias, NULL, writable, NULL); - if (!(nbdprops = qemuBlockExportGetNBDProps(src->nodeformat, - exportname, - writable, - bitmaps))) - return -1; + if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_BLOCK_EXPORT_ADD)) + return qemuMonitorNBDServerAdd(priv->mon, src->nodeformat, + exportname, writable, bitmap); - return qemuMonitorBlockExportAdd(priv->mon, &nbdprops); - } else { - return qemuMonitorNBDServerAdd(priv->mon, src->nodeformat, - exportname, writable, bitmap); - } - } else { - /* older qemu versions didn't support configuring the exportname and - * took the 'drivealias' as the export name */ - return qemuMonitorNBDServerAdd(priv->mon, drivealias, NULL, writable, NULL); - } + if ((nbdprops = qemuBlockExportGetNBDProps(src->nodeformat, exportname, + writable, bitmaps))) + return qemuMonitorBlockExportAdd(priv->mon, &nbdprops); - return 0; + return -1; } -- 2.31.1

2 1