Hi,

These patches apply on-top of the last clean-up series:

  Subject: [RISU PATCH 0/7] Add @Group support and some aarch64.risu cleanups
  Date: Tue, 31 Oct 2017 14:54:37 +0000
  Message-Id: <20171031145444.13766-1-alex.bennee@linaro.org>

This series adds support for SVE to RISU. Most of the initial patches
are plumbing changes to better support arch specific option flags
(cleaning up a TODO in the process). I also needed to ensure configure
actually honoured CPPFLAGS so it could be passed yet to be released
headers.

The actual guts of the SVE support is in 3 patches. One to risugen so
it can generate random values for the vector registers. If this isn't
done you get inconsistent runs because of left over junk in the
registers. The remaining two patches add support for copying the SVE
vectors from the signal context and dumping any differences found.

To test this I ran on the Foundation model with:

  ${RTSM_MODEL} --no-secure-memory --gicv3 --data=${BL1_FIRMWARE}@0x0 --data=${FIP_FIRMWARE}@0x8000000 \
                --semihost --network nat --network-nat-ports=8022=22 --block-device ${DISK_IMAGE}

With my hacked up copy of secure firmware to ensure SVE is enabled.
You also need a kernel with SVE support:

  Subject: [PATCH v5 00/30] ARM Scalable Vector Extension (SVE)
  Date: Tue, 31 Oct 2017 15:50:52 +0000
  Message-Id: <1509465082-30427-1-git-send-email-Dave.Martin@arm.com>

My testing so far has been to ensure that each run on the foundation
model is deterministic (same m5sum on each trace) and that differences
are printed out when the user-space vector length is tweaked
(/proc/sys/abi/sve_default_vector_length).


Alex Bennée (10):
  build-all-arches: drop -t (for tty) from docker invocation
  risu.c: split out setting up options
  risu.c: add missing --trace longopt
  risu: move optional args to each architecture
  configure: allow repeated invocation of configure in build dir
  configure: support CPPFLAGS
  risugen: add --sve support
  aarch64.risu: initial SVE instruction
  risu_reginfo_aarch64: add reginfo_copy_sve
  risu_reginfo_aarch64: add SVE support to reginfo_dump_mismatch

 README                 |   6 +++
 aarch64.risu           |  24 ++++++++++
 build-all-archs        |   2 +-
 configure              |   5 +-
 risu.c                 |  57 +++++++++++++++++-----
 risu.h                 |   6 ++-
 risu_reginfo_aarch64.c | 126 +++++++++++++++++++++++++++++++++++++++++++++++++
 risu_reginfo_aarch64.h |   8 ++++
 risu_reginfo_arm.c     |  11 +++++
 risu_reginfo_m68k.c    |   3 ++
 risu_reginfo_ppc64.c   |   3 ++
 risugen                |   3 ++
 risugen_arm.pm         |  57 +++++++++++++++++++---
 13 files changed, 286 insertions(+), 25 deletions(-)

-- 
2.14.2

On Tue, Nov 07, 2017 at 03:05:48PM +0000, Alex Bennée wrote:
> Hi,
> 
> These patches apply on-top of the last clean-up series:
> 
>   Subject: [RISU PATCH 0/7] Add @Group support and some aarch64.risu cleanups
>   Date: Tue, 31 Oct 2017 14:54:37 +0000
>   Message-Id: <20171031145444.13766-1-alex.bennee@linaro.org>
> 
> This series adds support for SVE to RISU. Most of the initial patches
> are plumbing changes to better support arch specific option flags
> (cleaning up a TODO in the process). I also needed to ensure configure
> actually honoured CPPFLAGS so it could be passed yet to be released
> headers.

Should there be a getauxval(AT_HWCAP) & HWCAP_SVE check in this series
somewhere?

I don't know enough about how RISU is structured to know whether/where
this is needed.

[...]

Cheers
---Dave

Dave Martin <Dave.Martin@arm.com> writes:

> On Tue, Nov 07, 2017 at 03:05:48PM +0000, Alex Bennée wrote:
>> Hi,
>>
>> These patches apply on-top of the last clean-up series:
>>
>>   Subject: [RISU PATCH 0/7] Add @Group support and some aarch64.risu cleanups
>>   Date: Tue, 31 Oct 2017 14:54:37 +0000
>>   Message-Id: <20171031145444.13766-1-alex.bennee@linaro.org>
>>
>> This series adds support for SVE to RISU. Most of the initial patches
>> are plumbing changes to better support arch specific option flags
>> (cleaning up a TODO in the process). I also needed to ensure configure
>> actually honoured CPPFLAGS so it could be passed yet to be released
>> headers.
>
> Should there be a getauxval(AT_HWCAP) & HWCAP_SVE check in this series
> somewhere?
>
> I don't know enough about how RISU is structured to know whether/where
> this is needed.

