[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: e6500 stvx instruction

From: BALATON Zoltan
Subject: Re: e6500 stvx instruction
Date: Wed, 16 Jun 2021 15:26:26 +0200 (CEST)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]