Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1241696 > unrolled thread

Re: [PATCH v2 07/22] arm64: Keep track of CPU feature registers

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 07/22] arm64: Keep track of CPU feature registers Catalin Marinas <catalin.marinas@arm.com> - 2015-10-07 19:20 +0200
    Re: [PATCH v2 07/22] arm64: Keep track of CPU feature registers "Suzuki K. Poulose" <Suzuki.Poulose@arm.com> - 2015-10-08 12:00 +0200
      Re: [PATCH v2 07/22] arm64: Keep track of CPU feature registers Catalin Marinas <catalin.marinas@arm.com> - 2015-10-08 17:10 +0200
        Re: [PATCH v2 07/22] arm64: Keep track of CPU feature registers "Suzuki K. Poulose" <Suzuki.Poulose@arm.com> - 2015-10-09 15:10 +0200
        Re: [PATCH v2 07/22] arm64: Keep track of CPU feature registers "Suzuki K. Poulose" <Suzuki.Poulose@arm.com> - 2015-10-12 19:10 +0200
          Re: [PATCH v2 07/22] arm64: Keep track of CPU feature registers Mark Rutland <mark.rutland@arm.com> - 2015-10-12 19:30 +0200
            Re: [PATCH v2 07/22] arm64: Keep track of CPU feature registers Catalin Marinas <catalin.marinas@arm.com> - 2015-10-13 11:50 +0200
      Re: [PATCH v2 07/22] arm64: Keep track of CPU feature registers "Suzuki K. Poulose" <Suzuki.Poulose@arm.com> - 2015-10-09 13:00 +0200
        Re: [PATCH v2 07/22] arm64: Keep track of CPU feature registers Catalin Marinas <catalin.marinas@arm.com> - 2015-10-09 16:20 +0200

#1241696 — Re: [PATCH v2 07/22] arm64: Keep track of CPU feature registers

On Mon, Oct 05, 2015 at 06:01:56PM +0100, Suzuki K. Poulose wrote:
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index b5f313d..7ed92f2 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -35,6 +35,38 @@
>  
>  #include <linux/kernel.h>
>  
> +/* CPU feature register tracking */
> +enum ftr_type {
> +	FTR_DISCRETE,	/* Use a predefined safe value */
> +	FTR_SCALAR_MIN,	/* Smaller value is safer */
> +	FTR_SCALAR_MAX,	/* Bigger value is safer */
> +};

I think s/safer/safe/ sounds better, otherwise it looks like we are not
entirely sure.

BTW, I don't fully understand the name choosing here (e.g. discrete vs.
scalar; a scalar type is also a discrete type). "MIN" looks to me like
any higher value should be safe but instead the comment states "smaller
value is safe". Maybe something like:

	FTR_EXACT
	FTR_LOWER_SAFE
	FTR_HIGHER_SAFE

> +
> +#define FTR_STRICT	true
> +#define FTR_NONSTRICT	false
> +
> +struct arm64_ftr_bits {
> +	bool		strict;		/* CPU Sanity check
> +					 *  strict matching required ? */

I don't care about 80 characters line, especially around comments. So
please place the comment on a single line.

> +	enum ftr_type	type;
> +	u8		shift;
> +	u8		width;
> +	s64		safe_val;	/* safe value for discrete features */
> +};
> +
> +/*
> + * @arm64_ftr_reg - Feature register
> + * @strict_mask 	Bits which should match across all CPUs for sanity.
> + * @sys_val		Safe value across the CPUs (system view)
> + */
> +struct arm64_ftr_reg {
> +	u32			sys_id;
> +	const char*		name;
> +	u64			strict_mask;
> +	u64			sys_val;
> +	struct arm64_ftr_bits*	ftr_bits;
> +};

Move '*' near the struct member names, not the type.

> +
>  struct arm64_cpu_capabilities {
>  	const char *desc;
>  	u16 capability;
> @@ -82,6 +114,22 @@ static inline int __attribute_const__ cpuid_feature_extract_field(u64 features,
>  	return (s64)(features << (64 - 4 - field)) >> (64 - 4);
>  }
>  
> +static inline s64 __attribute_const__
> +cpuid_feature_extract_field_width(u64 features, int field, u8 width)
> +{
> +	return (s64)(features << (64 - width - field)) >> (64 - width);
> +}

I think you should rewrite cpuid_feature_extract_field() in terms of the
_width one (the latter being more generic).

> +
> +static inline u64 ftr_mask(struct arm64_ftr_bits *ftrp)
> +{
> +	return (u64) GENMASK(ftrp->shift + ftrp->width - 1, ftrp->shift);
> +}

Nitpick: remove the space after (u64).

> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 1ae8b24..d42ad90 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -58,8 +58,442 @@ static void update_mixed_endian_el0_support(struct cpuinfo_arm64 *info)
>  	mixed_endian_el0 &= id_aa64mmfr0_mixed_endian_el0(info->reg_id_aa64mmfr0);
>  }
>  
> +#define ARM64_FTR_BITS(ftr_strict, ftr_type, ftr_shift, ftr_width, ftr_safe_val) \
> +	{							\
> +		.strict = ftr_strict,				\
> +		.type = ftr_type,				\
> +		.shift = ftr_shift,				\
> +		.width = ftr_width,				\
> +		.safe_val = ftr_safe_val,			\
> +	}

You can drop "ftr_" from all the arguments, it makes the macro
definition shorter.

[...]
> +static struct arm64_ftr_bits ftr_id_pfr0[] = {
> +	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 16, 16, 0),	// RAZ
> +	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 12, 4, 0),	// State3
> +	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 8, 4, 0),	// State2
> +	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 4, 4, 0),	// State1
> +	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 0, 4, 0),	// State0
> +	ARM64_FTR_END,
> +};

