February 2022 - Devel - libvirt List Archives

[libvirt PATCH] drivers: Group global feature together
by Andrea Bolognani 08 Apr '22

08 Apr '22

All these features are supposed to be handled by the call to virDriverFeatureIsGlobal() placed right above the switch statement, so group them together and add a comment. If any of these features is actually encountered as part of the switch statements, that means there's a bug in the driver and we should error out. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Applies on top of [PATCH 0/8] driver: Fix handling of driver feature flags https://listman.redhat.com/archives/libvir-list/2022-February/msg00644.html src/ch/ch_driver.c | 13 +++++++------ src/esx/esx_driver.c | 21 +++++++++++---------- src/libxl/libxl_driver.c | 16 +++++++++------- src/lxc/lxc_driver.c | 11 ++++++----- src/network/bridge_driver.c | 15 ++++++++------- src/openvz/openvz_driver.c | 16 +++++++++------- src/qemu/qemu_driver.c | 16 +++++++++------- 7 files changed, 59 insertions(+), 49 deletions(-) diff --git a/src/ch/ch_driver.c b/src/ch/ch_driver.c index ac9298c0b5..9cbd7b71df 100644 --- a/src/ch/ch_driver.c +++ b/src/ch/ch_driver.c @@ -928,23 +928,24 @@ chConnectSupportsFeature(virConnectPtr conn, return supported; switch ((virDrvFeature) feature) { + case VIR_DRV_FEATURE_REMOTE: + case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: + case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: + case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: case VIR_DRV_FEATURE_TYPED_PARAM_STRING: case VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER: - return 1; + case VIR_DRV_FEATURE_FD_PASSING: + /* Should have already been handled by virDriverFeatureIsGlobal() */ + return -1; case VIR_DRV_FEATURE_MIGRATION_V2: case VIR_DRV_FEATURE_MIGRATION_V3: case VIR_DRV_FEATURE_MIGRATION_P2P: case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION: - case VIR_DRV_FEATURE_FD_PASSING: case VIR_DRV_FEATURE_XML_MIGRATABLE: case VIR_DRV_FEATURE_MIGRATION_OFFLINE: case VIR_DRV_FEATURE_MIGRATION_PARAMS: case VIR_DRV_FEATURE_MIGRATION_DIRECT: case VIR_DRV_FEATURE_MIGRATION_V1: - case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: - case VIR_DRV_FEATURE_REMOTE: - case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: - case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: default: return 0; } diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c index 3149f3e963..6e5f9c8cc1 100644 --- a/src/esx/esx_driver.c +++ b/src/esx/esx_driver.c @@ -1024,7 +1024,17 @@ esxConnectSupportsFeature(virConnectPtr conn, int feature) return supported; switch ((virDrvFeature) feature) { - case VIR_DRV_FEATURE_MIGRATION_V1: + case VIR_DRV_FEATURE_REMOTE: + case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: + case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: + case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: + case VIR_DRV_FEATURE_TYPED_PARAM_STRING: + case VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER: + case VIR_DRV_FEATURE_FD_PASSING: + /* Should have already been handled by virDriverFeatureIsGlobal() */ + return -1; + + case VIR_DRV_FEATURE_MIGRATION_V1: supportsVMotion = esxSupportsVMotion(priv); if (supportsVMotion == esxVI_Boolean_Undefined) @@ -1034,10 +1044,6 @@ esxConnectSupportsFeature(virConnectPtr conn, int feature) return priv->vCenter && supportsVMotion == esxVI_Boolean_True ? 1 : 0; - case VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER: - return 1; - - case VIR_DRV_FEATURE_FD_PASSING: case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION: case VIR_DRV_FEATURE_MIGRATION_DIRECT: case VIR_DRV_FEATURE_MIGRATION_OFFLINE: @@ -1045,11 +1051,6 @@ esxConnectSupportsFeature(virConnectPtr conn, int feature) case VIR_DRV_FEATURE_MIGRATION_PARAMS: case VIR_DRV_FEATURE_MIGRATION_V2: case VIR_DRV_FEATURE_MIGRATION_V3: - case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: - case VIR_DRV_FEATURE_REMOTE: - case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: - case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: - case VIR_DRV_FEATURE_TYPED_PARAM_STRING: case VIR_DRV_FEATURE_XML_MIGRATABLE: default: return 0; diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index 478ab3e941..46596978d4 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -5706,22 +5706,24 @@ libxlConnectSupportsFeature(virConnectPtr conn, int feature) return supported; switch ((virDrvFeature) feature) { - case VIR_DRV_FEATURE_MIGRATION_V3: + case VIR_DRV_FEATURE_REMOTE: + case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: + case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: + case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: case VIR_DRV_FEATURE_TYPED_PARAM_STRING: + case VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER: + case VIR_DRV_FEATURE_FD_PASSING: + /* Should have already been handled by virDriverFeatureIsGlobal() */ + return -1; + case VIR_DRV_FEATURE_MIGRATION_V3: case VIR_DRV_FEATURE_MIGRATION_PARAMS: case VIR_DRV_FEATURE_MIGRATION_P2P: - case VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER: return 1; - case VIR_DRV_FEATURE_FD_PASSING: case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION: case VIR_DRV_FEATURE_MIGRATION_DIRECT: case VIR_DRV_FEATURE_MIGRATION_OFFLINE: case VIR_DRV_FEATURE_MIGRATION_V1: case VIR_DRV_FEATURE_MIGRATION_V2: - case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: - case VIR_DRV_FEATURE_REMOTE: - case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: - case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: case VIR_DRV_FEATURE_XML_MIGRATABLE: default: return 0; diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c index 020ec257ae..023292a75a 100644 --- a/src/lxc/lxc_driver.c +++ b/src/lxc/lxc_driver.c @@ -1627,10 +1627,15 @@ lxcConnectSupportsFeature(virConnectPtr conn, int feature) return supported; switch ((virDrvFeature) feature) { + case VIR_DRV_FEATURE_REMOTE: + case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: + case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: + case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: case VIR_DRV_FEATURE_TYPED_PARAM_STRING: case VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER: - return 1; case VIR_DRV_FEATURE_FD_PASSING: + /* Should have already been handled by virDriverFeatureIsGlobal() */ + return -1; case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION: case VIR_DRV_FEATURE_MIGRATION_DIRECT: case VIR_DRV_FEATURE_MIGRATION_OFFLINE: @@ -1639,10 +1644,6 @@ lxcConnectSupportsFeature(virConnectPtr conn, int feature) case VIR_DRV_FEATURE_MIGRATION_V1: case VIR_DRV_FEATURE_MIGRATION_V2: case VIR_DRV_FEATURE_MIGRATION_V3: - case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: - case VIR_DRV_FEATURE_REMOTE: - case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: - case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: case VIR_DRV_FEATURE_XML_MIGRATABLE: default: return 0; diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index d6ae05360b..559600d2af 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -866,23 +866,24 @@ networkConnectSupportsFeature(virConnectPtr conn, int feature) return supported; switch ((virDrvFeature) feature) { + case VIR_DRV_FEATURE_REMOTE: + case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: + case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: + case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: + case VIR_DRV_FEATURE_TYPED_PARAM_STRING: case VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER: - return 1; + case VIR_DRV_FEATURE_FD_PASSING: + /* Should have already been handled by virDriverFeatureIsGlobal() */ + return -1; case VIR_DRV_FEATURE_MIGRATION_V2: case VIR_DRV_FEATURE_MIGRATION_V3: case VIR_DRV_FEATURE_MIGRATION_P2P: case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION: - case VIR_DRV_FEATURE_FD_PASSING: - case VIR_DRV_FEATURE_TYPED_PARAM_STRING: case VIR_DRV_FEATURE_XML_MIGRATABLE: case VIR_DRV_FEATURE_MIGRATION_OFFLINE: case VIR_DRV_FEATURE_MIGRATION_PARAMS: case VIR_DRV_FEATURE_MIGRATION_DIRECT: case VIR_DRV_FEATURE_MIGRATION_V1: - case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: - case VIR_DRV_FEATURE_REMOTE: - case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: - case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: default: return 0; } diff --git a/src/openvz/openvz_driver.c b/src/openvz/openvz_driver.c index aa1db09540..c034fd5af9 100644 --- a/src/openvz/openvz_driver.c +++ b/src/openvz/openvz_driver.c @@ -1944,22 +1944,24 @@ openvzConnectSupportsFeature(virConnectPtr conn G_GNUC_UNUSED, int feature) return supported; switch ((virDrvFeature) feature) { + case VIR_DRV_FEATURE_REMOTE: + case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: + case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: + case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: + case VIR_DRV_FEATURE_TYPED_PARAM_STRING: + case VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER: + case VIR_DRV_FEATURE_FD_PASSING: + /* Should have already been handled by virDriverFeatureIsGlobal() */ + return -1; case VIR_DRV_FEATURE_MIGRATION_PARAMS: case VIR_DRV_FEATURE_MIGRATION_V3: - case VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER: return 1; - case VIR_DRV_FEATURE_FD_PASSING: case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION: case VIR_DRV_FEATURE_MIGRATION_DIRECT: case VIR_DRV_FEATURE_MIGRATION_OFFLINE: case VIR_DRV_FEATURE_MIGRATION_P2P: case VIR_DRV_FEATURE_MIGRATION_V1: case VIR_DRV_FEATURE_MIGRATION_V2: - case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: - case VIR_DRV_FEATURE_REMOTE: - case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: - case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: - case VIR_DRV_FEATURE_TYPED_PARAM_STRING: case VIR_DRV_FEATURE_XML_MIGRATABLE: default: return 0; diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index f1f708e511..433ba09745 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1182,23 +1182,25 @@ qemuConnectSupportsFeature(virConnectPtr conn, int feature) return supported; switch ((virDrvFeature) feature) { + case VIR_DRV_FEATURE_REMOTE: + case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: + case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: + case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: + case VIR_DRV_FEATURE_TYPED_PARAM_STRING: + case VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER: + case VIR_DRV_FEATURE_FD_PASSING: + /* Should have already been handled by virDriverFeatureIsGlobal() */ + return -1; case VIR_DRV_FEATURE_MIGRATION_V2: case VIR_DRV_FEATURE_MIGRATION_V3: case VIR_DRV_FEATURE_MIGRATION_P2P: case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION: - case VIR_DRV_FEATURE_FD_PASSING: - case VIR_DRV_FEATURE_TYPED_PARAM_STRING: case VIR_DRV_FEATURE_XML_MIGRATABLE: case VIR_DRV_FEATURE_MIGRATION_OFFLINE: case VIR_DRV_FEATURE_MIGRATION_PARAMS: - case VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER: return 1; case VIR_DRV_FEATURE_MIGRATION_DIRECT: case VIR_DRV_FEATURE_MIGRATION_V1: - case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE: - case VIR_DRV_FEATURE_REMOTE: - case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK: - case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK: default: return 0; } -- 2.35.1

