On Feb 13 17:11, Peter Maydell wrote:
> On Thu, 2 Feb 2023 at 21:12, Aaron Lindsay <aa...@os.amperecomputing.com>
> wrote:
> >
> > Signed-off-by: Aaron Lindsay <aa...@os.amperecomputing.com>
> > ---
> > target/arm/cpu.h | 5 +++
> > target/arm/cpu64.c | 81 ++++++++++++++++++++++++++++++++++++++--------
> > 2 files changed, 72 insertions(+), 14 deletions(-)
>
> Do we really need all these properties ? Generally we don't
> add CPU properties unless there's a good reason for the
> user (or the board/SoC code) to want to flip them. The
> more usual case is that we simply enable them on the 'max'
> CPU by setting the ID register fields appropriately.
Honestly, I wasn't sure where to draw the line... so I didn't. Though I
won't claim to have perfect knowledge of the evolution of this feature,
it felt like there were 4 distinct levels that I could imagine might be
wanted - I've starred those 4 below:
* 1) no PAC (APA/API=0b0000)
* 2) PAC without EPAC/Pauth2, QEMU's highest PAC implementation previous
to this patchset (APA/API=0b0001)
* 3) EPAC (APA/API=0b0010)
4) Pauth2 (APA/API=0b0011)
5) FPAC (APA/API=0b0100)
* 6) FPACCombined (APA/API=0b0101)
And I am not sure how likely 4) and 5) are to be implemented, but after
I was already up to 4, adding the last two more didn't feel like much
more!
I half-considered trying to make `pauth` a single option which took a
string instead of a handful of separate boolean arguments. The possible
options might be `pauth=off`, `pauth=no-epac` (no EPAC), `pauth=epac`,
`pauth=pauth2`, `pauth=fpac-combine`.
All this to say: I'm more than happy to take guidance here!
> Somewhere in this series you need to add documentation of
> the features being implemented to docs/system/arm/emulation.rst
> (just a one-liner per FEAT_whatever).
Will do in my next patchset based on what we decide upon above.
Thanks!
-Aaron
