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~
>
