- Devel - libvirt List Archives

[libvirt PATCH v3 00/11] Add ability to create mediated devices in libvirt
by Jonathon Jongsma 16 Jun '20

16 Jun '20

This is the first portion of an effort to support persistent mediated devices with libvirt. This first series simply enables creating and destroying non-persistent mediated devices via the virNodeDeviceCreateXML() and virNodeDeviceDestroy() functions. The 'mdevctl' utility[1] provides the backend implementation. Changes in v3: - Includes all of the changes mentioned by Michal - makes iommuGroup element optional for the nodedev schema (per Erik) - substitutes a placeholder for the path to the mdevctl binary before comparing to the expected output [1] https://github.com/mdevctl/mdevctl Jonathon Jongsma (11): nodedev: make iommuGroup optional for mdevs nodedev: factor out nodeDeviceHasCapability() nodedev: add support for mdev attributes nodedev: refactor nodeDeviceFindNewDevice() nodedev: store mdev UUID in mdev caps nodedev: add mdev support to virNodeDeviceCreateXML() nodedev: Build a non-loadable driver lib nodedev: Add testing for 'mdevctl start' nodedev: add mdev support to virNodeDeviceDestroy() nodedev: Add testing for 'mdevctl stop' docs: note node device fields that are read-only build-aux/syntax-check.mk | 2 +- docs/formatnode.html.in | 21 +- docs/schemas/nodedev.rng | 18 +- libvirt.spec.in | 2 + m4/virt-external-programs.m4 | 3 + src/conf/node_device_conf.c | 64 +++- src/conf/node_device_conf.h | 3 + src/conf/virnodedeviceobj.c | 34 ++ src/conf/virnodedeviceobj.h | 3 + src/libvirt_private.syms | 3 + src/node_device/Makefile.inc.am | 23 +- src/node_device/node_device_driver.c | 360 ++++++++++++++++-- src/node_device/node_device_driver.h | 8 + src/node_device/node_device_udev.c | 5 +- src/util/virmdev.c | 12 + src/util/virmdev.h | 11 + tests/Makefile.am | 14 + ...019_36ea_4111_8f0a_8c9a70e21366-start.argv | 1 + ...019_36ea_4111_8f0a_8c9a70e21366-start.json | 1 + ...d39_495e_4243_ad9f_beb3f14c23d9-start.argv | 1 + ...d39_495e_4243_ad9f_beb3f14c23d9-start.json | 1 + ...916_1ca8_49ac_b176_871d16c13076-start.argv | 1 + ...916_1ca8_49ac_b176_871d16c13076-start.json | 1 + tests/nodedevmdevctldata/mdevctl-stop.argv | 1 + tests/nodedevmdevctltest.c | 304 +++++++++++++++ ...v_d069d019_36ea_4111_8f0a_8c9a70e21366.xml | 7 + ...v_d2441d39_495e_4243_ad9f_beb3f14c23d9.xml | 9 + ...v_fedc4916_1ca8_49ac_b176_871d16c13076.xml | 8 + 28 files changed, 853 insertions(+), 68 deletions(-) create mode 100644 tests/nodedevmdevctldata/mdev_d069d019_36ea_4111_8f0a_8c9a70e21366-start.argv create mode 100644 tests/nodedevmdevctldata/mdev_d069d019_36ea_4111_8f0a_8c9a70e21366-start.json create mode 100644 tests/nodedevmdevctldata/mdev_d2441d39_495e_4243_ad9f_beb3f14c23d9-start.argv create mode 100644 tests/nodedevmdevctldata/mdev_d2441d39_495e_4243_ad9f_beb3f14c23d9-start.json create mode 100644 tests/nodedevmdevctldata/mdev_fedc4916_1ca8_49ac_b176_871d16c13076-start.argv create mode 100644 tests/nodedevmdevctldata/mdev_fedc4916_1ca8_49ac_b176_871d16c13076-start.json create mode 100644 tests/nodedevmdevctldata/mdevctl-stop.argv create mode 100644 tests/nodedevmdevctltest.c create mode 100644 tests/nodedevschemadata/mdev_d069d019_36ea_4111_8f0a_8c9a70e21366.xml create mode 100644 tests/nodedevschemadata/mdev_d2441d39_495e_4243_ad9f_beb3f14c23d9.xml create mode 100644 tests/nodedevschemadata/mdev_fedc4916_1ca8_49ac_b176_871d16c13076.xml -- 2.21.3

