[libvirt PATCH 0/3] meson: Fix RPM builds
by Andrea Bolognani
Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/461702102
The Ubuntu failures are due to connection issues and should be
transient; all RPM builds passed.
Andrea Bolognani (3):
rpm: List one more directory
meson: Sort virt_install_dirs
meson: Add missing virt_install_dirs
libvirt.spec.in | 1 +
src/ch/meson.build | 1 +
src/interface/meson.build | 4 ++++
src/libxl/meson.build | 8 +++++++-
src/lxc/meson.build | 4 +++-
src/meson.build | 2 +-
src/network/meson.build | 2 ++
src/node_device/meson.build | 4 ++++
src/nwfilter/meson.build | 6 ++++++
src/qemu/meson.build | 20 ++++++++++++++++----
src/remote/meson.build | 2 ++
src/secret/meson.build | 5 +++++
src/storage/meson.build | 6 ++++++
13 files changed, 58 insertions(+), 7 deletions(-)
--
2.34.1
2 years, 9 months
[PATCH v2 0/4] qemu_tpm: Get swtpm pid without binary validation
by Vasiliy Ulyanov
v2 of https://listman.redhat.com/archives/libvir-list/2022-January/msg00008.html
The v2 series introduces the new approach following the previous review
comments. It adds a function for pidfile lock validation (i.e. if its
locked by the expected process) and adds the new check to
virPidFileReadPathIfAlive. The daemonization and pidfile handling for
swtpm command are now handled by libvirt.
The fix to qemu_vhost_user_gpu is currently done by visual code
checking. Not really sure how to test e2e as I dont have a quick
reproducer atm :(
Note: I wasn't sure about the refactoring of virPidFileReadPathIfAlive
(i.e. whether to remove the binary path from there). For now decided to
introduce the new lock check only if the path is not provided. But I am
open for suggestions on how to better fit the new check.
Vasiliy Ulyanov (4):
virfile: Add virFileGetLockOwner function
virpidfile: Refactor virPidFileReadPathIfAlive
qemu_tpm: Get swtpm pid without binary validation
qemu: gpu: Get pid without binary validation
src/libvirt_private.syms | 1 +
src/qemu/qemu_tpm.c | 26 +++++++++-----------
src/qemu/qemu_vhost_user_gpu.c | 9 +++----
src/util/virfile.c | 45 ++++++++++++++++++++++++++++++++++
src/util/virfile.h | 2 ++
src/util/virpidfile.c | 20 +++++++++++++++
6 files changed, 82 insertions(+), 21 deletions(-)
--
2.34.1
2 years, 9 months
[libvirt PATCH 0/3] rpm: Fix and improve handling of directories
by Andrea Bolognani
With respect to the permissions topic mentioned in patch 3/3, I'm
currently working on some patches that aim to improve that situation
as well.
Andrea Bolognani (3):
rpm: Move /etc/libvirt from -daemon to -libs
rpm: Move /var/lib/libvirt from -libs to -daemon
rpm: List more directories
libvirt.spec.in | 34 +++++++++++++++++++++++++++++++---
1 file changed, 31 insertions(+), 3 deletions(-)
--
2.34.1
2 years, 9 months
[libvirt PATCH 0/2] qemu: QEMU_AUDIO_DRV fixes and cleanups
by Andrea Bolognani
Andrea Bolognani (2):
qemu: Correctly translate QEMU_AUDIO_DRV=wav
qemu: Drop qemuAudioDriver enumeration
src/qemu/qemu_command.c | 46 +++++++++++++++++++++++++++++------------
src/qemu/qemu_command.h | 3 +++
src/qemu/qemu_domain.c | 16 ++++----------
3 files changed, 40 insertions(+), 25 deletions(-)
--
2.34.1
2 years, 9 months
[libvirt PATCH 0/4] move virParseVersionString to virstring.c
by Ján Tomko
And clean up some includes while doing it.
Ján Tomko (4):
maint: add required includes
util: virParseVersionString: move to virstring.c
virParseVersionString: rename to virStringParseVersion
maint: remove unnecessary virutil.h includes
src/bhyve/bhyve_driver.c | 2 +-
src/ch/ch_conf.c | 2 +-
src/esx/esx_vi.c | 9 ++---
src/libvirt_private.syms | 2 +-
src/lxc/lxc_driver.c | 2 +-
src/nwfilter/nwfilter_ebiptables_driver.c | 6 +--
src/openvz/openvz_conf.c | 3 +-
src/util/virdnsmasq.c | 3 +-
src/util/virfirewalld.c | 4 +-
src/util/virstring.c | 48 +++++++++++++++++++++++
src/util/virstring.h | 4 ++
src/util/virutil.c | 46 ----------------------
src/util/virutil.h | 3 --
src/vbox/vbox_common.c | 2 +-
src/vmware/vmware_conf.c | 3 +-
src/vz/vz_utils.c | 2 +-
tests/testutilsqemu.c | 3 +-
tests/utiltest.c | 2 +-
tools/virt-host-validate-common.c | 2 +-
19 files changed, 73 insertions(+), 75 deletions(-)
--
2.34.1
2 years, 9 months
[libvirt PATCH] qemu: virtiofs: check whether the supplied binary exists
by Ján Tomko
Report an error upfront if the binary does not exist
or is not executable.
https://bugzilla.redhat.com/show_bug.cgi?id=1999372
Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
---
src/qemu/qemu_virtiofs.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/qemu/qemu_virtiofs.c b/src/qemu/qemu_virtiofs.c
index 1b853a5a59..7e3324b017 100644
--- a/src/qemu/qemu_virtiofs.c
+++ b/src/qemu/qemu_virtiofs.c
@@ -184,6 +184,13 @@ qemuVirtioFSStart(virQEMUDriver *driver,
VIR_AUTOCLOSE logfd = -1;
int rc;
+ if (!virFileIsExecutable(fs->binary)) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("virtiofsd binary '%s' is not executable"),
+ fs->binary);
+ return -1;
+ }
+
if (!virFileExists(fs->src->path)) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("the virtiofs export directory '%s' does not exist"),
--
2.31.1
2 years, 9 months
[PATCH] virnodedeviceobj: Don't unlock virNodeDeviceObj in virNodeDeviceObjListRemove()
by Michal Privoznik
When virNodeDeviceObjListRemove() is called, the passed
virNodeDeviceObj is removed from internal list of node devices
and then unrefed and unlocked. While the former is warranted (the
object was refed at the beginning of the function) the unlock is
not. In fact, it's wrong from conceptual POV. We still want
threads working on the object tu mutually exclude each other.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/conf/virnodedeviceobj.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/conf/virnodedeviceobj.c b/src/conf/virnodedeviceobj.c
index 2e4ef2df3c..7a560349d4 100644
--- a/src/conf/virnodedeviceobj.c
+++ b/src/conf/virnodedeviceobj.c
@@ -524,7 +524,7 @@ virNodeDeviceObjListRemove(virNodeDeviceObjList *devs,
virObjectRWLockWrite(devs);
virObjectLock(obj);
virNodeDeviceObjListRemoveLocked(devs, obj);
- virNodeDeviceObjEndAPI(&obj);
+ virObjectUnref(obj);
virObjectRWUnlock(devs);
}
--
2.34.1
2 years, 9 months
[libvirt PATCH v5 0/7] cgroup and thread management in ch driver
by Praveen K Paladugu
This patchset adds support for cgroup management of ch threads. This version
correctly manages cgroups for vcpu and emulator threads created by ch. cgroup
management for iothreads is not yet supported.
Along with cgroup management, this patchset also enables support for pinning
vcpu and emulator threads to selected host cpus.
v5:
* bumped the verion of callbacks in ch driver to 8.1.0
v4:
* addressed all open comments in v3
* dropped all the merged commits
v3:
* addrressed all the formatting comments in v2 patch set
* dropped indentation patches are they do not adhere to libvirt coding style
* fixed build issue in qemu driver that was introduced in v2
Praveen K Paladugu (3):
qemu,hypervisor: refactor some cgroup mgmt methods
ch_process: Setup emulator and iothread settings
ch_driver: emulator threadinfo & pinning callbacks
Vineeth Pillai (4):
ch: methods for cgroup mgmt in ch driver
ch_driver,ch_domain: vcpupin callback in ch driver
ch_driver: enable typed param string for numatune
ch_driver: add numatune callbacks for CH driver
src/ch/ch_conf.c | 2 +
src/ch/ch_conf.h | 4 +-
src/ch/ch_domain.c | 64 ++++
src/ch/ch_domain.h | 18 +-
src/ch/ch_driver.c | 590 +++++++++++++++++++++++++++++++++
src/ch/ch_monitor.c | 156 +++++++++
src/ch/ch_monitor.h | 56 +++-
src/ch/ch_process.c | 385 ++++++++++++++++++++-
src/ch/ch_process.h | 3 +
src/hypervisor/domain_cgroup.c | 457 ++++++++++++++++++++++++-
src/hypervisor/domain_cgroup.h | 72 ++++
src/libvirt_private.syms | 14 +-
src/qemu/qemu_cgroup.c | 413 +----------------------
src/qemu/qemu_cgroup.h | 11 -
src/qemu/qemu_driver.c | 14 +-
src/qemu/qemu_hotplug.c | 7 +-
src/qemu/qemu_process.c | 24 +-
17 files changed, 1835 insertions(+), 455 deletions(-)
--
2.27.0
2 years, 9 months
[PATCH 0/4] Couple of misc cleanups
by Michal Privoznik
*** BLURB HERE ***
Michal Prívozník (4):
test_driver: Don't leak @group_name
lib: Don't set variable to NULL after VIR_FREE()
virpcivpdtest: Fix potential double-free()
src: Use g_steal_pointer() more
src/conf/domain_conf.c | 1 -
src/conf/nwfilter_conf.c | 1 -
src/esx/esx_vi.c | 6 ++----
src/hyperv/hyperv_driver.c | 8 +++-----
src/hyperv/hyperv_wmi.c | 3 +--
src/hypervisor/virhostdev.c | 3 +--
src/libxl/xen_common.c | 12 ++++--------
src/qemu/qemu_hotplug.c | 6 ++----
src/qemu/qemu_migration.c | 9 +++------
src/storage/storage_backend_gluster.c | 9 +++------
src/storage/storage_util.c | 6 ++----
src/test/test_driver.c | 1 -
src/util/virfile.c | 3 +--
src/util/virlease.c | 3 +--
src/util/virnuma.c | 9 +++------
tests/virpcivpdtest.c | 4 +++-
tests/virtypedparamtest.c | 1 -
17 files changed, 29 insertions(+), 56 deletions(-)
--
2.34.1
2 years, 9 months
[PATCH v2] docs: expand firmware descriptor to allow flash without NVRAM
by Daniel P. Berrangé
The current firmware descriptor schema for flash requires that both the
executable to NVRAM template paths be provided. This is fine for the
most common usage of EDK2 builds in virtualization where the separate
_CODE and _VARS files are provided.
With confidential computing technology like AMD SEV, persistent storage
of variables may be completely disabled because the firmware requires a
known clean state on every cold boot. There is no way to express this
in the firmware descriptor today.
Even with regular EDK2 builds it is possible to create a firmware that
has both executable code and variable persistence in a single file. This
hasn't been commonly used, since it would mean every guest bootup would
need to clone the full firmware file, leading to redundant duplicate
storage of the code portion. In some scenarios this may not matter and
might even be beneficial. For example if a public cloud allows users to
bring their own firmware, such that the user can pre-enroll their own
secure boot keys, you're going to have this copied on disk for each
tenant already. At this point the it can be simpler to just deal with
a single file rather than split builds. The firmware descriptor ought
to be able to express this combined firmware model too.
This all points towards expanding the schema for flash with a 'mode'
concept:
- "split" - the current implicit behaviour with separate files
for code and variables.
- "combined" - the alternate behaviour where a single file contains
both code and variables.
- "stateless" - the confidential computing use case where storage
of variables is completely disable, leaving only the code.
Reviewed-by: Philippe Mathieu-Daudé <f4bug(a)amsat.org>
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
docs/interop/firmware.json | 54 ++++++++++++++++++++++++++++++++------
1 file changed, 46 insertions(+), 8 deletions(-)
In v2:
- Mark 'mode' as optional field
- Misc typos in docs
diff --git a/docs/interop/firmware.json b/docs/interop/firmware.json
index 8d8b0be030..f5d1d0b6e7 100644
--- a/docs/interop/firmware.json
+++ b/docs/interop/firmware.json
@@ -210,24 +210,61 @@
'data' : { 'filename' : 'str',
'format' : 'BlockdevDriver' } }
+
+##
+# @FirmwareFlashType:
+#
+# Describes how the firmware build handles code versus variable
+# persistence.
+#
+# @split: the executable file contains code while the NVRAM
+# template provides variable storage. The executable
+# must be configured read-only and can be shared between
+# multiple guests. The NVRAM template must be cloned
+# for each new guest and configured read-write.
+#
+# @combined: the executable file contains both code and
+# variable storage. The executable must be cloned
+# for each new guest and configured read-write.
+# No NVRAM template will be specified.
+#
+# @stateless: the executable file contains code and variable
+# storage is not persisted. The executed must
+# be configured read-only and can be shared
+# between multiple guests. No NVRAM template
+# will be specified.
+#
+# Since: 7.0.0
+##
+{ 'enum': 'FirmwareFlashMode',
+ 'data': [ 'split', 'combined', 'stateless' ] }
+
##
# @FirmwareMappingFlash:
#
# Describes loading and mapping properties for the firmware executable
# and its accompanying NVRAM file, when @FirmwareDevice is @flash.
#
-# @executable: Identifies the firmware executable. The firmware
-# executable may be shared by multiple virtual machine
-# definitions. The preferred corresponding QEMU command
-# line options are
+# @mode: describes how the firmware build handles code versus variable
+# storage. If not present, it must be treated as if it was
+# configured with value ``split``. Since: 7.0.0
+#
+# @executable: Identifies the firmware executable. The @mode
+# indicates whether there will be an associated
+# NVRAM template present. The preferred
+# corresponding QEMU command line options are
# -drive if=none,id=pflash0,readonly=on,file=@executable.@filename,format=@executable.(a)format
# -machine pflash0=pflash0
-# or equivalent -blockdev instead of -drive.
+# or equivalent -blockdev instead of -drive. When
+# @mode is ``combined`` the executable must be
+# cloned before use and configured with readonly=off.
# With QEMU versions older than 4.0, you have to use
# -drive if=pflash,unit=0,readonly=on,file=@executable.@filename,format=@executable.(a)format
#
# @nvram-template: Identifies the NVRAM template compatible with
-# @executable. Management software instantiates an
+# @executable, when @mode is set to ``split``,
+# otherwise it should not be present.
+# Management software instantiates an
# individual copy -- a specific NVRAM file -- from
# @nvram-template.@filename for each new virtual
# machine definition created. @nvram-template.@filename
@@ -246,8 +283,9 @@
# Since: 3.0
##
{ 'struct' : 'FirmwareMappingFlash',
- 'data' : { 'executable' : 'FirmwareFlashFile',
- 'nvram-template' : 'FirmwareFlashFile' } }
+ 'data' : { '*mode': 'FirmwareFlashMode',
+ 'executable' : 'FirmwareFlashFile',
+ '*nvram-template' : 'FirmwareFlashFile' } }
##
# @FirmwareMappingKernel:
--
2.34.1
2 years, 9 months
