From: Alexander Graf <agraf@suse.de>
To: Tom Musta <tommusta@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Help needed testing on ppc
Date: Wed, 07 May 2014 18:59:47 +0200 [thread overview]
Message-ID: <536A6683.2070500@suse.de> (raw)
In-Reply-To: <536A51C9.6060308@gmail.com>
On 05/07/2014 05:31 PM, Tom Musta wrote:
> On 5/6/2014 6:17 PM, BALATON Zoltan wrote:
>> On Tue, 6 May 2014, Tom Musta wrote:
>>> On 5/6/2014 5:03 AM, BALATON Zoltan wrote:
>>>> I'd appreciate some insight and help.
> [snip]
>>> (1) Why is MorphOS using this invalid instruction form? Would it be easier to fix the OS rather than QEMU?
>> I don't know why is it used. I can ask the MorphOS developers but they did not seem to be too supportive so far and at least one of them expressed that they have no interest supporting other than their officially supported list of hardware at this time. So
>> I assume it is easier to fix QEMU than MorphOS and if it works on a real Mac then it should also work on QEMU's emulation of that Mac hardware.
>>
>>> Is there some undocumented processor behavior that the code is dependent upon (e.g. is it actually expected CR0 to be set?).
>> This is what the testing was supposed to find out but MorphOS seems to run better with the quoted patch so I don't think it depends on any other undocumented behaviour other than ignoring reserved bits but I have no definitive answer.
>>
> It still seems to me that setting a reserved instruction bit is an strange thing to do. It would be nice to at least
> have a justification from MorphOS. It is possible that no one even knows the answer.
>
>>> (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.>>
> Alex: do you have an opinion on this? Are you OK with changing masks for a few stores but not all instructions in general?
I would like to see someone just test all those load/store instructions
on old CPUs and see whether they fault. If none faults, we should just
be consistent and remove them for all. If say a 750 really only ignores
the Rc bit for stwx for some reason we should just model it accordingly.
Alex
next prev parent reply other threads:[~2014-05-07 17:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-06 10:03 [Qemu-devel] Help needed testing on ppc BALATON Zoltan
2014-05-06 12:20 ` Tom Musta
2014-05-06 23:17 ` BALATON Zoltan
2014-05-07 15:31 ` Tom Musta
2014-05-07 16:59 ` Alexander Graf [this message]
2014-06-12 0:49 ` BALATON Zoltan
2014-06-16 23:42 ` BALATON Zoltan
2014-06-17 8:42 ` Alexander Graf
2014-06-17 9:34 ` [Qemu-devel] [Qemu-ppc] " BALATON Zoltan
2014-06-17 9:37 ` Alexander Graf
2014-06-17 11:05 ` BALATON Zoltan
2014-06-17 11:54 ` Tom Musta
2014-06-17 15:17 ` BALATON Zoltan
2014-06-18 12:40 ` Tom Musta
2014-06-19 13:21 ` BALATON Zoltan
2014-06-23 17:07 ` Alexander Graf
2014-05-20 23:55 ` [Qemu-devel] " BALATON Zoltan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=536A6683.2070500@suse.de \
--to=agraf@suse.de \
--cc=qemu-devel@nongnu.org \
--cc=tommusta@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).