[Top][All Lists]

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]