[PATCH v5 00/18] *** qemu: block: Support block disk along with throttle filters ***
by Harikumar R
*** BLURB HERE ***
Chun Feng Wu (17):
schema: Add new domain elements to support multiple throttle groups
schema: Add new domain elements to support multiple throttle filters
config: Introduce ThrottleGroup and corresponding XML parsing
config: Introduce ThrottleFilter and corresponding XML parsing
qemu: monitor: Add support for ThrottleGroup operations
tests: Test qemuMonitorJSONGetThrottleGroup and
qemuMonitorJSONUpdateThrottleGroup
remote: New APIs for ThrottleGroup lifecycle management
qemu: Refactor qemuDomainSetBlockIoTune to extract common methods
qemu: Implement qemu driver for throttle API
qemu: helper: throttle filter nodename and preparation processing
qemu: block: Support block disk along with throttle filters
config: validate: Verify iotune, throttle group and filter
qemuxmlconftest: Add 'throttlefilter' tests
test_driver: Test throttle group lifecycle APIs
virsh: Refactor iotune options for re-use
virsh: Add support for throttle group operations
virsh: Add option "throttle-groups" to "attach_disk"
Harikumar Rajkumar (1):
tests: Test qemuxmlactivetestThrottleGroup
docs/formatdomain.rst | 47 ++
docs/manpages/virsh.rst | 135 +++-
include/libvirt/libvirt-domain.h | 21 +
src/conf/domain_conf.c | 398 ++++++++++
src/conf/domain_conf.h | 45 ++
src/conf/domain_validate.c | 119 ++-
src/conf/schemas/domaincommon.rng | 293 ++++----
src/conf/virconftypes.h | 4 +
src/driver-hypervisor.h | 22 +
src/libvirt-domain.c | 174 +++++
src/libvirt_private.syms | 8 +
src/libvirt_public.syms | 7 +
src/qemu/qemu_block.c | 136 ++++
src/qemu/qemu_block.h | 49 ++
src/qemu/qemu_command.c | 180 +++++
src/qemu/qemu_command.h | 6 +
src/qemu/qemu_domain.c | 73 +-
src/qemu/qemu_driver.c | 619 +++++++++++++---
src/qemu/qemu_hotplug.c | 33 +
src/qemu/qemu_monitor.c | 34 +
src/qemu/qemu_monitor.h | 14 +
src/qemu/qemu_monitor_json.c | 134 ++++
src/qemu/qemu_monitor_json.h | 14 +
src/remote/remote_daemon_dispatch.c | 44 ++
src/remote/remote_driver.c | 40 ++
src/remote/remote_protocol.x | 48 +-
src/remote_protocol-structs | 28 +
src/test/test_driver.c | 452 ++++++++----
tests/qemumonitorjsontest.c | 86 +++
.../throttlefilter-in.xml | 392 ++++++++++
.../throttlefilter-out.xml | 393 ++++++++++
tests/qemuxmlactivetest.c | 1 +
.../throttlefilter-invalid.x86_64-latest.err | 1 +
.../throttlefilter-invalid.xml | 89 +++
.../throttlefilter.x86_64-latest.args | 55 ++
.../throttlefilter.x86_64-latest.xml | 105 +++
tests/qemuxmlconfdata/throttlefilter.xml | 95 +++
tests/qemuxmlconftest.c | 2 +
tools/virsh-completer-domain.c | 82 +++
tools/virsh-completer-domain.h | 16 +
tools/virsh-domain.c | 680 ++++++++++++++----
41 files changed, 4649 insertions(+), 525 deletions(-)
create mode 100644 tests/qemustatusxml2xmldata/throttlefilter-in.xml
create mode 100644 tests/qemustatusxml2xmldata/throttlefilter-out.xml
create mode 100644 tests/qemuxmlconfdata/throttlefilter-invalid.x86_64-latest.err
create mode 100644 tests/qemuxmlconfdata/throttlefilter-invalid.xml
create mode 100644 tests/qemuxmlconfdata/throttlefilter.x86_64-latest.args
create mode 100644 tests/qemuxmlconfdata/throttlefilter.x86_64-latest.xml
create mode 100644 tests/qemuxmlconfdata/throttlefilter.xml
--
2.39.5 (Apple Git-154)
2 days
[PATCH 0/3] conf,qemu: add AIA support for RISC-V 'virt'
by Daniel Henrique Barboza
Hi,
This series adds official support for RISC-V AIA (Advanced Interrupt
Architecture). AIA and has been supported by the 'virt' RISC-V board, as
a machine property, since QEMU 7.0.
Daniel Henrique Barboza (3):
qemu: add capability for RISC-V AIA feature
conf,qemu: implement RISC-V 'aia' virt domain feature
qemu: add RISC-V 'aia' command line
docs/formatdomain.rst | 8 ++++
src/conf/domain_conf.c | 39 +++++++++++++++++++
src/conf/domain_conf.h | 11 ++++++
src/conf/schemas/domaincommon.rng | 15 +++++++
src/libvirt_private.syms | 2 +
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 5 +++
src/qemu/qemu_validate.c | 15 +++++++
.../caps_8.0.0_riscv64.xml | 1 +
.../caps_9.1.0_riscv64.xml | 1 +
...cv64-virt-features-aia.riscv64-latest.args | 31 +++++++++++++++
...scv64-virt-features-aia.riscv64-latest.xml | 1 +
.../riscv64-virt-features-aia.xml | 27 +++++++++++++
tests/qemuxmlconftest.c | 2 +
15 files changed, 161 insertions(+)
create mode 100644 tests/qemuxmlconfdata/riscv64-virt-features-aia.riscv64-latest.args
create mode 120000 tests/qemuxmlconfdata/riscv64-virt-features-aia.riscv64-latest.xml
create mode 100644 tests/qemuxmlconfdata/riscv64-virt-features-aia.xml
--
2.45.2
3 days, 23 hours
[PATCH] qemuSnapshotDeleteValidate: Fix crash when disk is not found in VM definition
by kaihuan
qemuDomainDiskByName() can return a NULL pointer on failure.
But this returned value in qemuSnapshotDeleteValidate is not checked.It will make libvirtd crash.
Signed-off-by: kaihuan <jungleman759(a)gmail.com>
---
src/qemu/qemu_snapshot.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c
index 18b2e478f6..bcbd913073 100644
--- a/src/qemu/qemu_snapshot.c
+++ b/src/qemu/qemu_snapshot.c
@@ -4242,8 +4242,19 @@ qemuSnapshotDeleteValidate(virDomainObj *vm,
virDomainDiskDef *vmdisk = NULL;
virDomainDiskDef *disk = NULL;
- vmdisk = qemuDomainDiskByName(vm->def, snapDisk->name);
- disk = qemuDomainDiskByName(snapdef->parent.dom, snapDisk->name);
+ if (!(vmdisk = qemuDomainDiskByName(vm->def, snapDisk->name))) {
+ virReportError(VIR_ERR_OPERATION_FAILED,
+ _("disk '%1$s' referenced by snapshot '%2$s' not found in the current definition"),
+ snapDisk->name, snap->def->name);
+ return -1;
+ }
+
+ if (!(disk = qemuDomainDiskByName(snapdef->parent.dom, snapDisk->name))) {
+ virReportError(VIR_ERR_OPERATION_FAILED,
+ _("disk '%1$s' referenced by snapshot '%2$s' not found in the VM definition of the deleted snapshot"),
+ snapDisk->name, snap->def->name);
+ return -1;
+ }
if (!virStorageSourceIsSameLocation(vmdisk->src, disk->src)) {
virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
--
2.33.1.windows.1
4 days
[PATCH 00/12] Introduce SEV-SNP support
by Michal Privoznik
SEV-SNP support just landed in QEMU. Here is the first round of patches
to incorporate support into libvirt.
TODOs (aka problems of future me):
- Teach tools/virt-qemu-sev-validate how to deal with SEV-SNP
- Try to find a SEV-SNP machine a test these patches in real worl
- Write a kbase article on attestation with SEV-SNP
Michal Prívozník (12):
qemu_monitor_json: Report error in error paths in SEV related code
conf: Move some members of virDomainSEVDef into virDomainSEVCommonDef
conf: Separate SEV formatting into a function
Drop needless typecast to virDomainLaunchSecurity
src: Convert some _virDomainSecDef::sectype checks to switch()
qemu_monitor: Allow querying SEV-SNP state in 'query-sev'
qemu: Report snp-policy in virDomainGetLaunchSecurityInfo()
qemu_capabilities: Introduce QEMU_CAPS_SEV_SNP_GUEST
conf: Introduce SEV-SNP support
qemu: Build cmd line for SEV-SNP
qemu: Allow setting launch security for SEV-SNP
qemu_firmware: Pick the right firmware for SEV-SNP guests
docs/formatdomain.rst | 108 ++++++++++++
include/libvirt/libvirt-domain.h | 10 ++
src/conf/domain_conf.c | 156 ++++++++++++++----
src/conf/domain_conf.h | 28 +++-
src/conf/domain_validate.c | 44 +++++
src/conf/schemas/domaincommon.rng | 73 ++++++--
src/conf/virconftypes.h | 4 +
src/qemu/qemu_capabilities.c | 4 +
src/qemu/qemu_capabilities.h | 3 +
src/qemu/qemu_cgroup.c | 19 ++-
src/qemu/qemu_command.c | 56 ++++++-
src/qemu/qemu_driver.c | 60 +++++--
src/qemu/qemu_firmware.c | 20 ++-
src/qemu/qemu_monitor.c | 7 +-
src/qemu/qemu_monitor.h | 41 ++++-
src/qemu/qemu_monitor_json.c | 67 ++++++--
src/qemu/qemu_monitor_json.h | 8 +-
src/qemu/qemu_namespace.c | 3 +-
src/qemu/qemu_process.c | 34 ++--
src/qemu/qemu_validate.c | 13 +-
src/security/security_dac.c | 34 +++-
.../caps_9.1.0_x86_64.xml | 1 +
.../firmware/60-edk2-ovmf-x64-amdsev.json | 1 +
tests/qemumonitorjsontest.c | 65 +++++++-
...launch-security-sev-snp.x86_64-latest.args | 35 ++++
.../launch-security-sev-snp.x86_64-latest.xml | 1 +
.../launch-security-sev-snp.xml | 47 ++++++
tests/qemuxmlconftest.c | 2 +
28 files changed, 817 insertions(+), 127 deletions(-)
create mode 100644 tests/qemuxmlconfdata/launch-security-sev-snp.x86_64-latest.args
create mode 120000 tests/qemuxmlconfdata/launch-security-sev-snp.x86_64-latest.xml
create mode 100644 tests/qemuxmlconfdata/launch-security-sev-snp.xml
--
2.44.2
4 days, 2 hours
[PATCH 00/20] qemu: support mapped-ram+directio+mulitfd
by Jim Fehlig
This series is essentially V1 of a prior RFC [1] to support QEMU's
mapped-ram stream format [2] and migration capability. Along with
supporting mapped-ram, it implements a design approach we discussed
for supporting parallel save/restore [3]. In summary, the approach is
1. Add mapped-ram migration capability
2. Steal an element from save header 'unused' for a 'features' variable
and bump save version to 3.
3. Add /etc/libvirt/qemu.conf knob for the save format version,
defaulting to latest v3
4. Use v3 (aka mapped-ram) by default
5. Use mapped-ram with BYPASS_CACHE for v3, old approach for v2
6. include: Define constants for parallel save/restore
7. qemu: Add support for parallel save. Implies mapped-ram, reject if v2
8. qemu: Add support for parallel restore. Implies mapped-ram.
Reject if v2
9. tools: add parallel parameter to virsh save command
10. tools: add parallel parameter to virsh restore command
With this series, saving and restoring using mapped-ram is enabled by
default if the underlying QEMU advertises the mapped-ram migration
capability. It can be disabled by changing the 'save_image_version'
setting in qemu.conf.
To use mapped-ram with QEMU:
- The 'mapped-ram' migration capability must be set to true
- The 'multifd' migration capability must be set to true and
the 'multifd-channels' migration parameter must set to a
value >= 1
- QEMU must be provided an fdset containing the migration fd(s)
- The 'migrate' qmp command is invoked with a URI referencing the fdset
and an offset where to start reading or writing the data stream, e.g.
{"execute":"migrate",
"arguments":{"detach":true,"resume":false,
"uri":"file:/dev/fdset/0,offset=0x11921"}}
The mapped-ram stream, in conjunction with direct IO and multifd, can
significantly improve the time required to save VM memory state. The
following tables compare mapped-ram with the existing, sequential save
stream. In all cases, the save and restore operations are to/from a
block device comprised of two NVMe disks in RAID0 configuration with
xfs (~8600MiB/s). The values in the 'save time' and 'restore time'
columns were scraped from the 'real' time reported by time(1). The
'Size' and 'Blocks' columns were provided by the corresponding
outputs of stat(1).
VM: 32G RAM, 1 vcpu, idle (shortly after boot)
| save | restore |
| time | time | Size | Blocks
-----------------------+---------+---------+--------------+--------
legacy | 6.193s | 4.399s | 985744812 | 1925288
-----------------------+---------+---------+--------------+--------
mapped-ram | 5.109s | 1.176s | 34368554354 | 1774472
-----------------------+---------+---------+--------------+--------
legacy + direct IO | 5.725s | 4.512s | 985765251 | 1925328
-----------------------+---------+---------+--------------+--------
mapped-ram + direct IO | 4.627s | 1.490s | 34368554354 | 1774304
-----------------------+---------+---------+--------------+--------
mapped-ram + direct IO | | | |
+ multifd-channels=8 | 4.421s | 0.845s | 34368554318 | 1774312
-------------------------------------------------------------------
VM: 32G RAM, 30G dirty, 1 vcpu in tight loop dirtying memory
| save | restore |
| time | time | Size | Blocks
-----------------------+---------+---------+--------------+---------
legacy | 25.800s | 14.332s | 33154309983 | 64754512
-----------------------+---------+---------+--------------+---------
mapped-ram | 18.742s | 15.027s | 34368559228 | 64617160
-----------------------+---------+---------+--------------+---------
legacy + direct IO | 13.115s | 18.050s | 33154310496 | 64754520
-----------------------+---------+---------+--------------+---------
mapped-ram + direct IO | 13.623s | 15.959s | 34368557392 | 64662040
-----------------------+-------- +---------+--------------+---------
mapped-ram + direct IO | | | |
+ multifd-channels=8 | 6.994s | 6.470s | 34368554980 | 64665776
--------------------------------------------------------------------
As can be seen from the tables, one caveat of mapped-ram is the logical file
size of a saved image is basically equivalent to the VM memory size. Note
however that mapped-ram typically uses fewer blocks on disk.
Support for mapped-ram+direct-io only recently landed in upstream QEMU
and will first appear in the 9.1 release, which may complicate merging
support in libvirt. Specifically, I'm not sure how to detect if the
combination is supported by QEMU. Suggestions welcomed.
Similar to the RFC, V1 ignores compression. libvirt currently supports
compression by connecting the output of QEMU's save stream to the specified
compression program via a pipe. This approach is incompatible with mapped-ram
since the fd provided to QEMU must be seekable. In general, we can consider
mapped-ram and compression incompatible and document they cannot be used
together.
[1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/E...
[2] https://gitlab.com/qemu-project/qemu/-/blob/master/docs/devel/migration/m...
[3] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/K...
Claudio Fontana (2):
include: Define constants for parallel save/restore
tools: add parallel parameter to virsh restore command
Jim Fehlig (17):
lib: virDomainSaveParams: Ensure absolute save path
qemu_fd: Add function to retrieve fdset ID
qemu: Add function to check capability in migration params
qemu: Add function to get bool value from migration params
qemu: Add mapped-ram migration capability
qemu: Add function to get migration params for save
qemu: QEMU_SAVE_VERSION: Bump to version 3
qemu: conf: Add setting for save image version
qemu: Add helper function for creating save image fd
qemu: Add support for mapped-ram on save
qemu: Decompose qemuSaveImageOpen
qemu: Move creation of qemuProcessIncomingDef struct
qemu: Apply migration parameters in qemuMigrationDstRun
qemu: Add support for mapped-ram on restore
qemu: Support O_DIRECT with mapped-ram on save
qemu: Support O_DIRECT with mapped-ram on restore
qemu: Add support for parallel save and restore
Li Zhang (1):
tools: add parallel parameter to virsh save command
docs/manpages/virsh.rst | 9 +-
include/libvirt/libvirt-domain.h | 13 ++
src/libvirt-domain.c | 52 +++++--
src/qemu/libvirtd_qemu.aug | 1 +
src/qemu/qemu.conf.in | 6 +
src/qemu/qemu_conf.c | 16 +++
src/qemu/qemu_conf.h | 5 +
src/qemu/qemu_driver.c | 104 +++++++++-----
src/qemu/qemu_fd.c | 18 +++
src/qemu/qemu_fd.h | 3 +
src/qemu/qemu_migration.c | 192 +++++++++++++++++--------
src/qemu/qemu_migration.h | 9 +-
src/qemu/qemu_migration_params.c | 86 ++++++++++++
src/qemu/qemu_migration_params.h | 17 +++
src/qemu/qemu_monitor.c | 39 ++++++
src/qemu/qemu_monitor.h | 5 +
src/qemu/qemu_process.c | 120 +++++++++++-----
src/qemu/qemu_process.h | 19 ++-
src/qemu/qemu_saveimage.c | 216 ++++++++++++++++++++---------
src/qemu/qemu_saveimage.h | 35 +++--
src/qemu/qemu_snapshot.c | 26 ++--
src/qemu/test_libvirtd_qemu.aug.in | 1 +
tools/virsh-domain.c | 79 +++++++++--
23 files changed, 827 insertions(+), 244 deletions(-)
--
2.35.3
1 week, 4 days
[PATCH v2 0/4] fix AppArmor policy restore for runtime rules
by Georgia Garcia
Some rules are generated dynamically during boot and added to the
AppArmor policy. An example of that is macvtap devices that call the
AppArmorSetFDLabel hook to add a rule for the tap device path.
Since this information is dynamic, it is not available in the xml
config, therefore whenever a "Restore" hook is called, the entire
profile is regenerated by virt-aa-helper based only the information
from the VM definition, so the dynamic/runtime information is lost.
This patchset fixes that by storing these rules in a different file
called libvirt-uuid.runtime_files, which is included by
libvirt-uuid.files that already exists. It also includes other fixes
like memory leaks, adoption of the GLib API in the apparmor files and
a fix on the AppArmor policy that incorrectly applies apparmor policy
syntax.
Georgia Garcia (4):
security_apparmor: fix memleaks in AppArmorSetFDLabel
security: replace uses of label and VIR_FREE by g_autofree
apparmor: fix UUID specification
virt-aa-helper: store dynamically generated rules
.../usr.lib.libvirt.virt-aa-helper.in | 5 +-
src/security/apparmor/usr.sbin.libvirtd.in | 7 +-
src/security/security_apparmor.c | 83 +++++-----
src/security/virt-aa-helper.c | 145 +++++++++---------
4 files changed, 120 insertions(+), 120 deletions(-)
--
2.34.1
2 weeks, 4 days
[PATCH 00/19] hw/microblaze: Allow running cross-endian vCPUs
by Philippe Mathieu-Daudé
Make machines endianness-agnostic, allowing to run a big-endian vCPU
on the little-endian 'qemu-system-microblazeel' binary, and a little
endian one on the big-endian 'qemu-system-microblaze' binary.
Tests added, following combinations covered:
- little-endian vCPU using little-endian binary (in-tree)
- little-endian vCPU using big-endian binary (new)
- big-endian vCPU using little-endian binary (new)
- big-endian vCPU using big-endian binary (in-tree)
Deprecate untested big-endian machines, likely build on the big
endian binary by mistake:
- petalogix-ml605
- xlnx-zynqmp-pmu
To make a target endian-agnostic we need to remove the MO_TE uses.
In order to do that, we propagate the MemOp from earlier in the
call stack, or we extract it from the vCPU env (on MicroBlaze the
CPU endianness is exposed by the 'ENDI' bit).
Note, since vCPU can run in any endianness, the
MemoryRegionOps::endianness should not be DEVICE_NATIVE_ENDIAN
anymore, because this definition expand to the binary endianness,
swapping data regardless how the vcpu access it.
See adjust_endianness() -> devend_memop(). Something to keep in
mind, possibly requiring further work and optimizations (avoid
double-swap).
Next step: Look at unifying binaries.
Please review,
Phil.
Philippe Mathieu-Daudé (19):
target/microblaze: Rename CPU endianness property as 'little-endian'
hw/microblaze: Deprecate big-endian petalogix-ml605 & xlnx-zynqmp-pmu
hw/microblaze/s3adsp1800: Explicit CPU endianness
hw/microblaze/s3adsp1800: Rename unimplemented MMIO region as xps_gpio
hw/microblaze/s3adsp1800: Declare machine type using DEFINE_TYPES
macro
hw/microblaze: Fix MemoryRegionOps coding style
hw/microblaze: Restrict MemoryRegionOps are implemented as 32-bit
hw/microblaze: Propagate CPU endianness to microblaze_load_kernel()
hw/intc/xilinx_intc: Only expect big-endian accesses
hw/timer/xilinx_timer: Only expect big-endian accesses
hw/timer/xilinx_timer: Allow down to 8-bit memory access
hw/net/xilinx_ethlite: Only expect big-endian accesses
target/microblaze: Explode MO_TExx -> MO_TE | MO_xx
target/microblaze: Set MO_TE once in do_load() / do_store()
target/microblaze: Introduce mo_endian() helper
target/microblaze: Consider endianness while translating code
hw/microblaze: Support various endianness for s3adsp1800 machines
tests/functional: Explicit endianness of microblaze assets
tests/functional: Add microblaze cross-endianness tests
docs/about/deprecated.rst | 6 ++
.../devices/microblaze-softmmu/default.mak | 2 -
.../devices/microblazeel-softmmu/default.mak | 5 +-
hw/microblaze/boot.h | 4 +-
target/microblaze/cpu.h | 7 ++
hw/char/xilinx_uartlite.c | 8 ++-
hw/intc/xilinx_intc.c | 23 +++++--
hw/microblaze/boot.c | 8 +--
hw/microblaze/petalogix_ml605_mmu.c | 11 ++-
hw/microblaze/petalogix_s3adsp1800_mmu.c | 67 +++++++++++++++++--
hw/microblaze/xlnx-zynqmp-pmu.c | 12 ++--
hw/net/xilinx_ethlite.c | 28 ++++++--
hw/timer/xilinx_timer.c | 15 +++--
target/microblaze/cpu.c | 2 +-
target/microblaze/translate.c | 49 ++++++++------
.../functional/test_microblaze_s3adsp1800.py | 27 +++++++-
.../test_microblazeel_s3adsp1800.py | 25 ++++++-
17 files changed, 236 insertions(+), 63 deletions(-)
--
2.45.2
3 weeks, 3 days
[PATCH] util: Change return type of functions that never fail to void
by Alexander Kuznetsov
These functions return value is invariant since 18f3771, so change
its type and remove all dependent checks.
Found by Linux Verification Center (linuxtesting.org) with Svace.
Reported-by: Pavel Nekrasov <p.nekrasov(a)fobos-nt.ru>
Signed-off-by: Alexander Kuznetsov <kuznetsovam(a)altlinux.org>
---
src/hypervisor/virhostdev.c | 21 +++++++--------------
src/logging/log_daemon.c | 8 ++------
src/logging/log_daemon_config.c | 4 +---
src/logging/log_daemon_config.h | 2 +-
src/util/virpci.c | 4 +---
src/util/virpci.h | 2 +-
src/util/virscsi.c | 4 +---
src/util/virscsi.h | 2 +-
src/util/virscsivhost.c | 6 ++----
src/util/virscsivhost.h | 2 +-
tests/virscsitest.c | 6 ++----
11 files changed, 20 insertions(+), 41 deletions(-)
diff --git a/src/hypervisor/virhostdev.c b/src/hypervisor/virhostdev.c
index db94a2e056..037842c8a1 100644
--- a/src/hypervisor/virhostdev.c
+++ b/src/hypervisor/virhostdev.c
@@ -1131,8 +1131,7 @@ virHostdevUpdateActivePCIDevices(virHostdevManager *mgr,
if (!actual)
continue;
- if (virPCIDeviceSetUsedBy(actual, drv_name, dom_name) < 0)
- goto cleanup;
+ virPCIDeviceSetUsedBy(actual, drv_name, dom_name);
/* Setup the original states for the PCI device */
virPCIDeviceSetUnbindFromStub(actual, virBitmapIsBitSet(orig, VIR_DOMAIN_HOSTDEV_PCI_ORIGSTATE_UNBIND));
@@ -1213,11 +1212,9 @@ virHostdevUpdateActiveSCSIHostDevices(virHostdevManager *mgr,
return -1;
if ((tmp = virSCSIDeviceListFind(mgr->activeSCSIHostdevs, scsi))) {
- if (virSCSIDeviceSetUsedBy(tmp, drv_name, dom_name) < 0)
- return -1;
+ virSCSIDeviceSetUsedBy(tmp, drv_name, dom_name);
} else {
- if (virSCSIDeviceSetUsedBy(scsi, drv_name, dom_name) < 0 ||
- virSCSIDeviceListAdd(mgr->activeSCSIHostdevs, scsi) < 0)
+ if (virSCSIDeviceListAdd(mgr->activeSCSIHostdevs, scsi) < 0)
return -1;
scsi = NULL;
}
@@ -1598,11 +1595,9 @@ virHostdevPrepareSCSIDevices(virHostdevManager *mgr,
goto error;
}
- if (virSCSIDeviceSetUsedBy(tmp, drv_name, dom_name) < 0)
- goto error;
+ virSCSIDeviceSetUsedBy(tmp, drv_name, dom_name);
} else {
- if (virSCSIDeviceSetUsedBy(scsi, drv_name, dom_name) < 0)
- goto error;
+ virSCSIDeviceSetUsedBy(scsi, drv_name, dom_name);
VIR_DEBUG("Adding %s to activeSCSIHostdevs", virSCSIDeviceGetName(scsi));
@@ -1671,8 +1666,7 @@ virHostdevPrepareSCSIVHostDevices(virHostdevManager *mgr,
if (!(host = virSCSIVHostDeviceNew(hostsrc->wwpn)))
return -1;
- if (virSCSIVHostDeviceSetUsedBy(host, drv_name, dom_name) < 0)
- return -1;
+ virSCSIVHostDeviceSetUsedBy(host, drv_name, dom_name);
if (virSCSIVHostDeviceListAdd(list, host) < 0)
return -1;
@@ -2480,8 +2474,7 @@ virHostdevUpdateActiveNVMeDevices(virHostdevManager *hostdev_mgr,
/* We must restore some attributes that were lost on daemon restart. */
virPCIDeviceSetUnbindFromStub(actual, true);
- if (virPCIDeviceSetUsedBy(actual, drv_name, dom_name) < 0)
- goto rollback;
+ virPCIDeviceSetUsedBy(actual, drv_name, dom_name);
if (virPCIDeviceListAddCopy(hostdev_mgr->activePCIHostdevs, actual) < 0)
goto rollback;
diff --git a/src/logging/log_daemon.c b/src/logging/log_daemon.c
index daf7ef4b2f..5a9be4a44e 100644
--- a/src/logging/log_daemon.c
+++ b/src/logging/log_daemon.c
@@ -692,14 +692,10 @@ int main(int argc, char **argv) {
exit(EXIT_FAILURE);
}
- /* No explicit config, so try and find a default one */
+ /* No explicit config, so find a default one */
if (remote_config_file == NULL) {
implicit_conf = true;
- if (virLogDaemonConfigFilePath(privileged,
- &remote_config_file) < 0) {
- VIR_ERROR(_("Can't determine config path"));
- exit(EXIT_FAILURE);
- }
+ virLogDaemonConfigFilePath(privileged, &remote_config_file);
}
/* Read the config file if it exists */
diff --git a/src/logging/log_daemon_config.c b/src/logging/log_daemon_config.c
index 248bd927d3..60c424ad84 100644
--- a/src/logging/log_daemon_config.c
+++ b/src/logging/log_daemon_config.c
@@ -33,7 +33,7 @@
VIR_LOG_INIT("logging.log_daemon_config");
-int
+void
virLogDaemonConfigFilePath(bool privileged, char **configfile)
{
if (privileged) {
@@ -45,8 +45,6 @@ virLogDaemonConfigFilePath(bool privileged, char **configfile)
*configfile = g_strdup_printf("%s/virtlogd.conf", configdir);
}
-
- return 0;
}
diff --git a/src/logging/log_daemon_config.h b/src/logging/log_daemon_config.h
index 43922feedf..5c10cc50d7 100644
--- a/src/logging/log_daemon_config.h
+++ b/src/logging/log_daemon_config.h
@@ -39,7 +39,7 @@ struct _virLogDaemonConfig {
};
-int virLogDaemonConfigFilePath(bool privileged, char **configfile);
+void virLogDaemonConfigFilePath(bool privileged, char **configfile);
virLogDaemonConfig *virLogDaemonConfigNew(bool privileged);
void virLogDaemonConfigFree(virLogDaemonConfig *data);
int virLogDaemonConfigLoadFile(virLogDaemonConfig *data,
diff --git a/src/util/virpci.c b/src/util/virpci.c
index 289c0b330b..90617e69c6 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -2049,7 +2049,7 @@ virPCIDeviceSetReprobe(virPCIDevice *dev, bool reprobe)
dev->reprobe = reprobe;
}
-int
+void
virPCIDeviceSetUsedBy(virPCIDevice *dev,
const char *drv_name,
const char *dom_name)
@@ -2058,8 +2058,6 @@ virPCIDeviceSetUsedBy(virPCIDevice *dev,
VIR_FREE(dev->used_by_domname);
dev->used_by_drvname = g_strdup(drv_name);
dev->used_by_domname = g_strdup(dom_name);
-
- return 0;
}
void
diff --git a/src/util/virpci.h b/src/util/virpci.h
index ba5e0ae6f1..c5dcf9d37f 100644
--- a/src/util/virpci.h
+++ b/src/util/virpci.h
@@ -136,7 +136,7 @@ void virPCIDeviceSetStubDriverName(virPCIDevice *dev,
const char *driverName);
const char *virPCIDeviceGetStubDriverName(virPCIDevice *dev);
virPCIDeviceAddress *virPCIDeviceGetAddress(virPCIDevice *dev);
-int virPCIDeviceSetUsedBy(virPCIDevice *dev,
+void virPCIDeviceSetUsedBy(virPCIDevice *dev,
const char *drv_name,
const char *dom_name);
void virPCIDeviceGetUsedBy(virPCIDevice *dev,
diff --git a/src/util/virscsi.c b/src/util/virscsi.c
index 3d2c77e3b8..6899958e21 100644
--- a/src/util/virscsi.c
+++ b/src/util/virscsi.c
@@ -243,7 +243,7 @@ virSCSIDeviceFree(virSCSIDevice *dev)
g_free(dev);
}
-int
+void
virSCSIDeviceSetUsedBy(virSCSIDevice *dev,
const char *drvname,
const char *domname)
@@ -255,8 +255,6 @@ virSCSIDeviceSetUsedBy(virSCSIDevice *dev,
copy->domname = g_strdup(domname);
VIR_APPEND_ELEMENT(dev->used_by, dev->n_used_by, copy);
-
- return 0;
}
bool
diff --git a/src/util/virscsi.h b/src/util/virscsi.h
index ec34303bdc..d76ee13bcc 100644
--- a/src/util/virscsi.h
+++ b/src/util/virscsi.h
@@ -50,7 +50,7 @@ virSCSIDevice *virSCSIDeviceNew(const char *sysfs_prefix,
bool shareable);
void virSCSIDeviceFree(virSCSIDevice *dev);
-int virSCSIDeviceSetUsedBy(virSCSIDevice *dev,
+void virSCSIDeviceSetUsedBy(virSCSIDevice *dev,
const char *drvname,
const char *domname);
bool virSCSIDeviceIsAvailable(virSCSIDevice *dev);
diff --git a/src/util/virscsivhost.c b/src/util/virscsivhost.c
index 15024d7106..05b89e58d6 100644
--- a/src/util/virscsivhost.c
+++ b/src/util/virscsivhost.c
@@ -193,7 +193,7 @@ virSCSIVHostDeviceListNew(void)
}
-int
+void
virSCSIVHostDeviceSetUsedBy(virSCSIVHostDevice *dev,
const char *drvname,
const char *domname)
@@ -202,8 +202,6 @@ virSCSIVHostDeviceSetUsedBy(virSCSIVHostDevice *dev,
VIR_FREE(dev->used_by_domname);
dev->used_by_drvname = g_strdup(drvname);
dev->used_by_domname = g_strdup(domname);
-
- return 0;
}
@@ -214,7 +212,7 @@ virSCSIVHostDeviceGetUsedBy(virSCSIVHostDevice *dev,
{
*drv_name = dev->used_by_drvname;
*dom_name = dev->used_by_domname;
- }
+}
int
diff --git a/src/util/virscsivhost.h b/src/util/virscsivhost.h
index a7299382db..caaac26328 100644
--- a/src/util/virscsivhost.h
+++ b/src/util/virscsivhost.h
@@ -50,7 +50,7 @@ void virSCSIVHostDeviceListDel(virSCSIVHostDeviceList *list,
virSCSIVHostDevice *dev);
virSCSIVHostDeviceList *virSCSIVHostDeviceListNew(void);
virSCSIVHostDevice *virSCSIVHostDeviceNew(const char *name);
-int virSCSIVHostDeviceSetUsedBy(virSCSIVHostDevice *dev,
+void virSCSIVHostDeviceSetUsedBy(virSCSIVHostDevice *dev,
const char *drvname,
const char *domname);
void virSCSIVHostDeviceGetUsedBy(virSCSIVHostDevice *dev,
diff --git a/tests/virscsitest.c b/tests/virscsitest.c
index c96699e157..2c3b599c7a 100644
--- a/tests/virscsitest.c
+++ b/tests/virscsitest.c
@@ -87,14 +87,12 @@ test2(const void *data G_GNUC_UNUSED)
if (!virSCSIDeviceIsAvailable(dev))
goto cleanup;
- if (virSCSIDeviceSetUsedBy(dev, "QEMU", "fc18") < 0)
- goto cleanup;
+ virSCSIDeviceSetUsedBy(dev, "QEMU", "fc18");
if (virSCSIDeviceIsAvailable(dev))
goto cleanup;
- if (virSCSIDeviceSetUsedBy(dev, "QEMU", "fc20") < 0)
- goto cleanup;
+ virSCSIDeviceSetUsedBy(dev, "QEMU", "fc20");
if (virSCSIDeviceIsAvailable(dev))
goto cleanup;
--
2.42.2
1 month, 1 week
[PATCH v4 00/11] swtpm: Add support for profiles
by Stefan Berger
Upcoming libtpms v0.10 and swtpm v0.10 will have TPM profile support that
allows to restrict a TPM's provided set of crypto algorithms and commands
and through which backwards compatibility and migration from newer versions
of libtpms to older ones (up to libtpms v0.9) is supported. For the latter
to work it is necessary that the user chooses the right ('null') profile.
This series adds support for passing a profile choice to swtpm_setup by
setting it in the domain XML using the <profile/> XML node. An optional
attribute 'remove_disabled' can be set in this node and accepts two values:
"check": test a few crypto algorithms (tdes, camellia, unpadded encryption,
and others) for whether they are currently disabled due to FIPS
mode on the host and remove these algorithms in the 'custom'
profile if they are disabled;
"fips-host": do not test but remove all the possibly disabled crypto
algorithms (from list above)
Also extend the documentation but point the user to swtpm and libtpms
documentation for further details.
Follow Deniel's suggestions there's now a PR for swtpm_setup to support
searching for profiles though a configurable local directory, distro
directory and if no profile could be found there (with appended
".json" suffix) it will fall back to try to use a built-in profile by
the provided name: https://github.com/stefanberger/swtpm/pull/918
Stefan
v4:
- Renamed previous 'name' attribute in profile XML node to 'source'
to indicate that the profile was created from some sort of 'source'.
The 'name' is now set from the name of the profile read from the
swtpm instance's state once it has been created.
v3:
- 2/10: Adjustments to due rebase
- Applied Marc-André's R-b tags
- 10/10: Read back profile name from swtpm and adjust it in emulator defs
Stefan Berger (11):
conf: Move TPM emulator parameters into own struct
qemu: Pass virQEMUDriverConfig rather than some of its fields
util: Add parsing support for swtpm_setup's cmdarg-profile capability
conf: Define enum virDomainTPMProfileRemoveDisabled
schema: Extend schema for TPM emulator profile node
conf: Add support for profile parameter on TPM emulator in domain XML
docs: Add documentation for the TPM backend profile node
qemu: Extend swtpm_setup command line to set a profile by its name
qemu: Move adding of keys to swtpm command line into own function
qemu: Move adding --tpmstate to swtpm command line into own function
qemu: Read back the profile name after creation of a TPM instance
docs/formatdomain.rst | 32 +++
src/conf/domain_conf.c | 47 ++++
src/conf/domain_conf.h | 38 ++--
src/conf/domain_validate.c | 7 +
src/conf/schemas/domaincommon.rng | 32 +++
src/conf/virconftypes.h | 2 +
src/qemu/qemu_extdevice.c | 5 +-
src/qemu/qemu_tpm.c | 344 ++++++++++++++++++++----------
src/qemu/qemu_tpm.h | 3 +-
src/util/virtpm.c | 2 +
src/util/virtpm.h | 2 +
tests/testutilsqemu.c | 1 +
12 files changed, 386 insertions(+), 129 deletions(-)
--
2.47.0
1 month, 1 week
[PATCH safe for 10.10.0] qemu: re-use existing ActualNetDef for more interface types during update-device
by Laine Stump
For the full history behind this patch, look at the following:
https://issues.redhat.com/browse/RHEL-7036
commit v10.7.0-101-ga37bd2a15b
commit v10.8.0-rc2-8-gbcd5ae4e73
Summary: original problem was unexpected failure of update-device when
the user hadn't changed anything other than online status of the guest
NIC (which should always be allowed).
The first commit "fixed" this by avoiding the allocation of a new
ActualNetDef (i.e. creating a new networkport) for *all* network
device updates (because that was inappropriately changing which
ethernet physdev should be used for a macvtap connection, which by
design can't be handled in an update-device).
But this commit caused a regression for update-device of bridge-based
network devices (because some the updates of certain attributes *do*
require the ActualNetDef be re-allocated), so...
The 2nd commit narrowed the list of network types that get the "don't
allocate new ActualNetDef" treatment (so that only interfaces
connected to a network that uses a pool of ethernet VFs *being used in
passthrough mode* qualify).
But then it was pointed out that this re-broke simple updates of
devices that used a direct/macvtap network in "bridge" mode (because
it's possible to list multiple physdevs to use for bridge mode, in
which case the network driver attempts to "load balance" (and so a new
allocation might have a different ethernet physdev which, again, can't
be supported in a device-update).
So this (single line of code) patch *widens* the list of network types
that don't allocate a new ActualNetDef to also include the other
direct (macvtap) modes, e.g. bridge, private, etc.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
There is a more comprehensive fix that also, e.g., makes updating the
bandwidth or vlan info of a direct interface work correctly, but that
is much more invasive (and also isn't done yet). This patch fixes the
case of updating a direct interface's online status (for example)
without breaking anything else.
src/qemu/qemu_hotplug.c | 38 +++++++++++++++++++++-----------------
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 3c18af6b0c..ff8c1263c6 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -3935,25 +3935,29 @@ qemuDomainChangeNet(virQEMUDriver *driver,
if (newdev->type == VIR_DOMAIN_NET_TYPE_NETWORK) {
if (olddev->type == VIR_DOMAIN_NET_TYPE_NETWORK &&
oldType == VIR_DOMAIN_NET_TYPE_DIRECT &&
- virDomainNetGetActualDirectMode(olddev) == VIR_NETDEV_MACVLAN_MODE_PASSTHRU &&
STREQ(olddev->data.network.name, newdev->data.network.name)) {
/* old and new are type='network', and the network name
- * hasn't changed *and* this is a network where each
- * connection is allocated exclusive use of a VF
- * device. In this case we *don't* want to get a new port
- * ("actual device") from the network because attempting
- * to allocate a new device would also allocate a
- * new/different VF, causing the update to fail. And
- * anyway we can use olddev's actualNetDef (since it
- * hasn't changed).
- *
- * So instead we just duplicate *the pointer to* the
- * actualNetDef from olddev to newdev so that comparisons
- * of actualNetDef will show no change. If the update is
- * successful, we will clear the actualNetDef pointer from
- * olddev before destroying it (or if the update fails,
- * then we need to clear the pointer from newdev before
- * destroying it)
+ * hasn't changed *and* this is a "direct" network (a pool
+ * of 1 or more host ethernet devices where each guest
+ * interface is allocated one device that it connects to
+ * via macvtap. In this case we *don't* want to get a new
+ * port ("actual device") from the network because
+ * attempting to allocate a new device would also allocate
+ * a new/different ethernet, causing the update to fail
+ * (because the physical device of a macvtap-based
+ * interface can't be changed without completely
+ * unplugging and re-plugging the guest NIC).
+
+
+ * We can work around this issue by just re-using olddev's
+ * actualNetDef (since it hasn't changed) rather than
+ * allocating a new one. We just duplicate *the pointer
+ * to* the actualNetDef from olddev to newdev so that
+ * comparisons of actualNetDef will show no change. If the
+ * update is successful, we will clear the actualNetDef
+ * pointer from olddev before destroying it (or if the
+ * update fails, then we need to clear the pointer from
+ * newdev before destroying it)
*/
newdev->data.network.actual = olddev->data.network.actual;
memcpy(newdev->data.network.portid, olddev->data.network.portid,
--
2.47.0
1 month, 1 week