3 29

[RFC] Expanding hooks API for running several scripts by one call virHookCall
by Dmitry Nesterenko 16 Jun '20

16 Jun '20

Hi, all. I have the proposal about subject. Libvirt hook calls only one script (/etc/libvirt/hooks/<driver>) now. This is not convenient if scripts for hook are provided by many vendors. Script one vendor can replace previously installed script other vendor. Let's use usual linux scheme - running all scripts from directory /etc/libvirt/hooks/<driver>.d in alphabetical order. If we find script in old place we will execute it before others in subdirectory for backward compatibility. I want to implement patch for this scheme. What is your opinion? Dmitry

3 2

[PATCH 1/1] manpages/virsh.rst: clarify numatune memory migration on Linux
by Daniel Henrique Barboza 16 Jun '20

16 Jun '20

On Linux, changing the nodeset on 'numatune' does not imply that the guest memory will be migrated on the spot to the new nodeset. The memory migration is tied on guest usage of the memory pages, and an idle guest will take longer to have its memory migrated to the new nodeset. This is a behavior explained in detail in the Linux kernel documentation in Documentation/admin-guide/cgroup-v1/cpusets.rst. The user doesn't need this level of detail though - just needs his/her expectations under check. Running 'numastat' and hoping for instant memory migration from the previous nodeset to the new one is not viable. There's also parts of the memory that are locked by QEMU in the same place, e.g. when VFIO devices are present. Let's also mention it as another factor that impacts the results the user might expect from NUMA memory migration with numatune. Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com> --- docs/manpages/virsh.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index 969a4d5543..ff32338f43 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -3395,6 +3395,13 @@ If *--live* is specified, set scheduler information of a running guest. If *--config* is specified, affect the next boot of a persistent guest. If *--current* is specified, affect the current guest state. +For running guests in Linux hosts, the changes made in the domain's +numa parameters does not imply that the guest memory will be moved to a +different nodeset immediately. The memory migration depends on the +guest activity, and the memory of an idle guest will remain in its +previous nodeset for longer. The presence of VFIO devices will also +lock parts of the guest memory in the same nodeset used to start the +guest, regardless of nodeset changes. perf ---- -- 2.26.2

2 3

[PATCH 1/1] qemuDomainSetNumaParamsLive: set nodeset for root cgroup
by Daniel Henrique Barboza 16 Jun '20

16 Jun '20

This function handles the change of NUMA nodeset for a given guest, setting CpusetMems for the emulator, vcpus and IOThread sub-groups. It doesn't set the same nodeset to the root cgroup though. This means that cpuset.mems of the root cgroup ends up holding the new nodeset and the old nodeset as well. For a guest with placement=strict, nodeset='0', doing virsh numatune <vm> 0 8 --live Will make cpuset.mems of emulator, vcpus and iothread to be "8", but cpuset.mems of the root cgroup will be "0,8". This means that any new tasks that ends up landing in the root cgroup, aside from the emulator/vcpus/iothread sub-groups, will be split between the old nodeset and the new nodeset, which is not what we want. Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com> --- src/qemu/qemu_driver.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 88517ba6a7..59d322c8f3 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -9702,6 +9702,10 @@ qemuDomainSetNumaParamsLive(virDomainObjPtr vm, virCgroupFree(&cgroup_temp); } + /* set nodeset for root cgroup */ + if (virCgroupSetCpusetMems(priv->cgroup, nodeset_str) < 0) + goto cleanup; + ret = 0; cleanup: virCgroupFree(&cgroup_temp); -- 2.26.2

2 1

[PATCH] virsysinfo: Don't leak fw_cfg
by Michal Privoznik 16 Jun '20

16 Jun '20

