2013-09-03 23:12:07 +04:00
|
|
|
/*
|
|
|
|
* QEMU AArch64 CPU
|
|
|
|
*
|
|
|
|
* Copyright (c) 2013 Linaro Ltd
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, see
|
|
|
|
* <http://www.gnu.org/licenses/gpl-2.0.html>
|
|
|
|
*/
|
|
|
|
|
2015-12-07 19:23:44 +03:00
|
|
|
#include "qemu/osdep.h"
|
include/qemu/osdep.h: Don't include qapi/error.h
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the
Error typedef. Since then, we've moved to include qemu/osdep.h
everywhere. Its file comment explains: "To avoid getting into
possible circular include dependencies, this file should not include
any other QEMU headers, with the exceptions of config-host.h,
compiler.h, os-posix.h and os-win32.h, all of which are doing a
similar job to this file and are under similar constraints."
qapi/error.h doesn't do a similar job, and it doesn't adhere to
similar constraints: it includes qapi-types.h. That's in excess of
100KiB of crap most .c files don't actually need.
Add the typedef to qemu/typedefs.h, and include that instead of
qapi/error.h. Include qapi/error.h in .c files that need it and don't
get it now. Include qapi-types.h in qom/object.h for uint16List.
Update scripts/clean-includes accordingly. Update it further to match
reality: replace config.h by config-target.h, add sysemu/os-posix.h,
sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h
comment quoted above similarly.
This reduces the number of objects depending on qapi/error.h from "all
of them" to less than a third. Unfortunately, the number depending on
qapi-types.h shrinks only a little. More work is needed for that one.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[Fix compilation without the spice devel packages. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-14 11:01:28 +03:00
|
|
|
#include "qapi/error.h"
|
2013-09-03 23:12:07 +04:00
|
|
|
#include "cpu.h"
|
2023-03-13 06:39:36 +03:00
|
|
|
#include "cpregs.h"
|
2019-05-23 17:35:07 +03:00
|
|
|
#include "qemu/module.h"
|
2013-09-03 23:12:07 +04:00
|
|
|
#include "sysemu/kvm.h"
|
2022-02-04 19:55:05 +03:00
|
|
|
#include "sysemu/hvf.h"
|
2023-04-26 21:00:04 +03:00
|
|
|
#include "sysemu/qtest.h"
|
|
|
|
#include "sysemu/tcg.h"
|
2018-03-09 20:09:44 +03:00
|
|
|
#include "kvm_arm.h"
|
2022-02-04 19:55:01 +03:00
|
|
|
#include "hvf_arm.h"
|
2018-08-16 16:05:28 +03:00
|
|
|
#include "qapi/visitor.h"
|
2021-01-12 02:57:39 +03:00
|
|
|
#include "hw/qdev-properties.h"
|
2022-05-06 21:02:23 +03:00
|
|
|
#include "internals.h"
|
2023-10-24 19:35:05 +03:00
|
|
|
#include "cpu-features.h"
|
2023-04-26 21:00:01 +03:00
|
|
|
#include "cpregs.h"
|
2021-01-12 02:57:39 +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
|
|
|
void arm_cpu_sve_finalize(ARMCPU *cpu, Error **errp)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If any vector lengths are explicitly enabled with sve<N> properties,
|
|
|
|
* then all other lengths are implicitly disabled. If sve-max-vq is
|
|
|
|
* specified then it is the same as explicitly enabling all lengths
|
|
|
|
* up to and including the specified maximum, which means all larger
|
|
|
|
* lengths will be implicitly disabled. If no sve<N> properties
|
|
|
|
* are enabled and sve-max-vq is not specified, then all lengths not
|
|
|
|
* explicitly disabled will be enabled. Additionally, all power-of-two
|
|
|
|
* vector lengths less than the maximum enabled length will be
|
|
|
|
* automatically enabled and all vector lengths larger than the largest
|
|
|
|
* disabled power-of-two vector length will be automatically disabled.
|
|
|
|
* Errors are generated if the user provided input that interferes with
|
|
|
|
* any of the above. Finally, if SVE is not disabled, then at least one
|
|
|
|
* vector length must be enabled.
|
|
|
|
*/
|
2022-06-20 20:51:56 +03:00
|
|
|
uint32_t vq_map = cpu->sve_vq.map;
|
|
|
|
uint32_t vq_init = cpu->sve_vq.init;
|
2022-06-08 21:38:57 +03:00
|
|
|
uint32_t vq_supported;
|
|
|
|
uint32_t vq_mask = 0;
|
|
|
|
uint32_t tmp, vq, max_vq = 0;
|
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
|
|
|
|
2021-08-23 19:06:46 +03:00
|
|
|
/*
|
|
|
|
* CPU models specify a set of supported vector lengths which are
|
|
|
|
* enabled by default. Attempting to enable any vector length not set
|
|
|
|
* in the supported bitmap results in an error. When KVM is enabled we
|
|
|
|
* fetch the supported bitmap from the host.
|
|
|
|
*/
|
2022-06-08 21:38:57 +03:00
|
|
|
if (kvm_enabled()) {
|
|
|
|
if (kvm_arm_sve_supported()) {
|
2023-12-19 20:57:45 +03:00
|
|
|
cpu->sve_vq.supported = kvm_arm_sve_get_vls(cpu);
|
2022-06-20 20:51:56 +03:00
|
|
|
vq_supported = cpu->sve_vq.supported;
|
2022-06-08 21:38:57 +03:00
|
|
|
} else {
|
|
|
|
assert(!cpu_isar_feature(aa64_sve, cpu));
|
|
|
|
vq_supported = 0;
|
|
|
|
}
|
|
|
|
} else {
|
2022-06-20 20:51:56 +03:00
|
|
|
vq_supported = cpu->sve_vq.supported;
|
2019-10-31 17:27:33 +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
|
|
|
/*
|
|
|
|
* Process explicit sve<N> properties.
|
|
|
|
* From the properties, sve_vq_map<N> implies sve_vq_init<N>.
|
|
|
|
* Check first for any sve<N> enabled.
|
|
|
|
*/
|
2022-06-08 21:38:57 +03:00
|
|
|
if (vq_map != 0) {
|
|
|
|
max_vq = 32 - clz32(vq_map);
|
|
|
|
vq_mask = MAKE_64BIT_MASK(0, max_vq);
|
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 (cpu->sve_max_vq && max_vq > cpu->sve_max_vq) {
|
|
|
|
error_setg(errp, "cannot enable sve%d", max_vq * 128);
|
|
|
|
error_append_hint(errp, "sve%d is larger than the maximum vector "
|
|
|
|
"length, sve-max-vq=%d (%d bits)\n",
|
|
|
|
max_vq * 128, cpu->sve_max_vq,
|
|
|
|
cpu->sve_max_vq * 128);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-10-31 17:27:33 +03:00
|
|
|
if (kvm_enabled()) {
|
|
|
|
/*
|
2023-07-14 14:14:49 +03:00
|
|
|
* For KVM we have to automatically enable all supported uninitialized
|
2019-10-31 17:27:33 +03:00
|
|
|
* lengths, even when the smaller lengths are not all powers-of-two.
|
|
|
|
*/
|
2022-06-08 21:38:57 +03:00
|
|
|
vq_map |= vq_supported & ~vq_init & vq_mask;
|
2019-10-31 17:27:33 +03:00
|
|
|
} else {
|
|
|
|
/* Propagate enabled bits down through required powers-of-two. */
|
2022-06-08 21:38:57 +03:00
|
|
|
vq_map |= SVE_VQ_POW2_MAP & ~vq_init & vq_mask;
|
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 if (cpu->sve_max_vq == 0) {
|
|
|
|
/*
|
|
|
|
* No explicit bits enabled, and no implicit bits from sve-max-vq.
|
|
|
|
*/
|
|
|
|
if (!cpu_isar_feature(aa64_sve, cpu)) {
|
2024-05-26 23:45:51 +03:00
|
|
|
/*
|
|
|
|
* SVE is disabled and so are all vector lengths. Good.
|
|
|
|
* Disable all SVE extensions as well.
|
|
|
|
*/
|
|
|
|
cpu->isar.id_aa64zfr0 = 0;
|
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
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-10-31 17:27:33 +03:00
|
|
|
if (kvm_enabled()) {
|
|
|
|
/* Disabling a supported length disables all larger lengths. */
|
2022-06-08 21:38:57 +03:00
|
|
|
tmp = vq_init & vq_supported;
|
2019-10-31 17:27:33 +03:00
|
|
|
} else {
|
|
|
|
/* Disabling a power-of-two disables all larger lengths. */
|
2022-06-08 21:38:57 +03:00
|
|
|
tmp = vq_init & SVE_VQ_POW2_MAP;
|
2021-08-23 19:06:47 +03:00
|
|
|
}
|
2022-06-08 21:38:57 +03:00
|
|
|
vq = ctz32(tmp) + 1;
|
2021-08-23 19:06:47 +03:00
|
|
|
|
|
|
|
max_vq = vq <= ARM_MAX_VQ ? vq - 1 : ARM_MAX_VQ;
|
2023-07-04 18:43:32 +03:00
|
|
|
vq_mask = max_vq > 0 ? MAKE_64BIT_MASK(0, max_vq) : 0;
|
2022-06-08 21:38:57 +03:00
|
|
|
vq_map = vq_supported & ~vq_init & vq_mask;
|
|
|
|
|
2023-07-04 18:43:32 +03:00
|
|
|
if (vq_map == 0) {
|
2021-08-23 19:06:47 +03:00
|
|
|
error_setg(errp, "cannot disable sve%d", vq * 128);
|
|
|
|
error_append_hint(errp, "Disabling sve%d results in all "
|
|
|
|
"vector lengths being disabled.\n",
|
|
|
|
vq * 128);
|
|
|
|
error_append_hint(errp, "With SVE enabled, at least one "
|
|
|
|
"vector length must be enabled.\n");
|
|
|
|
return;
|
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
|
|
|
}
|
|
|
|
|
2022-06-08 21:38:57 +03:00
|
|
|
max_vq = 32 - clz32(vq_map);
|
|
|
|
vq_mask = MAKE_64BIT_MASK(0, max_vq);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Process the sve-max-vq property.
|
|
|
|
* Note that we know from the above that no bit above
|
|
|
|
* sve-max-vq is currently set.
|
|
|
|
*/
|
|
|
|
if (cpu->sve_max_vq != 0) {
|
|
|
|
max_vq = cpu->sve_max_vq;
|
2022-06-08 21:38:57 +03:00
|
|
|
vq_mask = MAKE_64BIT_MASK(0, max_vq);
|
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
|
|
|
|
2022-06-08 21:38:57 +03:00
|
|
|
if (vq_init & ~vq_map & (1 << (max_vq - 1))) {
|
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
|
|
|
error_setg(errp, "cannot disable sve%d", max_vq * 128);
|
|
|
|
error_append_hint(errp, "The maximum vector length must be "
|
|
|
|
"enabled, sve-max-vq=%d (%d bits)\n",
|
|
|
|
max_vq, max_vq * 128);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Set all bits not explicitly set within sve-max-vq. */
|
2022-06-08 21:38:57 +03:00
|
|
|
vq_map |= ~vq_init & vq_mask;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We should know what max-vq is now. Also, as we're done
|
|
|
|
* manipulating sve-vq-map, we ensure any bits above max-vq
|
|
|
|
* are clear, just in case anybody looks.
|
|
|
|
*/
|
|
|
|
assert(max_vq != 0);
|
2022-06-08 21:38:57 +03:00
|
|
|
assert(vq_mask != 0);
|
|
|
|
vq_map &= vq_mask;
|
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
|
|
|
|
2021-08-23 19:06:47 +03:00
|
|
|
/* Ensure the set of lengths matches what is supported. */
|
2022-06-08 21:38:57 +03:00
|
|
|
tmp = vq_map ^ (vq_supported & vq_mask);
|
|
|
|
if (tmp) {
|
|
|
|
vq = 32 - clz32(tmp);
|
|
|
|
if (vq_map & (1 << (vq - 1))) {
|
2021-08-23 19:06:47 +03:00
|
|
|
if (cpu->sve_max_vq) {
|
|
|
|
error_setg(errp, "cannot set sve-max-vq=%d", cpu->sve_max_vq);
|
|
|
|
error_append_hint(errp, "This CPU does not support "
|
|
|
|
"the vector length %d-bits.\n", vq * 128);
|
|
|
|
error_append_hint(errp, "It may not be possible to use "
|
|
|
|
"sve-max-vq with this CPU. Try "
|
|
|
|
"using only sve<N> properties.\n");
|
2019-10-31 17:27:33 +03:00
|
|
|
} else {
|
2021-08-23 19:06:47 +03:00
|
|
|
error_setg(errp, "cannot enable sve%d", vq * 128);
|
2022-06-20 20:51:55 +03:00
|
|
|
if (vq_supported) {
|
|
|
|
error_append_hint(errp, "This CPU does not support "
|
|
|
|
"the vector length %d-bits.\n", vq * 128);
|
|
|
|
} else {
|
|
|
|
error_append_hint(errp, "SVE not supported by KVM "
|
|
|
|
"on this host\n");
|
|
|
|
}
|
2021-08-23 19:06:47 +03:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
} else {
|
|
|
|
if (kvm_enabled()) {
|
2019-10-31 17:27:33 +03:00
|
|
|
error_setg(errp, "cannot disable sve%d", vq * 128);
|
|
|
|
error_append_hint(errp, "The KVM host requires all "
|
|
|
|
"supported vector lengths smaller "
|
|
|
|
"than %d bits to also be enabled.\n",
|
|
|
|
max_vq * 128);
|
|
|
|
return;
|
2021-08-23 19:06:47 +03:00
|
|
|
} else {
|
|
|
|
/* Ensure all required powers-of-two are enabled. */
|
2022-06-08 21:38:57 +03:00
|
|
|
tmp = SVE_VQ_POW2_MAP & vq_mask & ~vq_map;
|
|
|
|
if (tmp) {
|
|
|
|
vq = 32 - clz32(tmp);
|
|
|
|
error_setg(errp, "cannot disable sve%d", vq * 128);
|
|
|
|
error_append_hint(errp, "sve%d is required as it "
|
|
|
|
"is a power-of-two length smaller "
|
|
|
|
"than the maximum, sve%d\n",
|
|
|
|
vq * 128, max_vq * 128);
|
|
|
|
return;
|
2021-08-23 19:06:47 +03:00
|
|
|
}
|
2019-10-31 17:27:33 +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
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now that we validated all our vector lengths, the only question
|
|
|
|
* left to answer is if we even want SVE at all.
|
|
|
|
*/
|
|
|
|
if (!cpu_isar_feature(aa64_sve, cpu)) {
|
|
|
|
error_setg(errp, "cannot enable sve%d", max_vq * 128);
|
|
|
|
error_append_hint(errp, "SVE must be enabled to enable vector "
|
|
|
|
"lengths.\n");
|
|
|
|
error_append_hint(errp, "Add sve=on to the CPU property list.\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* From now on sve_max_vq is the actual maximum supported length. */
|
|
|
|
cpu->sve_max_vq = max_vq;
|
2022-06-20 20:51:56 +03:00
|
|
|
cpu->sve_vq.map = vq_map;
|
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
|
|
|
}
|
|
|
|
|
2021-01-12 02:57:40 +03:00
|
|
|
/*
|
2022-06-20 20:51:57 +03:00
|
|
|
* Note that cpu_arm_{get,set}_vq cannot use the simpler
|
|
|
|
* object_property_add_bool interface because they make use of the
|
|
|
|
* contents of "name" to determine which bit on which to operate.
|
2021-01-12 02:57:40 +03:00
|
|
|
*/
|
2022-06-20 20:51:57 +03:00
|
|
|
static void cpu_arm_get_vq(Object *obj, Visitor *v, const char *name,
|
|
|
|
void *opaque, Error **errp)
|
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
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
2022-06-20 20:51:57 +03:00
|
|
|
ARMVQMap *vq_map = opaque;
|
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
|
|
|
uint32_t vq = atoi(&name[3]) / 128;
|
2022-06-20 20:52:01 +03:00
|
|
|
bool sve = vq_map == &cpu->sve_vq;
|
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
|
|
|
bool value;
|
|
|
|
|
2022-06-20 20:52:01 +03:00
|
|
|
/* All vector lengths are disabled when feature is off. */
|
|
|
|
if (sve
|
|
|
|
? !cpu_isar_feature(aa64_sve, cpu)
|
|
|
|
: !cpu_isar_feature(aa64_sme, cpu)) {
|
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
|
|
|
value = false;
|
|
|
|
} else {
|
2022-06-20 20:51:57 +03:00
|
|
|
value = extract32(vq_map->map, vq - 1, 1);
|
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
|
|
|
}
|
|
|
|
visit_type_bool(v, name, &value, errp);
|
|
|
|
}
|
|
|
|
|
2022-06-20 20:51:57 +03:00
|
|
|
static void cpu_arm_set_vq(Object *obj, Visitor *v, const char *name,
|
|
|
|
void *opaque, Error **errp)
|
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
|
|
|
{
|
2022-06-20 20:51:57 +03:00
|
|
|
ARMVQMap *vq_map = opaque;
|
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
|
|
|
uint32_t vq = atoi(&name[3]) / 128;
|
|
|
|
bool value;
|
|
|
|
|
error: Eliminate error_propagate() with Coccinelle, part 1
When all we do with an Error we receive into a local variable is
propagating to somewhere else, we can just as well receive it there
right away. Convert
if (!foo(..., &err)) {
...
error_propagate(errp, err);
...
return ...
}
to
if (!foo(..., errp)) {
...
...
return ...
}
where nothing else needs @err. Coccinelle script:
@rule1 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
binary operator op;
constant c1, c2;
symbol false;
@@
if (
(
- fun(args, &err, args2)
+ fun(args, errp, args2)
|
- !fun(args, &err, args2)
+ !fun(args, errp, args2)
|
- fun(args, &err, args2) op c1
+ fun(args, errp, args2) op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
)
}
@rule2 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
expression var;
binary operator op;
constant c1, c2;
symbol false;
@@
- var = fun(args, &err, args2);
+ var = fun(args, errp, args2);
... when != err
if (
(
var
|
!var
|
var op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
|
return var;
)
}
@depends on rule1 || rule2@
identifier err;
@@
- Error *err = NULL;
... when != err
Not exactly elegant, I'm afraid.
The "when != lbl:" is necessary to avoid transforming
if (fun(args, &err)) {
goto out
}
...
out:
error_propagate(errp, err);
even though other paths to label out still need the error_propagate().
For an actual example, see sclp_realize().
Without the "when strict", Coccinelle transforms vfio_msix_setup(),
incorrectly. I don't know what exactly "when strict" does, only that
it helps here.
The match of return is narrower than what I want, but I can't figure
out how to express "return where the operand doesn't use @err". For
an example where it's too narrow, see vfio_intx_enable().
Silently fails to convert hw/arm/armsse.c, because Coccinelle gets
confused by ARMSSE being used both as typedef and function-like macro
there. Converted manually.
Line breaks tidied up manually. One nested declaration of @local_err
deleted manually. Preexisting unwanted blank line dropped in
hw/riscv/sifive_e.c.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-35-armbru@redhat.com>
2020-07-07 19:06:02 +03:00
|
|
|
if (!visit_type_bool(v, name, &value, errp)) {
|
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
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2022-06-20 20:51:57 +03:00
|
|
|
vq_map->map = deposit32(vq_map->map, vq - 1, 1, value);
|
|
|
|
vq_map->init |= 1 << (vq - 1);
|
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
|
|
|
}
|
|
|
|
|
2021-01-12 02:57:40 +03:00
|
|
|
static bool cpu_arm_get_sve(Object *obj, Error **errp)
|
2019-10-31 17:27:28 +03:00
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
2021-01-12 02:57:40 +03:00
|
|
|
return cpu_isar_feature(aa64_sve, cpu);
|
2019-10-31 17:27:28 +03:00
|
|
|
}
|
|
|
|
|
2021-01-12 02:57:40 +03:00
|
|
|
static void cpu_arm_set_sve(Object *obj, bool value, Error **errp)
|
2019-10-31 17:27:28 +03:00
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
uint64_t t;
|
|
|
|
|
target/arm: Check supported KVM features globally (not per vCPU)
Since commit d70c996df23f, when enabling the PMU we get:
$ qemu-system-aarch64 -cpu host,pmu=on -M virt,accel=kvm,gic-version=3
Segmentation fault (core dumped)
Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault.
0x0000aaaaaae356d0 in kvm_ioctl (s=0x0, type=44547) at accel/kvm/kvm-all.c:2588
2588 ret = ioctl(s->fd, type, arg);
(gdb) bt
#0 0x0000aaaaaae356d0 in kvm_ioctl (s=0x0, type=44547) at accel/kvm/kvm-all.c:2588
#1 0x0000aaaaaae31568 in kvm_check_extension (s=0x0, extension=126) at accel/kvm/kvm-all.c:916
#2 0x0000aaaaaafce254 in kvm_arm_pmu_supported (cpu=0xaaaaac214ab0) at target/arm/kvm.c:213
#3 0x0000aaaaaafc0f94 in arm_set_pmu (obj=0xaaaaac214ab0, value=true, errp=0xffffffffe438) at target/arm/cpu.c:1111
#4 0x0000aaaaab5533ac in property_set_bool (obj=0xaaaaac214ab0, v=0xaaaaac223a80, name=0xaaaaac11a970 "pmu", opaque=0xaaaaac222730, errp=0xffffffffe438) at qom/object.c:2170
#5 0x0000aaaaab5512f0 in object_property_set (obj=0xaaaaac214ab0, v=0xaaaaac223a80, name=0xaaaaac11a970 "pmu", errp=0xffffffffe438) at qom/object.c:1328
#6 0x0000aaaaab551e10 in object_property_parse (obj=0xaaaaac214ab0, string=0xaaaaac11b4c0 "on", name=0xaaaaac11a970 "pmu", errp=0xffffffffe438) at qom/object.c:1561
#7 0x0000aaaaab54ee8c in object_apply_global_props (obj=0xaaaaac214ab0, props=0xaaaaac018e20, errp=0xaaaaabd6fd88 <error_fatal>) at qom/object.c:407
#8 0x0000aaaaab1dd5a4 in qdev_prop_set_globals (dev=0xaaaaac214ab0) at hw/core/qdev-properties.c:1218
#9 0x0000aaaaab1d9fac in device_post_init (obj=0xaaaaac214ab0) at hw/core/qdev.c:1050
...
#15 0x0000aaaaab54f310 in object_initialize_with_type (obj=0xaaaaac214ab0, size=52208, type=0xaaaaabe237f0) at qom/object.c:512
#16 0x0000aaaaab54fa24 in object_new_with_type (type=0xaaaaabe237f0) at qom/object.c:687
#17 0x0000aaaaab54fa80 in object_new (typename=0xaaaaabe23970 "host-arm-cpu") at qom/object.c:702
#18 0x0000aaaaaaf04a74 in machvirt_init (machine=0xaaaaac0a8550) at hw/arm/virt.c:1770
#19 0x0000aaaaab1e8720 in machine_run_board_init (machine=0xaaaaac0a8550) at hw/core/machine.c:1138
#20 0x0000aaaaaaf95394 in qemu_init (argc=5, argv=0xffffffffea58, envp=0xffffffffea88) at softmmu/vl.c:4348
#21 0x0000aaaaaada3f74 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at softmmu/main.c:48
This is because in frame #2, cpu->kvm_state is still NULL
(the vCPU is not yet realized).
KVM has a hard requirement of all cores supporting the same
feature set. We only need to check if the accelerator supports
a feature, not each vCPU individually.
Fix by removing the 'CPUState *cpu' argument from the
kvm_arm_<FEATURE>_supported() functions.
Fixes: d70c996df23f ('Use CPUState::kvm_state in kvm_arm_pmu_supported')
Reported-by: Haibo Xu <haibo.xu@linaro.org>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-06-23 12:06:22 +03:00
|
|
|
if (value && kvm_enabled() && !kvm_arm_sve_supported()) {
|
2019-10-31 17:27:31 +03:00
|
|
|
error_setg(errp, "'sve' feature not supported by KVM on this host");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-10-31 17:27:28 +03:00
|
|
|
t = cpu->isar.id_aa64pfr0;
|
|
|
|
t = FIELD_DP64(t, ID_AA64PFR0, SVE, value);
|
|
|
|
cpu->isar.id_aa64pfr0 = t;
|
|
|
|
}
|
|
|
|
|
2022-06-20 20:52:01 +03:00
|
|
|
void arm_cpu_sme_finalize(ARMCPU *cpu, Error **errp)
|
|
|
|
{
|
|
|
|
uint32_t vq_map = cpu->sme_vq.map;
|
|
|
|
uint32_t vq_init = cpu->sme_vq.init;
|
|
|
|
uint32_t vq_supported = cpu->sme_vq.supported;
|
|
|
|
uint32_t vq;
|
|
|
|
|
|
|
|
if (vq_map == 0) {
|
|
|
|
if (!cpu_isar_feature(aa64_sme, cpu)) {
|
|
|
|
cpu->isar.id_aa64smfr0 = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* TODO: KVM will require limitations via SMCR_EL2. */
|
|
|
|
vq_map = vq_supported & ~vq_init;
|
|
|
|
|
|
|
|
if (vq_map == 0) {
|
|
|
|
vq = ctz32(vq_supported) + 1;
|
|
|
|
error_setg(errp, "cannot disable sme%d", vq * 128);
|
|
|
|
error_append_hint(errp, "All SME vector lengths are disabled.\n");
|
|
|
|
error_append_hint(errp, "With SME enabled, at least one "
|
|
|
|
"vector length must be enabled.\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (!cpu_isar_feature(aa64_sme, cpu)) {
|
|
|
|
vq = 32 - clz32(vq_map);
|
|
|
|
error_setg(errp, "cannot enable sme%d", vq * 128);
|
|
|
|
error_append_hint(errp, "SME must be enabled to enable "
|
|
|
|
"vector lengths.\n");
|
|
|
|
error_append_hint(errp, "Add sme=on to the CPU property list.\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/* TODO: KVM will require limitations via SMCR_EL2. */
|
|
|
|
}
|
|
|
|
|
|
|
|
cpu->sme_vq.map = vq_map;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool cpu_arm_get_sme(Object *obj, Error **errp)
|
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
return cpu_isar_feature(aa64_sme, cpu);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cpu_arm_set_sme(Object *obj, bool value, Error **errp)
|
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
uint64_t t;
|
|
|
|
|
|
|
|
t = cpu->isar.id_aa64pfr1;
|
|
|
|
t = FIELD_DP64(t, ID_AA64PFR1, SME, value);
|
|
|
|
cpu->isar.id_aa64pfr1 = t;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool cpu_arm_get_sme_fa64(Object *obj, Error **errp)
|
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
return cpu_isar_feature(aa64_sme, cpu) &&
|
|
|
|
cpu_isar_feature(aa64_sme_fa64, cpu);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cpu_arm_set_sme_fa64(Object *obj, bool value, Error **errp)
|
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
uint64_t t;
|
|
|
|
|
|
|
|
t = cpu->isar.id_aa64smfr0;
|
|
|
|
t = FIELD_DP64(t, ID_AA64SMFR0, FA64, value);
|
|
|
|
cpu->isar.id_aa64smfr0 = t;
|
|
|
|
}
|
|
|
|
|
2021-07-23 23:33:44 +03:00
|
|
|
#ifdef CONFIG_USER_ONLY
|
2022-06-20 20:52:01 +03:00
|
|
|
/* Mirror linux /proc/sys/abi/{sve,sme}_default_vector_length. */
|
2022-06-20 20:51:58 +03:00
|
|
|
static void cpu_arm_set_default_vec_len(Object *obj, Visitor *v,
|
|
|
|
const char *name, void *opaque,
|
|
|
|
Error **errp)
|
2021-07-23 23:33:44 +03:00
|
|
|
{
|
2022-06-20 20:51:58 +03:00
|
|
|
uint32_t *ptr_default_vq = opaque;
|
2021-07-23 23:33:44 +03:00
|
|
|
int32_t default_len, default_vq, remainder;
|
|
|
|
|
|
|
|
if (!visit_type_int32(v, name, &default_len, errp)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Undocumented, but the kernel allows -1 to indicate "maximum". */
|
|
|
|
if (default_len == -1) {
|
2022-06-20 20:51:58 +03:00
|
|
|
*ptr_default_vq = ARM_MAX_VQ;
|
2021-07-23 23:33:44 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
default_vq = default_len / 16;
|
|
|
|
remainder = default_len % 16;
|
|
|
|
|
|
|
|
/*
|
2022-08-12 20:41:56 +03:00
|
|
|
* Note that the 512 max comes from include/uapi/asm/sve_context.h
|
|
|
|
* and is the maximum architectural width of ZCR_ELx.LEN.
|
|
|
|
*/
|
|
|
|
if (remainder || default_vq < 1 || default_vq > 512) {
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
const char *which =
|
|
|
|
(ptr_default_vq == &cpu->sve_default_vq ? "sve" : "sme");
|
|
|
|
|
|
|
|
error_setg(errp, "cannot set %s-default-vector-length", which);
|
|
|
|
if (remainder) {
|
|
|
|
error_append_hint(errp, "Vector length not a multiple of 16\n");
|
|
|
|
} else if (default_vq < 1) {
|
|
|
|
error_append_hint(errp, "Vector length smaller than 16\n");
|
|
|
|
} else {
|
|
|
|
error_append_hint(errp, "Vector length larger than %d\n",
|
|
|
|
512 * 16);
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
*ptr_default_vq = default_vq;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cpu_arm_get_default_vec_len(Object *obj, Visitor *v,
|
|
|
|
const char *name, void *opaque,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
uint32_t *ptr_default_vq = opaque;
|
|
|
|
int32_t value = *ptr_default_vq * 16;
|
|
|
|
|
|
|
|
visit_type_int32(v, name, &value, errp);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2023-04-26 21:00:05 +03:00
|
|
|
void aarch64_add_sve_properties(Object *obj)
|
2022-08-12 20:41:56 +03:00
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
uint32_t vq;
|
|
|
|
|
|
|
|
object_property_add_bool(obj, "sve", cpu_arm_get_sve, cpu_arm_set_sve);
|
|
|
|
|
|
|
|
for (vq = 1; vq <= ARM_MAX_VQ; ++vq) {
|
|
|
|
char name[8];
|
2024-04-11 13:31:44 +03:00
|
|
|
snprintf(name, sizeof(name), "sve%d", vq * 128);
|
2022-08-12 20:41:56 +03:00
|
|
|
object_property_add(obj, name, "bool", cpu_arm_get_vq,
|
|
|
|
cpu_arm_set_vq, NULL, &cpu->sve_vq);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_USER_ONLY
|
|
|
|
/* Mirror linux /proc/sys/abi/sve_default_vector_length. */
|
|
|
|
object_property_add(obj, "sve-default-vector-length", "int32",
|
|
|
|
cpu_arm_get_default_vec_len,
|
|
|
|
cpu_arm_set_default_vec_len, NULL,
|
|
|
|
&cpu->sve_default_vq);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2023-04-26 21:00:05 +03:00
|
|
|
void aarch64_add_sme_properties(Object *obj)
|
2022-08-12 20:41:56 +03:00
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
uint32_t vq;
|
|
|
|
|
|
|
|
object_property_add_bool(obj, "sme", cpu_arm_get_sme, cpu_arm_set_sme);
|
|
|
|
object_property_add_bool(obj, "sme_fa64", cpu_arm_get_sme_fa64,
|
|
|
|
cpu_arm_set_sme_fa64);
|
|
|
|
|
|
|
|
for (vq = 1; vq <= ARM_MAX_VQ; vq <<= 1) {
|
|
|
|
char name[8];
|
2024-04-11 13:31:44 +03:00
|
|
|
snprintf(name, sizeof(name), "sme%d", vq * 128);
|
2022-08-12 20:41:56 +03:00
|
|
|
object_property_add(obj, name, "bool", cpu_arm_get_vq,
|
|
|
|
cpu_arm_set_vq, NULL, &cpu->sme_vq);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_USER_ONLY
|
|
|
|
/* Mirror linux /proc/sys/abi/sme_default_vector_length. */
|
|
|
|
object_property_add(obj, "sme-default-vector-length", "int32",
|
|
|
|
cpu_arm_get_default_vec_len,
|
|
|
|
cpu_arm_set_default_vec_len, NULL,
|
|
|
|
&cpu->sme_default_vq);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
void arm_cpu_pauth_finalize(ARMCPU *cpu, Error **errp)
|
|
|
|
{
|
2023-08-30 02:23:27 +03:00
|
|
|
ARMPauthFeature features = cpu_isar_feature(pauth_feature, cpu);
|
2023-08-30 02:23:28 +03:00
|
|
|
uint64_t isar1, isar2;
|
2022-08-12 20:41:56 +03:00
|
|
|
|
2023-08-30 02:23:27 +03:00
|
|
|
/*
|
|
|
|
* These properties enable or disable Pauth as a whole, or change
|
|
|
|
* the pauth algorithm, but do not change the set of features that
|
|
|
|
* are present. We have saved a copy of those features above and
|
|
|
|
* will now place it into the field that chooses the algorithm.
|
|
|
|
*
|
|
|
|
* Begin by disabling all fields.
|
|
|
|
*/
|
|
|
|
isar1 = cpu->isar.id_aa64isar1;
|
|
|
|
isar1 = FIELD_DP64(isar1, ID_AA64ISAR1, APA, 0);
|
|
|
|
isar1 = FIELD_DP64(isar1, ID_AA64ISAR1, GPA, 0);
|
|
|
|
isar1 = FIELD_DP64(isar1, ID_AA64ISAR1, API, 0);
|
|
|
|
isar1 = FIELD_DP64(isar1, ID_AA64ISAR1, GPI, 0);
|
2022-08-12 20:41:56 +03:00
|
|
|
|
2023-08-30 02:23:28 +03:00
|
|
|
isar2 = cpu->isar.id_aa64isar2;
|
|
|
|
isar2 = FIELD_DP64(isar2, ID_AA64ISAR2, APA3, 0);
|
|
|
|
isar2 = FIELD_DP64(isar2, ID_AA64ISAR2, GPA3, 0);
|
|
|
|
|
2023-08-30 02:23:27 +03:00
|
|
|
if (kvm_enabled() || hvf_enabled()) {
|
|
|
|
/*
|
|
|
|
* Exit early if PAuth is enabled and fall through to disable it.
|
|
|
|
* The algorithm selection properties are not present.
|
|
|
|
*/
|
|
|
|
if (cpu->prop_pauth) {
|
|
|
|
if (features == 0) {
|
|
|
|
error_setg(errp, "'pauth' feature not supported by "
|
|
|
|
"%s on this host", current_accel_name());
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* Pauth properties are only present when the model supports it. */
|
|
|
|
if (features == 0) {
|
|
|
|
assert(!cpu->prop_pauth);
|
|
|
|
return;
|
|
|
|
}
|
2022-08-12 20:41:56 +03:00
|
|
|
|
2023-08-30 02:23:27 +03:00
|
|
|
if (cpu->prop_pauth) {
|
2023-08-30 02:23:28 +03:00
|
|
|
if (cpu->prop_pauth_impdef && cpu->prop_pauth_qarma3) {
|
|
|
|
error_setg(errp,
|
|
|
|
"cannot enable both pauth-impdef and pauth-qarma3");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2023-08-30 02:23:27 +03:00
|
|
|
if (cpu->prop_pauth_impdef) {
|
|
|
|
isar1 = FIELD_DP64(isar1, ID_AA64ISAR1, API, features);
|
|
|
|
isar1 = FIELD_DP64(isar1, ID_AA64ISAR1, GPI, 1);
|
2023-08-30 02:23:28 +03:00
|
|
|
} else if (cpu->prop_pauth_qarma3) {
|
|
|
|
isar2 = FIELD_DP64(isar2, ID_AA64ISAR2, APA3, features);
|
|
|
|
isar2 = FIELD_DP64(isar2, ID_AA64ISAR2, GPA3, 1);
|
2023-08-30 02:23:27 +03:00
|
|
|
} else {
|
|
|
|
isar1 = FIELD_DP64(isar1, ID_AA64ISAR1, APA, features);
|
|
|
|
isar1 = FIELD_DP64(isar1, ID_AA64ISAR1, GPA, 1);
|
|
|
|
}
|
2023-08-30 02:23:28 +03:00
|
|
|
} else if (cpu->prop_pauth_impdef || cpu->prop_pauth_qarma3) {
|
|
|
|
error_setg(errp, "cannot enable pauth-impdef or "
|
|
|
|
"pauth-qarma3 without pauth");
|
2023-08-30 02:23:27 +03:00
|
|
|
error_append_hint(errp, "Add pauth=on to the CPU property list.\n");
|
2022-08-12 20:41:56 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-08-30 02:23:27 +03:00
|
|
|
cpu->isar.id_aa64isar1 = isar1;
|
2023-08-30 02:23:28 +03:00
|
|
|
cpu->isar.id_aa64isar2 = isar2;
|
2022-08-12 20:41:56 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static Property arm_cpu_pauth_property =
|
|
|
|
DEFINE_PROP_BOOL("pauth", ARMCPU, prop_pauth, true);
|
|
|
|
static Property arm_cpu_pauth_impdef_property =
|
|
|
|
DEFINE_PROP_BOOL("pauth-impdef", ARMCPU, prop_pauth_impdef, false);
|
2023-08-30 02:23:28 +03:00
|
|
|
static Property arm_cpu_pauth_qarma3_property =
|
|
|
|
DEFINE_PROP_BOOL("pauth-qarma3", ARMCPU, prop_pauth_qarma3, false);
|
2022-08-12 20:41:56 +03:00
|
|
|
|
2023-04-26 21:00:05 +03:00
|
|
|
void aarch64_add_pauth_properties(Object *obj)
|
2022-08-12 20:41:56 +03:00
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
|
|
|
|
/* Default to PAUTH on, with the architected algorithm on TCG. */
|
|
|
|
qdev_property_add_static(DEVICE(obj), &arm_cpu_pauth_property);
|
|
|
|
if (kvm_enabled() || hvf_enabled()) {
|
|
|
|
/*
|
|
|
|
* Mirror PAuth support from the probed sysregs back into the
|
|
|
|
* property for KVM or hvf. Is it just a bit backward? Yes it is!
|
|
|
|
* Note that prop_pauth is true whether the host CPU supports the
|
|
|
|
* architected QARMA5 algorithm or the IMPDEF one. We don't
|
|
|
|
* provide the separate pauth-impdef property for KVM or hvf,
|
|
|
|
* only for TCG.
|
|
|
|
*/
|
|
|
|
cpu->prop_pauth = cpu_isar_feature(aa64_pauth, cpu);
|
|
|
|
} else {
|
|
|
|
qdev_property_add_static(DEVICE(obj), &arm_cpu_pauth_impdef_property);
|
2023-08-30 02:23:28 +03:00
|
|
|
qdev_property_add_static(DEVICE(obj), &arm_cpu_pauth_qarma3_property);
|
2022-08-12 20:41:56 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void arm_cpu_lpa2_finalize(ARMCPU *cpu, Error **errp)
|
|
|
|
{
|
|
|
|
uint64_t t;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We only install the property for tcg -cpu max; this is the
|
|
|
|
* only situation in which the cpu field can be true.
|
2021-07-23 23:33:44 +03:00
|
|
|
*/
|
2022-08-12 20:41:56 +03:00
|
|
|
if (!cpu->prop_lpa2) {
|
2021-07-23 23:33:44 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2022-08-12 20:41:56 +03:00
|
|
|
t = cpu->isar.id_aa64mmfr0;
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR0, TGRAN16, 2); /* 16k pages w/ LPA2 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR0, TGRAN4, 1); /* 4k pages w/ LPA2 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR0, TGRAN16_2, 3); /* 16k stage2 w/ LPA2 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR0, TGRAN4_2, 3); /* 4k stage2 w/ LPA2 */
|
|
|
|
cpu->isar.id_aa64mmfr0 = t;
|
2021-07-23 23:33:44 +03:00
|
|
|
}
|
|
|
|
|
2022-08-12 20:41:56 +03:00
|
|
|
static void aarch64_a57_initfn(Object *obj)
|
2021-07-23 23:33:44 +03:00
|
|
|
{
|
2022-08-12 20:41:56 +03:00
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
2021-07-23 23:33:44 +03:00
|
|
|
|
2022-08-12 20:41:56 +03:00
|
|
|
cpu->dtb_compatible = "arm,cortex-a57";
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_V8);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_NEON);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
|
2024-04-26 15:29:13 +03:00
|
|
|
set_feature(&cpu->env, ARM_FEATURE_BACKCOMPAT_CNTFRQ);
|
2022-08-12 20:41:56 +03:00
|
|
|
set_feature(&cpu->env, ARM_FEATURE_AARCH64);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_CBAR_RO);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_EL2);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_EL3);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_PMU);
|
|
|
|
cpu->kvm_target = QEMU_KVM_ARM_TARGET_CORTEX_A57;
|
|
|
|
cpu->midr = 0x411fd070;
|
|
|
|
cpu->revidr = 0x00000000;
|
|
|
|
cpu->reset_fpsid = 0x41034070;
|
|
|
|
cpu->isar.mvfr0 = 0x10110222;
|
|
|
|
cpu->isar.mvfr1 = 0x12111111;
|
|
|
|
cpu->isar.mvfr2 = 0x00000043;
|
|
|
|
cpu->ctr = 0x8444c004;
|
|
|
|
cpu->reset_sctlr = 0x00c50838;
|
|
|
|
cpu->isar.id_pfr0 = 0x00000131;
|
|
|
|
cpu->isar.id_pfr1 = 0x00011011;
|
|
|
|
cpu->isar.id_dfr0 = 0x03010066;
|
|
|
|
cpu->id_afr0 = 0x00000000;
|
|
|
|
cpu->isar.id_mmfr0 = 0x10101105;
|
|
|
|
cpu->isar.id_mmfr1 = 0x40000000;
|
|
|
|
cpu->isar.id_mmfr2 = 0x01260000;
|
|
|
|
cpu->isar.id_mmfr3 = 0x02102211;
|
|
|
|
cpu->isar.id_isar0 = 0x02101110;
|
|
|
|
cpu->isar.id_isar1 = 0x13112111;
|
|
|
|
cpu->isar.id_isar2 = 0x21232042;
|
|
|
|
cpu->isar.id_isar3 = 0x01112131;
|
|
|
|
cpu->isar.id_isar4 = 0x00011142;
|
|
|
|
cpu->isar.id_isar5 = 0x00011121;
|
|
|
|
cpu->isar.id_isar6 = 0;
|
|
|
|
cpu->isar.id_aa64pfr0 = 0x00002222;
|
|
|
|
cpu->isar.id_aa64dfr0 = 0x10305106;
|
|
|
|
cpu->isar.id_aa64isar0 = 0x00011120;
|
|
|
|
cpu->isar.id_aa64mmfr0 = 0x00001124;
|
|
|
|
cpu->isar.dbgdidr = 0x3516d000;
|
|
|
|
cpu->isar.dbgdevid = 0x01110f13;
|
|
|
|
cpu->isar.dbgdevid1 = 0x2;
|
|
|
|
cpu->isar.reset_pmcr_el0 = 0x41013000;
|
|
|
|
cpu->clidr = 0x0a200023;
|
|
|
|
cpu->ccsidr[0] = 0x701fe00a; /* 32KB L1 dcache */
|
|
|
|
cpu->ccsidr[1] = 0x201fe012; /* 48KB L1 icache */
|
|
|
|
cpu->ccsidr[2] = 0x70ffe07a; /* 2048KB L2 cache */
|
|
|
|
cpu->dcz_blocksize = 4; /* 64 bytes */
|
|
|
|
cpu->gic_num_lrs = 4;
|
|
|
|
cpu->gic_vpribits = 5;
|
|
|
|
cpu->gic_vprebits = 5;
|
|
|
|
cpu->gic_pribits = 5;
|
|
|
|
define_cortex_a72_a57_a53_cp_reginfo(cpu);
|
2021-07-23 23:33:44 +03:00
|
|
|
}
|
|
|
|
|
2022-08-12 20:41:56 +03:00
|
|
|
static void aarch64_a53_initfn(Object *obj)
|
2019-10-31 17:27:34 +03:00
|
|
|
{
|
2022-06-20 20:51:57 +03:00
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
2019-10-31 17:27:34 +03:00
|
|
|
|
2022-08-12 20:41:56 +03:00
|
|
|
cpu->dtb_compatible = "arm,cortex-a53";
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_V8);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_NEON);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
|
2024-04-26 15:29:13 +03:00
|
|
|
set_feature(&cpu->env, ARM_FEATURE_BACKCOMPAT_CNTFRQ);
|
2022-08-12 20:41:56 +03:00
|
|
|
set_feature(&cpu->env, ARM_FEATURE_AARCH64);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_CBAR_RO);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_EL2);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_EL3);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_PMU);
|
|
|
|
cpu->kvm_target = QEMU_KVM_ARM_TARGET_CORTEX_A53;
|
|
|
|
cpu->midr = 0x410fd034;
|
2024-02-26 17:07:22 +03:00
|
|
|
cpu->revidr = 0x00000100;
|
2022-08-12 20:41:56 +03:00
|
|
|
cpu->reset_fpsid = 0x41034070;
|
|
|
|
cpu->isar.mvfr0 = 0x10110222;
|
|
|
|
cpu->isar.mvfr1 = 0x12111111;
|
|
|
|
cpu->isar.mvfr2 = 0x00000043;
|
|
|
|
cpu->ctr = 0x84448004; /* L1Ip = VIPT */
|
|
|
|
cpu->reset_sctlr = 0x00c50838;
|
|
|
|
cpu->isar.id_pfr0 = 0x00000131;
|
|
|
|
cpu->isar.id_pfr1 = 0x00011011;
|
|
|
|
cpu->isar.id_dfr0 = 0x03010066;
|
|
|
|
cpu->id_afr0 = 0x00000000;
|
|
|
|
cpu->isar.id_mmfr0 = 0x10101105;
|
|
|
|
cpu->isar.id_mmfr1 = 0x40000000;
|
|
|
|
cpu->isar.id_mmfr2 = 0x01260000;
|
|
|
|
cpu->isar.id_mmfr3 = 0x02102211;
|
|
|
|
cpu->isar.id_isar0 = 0x02101110;
|
|
|
|
cpu->isar.id_isar1 = 0x13112111;
|
|
|
|
cpu->isar.id_isar2 = 0x21232042;
|
|
|
|
cpu->isar.id_isar3 = 0x01112131;
|
|
|
|
cpu->isar.id_isar4 = 0x00011142;
|
|
|
|
cpu->isar.id_isar5 = 0x00011121;
|
|
|
|
cpu->isar.id_isar6 = 0;
|
|
|
|
cpu->isar.id_aa64pfr0 = 0x00002222;
|
|
|
|
cpu->isar.id_aa64dfr0 = 0x10305106;
|
|
|
|
cpu->isar.id_aa64isar0 = 0x00011120;
|
|
|
|
cpu->isar.id_aa64mmfr0 = 0x00001122; /* 40 bit physical addr */
|
|
|
|
cpu->isar.dbgdidr = 0x3516d000;
|
|
|
|
cpu->isar.dbgdevid = 0x00110f13;
|
|
|
|
cpu->isar.dbgdevid1 = 0x1;
|
|
|
|
cpu->isar.reset_pmcr_el0 = 0x41033000;
|
|
|
|
cpu->clidr = 0x0a200023;
|
|
|
|
cpu->ccsidr[0] = 0x700fe01a; /* 32KB L1 dcache */
|
|
|
|
cpu->ccsidr[1] = 0x201fe00a; /* 32KB L1 icache */
|
|
|
|
cpu->ccsidr[2] = 0x707fe07a; /* 1024KB L2 cache */
|
|
|
|
cpu->dcz_blocksize = 4; /* 64 bytes */
|
|
|
|
cpu->gic_num_lrs = 4;
|
|
|
|
cpu->gic_vpribits = 5;
|
|
|
|
cpu->gic_vprebits = 5;
|
|
|
|
cpu->gic_pribits = 5;
|
|
|
|
define_cortex_a72_a57_a53_cp_reginfo(cpu);
|
|
|
|
}
|
2019-10-31 17:27:34 +03:00
|
|
|
|
2022-02-04 19:55:02 +03:00
|
|
|
static void aarch64_host_initfn(Object *obj)
|
2022-02-04 19:55:01 +03:00
|
|
|
{
|
2022-02-04 19:55:03 +03:00
|
|
|
#if defined(CONFIG_KVM)
|
2022-02-04 19:55:01 +03:00
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
kvm_arm_set_cpu_features_from_host(cpu);
|
|
|
|
if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
|
|
|
|
aarch64_add_sve_properties(obj);
|
|
|
|
aarch64_add_pauth_properties(obj);
|
|
|
|
}
|
2022-02-04 19:55:03 +03:00
|
|
|
#elif defined(CONFIG_HVF)
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
2022-02-04 19:55:01 +03:00
|
|
|
hvf_arm_set_cpu_features_from_host(cpu);
|
2022-02-04 19:55:06 +03:00
|
|
|
aarch64_add_pauth_properties(obj);
|
2022-02-04 19:55:03 +03:00
|
|
|
#else
|
|
|
|
g_assert_not_reached();
|
2022-02-04 19:55:01 +03:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2023-04-26 21:00:03 +03:00
|
|
|
static void aarch64_max_initfn(Object *obj)
|
|
|
|
{
|
|
|
|
if (kvm_enabled() || hvf_enabled()) {
|
|
|
|
/* With KVM or HVF, '-cpu max' is identical to '-cpu host' */
|
|
|
|
aarch64_host_initfn(obj);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2023-04-26 21:00:04 +03:00
|
|
|
if (tcg_enabled() || qtest_enabled()) {
|
|
|
|
aarch64_a57_initfn(obj);
|
|
|
|
}
|
2023-04-26 21:00:03 +03:00
|
|
|
|
2023-04-26 21:00:04 +03:00
|
|
|
/* '-cpu max' for TCG: we currently do this as "A57 with extra things" */
|
|
|
|
if (tcg_enabled()) {
|
|
|
|
aarch64_max_tcg_initfn(obj);
|
|
|
|
}
|
2023-04-26 21:00:03 +03:00
|
|
|
}
|
|
|
|
|
2013-09-03 23:12:07 +04:00
|
|
|
static const ARMCPUInfo aarch64_cpus[] = {
|
2014-04-15 22:18:44 +04:00
|
|
|
{ .name = "cortex-a57", .initfn = aarch64_a57_initfn },
|
2015-05-15 05:22:55 +03:00
|
|
|
{ .name = "cortex-a53", .initfn = aarch64_a53_initfn },
|
2018-03-09 20:09:44 +03:00
|
|
|
{ .name = "max", .initfn = aarch64_max_initfn },
|
2022-02-04 19:55:02 +03:00
|
|
|
#if defined(CONFIG_KVM) || defined(CONFIG_HVF)
|
|
|
|
{ .name = "host", .initfn = aarch64_host_initfn },
|
|
|
|
#endif
|
2013-09-03 23:12:07 +04:00
|
|
|
};
|
|
|
|
|
2015-02-13 08:46:08 +03:00
|
|
|
static bool aarch64_cpu_get_aarch64(Object *obj, Error **errp)
|
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
|
|
|
|
return arm_feature(&cpu->env, ARM_FEATURE_AARCH64);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void aarch64_cpu_set_aarch64(Object *obj, bool value, Error **errp)
|
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
|
|
|
|
/* At this time, this property is only allowed if KVM is enabled. This
|
|
|
|
* restriction allows us to avoid fixing up functionality that assumes a
|
|
|
|
* uniform execution state like do_interrupt.
|
|
|
|
*/
|
|
|
|
if (value == false) {
|
target/arm: Check supported KVM features globally (not per vCPU)
Since commit d70c996df23f, when enabling the PMU we get:
$ qemu-system-aarch64 -cpu host,pmu=on -M virt,accel=kvm,gic-version=3
Segmentation fault (core dumped)
Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault.
0x0000aaaaaae356d0 in kvm_ioctl (s=0x0, type=44547) at accel/kvm/kvm-all.c:2588
2588 ret = ioctl(s->fd, type, arg);
(gdb) bt
#0 0x0000aaaaaae356d0 in kvm_ioctl (s=0x0, type=44547) at accel/kvm/kvm-all.c:2588
#1 0x0000aaaaaae31568 in kvm_check_extension (s=0x0, extension=126) at accel/kvm/kvm-all.c:916
#2 0x0000aaaaaafce254 in kvm_arm_pmu_supported (cpu=0xaaaaac214ab0) at target/arm/kvm.c:213
#3 0x0000aaaaaafc0f94 in arm_set_pmu (obj=0xaaaaac214ab0, value=true, errp=0xffffffffe438) at target/arm/cpu.c:1111
#4 0x0000aaaaab5533ac in property_set_bool (obj=0xaaaaac214ab0, v=0xaaaaac223a80, name=0xaaaaac11a970 "pmu", opaque=0xaaaaac222730, errp=0xffffffffe438) at qom/object.c:2170
#5 0x0000aaaaab5512f0 in object_property_set (obj=0xaaaaac214ab0, v=0xaaaaac223a80, name=0xaaaaac11a970 "pmu", errp=0xffffffffe438) at qom/object.c:1328
#6 0x0000aaaaab551e10 in object_property_parse (obj=0xaaaaac214ab0, string=0xaaaaac11b4c0 "on", name=0xaaaaac11a970 "pmu", errp=0xffffffffe438) at qom/object.c:1561
#7 0x0000aaaaab54ee8c in object_apply_global_props (obj=0xaaaaac214ab0, props=0xaaaaac018e20, errp=0xaaaaabd6fd88 <error_fatal>) at qom/object.c:407
#8 0x0000aaaaab1dd5a4 in qdev_prop_set_globals (dev=0xaaaaac214ab0) at hw/core/qdev-properties.c:1218
#9 0x0000aaaaab1d9fac in device_post_init (obj=0xaaaaac214ab0) at hw/core/qdev.c:1050
...
#15 0x0000aaaaab54f310 in object_initialize_with_type (obj=0xaaaaac214ab0, size=52208, type=0xaaaaabe237f0) at qom/object.c:512
#16 0x0000aaaaab54fa24 in object_new_with_type (type=0xaaaaabe237f0) at qom/object.c:687
#17 0x0000aaaaab54fa80 in object_new (typename=0xaaaaabe23970 "host-arm-cpu") at qom/object.c:702
#18 0x0000aaaaaaf04a74 in machvirt_init (machine=0xaaaaac0a8550) at hw/arm/virt.c:1770
#19 0x0000aaaaab1e8720 in machine_run_board_init (machine=0xaaaaac0a8550) at hw/core/machine.c:1138
#20 0x0000aaaaaaf95394 in qemu_init (argc=5, argv=0xffffffffea58, envp=0xffffffffea88) at softmmu/vl.c:4348
#21 0x0000aaaaaada3f74 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at softmmu/main.c:48
This is because in frame #2, cpu->kvm_state is still NULL
(the vCPU is not yet realized).
KVM has a hard requirement of all cores supporting the same
feature set. We only need to check if the accelerator supports
a feature, not each vCPU individually.
Fix by removing the 'CPUState *cpu' argument from the
kvm_arm_<FEATURE>_supported() functions.
Fixes: d70c996df23f ('Use CPUState::kvm_state in kvm_arm_pmu_supported')
Reported-by: Haibo Xu <haibo.xu@linaro.org>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-06-23 12:06:22 +03:00
|
|
|
if (!kvm_enabled() || !kvm_arm_aarch32_supported()) {
|
2019-08-02 15:25:26 +03:00
|
|
|
error_setg(errp, "'aarch64' feature cannot be disabled "
|
|
|
|
"unless KVM is enabled and 32-bit EL1 "
|
|
|
|
"is supported");
|
|
|
|
return;
|
|
|
|
}
|
2015-02-13 08:46:08 +03:00
|
|
|
unset_feature(&cpu->env, ARM_FEATURE_AARCH64);
|
|
|
|
} else {
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_AARCH64);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-03 23:12:07 +04:00
|
|
|
static void aarch64_cpu_finalizefn(Object *obj)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2023-10-09 19:40:53 +03:00
|
|
|
static const gchar *aarch64_gdb_arch_name(CPUState *cs)
|
2015-12-03 15:14:41 +03:00
|
|
|
{
|
2023-10-09 19:40:53 +03:00
|
|
|
return "aarch64";
|
2015-12-03 15:14:41 +03:00
|
|
|
}
|
|
|
|
|
2013-09-03 23:12:07 +04:00
|
|
|
static void aarch64_cpu_class_init(ObjectClass *oc, void *data)
|
|
|
|
{
|
2013-09-03 23:12:10 +04:00
|
|
|
CPUClass *cc = CPU_CLASS(oc);
|
|
|
|
|
2013-09-03 23:12:11 +04:00
|
|
|
cc->gdb_read_register = aarch64_cpu_gdb_read_register;
|
|
|
|
cc->gdb_write_register = aarch64_cpu_gdb_write_register;
|
|
|
|
cc->gdb_core_xml_file = "aarch64-core.xml";
|
2015-12-03 15:14:41 +03:00
|
|
|
cc->gdb_arch_name = aarch64_gdb_arch_name;
|
2020-11-11 21:38:18 +03:00
|
|
|
|
|
|
|
object_class_property_add_bool(oc, "aarch64", aarch64_cpu_get_aarch64,
|
|
|
|
aarch64_cpu_set_aarch64);
|
|
|
|
object_class_property_set_description(oc, "aarch64",
|
|
|
|
"Set on/off to enable/disable aarch64 "
|
|
|
|
"execution state ");
|
2013-09-03 23:12:07 +04:00
|
|
|
}
|
|
|
|
|
2018-11-27 11:55:59 +03:00
|
|
|
static void aarch64_cpu_instance_init(Object *obj)
|
|
|
|
{
|
|
|
|
ARMCPUClass *acc = ARM_CPU_GET_CLASS(obj);
|
|
|
|
|
|
|
|
acc->info->initfn(obj);
|
|
|
|
arm_cpu_post_init(obj);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cpu_register_class_init(ObjectClass *oc, void *data)
|
|
|
|
{
|
|
|
|
ARMCPUClass *acc = ARM_CPU_CLASS(oc);
|
|
|
|
|
|
|
|
acc->info = data;
|
|
|
|
}
|
|
|
|
|
2020-04-23 10:33:55 +03:00
|
|
|
void aarch64_cpu_register(const ARMCPUInfo *info)
|
2013-09-03 23:12:07 +04:00
|
|
|
{
|
|
|
|
TypeInfo type_info = {
|
|
|
|
.parent = TYPE_AARCH64_CPU,
|
2018-11-27 11:55:59 +03:00
|
|
|
.instance_init = aarch64_cpu_instance_init,
|
|
|
|
.class_init = info->class_init ?: cpu_register_class_init,
|
|
|
|
.class_data = (void *)info,
|
2013-09-03 23:12:07 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
type_info.name = g_strdup_printf("%s-" TYPE_ARM_CPU, info->name);
|
|
|
|
type_register(&type_info);
|
|
|
|
g_free((void *)type_info.name);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const TypeInfo aarch64_cpu_type_info = {
|
|
|
|
.name = TYPE_AARCH64_CPU,
|
|
|
|
.parent = TYPE_ARM_CPU,
|
|
|
|
.instance_finalize = aarch64_cpu_finalizefn,
|
|
|
|
.abstract = true,
|
|
|
|
.class_init = aarch64_cpu_class_init,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void aarch64_cpu_register_types(void)
|
|
|
|
{
|
2020-05-04 20:24:46 +03:00
|
|
|
size_t i;
|
2013-09-03 23:12:07 +04:00
|
|
|
|
|
|
|
type_register_static(&aarch64_cpu_type_info);
|
2014-01-13 14:26:16 +04:00
|
|
|
|
2020-05-04 20:24:46 +03:00
|
|
|
for (i = 0; i < ARRAY_SIZE(aarch64_cpus); ++i) {
|
|
|
|
aarch64_cpu_register(&aarch64_cpus[i]);
|
2013-09-03 23:12:07 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
type_init(aarch64_cpu_register_types)
|