Do we care about the RAZ/RAO fields? Or we use this later to check a new
CPU's compatibility with the overall features?

Also, you captured lots of fields that Linux does not care about. Is it
possible to ignore them altogether, only keep those which are relevant.

> +static struct arm64_ftr_reg crm_1[] = {
> +	ARM64_FTR_REG(SYS_ID_PFR0_EL1, ftr_id_pfr0),
> +	ARM64_FTR_REG(SYS_ID_PFR1_EL1, ftr_generic_scalar_32bit),
> +	ARM64_FTR_REG(SYS_ID_DFR0_EL1, ftr_generic_scalar_32bit),
> +	ARM64_FTR_REG(SYS_ID_MMFR0_EL1, ftr_id_mmfr0),
> +	ARM64_FTR_REG(SYS_ID_MMFR1_EL1, ftr_generic_scalar_32bit),
> +	ARM64_FTR_REG(SYS_ID_MMFR2_EL1, ftr_generic_scalar_32bit),
> +	ARM64_FTR_REG(SYS_ID_MMFR3_EL1, ftr_generic_scalar_32bit),
> +};
> +
> +static struct arm64_ftr_reg crm_2[] = {
> +	ARM64_FTR_REG(SYS_ID_ISAR0_EL1, ftr_generic_scalar_32bit),
> +	ARM64_FTR_REG(SYS_ID_ISAR1_EL1, ftr_generic_scalar_32bit),
> +	ARM64_FTR_REG(SYS_ID_ISAR2_EL1, ftr_generic_scalar_32bit),
> +	ARM64_FTR_REG(SYS_ID_ISAR3_EL1, ftr_generic_scalar_32bit),
> +	ARM64_FTR_REG(SYS_ID_ISAR4_EL1, ftr_generic_scalar_32bit),
> +	ARM64_FTR_REG(SYS_ID_ISAR5_EL1, ftr_id_isar5),
> +	ARM64_FTR_REG(SYS_ID_MMFR4_EL1, ftr_id_mmfr4),
> +};
> +
> +static struct arm64_ftr_reg crm_3[] = {
> +	ARM64_FTR_REG(SYS_MVFR0_EL1, ftr_generic_scalar_32bit),
> +	ARM64_FTR_REG(SYS_MVFR1_EL1, ftr_generic_scalar_32bit),
> +	ARM64_FTR_REG(SYS_MVFR2_EL1, ftr_mvfr2),
> +};
> +
> +static struct arm64_ftr_reg crm_4[] = {
> +	ARM64_FTR_REG(SYS_ID_AA64PFR0_EL1, ftr_id_aa64pfr0),
> +	ARM64_FTR_REG(SYS_ID_AA64PFR1_EL1, ftr_aa64raz),
> +};
> +
> +static struct arm64_ftr_reg crm_5[] = {
> +	ARM64_FTR_REG(SYS_ID_AA64DFR0_EL1, ftr_id_aa64dfr0),
> +	ARM64_FTR_REG(SYS_ID_AA64DFR1_EL1, ftr_generic),
> +};
> +
> +static struct arm64_ftr_reg crm_6[] = {
> +	ARM64_FTR_REG(SYS_ID_AA64ISAR0_EL1, ftr_id_aa64isar0),
> +	ARM64_FTR_REG(SYS_ID_AA64ISAR1_EL1, ftr_aa64raz),
> +};
> +
> +static struct arm64_ftr_reg crm_7[] = {
> +	ARM64_FTR_REG(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0),
> +	ARM64_FTR_REG(SYS_ID_AA64MMFR1_EL1, ftr_id_aa64mmfr1),
> +};
> +
> +static struct arm64_ftr_reg op1_3[] = {
> +	ARM64_FTR_REG(SYS_CTR_EL0, ftr_ctr),
> +	ARM64_FTR_REG(SYS_DCZID_EL0, ftr_dczid),
> +	ARM64_FTR_REG(SYS_CNTFRQ_EL0, ftr_generic32),
> +};
> +
> +#define ARM64_REG_TABLE(table) 		\
> +	{ .n = ARRAY_SIZE(table), .regs = table }
> +static struct arm64_reg_table {
> +	int n;
> +	struct arm64_ftr_reg *regs;
> +} op1_0[] = {
> +	ARM64_REG_TABLE(crm_1),
> +	ARM64_REG_TABLE(crm_2),
> +	ARM64_REG_TABLE(crm_3),
> +	ARM64_REG_TABLE(crm_4),
> +	ARM64_REG_TABLE(crm_5),
> +	ARM64_REG_TABLE(crm_6),
> +	ARM64_REG_TABLE(crm_7),
> +};
> +
> +/*
> + * get_arm6_sys_reg - Lookup a feature register entry using its

arm64_...

> + * sys_reg() encoding.
> + *
> + * We track only the following space:
> + * Op0 = 3, Op1 = 0, CRn = 0, CRm = [1 - 7], Op2 = [0 - 7]
> + * Op0 = 3, Op1 = 3, CRn = 0, CRm = 0, Op2 = { 1, 7 } 	(CTR, DCZID)
> + * Op0 = 3, Op1 = 3, CRn = 14, CRm = 0, Op2 = 0		(CNTFRQ)
> + *
> + * The space (3, 0, 0, {1-7}, {0-7}) is arranged in a 2D array op1_0,
> + * indexed by CRm and Op2. Since not all CRm's have fully allocated Op2's
> + * arm64_reg_table[CRm-1].n indicates the largest Op2 tracked for CRm.
> + *
> + * Since we have limited number of entries with Op1 = 3, we use linear search
> + * to find the reg.
> + *
> + */
> +static struct arm64_ftr_reg* get_arm64_sys_reg(u32 sys_id)
> +{
> +	int i;
> +	u8 op2, crn, crm;
> +	u8 op1 = sys_reg_Op1(sys_id);
> +
> +	if (sys_reg_Op0(sys_id) != 3)
> +		return NULL;
> +	switch (op1) {
> +	case 0:
> +
> +		crm = sys_reg_CRm(sys_id);
> +		op2 = sys_reg_Op2(sys_id);
> +		crn = sys_reg_CRn(sys_id);
> +		if (crn || !crm || crm > 7)
> +			return NULL;
> +		if (op2 < op1_0[crm - 1].n &&
> +			op1_0[crm - 1].regs[op2].sys_id == sys_id)
> +			return &op1_0[crm - 1].regs[op2];
> +		return NULL;
> +	case 3:
> +		for (i = 0; i < ARRAY_SIZE(op1_3); i++)
> +			if (op1_3[i].sys_id == sys_id)
> +				return &op1_3[i];
> +	}
> +	return NULL;
> +}

