| Message ID | 20200114150953.27659-21-alex.bennee@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | gdbstub refactor and SVE support (+check-tcg tweaks) | expand |
On 1/14/20 5:09 AM, Alex Bennée wrote: > This test exercises the gdbstub while runing the sve-iotcl test. I > haven't plubmed it into make system as we need a way of verifying if > gdb has the right support for SVE. > > Signed-off-by: Alex Bennée <alex.bennee@linaro.org> > > --- > v4 > - interrogate ZCR_EL1 directly as no longer have vg Note that ZCR_EL1 does not give you the correct answer if the hypervisor has set ZCR_EL2 to something lower. Also, ZCR_EL1 it itself not correct if the hardware does not support all vector sizes. See some of Andrew Jones' qemu command-line work. Try -cpu max,sve512=on and then use the ioctl to set vq to 3 (sve384). The result will be an effective vq of 2 (sve256). We *really* need vg, as computed from sve_zcr_len_for_el(). r~
Richard Henderson <richard.henderson@linaro.org> writes: > On 1/14/20 5:09 AM, Alex Bennée wrote: >> This test exercises the gdbstub while runing the sve-iotcl test. I >> haven't plubmed it into make system as we need a way of verifying if >> gdb has the right support for SVE. >> >> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> >> >> --- >> v4 >> - interrogate ZCR_EL1 directly as no longer have vg > > Note that ZCR_EL1 does not give you the correct answer if the hypervisor has > set ZCR_EL2 to something lower. Sure - although this is only a user space test so we are not expecting shenanigans. > Also, ZCR_EL1 it itself not correct if the > hardware does not support all vector sizes. > > See some of Andrew Jones' qemu command-line work. Try -cpu max,sve512=on and > then use the ioctl to set vq to 3 (sve384). The result will be an effective vq > of 2 (sve256). > > We *really* need vg, as computed from sve_zcr_len_for_el(). How come TARGET_PR_SVE_GET_VL is happy to compute directly from ZCR then? I'll put the vg back in but it seemed a little pointless given the gdbstub ignores it. > > > r~
On 2/4/20 9:45 PM, Alex Bennée wrote: >> Also, ZCR_EL1 it itself not correct if the >> hardware does not support all vector sizes. >> >> See some of Andrew Jones' qemu command-line work. Try -cpu max,sve512=on and >> then use the ioctl to set vq to 3 (sve384). The result will be an effective vq >> of 2 (sve256). >> >> We *really* need vg, as computed from sve_zcr_len_for_el(). > > How come TARGET_PR_SVE_GET_VL is happy to compute directly from ZCR > then? Bug. It didn't get updated with Andrew's changes to limit the set of supported sve lengths. > I'll put the vg back in but it seemed a little pointless given the > gdbstub ignores it. I'll say again that this is a gdb bug and we should simply report/fix it upstream. Don't try to work around it in qemu. r~
On Wed, Feb 05, 2020 at 10:19:08AM +0000, Richard Henderson wrote: > On 2/4/20 9:45 PM, Alex Bennée wrote: > >> Also, ZCR_EL1 it itself not correct if the > >> hardware does not support all vector sizes. > >> > >> See some of Andrew Jones' qemu command-line work. Try -cpu max,sve512=on and > >> then use the ioctl to set vq to 3 (sve384). The result will be an effective vq > >> of 2 (sve256). > >> > >> We *really* need vg, as computed from sve_zcr_len_for_el(). > > > > How come TARGET_PR_SVE_GET_VL is happy to compute directly from ZCR > > then? > > Bug. It didn't get updated with Andrew's changes to limit the set of supported > sve lengths. Yeah. Sorry about that. I don't know much about linux-user so I didn't look closely enough at it to realize it needed changes as well. Grepping now, I see there's a couple other places that might need updating too linux-user/aarch64/signal.c target_restore_sigframe: TARGET_SVE_MAGIC target_setup_frame: /* SVE state needs saving only if it exists. */ And, like TARGET_PR_SVE_GET_VL, TARGET_PR_SVE_SET_VL needs changes in linux-user/syscall.c as well. Thanks, drew > > > I'll put the vg back in but it seemed a little pointless given the > > gdbstub ignores it. > > I'll say again that this is a gdb bug and we should simply report/fix it > upstream. Don't try to work around it in qemu. > > > r~ >
diff --git a/tests/tcg/aarch64/Makefile.target b/tests/tcg/aarch64/Makefile.target index 66addbc52f..914ab81872 100644 --- a/tests/tcg/aarch64/Makefile.target +++ b/tests/tcg/aarch64/Makefile.target @@ -51,15 +51,22 @@ sve-ioctls: CFLAGS+=-march=armv8.1-a+sve ifneq ($(HAVE_GDB_BIN),) GDB_SCRIPT=$(SRC_PATH)/tests/guest-debug/run-test.py -AARCH64_TESTS += gdbstub-sysregs +AARCH64_TESTS += gdbstub-sysregs gdbstub-sve-ioctls -.PHONY: gdbstub-sysregs +.PHONY: gdbstub-sysregs gdbstub-sve-ioctls run-gdbstub-sysregs: sysregs $(call run-test, $@, $(GDB_SCRIPT) \ --gdb $(HAVE_GDB_BIN) \ --qemu $(QEMU) --qargs "$(QEMU_OPTS)" \ --bin $< --test $(AARCH64_SRC)/gdbstub/test-sve.py, \ "basic gdbstub SVE support") + +run-gdbstub-sve-ioctls: sve-ioctls + $(call run-test, $@, $(GDB_SCRIPT) \ + --gdb $(HAVE_GDB_BIN) \ + --qemu $(QEMU) --qargs "$(QEMU_OPTS)" \ + --bin $< --test $(AARCH64_SRC)/gdbstub/test-sve-ioctl.py, \ + "basic gdbstub SVE ZLEN support") endif endif diff --git a/tests/tcg/aarch64/gdbstub/test-sve-ioctl.py b/tests/tcg/aarch64/gdbstub/test-sve-ioctl.py new file mode 100644 index 0000000000..6f4f429cf2 --- /dev/null +++ b/tests/tcg/aarch64/gdbstub/test-sve-ioctl.py @@ -0,0 +1,79 @@ +from __future__ import print_function +# +# Test the SVE ZReg reports the right amount of data. It uses the +# sve-ioctl test and examines the register data each time the +# __sve_ld_done breakpoint is hit. +# +# This is launched via tests/guest-debug/run-test.py +# + +import gdb +import sys + +initial_vlen = 0 +failcount = 0 + +def report(cond, msg): + "Report success/fail of test" + if cond: + print ("PASS: %s" % (msg)) + else: + print ("FAIL: %s" % (msg)) + global failcount + failcount += 1 + +class TestBreakpoint(gdb.Breakpoint): + def __init__(self, sym_name="__sve_ld_done"): + super(TestBreakpoint, self).__init__(sym_name) + # self.sym, ok = gdb.lookup_symbol(sym_name) + + def stop(self): + val_i = gdb.parse_and_eval('i') + global initial_vlen + for i in range(0, int(val_i)): + val_z = gdb.parse_and_eval("$z0.b.u[%d]" % i) + report(int(val_z) == i, "z0.b.u[%d] == %d" % (i, i)) + for i in range(i + 1, initial_vlen): + val_z = gdb.parse_and_eval("$z0.b.u[%d]" % i) + report(int(val_z) == 0, "z0.b.u[%d] == 0" % (i)) + + +def run_test(): + "Run through the tests one by one" + + print ("Setup breakpoint") + bp = TestBreakpoint() + + global initial_vlen + vg = gdb.parse_and_eval("$ZCR_EL1") + initial_vlen = int(vg) * 16 + + gdb.execute("c") + +# +# This runs as the script it sourced (via -x, via run-test.py) +# +try: + inferior = gdb.selected_inferior() + arch = inferior.architecture() + report(arch.name() == "aarch64", "connected to aarch64") +except (gdb.error, AttributeError): + print("SKIPPING (not connected)", file=sys.stderr) + exit(0) + +try: + # These are not very useful in scripts + gdb.execute("set pagination off") + gdb.execute("set confirm off") + + # Run the actual tests + run_test() +except: + print ("GDB Exception: %s" % (sys.exc_info()[0])) + failcount += 1 + import code + code.InteractiveConsole(locals=globals()).interact() + raise + +print("All tests complete: %d failures" % failcount) +exit(failcount)
This test exercises the gdbstub while runing the sve-iotcl test. I haven't plubmed it into make system as we need a way of verifying if gdb has the right support for SVE. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> --- v4 - interrogate ZCR_EL1 directly as no longer have vg v5 - plumb in - skip if fails to connect --- tests/tcg/aarch64/Makefile.target | 11 ++- tests/tcg/aarch64/gdbstub/test-sve-ioctl.py | 79 +++++++++++++++++++++ 2 files changed, 88 insertions(+), 2 deletions(-) create mode 100644 tests/tcg/aarch64/gdbstub/test-sve-ioctl.py