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"
|
2021-02-04 19:39:23 +03:00
|
|
|
#ifdef CONFIG_TCG
|
|
|
|
#include "hw/core/tcg-cpu-ops.h"
|
|
|
|
#endif /* CONFIG_TCG */
|
2019-05-23 17:35:07 +03:00
|
|
|
#include "qemu/module.h"
|
2013-09-03 23:12:07 +04:00
|
|
|
#if !defined(CONFIG_USER_ONLY)
|
|
|
|
#include "hw/loader.h"
|
|
|
|
#endif
|
|
|
|
#include "sysemu/kvm.h"
|
2022-02-04 19:55:05 +03:00
|
|
|
#include "sysemu/hvf.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"
|
2021-01-12 02:57:39 +03:00
|
|
|
|
2013-09-03 23:12:07 +04:00
|
|
|
|
2014-04-15 22:18:44 +04:00
|
|
|
static void aarch64_a57_initfn(Object *obj)
|
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
|
2015-03-11 16:21:06 +03:00
|
|
|
cpu->dtb_compatible = "arm,cortex-a57";
|
2014-04-15 22:18:44 +04:00
|
|
|
set_feature(&cpu->env, ARM_FEATURE_V8);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_NEON);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_AARCH64);
|
2014-04-15 22:18:49 +04:00
|
|
|
set_feature(&cpu->env, ARM_FEATURE_CBAR_RO);
|
2017-01-20 14:15:10 +03:00
|
|
|
set_feature(&cpu->env, ARM_FEATURE_EL2);
|
2016-02-11 14:17:31 +03:00
|
|
|
set_feature(&cpu->env, ARM_FEATURE_EL3);
|
2016-10-28 16:12:31 +03:00
|
|
|
set_feature(&cpu->env, ARM_FEATURE_PMU);
|
2014-04-15 22:18:44 +04:00
|
|
|
cpu->kvm_target = QEMU_KVM_ARM_TARGET_CORTEX_A57;
|
|
|
|
cpu->midr = 0x411fd070;
|
2015-06-15 20:06:08 +03:00
|
|
|
cpu->revidr = 0x00000000;
|
2014-04-15 22:18:44 +04:00
|
|
|
cpu->reset_fpsid = 0x41034070;
|
2018-10-24 09:50:16 +03:00
|
|
|
cpu->isar.mvfr0 = 0x10110222;
|
|
|
|
cpu->isar.mvfr1 = 0x12111111;
|
|
|
|
cpu->isar.mvfr2 = 0x00000043;
|
2014-04-15 22:18:44 +04:00
|
|
|
cpu->ctr = 0x8444c004;
|
|
|
|
cpu->reset_sctlr = 0x00c50838;
|
2020-09-10 20:38:52 +03:00
|
|
|
cpu->isar.id_pfr0 = 0x00000131;
|
|
|
|
cpu->isar.id_pfr1 = 0x00011011;
|
2020-02-14 20:51:03 +03:00
|
|
|
cpu->isar.id_dfr0 = 0x03010066;
|
2014-04-15 22:18:44 +04:00
|
|
|
cpu->id_afr0 = 0x00000000;
|
2020-02-14 20:51:13 +03:00
|
|
|
cpu->isar.id_mmfr0 = 0x10101105;
|
|
|
|
cpu->isar.id_mmfr1 = 0x40000000;
|
|
|
|
cpu->isar.id_mmfr2 = 0x01260000;
|
|
|
|
cpu->isar.id_mmfr3 = 0x02102211;
|
2018-10-24 09:50:16 +03:00
|
|
|
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;
|
2020-02-14 20:51:04 +03:00
|
|
|
cpu->isar.id_aa64dfr0 = 0x10305106;
|
2018-10-24 09:50:16 +03:00
|
|
|
cpu->isar.id_aa64isar0 = 0x00011120;
|
2018-12-13 17:40:56 +03:00
|
|
|
cpu->isar.id_aa64mmfr0 = 0x00001124;
|
2020-02-14 20:51:06 +03:00
|
|
|
cpu->isar.dbgdidr = 0x3516d000;
|
target/arm: Implement AArch32 DBGDEVID, DBGDEVID1, DBGDEVID2
Starting with v7 of the debug architecture, there are three extra
ID registers that add information on top of that provided in
DBGDIDR. These are DBGDEVID, DBGDEVID1 and DBGDEVID2. In the
v7 debug architecture, DBGDEVID is optional, present only of
DBGDIDR.DEVID_imp is set. In v7.1 all three must be present.
Implement the missing registers. Note that we only need to set the
values in the ARMISARegisters struct for the CPUs Cortex-A7, A15,
A53, A57 and A72 (plus the 32-bit 'max' which uses the Cortex-A53
values): earlier CPUs didn't implement v7 of the architecture, and
our other 64-bit CPUs (Cortex-A76, Neoverse-N1 and A64fx) don't have
AArch32 support at EL1.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220630194116.3438513-5-peter.maydell@linaro.org
2022-06-30 22:41:15 +03:00
|
|
|
cpu->isar.dbgdevid = 0x01110f13;
|
|
|
|
cpu->isar.dbgdevid1 = 0x2;
|
target/arm: Make number of counters in PMCR follow the CPU
Currently we give all the v7-and-up CPUs a PMU with 4 counters. This
means that we don't provide the 6 counters that are required by the
Arm BSA (Base System Architecture) specification if the CPU supports
the Virtualization extensions.
Instead of having a single PMCR_NUM_COUNTERS, make each CPU type
specify the PMCR reset value (obtained from the appropriate TRM), and
use the 'N' field of that value to define the number of counters
provided.
This means that we now supply 6 counters instead of 4 for:
Cortex-A9, Cortex-A15, Cortex-A53, Cortex-A57, Cortex-A72,
Cortex-A76, Neoverse-N1, '-cpu max'
This CPU goes from 4 to 8 counters:
A64FX
These CPUs remain with 4 counters:
Cortex-A7, Cortex-A8
This CPU goes down from 4 to 3 counters:
Cortex-R5
Note that because we now use the PMCR reset value of the specific
implementation, we no longer set the LC bit out of reset. This has
an UNKNOWN value out of reset for all cores with any AArch32 support,
so guest software should be setting it anyway if it wants it.
This change was originally landed in commit f7fb73b8cdd3f7 (during
the 6.0 release cycle) but was then reverted by commit
21c2dd77a6aa517 before that release because it did not work with KVM.
This version fixes that by creating the scratch vCPU in
kvm_arm_get_host_cpu_features() with the KVM_ARM_VCPU_PMU_V3 feature
if KVM supports it, and then only asking KVM for the PMCR_EL0 value
if the vCPU has a PMU.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
[PMM: Added the correct value for a64fx]
Message-id: 20220513122852.4063586-1-peter.maydell@linaro.org
2022-05-13 15:28:52 +03:00
|
|
|
cpu->isar.reset_pmcr_el0 = 0x41013000;
|
2014-04-15 22:18:44 +04:00
|
|
|
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 */
|
2017-01-20 14:15:09 +03:00
|
|
|
cpu->gic_num_lrs = 4;
|
|
|
|
cpu->gic_vpribits = 5;
|
|
|
|
cpu->gic_vprebits = 5;
|
2022-05-12 18:14:56 +03:00
|
|
|
cpu->gic_pribits = 5;
|
2022-05-06 21:02:23 +03:00
|
|
|
define_cortex_a72_a57_a53_cp_reginfo(cpu);
|
2014-04-15 22:18:44 +04:00
|
|
|
}
|
|
|
|
|
2015-05-15 05:22:55 +03:00
|
|
|
static void aarch64_a53_initfn(Object *obj)
|
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
|
|
|
|
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);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_AARCH64);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_CBAR_RO);
|
2017-01-20 14:15:10 +03:00
|
|
|
set_feature(&cpu->env, ARM_FEATURE_EL2);
|
2016-02-11 14:17:31 +03:00
|
|
|
set_feature(&cpu->env, ARM_FEATURE_EL3);
|
2016-10-28 16:12:31 +03:00
|
|
|
set_feature(&cpu->env, ARM_FEATURE_PMU);
|
2015-06-15 20:06:08 +03:00
|
|
|
cpu->kvm_target = QEMU_KVM_ARM_TARGET_CORTEX_A53;
|
2015-05-15 05:22:55 +03:00
|
|
|
cpu->midr = 0x410fd034;
|
2015-06-15 20:06:08 +03:00
|
|
|
cpu->revidr = 0x00000000;
|
2015-05-15 05:22:55 +03:00
|
|
|
cpu->reset_fpsid = 0x41034070;
|
2018-10-24 09:50:16 +03:00
|
|
|
cpu->isar.mvfr0 = 0x10110222;
|
|
|
|
cpu->isar.mvfr1 = 0x12111111;
|
|
|
|
cpu->isar.mvfr2 = 0x00000043;
|
2015-05-15 05:22:55 +03:00
|
|
|
cpu->ctr = 0x84448004; /* L1Ip = VIPT */
|
|
|
|
cpu->reset_sctlr = 0x00c50838;
|
2020-09-10 20:38:52 +03:00
|
|
|
cpu->isar.id_pfr0 = 0x00000131;
|
|
|
|
cpu->isar.id_pfr1 = 0x00011011;
|
2020-02-14 20:51:03 +03:00
|
|
|
cpu->isar.id_dfr0 = 0x03010066;
|
2015-05-15 05:22:55 +03:00
|
|
|
cpu->id_afr0 = 0x00000000;
|
2020-02-14 20:51:13 +03:00
|
|
|
cpu->isar.id_mmfr0 = 0x10101105;
|
|
|
|
cpu->isar.id_mmfr1 = 0x40000000;
|
|
|
|
cpu->isar.id_mmfr2 = 0x01260000;
|
|
|
|
cpu->isar.id_mmfr3 = 0x02102211;
|
2018-10-24 09:50:16 +03:00
|
|
|
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;
|
2020-02-14 20:51:04 +03:00
|
|
|
cpu->isar.id_aa64dfr0 = 0x10305106;
|
2018-10-24 09:50:16 +03:00
|
|
|
cpu->isar.id_aa64isar0 = 0x00011120;
|
2018-12-13 17:40:56 +03:00
|
|
|
cpu->isar.id_aa64mmfr0 = 0x00001122; /* 40 bit physical addr */
|
2020-02-14 20:51:06 +03:00
|
|
|
cpu->isar.dbgdidr = 0x3516d000;
|
target/arm: Implement AArch32 DBGDEVID, DBGDEVID1, DBGDEVID2
Starting with v7 of the debug architecture, there are three extra
ID registers that add information on top of that provided in
DBGDIDR. These are DBGDEVID, DBGDEVID1 and DBGDEVID2. In the
v7 debug architecture, DBGDEVID is optional, present only of
DBGDIDR.DEVID_imp is set. In v7.1 all three must be present.
Implement the missing registers. Note that we only need to set the
values in the ARMISARegisters struct for the CPUs Cortex-A7, A15,
A53, A57 and A72 (plus the 32-bit 'max' which uses the Cortex-A53
values): earlier CPUs didn't implement v7 of the architecture, and
our other 64-bit CPUs (Cortex-A76, Neoverse-N1 and A64fx) don't have
AArch32 support at EL1.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220630194116.3438513-5-peter.maydell@linaro.org
2022-06-30 22:41:15 +03:00
|
|
|
cpu->isar.dbgdevid = 0x00110f13;
|
|
|
|
cpu->isar.dbgdevid1 = 0x1;
|
target/arm: Make number of counters in PMCR follow the CPU
Currently we give all the v7-and-up CPUs a PMU with 4 counters. This
means that we don't provide the 6 counters that are required by the
Arm BSA (Base System Architecture) specification if the CPU supports
the Virtualization extensions.
Instead of having a single PMCR_NUM_COUNTERS, make each CPU type
specify the PMCR reset value (obtained from the appropriate TRM), and
use the 'N' field of that value to define the number of counters
provided.
This means that we now supply 6 counters instead of 4 for:
Cortex-A9, Cortex-A15, Cortex-A53, Cortex-A57, Cortex-A72,
Cortex-A76, Neoverse-N1, '-cpu max'
This CPU goes from 4 to 8 counters:
A64FX
These CPUs remain with 4 counters:
Cortex-A7, Cortex-A8
This CPU goes down from 4 to 3 counters:
Cortex-R5
Note that because we now use the PMCR reset value of the specific
implementation, we no longer set the LC bit out of reset. This has
an UNKNOWN value out of reset for all cores with any AArch32 support,
so guest software should be setting it anyway if it wants it.
This change was originally landed in commit f7fb73b8cdd3f7 (during
the 6.0 release cycle) but was then reverted by commit
21c2dd77a6aa517 before that release because it did not work with KVM.
This version fixes that by creating the scratch vCPU in
kvm_arm_get_host_cpu_features() with the KVM_ARM_VCPU_PMU_V3 feature
if KVM supports it, and then only asking KVM for the PMCR_EL0 value
if the vCPU has a PMU.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
[PMM: Added the correct value for a64fx]
Message-id: 20220513122852.4063586-1-peter.maydell@linaro.org
2022-05-13 15:28:52 +03:00
|
|
|
cpu->isar.reset_pmcr_el0 = 0x41033000;
|
2015-05-15 05:22:55 +03:00
|
|
|
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 */
|
2017-01-20 14:15:09 +03:00
|
|
|
cpu->gic_num_lrs = 4;
|
|
|
|
cpu->gic_vpribits = 5;
|
|
|
|
cpu->gic_vprebits = 5;
|
2022-05-12 18:14:56 +03:00
|
|
|
cpu->gic_pribits = 5;
|
2022-05-06 21:02:23 +03:00
|
|
|
define_cortex_a72_a57_a53_cp_reginfo(cpu);
|
2018-10-11 05:19:29 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void aarch64_a72_initfn(Object *obj)
|
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
|
|
|
|
cpu->dtb_compatible = "arm,cortex-a72";
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_V8);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_NEON);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
|
|
|
|
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->midr = 0x410fd083;
|
|
|
|
cpu->revidr = 0x00000000;
|
|
|
|
cpu->reset_fpsid = 0x41034080;
|
2018-10-24 09:50:16 +03:00
|
|
|
cpu->isar.mvfr0 = 0x10110222;
|
|
|
|
cpu->isar.mvfr1 = 0x12111111;
|
|
|
|
cpu->isar.mvfr2 = 0x00000043;
|
2018-10-11 05:19:29 +03:00
|
|
|
cpu->ctr = 0x8444c004;
|
|
|
|
cpu->reset_sctlr = 0x00c50838;
|
2020-09-10 20:38:52 +03:00
|
|
|
cpu->isar.id_pfr0 = 0x00000131;
|
|
|
|
cpu->isar.id_pfr1 = 0x00011011;
|
2020-02-14 20:51:03 +03:00
|
|
|
cpu->isar.id_dfr0 = 0x03010066;
|
2018-10-11 05:19:29 +03:00
|
|
|
cpu->id_afr0 = 0x00000000;
|
2020-02-14 20:51:13 +03:00
|
|
|
cpu->isar.id_mmfr0 = 0x10201105;
|
|
|
|
cpu->isar.id_mmfr1 = 0x40000000;
|
|
|
|
cpu->isar.id_mmfr2 = 0x01260000;
|
|
|
|
cpu->isar.id_mmfr3 = 0x02102211;
|
2018-10-24 09:50:16 +03:00
|
|
|
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_aa64pfr0 = 0x00002222;
|
2020-02-14 20:51:04 +03:00
|
|
|
cpu->isar.id_aa64dfr0 = 0x10305106;
|
2018-10-24 09:50:16 +03:00
|
|
|
cpu->isar.id_aa64isar0 = 0x00011120;
|
2018-12-13 17:40:56 +03:00
|
|
|
cpu->isar.id_aa64mmfr0 = 0x00001124;
|
2020-02-14 20:51:06 +03:00
|
|
|
cpu->isar.dbgdidr = 0x3516d000;
|
target/arm: Implement AArch32 DBGDEVID, DBGDEVID1, DBGDEVID2
Starting with v7 of the debug architecture, there are three extra
ID registers that add information on top of that provided in
DBGDIDR. These are DBGDEVID, DBGDEVID1 and DBGDEVID2. In the
v7 debug architecture, DBGDEVID is optional, present only of
DBGDIDR.DEVID_imp is set. In v7.1 all three must be present.
Implement the missing registers. Note that we only need to set the
values in the ARMISARegisters struct for the CPUs Cortex-A7, A15,
A53, A57 and A72 (plus the 32-bit 'max' which uses the Cortex-A53
values): earlier CPUs didn't implement v7 of the architecture, and
our other 64-bit CPUs (Cortex-A76, Neoverse-N1 and A64fx) don't have
AArch32 support at EL1.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220630194116.3438513-5-peter.maydell@linaro.org
2022-06-30 22:41:15 +03:00
|
|
|
cpu->isar.dbgdevid = 0x01110f13;
|
|
|
|
cpu->isar.dbgdevid1 = 0x2;
|
target/arm: Make number of counters in PMCR follow the CPU
Currently we give all the v7-and-up CPUs a PMU with 4 counters. This
means that we don't provide the 6 counters that are required by the
Arm BSA (Base System Architecture) specification if the CPU supports
the Virtualization extensions.
Instead of having a single PMCR_NUM_COUNTERS, make each CPU type
specify the PMCR reset value (obtained from the appropriate TRM), and
use the 'N' field of that value to define the number of counters
provided.
This means that we now supply 6 counters instead of 4 for:
Cortex-A9, Cortex-A15, Cortex-A53, Cortex-A57, Cortex-A72,
Cortex-A76, Neoverse-N1, '-cpu max'
This CPU goes from 4 to 8 counters:
A64FX
These CPUs remain with 4 counters:
Cortex-A7, Cortex-A8
This CPU goes down from 4 to 3 counters:
Cortex-R5
Note that because we now use the PMCR reset value of the specific
implementation, we no longer set the LC bit out of reset. This has
an UNKNOWN value out of reset for all cores with any AArch32 support,
so guest software should be setting it anyway if it wants it.
This change was originally landed in commit f7fb73b8cdd3f7 (during
the 6.0 release cycle) but was then reverted by commit
21c2dd77a6aa517 before that release because it did not work with KVM.
This version fixes that by creating the scratch vCPU in
kvm_arm_get_host_cpu_features() with the KVM_ARM_VCPU_PMU_V3 feature
if KVM supports it, and then only asking KVM for the PMCR_EL0 value
if the vCPU has a PMU.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
[PMM: Added the correct value for a64fx]
Message-id: 20220513122852.4063586-1-peter.maydell@linaro.org
2022-05-13 15:28:52 +03:00
|
|
|
cpu->isar.reset_pmcr_el0 = 0x41023000;
|
2018-10-11 05:19:29 +03:00
|
|
|
cpu->clidr = 0x0a200023;
|
|
|
|
cpu->ccsidr[0] = 0x701fe00a; /* 32KB L1 dcache */
|
|
|
|
cpu->ccsidr[1] = 0x201fe012; /* 48KB L1 icache */
|
|
|
|
cpu->ccsidr[2] = 0x707fe07a; /* 1MB L2 cache */
|
|
|
|
cpu->dcz_blocksize = 4; /* 64 bytes */
|
|
|
|
cpu->gic_num_lrs = 4;
|
|
|
|
cpu->gic_vpribits = 5;
|
|
|
|
cpu->gic_vprebits = 5;
|
2022-05-12 18:14:56 +03:00
|
|
|
cpu->gic_pribits = 5;
|
2022-05-06 21:02:23 +03:00
|
|
|
define_cortex_a72_a57_a53_cp_reginfo(cpu);
|
2015-05-15 05:22:55 +03:00
|
|
|
}
|
|
|
|
|
2022-05-06 21:02:41 +03:00
|
|
|
static void aarch64_a76_initfn(Object *obj)
|
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
|
|
|
|
cpu->dtb_compatible = "arm,cortex-a76";
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_V8);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_NEON);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
|
|
|
|
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);
|
|
|
|
|
|
|
|
/* Ordered by B2.4 AArch64 registers by functional group */
|
|
|
|
cpu->clidr = 0x82000023;
|
|
|
|
cpu->ctr = 0x8444C004;
|
|
|
|
cpu->dcz_blocksize = 4;
|
|
|
|
cpu->isar.id_aa64dfr0 = 0x0000000010305408ull;
|
|
|
|
cpu->isar.id_aa64isar0 = 0x0000100010211120ull;
|
|
|
|
cpu->isar.id_aa64isar1 = 0x0000000000100001ull;
|
|
|
|
cpu->isar.id_aa64mmfr0 = 0x0000000000101122ull;
|
|
|
|
cpu->isar.id_aa64mmfr1 = 0x0000000010212122ull;
|
|
|
|
cpu->isar.id_aa64mmfr2 = 0x0000000000001011ull;
|
|
|
|
cpu->isar.id_aa64pfr0 = 0x1100000010111112ull; /* GIC filled in later */
|
|
|
|
cpu->isar.id_aa64pfr1 = 0x0000000000000010ull;
|
|
|
|
cpu->id_afr0 = 0x00000000;
|
|
|
|
cpu->isar.id_dfr0 = 0x04010088;
|
|
|
|
cpu->isar.id_isar0 = 0x02101110;
|
|
|
|
cpu->isar.id_isar1 = 0x13112111;
|
|
|
|
cpu->isar.id_isar2 = 0x21232042;
|
|
|
|
cpu->isar.id_isar3 = 0x01112131;
|
|
|
|
cpu->isar.id_isar4 = 0x00010142;
|
|
|
|
cpu->isar.id_isar5 = 0x01011121;
|
|
|
|
cpu->isar.id_isar6 = 0x00000010;
|
|
|
|
cpu->isar.id_mmfr0 = 0x10201105;
|
|
|
|
cpu->isar.id_mmfr1 = 0x40000000;
|
|
|
|
cpu->isar.id_mmfr2 = 0x01260000;
|
|
|
|
cpu->isar.id_mmfr3 = 0x02122211;
|
|
|
|
cpu->isar.id_mmfr4 = 0x00021110;
|
|
|
|
cpu->isar.id_pfr0 = 0x10010131;
|
|
|
|
cpu->isar.id_pfr1 = 0x00010000; /* GIC filled in later */
|
|
|
|
cpu->isar.id_pfr2 = 0x00000011;
|
|
|
|
cpu->midr = 0x414fd0b1; /* r4p1 */
|
|
|
|
cpu->revidr = 0;
|
|
|
|
|
|
|
|
/* From B2.18 CCSIDR_EL1 */
|
|
|
|
cpu->ccsidr[0] = 0x701fe01a; /* 64KB L1 dcache */
|
|
|
|
cpu->ccsidr[1] = 0x201fe01a; /* 64KB L1 icache */
|
|
|
|
cpu->ccsidr[2] = 0x707fe03a; /* 512KB L2 cache */
|
|
|
|
|
|
|
|
/* From B2.93 SCTLR_EL3 */
|
|
|
|
cpu->reset_sctlr = 0x30c50838;
|
|
|
|
|
|
|
|
/* From B4.23 ICH_VTR_EL2 */
|
|
|
|
cpu->gic_num_lrs = 4;
|
|
|
|
cpu->gic_vpribits = 5;
|
|
|
|
cpu->gic_vprebits = 5;
|
2022-05-12 18:14:56 +03:00
|
|
|
cpu->gic_pribits = 5;
|
2022-05-06 21:02:41 +03:00
|
|
|
|
|
|
|
/* From B5.1 AdvSIMD AArch64 register summary */
|
|
|
|
cpu->isar.mvfr0 = 0x10110222;
|
|
|
|
cpu->isar.mvfr1 = 0x13211111;
|
|
|
|
cpu->isar.mvfr2 = 0x00000043;
|
target/arm: Make number of counters in PMCR follow the CPU
Currently we give all the v7-and-up CPUs a PMU with 4 counters. This
means that we don't provide the 6 counters that are required by the
Arm BSA (Base System Architecture) specification if the CPU supports
the Virtualization extensions.
Instead of having a single PMCR_NUM_COUNTERS, make each CPU type
specify the PMCR reset value (obtained from the appropriate TRM), and
use the 'N' field of that value to define the number of counters
provided.
This means that we now supply 6 counters instead of 4 for:
Cortex-A9, Cortex-A15, Cortex-A53, Cortex-A57, Cortex-A72,
Cortex-A76, Neoverse-N1, '-cpu max'
This CPU goes from 4 to 8 counters:
A64FX
These CPUs remain with 4 counters:
Cortex-A7, Cortex-A8
This CPU goes down from 4 to 3 counters:
Cortex-R5
Note that because we now use the PMCR reset value of the specific
implementation, we no longer set the LC bit out of reset. This has
an UNKNOWN value out of reset for all cores with any AArch32 support,
so guest software should be setting it anyway if it wants it.
This change was originally landed in commit f7fb73b8cdd3f7 (during
the 6.0 release cycle) but was then reverted by commit
21c2dd77a6aa517 before that release because it did not work with KVM.
This version fixes that by creating the scratch vCPU in
kvm_arm_get_host_cpu_features() with the KVM_ARM_VCPU_PMU_V3 feature
if KVM supports it, and then only asking KVM for the PMCR_EL0 value
if the vCPU has a PMU.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
[PMM: Added the correct value for a64fx]
Message-id: 20220513122852.4063586-1-peter.maydell@linaro.org
2022-05-13 15:28:52 +03:00
|
|
|
|
|
|
|
/* From D5.1 AArch64 PMU register summary */
|
|
|
|
cpu->isar.reset_pmcr_el0 = 0x410b3000;
|
2022-05-06 21:02:41 +03:00
|
|
|
}
|
|
|
|
|
2022-05-06 21:02:42 +03:00
|
|
|
static void aarch64_neoverse_n1_initfn(Object *obj)
|
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
|
|
|
|
cpu->dtb_compatible = "arm,neoverse-n1";
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_V8);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_NEON);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
|
|
|
|
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);
|
|
|
|
|
|
|
|
/* Ordered by B2.4 AArch64 registers by functional group */
|
|
|
|
cpu->clidr = 0x82000023;
|
|
|
|
cpu->ctr = 0x8444c004;
|
|
|
|
cpu->dcz_blocksize = 4;
|
|
|
|
cpu->isar.id_aa64dfr0 = 0x0000000110305408ull;
|
|
|
|
cpu->isar.id_aa64isar0 = 0x0000100010211120ull;
|
|
|
|
cpu->isar.id_aa64isar1 = 0x0000000000100001ull;
|
|
|
|
cpu->isar.id_aa64mmfr0 = 0x0000000000101125ull;
|
|
|
|
cpu->isar.id_aa64mmfr1 = 0x0000000010212122ull;
|
|
|
|
cpu->isar.id_aa64mmfr2 = 0x0000000000001011ull;
|
|
|
|
cpu->isar.id_aa64pfr0 = 0x1100000010111112ull; /* GIC filled in later */
|
|
|
|
cpu->isar.id_aa64pfr1 = 0x0000000000000020ull;
|
|
|
|
cpu->id_afr0 = 0x00000000;
|
|
|
|
cpu->isar.id_dfr0 = 0x04010088;
|
|
|
|
cpu->isar.id_isar0 = 0x02101110;
|
|
|
|
cpu->isar.id_isar1 = 0x13112111;
|
|
|
|
cpu->isar.id_isar2 = 0x21232042;
|
|
|
|
cpu->isar.id_isar3 = 0x01112131;
|
|
|
|
cpu->isar.id_isar4 = 0x00010142;
|
|
|
|
cpu->isar.id_isar5 = 0x01011121;
|
|
|
|
cpu->isar.id_isar6 = 0x00000010;
|
|
|
|
cpu->isar.id_mmfr0 = 0x10201105;
|
|
|
|
cpu->isar.id_mmfr1 = 0x40000000;
|
|
|
|
cpu->isar.id_mmfr2 = 0x01260000;
|
|
|
|
cpu->isar.id_mmfr3 = 0x02122211;
|
|
|
|
cpu->isar.id_mmfr4 = 0x00021110;
|
|
|
|
cpu->isar.id_pfr0 = 0x10010131;
|
|
|
|
cpu->isar.id_pfr1 = 0x00010000; /* GIC filled in later */
|
|
|
|
cpu->isar.id_pfr2 = 0x00000011;
|
|
|
|
cpu->midr = 0x414fd0c1; /* r4p1 */
|
|
|
|
cpu->revidr = 0;
|
|
|
|
|
|
|
|
/* From B2.23 CCSIDR_EL1 */
|
|
|
|
cpu->ccsidr[0] = 0x701fe01a; /* 64KB L1 dcache */
|
|
|
|
cpu->ccsidr[1] = 0x201fe01a; /* 64KB L1 icache */
|
|
|
|
cpu->ccsidr[2] = 0x70ffe03a; /* 1MB L2 cache */
|
|
|
|
|
|
|
|
/* From B2.98 SCTLR_EL3 */
|
|
|
|
cpu->reset_sctlr = 0x30c50838;
|
|
|
|
|
|
|
|
/* From B4.23 ICH_VTR_EL2 */
|
|
|
|
cpu->gic_num_lrs = 4;
|
|
|
|
cpu->gic_vpribits = 5;
|
|
|
|
cpu->gic_vprebits = 5;
|
2022-05-12 18:14:56 +03:00
|
|
|
cpu->gic_pribits = 5;
|
2022-05-06 21:02:42 +03:00
|
|
|
|
|
|
|
/* From B5.1 AdvSIMD AArch64 register summary */
|
|
|
|
cpu->isar.mvfr0 = 0x10110222;
|
|
|
|
cpu->isar.mvfr1 = 0x13211111;
|
|
|
|
cpu->isar.mvfr2 = 0x00000043;
|
target/arm: Make number of counters in PMCR follow the CPU
Currently we give all the v7-and-up CPUs a PMU with 4 counters. This
means that we don't provide the 6 counters that are required by the
Arm BSA (Base System Architecture) specification if the CPU supports
the Virtualization extensions.
Instead of having a single PMCR_NUM_COUNTERS, make each CPU type
specify the PMCR reset value (obtained from the appropriate TRM), and
use the 'N' field of that value to define the number of counters
provided.
This means that we now supply 6 counters instead of 4 for:
Cortex-A9, Cortex-A15, Cortex-A53, Cortex-A57, Cortex-A72,
Cortex-A76, Neoverse-N1, '-cpu max'
This CPU goes from 4 to 8 counters:
A64FX
These CPUs remain with 4 counters:
Cortex-A7, Cortex-A8
This CPU goes down from 4 to 3 counters:
Cortex-R5
Note that because we now use the PMCR reset value of the specific
implementation, we no longer set the LC bit out of reset. This has
an UNKNOWN value out of reset for all cores with any AArch32 support,
so guest software should be setting it anyway if it wants it.
This change was originally landed in commit f7fb73b8cdd3f7 (during
the 6.0 release cycle) but was then reverted by commit
21c2dd77a6aa517 before that release because it did not work with KVM.
This version fixes that by creating the scratch vCPU in
kvm_arm_get_host_cpu_features() with the KVM_ARM_VCPU_PMU_V3 feature
if KVM supports it, and then only asking KVM for the PMCR_EL0 value
if the vCPU has a PMU.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
[PMM: Added the correct value for a64fx]
Message-id: 20220513122852.4063586-1-peter.maydell@linaro.org
2022-05-13 15:28:52 +03:00
|
|
|
|
|
|
|
/* From D5.1 AArch64 PMU register summary */
|
|
|
|
cpu->isar.reset_pmcr_el0 = 0x410c3000;
|
2022-05-06 21:02:42 +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()) {
|
2022-06-20 20:51:56 +03:00
|
|
|
cpu->sve_vq.supported = kvm_arm_sve_get_vls(CPU(cpu));
|
|
|
|
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()) {
|
|
|
|
/*
|
|
|
|
* For KVM we have to automatically enable all supported unitialized
|
|
|
|
* 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)) {
|
|
|
|
/* SVE is disabled and so are all vector lengths. Good. */
|
|
|
|
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;
|
2022-06-08 21:38:57 +03:00
|
|
|
vq_mask = MAKE_64BIT_MASK(0, max_vq);
|
|
|
|
vq_map = vq_supported & ~vq_init & vq_mask;
|
|
|
|
|
|
|
|
if (max_vq == 0 || 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
|
|
|
}
|
|
|
|
|
2019-10-31 17:27:28 +03:00
|
|
|
static void cpu_max_get_sve_max_vq(Object *obj, Visitor *v, const char *name,
|
|
|
|
void *opaque, Error **errp)
|
2018-08-16 16:05:28 +03:00
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
2019-10-31 17:27:28 +03:00
|
|
|
uint32_t value;
|
|
|
|
|
|
|
|
/* All vector lengths are disabled when SVE is off. */
|
|
|
|
if (!cpu_isar_feature(aa64_sve, cpu)) {
|
|
|
|
value = 0;
|
|
|
|
} else {
|
|
|
|
value = cpu->sve_max_vq;
|
|
|
|
}
|
|
|
|
visit_type_uint32(v, name, &value, errp);
|
2018-08-16 16:05:28 +03:00
|
|
|
}
|
|
|
|
|
2019-10-31 17:27:28 +03:00
|
|
|
static void cpu_max_set_sve_max_vq(Object *obj, Visitor *v, const char *name,
|
|
|
|
void *opaque, Error **errp)
|
2018-08-16 16:05:28 +03:00
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
2019-10-31 17:27:33 +03:00
|
|
|
uint32_t max_vq;
|
|
|
|
|
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_uint32(v, name, &max_vq, errp)) {
|
2019-10-31 17:27:33 +03:00
|
|
|
return;
|
|
|
|
}
|
2018-08-16 16:05:28 +03:00
|
|
|
|
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_sve_supported()) {
|
2019-10-31 17:27:33 +03:00
|
|
|
error_setg(errp, "cannot set sve-max-vq");
|
|
|
|
error_append_hint(errp, "SVE not supported by KVM on this host\n");
|
|
|
|
return;
|
|
|
|
}
|
2018-08-16 16:05:28 +03:00
|
|
|
|
2019-10-31 17:27:33 +03:00
|
|
|
if (max_vq == 0 || max_vq > ARM_MAX_VQ) {
|
|
|
|
error_setg(errp, "unsupported SVE vector length");
|
|
|
|
error_append_hint(errp, "Valid sve-max-vq in range [1-%d]\n",
|
2018-08-16 16:05:28 +03:00
|
|
|
ARM_MAX_VQ);
|
2019-10-31 17:27:33 +03:00
|
|
|
return;
|
2018-08-16 16:05:28 +03:00
|
|
|
}
|
2019-10-31 17:27:33 +03:00
|
|
|
|
|
|
|
cpu->sve_max_vq = max_vq;
|
2018-08-16 16:05:28 +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;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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) {
|
2022-06-20 20:52:01 +03:00
|
|
|
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);
|
2021-07-23 23:33:44 +03:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2022-06-20 20:51:58 +03:00
|
|
|
*ptr_default_vq = default_vq;
|
2021-07-23 23:33:44 +03:00
|
|
|
}
|
|
|
|
|
2022-06-20 20:51:58 +03:00
|
|
|
static void cpu_arm_get_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;
|
|
|
|
int32_t value = *ptr_default_vq * 16;
|
2021-07-23 23:33:44 +03:00
|
|
|
|
|
|
|
visit_type_int32(v, name, &value, errp);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2022-06-20 20:52:00 +03:00
|
|
|
static void aarch64_add_sve_properties(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
|
|
|
uint32_t vq;
|
|
|
|
|
2021-01-12 02:57:40 +03:00
|
|
|
object_property_add_bool(obj, "sve", cpu_arm_get_sve, cpu_arm_set_sve);
|
2019-10-31 17:27:34 +03:00
|
|
|
|
|
|
|
for (vq = 1; vq <= ARM_MAX_VQ; ++vq) {
|
|
|
|
char name[8];
|
|
|
|
sprintf(name, "sve%d", vq * 128);
|
2022-06-20 20:51:57 +03:00
|
|
|
object_property_add(obj, name, "bool", cpu_arm_get_vq,
|
|
|
|
cpu_arm_set_vq, NULL, &cpu->sve_vq);
|
2019-10-31 17:27:34 +03:00
|
|
|
}
|
2021-07-23 23:33:44 +03:00
|
|
|
|
|
|
|
#ifdef CONFIG_USER_ONLY
|
|
|
|
/* Mirror linux /proc/sys/abi/sve_default_vector_length. */
|
|
|
|
object_property_add(obj, "sve-default-vector-length", "int32",
|
2022-06-20 20:51:58 +03:00
|
|
|
cpu_arm_get_default_vec_len,
|
|
|
|
cpu_arm_set_default_vec_len, NULL,
|
|
|
|
&cpu->sve_default_vq);
|
2021-07-23 23:33:44 +03:00
|
|
|
#endif
|
2019-10-31 17:27:34 +03:00
|
|
|
}
|
|
|
|
|
2022-06-20 20:52:01 +03:00
|
|
|
static void aarch64_add_sme_properties(Object *obj)
|
|
|
|
{
|
|
|
|
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];
|
|
|
|
sprintf(name, "sme%d", vq * 128);
|
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2021-01-12 02:57:39 +03:00
|
|
|
void arm_cpu_pauth_finalize(ARMCPU *cpu, Error **errp)
|
|
|
|
{
|
|
|
|
int arch_val = 0, impdef_val = 0;
|
|
|
|
uint64_t t;
|
|
|
|
|
2022-01-07 18:01:54 +03:00
|
|
|
/* Exit early if PAuth is enabled, and fall through to disable it */
|
2022-02-04 19:55:06 +03:00
|
|
|
if ((kvm_enabled() || hvf_enabled()) && cpu->prop_pauth) {
|
2022-01-07 18:01:54 +03:00
|
|
|
if (!cpu_isar_feature(aa64_pauth, cpu)) {
|
2022-02-04 19:55:06 +03:00
|
|
|
error_setg(errp, "'pauth' feature not supported by %s on this host",
|
|
|
|
kvm_enabled() ? "KVM" : "hvf");
|
2022-01-07 18:01:54 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-01-12 02:57:39 +03:00
|
|
|
/* TODO: Handle HaveEnhancedPAC, HaveEnhancedPAC2, HaveFPAC. */
|
|
|
|
if (cpu->prop_pauth) {
|
|
|
|
if (cpu->prop_pauth_impdef) {
|
|
|
|
impdef_val = 1;
|
|
|
|
} else {
|
|
|
|
arch_val = 1;
|
|
|
|
}
|
|
|
|
} else if (cpu->prop_pauth_impdef) {
|
|
|
|
error_setg(errp, "cannot enable pauth-impdef without pauth");
|
|
|
|
error_append_hint(errp, "Add pauth=on to the CPU property list.\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
t = cpu->isar.id_aa64isar1;
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, APA, arch_val);
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, GPA, arch_val);
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, API, impdef_val);
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, GPI, impdef_val);
|
|
|
|
cpu->isar.id_aa64isar1 = t;
|
|
|
|
}
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
2022-06-20 20:52:00 +03:00
|
|
|
static void aarch64_add_pauth_properties(Object *obj)
|
2022-01-07 18:01:54 +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);
|
2022-02-04 19:55:06 +03:00
|
|
|
if (kvm_enabled() || hvf_enabled()) {
|
2022-01-07 18:01:54 +03:00
|
|
|
/*
|
|
|
|
* Mirror PAuth support from the probed sysregs back into the
|
2022-02-04 19:55:06 +03:00
|
|
|
* 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.
|
2022-01-07 18:01:54 +03:00
|
|
|
*/
|
|
|
|
cpu->prop_pauth = cpu_isar_feature(aa64_pauth, cpu);
|
|
|
|
} else {
|
|
|
|
qdev_property_add_static(DEVICE(obj), &arm_cpu_pauth_impdef_property);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-03-02 00:59:57 +03:00
|
|
|
static Property arm_cpu_lpa2_property =
|
|
|
|
DEFINE_PROP_BOOL("lpa2", ARMCPU, prop_lpa2, true);
|
|
|
|
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
if (!cpu->prop_lpa2) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2018-03-09 20:09:44 +03:00
|
|
|
/* -cpu max: if KVM is enabled, like -cpu host (best possible with this host);
|
|
|
|
* otherwise, a CPU with as many features enabled as our emulation supports.
|
|
|
|
* The version of '-cpu max' for qemu-system-arm is defined in cpu.c;
|
|
|
|
* this only needs to handle 64 bits.
|
|
|
|
*/
|
|
|
|
static void aarch64_max_initfn(Object *obj)
|
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
2022-02-04 19:55:04 +03:00
|
|
|
uint64_t t;
|
2022-05-05 21:39:50 +03:00
|
|
|
uint32_t u;
|
2018-03-09 20:09:44 +03:00
|
|
|
|
2022-02-04 19:55:05 +03:00
|
|
|
if (kvm_enabled() || hvf_enabled()) {
|
|
|
|
/* With KVM or HVF, '-cpu max' is identical to '-cpu host' */
|
2022-02-04 19:55:03 +03:00
|
|
|
aarch64_host_initfn(obj);
|
|
|
|
return;
|
2022-02-04 19:55:04 +03:00
|
|
|
}
|
2018-10-24 09:50:16 +03:00
|
|
|
|
2022-02-04 19:55:04 +03:00
|
|
|
/* '-cpu max' for TCG: we currently do this as "A57 with extra things" */
|
|
|
|
|
|
|
|
aarch64_a57_initfn(obj);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reset MIDR so the guest doesn't mistake our 'max' CPU type for a real
|
|
|
|
* one and try to apply errata workarounds or use impdef features we
|
|
|
|
* don't provide.
|
|
|
|
* An IMPLEMENTER field of 0 means "reserved for software use";
|
|
|
|
* ARCHITECTURE must be 0xf indicating "v7 or later, check ID registers
|
|
|
|
* to see which features are present";
|
|
|
|
* the VARIANT, PARTNUM and REVISION fields are all implementation
|
|
|
|
* defined and we choose to define PARTNUM just in case guest
|
|
|
|
* code needs to distinguish this QEMU CPU from other software
|
|
|
|
* implementations, though this shouldn't be needed.
|
|
|
|
*/
|
|
|
|
t = FIELD_DP64(0, MIDR_EL1, IMPLEMENTER, 0);
|
|
|
|
t = FIELD_DP64(t, MIDR_EL1, ARCHITECTURE, 0xf);
|
|
|
|
t = FIELD_DP64(t, MIDR_EL1, PARTNUM, 'Q');
|
|
|
|
t = FIELD_DP64(t, MIDR_EL1, VARIANT, 0);
|
|
|
|
t = FIELD_DP64(t, MIDR_EL1, REVISION, 0);
|
|
|
|
cpu->midr = t;
|
|
|
|
|
2022-05-05 21:39:50 +03:00
|
|
|
/*
|
|
|
|
* We're going to set FEAT_S2FWB, which mandates that CLIDR_EL1.{LoUU,LoUIS}
|
|
|
|
* are zero.
|
|
|
|
*/
|
|
|
|
u = cpu->clidr;
|
|
|
|
u = FIELD_DP32(u, CLIDR_EL1, LOUIS, 0);
|
|
|
|
u = FIELD_DP32(u, CLIDR_EL1, LOUU, 0);
|
|
|
|
cpu->clidr = u;
|
|
|
|
|
2022-02-04 19:55:04 +03:00
|
|
|
t = cpu->isar.id_aa64isar0;
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, AES, 2); /* FEAT_PMULL */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, SHA1, 1); /* FEAT_SHA1 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, SHA2, 2); /* FEAT_SHA512 */
|
2022-02-04 19:55:04 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, CRC32, 1);
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, ATOMIC, 2); /* FEAT_LSE */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, RDM, 1); /* FEAT_RDM */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, SHA3, 1); /* FEAT_SHA3 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, SM3, 1); /* FEAT_SM3 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, SM4, 1); /* FEAT_SM4 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, DP, 1); /* FEAT_DotProd */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, FHM, 1); /* FEAT_FHM */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, TS, 2); /* FEAT_FlagM2 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, TLB, 2); /* FEAT_TLBIRANGE */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR0, RNDR, 1); /* FEAT_RNG */
|
2022-02-04 19:55:04 +03:00
|
|
|
cpu->isar.id_aa64isar0 = t;
|
|
|
|
|
|
|
|
t = cpu->isar.id_aa64isar1;
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, DPB, 2); /* FEAT_DPB2 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, JSCVT, 1); /* FEAT_JSCVT */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, FCMA, 1); /* FEAT_FCMA */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, LRCPC, 2); /* FEAT_LRCPC2 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, FRINTTS, 1); /* FEAT_FRINTTS */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, SB, 1); /* FEAT_SB */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, SPECRES, 1); /* FEAT_SPECRES */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, BF16, 1); /* FEAT_BF16 */
|
2022-05-06 21:02:40 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, DGH, 1); /* FEAT_DGH */
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64ISAR1, I8MM, 1); /* FEAT_I8MM */
|
2022-02-04 19:55:04 +03:00
|
|
|
cpu->isar.id_aa64isar1 = t;
|
|
|
|
|
|
|
|
t = cpu->isar.id_aa64pfr0;
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64PFR0, FP, 1); /* FEAT_FP16 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64PFR0, ADVSIMD, 1); /* FEAT_FP16 */
|
2022-06-08 21:38:46 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64PFR0, RAS, 2); /* FEAT_RASv1p1 + FEAT_DoubleFault */
|
2022-02-04 19:55:04 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64PFR0, SVE, 1);
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64PFR0, SEL2, 1); /* FEAT_SEL2 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64PFR0, DIT, 1); /* FEAT_DIT */
|
2022-05-06 21:02:38 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64PFR0, CSV2, 2); /* FEAT_CSV2_2 */
|
2022-05-06 21:02:39 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64PFR0, CSV3, 1); /* FEAT_CSV3 */
|
2022-02-04 19:55:04 +03:00
|
|
|
cpu->isar.id_aa64pfr0 = t;
|
|
|
|
|
|
|
|
t = cpu->isar.id_aa64pfr1;
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64PFR1, BT, 1); /* FEAT_BTI */
|
|
|
|
t = FIELD_DP64(t, ID_AA64PFR1, SSBS, 2); /* FEAT_SSBS2 */
|
2022-02-04 19:55:04 +03:00
|
|
|
/*
|
|
|
|
* Begin with full support for MTE. This will be downgraded to MTE=0
|
|
|
|
* during realize if the board provides no tag memory, much like
|
|
|
|
* we do for EL2 with the virtualization=on property.
|
|
|
|
*/
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64PFR1, MTE, 3); /* FEAT_MTE3 */
|
2022-06-08 21:38:46 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64PFR1, RAS_FRAC, 0); /* FEAT_RASv1p1 + FEAT_DoubleFault */
|
2022-07-08 18:15:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64PFR1, SME, 1); /* FEAT_SME */
|
2022-05-06 21:02:38 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64PFR1, CSV2_FRAC, 0); /* FEAT_CSV2_2 */
|
2022-02-04 19:55:04 +03:00
|
|
|
cpu->isar.id_aa64pfr1 = t;
|
|
|
|
|
|
|
|
t = cpu->isar.id_aa64mmfr0;
|
2022-03-02 00:59:50 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR0, PARANGE, 6); /* FEAT_LPA: 52 bits */
|
2022-03-02 00:59:55 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR0, TGRAN16, 1); /* 16k pages supported */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR0, TGRAN16_2, 2); /* 16k stage2 supported */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR0, TGRAN64_2, 2); /* 64k stage2 supported */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR0, TGRAN4_2, 2); /* 4k stage2 supported */
|
2022-02-04 19:55:04 +03:00
|
|
|
cpu->isar.id_aa64mmfr0 = t;
|
|
|
|
|
|
|
|
t = cpu->isar.id_aa64mmfr1;
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR1, VMIDBITS, 2); /* FEAT_VMID16 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR1, VH, 1); /* FEAT_VHE */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR1, HPDS, 1); /* FEAT_HPDS */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR1, LO, 1); /* FEAT_LOR */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR1, PAN, 2); /* FEAT_PAN2 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR1, XNX, 1); /* FEAT_XNX */
|
2022-05-17 08:48:44 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR1, HCX, 1); /* FEAT_HCX */
|
2022-02-04 19:55:04 +03:00
|
|
|
cpu->isar.id_aa64mmfr1 = t;
|
|
|
|
|
|
|
|
t = cpu->isar.id_aa64mmfr2;
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR2, CNP, 1); /* FEAT_TTCNP */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR2, UAO, 1); /* FEAT_UAO */
|
2022-05-06 21:02:36 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR2, IESB, 1); /* FEAT_IESB */
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR2, VARANGE, 1); /* FEAT_LVA */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR2, ST, 1); /* FEAT_TTST */
|
2022-05-09 18:54:57 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR2, IDS, 1); /* FEAT_IDST */
|
2022-05-05 21:39:50 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR2, FWB, 1); /* FEAT_S2FWB */
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR2, TTL, 1); /* FEAT_TTL */
|
|
|
|
t = FIELD_DP64(t, ID_AA64MMFR2, BBM, 2); /* FEAT_BBM at level 2 */
|
2022-02-04 19:55:04 +03:00
|
|
|
cpu->isar.id_aa64mmfr2 = t;
|
|
|
|
|
|
|
|
t = cpu->isar.id_aa64zfr0;
|
|
|
|
t = FIELD_DP64(t, ID_AA64ZFR0, SVEVER, 1);
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64ZFR0, AES, 2); /* FEAT_SVE_PMULL128 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ZFR0, BITPERM, 1); /* FEAT_SVE_BitPerm */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ZFR0, BFLOAT16, 1); /* FEAT_BF16 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ZFR0, SHA3, 1); /* FEAT_SVE_SHA3 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ZFR0, SM4, 1); /* FEAT_SVE_SM4 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ZFR0, I8MM, 1); /* FEAT_I8MM */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ZFR0, F32MM, 1); /* FEAT_F32MM */
|
|
|
|
t = FIELD_DP64(t, ID_AA64ZFR0, F64MM, 1); /* FEAT_F64MM */
|
2022-02-04 19:55:04 +03:00
|
|
|
cpu->isar.id_aa64zfr0 = t;
|
|
|
|
|
|
|
|
t = cpu->isar.id_aa64dfr0;
|
2022-05-06 21:02:30 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64DFR0, DEBUGVER, 9); /* FEAT_Debugv8p4 */
|
2022-05-06 21:02:27 +03:00
|
|
|
t = FIELD_DP64(t, ID_AA64DFR0, PMUVER, 5); /* FEAT_PMUv3p4 */
|
2022-02-04 19:55:04 +03:00
|
|
|
cpu->isar.id_aa64dfr0 = t;
|
|
|
|
|
2022-07-08 18:15:27 +03:00
|
|
|
t = cpu->isar.id_aa64smfr0;
|
|
|
|
t = FIELD_DP64(t, ID_AA64SMFR0, F32F32, 1); /* FEAT_SME */
|
|
|
|
t = FIELD_DP64(t, ID_AA64SMFR0, B16F32, 1); /* FEAT_SME */
|
|
|
|
t = FIELD_DP64(t, ID_AA64SMFR0, F16F32, 1); /* FEAT_SME */
|
|
|
|
t = FIELD_DP64(t, ID_AA64SMFR0, I8I32, 0xf); /* FEAT_SME */
|
|
|
|
t = FIELD_DP64(t, ID_AA64SMFR0, F64F64, 1); /* FEAT_SME_F64F64 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64SMFR0, I16I64, 0xf); /* FEAT_SME_I16I64 */
|
|
|
|
t = FIELD_DP64(t, ID_AA64SMFR0, FA64, 1); /* FEAT_SME_FA64 */
|
|
|
|
cpu->isar.id_aa64smfr0 = t;
|
|
|
|
|
2022-05-06 21:02:26 +03:00
|
|
|
/* Replicate the same data to the 32-bit id registers. */
|
|
|
|
aa32_max_features(cpu);
|
2018-10-24 09:50:17 +03:00
|
|
|
|
|
|
|
#ifdef CONFIG_USER_ONLY
|
2022-02-04 19:55:04 +03:00
|
|
|
/*
|
|
|
|
* For usermode -cpu max we can use a larger and more efficient DCZ
|
|
|
|
* blocksize since we don't have to follow what the hardware does.
|
|
|
|
*/
|
|
|
|
cpu->ctr = 0x80038003; /* 32 byte I and D cacheline size, VIPT icache */
|
|
|
|
cpu->dcz_blocksize = 7; /* 512 bytes */
|
2018-03-09 20:09:44 +03:00
|
|
|
#endif
|
2021-01-12 02:57:39 +03:00
|
|
|
|
2022-06-20 20:51:56 +03:00
|
|
|
cpu->sve_vq.supported = MAKE_64BIT_MASK(0, ARM_MAX_VQ);
|
2022-06-20 20:52:01 +03:00
|
|
|
cpu->sme_vq.supported = SVE_VQ_POW2_MAP;
|
2019-10-31 17:27:31 +03:00
|
|
|
|
2022-01-07 18:01:54 +03:00
|
|
|
aarch64_add_pauth_properties(obj);
|
2019-10-31 17:27:34 +03:00
|
|
|
aarch64_add_sve_properties(obj);
|
2022-06-20 20:52:01 +03:00
|
|
|
aarch64_add_sme_properties(obj);
|
2019-10-31 17:27:33 +03:00
|
|
|
object_property_add(obj, "sve-max-vq", "uint32", cpu_max_get_sve_max_vq,
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
cpu_max_set_sve_max_vq, NULL, NULL);
|
2022-03-02 00:59:57 +03:00
|
|
|
qdev_property_add_static(DEVICE(obj), &arm_cpu_lpa2_property);
|
2018-03-09 20:09:44 +03:00
|
|
|
}
|
|
|
|
|
2021-08-31 11:29:38 +03:00
|
|
|
static void aarch64_a64fx_initfn(Object *obj)
|
|
|
|
{
|
|
|
|
ARMCPU *cpu = ARM_CPU(obj);
|
|
|
|
|
|
|
|
cpu->dtb_compatible = "arm,a64fx";
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_V8);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_NEON);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_AARCH64);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_EL2);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_EL3);
|
|
|
|
set_feature(&cpu->env, ARM_FEATURE_PMU);
|
|
|
|
cpu->midr = 0x461f0010;
|
|
|
|
cpu->revidr = 0x00000000;
|
|
|
|
cpu->ctr = 0x86668006;
|
|
|
|
cpu->reset_sctlr = 0x30000180;
|
|
|
|
cpu->isar.id_aa64pfr0 = 0x0000000101111111; /* No RAS Extensions */
|
|
|
|
cpu->isar.id_aa64pfr1 = 0x0000000000000000;
|
|
|
|
cpu->isar.id_aa64dfr0 = 0x0000000010305408;
|
|
|
|
cpu->isar.id_aa64dfr1 = 0x0000000000000000;
|
|
|
|
cpu->id_aa64afr0 = 0x0000000000000000;
|
|
|
|
cpu->id_aa64afr1 = 0x0000000000000000;
|
|
|
|
cpu->isar.id_aa64mmfr0 = 0x0000000000001122;
|
|
|
|
cpu->isar.id_aa64mmfr1 = 0x0000000011212100;
|
|
|
|
cpu->isar.id_aa64mmfr2 = 0x0000000000001011;
|
|
|
|
cpu->isar.id_aa64isar0 = 0x0000000010211120;
|
|
|
|
cpu->isar.id_aa64isar1 = 0x0000000000010001;
|
|
|
|
cpu->isar.id_aa64zfr0 = 0x0000000000000000;
|
|
|
|
cpu->clidr = 0x0000000080000023;
|
|
|
|
cpu->ccsidr[0] = 0x7007e01c; /* 64KB L1 dcache */
|
|
|
|
cpu->ccsidr[1] = 0x2007e01c; /* 64KB L1 icache */
|
|
|
|
cpu->ccsidr[2] = 0x70ffe07c; /* 8MB L2 cache */
|
|
|
|
cpu->dcz_blocksize = 6; /* 256 bytes */
|
|
|
|
cpu->gic_num_lrs = 4;
|
|
|
|
cpu->gic_vpribits = 5;
|
|
|
|
cpu->gic_vprebits = 5;
|
2022-05-12 18:14:56 +03:00
|
|
|
cpu->gic_pribits = 5;
|
2021-08-31 11:29:38 +03:00
|
|
|
|
2022-06-08 21:38:57 +03:00
|
|
|
/* The A64FX supports only 128, 256 and 512 bit vector lengths */
|
2021-08-31 11:29:38 +03:00
|
|
|
aarch64_add_sve_properties(obj);
|
2022-06-20 20:51:56 +03:00
|
|
|
cpu->sve_vq.supported = (1 << 0) /* 128bit */
|
2022-06-08 21:38:57 +03:00
|
|
|
| (1 << 1) /* 256bit */
|
|
|
|
| (1 << 3); /* 512bit */
|
2021-08-31 11:29:38 +03:00
|
|
|
|
target/arm: Make number of counters in PMCR follow the CPU
Currently we give all the v7-and-up CPUs a PMU with 4 counters. This
means that we don't provide the 6 counters that are required by the
Arm BSA (Base System Architecture) specification if the CPU supports
the Virtualization extensions.
Instead of having a single PMCR_NUM_COUNTERS, make each CPU type
specify the PMCR reset value (obtained from the appropriate TRM), and
use the 'N' field of that value to define the number of counters
provided.
This means that we now supply 6 counters instead of 4 for:
Cortex-A9, Cortex-A15, Cortex-A53, Cortex-A57, Cortex-A72,
Cortex-A76, Neoverse-N1, '-cpu max'
This CPU goes from 4 to 8 counters:
A64FX
These CPUs remain with 4 counters:
Cortex-A7, Cortex-A8
This CPU goes down from 4 to 3 counters:
Cortex-R5
Note that because we now use the PMCR reset value of the specific
implementation, we no longer set the LC bit out of reset. This has
an UNKNOWN value out of reset for all cores with any AArch32 support,
so guest software should be setting it anyway if it wants it.
This change was originally landed in commit f7fb73b8cdd3f7 (during
the 6.0 release cycle) but was then reverted by commit
21c2dd77a6aa517 before that release because it did not work with KVM.
This version fixes that by creating the scratch vCPU in
kvm_arm_get_host_cpu_features() with the KVM_ARM_VCPU_PMU_V3 feature
if KVM supports it, and then only asking KVM for the PMCR_EL0 value
if the vCPU has a PMU.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
[PMM: Added the correct value for a64fx]
Message-id: 20220513122852.4063586-1-peter.maydell@linaro.org
2022-05-13 15:28:52 +03:00
|
|
|
cpu->isar.reset_pmcr_el0 = 0x46014040;
|
|
|
|
|
2021-08-31 11:29:38 +03:00
|
|
|
/* TODO: Add A64FX specific HPC extension registers */
|
|
|
|
}
|
|
|
|
|
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-10-11 05:19:29 +03:00
|
|
|
{ .name = "cortex-a72", .initfn = aarch64_a72_initfn },
|
2022-05-06 21:02:41 +03:00
|
|
|
{ .name = "cortex-a76", .initfn = aarch64_a76_initfn },
|
2021-08-31 11:29:38 +03:00
|
|
|
{ .name = "a64fx", .initfn = aarch64_a64fx_initfn },
|
2022-05-06 21:02:42 +03:00
|
|
|
{ .name = "neoverse-n1", .initfn = aarch64_neoverse_n1_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)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2015-12-03 15:14:41 +03:00
|
|
|
static gchar *aarch64_gdb_arch_name(CPUState *cs)
|
|
|
|
{
|
|
|
|
return g_strdup("aarch64");
|
|
|
|
}
|
|
|
|
|
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_num_core_regs = 34;
|
|
|
|
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,
|
|
|
|
.instance_size = sizeof(ARMCPU),
|
2018-11-27 11:55:59 +03:00
|
|
|
.instance_init = aarch64_cpu_instance_init,
|
2013-09-03 23:12:07 +04:00
|
|
|
.class_size = sizeof(ARMCPUClass),
|
2018-11-27 11:55:59 +03:00
|
|
|
.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_size = sizeof(ARMCPU),
|
|
|
|
.instance_finalize = aarch64_cpu_finalizefn,
|
|
|
|
.abstract = true,
|
|
|
|
.class_size = sizeof(AArch64CPUClass),
|
|
|
|
.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)
|