1. Patchew
  2. QEMU
  3. View series

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

Alex Bennée posted 1 patch 4 years, 9 months ago
Test s390x passed
Test docker-clang@ubuntu passed
Test asan passed
Test docker-mingw@fedora passed
Test FreeBSD passed
Test checkpatch passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20190723113301.16867-1-alex.bennee@linaro.org
There is a newer version of this series
target/arm/cpu.h   | 6 ++++++
target/arm/cpu64.c | 6 ++++++
2 files changed, 12 insertions(+)
[Qemu-devel] [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
Posted by Alex Bennée 4 years, 9 months ago 
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 telling kernels the ID
registers should tell them everything they need to know.

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

---
v2
  - don't leak QEMU version into ID reg
---
 target/arm/cpu.h   | 6 ++++++
 target/arm/cpu64.c | 6 ++++++
 2 files changed, 12 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..e88aadfd2fd 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -296,6 +296,12 @@ 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 = FIELD_DP64(0, MIDR_EL1, IMPLEMENTER, 0); /* Reserved for SW */
+        t = FIELD_DP64(t, MIDR_EL1, ARCHITECTURE, 0xf); /* See ID_* for details */
+        /* the rest is enigmatically empty lest kernels assume it means something */
+        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: [Qemu-devel] [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
Posted by Peter Maydell 4 years, 9 months ago 
On Tue, 23 Jul 2019 at 12:33, 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 telling kernels the ID
> registers should tell them everything they need to know.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>
> ---
> v2
>   - don't leak QEMU version into ID reg
> ---
>  target/arm/cpu.h   | 6 ++++++
>  target/arm/cpu64.c | 6 ++++++
>  2 files changed, 12 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)

"VARIANT".

> +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..e88aadfd2fd 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -296,6 +296,12 @@ 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 = FIELD_DP64(0, MIDR_EL1, IMPLEMENTER, 0); /* Reserved for SW */
> +        t = FIELD_DP64(t, MIDR_EL1, ARCHITECTURE, 0xf); /* See ID_* for details */
> +        /* the rest is enigmatically empty lest kernels assume it means something */
> +        cpu->midr = t;

I think this would be easier to read if you used one big block
comment rather than being extremely terse so as to fit the
comments on the end of the lines:

 /*
  * 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 leave them all at zero.
  */

It's also a bit inconsistent to do an explicit deposit of 0
for the IMPLEMENTER field but not for the VARIANT/PARTNUM/REVISION.

I wonder if we should put 0x51 (ascii 'Q') in the PARTNUM field;
then if somebody really needs to distinguish QEMU from random
other software-models they have a way to do it.

thanks
-- PMM
Re: [Qemu-devel] [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
Posted by Alex Bennée 4 years, 9 months ago 
Peter Maydell <peter.maydell@linaro.org> writes:

> On Tue, 23 Jul 2019 at 12:33, 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 telling kernels the ID
>> registers should tell them everything they need to know.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>>
>> ---
>> v2
>>   - don't leak QEMU version into ID reg
>> ---
>>  target/arm/cpu.h   | 6 ++++++
>>  target/arm/cpu64.c | 6 ++++++
>>  2 files changed, 12 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)
>
> "VARIANT".
>
>> +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..e88aadfd2fd 100644
>> --- a/target/arm/cpu64.c
>> +++ b/target/arm/cpu64.c
>> @@ -296,6 +296,12 @@ 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 = FIELD_DP64(0, MIDR_EL1, IMPLEMENTER, 0); /* Reserved for SW */
>> +        t = FIELD_DP64(t, MIDR_EL1, ARCHITECTURE, 0xf); /* See ID_* for details */
>> +        /* the rest is enigmatically empty lest kernels assume it means something */
>> +        cpu->midr = t;
>
> I think this would be easier to read if you used one big block
> comment rather than being extremely terse so as to fit the
> comments on the end of the lines:
>
>  /*
>   * 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 leave them all at zero.
>   */
>
> It's also a bit inconsistent to do an explicit deposit of 0
> for the IMPLEMENTER field but not for the VARIANT/PARTNUM/REVISION.
>
> I wonder if we should put 0x51 (ascii 'Q') in the PARTNUM field;
> then if somebody really needs to distinguish QEMU from random
> other software-models they have a way to do it.

Q is reserved for Qualcomm - It would be nice if ARM could assign QEMU a
code but I suspect that's not part of the business model.

>
> thanks
> -- PMM


--
Alex Bennée
Re: [Qemu-devel] [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
Posted by Laurent Desnogues 4 years, 9 months ago 
On Fri, Jul 26, 2019 at 9:24 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Tue, 23 Jul 2019 at 12:33, Alex Bennée <alex.bennee@linaro.org> wrote:
[...]
> >  /*
> >   * 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 leave them all at zero.
> >   */
> >
> > It's also a bit inconsistent to do an explicit deposit of 0
> > for the IMPLEMENTER field but not for the VARIANT/PARTNUM/REVISION.
> >
> > I wonder if we should put 0x51 (ascii 'Q') in the PARTNUM field;
> > then if somebody really needs to distinguish QEMU from random
> > other software-models they have a way to do it.
>
> Q is reserved for Qualcomm - It would be nice if ARM could assign QEMU a
> code but I suspect that's not part of the business model.

That was my reaction at first too, but that Q is reserved for the
Implementer field, while Peter is proposing to put it in the PartNum
field :-)

Laurent
Re: [Qemu-devel] [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
Posted by Peter Maydell 4 years, 9 months ago 
On Fri, 26 Jul 2019 at 08:37, Laurent Desnogues
<laurent.desnogues@gmail.com> wrote:
> On Fri, Jul 26, 2019 at 9:24 AM Alex Bennée <alex.bennee@linaro.org> wrote:
> > Peter Maydell <peter.maydell@linaro.org> writes:
> > > I wonder if we should put 0x51 (ascii 'Q') in the PARTNUM field;
> > > then if somebody really needs to distinguish QEMU from random
> > > other software-models they have a way to do it.
> >
> > Q is reserved for Qualcomm - It would be nice if ARM could assign QEMU a
> > code but I suspect that's not part of the business model.
>
> That was my reaction at first too, but that Q is reserved for the
> Implementer field, while Peter is proposing to put it in the PartNum
> field :-)

Yes; I should have been a bit clearer... This is totally ad-hoc,
of course, and I have no idea what other models might be using
IMPLEMENTER==0, but it seems harmless enough and it might come
in useful someday.

thanks
-- PMM

Patchew 2.1-devel-0870f84

© 2016 - 2024 Red Hat, Inc.