qemu/target/arm/monitor.c

242 lines
7.2 KiB
C
Raw Normal View History

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.
*/
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"
#include "hw/boards.h"
#include "kvm_arm.h"
#include "qapi/error.h"
#include "qapi/visitor.h"
#include "qapi/qobject-input-visitor.h"
#include "qapi/qapi-commands-machine-target.h"
#include "qapi/qapi-commands-misc-target.h"
#include "qapi/qmp/qerror.h"
#include "qapi/qmp/qdict.h"
#include "qom/qom-qobject.h"
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 GICCapabilityList *gic_cap_list_add(GICCapabilityList *head,
GICCapability *cap)
{
GICCapabilityList *item = g_new0(GICCapabilityList, 1);
item->value = cap;
item->next = head;
return item;
}
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)
{
GICCapabilityList *head = NULL;
GICCapability *v2 = gic_cap_new(2), *v3 = gic_cap_new(3);
v2->emulated = true;
v3->emulated = true;
gic_cap_kvm_probe(v2, v3);
head = gic_cap_list_add(head, v2);
head = gic_cap_list_add(head, v3);
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
}
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);
/*
* 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[] = {
"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",
"kvm-no-adjvtime",
NULL
};
CpuModelExpansionInfo *qmp_query_cpu_model_expansion(CpuModelExpansionType type,
CpuModelInfo *model,
Error **errp)
{
CpuModelExpansionInfo *expansion_info;
const QDict *qdict_in = NULL;
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;
} 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;
}
}
if (!supported) {
error_setg(errp, "We cannot guarantee the CPU type '%s' works "
"with KVM on this host", model->name);
return NULL;
}
}
if (model->props) {
qdict_in = qobject_to(QDict, model->props);
if (!qdict_in) {
error_setg(errp, QERR_INVALID_PARAMETER_TYPE, "props", "dict");
return NULL;
}
}
obj = object_new(object_class_get_name(oc));
if (qdict_in) {
Visitor *visitor;
Error *err = NULL;
visitor = qobject_input_visitor_new(model->props);
visit_start_struct(visitor, NULL, NULL, 0, &err);
if (err) {
visit_free(visitor);
object_unref(obj);
error_propagate(errp, err);
return NULL;
}
i = 0;
while ((name = cpu_model_advertised_features[i++]) != NULL) {
if (qdict_get(qdict_in, name)) {
object_property_set(obj, visitor, name, &err);
if (err) {
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);
}
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 {
arm_cpu_finalize_features(ARM_CPU(obj), &error_abort);
}
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) {
ObjectProperty *prop = object_property_find(obj, name, NULL);
if (prop) {
QObject *value;
assert(prop->get);
value = object_property_get_qobject(obj, name, &error_abort);
qdict_put_obj(qdict_out, name, value);
}
}
if (!qdict_size(qdict_out)) {
qobject_unref(qdict_out);
} else {
expansion_info->model->props = QOBJECT(qdict_out);
expansion_info->model->has_props = true;
}
object_unref(obj);
return expansion_info;
}