* v8.1M cpu emulation and target-arm feature-identification strategy
@ 2020-08-05 11:08 Peter Maydell
2020-08-05 12:22 ` Philippe Mathieu-Daudé
2020-08-05 16:13 ` Richard Henderson
0 siblings, 2 replies; 8+ messages in thread
From: Peter Maydell @ 2020-08-05 11:08 UTC (permalink / raw)
To: QEMU Developers, qemu-arm, Richard Henderson, Alex Bennée
Mostly recently we've been aiming for QEMU emulation code in
target/arm to use ID register fields to determine whether a
feature is present or not (the isar_feature_* functions) rather
than the old style of defining ARM_FEATURE_* flags. This seems to
be working out well for A-profile. However, for v8.1M there are
a small handful of minor behaviour differences which don't have an
associated ID register field, but which are instead in the spec
and pseudocode just called out as "if this is a v8.1M CPU".
(The major v8.1M new features do have ID register fields.)
I can think of two ways to handle this:
(1) define an ARM_FEATURE_V81M flag
(2) define an isar_feature_aa32_v81m() function which under the
hood is actually testing for a specific feature which happens
to be known to be always present in v8.1M, like low-overhead-branches
(ie ID_ISAR0.CmpBranch >=3)
Any preferences ?
thanks
-- PMM
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: v8.1M cpu emulation and target-arm feature-identification strategy
2020-08-05 11:08 v8.1M cpu emulation and target-arm feature-identification strategy Peter Maydell
@ 2020-08-05 12:22 ` Philippe Mathieu-Daudé
2020-08-05 16:13 ` Richard Henderson
1 sibling, 0 replies; 8+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-05 12:22 UTC (permalink / raw)
To: Peter Maydell, QEMU Developers, qemu-arm, Richard Henderson,
Alex Bennée
On 8/5/20 1:08 PM, Peter Maydell wrote:
> Mostly recently we've been aiming for QEMU emulation code in
> target/arm to use ID register fields to determine whether a
> feature is present or not (the isar_feature_* functions) rather
> than the old style of defining ARM_FEATURE_* flags. This seems to
> be working out well for A-profile. However, for v8.1M there are
> a small handful of minor behaviour differences which don't have an
> associated ID register field, but which are instead in the spec
> and pseudocode just called out as "if this is a v8.1M CPU".
> (The major v8.1M new features do have ID register fields.)
>
> I can think of two ways to handle this:
> (1) define an ARM_FEATURE_V81M flag
> (2) define an isar_feature_aa32_v81m() function which under the
> hood is actually testing for a specific feature which happens
> to be known to be always present in v8.1M, like low-overhead-branches
> (ie ID_ISAR0.CmpBranch >=3)
FWIW finding myself sometime git-grepping 'isar_feature' I'd rather
choose (2), even if there is no such v8.1M ID register field.
That said, my end-user preference isn't very important compared to
the developer/maintainer one.
>
> Any preferences ?
>
> thanks
> -- PMM
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: v8.1M cpu emulation and target-arm feature-identification strategy
2020-08-05 11:08 v8.1M cpu emulation and target-arm feature-identification strategy Peter Maydell
2020-08-05 12:22 ` Philippe Mathieu-Daudé
@ 2020-08-05 16:13 ` Richard Henderson
2020-08-05 16:45 ` Alex Bennée
1 sibling, 1 reply; 8+ messages in thread
From: Richard Henderson @ 2020-08-05 16:13 UTC (permalink / raw)
To: Peter Maydell, QEMU Developers, qemu-arm, Alex Bennée
On 8/5/20 4:08 AM, Peter Maydell wrote:
> Mostly recently we've been aiming for QEMU emulation code in
> target/arm to use ID register fields to determine whether a
> feature is present or not (the isar_feature_* functions) rather
> than the old style of defining ARM_FEATURE_* flags. This seems to
> be working out well for A-profile. However, for v8.1M there are
> a small handful of minor behaviour differences which don't have an
> associated ID register field, but which are instead in the spec
> and pseudocode just called out as "if this is a v8.1M CPU".
> (The major v8.1M new features do have ID register fields.)
>
> I can think of two ways to handle this:
> (1) define an ARM_FEATURE_V81M flag
> (2) define an isar_feature_aa32_v81m() function which under the
> hood is actually testing for a specific feature which happens
> to be known to be always present in v8.1M, like low-overhead-branches
> (ie ID_ISAR0.CmpBranch >=3)
I think (2) has the potential to be confusing in odd ways. If there really is
no official flag for this, I think we should use (1).
r~
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: v8.1M cpu emulation and target-arm feature-identification strategy
2020-08-05 16:13 ` Richard Henderson
@ 2020-08-05 16:45 ` Alex Bennée
2020-08-05 16:52 ` Peter Maydell
0 siblings, 1 reply; 8+ messages in thread
From: Alex Bennée @ 2020-08-05 16:45 UTC (permalink / raw)
To: Richard Henderson; +Cc: Peter Maydell, qemu-arm, QEMU Developers
Richard Henderson <richard.henderson@linaro.org> writes:
> On 8/5/20 4:08 AM, Peter Maydell wrote:
>> Mostly recently we've been aiming for QEMU emulation code in
>> target/arm to use ID register fields to determine whether a
>> feature is present or not (the isar_feature_* functions) rather
>> than the old style of defining ARM_FEATURE_* flags. This seems to
>> be working out well for A-profile. However, for v8.1M there are
>> a small handful of minor behaviour differences which don't have an
>> associated ID register field, but which are instead in the spec
>> and pseudocode just called out as "if this is a v8.1M CPU".
>> (The major v8.1M new features do have ID register fields.)
>>
>> I can think of two ways to handle this:
>> (1) define an ARM_FEATURE_V81M flag
>> (2) define an isar_feature_aa32_v81m() function which under the
>> hood is actually testing for a specific feature which happens
>> to be known to be always present in v8.1M, like low-overhead-branches
>> (ie ID_ISAR0.CmpBranch >=3)
>
> I think (2) has the potential to be confusing in odd ways. If there really is
> no official flag for this, I think we should use (1).
I wouldn't test other feature bits but what stopping us adding:
struct ARMISARegisters {
uint32_t id_isar0;
...
uint64_t id_aa64dfr1;
/*
* The following are synthetic flags for features not exposed to
* the directly exposed to the guest but needed by QEMU's
* feature detection.
*/
bool v81m_lob;
} isar;
And having the normal:
static inline bool isar_feature_aa32_v81m_lob(const ARMISARegisters *id)
{
return id->v81m_lob;
}
That said we still seem to have a number of ARM_FEATURE flags, are we
hoping they all go away eventually?
>
>
> r~
--
Alex Bennée
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: v8.1M cpu emulation and target-arm feature-identification strategy
2020-08-05 16:45 ` Alex Bennée
@ 2020-08-05 16:52 ` Peter Maydell
2020-08-05 17:00 ` Richard Henderson
0 siblings, 1 reply; 8+ messages in thread
From: Peter Maydell @ 2020-08-05 16:52 UTC (permalink / raw)
To: Alex Bennée; +Cc: qemu-arm, Richard Henderson, QEMU Developers
On Wed, 5 Aug 2020 at 17:45, Alex Bennée <alex.bennee@linaro.org> wrote:
> I wouldn't test other feature bits but what stopping us adding:
>
> struct ARMISARegisters {
> uint32_t id_isar0;
> ...
> uint64_t id_aa64dfr1;
> /*
> * The following are synthetic flags for features not exposed to
> * the directly exposed to the guest but needed by QEMU's
> * feature detection.
> */
> bool v81m_lob;
> } isar;
Nothing, except we already have a set of synthetic flags, that's
what the ARM_FEATURE_* are...
> That said we still seem to have a number of ARM_FEATURE flags, are we
> hoping they all go away eventually?
I think that they're a mixed bag. Some represent cleanups we
haven't got round to doing yet (eg ARM_FEATURE_NEON, which would
be a fair chunk of work, or ARM_FEATURE_PXN which would be pretty
trivial to change to looking at ID_MMFR0.VMSA >=4). Some are
features that pre-date the ID feature bit scheme and so might
be awkward to convert (eg ARM_FEATURE_XSCALE). One or two
we've already converted and just forgot to take out of the
enum (eg ARM_FEATURE_CRC)...
thanks
-- PMM
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: v8.1M cpu emulation and target-arm feature-identification strategy
2020-08-05 16:52 ` Peter Maydell
@ 2020-08-05 17:00 ` Richard Henderson
2020-08-05 19:02 ` Peter Maydell
2020-08-05 19:16 ` Peter Maydell
0 siblings, 2 replies; 8+ messages in thread
From: Richard Henderson @ 2020-08-05 17:00 UTC (permalink / raw)
To: Peter Maydell, Alex Bennée; +Cc: qemu-arm, QEMU Developers
On 8/5/20 9:52 AM, Peter Maydell wrote:
> On Wed, 5 Aug 2020 at 17:45, Alex Bennée <alex.bennee@linaro.org> wrote:
>> I wouldn't test other feature bits but what stopping us adding:
>>
>> struct ARMISARegisters {
>> uint32_t id_isar0;
>> ...
>> uint64_t id_aa64dfr1;
>> /*
>> * The following are synthetic flags for features not exposed to
>> * the directly exposed to the guest but needed by QEMU's
>> * feature detection.
>> */
>> bool v81m_lob;
>> } isar;
>
> Nothing, except we already have a set of synthetic flags, that's
> what the ARM_FEATURE_* are...
>
>> That said we still seem to have a number of ARM_FEATURE flags, are we
>> hoping they all go away eventually?
>
> I think that they're a mixed bag. Some represent cleanups we
> haven't got round to doing yet (eg ARM_FEATURE_NEON, which would
> be a fair chunk of work, or ARM_FEATURE_PXN which would be pretty
> trivial to change to looking at ID_MMFR0.VMSA >=4). Some are
> features that pre-date the ID feature bit scheme and so might
> be awkward to convert (eg ARM_FEATURE_XSCALE). One or two
> we've already converted and just forgot to take out of the
> enum (eg ARM_FEATURE_CRC)...
I've always assumed we'd never get rid of all of them.
Older ones like XSCALE are obvious, but I don't think there's a clear indicator
for V{5,6,7,8} either.
r~
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: v8.1M cpu emulation and target-arm feature-identification strategy
2020-08-05 17:00 ` Richard Henderson
@ 2020-08-05 19:02 ` Peter Maydell
2020-08-05 19:16 ` Peter Maydell
1 sibling, 0 replies; 8+ messages in thread
From: Peter Maydell @ 2020-08-05 19:02 UTC (permalink / raw)
To: Richard Henderson; +Cc: qemu-arm, Alex Bennée, QEMU Developers
On Wed, 5 Aug 2020 at 18:00, Richard Henderson
<richard.henderson@linaro.org> wrote:
> I've always assumed we'd never get rid of all of them.
>
> Older ones like XSCALE are obvious, but I don't think there's a clear indicator
> for V{5,6,7,8} either.
MIDR.Architecture lets you distinguish v4/v4T/v5/v5T/v5TE/v5TEJ/v6,
and there are also some separate per-feature ID register fields for
things which we currently hang off those ARM_FEATURE_Vx flags.
In theory all the v7-and-later stuff should have its own ID register
field...
Regardless, it's hard to see a clear benefit from a hypothetical
concerted effort to convert all the ARM_FEATURE_* uses to ID
register checks, though we might choose to convert a few here
and there if we need to overhaul the code anyway.
thanks
-- PMM
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: v8.1M cpu emulation and target-arm feature-identification strategy
2020-08-05 17:00 ` Richard Henderson
2020-08-05 19:02 ` Peter Maydell
@ 2020-08-05 19:16 ` Peter Maydell
1 sibling, 0 replies; 8+ messages in thread
From: Peter Maydell @ 2020-08-05 19:16 UTC (permalink / raw)
To: Richard Henderson; +Cc: qemu-arm, Alex Bennée, QEMU Developers
On Wed, 5 Aug 2020 at 18:00, Richard Henderson
<richard.henderson@linaro.org> wrote:
> Older ones like XSCALE are obvious
Looking at the XScale manual we could actually implement
ARM_FEATURE_XSCALE as (cpu->midr & 0xffff0000 == 0x69050000)
[Vendor=intel, arch=ARMv5TE], and ARM_FEATURE_IWMMXT as
(cpu->midr & 0xffffe000 == 0x69054000) [Vendor=intel,
arch=ARMv5TE, Core Generation=2]... Doesn't really gain
us much, of course :-)
thanks
-- PMM
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-08-05 19:17 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-05 11:08 v8.1M cpu emulation and target-arm feature-identification strategy Peter Maydell
2020-08-05 12:22 ` Philippe Mathieu-Daudé
2020-08-05 16:13 ` Richard Henderson
2020-08-05 16:45 ` Alex Bennée
2020-08-05 16:52 ` Peter Maydell
2020-08-05 17:00 ` Richard Henderson
2020-08-05 19:02 ` Peter Maydell
2020-08-05 19:16 ` 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.