* [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
@ 2019-07-23 11:33 ` Alex Bennée
0 siblings, 0 replies; 9+ messages in thread
From: Alex Bennée @ 2019-07-23 11:33 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-arm, Alex Bennée, Peter Maydell
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
^ permalink raw reply related [flat|nested] 9+ messages in thread* [Qemu-devel] [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
@ 2019-07-23 11:33 ` Alex Bennée
0 siblings, 0 replies; 9+ messages in thread
From: Alex Bennée @ 2019-07-23 11:33 UTC (permalink / raw)
To: qemu-devel; +Cc: Peter Maydell, qemu-arm, 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 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
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
2019-07-23 11:33 ` [Qemu-devel] " Alex Bennée
@ 2019-07-23 11:47 ` Peter Maydell
-1 siblings, 0 replies; 9+ messages in thread
From: Peter Maydell @ 2019-07-23 11:47 UTC (permalink / raw)
To: Alex Bennée; +Cc: QEMU Developers, qemu-arm
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
@ 2019-07-23 11:47 ` Peter Maydell
0 siblings, 0 replies; 9+ messages in thread
From: Peter Maydell @ 2019-07-23 11:47 UTC (permalink / raw)
To: Alex Bennée; +Cc: qemu-arm, QEMU Developers
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
2019-07-23 11:47 ` [Qemu-devel] " Peter Maydell
@ 2019-07-26 7:24 ` Alex Bennée
-1 siblings, 0 replies; 9+ messages in thread
From: Alex Bennée @ 2019-07-26 7:24 UTC (permalink / raw)
To: Peter Maydell; +Cc: QEMU Developers, qemu-arm
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
@ 2019-07-26 7:24 ` Alex Bennée
0 siblings, 0 replies; 9+ messages in thread
From: Alex Bennée @ 2019-07-26 7:24 UTC (permalink / raw)
To: Peter Maydell; +Cc: qemu-arm, QEMU Developers
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
2019-07-26 7:24 ` [Qemu-devel] " Alex Bennée
(?)
@ 2019-07-26 7:37 ` Laurent Desnogues
2019-07-26 8:44 ` Peter Maydell
-1 siblings, 1 reply; 9+ messages in thread
From: Laurent Desnogues @ 2019-07-26 7:37 UTC (permalink / raw)
To: Alex Bennée; +Cc: Peter Maydell, qemu-arm, QEMU Developers
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
2019-07-26 7:37 ` Laurent Desnogues
@ 2019-07-26 8:44 ` Peter Maydell
0 siblings, 0 replies; 9+ messages in thread
From: Peter Maydell @ 2019-07-26 8:44 UTC (permalink / raw)
To: Laurent Desnogues; +Cc: Alex Bennée, qemu-arm, QEMU Developers
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
@ 2019-07-26 8:44 ` Peter Maydell
0 siblings, 0 replies; 9+ messages in thread
From: Peter Maydell @ 2019-07-26 8:44 UTC (permalink / raw)
To: Laurent Desnogues; +Cc: qemu-arm, Alex Bennée, QEMU Developers
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-07-26 8:45 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-07-23 11:33 [PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max Alex Bennée
2019-07-23 11:33 ` [Qemu-devel] " Alex Bennée
2019-07-23 11:47 ` Peter Maydell
2019-07-23 11:47 ` [Qemu-devel] " Peter Maydell
2019-07-26 7:24 ` Alex Bennée
2019-07-26 7:24 ` [Qemu-devel] " Alex Bennée
2019-07-26 7:37 ` Laurent Desnogues
2019-07-26 8:44 ` Peter Maydell
2019-07-26 8:44 ` Peter Maydell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.