2 4

[PATCH v2 0/4] VirtioNet RSS support.
by Andrew Melnychenko 05 Apr '22

05 Apr '22

This series of patches add RSS property support for virtio-net-pci. Virtio RSS effectively works with TAP devices, it requires additional vectors for VirtioNet, queues for TAP device, and vCPU cores. Example of device configuration: ``` <interface type="network"> <mac address="52:54:00:c4:90:25"/> <source network="default"/> <model type="virtio"/> <driver name="qemu" queues="9" rss="on" rss_hash_report="off"/> <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/> </interface> ``` Capability "rss" enables RSS, "rss_hash_report" - enables hashes in vheader. For now, "rss" property will trigger "in-qemu" RSS in most cases. Current Qemu(6.2) supports eBPF RSS that may require additional capabilities. In future, the helper will be provided. And this code is the base for VirtIO RSS. Changes since v1: * refactored patches * changed docs and tests Changes since RFC: * rebased and refactored * added tests * postponed the helper Andrew Melnychenko (4): domain_conf: Added configs for RSS and Hash report. qemu_capabilities: Added capabilites for qemu's "rss" and "hash". qemu_command: Added "rss" and "hash" properties. test: Added xml2argv and xml2xml tests. docs/formatdomain.rst | 18 ++++++++ docs/schemas/domaincommon.rng | 10 +++++ src/conf/domain_conf.c | 31 ++++++++++++- src/conf/domain_conf.h | 2 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 2 + src/qemu/qemu_validate.c | 14 ++++++ .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 + .../caps_5.2.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + .../caps_6.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 1 + .../caps_6.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 + .../caps_6.2.0.x86_64.xml | 1 + .../net-virtio-rss.x86_64-latest.args | 43 +++++++++++++++++++ tests/qemuxml2argvdata/net-virtio-rss.xml | 39 +++++++++++++++++ .../virtio-options.x86_64-latest.args | 2 +- tests/qemuxml2argvdata/virtio-options.xml | 2 +- tests/qemuxml2argvtest.c | 2 + 26 files changed, 178 insertions(+), 3 deletions(-) create mode 100644 tests/qemuxml2argvdata/net-virtio-rss.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/net-virtio-rss.xml -- 2.34.1

