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?

> From the e6500 manual:

"11.4.5 MSR, FPSCR, and VSCR

At reset, the MSR, FPSCR, and VSCR of each thread are set to 0. The FPSCR 
and VSCR do not require initialization and can be set at a later time 
before floating-point or AltiVec is used depending on which modes software 
wishes to operate in."

So this suggests it's not a problem with defaults unless the manual is 
wrong or there's some interaction between regs that should turn this bit 
on while setting another reg.

Then there may be two bugs: one that we don't have a handler for this 
exception to raise it in the guest and another in the guest that it does 
not init MSR properly. On a real machine the firmware may do it, so maybe 
we could do that in reset method if it works with u-boot as the problem 
was reported using -kernel but I think the ppce500 machine did not expect 
to have e6500 CPU so it probably does not try to do anything with this. 
It's probably a kind of imaginary machine (ppce500 with -cpu e6500) not 
emulating any real machine.

Mario, did you try booting the kernel with u-boot instead of using -kernel 
or do you have more info on how this works on real hardware? If you can 
find what code this stvx instruction is part of then we may see if it 
expects an exception that would make it fall back to non-altivec here. 
That may also explain why it works on real hardware but may also mean that 
it does not use altivec where it could.

Regards,
BALATON Zoltan