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

["Alex Bennée" <alex.bennee@linaro.org>]

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