For this function, do we ever expect to be called with an invalid
sys_id? You could add a BUG_ON(!ret) here.

Is this function ever called on a hot path? If not, just keep everything
in an array and do a linear search rather than having different arrays
based on op*. Especially if we managed to limit the number of registers
to only those that Linux cares about.

As a general coding style comment, I would much prefer to have a "ret"
local variable and one or two points of return from a function rather
than multiple returns. I've seen this as a general trend in your
patches, so please fix.

> +
> +static u64 arm64_ftr_set_value(struct arm64_ftr_bits *ftrp, s64 reg, s64 ftr_val)
> +{
> +	u64 mask = ftr_mask(ftrp);
> +
> +	reg &= ~mask;
> +	reg |= (ftr_val << ftrp->shift) & mask;
> +	return reg;
> +}
> +
> +static s64 arm64_ftr_safe_value(struct arm64_ftr_bits *ftrp, s64 new, s64 cur)
> +{
> +	switch(ftrp->type) {
> +	case FTR_DISCRETE:
> +		return ftrp->safe_val;
> +	case FTR_SCALAR_MIN:
> +		return new < cur ? new : cur;
> +	case FTR_SCALAR_MAX:
> +		return new > cur ? new : cur;
> +	}

Same here about the returns.

> +static void update_cpu_ftr_reg(u32 sys_reg, u64 new)
> +{
> +	struct arm64_ftr_bits *ftrp;
> +	struct arm64_ftr_reg *reg = get_arm64_sys_reg(sys_reg);
> +
> +	BUG_ON(!reg);
> +
> +	for(ftrp = reg->ftr_bits; ftrp->width; ftrp++) {
> +		s64 ftr_cur = arm64_ftr_value(ftrp, reg->sys_val);
> +		s64 ftr_new = arm64_ftr_value(ftrp, new);
> +
> +		if (ftr_cur == ftr_new)
> +			continue;
> +		/* Find a safe value */
> +		ftr_new = arm64_ftr_safe_value(ftrp, ftr_new, ftr_cur);
> +		reg->sys_val = arm64_ftr_set_value(ftrp, reg->sys_val, ftr_new);
> +	}
> +
> +}
> +
> +/* Update CPU feature register from non-boot CPU */

s/register from/registers for/

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1242136

On 07/10/15 18:16, Catalin Marinas wrote:
> On Mon, Oct 05, 2015 at 06:01:56PM +0100, Suzuki K. Poulose wrote:
>> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
>> index b5f313d..7ed92f2 100644
>> --- a/arch/arm64/include/asm/cpufeature.h
>> +++ b/arch/arm64/include/asm/cpufeature.h
>> @@ -35,6 +35,38 @@
>>
>>   #include <linux/kernel.h>
>>
>> +/* CPU feature register tracking */
>> +enum ftr_type {
>> +	FTR_DISCRETE,	/* Use a predefined safe value */
>> +	FTR_SCALAR_MIN,	/* Smaller value is safer */
>> +	FTR_SCALAR_MAX,	/* Bigger value is safer */
>> +};
>
> I think s/safer/safe/ sounds better, otherwise it looks like we are not
> entirely sure.

>
> BTW, I don't fully understand the name choosing here (e.g. discrete vs.
> scalar; a scalar type is also a discrete type). "MIN" looks to me like
> any higher value should be safe but instead the comment states "smaller
> value is safe". Maybe something like:
>
> 	FTR_EXACT
> 	FTR_LOWER_SAFE
> 	FTR_HIGHER_SAFE

OK, I will change them.


>
>> +
>> +#define FTR_STRICT	true
>> +#define FTR_NONSTRICT	false
>> +
>> +struct arm64_ftr_bits {
>> +	bool		strict;		/* CPU Sanity check
>> +					 *  strict matching required ? */
>
> I don't care about 80 characters line, especially around comments. So
> please place the comment on a single line.
>

OK

>> +struct arm64_ftr_reg {
>> +	u32			sys_id;
>> +	const char*		name;
>> +	u64			strict_mask;
>> +	u64			sys_val;
>> +	struct arm64_ftr_bits*	ftr_bits;
>> +};
>
> Move '*' near the struct member names, not the type.
>

Ok

>> +
>>   struct arm64_cpu_capabilities {
>>   	const char *desc;
>>   	u16 capability;
>> @@ -82,6 +114,22 @@ static inline int __attribute_const__ cpuid_feature_extract_field(u64 features,
>>   	return (s64)(features << (64 - 4 - field)) >> (64 - 4);
>>   }
>>
>> +static inline s64 __attribute_const__
>> +cpuid_feature_extract_field_width(u64 features, int field, u8 width)
>> +{
>> +	return (s64)(features << (64 - width - field)) >> (64 - width);
>> +}
>
> I think you should rewrite cpuid_feature_extract_field() in terms of the
> _width one (the latter being more generic).
>

OK, somehow, I was thinking that cpuid_feature_extract_field() could be
optimised by the compiler for a fixed width of for. Hence didn't change it.


>> +
>> +static inline u64 ftr_mask(struct arm64_ftr_bits *ftrp)
>> +{
>> +	return (u64) GENMASK(ftrp->shift + ftrp->width - 1, ftrp->shift);
>> +}
>
> Nitpick: remove the space after (u64).

OK

>
>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>> index 1ae8b24..d42ad90 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -58,8 +58,442 @@ static void update_mixed_endian_el0_support(struct cpuinfo_arm64 *info)
>>   	mixed_endian_el0 &= id_aa64mmfr0_mixed_endian_el0(info->reg_id_aa64mmfr0);
>>   }
>>
>> +#define ARM64_FTR_BITS(ftr_strict, ftr_type, ftr_shift, ftr_width, ftr_safe_val) \
>> +	{							\
>> +		.strict = ftr_strict,				\
>> +		.type = ftr_type,				\
>> +		.shift = ftr_shift,				\
>> +		.width = ftr_width,				\
>> +		.safe_val = ftr_safe_val,			\
>> +	}
>
> You can drop "ftr_" from all the arguments, it makes the macro
> definition shorter.

In fact I tried that before, but then the macro expansion will replace the
field names with the supplied values and hence won't compile. Either we
should change the field names or the values.

>
> [...]
>> +static struct arm64_ftr_bits ftr_id_pfr0[] = {
>> +	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 16, 16, 0),	// RAZ
>> +	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 12, 4, 0),	// State3
>> +	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 8, 4, 0),	// State2
>> +	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 4, 4, 0),	// State1
>> +	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 0, 4, 0),	// State0
>> +	ARM64_FTR_END,
>> +};
>
> Do we care about the RAZ/RAO fields? Or we use this later to check a new
> CPU's compatibility with the overall features?

Its just for sanity checks.

> Also, you captured lots of fields that Linux does not care about. Is it
> possible to ignore them altogether, only keep those which are relevant.
>

The list is entierly from the SANITY check. If there are any registers
that we think need not be cross checked, we could get rid of them.

  
>> +
>> +/*
>> + * get_arm6_sys_reg - Lookup a feature register entry using its
>
> arm64_...

yikes, thanks for spotting.

>
>> + * sys_reg() encoding.
>> + *
>> + * We track only the following space:
>> + * Op0 = 3, Op1 = 0, CRn = 0, CRm = [1 - 7], Op2 = [0 - 7]
>> + * Op0 = 3, Op1 = 3, CRn = 0, CRm = 0, Op2 = { 1, 7 } 	(CTR, DCZID)
>> + * Op0 = 3, Op1 = 3, CRn = 14, CRm = 0, Op2 = 0		(CNTFRQ)
>> + *
>> + * The space (3, 0, 0, {1-7}, {0-7}) is arranged in a 2D array op1_0,
>> + * indexed by CRm and Op2. Since not all CRm's have fully allocated Op2's
>> + * arm64_reg_table[CRm-1].n indicates the largest Op2 tracked for CRm.
>> + *
>> + * Since we have limited number of entries with Op1 = 3, we use linear search
>> + * to find the reg.
>> + *
>> + */
>> +static struct arm64_ftr_reg* get_arm64_sys_reg(u32 sys_id)
>> +{
>> +	int i;
>> +	u8 op2, crn, crm;
>> +	u8 op1 = sys_reg_Op1(sys_id);
>> +
>> +	if (sys_reg_Op0(sys_id) != 3)
>> +		return NULL;
>> +	switch (op1) {
>> +	case 0:
>> +
>> +		crm = sys_reg_CRm(sys_id);
>> +		op2 = sys_reg_Op2(sys_id);
>> +		crn = sys_reg_CRn(sys_id);
>> +		if (crn || !crm || crm > 7)
>> +			return NULL;
>> +		if (op2 < op1_0[crm - 1].n &&
>> +			op1_0[crm - 1].regs[op2].sys_id == sys_id)
>> +			return &op1_0[crm - 1].regs[op2];
>> +		return NULL;
>> +	case 3:
>> +		for (i = 0; i < ARRAY_SIZE(op1_3); i++)
>> +			if (op1_3[i].sys_id == sys_id)
>> +				return &op1_3[i];
>> +	}
>> +	return NULL;
>> +}
>
> For this function, do we ever expect to be called with an invalid
> sys_id? You could add a BUG_ON(!ret) here.
>

It could be called for an id which Reserved RAZ in the id range, we
plan to emulate. i.e, (3, 0, 0, [0-7], [0-7]).
See emulate_sys_reg(u32 id, u64 *valp) in Patch 20/22.
Since we don't track them, we return NULL here..
We could BUG_ON() all the other cases (e.g, MIDR and the other
classes).

Thanks for pointing that out.

> Is this function ever called on a hot path? If not, just keep everything
> in an array and do a linear search rather than having different arrays
> based on op*. Especially if we managed to limit the number of registers
> to only those that Linux cares about.

I started with linear array in the RFC post. But since then the number of
users for the API has gone up. Hence thought of optimising it. The only
'intensive' user is SANITY check for each register at CPU bring up.

>
> As a general coding style comment, I would much prefer to have a "ret"
> local variable and one or two points of return from a function rather
> than multiple returns. I've seen this as a general trend in your
> patches, so please fix.
>

...

>> +
>> +static s64 arm64_ftr_safe_value(struct arm64_ftr_bits *ftrp, s64 new, s64 cur)
>> +{
>> +	switch(ftrp->type) {
>> +	case FTR_DISCRETE:
>> +		return ftrp->safe_val;
>> +	case FTR_SCALAR_MIN:
>> +		return new < cur ? new : cur;
>> +	case FTR_SCALAR_MAX:
>> +		return new > cur ? new : cur;
>> +	}
>
> Same here about the returns.

Will fix it everywhere. Thanks for pointing out.

>
>> +static void update_cpu_ftr_reg(u32 sys_reg, u64 new)
>> +{
>> +	struct arm64_ftr_bits *ftrp;
>> +	struct arm64_ftr_reg *reg = get_arm64_sys_reg(sys_reg);
>> +
>> +	BUG_ON(!reg);
>> +
>> +	for(ftrp = reg->ftr_bits; ftrp->width; ftrp++) {
>> +		s64 ftr_cur = arm64_ftr_value(ftrp, reg->sys_val);
>> +		s64 ftr_new = arm64_ftr_value(ftrp, new);
>> +
>> +		if (ftr_cur == ftr_new)
>> +			continue;
>> +		/* Find a safe value */
>> +		ftr_new = arm64_ftr_safe_value(ftrp, ftr_new, ftr_cur);
>> +		reg->sys_val = arm64_ftr_set_value(ftrp, reg->sys_val, ftr_new);
>> +	}
>> +
>> +}
>> +
>> +/* Update CPU feature register from non-boot CPU */
>
> s/register from/registers for/

OK

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1242500

On Thu, Oct 08, 2015 at 10:55:11AM +0100, Suzuki K. Poulose wrote:
> >>@@ -82,6 +114,22 @@ static inline int __attribute_const__ cpuid_feature_extract_field(u64 features,
> >>  	return (s64)(features << (64 - 4 - field)) >> (64 - 4);
> >>  }
> >>
> >>+static inline s64 __attribute_const__
> >>+cpuid_feature_extract_field_width(u64 features, int field, u8 width)
> >>+{
> >>+	return (s64)(features << (64 - width - field)) >> (64 - width);
> >>+}
> >
> >I think you should rewrite cpuid_feature_extract_field() in terms of the
> >_width one (the latter being more generic).
> >
> 
> OK, somehow, I was thinking that cpuid_feature_extract_field() could be
> optimised by the compiler for a fixed width of for. Hence didn't change it.

Since both are static inline, the compiler should be smart enough to
optimise it already.

> >>diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> >>index 1ae8b24..d42ad90 100644
> >>--- a/arch/arm64/kernel/cpufeature.c
> >>+++ b/arch/arm64/kernel/cpufeature.c
> >>@@ -58,8 +58,442 @@ static void update_mixed_endian_el0_support(struct cpuinfo_arm64 *info)
> >>  	mixed_endian_el0 &= id_aa64mmfr0_mixed_endian_el0(info->reg_id_aa64mmfr0);
> >>  }
> >>
> >>+#define ARM64_FTR_BITS(ftr_strict, ftr_type, ftr_shift, ftr_width, ftr_safe_val) \
> >>+	{							\
> >>+		.strict = ftr_strict,				\
> >>+		.type = ftr_type,				\
> >>+		.shift = ftr_shift,				\
> >>+		.width = ftr_width,				\
> >>+		.safe_val = ftr_safe_val,			\
> >>+	}
> >
> >You can drop "ftr_" from all the arguments, it makes the macro
> >definition shorter.
> 
> In fact I tried that before, but then the macro expansion will replace the
> field names with the supplied values and hence won't compile. Either we
> should change the field names or the values.

OK, keep them in this case.

> >[...]
> >>+static struct arm64_ftr_bits ftr_id_pfr0[] = {
> >>+	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 16, 16, 0),	// RAZ
> >>+	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 12, 4, 0),	// State3
> >>+	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 8, 4, 0),	// State2
> >>+	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 4, 4, 0),	// State1
> >>+	ARM64_FTR_BITS(FTR_STRICT, FTR_DISCRETE, 0, 4, 0),	// State0
> >>+	ARM64_FTR_END,
> >>+};
> >
> >Do we care about the RAZ/RAO fields? Or we use this later to check a new
> >CPU's compatibility with the overall features?
> 
> Its just for sanity checks.
> 
> >Also, you captured lots of fields that Linux does not care about. Is it
> >possible to ignore them altogether, only keep those which are relevant.
> >
> 
> The list is entierly from the SANITY check. If there are any registers
> that we think need not be cross checked, we could get rid of them.

So we have three types of fields in these registers:

a) features defined but not something we care about in Linux
b) reserved fields
c) features important to Linux

I guess for (a), Linux may not even care if they don't match (though we
need to be careful which fields we ignore). As for (b), even if they
differ, since we don't know the meaning at this point, I think we should
just ignore them. If, for example, they add a feature that Linux doesn't
care about, they practically fall under the (a) category.

Regarding exposing reserved CPUID fields to user, I assume we would
always return 0.

> >>+ * sys_reg() encoding.
> >>+ *
> >>+ * We track only the following space:
> >>+ * Op0 = 3, Op1 = 0, CRn = 0, CRm = [1 - 7], Op2 = [0 - 7]
> >>+ * Op0 = 3, Op1 = 3, CRn = 0, CRm = 0, Op2 = { 1, 7 } 	(CTR, DCZID)
> >>+ * Op0 = 3, Op1 = 3, CRn = 14, CRm = 0, Op2 = 0		(CNTFRQ)
> >>+ *
> >>+ * The space (3, 0, 0, {1-7}, {0-7}) is arranged in a 2D array op1_0,
> >>+ * indexed by CRm and Op2. Since not all CRm's have fully allocated Op2's
> >>+ * arm64_reg_table[CRm-1].n indicates the largest Op2 tracked for CRm.
> >>+ *
> >>+ * Since we have limited number of entries with Op1 = 3, we use linear search
> >>+ * to find the reg.
> >>+ *
> >>+ */
> >>+static struct arm64_ftr_reg* get_arm64_sys_reg(u32 sys_id)
> >>+{
> >>+	int i;
> >>+	u8 op2, crn, crm;
> >>+	u8 op1 = sys_reg_Op1(sys_id);
> >>+
> >>+	if (sys_reg_Op0(sys_id) != 3)
> >>+		return NULL;
> >>+	switch (op1) {
> >>+	case 0:
> >>+
> >>+		crm = sys_reg_CRm(sys_id);
> >>+		op2 = sys_reg_Op2(sys_id);
> >>+		crn = sys_reg_CRn(sys_id);
> >>+		if (crn || !crm || crm > 7)
> >>+			return NULL;
> >>+		if (op2 < op1_0[crm - 1].n &&
> >>+			op1_0[crm - 1].regs[op2].sys_id == sys_id)
> >>+			return &op1_0[crm - 1].regs[op2];
> >>+		return NULL;
> >>+	case 3:
> >>+		for (i = 0; i < ARRAY_SIZE(op1_3); i++)
> >>+			if (op1_3[i].sys_id == sys_id)
> >>+				return &op1_3[i];
> >>+	}
> >>+	return NULL;
> >>+}
[...]
> >Is this function ever called on a hot path? If not, just keep everything
> >in an array and do a linear search rather than having different arrays
> >based on op*. Especially if we managed to limit the number of registers
> >to only those that Linux cares about.
> 
> I started with linear array in the RFC post. But since then the number of
> users for the API has gone up. Hence thought of optimising it. The only
> 'intensive' user is SANITY check for each register at CPU bring up.

This shouldn't be that bad since it's not happening very often. However,
do we need this thing for MRS emulation (not many registers though)? You
could use a binary search (something like radix tree seems overkill)

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1243333

On 08/10/15 16:03, Catalin Marinas wrote:
> On Thu, Oct 08, 2015 at 10:55:11AM +0100, Suzuki K. Poulose wrote:
>>>> +#define ARM64_FTR_BITS(ftr_strict, ftr_type, ftr_shift, ftr_width, ftr_safe_val) \

>>>
>>> You can drop "ftr_" from all the arguments, it makes the macro
>>> definition shorter.
>>
>> In fact I tried that before, but then the macro expansion will replace the
>> field names with the supplied values and hence won't compile. Either we
>> should change the field names or the values.
>
> OK, keep them in this case.

I have changed it to :

ARM64_FTR_BITS(STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL)

>>
>>> Also, you captured lots of fields that Linux does not care about. Is it
>>> possible to ignore them altogether, only keep those which are relevant.
>>>
>>
>> The list is entierly from the SANITY check. If there are any registers
>> that we think need not be cross checked, we could get rid of them.
>
> So we have three types of fields in these registers:
>
> a) features defined but not something we care about in Linux
> b) reserved fields
> c) features important to Linux
>
> I guess for (a), Linux may not even care if they don't match (though we
> need to be careful which fields we ignore). As for (b), even if they
> differ, since we don't know the meaning at this point, I think we should
> just ignore them. If, for example, they add a feature that Linux doesn't
> care about, they practically fall under the (a) category.

OK. So we can pack the consecutive features of type (a) and make it NONSTRICT.

>
> Regarding exposing reserved CPUID fields to user, I assume we would
> always return 0.

Ideally, the architecturally reserved value (i.e, 0 for RAZ and 1 for RES1).

>>> Is this function ever called on a hot path? If not, just keep everything
>>> in an array and do a linear search rather than having different arrays
>>> based on op*. Especially if we managed to limit the number of registers
>>> to only those that Linux cares about.
>>
>> I started with linear array in the RFC post. But since then the number of
>> users for the API has gone up. Hence thought of optimising it. The only
>> 'intensive' user is SANITY check for each register at CPU bring up.
>
> This shouldn't be that bad since it's not happening very often. However,
> do we need this thing for MRS emulation (not many registers though)? You
> could use a binary search (something like radix tree seems overkill)

Yes we do need this for MRS emulation. I will change it to binary search.

Thanks
Suzuki

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1244929

On 08/10/15 16:03, Catalin Marinas wrote:
> On Thu, Oct 08, 2015 at 10:55:11AM +0100, Suzuki K. Poulose wrote:

...
>
> So we have three types of fields in these registers:
>
> a) features defined but not something we care about in Linux
> b) reserved fields
> c) features important to Linux
>
> I guess for (a), Linux may not even care if they don't match (though we
> need to be careful which fields we ignore). As for (b), even if they
> differ, since we don't know the meaning at this point, I think we should
> just ignore them. If, for example, they add a feature that Linux doesn't
> care about, they practically fall under the (a) category.
>
> Regarding exposing reserved CPUID fields to user, I assume we would
> always return 0.

Mark,

Do you have any comments on this ? The list I have here is what you came
up with in SANITY checks.

Thanks
Suzuki

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1244945

Hi,

Thanks for the heads-up.

On Mon, Oct 12, 2015 at 06:01:25PM +0100, Suzuki K. Poulose wrote:
> On 08/10/15 16:03, Catalin Marinas wrote:
> >On Thu, Oct 08, 2015 at 10:55:11AM +0100, Suzuki K. Poulose wrote:
> 
> ...
> >
> >So we have three types of fields in these registers:
> >
> >a) features defined but not something we care about in Linux
> >b) reserved fields
> >c) features important to Linux
> >
> >I guess for (a), Linux may not even care if they don't match (though we
> >need to be careful which fields we ignore). As for (b), even if they
> >differ, since we don't know the meaning at this point, I think we should
> >just ignore them. If, for example, they add a feature that Linux doesn't
> >care about, they practically fall under the (a) category.
> >
> >Regarding exposing reserved CPUID fields to user, I assume we would
> >always return 0.
> 
> Mark,
> 
> Do you have any comments on this ? The list I have here is what you came
> up with in SANITY checks.

My feeling was that we should play it safe with fields which are
currently reserved (warning if they differ for now).

If they turn out to be irrelevant, it's simple to backport a patch to
ignore them, whereas if they matter we get instant visibility, which is
the entire point of the sanity checks.

So I think we should warn if reserved fields differ. I'd rather have a
few spurious warnings until kernels get updated than miss an issue that
could have been dealt with and avoided.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1245517

On Mon, Oct 12, 2015 at 06:21:04PM +0100, Mark Rutland wrote:
> On Mon, Oct 12, 2015 at 06:01:25PM +0100, Suzuki K. Poulose wrote:
> > On 08/10/15 16:03, Catalin Marinas wrote:
> > >On Thu, Oct 08, 2015 at 10:55:11AM +0100, Suzuki K. Poulose wrote:
> > 
> > ...
> > >
> > >So we have three types of fields in these registers:
> > >
> > >a) features defined but not something we care about in Linux
> > >b) reserved fields
> > >c) features important to Linux
> > >
> > >I guess for (a), Linux may not even care if they don't match (though we
> > >need to be careful which fields we ignore). As for (b), even if they
> > >differ, since we don't know the meaning at this point, I think we should
> > >just ignore them. If, for example, they add a feature that Linux doesn't
> > >care about, they practically fall under the (a) category.
> > >
> > >Regarding exposing reserved CPUID fields to user, I assume we would
> > >always return 0.
> > 
> > Mark,
> > 
> > Do you have any comments on this ? The list I have here is what you came
> > up with in SANITY checks.
> 
> My feeling was that we should play it safe with fields which are
> currently reserved (warning if they differ for now).
> 
> If they turn out to be irrelevant, it's simple to backport a patch to
> ignore them, whereas if they matter we get instant visibility, which is
> the entire point of the sanity checks.
> 
> So I think we should warn if reserved fields differ. I'd rather have a
> few spurious warnings until kernels get updated than miss an issue that
> could have been dealt with and avoided.

The warnings are indeed harmless. I think the main danger is when a
field goes negative which means an existing feature without CPUID field
allocated is removed (though I don't expect this for ARMv8). But you are
right, let the warnings in for now, let's re-assess when/if a difference
happens.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1243239

On 08/10/15 10:55, Suzuki K. Poulose wrote:
> On 07/10/15 18:16, Catalin Marinas wrote:
>> On Mon, Oct 05, 2015 at 06:01:56PM +0100, Suzuki K. Poulose wrote:
>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>>> index 1ae8b24..d42ad90 100644
>>> --- a/arch/arm64/kernel/cpufeature.c
>>> +++ b/arch/arm64/kernel/cpufeature.c
>>> @@ -58,8 +58,442 @@ static void update_mixed_endian_el0_support(struct cpuinfo_arm64 *info)
>>>       mixed_endian_el0 &= id_aa64mmfr0_mixed_endian_el0(info->reg_id_aa64mmfr0);

>>> + * sys_reg() encoding.
>>> + *
>>> + * We track only the following space:
>>> + * Op0 = 3, Op1 = 0, CRn = 0, CRm = [1 - 7], Op2 = [0 - 7]
>>> + * Op0 = 3, Op1 = 3, CRn = 0, CRm = 0, Op2 = { 1, 7 }     (CTR, DCZID)
>>> + * Op0 = 3, Op1 = 3, CRn = 14, CRm = 0, Op2 = 0        (CNTFRQ)
>>> + *
>>> + * The space (3, 0, 0, {1-7}, {0-7}) is arranged in a 2D array op1_0,
>>> + * indexed by CRm and Op2. Since not all CRm's have fully allocated Op2's
>>> + * arm64_reg_table[CRm-1].n indicates the largest Op2 tracked for CRm.
>>> + *
>>> + * Since we have limited number of entries with Op1 = 3, we use linear search
>>> + * to find the reg.
>>> + *
>>> + */
>>> +static struct arm64_ftr_reg* get_arm64_sys_reg(u32 sys_id)
>>> +{
>>> +    int i;
>>> +    u8 op2, crn, crm;
>>> +    u8 op1 = sys_reg_Op1(sys_id);
>>> +
>>> +    if (sys_reg_Op0(sys_id) != 3)
>>> +        return NULL;
>>> +    switch (op1) {
>>> +    case 0:
>>> +
>>> +        crm = sys_reg_CRm(sys_id);
>>> +        op2 = sys_reg_Op2(sys_id);
>>> +        crn = sys_reg_CRn(sys_id);
>>> +        if (crn || !crm || crm > 7)
>>> +            return NULL;
>>> +        if (op2 < op1_0[crm - 1].n &&
>>> +            op1_0[crm - 1].regs[op2].sys_id == sys_id)
>>> +            return &op1_0[crm - 1].regs[op2];
>>> +        return NULL;
>>> +    case 3:
>>> +        for (i = 0; i < ARRAY_SIZE(op1_3); i++)
>>> +            if (op1_3[i].sys_id == sys_id)
>>> +                return &op1_3[i];
>>> +    }
>>> +    return NULL;
>>> +}
>>
>> For this function, do we ever expect to be called with an invalid
>> sys_id? You could add a BUG_ON(!ret) here.
>>
>
> It could be called for an id which Reserved RAZ in the id range, we
> plan to emulate. i.e, (3, 0, 0, [0-7], [0-7]).
> See emulate_sys_reg(u32 id, u64 *valp) in Patch 20/22.
> Since we don't track them, we return NULL here..
> We could BUG_ON() all the other cases (e.g, MIDR and the other
> classes).
>
> Thanks for pointing that out.

Actually, the error handling is left to the users of the function.
We do a BUG_ON() in the caller. e.g, init/update_cpu_ftr_reg can't
accept a NULL and BUGs. While the emulate_sys_reg() issues the call
only for the emualted feature registers(excluding MIDR/REVIDR etc),
so a NULL is perfectly acceptable for them.

Thanks
Suzuki


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1243403

On Fri, Oct 09, 2015 at 11:56:14AM +0100, Suzuki K. Poulose wrote:
> On 08/10/15 10:55, Suzuki K. Poulose wrote:
> >On 07/10/15 18:16, Catalin Marinas wrote:
> >>On Mon, Oct 05, 2015 at 06:01:56PM +0100, Suzuki K. Poulose wrote:
> >>>diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> >>>index 1ae8b24..d42ad90 100644
> >>>--- a/arch/arm64/kernel/cpufeature.c
> >>>+++ b/arch/arm64/kernel/cpufeature.c
> >>>@@ -58,8 +58,442 @@ static void update_mixed_endian_el0_support(struct cpuinfo_arm64 *info)
> >>>      mixed_endian_el0 &= id_aa64mmfr0_mixed_endian_el0(info->reg_id_aa64mmfr0);
> 
> >>>+ * sys_reg() encoding.
> >>>+ *
> >>>+ * We track only the following space:
> >>>+ * Op0 = 3, Op1 = 0, CRn = 0, CRm = [1 - 7], Op2 = [0 - 7]
> >>>+ * Op0 = 3, Op1 = 3, CRn = 0, CRm = 0, Op2 = { 1, 7 }     (CTR, DCZID)
> >>>+ * Op0 = 3, Op1 = 3, CRn = 14, CRm = 0, Op2 = 0        (CNTFRQ)
> >>>+ *
> >>>+ * The space (3, 0, 0, {1-7}, {0-7}) is arranged in a 2D array op1_0,
> >>>+ * indexed by CRm and Op2. Since not all CRm's have fully allocated Op2's
> >>>+ * arm64_reg_table[CRm-1].n indicates the largest Op2 tracked for CRm.
> >>>+ *
> >>>+ * Since we have limited number of entries with Op1 = 3, we use linear search
> >>>+ * to find the reg.
> >>>+ *
> >>>+ */
> >>>+static struct arm64_ftr_reg* get_arm64_sys_reg(u32 sys_id)
> >>>+{
> >>>+    int i;
> >>>+    u8 op2, crn, crm;
> >>>+    u8 op1 = sys_reg_Op1(sys_id);
> >>>+
> >>>+    if (sys_reg_Op0(sys_id) != 3)
> >>>+        return NULL;
> >>>+    switch (op1) {
> >>>+    case 0:
> >>>+
> >>>+        crm = sys_reg_CRm(sys_id);
> >>>+        op2 = sys_reg_Op2(sys_id);
> >>>+        crn = sys_reg_CRn(sys_id);
> >>>+        if (crn || !crm || crm > 7)
> >>>+            return NULL;
> >>>+        if (op2 < op1_0[crm - 1].n &&
> >>>+            op1_0[crm - 1].regs[op2].sys_id == sys_id)
> >>>+            return &op1_0[crm - 1].regs[op2];
> >>>+        return NULL;
> >>>+    case 3:
> >>>+        for (i = 0; i < ARRAY_SIZE(op1_3); i++)
> >>>+            if (op1_3[i].sys_id == sys_id)
> >>>+                return &op1_3[i];
> >>>+    }
> >>>+    return NULL;
> >>>+}
> >>
> >>For this function, do we ever expect to be called with an invalid
> >>sys_id? You could add a BUG_ON(!ret) here.
> >>
> >
> >It could be called for an id which Reserved RAZ in the id range, we
> >plan to emulate. i.e, (3, 0, 0, [0-7], [0-7]).
> >See emulate_sys_reg(u32 id, u64 *valp) in Patch 20/22.
> >Since we don't track them, we return NULL here..
> >We could BUG_ON() all the other cases (e.g, MIDR and the other
> >classes).
> >
> >Thanks for pointing that out.
> 
> Actually, the error handling is left to the users of the function.
> We do a BUG_ON() in the caller. e.g, init/update_cpu_ftr_reg can't
> accept a NULL and BUGs. While the emulate_sys_reg() issues the call
> only for the emualted feature registers(excluding MIDR/REVIDR etc),
> so a NULL is perfectly acceptable for them.

OK, please leave the NULL checking in the caller then.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web