4 9

libvirt: introduce VIR_DOMAIN_DESTROY_REMOVE_LOGS flag
by Nikolay Shirokovskiy 05 Apr '22

05 Apr '22

The patch series based on discussion in RFC [1]. I wonder if we'd better add some property like "transient logs" instead of adding a flag to destoy API. Yes libguestfs uses virDomainDestroyFlags to terminate a VM and it is intended client of this new flag but it or other clients may want to use shutdown API or use autodestroy domains with same log behaviour. Then for the current task we only need to support this property in domain xml I guess. [1] removing VMs logs https://listman.redhat.com/archives/libvir-list/2022-February/msg00273.html Nikolay Shirokovskiy (3): libvirt: introduce VIR_DOMAIN_DESTROY_REMOVE_LOGS flag qemu: support VIR_DOMAIN_DESTROY_REMOVE_LOGS flag tools: support --remove-logs flag on destroing domain docs/manpages/virsh.rst | 7 +++++- include/libvirt/libvirt-domain.h | 1 + src/libvirt-domain.c | 6 +++++ src/qemu/qemu_domain.c | 41 ++++++++++++++++++++++++++++++++ src/qemu/qemu_domain.h | 4 ++++ src/qemu/qemu_driver.c | 8 ++++++- tools/virsh-domain.c | 8 ++++++- 7 files changed, 72 insertions(+), 3 deletions(-) -- 2.31.1

