This command is hooked into the virsh hypervisor-cpu-compare command.
As such, the CPU model XML provided to the command will be compared
to the hypervisor CPU contained in the QEMU capabilities file for the
appropriate QEMU binary (for s390x, this CPU definition can be observed
via virsh domcapabilities).
QMP will report that the XML CPU is either identical to, a subset of,
or incompatible with the hypervisor CPU. s390 can also report that
the XML CPU is a "superset" of the hypervisor CPU. This response is
presented as incompatible, as this CPU model would not be able to run
on the hypervisor.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielh413@gmail.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Message-Id: <1568924706-2311-15-git-send-email-walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Interfaces with QEMU to compare CPU models. The command takes two CPU
models, A and B, that are given a model name and an optional list of
CPU features. Through the query-cpu-model-comparison command issued
via QMP, a result is produced that contains the comparison evaluation
string (identical, superset, subset, incompatible).
The list of properties (aka CPU features) that is returned from the QMP
response is ignored.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielh413@gmail.com>
Message-Id: <1568924706-2311-12-git-send-email-walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This command is hooked into the virsh hypervisor-cpu-baseline command.
The CPU models provided in the XML sent to the command will be baselined
via the query-cpu-model-baseline QMP command. The resulting CPU model
will be reported.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielh413@gmail.com>
Message-Id: <1568924706-2311-10-git-send-email-walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Interfaces with QEMU to baseline CPU models. The command takes two
CPU models, A and B, that are given a model name and an optional list
of CPU features. Through the query-cpu-model-baseline command issued
via QMP, a result is produced that contains a new baselined CPU model
that is guaranteed to run on both A and B.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielh413@gmail.com>
Message-Id: <1568924706-2311-8-git-send-email-walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Some older s390 CPU models (e.g. z900) will not report props as a
response from query-cpu-model-expansion. As such, we should make the
props field optional when parsing the return data from the QMP response.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Message-Id: <1568924706-2311-6-git-send-email-walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
query-cpu-model-baseline/comparison will accept a list of features
as part of the command. Since CPUs may be defined with CPU feature
policies, let's parse it to the appropriate boolean that the QMP
command expects.
A feature that is set to required, force, or if it is a hypervisor
CPU feature (-1), then set the property value to true. Otherwise
(optional, disabled) set the value to false.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Message-Id: <1568924706-2311-5-git-send-email-walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
When expanding a CPU model via query-cpu-model-expansion, any features
that were a part of the original model are discarded. For exmaple,
when expanding modelA with features f1, f2, a full expansion may reveal
feature f3, but the expanded model will not include f1 or f2.
Let's pass a virCPUDefPtr to the expansion function in preparation for
taking features into consideration.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Message-Id: <1568924706-2311-4-git-send-email-walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Collin Walling