Re: [Qemu-devel] Help needed testing on ppc

[Tom Musta <tommusta@gmail.com>]

On 5/6/2014 5:03 AM, BALATON Zoltan wrote:
> Hello,
> 
> As I got no reply on the qemu-ppc list so far I try here maybe there are some people who read this list but don't follow the ppc one.
> 
> I don't have the necessary hardware to do the testing needed for the patch below. Some context for the discussion can be found in this message: http://lists.nongnu.org/archive/html/qemu-ppc/2014-04/msg00277.html
> 
> It seems we have some code that contains instructions with a reserved bit set in an stwx instruction that works on real hardware but causes an invalid instruction exception on QEMU.
> 
> I'd appreciate some insight and help.
> 
> Regards,
> BALATON Zoltan

This is a bit tricky.  You appear to have code that has a reserved bit set.

Early forms of the PowerPC ISA (circa 1998) said this:  "All reserved fields in instructions should be zero.  If they are not, the instruction form
is invalid. ...  Any attempt to execute an invalid form of an instruction will cause the system illegal instruction error handler to
be invoked or yield boundedly undefined results."   QEMU, as a general rule, meets this requirement by causing illegal instruction
exceptions.

More modern versions of the ISA (circa 2006) say this: "Reserved fields in instructions are ignored by the processor.  This is a requirement
in the Server environment and is being phased into the Embedded environment. ... To maximize compatibility with future architecture
extensions, software must ensure that reserved fields in instructions contain zero and that defined fields of instructions do not contain
reserved values."  Technically, QEMU does not comply with the requirement in the first sentence;  and MorpOS does not comply with the third.

The newer form of the ISA is compatible with the older one since ignoring reserved fields is a valid implementation of "boundedly undefined."

A few questions and comments:

(1) Why is MorphOS using this invalid instruction form?  Would it be easier to fix the OS rather than QEMU?  Is there some undocumented
processor behavior that the code is dependent upon (e.g. is it actually expected CR0 to be set?).

(2) Your patch makes some store instructions compliant with the most recent ISAs but there are many other instructions that are not
addressed by the patch.  I think fixing only some will be a future source of confusion.

(3) The change risks breaking behavior on older designs which may very well have taken the illegal instruction interrupt.  Would it make more
sense to leave the masks as-is and instead make a single, isolated change in the decoder (gen_intermediate_code_internal).  This behavior
could be made conditional (configuration item?  processor family specific flag?).  Unfortunately, the masks also catch some invalid forms
that do not involve reserved fields (e.g. lq/stq to odd numbered registers).

(4) In general, modeling undefined behavior is a slippery slope.  I would much prefer to see the code fixed or justified before changing QEMU.