v8.1M cpu emulation and target-arm feature-identification strategy

v8.1M cpu emulation and target-arm feature-identification strategy

[Peter Maydell]

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

Re: v8.1M cpu emulation and target-arm feature-identification strategy

[Philippe Mathieu-Daudé]

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
> 

Re: v8.1M cpu emulation and target-arm feature-identification strategy

[Richard Henderson]

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~

Re: v8.1M cpu emulation and target-arm feature-identification strategy

[Alex Bennée]

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

Re: v8.1M cpu emulation and target-arm feature-identification strategy

[Peter Maydell]

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

Re: v8.1M cpu emulation and target-arm feature-identification strategy

[Richard Henderson]

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~

Re: v8.1M cpu emulation and target-arm feature-identification strategy

[Peter Maydell]

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

Re: v8.1M cpu emulation and target-arm feature-identification strategy

[Peter Maydell]

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