[PATCH 0/2] target/arm: Implement Cortex Neoverse-V1

[PATCH 0/2] target/arm: Implement Cortex Neoverse-V1

[Peter Maydell]

This patchset implements the Cortex Neoverse-V1 CPU type, as a
representative Armv8.3 (+ some extras from 8.4) CPU matching real
hardware.  The main thing we were waiting for to be able to define
this was FEAT_LSE2, and that is now supported.

There are a few things the real hardware implements that QEMU does
not yet, which patch 1 ensures we don't advertise to the guest:

  * FEAT_TRF (Self-hosted Trace Extension)
  * Trace Macrocell system register access
  * Memory mapped trace
  * FEAT_AMU (Activity Monitors Extension)
  * FEAT_MPAM (Memory Partitioning and Monitoring Extension)
  * FEAT_NV (Nested Virtualization)

Most of these, like FEAT_SPE which we were already suppressing, are
"introspection/trace" type features which QEMU is unlikely to ever
implement.  The odd-one-out here is FEAT_NV -- we could implement
that and at some point we probably will.
                
Patch 2 then implements the CPU itself.

thanks
-- PMM

Peter Maydell (2):
  target/arm: Suppress more TCG unimplemented features in ID registers
  target/arm: Define neoverse-v1

 docs/system/arm/virt.rst |   1 +
 hw/arm/sbsa-ref.c        |   1 +
 hw/arm/virt.c            |   1 +
 target/arm/cpu.c         |  33 ++++++++--
 target/arm/tcg/cpu64.c   | 128 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 160 insertions(+), 4 deletions(-)

-- 
2.34.1

[PATCH 1/2] target/arm: Suppress more TCG unimplemented features in ID registers

[Peter Maydell]

We already squash the ID register field for FEAT_SPE (the Statistical
Profiling Extension) because TCG does not implement it and if we
advertise it to the guest the guest will crash trying to look at
non-existent system registers.  Do the same for some other features
which a real hardware Neoverse-V1 implements but which TCG doesn't:
 * FEAT_TRF (Self-hosted Trace Extension)
 * Trace Macrocell system register access
 * Memory mapped trace
 * FEAT_AMU (Activity Monitors Extension)
 * FEAT_MPAM (Memory Partitioning and Monitoring Extension)
 * FEAT_NV (Nested Virtualization)