In v6.4.0-72-g3dda889a44 I've introduced parsing and formatting of new sysinfo type 'fwcfg'. However, I've forgot to introduce code that would free parsed data. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/util/virsysinfo.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c index 52e576f129..db84339bda 100644 --- a/src/util/virsysinfo.c +++ b/src/util/virsysinfo.c @@ -131,6 +131,19 @@ void virSysinfoOEMStringsDefFree(virSysinfoOEMStringsDefPtr def) VIR_FREE(def); } + +static void +virSysinfoFWCfgDefClear(virSysinfoFWCfgDefPtr def) +{ + if (!def) + return; + + VIR_FREE(def->name); + VIR_FREE(def->value); + VIR_FREE(def->file); +} + + /** * virSysinfoDefFree: * @def: a sysinfo structure @@ -184,6 +197,10 @@ void virSysinfoDefFree(virSysinfoDefPtr def) virSysinfoOEMStringsDefFree(def->oemStrings); + for (i = 0; i < def->nfw_cfgs; i++) + virSysinfoFWCfgDefClear(&def->fw_cfgs[i]); + VIR_FREE(def->fw_cfgs); + VIR_FREE(def); } -- 2.26.2

2 1

[PATCH 0/9] Some Coverity memory leak patches
by John Ferlan 16 Jun '20

16 Jun '20

Even though I changed roles, the cron job still runs. I recently updated to a newer coverity version and it found some new stuff and even more false positives. It's still very unhappy with the usage of GLIB_DEPRECATED_ENUMERATOR_IN_* macros for *glib/gspawn.h and *gobject/gparam.h, but I can work around that. I had to disable the use_after_free type checking because the virObject to GObject change just caused a large number of possible false positives for virObjectUnref usages (coverity cannot keep track of all the counts). Anyway, I had a few spare cycles, so I figured I'd pass along at least the memory leak and usage things that were found. I haven't posted in a while so hopefully I haven't missed some subtlety. FWIW: I no longer have commit access so I'm at the mercy of someone else pushing my patches now. John Ferlan (9): util: Fix memory leak in virAuthGetCredential util: Fix memory leak in virAuthConfigLookup lxc: Fix memory leak in virLXCControllerPopulateDevices util: Fix memory leak in virPCIProbeStubDriver test: Fix memory leak in testParseXMLDocFromFile conf: Fix memory leak in openvzWriteConfigParam conf: Fix memory leak in openvzReadFSConf conf: Fix memory leak in virCPUDefParseXML util: Avoid using wrong free function src/conf/cpu_conf.c | 2 +- src/lxc/lxc_controller.c | 3 ++- src/openvz/openvz_conf.c | 7 ++----- src/remote/remote_driver.c | 2 +- src/test/test_driver.c | 2 +- src/util/iohelper.c | 7 +++++++ src/util/virauth.c | 5 +---- src/util/virauthconfig.c | 4 ++-- src/util/virauthconfig.h | 2 +- src/util/virpci.c | 1 + tests/virauthconfigtest.c | 2 +- 11 files changed, 20 insertions(+), 17 deletions(-) -- 2.25.4

3 16

[libvirt PATCH 0/5] Avoid deprecated commands for migration parameters
by Jiri Denemark 16 Jun '20

16 Jun '20

Jiri Denemark (5): qemu: Probe for a few params supported by migrate-set-parameters qemu: Avoid deprecated migrate_set_speed QMP command qemu: Avoid deprecated migrate_set_downtime QMP command qemu: Avoid deprecated query-migrate-cache-size QMP command qemu: Avoid deprecated migrate-set-cache-size QMP command src/qemu/qemu_capabilities.c | 8 ++ src/qemu/qemu_capabilities.h | 5 + src/qemu/qemu_driver.c | 92 +++++++++++++++---- src/qemu/qemu_migration.c | 53 +++++++++-- src/qemu/qemu_migration_params.c | 3 +- .../caps_2.10.0.aarch64.xml | 2 + .../caps_2.10.0.ppc64.xml | 2 + .../caps_2.10.0.s390x.xml | 2 + .../caps_2.10.0.x86_64.xml | 2 + .../caps_2.11.0.s390x.xml | 3 + .../caps_2.11.0.x86_64.xml | 3 + .../caps_2.12.0.aarch64.xml | 3 + .../caps_2.12.0.ppc64.xml | 3 + .../caps_2.12.0.s390x.xml | 3 + .../caps_2.12.0.x86_64.xml | 3 + .../qemucapabilitiesdata/caps_2.8.0.s390x.xml | 2 + .../caps_2.8.0.x86_64.xml | 2 + .../qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 2 + .../qemucapabilitiesdata/caps_2.9.0.s390x.xml | 2 + .../caps_2.9.0.x86_64.xml | 2 + .../qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 3 + .../caps_3.0.0.riscv32.xml | 3 + .../caps_3.0.0.riscv64.xml | 3 + .../qemucapabilitiesdata/caps_3.0.0.s390x.xml | 3 + .../caps_3.0.0.x86_64.xml | 3 + .../qemucapabilitiesdata/caps_3.1.0.ppc64.xml | 3 + .../caps_3.1.0.x86_64.xml | 3 + .../caps_4.0.0.aarch64.xml | 3 + .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 3 + .../caps_4.0.0.riscv32.xml | 3 + .../caps_4.0.0.riscv64.xml | 3 + .../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 3 + .../caps_4.0.0.x86_64.xml | 3 + .../caps_4.1.0.x86_64.xml | 3 + .../caps_4.2.0.aarch64.xml | 3 + .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 3 + .../qemucapabilitiesdata/caps_4.2.0.s390x.xml | 3 + .../caps_4.2.0.x86_64.xml | 3 + .../caps_5.0.0.aarch64.xml | 3 + .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 3 + .../caps_5.0.0.riscv64.xml | 3 + .../caps_5.0.0.x86_64.xml | 3 + .../caps_5.1.0.x86_64.xml | 3 + tests/qemumonitorjsontest.c | 6 +- 44 files changed, 240 insertions(+), 32 deletions(-) -- 2.27.0

2 7

[libvirt PATCH v2 00/10] Add ability to create mediated devices in libvirt
by Jonathon Jongsma 16 Jun '20

16 Jun '20

Apologies for the delay in posting the second version of this series. This is the first portion of an effort to support persistent mediated devices with libvirt. This first series simply enables creating and destroying non-persistent mediated devices via the virNodeDeviceCreateXML() and virNodeDeviceDestroy() functions. The 'mdevctl' utility[1] provides the backend implementation. Changes in v2: - review findings fixed - Added Unit testing - passed JSON config via stdin instead of a temporary file (see portability note in patch 5) [1] https://github.com/mdevctl/mdevctl Jonathon Jongsma (10): nodedev: factor out nodeDeviceHasCapability() nodedev: add support for mdev attributes nodedev: refactor nodeDeviceFindNewDevice() nodedev: store mdev UUID in mdev caps nodedev: add mdev support to virNodeDeviceCreateXML() nodedev: Build a non-loadable driver lib nodedev: Add testing for 'mdevctl start' nodedev: add mdev support to virNodeDeviceDestroy() nodedev: Add testing for 'mdevctl stop' docs: note node device fields that are read-only build-aux/syntax-check.mk | 2 +- docs/formatnode.html.in | 16 +- docs/schemas/nodedev.rng | 6 + libvirt.spec.in | 2 + m4/virt-external-programs.m4 | 3 + src/conf/node_device_conf.c | 60 ++- src/conf/node_device_conf.h | 3 + src/conf/virnodedeviceobj.c | 34 ++ src/conf/virnodedeviceobj.h | 3 + src/libvirt_private.syms | 3 + src/node_device/Makefile.inc.am | 23 +- src/node_device/node_device_driver.c | 377 ++++++++++++++++-- src/node_device/node_device_driver.h | 9 + src/node_device/node_device_udev.c | 5 +- src/util/virmdev.c | 12 + src/util/virmdev.h | 11 + tests/Makefile.am | 14 + ...019_36ea_4111_8f0a_8c9a70e21366-start.argv | 1 + ...019_36ea_4111_8f0a_8c9a70e21366-start.json | 1 + ...d39_495e_4243_ad9f_beb3f14c23d9-start.argv | 1 + ...d39_495e_4243_ad9f_beb3f14c23d9-start.json | 1 + ...916_1ca8_49ac_b176_871d16c13076-start.argv | 1 + ...916_1ca8_49ac_b176_871d16c13076-start.json | 1 + tests/nodedevmdevctldata/mdevctl-stop.argv | 1 + tests/nodedevmdevctltest.c | 300 ++++++++++++++ ...v_d069d019_36ea_4111_8f0a_8c9a70e21366.xml | 8 + ...v_d2441d39_495e_4243_ad9f_beb3f14c23d9.xml | 10 + ...v_fedc4916_1ca8_49ac_b176_871d16c13076.xml | 9 + 28 files changed, 862 insertions(+), 55 deletions(-) create mode 100644 tests/nodedevmdevctldata/mdev_d069d019_36ea_4111_8f0a_8c9a70e21366-start.argv create mode 100644 tests/nodedevmdevctldata/mdev_d069d019_36ea_4111_8f0a_8c9a70e21366-start.json create mode 100644 tests/nodedevmdevctldata/mdev_d2441d39_495e_4243_ad9f_beb3f14c23d9-start.argv create mode 100644 tests/nodedevmdevctldata/mdev_d2441d39_495e_4243_ad9f_beb3f14c23d9-start.json create mode 100644 tests/nodedevmdevctldata/mdev_fedc4916_1ca8_49ac_b176_871d16c13076-start.argv create mode 100644 tests/nodedevmdevctldata/mdev_fedc4916_1ca8_49ac_b176_871d16c13076-start.json create mode 100644 tests/nodedevmdevctldata/mdevctl-stop.argv create mode 100644 tests/nodedevmdevctltest.c create mode 100644 tests/nodedevschemadata/mdev_d069d019_36ea_4111_8f0a_8c9a70e21366.xml create mode 100644 tests/nodedevschemadata/mdev_d2441d39_495e_4243_ad9f_beb3f14c23d9.xml create mode 100644 tests/nodedevschemadata/mdev_fedc4916_1ca8_49ac_b176_871d16c13076.xml -- 2.21.3

3 33

[PATCH libvirt v1 0/6] Fix ZPCI address auto-generation on s390
by Shalini Chellathurai Saroja 16 Jun '20

16 Jun '20

The ZPCI address validation or autogeneration does not work as expected in the following scenarios 1. uid = 0 and fid = 0 2. uid = 0 and fid > 0 3. uid = 0 and fid not specified 4. uid not specified and fid > 0 5. 2 ZPCI devices with uid > 0 and fid not specified. This is because of the following reasons 1. If uid = 0 or fid = 0 the code assumes that user has not specified the corresponding address 2. If either uid or fid is provided, the code assumes that both uid and fid addresses are specified by the user. This patch fixes these issues. Shalini Chellathurai Saroja (6): conf: fix ZPCI address validation on s390 tests: qemu: add tests for ZPCI on s390 conf: fix ZPCI address auto-generation on s390 qemu: move ZPCI uid validation into device validation tests: qemu: add more tests for ZPCI on S390 tests: add test with PCI and CCW device src/conf/device_conf.c | 45 ++++++-------- src/conf/domain_addr.c | 59 +++++++++++++------ src/conf/domain_conf.c | 2 +- src/libvirt_private.syms | 4 +- src/qemu/qemu_validate.c | 26 +++++++- src/util/virpci.c | 23 ++------ src/util/virpci.h | 6 +- .../hostdev-vfio-zpci-autogenerate-fids.args | 31 ++++++++++ .../hostdev-vfio-zpci-autogenerate-fids.xml | 29 +++++++++ .../hostdev-vfio-zpci-autogenerate-uids.args | 31 ++++++++++ .../hostdev-vfio-zpci-autogenerate-uids.xml | 29 +++++++++ .../hostdev-vfio-zpci-ccw-memballoon.args | 28 +++++++++ .../hostdev-vfio-zpci-ccw-memballoon.xml | 17 ++++++ .../hostdev-vfio-zpci-duplicate.xml | 30 ++++++++++ ...ostdev-vfio-zpci-invalid-uid-valid-fid.xml | 21 +++++++ .../hostdev-vfio-zpci-multidomain-many.args | 6 +- .../hostdev-vfio-zpci-set-zero.xml | 21 +++++++ .../hostdev-vfio-zpci-uid-set-zero.xml | 20 +++++++ tests/qemuxml2argvtest.c | 25 ++++++++ .../hostdev-vfio-zpci-multidomain-many.xml | 6 +- 20 files changed, 387 insertions(+), 72 deletions(-) create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-fids.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-fids.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-uids.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-uids.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-ccw-memballoon.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-ccw-memballoon.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-duplicate.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-invalid-uid-valid-fid.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-set-zero.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-uid-set-zero.xml -- 2.21.1

5 35

[PATCH v3 0/7] Add Security Guest doc and check for capabilities cache validation
by Paulo de Rezende Pinatti 16 Jun '20

16 Jun '20

This series introduces the concept of a 'Secure Guest' feature which covers on s390 IBM Secure Execution and on x86 AMD Secure Encrypted Virtualization. Besides adding documentation for IBM Secure Execution it also adds checks during validation of the qemu capabilities cache. These checks per architecture can be performed for IBM Secure Execution on s390 and AMD Secure Encrypted Virtualization on AMD x86 CPUs (both checks implemented in this series). For s390 the verification consists of: - checking if /sys/firmware/uv is available: meaning the HW facility is available and the host OS supports it; - checking if the kernel cmdline contains 'prot_virt=1': meaning the host OS wants to use the feature. For AMD Secure Encrypted Virtualization the verification consists of: - checking if /sys/module/kvm_amd/parameters/sev contains the value '1': meaning SEV is enabled in the host kernel; - checking if /dev/sev exists Whenever the availability of the feature does not match the secure guest flag in the cache then libvirt will re-build it in order to pick up the new set of capabilities available. Additionally, this series adds the same aforementioned checks to the virt-host-validate tool to facilitate the manual verification process for users. Changes in v3: [Patch 1] Reworked auxiliary functions to eliminate unnecessary wrappers Moved arg normalization to MatchParam function Replaced macro VIR_CMDLINE_STR_CMP by the simpler function virKernelCmdlineStrCmp Renamed function SkipDbQuote to SkipQuote Renamed flag SEARCH_STICKY to SEARCH_FIRST Reworked some input values in unit test for better test coverage [Patches 4, 5] Added empty lines between if statements link to v2: https://www.redhat.com/archives/libvir-list/2020-May/msg01175.html Boris Fiuczynski (3): tools: secure guest check on s390 in virt-host-validate tools: secure guest check for AMD in virt-host-validate docs: update AMD launch secure description Paulo de Rezende Pinatti (3): util: introduce a parser for kernel cmdline arguments qemu: check if s390 secure guest support is enabled qemu: check if AMD secure guest support is enabled Viktor Mihajlovski (1): docs: Describe protected virtualization guest setup docs/kbase.html.in | 3 + docs/kbase/launch_security_sev.rst | 9 +- docs/kbase/s390_protected_virt.rst | 189 +++++++++++++++++++++++++++++ src/libvirt_private.syms | 2 + src/qemu/qemu_capabilities.c | 76 ++++++++++++ src/util/virutil.c | 188 ++++++++++++++++++++++++++++ src/util/virutil.h | 17 +++ tests/utiltest.c | 144 ++++++++++++++++++++++ tools/virt-host-validate-common.c | 88 +++++++++++++- tools/virt-host-validate-common.h | 5 + tools/virt-host-validate-qemu.c | 4 + 11 files changed, 720 insertions(+), 5 deletions(-) create mode 100644 docs/kbase/s390_protected_virt.rst -- 2.26.2

3 21