[libvirt PATCH v3 00/11] Add ability to create mediated devices in libvirt
by Jonathon Jongsma
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
4 years, 5 months
[RFC] Expanding hooks API for running several scripts by one call virHookCall
by Dmitry Nesterenko
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
4 years, 5 months
[PATCH 1/1] manpages/virsh.rst: clarify numatune memory migration on Linux
by Daniel Henrique Barboza
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
4 years, 5 months
[PATCH 1/1] qemuDomainSetNumaParamsLive: set nodeset for root cgroup
by Daniel Henrique Barboza
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
4 years, 5 months
[PATCH] virsysinfo: Don't leak fw_cfg
by Michal Privoznik
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
4 years, 5 months
[PATCH 0/9] Some Coverity memory leak patches
by John Ferlan
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
4 years, 5 months
[libvirt PATCH 0/5] Avoid deprecated commands for migration parameters
by Jiri Denemark
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
4 years, 5 months
[libvirt PATCH v2 00/10] Add ability to create mediated devices in libvirt
by Jonathon Jongsma
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
4 years, 5 months
[PATCH libvirt v1 0/6] Fix ZPCI address auto-generation on s390
by Shalini Chellathurai Saroja
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
4 years, 5 months
[PATCH v3 0/7] Add Security Guest doc and check for capabilities cache validation
by Paulo de Rezende Pinatti
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
4 years, 5 months
