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

[Suzuki K. Poulose]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/