[RFC PATCH 00/10] VirtioNet RSS support
by Andrew Melnychenko
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
3 years, 2 months
[libvirt PATCH 0/7] Accumulated mdev fixes
by Jonathon Jongsma
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
3 years, 2 months
set custom loglevel for external libraries
by Olaf Hering
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 years, 2 months
[PATCH v2 0/3] qapi & doc: deprecate drive-backup
by Vladimir Sementsov-Ogievskiy
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
3 years, 3 months
question on vhost, limiting kernel threads and NPROC
by Mike Christie
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...
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.
3 years, 3 months
[PATCH v4 for v7.6.0 00/14] Introduce virtio-mem <memory/> model
by Michal Privoznik
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
3 years, 3 months
[PATCH v3 0/4] Dirty Ring support (Libvirt)
by huangy81＠chinatelecom.cn
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...
https://lore.kernel.org/qemu-devel/3aa73987-40e8-3619-0723-9f17f73850bd@r...
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
3 years, 3 months
[PATCH] lxcxml2xmltest: Substitute 'inactive' variable with 'active'
by Kristina Hanicova
I removed negation from the name of a variable to make the code
more readable.
Signed-off-by: Kristina Hanicova <khanicov(a)redhat.com>
---
tests/lxcxml2xmltest.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tests/lxcxml2xmltest.c b/tests/lxcxml2xmltest.c
index 00341ad695..69c333b9b5 100644
--- a/tests/lxcxml2xmltest.c
+++ b/tests/lxcxml2xmltest.c
@@ -21,7 +21,7 @@ static virLXCDriver *driver;
struct testInfo {
const char *name;
int different;
- bool inactive_only;
+ bool active_only;
unsigned int parse_flags;
};
@@ -40,7 +40,7 @@ testCompareXMLToXMLHelper(const void *data)
ret = testCompareDomXML2XMLFiles(driver->caps, driver->xmlopt, xml_in,
info->different ? xml_out : xml_in,
- !info->inactive_only,
+ info->active_only,
info->parse_flags,
TEST_COMPARE_DOM_XML2XML_RESULT_SUCCESS);
VIR_FREE(xml_in);
@@ -57,9 +57,9 @@ mymain(void)
if (!(driver = testLXCDriverInit()))
return EXIT_FAILURE;
-# define DO_TEST_FULL(name, is_different, inactive, parse_flags) \
+# define DO_TEST_FULL(name, is_different, active, parse_flags) \
do { \
- const struct testInfo info = {name, is_different, inactive, \
+ const struct testInfo info = {name, is_different, active, \
parse_flags}; \
if (virTestRun("LXC XML-2-XML " name, \
testCompareXMLToXMLHelper, &info) < 0) \
@@ -67,10 +67,10 @@ mymain(void)
} while (0)
# define DO_TEST(name) \
- DO_TEST_FULL(name, 0, false, 0)
+ DO_TEST_FULL(name, 0, true, 0)
# define DO_TEST_DIFFERENT(name) \
- DO_TEST_FULL(name, 1, false, 0)
+ DO_TEST_FULL(name, 1, true, 0)
/* Unset or set all envvars here that are copied in lxcdBuildCommandLine
* using ADD_ENV_COPY, otherwise these tests may fail due to unexpected
--
2.31.1
3 years, 4 months
[PATCH 0/3] Implement some BlkioParameters related APIs for test driver
by Luke Yue
- Implement virDomainGetBlkioParameters
- Implement virDomainSetBlkioParameters
- Add tests for these APIs
Luke Yue (3):
test_driver: Implement virDomainGetBlkioParameters
test_driver: Implement virDomainSetBlkioParameters
tests: Test BlkioParameters related functions for test driver
examples/xml/test/testdomfv0.xml | 11 ++++
examples/xml/test/testnodeinline.xml | 11 ++++
src/test/meson.build | 1 +
src/test/test_driver.c | 96 ++++++++++++++++++++++++++++
tests/virshtest.c | 36 +++++++++++
5 files changed, 155 insertions(+)
--
2.32.0
3 years, 4 months
[PATCH 0/2] versions of: save status xml after generating taint message
by Kristina Hanicova
Both of these patches solve the same bug and only one needs to be
merged. The first one is a bit longer, but I think it is more effective
(because of function qemuDomainObjCheckTaint, where qemuDomainObjTaint
could be potentially called in multiple for cycles). The second one is
short and probably more readable.
I will leave it up to the reviewer to choose one.
Kristina Hanicova (2):
qemu: save status xml after generating taint message
qemu: save status xml after generating taint message
src/qemu/qemu_domain.c | 14 ++++++++++++++
src/qemu/qemu_domain.h | 5 +++++
src/qemu/qemu_driver.c | 4 ++--
3 files changed, 21 insertions(+), 2 deletions(-)
--
2.31.1
3 years, 4 months
