arm: qmp: add query-gic-capabilities interface
This patch add "query-gic-capabilities" but does not implement it. The
command is ARM-only. The command will return a list of GICCapability
structs that describes all GIC versions that current QEMU and system
support.
Libvirt is possibly the first consumer of this new command.
Before this patch, a libvirt user can successfully configure all kinds
of GIC devices for ARM guests, no matter whether current QEMU/kernel
supports them. If the specified GIC version/type is not supported, the
user will get an ambiguous "QEMU boot failure" error when trying to start
the VM. This is not user-friendly.
With this patch, libvirt should be able to query which type (and which
version) of GIC device is supported. Using this information, libvirt
can warn the user during configuration of guests when specified GIC
device type is not supported. Or better, we can just list those versions
that we support, and filter out the unsupported ones.
For example, if we got the query result:
{"return": [{"emulated": false, "version": 3, "kernel": true},
{"emulated": true, "version": 2, "kernel": false}]}
then it means that we support emulated GIC version 2 using:
qemu-system-aarch64 -M virt,accel=tcg,gic-version=2 ...
or KVM-accelerated GIC version 3 using:
qemu-system-aarch64 -M virt,accel=kvm,gic-version=3 ...
If we specify other explicit GIC versions rather than the above, QEMU
will not be able to boot.
The community is working on a more generic way to query these kinds of
information about valid values of machine properties. However, due to
the importance of supporting this specific use case, weecided to first
implement this ad-hoc one; then when the generic method is ready, we
can move on to that one smoothly.
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1458788142-17509-2-git-send-email-peterx@redhat.com
[PMM: tweaked commit message a bit; monitor.o is CONFIG_SOFTMMU only]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-03-30 19:27:24 +03:00
|
|
|
/*
|
|
|
|
* QEMU monitor.c for ARM.
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
2018-02-27 02:13:27 +03:00
|
|
|
|
arm: qmp: add query-gic-capabilities interface
This patch add "query-gic-capabilities" but does not implement it. The
command is ARM-only. The command will return a list of GICCapability
structs that describes all GIC versions that current QEMU and system
support.
Libvirt is possibly the first consumer of this new command.
Before this patch, a libvirt user can successfully configure all kinds
of GIC devices for ARM guests, no matter whether current QEMU/kernel
supports them. If the specified GIC version/type is not supported, the
user will get an ambiguous "QEMU boot failure" error when trying to start
the VM. This is not user-friendly.
With this patch, libvirt should be able to query which type (and which
version) of GIC device is supported. Using this information, libvirt
can warn the user during configuration of guests when specified GIC
device type is not supported. Or better, we can just list those versions
that we support, and filter out the unsupported ones.
For example, if we got the query result:
{"return": [{"emulated": false, "version": 3, "kernel": true},
{"emulated": true, "version": 2, "kernel": false}]}
then it means that we support emulated GIC version 2 using:
qemu-system-aarch64 -M virt,accel=tcg,gic-version=2 ...
or KVM-accelerated GIC version 3 using:
qemu-system-aarch64 -M virt,accel=kvm,gic-version=3 ...
If we specify other explicit GIC versions rather than the above, QEMU
will not be able to boot.
The community is working on a more generic way to query these kinds of
information about valid values of machine properties. However, due to
the importance of supporting this specific use case, weecided to first
implement this ad-hoc one; then when the generic method is ready, we
can move on to that one smoothly.
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1458788142-17509-2-git-send-email-peterx@redhat.com
[PMM: tweaked commit message a bit; monitor.o is CONFIG_SOFTMMU only]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-03-30 19:27:24 +03:00
|
|
|
#include "qemu/osdep.h"
|
2019-10-31 17:27:26 +03:00
|
|
|
#include "hw/boards.h"
|
2016-03-30 19:27:24 +03:00
|
|
|
#include "kvm_arm.h"
|
2019-10-31 17:27:26 +03:00
|
|
|
#include "qapi/error.h"
|
|
|
|
#include "qapi/visitor.h"
|
|
|
|
#include "qapi/qobject-input-visitor.h"
|
|
|
|
#include "qapi/qapi-commands-machine-target.h"
|
2019-06-19 23:10:46 +03:00
|
|
|
#include "qapi/qapi-commands-misc-target.h"
|
2019-10-31 17:27:26 +03:00
|
|
|
#include "qapi/qmp/qdict.h"
|
|
|
|
#include "qom/qom-qobject.h"
|
2016-03-30 19:27:24 +03:00
|
|
|
|
|
|
|
static GICCapability *gic_cap_new(int version)
|
|
|
|
{
|
|
|
|
GICCapability *cap = g_new0(GICCapability, 1);
|
|
|
|
cap->version = version;
|
|
|
|
/* by default, support none */
|
|
|
|
cap->emulated = false;
|
|
|
|
cap->kernel = false;
|
|
|
|
return cap;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void gic_cap_kvm_probe(GICCapability *v2, GICCapability *v3)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_KVM
|
|
|
|
int fdarray[3];
|
|
|
|
|
|
|
|
if (!kvm_arm_create_scratch_host_vcpu(NULL, fdarray, NULL)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Test KVM GICv2 */
|
|
|
|
if (kvm_device_supported(fdarray[1], KVM_DEV_TYPE_ARM_VGIC_V2)) {
|
|
|
|
v2->kernel = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Test KVM GICv3 */
|
|
|
|
if (kvm_device_supported(fdarray[1], KVM_DEV_TYPE_ARM_VGIC_V3)) {
|
|
|
|
v3->kernel = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
kvm_arm_destroy_scratch_host_vcpu(fdarray);
|
|
|
|
#endif
|
|
|
|
}
|
arm: qmp: add query-gic-capabilities interface
This patch add "query-gic-capabilities" but does not implement it. The
command is ARM-only. The command will return a list of GICCapability
structs that describes all GIC versions that current QEMU and system
support.
Libvirt is possibly the first consumer of this new command.
Before this patch, a libvirt user can successfully configure all kinds
of GIC devices for ARM guests, no matter whether current QEMU/kernel
supports them. If the specified GIC version/type is not supported, the
user will get an ambiguous "QEMU boot failure" error when trying to start
the VM. This is not user-friendly.
With this patch, libvirt should be able to query which type (and which
version) of GIC device is supported. Using this information, libvirt
can warn the user during configuration of guests when specified GIC
device type is not supported. Or better, we can just list those versions
that we support, and filter out the unsupported ones.
For example, if we got the query result:
{"return": [{"emulated": false, "version": 3, "kernel": true},
{"emulated": true, "version": 2, "kernel": false}]}
then it means that we support emulated GIC version 2 using:
qemu-system-aarch64 -M virt,accel=tcg,gic-version=2 ...
or KVM-accelerated GIC version 3 using:
qemu-system-aarch64 -M virt,accel=kvm,gic-version=3 ...
If we specify other explicit GIC versions rather than the above, QEMU
will not be able to boot.
The community is working on a more generic way to query these kinds of
information about valid values of machine properties. However, due to
the importance of supporting this specific use case, weecided to first
implement this ad-hoc one; then when the generic method is ready, we
can move on to that one smoothly.
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1458788142-17509-2-git-send-email-peterx@redhat.com
[PMM: tweaked commit message a bit; monitor.o is CONFIG_SOFTMMU only]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-03-30 19:27:24 +03:00
|
|
|
|
|
|
|
GICCapabilityList *qmp_query_gic_capabilities(Error **errp)
|
|
|
|
{
|
2016-03-30 19:27:24 +03:00
|
|
|
GICCapabilityList *head = NULL;
|
|
|
|
GICCapability *v2 = gic_cap_new(2), *v3 = gic_cap_new(3);
|
|
|
|
|
|
|
|
v2->emulated = true;
|
2016-06-17 17:23:48 +03:00
|
|
|
v3->emulated = true;
|
2016-03-30 19:27:24 +03:00
|
|
|
|
|
|
|
gic_cap_kvm_probe(v2, v3);
|
|
|
|
|
2020-11-13 04:13:37 +03:00
|
|
|
QAPI_LIST_PREPEND(head, v2);
|
|
|
|
QAPI_LIST_PREPEND(head, v3);
|
2016-03-30 19:27:24 +03:00
|
|
|
|
|
|
|
return head;
|
arm: qmp: add query-gic-capabilities interface
This patch add "query-gic-capabilities" but does not implement it. The
command is ARM-only. The command will return a list of GICCapability
structs that describes all GIC versions that current QEMU and system
support.
Libvirt is possibly the first consumer of this new command.
Before this patch, a libvirt user can successfully configure all kinds
of GIC devices for ARM guests, no matter whether current QEMU/kernel
supports them. If the specified GIC version/type is not supported, the
user will get an ambiguous "QEMU boot failure" error when trying to start
the VM. This is not user-friendly.
With this patch, libvirt should be able to query which type (and which
version) of GIC device is supported. Using this information, libvirt
can warn the user during configuration of guests when specified GIC
device type is not supported. Or better, we can just list those versions
that we support, and filter out the unsupported ones.
For example, if we got the query result:
{"return": [{"emulated": false, "version": 3, "kernel": true},
{"emulated": true, "version": 2, "kernel": false}]}
then it means that we support emulated GIC version 2 using:
qemu-system-aarch64 -M virt,accel=tcg,gic-version=2 ...
or KVM-accelerated GIC version 3 using:
qemu-system-aarch64 -M virt,accel=kvm,gic-version=3 ...
If we specify other explicit GIC versions rather than the above, QEMU
will not be able to boot.
The community is working on a more generic way to query these kinds of
information about valid values of machine properties. However, due to
the importance of supporting this specific use case, weecided to first
implement this ad-hoc one; then when the generic method is ready, we
can move on to that one smoothly.
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1458788142-17509-2-git-send-email-peterx@redhat.com
[PMM: tweaked commit message a bit; monitor.o is CONFIG_SOFTMMU only]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-03-30 19:27:24 +03:00
|
|
|
}
|
2019-10-31 17:27:26 +03:00
|
|
|
|
target/arm/cpu64: max cpu: Introduce sve<N> properties
Introduce cpu properties to give fine control over SVE vector lengths.
We introduce a property for each valid length up to the current
maximum supported, which is 2048-bits. The properties are named, e.g.
sve128, sve256, sve384, sve512, ..., where the number is the number of
bits. See the updates to docs/arm-cpu-features.rst for a description
of the semantics and for example uses.
Note, as sve-max-vq is still present and we'd like to be able to
support qmp_query_cpu_model_expansion with guests launched with e.g.
-cpu max,sve-max-vq=8 on their command lines, then we do allow
sve-max-vq and sve<N> properties to be provided at the same time, but
this is not recommended, and is why sve-max-vq is not mentioned in the
document. If sve-max-vq is provided then it enables all lengths smaller
than and including the max and disables all lengths larger. It also has
the side-effect that no larger lengths may be enabled and that the max
itself cannot be disabled. Smaller non-power-of-two lengths may,
however, be disabled, e.g. -cpu max,sve-max-vq=4,sve384=off provides a
guest the vector lengths 128, 256, and 512 bits.
This patch has been co-authored with Richard Henderson, who reworked
the target/arm/cpu64.c changes in order to push all the validation and
auto-enabling/disabling steps into the finalizer, resulting in a nice
LOC reduction.
Signed-off-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reviewed-by: Beata Michalska <beata.michalska@linaro.org>
Message-id: 20191031142734.8590-5-drjones@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-31 17:27:29 +03:00
|
|
|
QEMU_BUILD_BUG_ON(ARM_MAX_VQ > 16);
|
|
|
|
|
2019-10-31 17:27:26 +03:00
|
|
|
/*
|
|
|
|
* These are cpu model features we want to advertise. The order here
|
|
|
|
* matters as this is the order in which qmp_query_cpu_model_expansion
|
|
|
|
* will attempt to set them. If there are dependencies between features,
|
|
|
|
* then the order that considers those dependencies must be used.
|
|
|
|
*/
|
|
|
|
static const char *cpu_model_advertised_features[] = {
|
2019-10-31 17:27:28 +03:00
|
|
|
"aarch64", "pmu", "sve",
|
target/arm/cpu64: max cpu: Introduce sve<N> properties
Introduce cpu properties to give fine control over SVE vector lengths.
We introduce a property for each valid length up to the current
maximum supported, which is 2048-bits. The properties are named, e.g.
sve128, sve256, sve384, sve512, ..., where the number is the number of
bits. See the updates to docs/arm-cpu-features.rst for a description
of the semantics and for example uses.
Note, as sve-max-vq is still present and we'd like to be able to
support qmp_query_cpu_model_expansion with guests launched with e.g.
-cpu max,sve-max-vq=8 on their command lines, then we do allow
sve-max-vq and sve<N> properties to be provided at the same time, but
this is not recommended, and is why sve-max-vq is not mentioned in the
document. If sve-max-vq is provided then it enables all lengths smaller
than and including the max and disables all lengths larger. It also has
the side-effect that no larger lengths may be enabled and that the max
itself cannot be disabled. Smaller non-power-of-two lengths may,
however, be disabled, e.g. -cpu max,sve-max-vq=4,sve384=off provides a
guest the vector lengths 128, 256, and 512 bits.
This patch has been co-authored with Richard Henderson, who reworked
the target/arm/cpu64.c changes in order to push all the validation and
auto-enabling/disabling steps into the finalizer, resulting in a nice
LOC reduction.
Signed-off-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reviewed-by: Beata Michalska <beata.michalska@linaro.org>
Message-id: 20191031142734.8590-5-drjones@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-31 17:27:29 +03:00
|
|
|
"sve128", "sve256", "sve384", "sve512",
|
|
|
|
"sve640", "sve768", "sve896", "sve1024", "sve1152", "sve1280",
|
|
|
|
"sve1408", "sve1536", "sve1664", "sve1792", "sve1920", "sve2048",
|
2020-10-01 09:17:18 +03:00
|
|
|
"kvm-no-adjvtime", "kvm-steal-time",
|
2023-08-30 02:23:28 +03:00
|
|
|
"pauth", "pauth-impdef", "pauth-qarma3",
|
2019-10-31 17:27:26 +03:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
CpuModelExpansionInfo *qmp_query_cpu_model_expansion(CpuModelExpansionType type,
|
|
|
|
CpuModelInfo *model,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
CpuModelExpansionInfo *expansion_info;
|
2024-03-05 17:59:15 +03:00
|
|
|
const QDict *qdict_in;
|
2019-10-31 17:27:26 +03:00
|
|
|
QDict *qdict_out;
|
|
|
|
ObjectClass *oc;
|
|
|
|
Object *obj;
|
|
|
|
const char *name;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (type != CPU_MODEL_EXPANSION_TYPE_FULL) {
|
|
|
|
error_setg(errp, "The requested expansion type is not supported");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!kvm_enabled() && !strcmp(model->name, "host")) {
|
|
|
|
error_setg(errp, "The CPU type '%s' requires KVM", model->name);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
oc = cpu_class_by_name(TYPE_ARM_CPU, model->name);
|
|
|
|
if (!oc) {
|
|
|
|
error_setg(errp, "The CPU type '%s' is not a recognized ARM CPU type",
|
|
|
|
model->name);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (kvm_enabled()) {
|
|
|
|
bool supported = false;
|
|
|
|
|
|
|
|
if (!strcmp(model->name, "host") || !strcmp(model->name, "max")) {
|
|
|
|
/* These are kvmarm's recommended cpu types */
|
|
|
|
supported = true;
|
2020-02-07 17:04:21 +03:00
|
|
|
} else if (current_machine->cpu_type) {
|
|
|
|
const char *cpu_type = current_machine->cpu_type;
|
|
|
|
int len = strlen(cpu_type) - strlen(ARM_CPU_TYPE_SUFFIX);
|
|
|
|
|
|
|
|
if (strlen(model->name) == len &&
|
|
|
|
!strncmp(model->name, cpu_type, len)) {
|
|
|
|
/* KVM is enabled and we're using this type, so it works. */
|
|
|
|
supported = true;
|
|
|
|
}
|
2019-10-31 17:27:26 +03:00
|
|
|
}
|
|
|
|
if (!supported) {
|
|
|
|
error_setg(errp, "We cannot guarantee the CPU type '%s' works "
|
|
|
|
"with KVM on this host", model->name);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
obj = object_new(object_class_get_name(oc));
|
|
|
|
|
2024-03-05 17:59:15 +03:00
|
|
|
if (model->props) {
|
2019-10-31 17:27:26 +03:00
|
|
|
Visitor *visitor;
|
|
|
|
Error *err = NULL;
|
|
|
|
|
|
|
|
visitor = qobject_input_visitor_new(model->props);
|
target: Improve error reporting for CpuModelInfo member @props
query-cpu-model-comparison, query-cpu-model-baseline, and
query-cpu-model-expansion take CpuModelInfo arguments. Errors in
@props members of these arguments are reported for 'props', without
further context. For instance, s390x rejects
{"execute": "query-cpu-model-comparison", "arguments": {"modela": {"name": "z13", "props": {}}, "modelb": {"name": "z14", "props": []}}}
with
{"error": {"class": "GenericError", "desc": "Invalid parameter type for 'props', expected: object"}}
This is unusual; the common QAPI unmarshaling machinery would complain
about 'modelb.props'. Our hand-written code to visit the @props
member neglects to provide the context.
Tweak it so it provides it. The command above now fails with
{"error": {"class": "GenericError", "desc": "Invalid parameter type for 'modelb.props', expected: dict"}}
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20240305145919.2186971-4-armbru@redhat.com>
Acked-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
2024-03-05 17:59:17 +03:00
|
|
|
if (!visit_start_struct(visitor, "model.props", NULL, 0, errp)) {
|
2019-10-31 17:27:26 +03:00
|
|
|
visit_free(visitor);
|
|
|
|
object_unref(obj);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2024-03-05 17:59:15 +03:00
|
|
|
qdict_in = qobject_to(QDict, model->props);
|
2019-10-31 17:27:26 +03:00
|
|
|
i = 0;
|
|
|
|
while ((name = cpu_model_advertised_features[i++]) != NULL) {
|
|
|
|
if (qdict_get(qdict_in, name)) {
|
qom: Use returned bool to check for failure, Coccinelle part
The previous commit enables conversion of
foo(..., &err);
if (err) {
...
}
to
if (!foo(..., errp)) {
...
}
for QOM functions that now return true / false on success / error.
Coccinelle script:
@@
identifier fun = {
object_apply_global_props, object_initialize_child_with_props,
object_initialize_child_with_propsv, object_property_get,
object_property_get_bool, object_property_parse, object_property_set,
object_property_set_bool, object_property_set_int,
object_property_set_link, object_property_set_qobject,
object_property_set_str, object_property_set_uint, object_set_props,
object_set_propv, user_creatable_add_dict,
user_creatable_complete, user_creatable_del
};
expression list args, args2;
typedef Error;
Error *err;
@@
- fun(args, &err, args2);
- if (err)
+ if (!fun(args, &err, args2))
{
...
}
Fails to convert hw/arm/armsse.c, because Coccinelle gets confused by
ARMSSE being used both as typedef and function-like macro there.
Convert manually.
Line breaks tidied up manually.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200707160613.848843-29-armbru@redhat.com>
2020-07-07 19:05:56 +03:00
|
|
|
if (!object_property_set(obj, name, visitor, &err)) {
|
2019-10-31 17:27:26 +03:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!err) {
|
|
|
|
visit_check_struct(visitor, &err);
|
|
|
|
}
|
target/arm/cpu64: max cpu: Introduce sve<N> properties
Introduce cpu properties to give fine control over SVE vector lengths.
We introduce a property for each valid length up to the current
maximum supported, which is 2048-bits. The properties are named, e.g.
sve128, sve256, sve384, sve512, ..., where the number is the number of
bits. See the updates to docs/arm-cpu-features.rst for a description
of the semantics and for example uses.
Note, as sve-max-vq is still present and we'd like to be able to
support qmp_query_cpu_model_expansion with guests launched with e.g.
-cpu max,sve-max-vq=8 on their command lines, then we do allow
sve-max-vq and sve<N> properties to be provided at the same time, but
this is not recommended, and is why sve-max-vq is not mentioned in the
document. If sve-max-vq is provided then it enables all lengths smaller
than and including the max and disables all lengths larger. It also has
the side-effect that no larger lengths may be enabled and that the max
itself cannot be disabled. Smaller non-power-of-two lengths may,
however, be disabled, e.g. -cpu max,sve-max-vq=4,sve384=off provides a
guest the vector lengths 128, 256, and 512 bits.
This patch has been co-authored with Richard Henderson, who reworked
the target/arm/cpu64.c changes in order to push all the validation and
auto-enabling/disabling steps into the finalizer, resulting in a nice
LOC reduction.
Signed-off-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reviewed-by: Beata Michalska <beata.michalska@linaro.org>
Message-id: 20191031142734.8590-5-drjones@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-31 17:27:29 +03:00
|
|
|
if (!err) {
|
|
|
|
arm_cpu_finalize_features(ARM_CPU(obj), &err);
|
|
|
|
}
|
2019-10-31 17:27:26 +03:00
|
|
|
visit_end_struct(visitor, NULL);
|
|
|
|
visit_free(visitor);
|
|
|
|
if (err) {
|
|
|
|
object_unref(obj);
|
|
|
|
error_propagate(errp, err);
|
|
|
|
return NULL;
|
|
|
|
}
|
target/arm/cpu64: max cpu: Introduce sve<N> properties
Introduce cpu properties to give fine control over SVE vector lengths.
We introduce a property for each valid length up to the current
maximum supported, which is 2048-bits. The properties are named, e.g.
sve128, sve256, sve384, sve512, ..., where the number is the number of
bits. See the updates to docs/arm-cpu-features.rst for a description
of the semantics and for example uses.
Note, as sve-max-vq is still present and we'd like to be able to
support qmp_query_cpu_model_expansion with guests launched with e.g.
-cpu max,sve-max-vq=8 on their command lines, then we do allow
sve-max-vq and sve<N> properties to be provided at the same time, but
this is not recommended, and is why sve-max-vq is not mentioned in the
document. If sve-max-vq is provided then it enables all lengths smaller
than and including the max and disables all lengths larger. It also has
the side-effect that no larger lengths may be enabled and that the max
itself cannot be disabled. Smaller non-power-of-two lengths may,
however, be disabled, e.g. -cpu max,sve-max-vq=4,sve384=off provides a
guest the vector lengths 128, 256, and 512 bits.
This patch has been co-authored with Richard Henderson, who reworked
the target/arm/cpu64.c changes in order to push all the validation and
auto-enabling/disabling steps into the finalizer, resulting in a nice
LOC reduction.
Signed-off-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reviewed-by: Beata Michalska <beata.michalska@linaro.org>
Message-id: 20191031142734.8590-5-drjones@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-31 17:27:29 +03:00
|
|
|
} else {
|
2020-03-13 20:05:15 +03:00
|
|
|
arm_cpu_finalize_features(ARM_CPU(obj), &error_abort);
|
2019-10-31 17:27:26 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
expansion_info = g_new0(CpuModelExpansionInfo, 1);
|
|
|
|
expansion_info->model = g_malloc0(sizeof(*expansion_info->model));
|
|
|
|
expansion_info->model->name = g_strdup(model->name);
|
|
|
|
|
|
|
|
qdict_out = qdict_new();
|
|
|
|
|
|
|
|
i = 0;
|
|
|
|
while ((name = cpu_model_advertised_features[i++]) != NULL) {
|
2020-09-14 16:56:17 +03:00
|
|
|
ObjectProperty *prop = object_property_find(obj, name);
|
2019-10-31 17:27:26 +03:00
|
|
|
if (prop) {
|
|
|
|
QObject *value;
|
|
|
|
|
|
|
|
assert(prop->get);
|
2020-03-13 20:05:15 +03:00
|
|
|
value = object_property_get_qobject(obj, name, &error_abort);
|
2019-10-31 17:27:26 +03:00
|
|
|
|
|
|
|
qdict_put_obj(qdict_out, name, value);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!qdict_size(qdict_out)) {
|
|
|
|
qobject_unref(qdict_out);
|
|
|
|
} else {
|
|
|
|
expansion_info->model->props = QOBJECT(qdict_out);
|
|
|
|
}
|
|
|
|
|
|
|
|
object_unref(obj);
|
|
|
|
|
|
|
|
return expansion_info;
|
|
|
|
}
|
2023-02-23 18:55:37 +03:00
|
|
|
|
|
|
|
static void arm_cpu_add_definition(gpointer data, gpointer user_data)
|
|
|
|
{
|
|
|
|
ObjectClass *oc = data;
|
|
|
|
CpuDefinitionInfoList **cpu_list = user_data;
|
|
|
|
CpuDefinitionInfo *info;
|
|
|
|
const char *typename;
|
|
|
|
|
|
|
|
typename = object_class_get_name(oc);
|
|
|
|
info = g_malloc0(sizeof(*info));
|
2023-11-15 02:56:19 +03:00
|
|
|
info->name = cpu_model_from_type(typename);
|
2023-02-23 18:55:37 +03:00
|
|
|
info->q_typename = g_strdup(typename);
|
|
|
|
|
|
|
|
QAPI_LIST_PREPEND(*cpu_list, info);
|
|
|
|
}
|
|
|
|
|
|
|
|
CpuDefinitionInfoList *qmp_query_cpu_definitions(Error **errp)
|
|
|
|
{
|
|
|
|
CpuDefinitionInfoList *cpu_list = NULL;
|
|
|
|
GSList *list;
|
|
|
|
|
|
|
|
list = object_class_get_list(TYPE_ARM_CPU, false);
|
|
|
|
g_slist_foreach(list, arm_cpu_add_definition, &cpu_list);
|
|
|
|
g_slist_free(list);
|
|
|
|
|
|
|
|
return cpu_list;
|
|
|
|
}
|