With qom-list-get we already have the value of unavailable-features
property in the returned object (just like we have all values of all
bool properties). Let's use the value from there instead of querying for
it separately using qom-get.
After this patch only a single QMP command is used for getting all the
required info about guest CPUs created by QEMU 10.1 or newer.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemuMonitorJSONGetCPUDataDisabled function is just a wrapper around
two function calls and it is only used by qemuMonitorJSONGetGuestCPU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemuMonitorJSONGetCPUData function is just a wrapper around two
function calls and it is only used by qemuMonitorJSONGetGuestCPU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function translates a list of CPU feature names retrieved from QEMU
and adds them to virCPUData.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test cases show both the legacy method and the new one produce
identical results.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qom-list-get is a new QMP command (since QEMU 10.1) that combines
qom-list for listing properties of a specified object with qom-get for
getting a value of a given property. The new command provides an array
of all properties and their values, which allows us to dramatically
reduce the number of QMP commands we have to call when starting a domain
to check which CPU features were actually enabled.
A simple domain with no disk can now be started with only 15 QMP
commands in about 200 ms compared to 485 commands and 400 ms startup
time without this patch.
https://issues.redhat.com/browse/RHEL-7038
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemuMonitorJSONParsePropsList API expected a QMP reply as an input.
By generalizing it to work on any JSON array, we can reuse the API even
for commands which return the array of properties nested in an object.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When getting enabled CPU features (qemuMonitorJSONGetCPUData), we used
to call qemuMonitorJSONGetCPUProperties to get the list of all boolean
properties and then queried their values and ignored properties that
were not true. By moving the filtering inside
qemuMonitorJSONGetCPUProperties we don't need to even add disabled
features to any list and also get ready for better QMP interface.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuMonitorJSONParsePropsList supported filtering based on type. Let's
replace it with a callback supplied by the caller to allow for more
advanced filtering.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The key point here is that the unavailable-features property reports an
empty array.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The SierraForest CPU was just randomly chosen and it doesn't mean we
should have test cases for all CPU models.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The legacy probing which reads CPUID registers from QEMU and interprets
the individual bits is not used with any QEMU version currently
supported by libvirt. The code would only be used if
QEMU_CAPS_CPU_UNAVAILABLE_FEATURES capability (detected by probing the
presence of 'unavailable-features') was missing on x86, but all QEMU
release we care about report unavailable-features on x86.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With this new flag virConnectHypervisorBaselineCPU can be used on any
host (rather than being limited to hosts described by individual CPUs
passed to the API). Using the flag makes the API behave similarly to the
old virConnectBaselineCPU. The main difference is the CPU definition
accepted by both APIs: the old one only accepts host CPU definition,
i.e., without 'policy' attributes as seen in the host capabilities XML.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Moving the documentation above each enum item gives us more space for
it.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The API was apparently never considered for being used on a host that is
not represented in the input set of CPU definitions. The result is
limited to the set of features and CPU models known to the host's
hypervisor. This would likely not be a big issue, but thanks to a side
effect of commit v3.8.0-99-g9c9620af1d usability blockers come to play
as well. When converting CPU data (CPUID and MSR bits) to each named
model for comparison, we disable features that block usability of the
model on the current hypervisor, the rest of the features are set
according to the data without taking host capabilities into account.
Thus the process of comparing and selecting the most appropriate CPU
model for the given data is significantly influenced by the host, but it
doesn't behave as if the host CPU model was included in the input data.
The documentation tried to say the result was tied to the host's
hypervisor, but it wasn't very clear.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The function is called by virFileIsSharedFSOverride which is not Linux
specific and thus building on anything but Linux failes.
Fixes: 94fb348d67
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The code was separated from virFileIsSharedFSType which is Linux-only,
but virFileGetExistingParent is also called from
virFileIsSharedFSOverride which is OS independent. Thus we can't use
statfs. Let's use virFileExists (access) instead, we were not interested
in anything but success/failure from statfs anyway.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Commit v11.0.0-162-gf2023e8018 added path canonicalization to
virFileIsSharedFSOverride to make sure we can properly match shared
filesystem override paths which include symlinks. But
virFileCanonicalizePath only works on existing paths, while
virFileIsSharedFSOverride may be called on paths that do not exist yet.
Matching paths against overrides has always worked even for nonexistent
paths. To fix the regression we need to first get the longest existing
sub-path and canonicalize only this part and use the result for
searching in overrides. Clearly any portion of the path we dynamically
create is not going to end up on a different filesystem to what the
parent directory is stored in. So checking just the existing parent is
enough.
https://issues.redhat.com/browse/RHEL-86592
Fixes: f2023e8018
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code from virFileIsSharedFSType which finds the longest existing
path for a given input is separated into a new helper so that it can be
reused elsewhere.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
On most platforms virFileCanonicalizePath is implemented using
realpath(), which only works on existing paths.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The VIR_ERR_NO_SUPPORT error is supposed to be used for unsupported
driver APIs. It is incorrectly used when swtpm does not support
migration with shared storage resulting in a rather strange error
message:
this function is not supported by the connection driver: the running
swtpm does not support migration with shared storage
The correct VIR_ERR_OPERATION_UNSUPPORTED error code provides a much
better message:
Operation not supported: the running swtpm does not support
migration with shared storage
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since commit 28a0621528 (released in 11.2.0) resuming a failed
post-copy migration calls qemuProcessIncomingDefNew with fd == NULL
rather than -1. The function does not expect to be called with NULL file
descriptor and tries to dereference it causing virtqemud on the
destination host to crash.
Fixes: 28a0621528
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This patch is effectively a NOP, but it fixes a logic bug and makes the
heuristics more visible and easier to change should there be a need to
do so in the future.
We decide which CPU model is the best match for given CPU data by
comparing lists of features that need to be enabled/disabled on top of
the selected CPU model. Since the original approach of using just the
total number of features was not working well enough, commit
v8.3.0-42-g48341b025a implemented a penalty for disabled features which
would increase for each additional disabled features. Apparently the
intention was weighting disabled features as
disabled * (disabled + 3)
weightDisabled = -------------------------
2
and complete CPU model as
weight = enabled + weightDisabled
But there was a bug in the code which caused it to ignore some of the
features and counted as enabled regardless on their policy. Instead of
going through all features the code used the number of "enabled"
features (the variable was not really counting number of enabled
features though) which was initialized to the total number of features
and decremented each time a disabled features was found. Thus depending
on the number of disabled features, some features at the end of the list
were ignored. Luckily we know all the ignored features had to be
disabled because the CPU definitions were created by x86DataToCPU which
constructs a list of enabled features followed by disabled features.
So to fix the bug while providing the same results we can come up with
an equivalent formula using properly counted features in the CPU
definition.
The number of disabled features counted by the buggy code is
half = (disabled + 1) div 2
and the weight of all disabled features is
half * (half + 3)
weightDisabled = -----------------
2
When computing the total weight, we can't no longer use number of
enabled features because the original code counted some of the disabled
features as enabled. So to match the old behavior, we count the total
weight as
weight = features - half + weightDisabled
The weight of enabled features now differs from the value computed by
the old code, but we don't need to worry about it as it's not really
used anywhere except for logging.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/759
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Refactor weight calculation to a separate virCPUx86WeightFeatures
function to avoid code duplication. The algorithm is not changed during
the refactoring, it will be fixed later.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When migrating a domain with TPM state on a shared disk, we need to skip
TPM cleanup on both ends. So far the code only handled successful
migration and skipped the cleanup on the source host. But if the
migration failed for some reason, the cleanup would be incorrectly
called on the destination host removing the TPM files even though the
domain was still running on the source host.
https://issues.redhat.com/browse/RHEL-82411
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The parameter is used to skip TPM state cleanup on outgoing migration
with shared storage. But we also need to skip the cleanup after a failed
incoming migration. Let's call the parameter "migration" to reflect its
usage on both sides of migration.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The purpose of this test is to enforce loading and parsing of ARM CPU
map so that possible issues are found earlier.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
With a specific combination of compiler options gcc reported the
following bogus warning (I added a context to it to make the issue
visible):
../src/esx/esx_vi.c: In function ‘esxVI_LookupHostScsiTopologyLunListByTargetName’:
../src/esx/esx_vi.c:4674:32: error: potential null pointer dereference [-Werror=null-dereference]
4671 | if (!found || !hostScsiTopologyTarget)
4672 | goto cleanup;
4673 |
4674 | if (!hostScsiTopologyTarget->lun) {
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~
Most likely this is caused by found and hostScsiTopologyTarget doing
essentially the same thing as found is true if and only if
hostScsiTopologyTarget is non-NULL. The found variable is completely
redundant. Removing it would be enough, but I decided to make the code a
little bit easier to read by not using the iterator variable directly.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When virCPUx86UpdateLive checks whether a feature was added to a CPU
model after the model was already released (vmx-* features in most Intel
models), the following assert could be logged by glib:
g_strv_contains: assertion 'strv != NULL' failed
While most of our CPU models have a non-empty list of added feature, new
models added in 2024 and versioned variants of older models have
addedFeatures == NULL.
Fixes: e622970c87
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Only libvirtd uses virtd_t/virt_exec_t context, modular daemons use
their specific context each.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
To make sure both error and warning messages printed by virsh are
properly marked for translation.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The prohibit_newline_at_end_of_diagnostic syntax check is confused when
another unrelated translatable message with a newline is too close to
the function it is supposed to check. Refactoring the code to make the
two strings further apart seems like the easiest solution.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Having to put a newline at the end of each debug message in virsh has
always felt strange.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
While using host CPU definition from capabilities XML is allowed for
historical reasons, it will likely provide incorrect results and should
be avoided.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This new function can be used for printing warnings about suboptimal
usage.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The code is moved into a newly introduced generic vshPrintStderr and
vshError changed into a tiny wrapper.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The same message was formatted both in vshOutputLogFile and in vshDebug
and vshError functions. This patch refactor vshOutputLogFile and its
callers to only format each message once.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Using host CPU definition with hypervisor-cpu-baseline is possible, but
it provide incorrect results and thus it should not be documented the
same way we describe the correct usage. Also using host-model CPU from
domain capabilities was not described clearly enough.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Using host CPU definition with hypervisor-cpu-compare is possible, but
it provide incorrect results and thus it should not be documented the
same way we describe the correct usage. Also using host-model CPU from
domain capabilities was not described clearly enough.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When a migration with non-shared storage is started with
VIR_MIGRATE_PARAM_BANDWIDTH set, it will be applied to both memory
migration and each block job started for storage migration. Once the
migration is running virDomainMigrateSetMaxSpeed may be used to change
the bandwidth used by memory migration, but there was no way of changing
storage migration speed. Let's allow virDomainBlockJobSetSpeed during
migration to enable the missing functionality.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark