lkml.org 
[lkml]   [2019]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] arm64: Introduce ISAR6 CPU ID register
From
Date
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.

Cheers
Suzuki

\
 
 \ /
  Last update: 2019-12-12 16:23    [W:0.049 / U:3.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site