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?