Clarify documentation of virConnectBaselineHypervisorCPU

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>
This commit is contained in:
Jiri Denemark
2025-07-18 11:56:13 +02:00
parent 999d155b21
commit d74928fed3
2 changed files with 23 additions and 12 deletions
+8 -3
View File
@@ -1015,9 +1015,14 @@ hypervisor-cpu-baseline
[--features] [--migratable] [model]
Compute a baseline CPU which will be compatible with all CPUs defined in an XML
*file* and with the CPU the hypervisor is able to provide on the host. (This
is different from ``cpu-baseline`` which does not consider any hypervisor
abilities when computing the baseline CPU.)
*FILE*. This command must be called on one of the hosts described in *FILE*.
Calling it on another host results in an undefined behavior as the computed CPU
model is influenced by the hypervisor (the result may use an unexpected CPU
model or some features may disabled even though they are supported on all input
CPUs).
This is different from ``cpu-baseline`` which does not consider any hypervisor
abilities when computing the baseline CPU.
As an alternative for *FILE* in case the XML would only contain a CPU model
with no additional features the CPU model name itself can be passed as *model*.