Most of these, like FEAT_SPE, are "introspection/trace" type features
which QEMU is unlikely to ever implement.  The odd-one-out here is
FEAT_NV -- we could implement that and at some point we probably
will.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 target/arm/cpu.c | 33 +++++++++++++++++++++++++++++----
 1 file changed, 29 insertions(+), 4 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index a1e77698ba2..7eb7e909097 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2048,13 +2048,38 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)
 
     if (tcg_enabled()) {
         /*
-         * Don't report the Statistical Profiling Extension in the ID
-         * registers, because TCG doesn't implement it yet (not even a
-         * minimal stub version) and guests will fall over when they
-         * try to access the non-existent system registers for it.
+         * Don't report some architectural features in the ID registers
+         * where TCG does not yet implement it (not even a minimal
+         * stub version). This avoids guests falling over when they
+         * try to access the non-existent system registers for them.
          */
+        /* FEAT_SPE (Statistical Profiling Extension) */
         cpu->isar.id_aa64dfr0 =
             FIELD_DP64(cpu->isar.id_aa64dfr0, ID_AA64DFR0, PMSVER, 0);
+        /* FEAT_TRF (Self-hosted Trace Extension) */
+        cpu->isar.id_aa64dfr0 =
+            FIELD_DP64(cpu->isar.id_aa64dfr0, ID_AA64DFR0, TRACEFILT, 0);
+        cpu->isar.id_dfr0 =
+            FIELD_DP32(cpu->isar.id_dfr0, ID_DFR0, TRACEFILT, 0);
+        /* Trace Macrocell system register access */
+        cpu->isar.id_aa64dfr0 =
+            FIELD_DP64(cpu->isar.id_aa64dfr0, ID_AA64DFR0, TRACEVER, 0);
+        cpu->isar.id_dfr0 =
+            FIELD_DP32(cpu->isar.id_dfr0, ID_DFR0, COPTRC, 0);
+        /* Memory mapped trace */
+        cpu->isar.id_dfr0 =
+            FIELD_DP32(cpu->isar.id_dfr0, ID_DFR0, MMAPTRC, 0);
+        /* FEAT_AMU (Activity Monitors Extension) */
+        cpu->isar.id_aa64pfr0 =
+            FIELD_DP64(cpu->isar.id_aa64pfr0, ID_AA64PFR0, AMU, 0);
+        cpu->isar.id_pfr0 =
+            FIELD_DP32(cpu->isar.id_pfr0, ID_PFR0, AMU, 0);
+        /* FEAT_MPAM (Memory Partitioning and Monitoring Extension) */
+        cpu->isar.id_aa64pfr0 =
+            FIELD_DP64(cpu->isar.id_aa64pfr0, ID_AA64PFR0, MPAM, 0);
+        /* FEAT_NV (Nested Virtualization) */
+        cpu->isar.id_aa64mmfr2 =
+            FIELD_DP64(cpu->isar.id_aa64mmfr2, ID_AA64MMFR2, NV, 0);
     }
 
     /* MPU can be configured out of a PMSA CPU either by setting has-mpu
-- 
2.34.1

Re: [PATCH 1/2] target/arm: Suppress more TCG unimplemented features in ID registers

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> We already squash the ID register field for FEAT_SPE (the Statistical
> Profiling Extension) because TCG does not implement it and if we
> advertise it to the guest the guest will crash trying to look at
> non-existent system registers.  Do the same for some other features
> which a real hardware Neoverse-V1 implements but which TCG doesn't:
>  * FEAT_TRF (Self-hosted Trace Extension)
>  * Trace Macrocell system register access
>  * Memory mapped trace
>  * FEAT_AMU (Activity Monitors Extension)
>  * FEAT_MPAM (Memory Partitioning and Monitoring Extension)
>  * FEAT_NV (Nested Virtualization)
>
> Most of these, like FEAT_SPE, are "introspection/trace" type features
> which QEMU is unlikely to ever implement.  The odd-one-out here is
> FEAT_NV -- we could implement that and at some point we probably
> will.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH 1/2] target/arm: Suppress more TCG unimplemented features in ID registers

[Richard Henderson]

On 7/4/23 15:06, Peter Maydell wrote:
> We already squash the ID register field for FEAT_SPE (the Statistical
> Profiling Extension) because TCG does not implement it and if we
> advertise it to the guest the guest will crash trying to look at
> non-existent system registers.  Do the same for some other features
> which a real hardware Neoverse-V1 implements but which TCG doesn't:
>   * FEAT_TRF (Self-hosted Trace Extension)
>   * Trace Macrocell system register access
>   * Memory mapped trace
>   * FEAT_AMU (Activity Monitors Extension)
>   * FEAT_MPAM (Memory Partitioning and Monitoring Extension)
>   * FEAT_NV (Nested Virtualization)
> 
> Most of these, like FEAT_SPE, are "introspection/trace" type features
> which QEMU is unlikely to ever implement.  The odd-one-out here is
> FEAT_NV -- we could implement that and at some point we probably
> will.
> 
> Signed-off-by: Peter Maydell<peter.maydell@linaro.org>
> ---
>   target/arm/cpu.c | 33 +++++++++++++++++++++++++++++----
>   1 file changed, 29 insertions(+), 4 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

[PATCH 2/2] target/arm: Define neoverse-v1

[Peter Maydell]

Now that we have implemented support for FEAT_LSE2, we can define
a CPU model for the Neoverse-V1, and enable it for the virt and
sbsa-ref boards.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
If you're checking the values against the TRM, note that the
summary tables differ from the register description in the TRM
for ID_AA64DFR0_EL1, ID_AA64ZFR0_EL1 and ID_PFR0_EL1: we
trust the versions in the register descriptions. Also the
MIDR value in the r1p2 TRM isn't updated from r1p1.
The CCSIDR_EL1 values in the TRM unfortunately seem to be wrong:
the comment in the patch describes how I've calculated the
values used here.

I've stuck with the existing approach for aarch64_add_*_properties
in the interests of getting this in before softfreeze, though
there does seem like there ought to be a workable refactoring
there somewhere.
---
 docs/system/arm/virt.rst |   1 +
 hw/arm/sbsa-ref.c        |   1 +
 hw/arm/virt.c            |   1 +
 target/arm/tcg/cpu64.c   | 128 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 131 insertions(+)

diff --git a/docs/system/arm/virt.rst b/docs/system/arm/virt.rst
index 1cab33f02e3..51cdac68410 100644
--- a/docs/system/arm/virt.rst
+++ b/docs/system/arm/virt.rst
@@ -61,6 +61,7 @@ Supported guest CPU types:
 - ``a64fx`` (64-bit)
 - ``host`` (with KVM only)
 - ``neoverse-n1`` (64-bit)
+- ``neoverse-v1`` (64-bit)
 - ``max`` (same as ``host`` for KVM; best possible emulation with TCG)
 
 Note that the default is ``cortex-a15``, so for an AArch64 guest you must
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index 0639f97dd5f..f0857198983 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -150,6 +150,7 @@ static const char * const valid_cpus[] = {
     ARM_CPU_TYPE_NAME("cortex-a57"),
     ARM_CPU_TYPE_NAME("cortex-a72"),
     ARM_CPU_TYPE_NAME("neoverse-n1"),
+    ARM_CPU_TYPE_NAME("neoverse-v1"),
     ARM_CPU_TYPE_NAME("max"),
 };
 
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 9b9f7d9c687..20b134fe477 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -213,6 +213,7 @@ static const char *valid_cpus[] = {
     ARM_CPU_TYPE_NAME("cortex-a76"),
     ARM_CPU_TYPE_NAME("a64fx"),
     ARM_CPU_TYPE_NAME("neoverse-n1"),
+    ARM_CPU_TYPE_NAME("neoverse-v1"),
 #endif
     ARM_CPU_TYPE_NAME("cortex-a53"),
     ARM_CPU_TYPE_NAME("cortex-a57"),
diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c
index 6fec2d8a57a..6b8e8461f54 100644
--- a/target/arm/tcg/cpu64.c
+++ b/target/arm/tcg/cpu64.c
@@ -502,6 +502,31 @@ static void define_neoverse_n1_cp_reginfo(ARMCPU *cpu)
     define_arm_cp_regs(cpu, neoverse_n1_cp_reginfo);
 }
 
+static const ARMCPRegInfo neoverse_v1_cp_reginfo[] = {
+    { .name = "CPUECTLR2_EL1", .state = ARM_CP_STATE_AA64,
+      .opc0 = 3, .opc1 = 0, .crn = 15, .crm = 1, .opc2 = 5,
+      .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+    { .name = "CPUPPMCR_EL3", .state = ARM_CP_STATE_AA64,
+      .opc0 = 3, .opc1 = 6, .crn = 15, .crm = 2, .opc2 = 0,
+      .access = PL3_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+    { .name = "CPUPPMCR2_EL3", .state = ARM_CP_STATE_AA64,
+      .opc0 = 3, .opc1 = 6, .crn = 15, .crm = 2, .opc2 = 1,
+      .access = PL3_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+    { .name = "CPUPPMCR3_EL3", .state = ARM_CP_STATE_AA64,
+      .opc0 = 3, .opc1 = 6, .crn = 15, .crm = 2, .opc2 = 6,
+      .access = PL3_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+};
+
+static void define_neoverse_v1_cp_reginfo(ARMCPU *cpu)
+{
+    /*
+     * The Neoverse V1 has all of the Neoverse N1's IMPDEF
+     * registers and a few more of its own.
+     */
+    define_arm_cp_regs(cpu, neoverse_n1_cp_reginfo);
+    define_arm_cp_regs(cpu, neoverse_v1_cp_reginfo);
+}
+
 static void aarch64_neoverse_n1_initfn(Object *obj)
 {
     ARMCPU *cpu = ARM_CPU(obj);
@@ -573,6 +598,108 @@ static void aarch64_neoverse_n1_initfn(Object *obj)
     define_neoverse_n1_cp_reginfo(cpu);
 }
 