3 6

[PATCH v2 00/19] Refactoring conf to use XPath
by Kristina Hanicova 26 Mar '22

26 Mar '22

This is v2 from https://listman.redhat.com/archives/libvir-list/2021-April/msg00617.html Changes since v1: - rebase to the lastest git master This series reworks the outdated way of parsing XML to parsing by XPath, which is more obvious and saves a few lines of code. Kristina Hanicova (19): conf: Propagate xmlXPathContextPtr into virDomainHostdevSubsysUSBDefParseXML() Refactoring virDomainHostdevSubsysUSBDefParseXML() to use XPath conf: Propagate xmlXPathContextPtr into virDomainBlkioDeviceParseXML() Refactoring virDomainBlkioDeviceParseXML() to use XPath conf: Propagate xmlXPathContextPtr into virDomainHostdevSubsysPCIDefParseXML() Refactoring virDomainHostdevSubsysPCIDefParseXML() to use XPath conf: Propagate xmlXPathContextPtr into virDomainLeaseDefParseXML() Refactoring virDomainLeaseDefParseXML() to use XPath Refactoring virDomainFSDefParseXML() to use XPath Refactoring virDomainNetDefParseXML() to use XPath conf: Propagate xmlXPathContextPtr into virDomainChrDefParseTargetXML() Refactoring virDomainChrDefParseTargetXML() to use XPath Refactoring virDomainChrSourceDefParseXML() to use XPath Refactoring virDomainChrDefParseXML() to use XPath Refactoring virDomainSmartcardDefParseXML() to use XPath Refactoring virDomainGraphicsDefParseXMLSpice() to use XPath conf: Propagate xmlXPathContextPtr into virDomainVideoDriverDefParseXML() Refactoring virDomainVideoDriverDefParseXML() to use XPath Refactoring virDomainVideoDefParseXML() to use XPath src/conf/domain_conf.c | 1641 +++++++++++++++++----------------------- 1 file changed, 707 insertions(+), 934 deletions(-) -- 2.30.2

