[RFC PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max

[RFC PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max

[Alex Bennée]

While most features are now detected by probing the ID_* registers
kernels can (and do) use MIDR_EL1 for working out of they have to
apply errata. This can trip up warnings in the kernel as it tries to
work out if it should apply workarounds to features that don't
actually exist in the reported CPU type.

Avoid this problem by synthesising our own MIDR value using the
reserved value of 0 for the implementer and encoding the moving feast
that is the QEMU version string into the other fields.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 target/arm/cpu.h   |  6 ++++++
 target/arm/cpu64.c | 10 ++++++++++
 2 files changed, 16 insertions(+)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 7efbb488d9d..61eaef924e4 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1605,6 +1605,12 @@ FIELD(V7M_FPCCR, ASPEN, 31, 1)
 /*
  * System register ID fields.
  */
+FIELD(MIDR_EL1, REVISION, 0, 4)
+FIELD(MIDR_EL1, PARTNUM, 4, 12)
+FIELD(MIDR_EL1, ARCHITECTURE, 16, 4)
+FIELD(MIDR_EL1, VARIENT, 20, 4)
+FIELD(MIDR_EL1, IMPLEMENTER, 24, 8)
+
 FIELD(ID_ISAR0, SWAP, 0, 4)
 FIELD(ID_ISAR0, BITCOUNT, 4, 4)
 FIELD(ID_ISAR0, BITFIELD, 8, 4)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index b1bb394c6dd..c121d0b37e0 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -296,6 +296,16 @@ static void aarch64_max_initfn(Object *obj)
         uint32_t u;
         aarch64_a57_initfn(obj);
 
+        /* reset MIDR so our franken-max-cpu type isn't mistaken for a real one */
+        t = 0;
+        t = FIELD_DP64(t, MIDR_EL1, IMPLEMENTER, 0); /* Reserved for SW */
+        t = FIELD_DP64(t, MIDR_EL1, ARCHITECTURE, 0xf); /* See ID_* for details */
+        /* Encode QEMU version details */
+        t = FIELD_DP64(t, MIDR_EL1, VARIENT, QEMU_VERSION_MAJOR);
+        t = FIELD_DP64(t, MIDR_EL1, REVISION, QEMU_VERSION_MINOR);
+        t = FIELD_DP64(t, MIDR_EL1, PARTNUM, QEMU_VERSION_MICRO);
+        cpu->midr = t;
+
         t = cpu->isar.id_aa64isar0;
         t = FIELD_DP64(t, ID_AA64ISAR0, AES, 2); /* AES + PMULL */
         t = FIELD_DP64(t, ID_AA64ISAR0, SHA1, 1);
-- 
2.20.1

[Qemu-devel] [RFC PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max

[Alex Bennée]

While most features are now detected by probing the ID_* registers
kernels can (and do) use MIDR_EL1 for working out of they have to
apply errata. This can trip up warnings in the kernel as it tries to
work out if it should apply workarounds to features that don't
actually exist in the reported CPU type.

Avoid this problem by synthesising our own MIDR value using the
reserved value of 0 for the implementer and encoding the moving feast
that is the QEMU version string into the other fields.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 target/arm/cpu.h   |  6 ++++++
 target/arm/cpu64.c | 10 ++++++++++
 2 files changed, 16 insertions(+)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 7efbb488d9d..61eaef924e4 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1605,6 +1605,12 @@ FIELD(V7M_FPCCR, ASPEN, 31, 1)
 /*
  * System register ID fields.
  */
+FIELD(MIDR_EL1, REVISION, 0, 4)
+FIELD(MIDR_EL1, PARTNUM, 4, 12)
+FIELD(MIDR_EL1, ARCHITECTURE, 16, 4)
+FIELD(MIDR_EL1, VARIENT, 20, 4)
+FIELD(MIDR_EL1, IMPLEMENTER, 24, 8)
+
 FIELD(ID_ISAR0, SWAP, 0, 4)
 FIELD(ID_ISAR0, BITCOUNT, 4, 4)
 FIELD(ID_ISAR0, BITFIELD, 8, 4)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index b1bb394c6dd..c121d0b37e0 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -296,6 +296,16 @@ static void aarch64_max_initfn(Object *obj)
         uint32_t u;
         aarch64_a57_initfn(obj);
 
+        /* reset MIDR so our franken-max-cpu type isn't mistaken for a real one */
+        t = 0;
+        t = FIELD_DP64(t, MIDR_EL1, IMPLEMENTER, 0); /* Reserved for SW */
+        t = FIELD_DP64(t, MIDR_EL1, ARCHITECTURE, 0xf); /* See ID_* for details */
+        /* Encode QEMU version details */
+        t = FIELD_DP64(t, MIDR_EL1, VARIENT, QEMU_VERSION_MAJOR);
+        t = FIELD_DP64(t, MIDR_EL1, REVISION, QEMU_VERSION_MINOR);
+        t = FIELD_DP64(t, MIDR_EL1, PARTNUM, QEMU_VERSION_MICRO);
+        cpu->midr = t;
+
         t = cpu->isar.id_aa64isar0;
         t = FIELD_DP64(t, ID_AA64ISAR0, AES, 2); /* AES + PMULL */
         t = FIELD_DP64(t, ID_AA64ISAR0, SHA1, 1);
-- 
2.20.1

Re: [RFC PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max

[Peter Maydell]

On Mon, 22 Jul 2019 at 12:19, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> While most features are now detected by probing the ID_* registers
> kernels can (and do) use MIDR_EL1 for working out of they have to
> apply errata. This can trip up warnings in the kernel as it tries to
> work out if it should apply workarounds to features that don't
> actually exist in the reported CPU type.
>
> Avoid this problem by synthesising our own MIDR value using the
> reserved value of 0 for the implementer and encoding the moving feast
> that is the QEMU version string into the other fields.

Exposing the QEMU_VERSION_* information to the guest is
usually not a good plan. For instance it means that the
MIDR will mysteriously change if you save a VM on one
version of QEMU and restore it on another. We went through
a while back carefully removing places where we'd exposed
the version number to the guest (have a look at the
qemu_hw_version() stuff which has to jump through hoops
so that old versioned machines like pc-1.5 report the
old "1.5" version number, and any QEMU 2.5 and above
now reports "2.5+"...)

thanks
-- PMM

Re: [Qemu-devel] [RFC PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max

[Peter Maydell]

On Mon, 22 Jul 2019 at 12:19, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> While most features are now detected by probing the ID_* registers
> kernels can (and do) use MIDR_EL1 for working out of they have to
> apply errata. This can trip up warnings in the kernel as it tries to
> work out if it should apply workarounds to features that don't
> actually exist in the reported CPU type.
>
> Avoid this problem by synthesising our own MIDR value using the
> reserved value of 0 for the implementer and encoding the moving feast
> that is the QEMU version string into the other fields.

Exposing the QEMU_VERSION_* information to the guest is
usually not a good plan. For instance it means that the
MIDR will mysteriously change if you save a VM on one
version of QEMU and restore it on another. We went through
a while back carefully removing places where we'd exposed
the version number to the guest (have a look at the
qemu_hw_version() stuff which has to jump through hoops
so that old versioned machines like pc-1.5 report the
old "1.5" version number, and any QEMU 2.5 and above
now reports "2.5+"...)

thanks
-- PMM

Re: [RFC PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max

[Alex Bennée]

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

> On Mon, 22 Jul 2019 at 12:19, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> While most features are now detected by probing the ID_* registers
>> kernels can (and do) use MIDR_EL1 for working out of they have to
>> apply errata. This can trip up warnings in the kernel as it tries to
>> work out if it should apply workarounds to features that don't
>> actually exist in the reported CPU type.
>>
>> Avoid this problem by synthesising our own MIDR value using the
>> reserved value of 0 for the implementer and encoding the moving feast
>> that is the QEMU version string into the other fields.
>
> Exposing the QEMU_VERSION_* information to the guest is
> usually not a good plan. For instance it means that the
> MIDR will mysteriously change if you save a VM on one
> version of QEMU and restore it on another.

Given the mutability of -cpu max that is probably a good thing?

> We went through
> a while back carefully removing places where we'd exposed
> the version number to the guest (have a look at the
> qemu_hw_version() stuff which has to jump through hoops
> so that old versioned machines like pc-1.5 report the
> old "1.5" version number, and any QEMU 2.5 and above
> now reports "2.5+"...)

Well I guess we could do:

  cpu->midr = FIELD_DP64(0, MIDR_EL1, ARCHITECTURE, 0xf)

but any kernel that attempts to apply fixups for a 0x0 implementer is
asking for trouble anyway. I assume it's unlikely ARM would assign QEMU
an implementer code!

>
> thanks
> -- PMM


--
Alex Bennée

Re: [Qemu-devel] [RFC PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max

[Alex Bennée]

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

> On Mon, 22 Jul 2019 at 12:19, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> While most features are now detected by probing the ID_* registers
>> kernels can (and do) use MIDR_EL1 for working out of they have to
>> apply errata. This can trip up warnings in the kernel as it tries to
>> work out if it should apply workarounds to features that don't
>> actually exist in the reported CPU type.
>>
>> Avoid this problem by synthesising our own MIDR value using the
>> reserved value of 0 for the implementer and encoding the moving feast
>> that is the QEMU version string into the other fields.
>
> Exposing the QEMU_VERSION_* information to the guest is
> usually not a good plan. For instance it means that the
> MIDR will mysteriously change if you save a VM on one
> version of QEMU and restore it on another.

Given the mutability of -cpu max that is probably a good thing?

> We went through
> a while back carefully removing places where we'd exposed
> the version number to the guest (have a look at the
> qemu_hw_version() stuff which has to jump through hoops
> so that old versioned machines like pc-1.5 report the
> old "1.5" version number, and any QEMU 2.5 and above
> now reports "2.5+"...)

Well I guess we could do:

  cpu->midr = FIELD_DP64(0, MIDR_EL1, ARCHITECTURE, 0xf)

but any kernel that attempts to apply fixups for a 0x0 implementer is
asking for trouble anyway. I assume it's unlikely ARM would assign QEMU
an implementer code!

>
> thanks
> -- PMM


--
Alex Bennée