On Thu, Aug 13, 2020 at 10:05:04AM +0100, Mark Rutland wrote:
> On Thu, Aug 13, 2020 at 08:03:21AM +0200, Andrew Jones wrote:
> > Thinking about this some more, maybe we don't need pauth-arch.
> > If we don't, then it simplifies nicely to
> >
> > # Default (enabled with architected algorithm)
> > -cpu max[,pauth=on][,pauth-fast=off]
> >
> > # Select pauth-fast
> > -cpu max[,pauth=on],pauth-fast=on
>
> One reason that users may wish to choose the IMP-DEF algorithm is for
> functional testing regardless of speed (since APA+GPA / API+GPI depend
> on whether the algo is architected or imp-def).
>
> Given that, I think that "impdef" is a better option name than
> "pauth-fast", and speed is a benefit but not the only reason to use the
> option.
I was going with pauth-fast because in this case Richard identified a
need for a fast version. If we identify another need later, then we may
want to add another impdef version, e.g. pauth-foo. Maybe all the impdef
versions should have impdef in their name to make that more explicit?
pauth-impdef-fast
pauth-impdef-foo
...
That seems a bit verbose, though, and we can document that pauth-* are
impdefs and that the default is architected.
>
> How about hacing a 'pauth-algo' option which defaults to architected,
> e.g.
>
> | -cpu max,pauth={on,off},pauth-algo={impdef,architected}
>
> ... then in future the 'pauth={on,off}' bit could de extended to cover
> FPAC version etc independently of the algorithm, but for now that can be
> a boolean.
>
Keeping pauth a boolean, but creating a pauth-algo enum doesn't help us
much, because probing will only be possible for pauth. The prober could
only decide to enable pauth with the default algo or not. We could create
a pauth-specific probe, similar to the gic-specific probe, but, IMO, it's
really not necessary. If we need multiple pauth-* properties, then we can
have them all. It just adds a few more lines of logic to the pauth
finalize function.
Thanks,
drew