3 26

[libvirt][PATCH RESEND v10 0/5] Support query and use SGX
by Haibin Huang 16 Mar '22

16 Mar '22

Because the 5th patch was sent by mistake, so replace the 5th patch and send it again. This patch series provides support for enabling Intel's Software Guard Extensions (SGX) feature in guest VM. Giving the SGX support in QEMU had been merged. 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. It depends on QEMU fixing[1], which will move cpu QOM object from /machine/unattached/device[nn] to /machine/cpu[nn]. It requires libvirt to change the default cpu QOM object location once QEMU patch gets accepted, but it is out of this SGX patch scope. 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 does not support NUMA yet, since latest QEMU 6.2 release does not support NUMA. It should contain <devices> ... <memory model='sgx-epc'> <target> <size unit='KiB'>N</size> </target> </memory> ... </devices> [1] https://lists.nongnu.org/archive/html/qemu-devel/2022-01/msg03534.html Haibin Huang (3): qemu: provide support to query the SGX capability conf: expose SGX feature in domain capabilities Add unit test for domaincapsdata sgx Lin Yang (2): conf: Introduce SGX EPC element into device memory xml Update default CPU location in qemu QOM tree docs/formatdomain.rst | 9 +- docs/formatdomaincaps.html.in | 26 ++++ docs/schemas/domaincaps.rng | 22 ++- docs/schemas/domaincommon.rng | 1 + src/conf/domain_capabilities.c | 29 ++++ src/conf/domain_capabilities.h | 13 ++ src/conf/domain_conf.c | 6 + src/conf/domain_conf.h | 1 + src/conf/domain_validate.c | 16 ++ src/libvirt_private.syms | 1 + src/qemu/qemu_alias.c | 3 + src/qemu/qemu_capabilities.c | 137 ++++++++++++++++++ src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_capspriv.h | 4 + src/qemu/qemu_command.c | 1 + src/qemu/qemu_domain.c | 38 +++-- src/qemu/qemu_domain_address.c | 6 + src/qemu/qemu_driver.c | 1 + src/qemu/qemu_monitor.c | 10 ++ src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 84 ++++++++++- src/qemu/qemu_monitor_json.h | 9 ++ 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 + .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 4 + .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 4 + .../qemu_6.2.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_6.2.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 4 + .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 4 + .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 4 + tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 4 + .../caps_6.2.0.x86_64.replies | 22 ++- .../caps_6.2.0.x86_64.xml | 5 + .../caps_7.0.0.x86_64.replies | 22 ++- .../caps_7.0.0.x86_64.xml | 5 + tests/qemuxml2argvdata/sgx-epc.xml | 36 +++++ .../sgx-epc.x86_64-latest.xml | 52 +++++++ tests/qemuxml2xmltest.c | 2 + 138 files changed, 675 insertions(+), 30 deletions(-) create mode 100644 tests/qemuxml2argvdata/sgx-epc.xml create mode 100644 tests/qemuxml2xmloutdata/sgx-epc.x86_64-latest.xml -- 2.17.1

5 22

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

15 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 v3 00/29] ppc64 PowerNV machines support
by Daniel Henrique Barboza 15 Mar '22

15 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

[libvirt PATCH v2 0/1] meson: Fixes and improvements to handling of qemu_user and qemu_group
by Andrea Bolognani 09 Mar '22

09 Mar '22

Changes from [v1]: * most patches have been pushed; * added comments. [v1] https://listman.redhat.com/archives/libvir-list/2022-January/msg01189.html Andrea Bolognani (1): meson: Check for os-release's ID_LIKE in addition to ID meson.build | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) -- 2.34.1

2 4

[libvirt PATCH v2 0/6] Add support for 'blob' to virtio video device
by Jonathon Jongsma 09 Mar '22

09 Mar '22

