Richard Henderson <richard.hender...@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
