July 2021 - Devel - libvirt List Archives

[libvirt PATCH] qemu_firmware: don't error out for unknown firmware features
by Pavel Hrdina 31 Jan '22

31 Jan '22

When QEMU introduces new firmware features libvirt will fail until we list that feature in our code as well which doesn't sound right. We should simply ignore the new feature until we add a proper support for it. Reported-by: Laszlo Ersek <lersek(a)redhat.com> Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/qemu/qemu_firmware.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c index 94e88ebe4b..e37a7edefa 100644 --- a/src/qemu/qemu_firmware.c +++ b/src/qemu/qemu_firmware.c @@ -567,6 +567,7 @@ qemuFirmwareFeatureParse(const char *path, virJSONValue *featuresJSON; g_autoptr(qemuFirmwareFeature) features = NULL; size_t nfeatures; + size_t nparsed = 0; size_t i; if (!(featuresJSON = virJSONValueObjectGetArray(doc, "features"))) { @@ -586,17 +587,16 @@ qemuFirmwareFeatureParse(const char *path, int tmp; if ((tmp = qemuFirmwareFeatureTypeFromString(tmpStr)) <= 0) { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("unknown feature %s"), - tmpStr); - return -1; + VIR_DEBUG("unknown feature %s", tmpStr); + continue; } - features[i] = tmp; + features[nparsed] = tmp; + nparsed++; } fw->features = g_steal_pointer(&features); - fw->nfeatures = nfeatures; + fw->nfeatures = nparsed; return 0; } -- 2.30.2

4 10

