Re: e6500 stvx instruction

[BALATON Zoltan]

On Wed, 16 Jun 2021, Mark Cave-Ayland wrote:
> On 16/06/2021 10:57, BALATON Zoltan wrote:
> > 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?
>
> I guess it could be either the guest is trying to execute Altivec 
> instructions without configuring the MSR correctly, or perhaps that the 
> default value of the MSR is incorrect and should have the SPV bit set for 
> that particular CPU?

I don't know but thinking about it more I think in any case it should not 
trip an assert in QEMU. If it's an exception that can happen on a real 
e6500 then we're missing a handler for that that would correctly raise it 
in the guest so it could fall back to a non-Altivec path or do whatever 
appropriate. If it can't happen on real hardware then what's the MSR bit 
is for? I think we need some input from somebody who knows more about 
e6500 here. Maybe Mario could try to check on real hardware or ask NXP 
about how the real CPU works for this case then we could implement that in 
QEMU. Or does anybody know e6500 here on the list?

Regards,
BALATON Zoltan