[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: v8.1M cpu emulation and target-arm feature-identification strategy
From: |
Richard Henderson |
Subject: |
Re: v8.1M cpu emulation and target-arm feature-identification strategy |
Date: |
Wed, 5 Aug 2020 10:00:50 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
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~