That would be a saner runtime check to do but it's a balance as RISU is
a fairly specialist tool which kind of assumes people know what they are
doing.

The current check is on SVE_MAGIC in the header files which does mean a
binary compiled on an SVE headered system is now carrying about a much
larger register dump even when run without the --test-sve flag.

Whether it makes sense to be more flexible is a call I'll leave up to
Peter.

>
> [...]
>
> Cheers
> ---Dave


--
Alex Bennée

On Wed, Nov 08, 2017 at 11:02:15AM +0000, Alex Bennée wrote:
> 
> Dave Martin <Dave.Martin@arm.com> writes:
> 
> > On Tue, Nov 07, 2017 at 03:05:48PM +0000, Alex Bennée wrote:
> >> Hi,
> >>
> >> These patches apply on-top of the last clean-up series:
> >>
> >>   Subject: [RISU PATCH 0/7] Add @Group support and some aarch64.risu cleanups
> >>   Date: Tue, 31 Oct 2017 14:54:37 +0000
> >>   Message-Id: <20171031145444.13766-1-alex.bennee@linaro.org>
> >>
> >> This series adds support for SVE to RISU. Most of the initial patches
> >> are plumbing changes to better support arch specific option flags
> >> (cleaning up a TODO in the process). I also needed to ensure configure
> >> actually honoured CPPFLAGS so it could be passed yet to be released
> >> headers.
> >
> > Should there be a getauxval(AT_HWCAP) & HWCAP_SVE check in this series
> > somewhere?
> >
> > I don't know enough about how RISU is structured to know whether/where
> > this is needed.
> 
> That would be a saner runtime check to do but it's a balance as RISU is
> a fairly specialist tool which kind of assumes people know what they are
> doing.
> 
> The current check is on SVE_MAGIC in the header files which does mean a
> binary compiled on an SVE headered system is now carrying about a much
> larger register dump even when run without the --test-sve flag.
> 
> Whether it makes sense to be more flexible is a call I'll leave up to
> Peter.

Fair enough.  If there is anywhere useful to put it, it would serve as
a useful example -- but as you point out, this is not a typical piece
of userspace software...

Cheers
---Dave

On 7 November 2017 at 15:05, Alex Bennée <alex.bennee@linaro.org> wrote:
> Hi,
>
> These patches apply on-top of the last clean-up series:
>
>   Subject: [RISU PATCH 0/7] Add @Group support and some aarch64.risu cleanups
>   Date: Tue, 31 Oct 2017 14:54:37 +0000
>   Message-Id: <20171031145444.13766-1-alex.bennee@linaro.org>
>
> This series adds support for SVE to RISU. Most of the initial patches
> are plumbing changes to better support arch specific option flags
> (cleaning up a TODO in the process). I also needed to ensure configure
> actually honoured CPPFLAGS so it could be passed yet to be released
> headers.
>
> The actual guts of the SVE support is in 3 patches. One to risugen so
> it can generate random values for the vector registers. If this isn't
> done you get inconsistent runs because of left over junk in the
> registers. The remaining two patches add support for copying the SVE
> vectors from the signal context and dumping any differences found.
>
> To test this I ran on the Foundation model with:
>
>   ${RTSM_MODEL} --no-secure-memory --gicv3 --data=${BL1_FIRMWARE}@0x0 --data=${FIP_FIRMWARE}@0x8000000 \
>                 --semihost --network nat --network-nat-ports=8022=22 --block-device ${DISK_IMAGE}
>
> With my hacked up copy of secure firmware to ensure SVE is enabled.
> You also need a kernel with SVE support:
>
>   Subject: [PATCH v5 00/30] ARM Scalable Vector Extension (SVE)
>   Date: Tue, 31 Oct 2017 15:50:52 +0000
>   Message-Id: <1509465082-30427-1-git-send-email-Dave.Martin@arm.com>
>
> My testing so far has been to ensure that each run on the foundation
> model is deterministic (same m5sum on each trace) and that differences
> are printed out when the user-space vector length is tweaked
> (/proc/sys/abi/sve_default_vector_length).
>
>
> Alex Bennée (10):
>   build-all-arches: drop -t (for tty) from docker invocation
>   risu.c: split out setting up options
>   risu.c: add missing --trace longopt
>   risu: move optional args to each architecture
>   configure: allow repeated invocation of configure in build dir
>   configure: support CPPFLAGS
>   risugen: add --sve support
>   aarch64.risu: initial SVE instruction
>   risu_reginfo_aarch64: add reginfo_copy_sve
>   risu_reginfo_aarch64: add SVE support to reginfo_dump_mismatch

I've applied patches 1, 2, 3, 5, 6 to risu master.

thanks
-- PMM