conf: skip resource cache init if sysfs files are missing
On aarch64 the 'id' file is not present for CPU cache information in
sysfs. This causes the local stateful hypervisor drivers to fail to
initialize capabilities:
virStateInitialize:657 : Initialisation of cloud-hypervisor state driver failed: no error
The 'no error' is because the 'virFileReadValueNNN' methods return
ret==-2, with no error raised, when the requeted file does not exist.
None of the callers were checking for this scenario when populating
capabilities. The most graceful way to handle this is to skip the
cache bank in question. This fixes failure to launch libvirt drivers
on certain aarch64 hardware.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/389 Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
virGetConnectGeneric: Only delegate existing identities
Inside virt-qemu-run, just like in virsh for example, there is no
identity set in the current thread, so we should not try to set it,
otherwise things like connecting to other drivers might fail and on
top of that there is no error set so the user can't even see what's
wrong.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2000075 Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
* the macOS platform has switched from x86_64 to aarch64
* if a new pipeline starts before a previous one finishes,
jobs marked 'interruptible: true' will be auto-cancelled
Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Michal Privoznik [Fri, 11 Nov 2022 13:55:14 +0000 (14:55 +0100)]
qemu_validate: Use proper printf directive for ssize_t
In one of recent commits an error message was introduced. In this
message a variable of type ssize_t is being printed out, but the
corresponding format directive is %ld instead of %zd which breaks
on 32bits systems. Switch to proper format.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Jim Fehlig [Fri, 11 Nov 2022 00:55:38 +0000 (17:55 -0700)]
tests: Fix libxlxml2domconfigtest
Downstream CI recently encountered failures of libxlxml2domconfigtest when
building libvirt packages against Xen 4.17 rc3 packages. The test fails on
vnuma_hvm config, where suddently the actual json produced by
libxl_domain_config_to_json() contains a 'pnode' entry in the 'vnuma_nodes'
list, which is absent in the expected json. It appears the test has thus far
passed by luck. E.g. I was able to make the test pass in the failing
environment by changing the meson buildtype from debugoptimized to debug.
When a VM config contains vnuma settings, libxlMakeVnumaList() checks if the
number of requested vnuma nodes exceeds the number of physical nodes. The
number of physical nodes is retrieved with libxl_get_physinfo(), which can
return wildly different results in the context of unit tests. This change
mocks libxl_get_physinfo() to return consistent results. All fields of the
libxl_physinfo struct are set to 0 except nr_nodes, which is set to 6 to
ensure the vnuma_hvm configuration is properly tested.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Lin Yang <lin.a.yang@intel.com> Signed-off-by: Haibin Huang <haibin.huang@intel.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Fri, 11 Nov 2022 01:21:26 +0000 (17:21 -0800)]
security_dac: Set DAC label on SGX /dev nodes
As advertised in previous commits, QEMU needs to access
/dev/sgx_vepc and /dev/sgx_provision files when SGX memory
backend is configured. And if it weren't for QEMU's namespaces,
we wouldn't dare to relabel them, because they are system wide
files. But if namespaces are used, then we can set label on
domain's private copies, just like we do for /dev/sev.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Haibin Huang <haibin.huang@intel.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Fri, 11 Nov 2022 01:21:25 +0000 (17:21 -0800)]
qemu_namespace: Create SGX related nodes in domain's namespace
This is similar to the previous commit. SGX memory backend needs
to access /dev/sgx_vepc and /dev/sgx_provision. Create these
nodes in domain's private /dev when required by domain's config.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Haibin Huang <haibin.huang@intel.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Fri, 11 Nov 2022 01:21:24 +0000 (17:21 -0800)]
qemu_cgroup: Allow SGX in devices controller
SGX memory backend needs to access /dev/sgx_vepc (which allows
userspace to allocate "raw" EPC without an associated enclave)
and /dev/sgx_provision (which allows creating provisioning
enclaves). Allow these two devices in CGroups if a domain is
configured so.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Haibin Huang <haibin.huang@intel.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Lin Yang <lin.a.yang@intel.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Haibin Huang <haibin.huang@intel.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Haibin Huang [Fri, 11 Nov 2022 01:21:22 +0000 (17:21 -0800)]
conf: expose SGX feature in domain capabilities
Extend hypervisor capabilities to include sgx feature. When available,
the hypervisor supports launching an VM with SGX on Intel platfrom.
The SGX feature tag privides additional details like section size and
sgx1 or sgx2.
Signed-off-by: Haibin Huang <haibin.huang@intel.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 9 Nov 2022 17:12:12 +0000 (18:12 +0100)]
qemu: capabilities: Detect support for JSON args for -netdev
JSON args for -netdev were added as precursor for adding the 'dgram'
network backend type. Enable the detection and update test cases using
DO_TEST_CAPS_LATEST.
Enabling the capability also ensures that the -netdev argument is
validated against the QAPI schema of 'netdev_add' which was already
implemented but not enabled.
The parser supporting JSON was added by qemu commit f3eedcddba3 and
enabled when adding stream/dgram netdevs in commit 5166fe0ae46.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
nodedev: ignore EINVAL from libudev in udevEventHandleThread
Certain udev entries might be of a size that makes libudev emit EINVAL
which right now leads to udevEventHandleThread exiting. Due to no more
handling events other elements of libvirt will start pushing for events
to be consumed which never happens causing a busy loop burning a cpu
without any gain.
After evaluation of the example case discussed in in #245 and a test
run ignoring EINVAL it was considered safe to add EINVAL to the ignored
errnos to not exit udevEventHandleThread giving it more resilience.
The root cause is in systemd and by now was discussed and fixed via
https://github.com/systemd/systemd/issues/24987, but hardening libvirt
to be able to better deal with EINVAL returned still is the right thing
to avoid the reported busy loops on systemd with older systemd versions.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/245 Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Wed, 9 Nov 2022 10:12:48 +0000 (11:12 +0100)]
qemuMonitorJSONQueryNamedBlockNodes: Drop 'flat' argument
All callers pass the equivalent of looking up whether qemu supports
QEMU_CAPS_QMP_QUERY_NAMED_BLOCK_NODES_FLAT. Use
'mon->queryNamedBlockNodesFlat' directly and refactor all callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 9 Nov 2022 10:06:25 +0000 (11:06 +0100)]
qemuMonitorJSONBlockStatsUpdateCapacityBlockdev: Use 'flat' mode of query-named-block-nodes
'query-named-block-nodes' in non-flat mode returns redundantly nested
data under the 'backing-image' field. Fortunately we don't need it when
updating the capacity stats.
This function was unfortunately not fixed originally when the support
for flat mode was added. Use the flat cached in the monitor object to
force flat mode if available.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 9 Nov 2022 09:53:49 +0000 (10:53 +0100)]
qemu: monitor: Store whether 'query-named-block-nodes' supports 'flat' parameter
Rather than having callers always pass this flag store it in the
qemuMonitor object. Following patches will convert the code to use this
internal flag.
In the future this will also simplify removal when all supported qemu
versions will support the new mode.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 8 Nov 2022 12:42:41 +0000 (13:42 +0100)]
cpu: x86: Group and order hyperv enlightenment features by leaf and register
'VIR_CPU_x86_HV_STIMER_DIRECT' is reported under leaf 0x40000003,
but the data is in the EDX register. Create a new group for such
features and move them after the 0x40000003 EAX group.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu: Add missing 'break' statement in couple of switch()-es
In recent commits migration of TPM on shared storage was
introduced. However, I've only complied it with gcc and thus did
not notice that clang build fails due to missing break; at the
end of some (empty) cases in switch() statements.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Berger [Mon, 24 Oct 2022 10:28:48 +0000 (06:28 -0400)]
qemu: tpm: Never remove state on outgoing migration and shared storage
Never remove the TPM state on outgoing migration if the storage setup
has shared storage for the TPM state files. Also, do not do the security
cleanup on outgoing migration if shared storage is detected.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Berger [Mon, 24 Oct 2022 10:28:47 +0000 (06:28 -0400)]
qemu: tpm: Avoid security labels on incoming migration with shared storage
When using shared storage there is no need to apply security labels on the
storage since the files have to have been labeled already on the source
side and we must assume that the source and destination side have been
setup to use the same uid and gid for running swtpm as well as share the
same security labels. Whether the security labels can be used at all
depends on the shared storage and whether and how it supports them.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Berger [Mon, 24 Oct 2022 10:28:46 +0000 (06:28 -0400)]
qemu: tpm: Pass --migration option to swtpm if supported and needed
Pass the --migration option to swtpm if swptm supports it (starting
with v0.8) and if the TPM's state is written on shared storage. If this
is the case apply the 'release-lock-outgoing' parameter with this
option and apply the 'incoming' parameter for incoming migration so that
swtpm releases the file lock on the source side when the state is migrated
and locks the file on the destination side when the state is received.
If a started swtpm instance is running with the necessary options of
migrating with share storage then remember this with a flag in the
virDomainTPMPrivateDef.
Report an error if swtpm does not support the --migration option and an
incoming migration across shared storage is requested.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Berger [Mon, 24 Oct 2022 10:28:45 +0000 (06:28 -0400)]
qemu: tpm: Add support for storing private TPM-related data
Add support for storing private TPM-related data. The first private data
will be related to the capability of the started swtpm indicating whether
it is capable of migration with a shared storage setup since that requires
support for certain command line flags that were only becoming available
in v0.8.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Berger [Mon, 24 Oct 2022 10:28:44 +0000 (06:28 -0400)]
qemu: tpm: Conditionally create storage on incoming migration
Do not create storage if the TPM state files are on shared storage and
there's an incoming migration since in this case the storage directory
must already exist. Also do not run swtpm_setup in this case.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Berger [Mon, 24 Oct 2022 10:28:43 +0000 (06:28 -0400)]
qemu: tpm: Introduce qemuTPMHasSharedStorage()
New qemuTPMHasSharedStorage() function is introduced which
returns whether the swtpm state directory is on a shared
filesystem (e.g. NFS).
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Tim Wiederhake [Mon, 17 Oct 2022 09:55:08 +0000 (11:55 +0200)]
cpu-data.py: Allow for more than child in feature nodes
cpu-data.py assumes that all "feature" nodes have exactly one child.
This assumption will no longer be true when the cpumap includes alias-
names for features.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Introduced in QEMU's commit of v2.7.0-rc0~32^2~5 the .write-cache
attribute of virtio-blk dvice is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.
The change in some .args is justified, because the qemuxml2argvdatatest
runs these test caseses with very minimalistic set of capabilities,
that's nowhere near real life scenario.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.9.0-rc0~48^2~25 the .share-rw
attribute of virtio-blk device is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.
The change in controller-order.args is justified, because the
qemuxml2argvdatatest runs the test case with very minimalistic
set of capabilities, that's nowhere near real life scenario.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.7.0-rc0~83^2 the .num-queues
attribute of virtio-blk device is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v0.13.0-rc0~1072 the
.logical_block_size attribute of virtio-blk device is always
available for all QEMU versions we support (4.2.0, currently).
Therefore, we can assume the capability is always set and thus
doesn't need to be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v4.2.0-rc0~23^2~4 the .failover
attribute of virtio-net device is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.9.0-rc0~162^2~10 the .host_mtu
attribute of virtio-net device is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.10.0-rc0~95^2~20 the
.tx_queue_size attribute of virtio-net device is always available
for all QEMU versions we support (4.2.0, currently). Therefore,
we can assume the capability is always set and thus doesn't need
to be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.8.0-rc0~116^2~26 the
.rx_queue_size attribute of virtio-net device is always available
for all QEMU versions we support (4.2.0, currently). Therefore,
we can assume the capability is always set and thus doesn't need
to be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v3.1.0-rc3~8^2 the
query-display-options command is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v4.0.0-rc0~202^2~3 the
query-current-machine command is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.12.0-rc0~48^2~25 the
qom-list-properties command is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.6.0-rc0~74^2~6 the
DUMP_COMPLETED event is always available for all QEMU versions we
support (4.2.0, currently). Therefore, we can assume the
capability is always set and thus doesn't need to be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
projects / libvirt.git / log