Add support to libvirt for the 'blob' option for virtio video devices in qemu. Also do a little preparatory refactoring of the video device xml parsing code. Changes in v2: - Added some basic documentation - add a qemu capability - Make sure that the /dev/udmabuf device is accessible to qemu (cgroups, etc) Jonathon Jongsma (6): conf: Refactor video model parsing conf: switch to virXMLProp* functions conf: use enum variable for video type conf: add support for 'blob' in virtio video device qemu: Add capability for virtio-gpu.blob qemu: Implement 'blob' support for virtio gpu docs/formatdomain.rst | 6 + docs/schemas/domaincommon.rng | 5 + src/conf/domain_conf.c | 133 +++++++++--------- src/conf/domain_conf.h | 3 +- src/conf/domain_validate.c | 13 +- src/libxl/libxl_conf.c | 10 ++ src/libxl/libxl_domain.c | 11 ++ src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_cgroup.c | 28 ++-- src/qemu/qemu_command.c | 3 + src/qemu/qemu_domain.h | 1 + src/qemu/qemu_monitor_json.c | 16 ++- src/qemu/qemu_namespace.c | 22 +++ src/qemu/qemu_process.c | 7 + src/qemu/qemu_validate.c | 9 ++ .../caps_6.1.0.x86_64.xml | 1 + .../caps_6.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 + .../caps_6.2.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 1 + .../caps_7.0.0.x86_64.xml | 1 + .../video-virtio-blob-absent.args | 34 +++++ .../video-virtio-blob-absent.xml | 33 +++++ .../video-virtio-blob-off.args | 34 +++++ .../video-virtio-blob-off.xml | 33 +++++ .../video-virtio-blob-on.args | 34 +++++ .../qemuxml2argvdata/video-virtio-blob-on.xml | 33 +++++ .../video-virtio-vga-blob-on.args | 34 +++++ .../video-virtio-vga-blob-on.xml | 33 +++++ tests/qemuxml2argvtest.c | 12 ++ .../video-virtio-blob-absent.xml | 41 ++++++ .../video-virtio-blob-off.xml | 41 ++++++ .../video-virtio-blob-on.xml | 41 ++++++ .../video-virtio-vga-blob-on.xml | 41 ++++++ tests/qemuxml2xmltest.c | 12 ++ 36 files changed, 652 insertions(+), 84 deletions(-) create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-absent.args create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-absent.xml create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-off.args create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-off.xml create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-on.args create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-on.xml create mode 100644 tests/qemuxml2argvdata/video-virtio-vga-blob-on.args create mode 100644 tests/qemuxml2argvdata/video-virtio-vga-blob-on.xml create mode 100644 tests/qemuxml2xmloutdata/video-virtio-blob-absent.xml create mode 100644 tests/qemuxml2xmloutdata/video-virtio-blob-off.xml create mode 100644 tests/qemuxml2xmloutdata/video-virtio-blob-on.xml create mode 100644 tests/qemuxml2xmloutdata/video-virtio-vga-blob-on.xml -- 2.35.1

1 7

[libvirt PATCH] spec: Move virkey* manual pages from -daemon to -client
by Andrea Bolognani 08 Mar '22

08 Mar '22

The documentation included in these manual pages is mostly useful to users of the 'send-key' virsh command, and the virsh manual page refers to them, so it makes more sense to install them along with virsh instead of libvirtd. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- libvirt.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 0e6cd13bb2..6855b3a760 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1733,7 +1733,6 @@ exit 0 %{_mandir}/man8/virtlogd.8* %{_mandir}/man8/virtlockd.8* %{_mandir}/man8/virtproxyd.8* -%{_mandir}/man7/virkey*.7* %{_bindir}/virt-host-validate %{_bindir}/virt-admin @@ -2010,6 +2009,7 @@ exit 0 %{_mandir}/man1/virt-xml-validate.1* %{_mandir}/man1/virt-pki-query-dn.1* %{_mandir}/man1/virt-pki-validate.1* +%{_mandir}/man7/virkey*.7* %{_bindir}/virsh %{_bindir}/virt-xml-validate %{_bindir}/virt-pki-query-dn -- 2.34.1

2 2