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

[Tom Musta]

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.