[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

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

29 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

[RFC PATCH 00/10] VirtioNet RSS support
by Andrew Melnychenko 21 Oct '21

21 Oct '21

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. Qemu uses eBPF program as RSS driver. For loading RSS eBPF program, the helper is used. Path to the helper is provided by Qemu through "query-helper-paths" qmp command. The helper "qemu-ebpf-rss-helper" is built with Qemu and may differ from build to build. So it's required that the Qemu should provide a proper helper path. Libvirt would call the helper and receive the program and map fd through unix socket. Fds would be passed to Qemu in "ebpf_rss_fds" property by passing to child process or unix socket. If libvirt would fail at helper call or Qemu didn't provide the path, the Qemu would be launched without "ebpf_rss_fds" property. Without "ebpf_rss_fds" property, Qemu would try to load eBPF program by itself - usually, it would require additional system permissions. Qemu may use "in-qemu" RSS as a fallback option, which will not require system permissions, but doesn't work with vhost TAP. Qemu patches: https://lists.nongnu.org/archive/html/qemu-devel/2021-07/msg03535.html Andrew Melnychenko (10): 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. virsocket: Added receive for multiple fds. qemu_capabilities: Added capability for qemu's "ebpf_rss_fds". qemu_capabilities: Added capability for ebpf helper path. qemu_interface: Added ebpf helper call. qemu_command: Added ebpf RSS helper call for NIC creation. qemu_hotplug: Added helper call for hotplug NIC. docs: Added descriptions for "rss" and "rss_hash_report" configurations. docs/formatdomain.rst | 16 +++++++ src/conf/domain_conf.c | 31 +++++++++++++- src/conf/domain_conf.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 48 +++++++++++++++++++++ src/qemu/qemu_capabilities.h | 5 +++ src/qemu/qemu_command.c | 46 +++++++++++++++++++- src/qemu/qemu_command.h | 2 + src/qemu/qemu_hotplug.c | 30 ++++++++++++- src/qemu/qemu_interface.c | 54 +++++++++++++++++++++++ src/qemu/qemu_interface.h | 2 + src/qemu/qemu_monitor.c | 9 ++++ src/qemu/qemu_monitor.h | 3 ++ src/qemu/qemu_monitor_json.c | 50 ++++++++++++++++++++++ src/qemu/qemu_monitor_json.h | 3 ++ src/qemu/qemu_validate.c | 16 +++++++ src/util/virsocket.c | 83 ++++++++++++++++++++++++++++++++++++ src/util/virsocket.h | 2 + 18 files changed, 399 insertions(+), 4 deletions(-) -- 2.31.1

4 29

[libvirt PATCH 0/7] Accumulated mdev fixes
by Jonathon Jongsma 13 Oct '21

13 Oct '21

These patches fix a couple of outstanding issues with mdev support. These include: 1. output proper xml for the mdev parent device when run under the test suite 2. mdevctl allows multiple devices with the same UUID (but different parents), so we have to be prepared to handle this. This also requires a change in nodedev name for mdev devices. From 'mdev_$UUID' to 'mdev_$UUID_$PARENTADDR' 3. validate input xml when defining or creating mdevs (e.g. ensure we have a proper parent device) This patch obsoletes the previous patch titled "nodedev: Handle inactive mdevs with the same UUID" Jonathon Jongsma (7): nodedev: add internal virNodeDeviceObjListFind() nodedev: fix xml output for mdev parents in test suite nodedev: cache parent address in mdev caps nodedev: Add parser validation for node devices nodedev: add PostParse callback for nodedev parsing nodedev: Handle inactive mdevs with the same UUID nodedev: look up mdevs by UUID and parent src/conf/node_device_conf.c | 37 +++- src/conf/node_device_conf.h | 21 +- src/conf/virnodedeviceobj.c | 71 +++++-- src/conf/virnodedeviceobj.h | 15 +- src/hypervisor/domain_driver.c | 7 +- src/libvirt_private.syms | 1 + src/node_device/node_device_driver.c | 182 ++++++++++++++---- src/node_device/node_device_driver.h | 6 + src/node_device/node_device_udev.c | 21 +- src/test/test_driver.c | 6 +- .../mdevctl-list-multiple.out.xml | 16 +- tests/nodedevmdevctltest.c | 36 +++- tests/nodedevxml2xmltest.c | 3 +- 13 files changed, 338 insertions(+), 84 deletions(-) -- 2.31.1

4 26

set custom loglevel for external libraries
by Olaf Hering 11 Oct '21

11 Oct '21

In src/libxl/libxl_conf.c:libxlDriverConfigInit, virLogGetDefaultPriority is used to specify the (private) loglevel of an external library. This value could be controlled via "log_level=N" in libvirtd.conf. But doing it that way will affect libvirtd itself, instead of libxenlight.so as intended. There might be ways to suppress everything but libxl output via "log_filters=", but it is not clear what the syntax would be. I wonder what the preferred way is to specify the desired loglevel for the external library. It seems a separate configuration setting is required so that each value of XTL_* from xentoollog.h can be specified. Olaf

3 11

[PATCH v2 0/3] qapi & doc: deprecate drive-backup
by Vladimir Sementsov-Ogievskiy 15 Sep '21

15 Sep '21

Hi all! See 03 commit message for details. 01-02 are preparation docs update. v2: add a lot of documentation changes v1 was "[PATCH] qapi: deprecate drive-backup" Supersedes: <20210423125900.3640-1-vsementsov(a)virtuozzo.com> Vladimir Sementsov-Ogievskiy (3): docs/block-replication: use blockdev-backup docs/interop/bitmaps: use blockdev-backup qapi: deprecate drive-backup docs/block-replication.txt | 4 +- docs/interop/bitmaps.rst | 285 +++++++++++++++++++------ docs/interop/live-block-operations.rst | 47 ++-- docs/system/deprecated.rst | 11 + qapi/block-core.json | 5 +- 5 files changed, 263 insertions(+), 89 deletions(-) -- 2.29.2

4 17

question on vhost, limiting kernel threads and NPROC
by Mike Christie 14 Sep '21

14 Sep '21

Hi, The goal of this email is to try and figure how we want to track/limit the number of kernel threads created by vhost devices. Background: ----------- For vhost-scsi, we've hit a issue where the single vhost worker thread can't handle all IO the being sent from multiple queues. IOPs is stuck at around 500K. To fix this, we did this patchset: https://lore.kernel.org/linux-scsi/20210525180600.6349-1-michael.christie@o… which allows userspace to create N threads and map them to a dev's virtqueues. With this we can get around 1.4M IOPs. Problem: -------- While those patches were being reviewed, a concern about tracking all these new possible threads was raised here: https://lore.kernel.org/linux-scsi/YL45CfpHyzSEcAJv@stefanha-x1.localdomain/ To save you some time, the question is what does other kernel code using the kthread API do to track the number of kernel threads created on behalf of a userspace thread. The answer is they don't do anything so we will have to add that code. I started to do that here: https://lkml.org/lkml/2021/6/23/1233 where those patches would charge/check the vhost device owner's RLIMIT_NPROC value. But, the question of if we really want to do this has come up which is why I'm bugging lists like libvirt now. Question/Solution: ------------------ I'm bugging everyone so we can figure out: If we need to specifically track the number of kernel threads being made for the vhost kernel use case by the RLIMIT_NPROC limit? Or, is it ok to limit the number of devices with the RLIMIT_NOFILE limit. Then each device has a limit on the number of threads it can create.

4 4

[PATCH v4 for v7.6.0 00/14] Introduce virtio-mem <memory/> model
by Michal Privoznik 13 Sep '21

13 Sep '21

v4 of: https://listman.redhat.com/archives/libvir-list/2021-April/msg01138.html diff to v3: - Rebased code on the top of master - Tried to work in all Peter's review suggestions - Fixed a bug where adjusting <requested/> was viewed as hotplug of new <memory/> by XML validator and thus if <maxMemory/> was close enough to <currentMemory/> the validator reported an error (this was reported by David). You can also find these patches on my branch: https://gitlab.com/MichalPrivoznik/libvirt/-/tree/virtio_mem_v4 Michal Prívozník (14): virhostmem: Introduce virHostMemGetTHPSize() qemu_capabilities: Introduce QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI conf: Introduce virtio-mem <memory/> model qemu: Build command line for virtio-mem qemu: Wire up <memory/> live update Introduce <actual/> property to virtio-mem conf: Introduce virDomainMemoryFindByDeviceAlias() qemu: Wire up MEMORY_DEVICE_SIZE_CHANGE event qemu: Refresh the actual size of virtio-mem on monitor reconnect qemu: Account for both memballoon and virtio-mem qemuDomainSetMemoryFlags: Take virtio-mem into consideration virsh: Introduce update-memory-device command news: document recent virtio memory addition kbase: Document virtio-mem NEWS.rst | 12 + docs/formatdomain.rst | 45 +++- docs/kbase/index.rst | 4 + docs/kbase/memorydevices.rst | 150 +++++++++++ docs/kbase/meson.build | 1 + docs/manpages/virsh.rst | 30 +++ docs/schemas/domaincommon.rng | 16 ++ examples/c/misc/event-test.c | 17 ++ include/libvirt/libvirt-domain.h | 23 ++ src/conf/domain_conf.c | 118 ++++++++- src/conf/domain_conf.h | 15 ++ src/conf/domain_event.c | 84 ++++++ src/conf/domain_event.h | 10 + src/conf/domain_validate.c | 39 +++ src/libvirt_private.syms | 5 + src/qemu/qemu_alias.c | 10 +- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 13 +- src/qemu/qemu_domain.c | 33 ++- src/qemu/qemu_domain.h | 1 + src/qemu/qemu_domain_address.c | 38 ++- src/qemu/qemu_driver.c | 240 +++++++++++++++++- src/qemu/qemu_hotplug.c | 18 ++ src/qemu/qemu_hotplug.h | 5 + src/qemu/qemu_monitor.c | 37 +++ src/qemu/qemu_monitor.h | 28 ++ src/qemu/qemu_monitor_json.c | 97 +++++-- src/qemu/qemu_monitor_json.h | 5 + src/qemu/qemu_process.c | 72 ++++++ src/qemu/qemu_validate.c | 8 + src/remote/remote_daemon_dispatch.c | 30 +++ src/remote/remote_driver.c | 32 +++ src/remote/remote_protocol.x | 14 +- src/remote_protocol-structs | 7 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 2 + src/security/security_selinux.c | 2 + src/util/virhostmem.c | 54 ++++ src/util/virhostmem.h | 3 + tests/domaincapsmock.c | 9 + .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 1 + ...mory-hotplug-virtio-mem.x86_64-latest.args | 41 +++ .../memory-hotplug-virtio-mem.xml | 67 +++++ tests/qemuxml2argvtest.c | 1 + ...emory-hotplug-virtio-mem.x86_64-latest.xml | 1 + tests/qemuxml2xmltest.c | 1 + tools/virsh-domain.c | 169 ++++++++++++ 51 files changed, 1562 insertions(+), 53 deletions(-) create mode 100644 docs/kbase/memorydevices.rst create mode 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-mem.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-mem.xml create mode 120000 tests/qemuxml2xmloutdata/memory-hotplug-virtio-mem.x86_64-latest.xml -- 2.31.1

4 21

[PATCH v3 0/4] Dirty Ring support (Libvirt)
by huangy81＠chinatelecom.cn 29 Aug '21

29 Aug '21

From: Hyman Huang(黄勇) <huangy81(a)chinatelecom.cn> v3 - rebase master and fix the confilict when apply "conf: introduce dirty_ring_size in struct "_virDomainDef" to current master. v2 - split patchset into 4 patches - leave out the tcg case when building commandline. - handle the VIR_DOMAIN_KVM_DIRTY_RING case independently in , virDomainFeatureDefParse and virDomainDefFeaturesCheckABIStability, do not integrate it with other cases... - add dirty ring size check in virDomainDefFeaturesCheckABIStability - modify zero checks on integers of dirty ring size in a explicit way. - set the default value of dirty ring size in a post-parser callback. - check the absence of kvm_feature in a explicit way. - code clean of virTristateSwitchTypeToString function. this version's modification base on Peter's advices mostly, thanks a lot, please review ! Best Regards ! Hyman Huang(黄勇) v1 since qemu has introduced a dirty ring feature in 6.1.0, may be it's the right time to introduce dirty ring in libvirt meanwhile. this patch add feature named 'dirty-ring', which enable dirty ring feature when starting vm. to try this out, three things has done in this patchset: - introduce QEMU_CAPS_ACCEL so the the libvirt can use it to select the right option when specifying the accelerator type. - switch the option "-machine accel=xxx" to "-accel xxx" when specifying accelerator type once libvirt build QEMU command line, so that dirty-ring-size property can be passed to qemu when start vm. - introduce dirty_ring_size to hold the ring size configured by user and pass dirty_ring_size when building qemu commandline if dirty ring feature enabled. though dirty ring is per-cpu logically, the size of dirty ring is registered by 'struct kvm' in QEMU. so we would like to place the dirty_ring_size as a property of vm in Libvirt as the QEMU do. the dirty ring feature is disabled by default, and if enabled, the default value of ring size if 4096 if size not configured. for more details about dirty ring and "-accel" option, please refer to: https://lore.kernel.org/qemu-devel/20210108165050.406906-10-peterx@redhat.c… https://lore.kernel.org/qemu-devel/3aa73987-40e8-3619-0723-9f17f73850bd@red… please review, Thanks! Best Regards ! Hyman Huang(黄勇) (4): qemu_capabilities: introduce QEMU_CAPS_ACCEL qemu_command: switch accelerator option to new style conf: introduce dirty_ring_size in struct "_virDomainDef" qemu: support dirty ring feature docs/formatdomain.rst | 16 +++-- docs/schemas/domaincommon.rng | 10 +++ src/conf/domain_conf.c | 74 +++++++++++++++++++++- src/conf/domain_conf.h | 4 ++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 40 +++++++++++- tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.11.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_3.0.0.riscv32.xml | 1 + tests/qemucapabilitiesdata/caps_3.0.0.riscv64.xml | 1 + tests/qemucapabilitiesdata/caps_3.0.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_3.0.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_3.1.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_3.1.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml | 1 + tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 + tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml | 1 + tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml | 1 + ...64-default-cpu-kvm-virt-4.2.aarch64-latest.args | 3 +- .../aarch64-features-sve.aarch64-latest.args | 3 +- .../channel-unix-guestfwd.x86_64-latest.args | 3 +- .../clock-timer-armvtimer.aarch64-latest.args | 3 +- .../console-virtio-unix.x86_64-latest.args | 3 +- .../cpu-Icelake-Server-pconfig.x86_64-3.1.0.args | 3 +- .../cpu-Icelake-Server-pconfig.x86_64-latest.args | 3 +- .../cpu-tsc-frequency.x86_64-4.0.0.args | 3 +- .../cpu-tsc-high-frequency.x86_64-latest.args | 3 +- .../default-video-type-aarch64.aarch64-latest.args | 3 +- .../default-video-type-ppc64.ppc64-latest.args | 3 +- .../default-video-type-s390x.s390x-latest.args | 3 +- .../disk-cdrom-network.x86_64-2.12.0.args | 3 +- .../disk-cdrom-network.x86_64-latest.args | 3 +- .../disk-network-http.x86_64-latest.args | 3 +- .../hugepages-memaccess3.x86_64-latest.args | 3 +- .../intel-iommu-aw-bits.x86_64-latest.args | 3 +- .../intel-iommu-caching-mode.x86_64-latest.args | 3 +- .../intel-iommu-device-iotlb.x86_64-latest.args | 3 +- .../intel-iommu-eim.x86_64-latest.args | 3 +- ...ty-sev-missing-platform-info.x86_64-2.12.0.args | 3 +- .../launch-security-sev.x86_64-2.12.0.args | 3 +- .../launch-security-sev.x86_64-6.0.0.args | 3 +- ...emfd-memory-default-hugepage.x86_64-latest.args | 3 +- .../memfd-memory-numa.x86_64-latest.args | 3 +- .../memory-hotplug-virtio-pmem.x86_64-5.2.0.args | 3 +- .../memory-hotplug-virtio-pmem.x86_64-latest.args | 3 +- .../os-firmware-bios.x86_64-latest.args | 3 +- ...irmware-efi-no-enrolled-keys.x86_64-latest.args | 3 +- .../os-firmware-efi-secboot.x86_64-latest.args | 3 +- .../os-firmware-efi.x86_64-latest.args | 3 +- .../parallel-unix-chardev.x86_64-latest.args | 3 +- ...4-default-cpu-kvm-pseries-2.7.ppc64-latest.args | 3 +- ...4-default-cpu-kvm-pseries-3.1.ppc64-latest.args | 3 +- ...4-default-cpu-kvm-pseries-4.2.ppc64-latest.args | 3 +- ...efault-cpu-kvm-ccw-virtio-2.7.s390x-latest.args | 3 +- ...efault-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 3 +- .../smartcard-passthrough-unix.x86_64-latest.args | 3 +- .../usb-redir-unix.x86_64-latest.args | 3 +- .../vhost-user-fs-fd-memory.x86_64-latest.args | 3 +- .../virtio-rng-builtin.x86_64-5.2.0.args | 3 +- .../virtio-rng-builtin.x86_64-latest.args | 3 +- .../virtio-rng-egd-unix.x86_64-5.2.0.args | 3 +- .../virtio-rng-egd-unix.x86_64-latest.args | 3 +- ...86_64-default-cpu-kvm-pc-4.2.x86_64-latest.args | 3 +- ...6_64-default-cpu-kvm-q35-4.2.x86_64-latest.args | 3 +- 91 files changed, 268 insertions(+), 55 deletions(-) -- 1.8.3.1

2 5