| Message ID | 20171107150558.22131-1-alex.bennee@linaro.org |
|---|---|
| Headers | show |
| Series | Initial support for SVE | expand |
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
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