+static void aarch64_neoverse_v1_initfn(Object *obj)
+{
+    ARMCPU *cpu = ARM_CPU(obj);
+
+    cpu->dtb_compatible = "arm,neoverse-v1";
+    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 3.2.4 AArch64 registers by functional group */
+    cpu->clidr = 0x82000023;
+    cpu->ctr = 0xb444c004; /* With DIC and IDC set */
+    cpu->dcz_blocksize = 4;
+    cpu->id_aa64afr0 = 0x00000000;
+    cpu->id_aa64afr1 = 0x00000000;
+    cpu->isar.id_aa64dfr0  = 0x000001f210305519ull;
+    cpu->isar.id_aa64dfr1 = 0x00000000;
+    cpu->isar.id_aa64isar0 = 0x1011111110212120ull; /* with FEAT_RNG */
+    cpu->isar.id_aa64isar1 = 0x0111000001211032ull;
+    cpu->isar.id_aa64mmfr0 = 0x0000000000101125ull;
+    cpu->isar.id_aa64mmfr1 = 0x0000000010212122ull;
+    cpu->isar.id_aa64mmfr2 = 0x0000000000001011ull;
+    cpu->isar.id_aa64pfr0  = 0x1101110120111112ull; /* GIC filled in later */
+    cpu->isar.id_aa64pfr1  = 0x0000000000000020ull;
+    cpu->id_afr0       = 0x00000000;
+    cpu->isar.id_dfr0  = 0x15011099;
+    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 = 0x11011121;
+    cpu->isar.id_isar6 = 0x01100111;
+    cpu->isar.id_mmfr0 = 0x10201105;
+    cpu->isar.id_mmfr1 = 0x40000000;
+    cpu->isar.id_mmfr2 = 0x01260000;
+    cpu->isar.id_mmfr3 = 0x02122211;
+    cpu->isar.id_mmfr4 = 0x01021110;
+    cpu->isar.id_pfr0  = 0x21110131;
+    cpu->isar.id_pfr1  = 0x00010000; /* GIC filled in later */
+    cpu->isar.id_pfr2  = 0x00000011;
+    cpu->midr = 0x411FD402;          /* r1p2 */
+    cpu->revidr = 0;
+
+    /*
+     * The Neoverse-V1 r1p2 TRM lists 32-bit format CCSIDR_EL1 values,
+     * but also says it implements CCIDX, which means they should be
+     * 64-bit format. So we here use values which are based on the textual
+     * information in chapter 2 of the TRM (and on the fact that
+     * sets * associativity * linesize == cachesize).
+     *
+     * The 64-bit CCSIDR_EL1 format is:
+     *   [55:32] number of sets - 1
+     *   [23:3]  associativity - 1
+     *   [2:0]   log2(linesize) - 4
+     *           so 0 == 16 bytes, 1 == 32 bytes, 2 == 64 bytes, etc
+     *
+     * L1: 4-way set associative 64-byte line size, total size 64K,
+     * so sets is 256.
+     *
+     * L2: 8-way set associative, 64 byte line size, either 512K or 1MB.
+     * We pick 1MB, so this has 2048 sets.
+     *
+     * L3: No L3 (this matches the CLIDR_EL1 value).
+     */
+    cpu->ccsidr[0] = 0x000000ff0000001aull; /* 64KB L1 dcache */
+    cpu->ccsidr[1] = 0x000000ff0000001aull; /* 64KB L1 icache */
+    cpu->ccsidr[2] = 0x000007ff0000003aull; /* 1MB L2 cache */
+
+    /* From 3.2.115 SCTLR_EL3 */
+    cpu->reset_sctlr = 0x30c50838;
+
+    /* From 3.4.8 ICC_CTLR_EL3 and 3.4.23 ICH_VTR_EL2 */
+    cpu->gic_num_lrs = 4;
+    cpu->gic_vpribits = 5;
+    cpu->gic_vprebits = 5;
+    cpu->gic_pribits = 5;
+
+    /* From 3.5.1 AdvSIMD AArch64 register summary */
+    cpu->isar.mvfr0 = 0x10110222;
+    cpu->isar.mvfr1 = 0x13211111;
+    cpu->isar.mvfr2 = 0x00000043;
+
+    /* From 3.7.5 ID_AA64ZFR0_EL1 */
+    cpu->isar.id_aa64zfr0 = 0x0000100000100000;
+    cpu->sve_vq.supported = (1 << 0)  /* 128bit */
+                            | (1 << 1);  /* 256bit */
+
+    /* From 5.5.1 AArch64 PMU register summary */
+    cpu->isar.reset_pmcr_el0 = 0x41213000;
+
+    define_neoverse_v1_cp_reginfo(cpu);
+
+    aarch64_add_pauth_properties(obj);
+    aarch64_add_sve_properties(obj);
+}
+
 /*
  * -cpu max: a CPU with as many features enabled as our emulation supports.
  * The version of '-cpu max' for qemu-system-arm is defined in cpu32.c;
@@ -763,6 +890,7 @@ static const ARMCPUInfo aarch64_cpus[] = {
     { .name = "cortex-a76",         .initfn = aarch64_a76_initfn },
     { .name = "a64fx",              .initfn = aarch64_a64fx_initfn },
     { .name = "neoverse-n1",        .initfn = aarch64_neoverse_n1_initfn },
+    { .name = "neoverse-v1",        .initfn = aarch64_neoverse_v1_initfn },
 };
 
 static void aarch64_cpu_register_types(void)
-- 
2.34.1

Re: [PATCH 2/2] target/arm: Define neoverse-v1

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> Now that we have implemented support for FEAT_LSE2, we can define
> a CPU model for the Neoverse-V1, and enable it for the virt and
> sbsa-ref boards.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH 2/2] target/arm: Define neoverse-v1

[Richard Henderson]

On 7/4/23 15:06, Peter Maydell wrote:
> If you're checking the values against the TRM, note that the
> summary tables differ from the register description in the TRM
> for ID_AA64DFR0_EL1, ID_AA64ZFR0_EL1 and ID_PFR0_EL1: we
> trust the versions in the register descriptions. Also the
> MIDR value in the r1p2 TRM isn't updated from r1p1.
> The CCSIDR_EL1 values in the TRM unfortunately seem to be wrong:
> the comment in the patch describes how I've calculated the
> values used here.
...
> +    cpu->isar.id_aa64mmfr2 = 0x0000000000001011ull;

I see 0x0220011102101011, not in your list of exceptions above.

Otherwise,
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~

Re: [PATCH 2/2] target/arm: Define neoverse-v1

[Peter Maydell]

On Wed, 5 Jul 2023 at 15:09, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 7/4/23 15:06, Peter Maydell wrote:
> > If you're checking the values against the TRM, note that the
> > summary tables differ from the register description in the TRM
> > for ID_AA64DFR0_EL1, ID_AA64ZFR0_EL1 and ID_PFR0_EL1: we
> > trust the versions in the register descriptions. Also the
> > MIDR value in the r1p2 TRM isn't updated from r1p1.
> > The CCSIDR_EL1 values in the TRM unfortunately seem to be wrong:
> > the comment in the patch describes how I've calculated the
> > values used here.
> ...
> > +    cpu->isar.id_aa64mmfr2 = 0x0000000000001011ull;
>
> I see 0x0220011102101011, not in your list of exceptions above.

Good catch -- I must have cut-and-pasted the neoverse-n1
code and then forgotten to update that value in it.

-- PMM

Re: [PATCH 0/2] target/arm: Implement Cortex Neoverse-V1

[Marcin Juszkiewicz]

W dniu 4.07.2023 o 15:06, Peter Maydell pisze:

> This patchset implements the Cortex Neoverse-V1 CPU type, as a
> representative Armv8.3 (+ some extras from 8.4) CPU matching real
> hardware.  The main thing we were waiting for to be able to define
> this was FEAT_LSE2, and that is now supported.

Now I can add "reach SBSA level 4" to todo list as it requires v8.3 cpu 
(I do not count 'max' cpu type).

Tested-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>

Re: [PATCH 0/2] target/arm: Implement Cortex Neoverse-V1

[Philippe Mathieu-Daudé]

On 4/7/23 15:35, Marcin Juszkiewicz wrote:
> W dniu 4.07.2023 o 15:06, Peter Maydell pisze:
> 
>> This patchset implements the Cortex Neoverse-V1 CPU type, as a
>> representative Armv8.3 (+ some extras from 8.4) CPU matching real
>> hardware.  The main thing we were waiting for to be able to define
>> this was FEAT_LSE2, and that is now supported.
> 
> Now I can add "reach SBSA level 4" to todo list as it requires v8.3 cpu 
> (I do not count 'max' cpu type).

Do we need to introduce machine variants, such sbsa-lvl3-ref and
sbsa-lvl4-ref? Or simply sbsa-level3/sbsa-level4?

Re: [PATCH 0/2] target/arm: Implement Cortex Neoverse-V1

[Marcin Juszkiewicz]

W dniu 4.07.2023 o 16:54, Philippe Mathieu-Daudé pisze:
> On 4/7/23 15:35, Marcin Juszkiewicz wrote:
>> W dniu 4.07.2023 o 15:06, Peter Maydell pisze:
>>
>>> This patchset implements the Cortex Neoverse-V1 CPU type, as a
>>> representative Armv8.3 (+ some extras from 8.4) CPU matching real
>>> hardware.  The main thing we were waiting for to be able to define
>>> this was FEAT_LSE2, and that is now supported.
>>
>> Now I can add "reach SBSA level 4" to todo list as it requires v8.3 
>> cpu (I do not count 'max' cpu type).
> 
> Do we need to introduce machine variants, such sbsa-lvl3-ref and
> sbsa-lvl4-ref? Or simply sbsa-level3/sbsa-level4?

No such combinations. The plan for sbsa-ref is to have only one platform.

Version of platform is exported in DeviceTree already. TF-A reads it and 
exports via SMC call to EDK2. What changes between versions is present 
in documentation.

Re: [PATCH 0/2] target/arm: Implement Cortex Neoverse-V1

[Philippe Mathieu-Daudé]

On 4/7/23 17:00, Marcin Juszkiewicz wrote:
> W dniu 4.07.2023 o 16:54, Philippe Mathieu-Daudé pisze:
>> On 4/7/23 15:35, Marcin Juszkiewicz wrote:
>>> W dniu 4.07.2023 o 15:06, Peter Maydell pisze:
>>>
>>>> This patchset implements the Cortex Neoverse-V1 CPU type, as a
>>>> representative Armv8.3 (+ some extras from 8.4) CPU matching real
>>>> hardware.  The main thing we were waiting for to be able to define
>>>> this was FEAT_LSE2, and that is now supported.
>>>
>>> Now I can add "reach SBSA level 4" to todo list as it requires v8.3 
>>> cpu (I do not count 'max' cpu type).
>>
>> Do we need to introduce machine variants, such sbsa-lvl3-ref and
>> sbsa-lvl4-ref? Or simply sbsa-level3/sbsa-level4?
> 
> No such combinations. The plan for sbsa-ref is to have only one platform.
> 
> Version of platform is exported in DeviceTree already. TF-A reads it and 
> exports via SMC call to EDK2. What changes between versions is present 
> in documentation.

Great! I like simplicity :)