Ah. thanks. I've missed that as I've only looked in .c files and it's in .c.inc. If I
get this macro correctly it pastes name to gen_st so I expect to see a
GEN_VR_STX(vx,...) somewhere for stvx but I can only find:
GEN_VR_STX(svx, 0x07, 0x07);
/* As we don't emulate the cache, stvxl is stricly equivalent to stvx */
GEN_VR_STX(svxl, 0x07, 0x0F);
so where is stvx defined at the end or how does this work?
Then I've checked the opcode above: 0x7e8029ce which seems to be 1f-07-07-00 so the
GEN_VR_STX(svx, 0x07, 0x07) seems to match that.
From this you can see the exception is thrown if ctx->altivec_enabled isn't true,
where ctx->altivec_enabled is set in ppc_tr_init_disas_context() to:
ctx->altivec_enabled = (hflags >> HFLAGS_VR) & 1;
It seems the issue is that somehow HFLAGS_VR isn't being set from the CPUPPCState
env->flags in hreg_compute_hflags_value(). There was a recent patchset from Richard
that tidied up the hflags (see
https://patchew.org/QEMU/20210323184340.619757-1-richard.henderson@linaro.org/) so
it could be the issue was accidentally introduced there.
As far as I could trace this back MSR_VR that should correspond to HFLAGS_VR is
turned on by POWERPC_FLAG_VRE which is set in PowerPCCPUClass::flags in
POWERPC_FAMILY(e6500) in cpu_init.c (the last thing in that function). This is done
in hreg_compute_hflags_value(). Other than that HFLAGS_VR only appears in
ppc_tr_init_disas_context() so probably this should correspond to MSR_VR which the
e6500 manual calls MSR[SPV] and seems to be off in the register dump above. So maybe
it's a guest bug trying to execute Altivec instruction without enabling the vector unit?