Re: [PATCH] arm64: Introduce ISAR6 CPU ID register

[Anshuman Khandual]

On 12/12/2019 08:52 PM, Suzuki Kuruppassery Poulose wrote:
> On 12/12/2019 14:46, Mark Rutland wrote:
>> On Thu, Dec 12, 2019 at 03:44:23PM +0530, Anshuman Khandual wrote:
>>> +#define ID_ISAR6_JSCVT_SHIFTÂÂÂÂÂÂÂ 0
>>> +#define ID_ISAR6_DP_SHIFTÂÂÂÂÂÂÂ 4
>>> +#define ID_ISAR6_FHM_SHIFTÂÂÂÂÂÂÂ 8
>>> +#define ID_ISAR6_SB_SHIFTÂÂÂÂÂÂÂ 12
>>> +#define ID_ISAR6_SPECRES_SHIFTÂÂÂÂÂÂÂ 16
>>> +#define ID_ISAR6_BF16_SHIFTÂÂÂÂÂÂÂ 20
>>> +#define ID_ISAR6_I8MM_SHIFTÂÂÂÂÂÂÂ 24
>>
>>> @@ -399,6 +399,7 @@ static const struct __ftr_reg_entry {
>>> ÂÂÂÂÂ ARM64_FTR_REG(SYS_ID_ISAR4_EL1, ftr_generic_32bits),
>>> ÂÂÂÂÂ ARM64_FTR_REG(SYS_ID_ISAR5_EL1, ftr_id_isar5),
>>> ÂÂÂÂÂ ARM64_FTR_REG(SYS_ID_MMFR4_EL1, ftr_id_mmfr4),
>>
>>> +ÂÂÂ ARM64_FTR_REG(SYS_ID_ISAR6_EL1, ftr_generic_32bits),
>>
>> Using ftr_generic_32bits exposes the lowest-common-denominator for all
>> 4-bit fields in the register, and I don't think that's the right thing
>> to do here, because:
>>
>> * We have no idea what ID_ISAR6 bits [31:28] may mean in future.
>>
>> * AFAICT, the instructions described by ID_ISAR6.SPECRES (from the
>> ÂÂ ARMv8.0-PredInv extension) operate on the local PE and are not
>> ÂÂ broadcast. To make those work as a guest expects, the host will need
>> ÂÂ to do additional things (e.g. to preserve that illusion when a vCPU is
>> ÂÂ migrated from one pCPU to another and back).
>>
>> Given that, think we should add an explicit ftr_id_isar6 which only
>> exposes the fields that we're certain are safe to expose to a guest
>> (i.e. without SPECRES).
> 
> Agree. Thanks for pointing this out. I recommended the usage of
> generic_32bits table without actually looking at the feature
> definitions.
> 
> Anshuman,
> 
> Sorry about this.

Not a problem, will add an explicit definition for ftr_id_isar6 with
all features except SPECRES as Mark had pointed put.

> 
> Cheers
> Suzuki