From "BALATON Zoltan" balaton@eik.bme.hu
To "Mark Cave-Ayland" mark.cave-ayland@ilande.co.uk
Cc qemu-ppc@nongnu.org, mario@locati.it
Date Wed, 16 Jun 2021 15:26:26 +0200 (CEST)
Subject Re: e6500 stvx instruction
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