From: Alexander Graf <agraf@suse.de>
To: Thomas Monjalon <thomas_ml@monjalon.net>
Cc: Blue Swirl <blauwirbel@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 4/5] target-ppc: fix RFI by clearing upper bytes of MSR
Date: Tue, 18 May 2010 16:35:58 +0200 [thread overview]
Message-ID: <4BF2A5CE.8020709@suse.de> (raw)
In-Reply-To: <201005181600.27913.thomas_ml@monjalon.net>
Thomas Monjalon wrote:
> Alexander Graf wrote:
>
>> On 27.04.2010, at 17:31, Thomas Monjalon wrote:
>>
>>> Since commit 2ada0ed, "Return From Interrupt" is broken for PPC
>>> processors because the upper bits (POW, TGPR, ILE) of MSR were not
>>> cleared.
>>>
>> May I ask for your test case or how you stumbled over this? I haven't seen
>> any OS rely on this yet.
>>
>
> I'm running Linux for SBC834x in Qemu. The interrupt controller and board
> definition are not yet published.
>
Wow, I didn't know there were still new products based on e300.
> The boot process hang with the actual implementation of RFI.
>
Hrm.
>
>>> Below is a representation of MSR bits:
>>> 0 .. 12 13 14 15 16 .. 23 24 .. 31
>>> ————— POW TGPR ILE EE PR FP ME FE0 SE BE FE1 CE IP IR DR —— RI LE
>>>
>>> Only the 2 lower bytes (16-31) of MSR are saved to SRR1 before an
>>> interrupt. So only these bytes should be restored and the upper ones
>>> (0-15) cleared. But, referring to commit 2ada0ed, clearing all the upper
>>> bytes breaks Altivec. The compromise is to clear the well known bits
>>> (13-15).
>>>
>> IIRC this is vastly implementation dependent. Book3 lists the bits saved
>> when setting SRR1 explicitly and I haven't found a good rule of thumb yet.
>> RFI on the other hand is described as MSR <- SRR1. So I'm fairly sure RFI
>> is implemented correctly.
>>
>
> From the programming manual (MPCFPE32B):
> "The save/restore register 1 (SRR1) is used to save machine status (selected
> bits from the MSR and other implementation-specific status bits as well) on
> interrupts and to restore those values when rfi is executed.
> [..]
> When an interrupt occurs, SRR1 bits 1–4 and 10–15 are loaded with
> interrupt-specific information and MSR bits 16–23, 25–27, and 30–31 are
> placed into the corresponding bit positions of SRR1. Depending on the
> implementation, additional MSR bits may be copied to SRR1."
>
According to the 2.06 ISA, for example the DSI sets SRR1 to:
33:36 Set to 0
42:47 Set to 0
Others Loaded from the MSR
> From the e300 reference manual (e300CORERM):
> "The TGPR bit is cleared by an rfi instruction."
>
> My first try was to clear only TGPR. But it doesn't work properly if POW and
> ILE are not cleared.
>
According to the 2.06 ISA again, rfi does the following:
The contents of SRR1 are placed into the MSR. If the new MSR value does
not enable any pending exceptions, then the next instruction is fetched,
under control of the new MSR value, from the address SRR0 0:64 || 0b00.
(Note: VLE behavior may be different; see Book VLE).
Book VLE is the Variable Length Encoded Instructions Architecture, so
that doesn't come into play here.
If rfi would clear ILE, how would it be enabled then?
Alex
next prev parent reply other threads:[~2010-05-18 14:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-27 15:31 [Qemu-devel] [PATCH v2 0/5] fix & clean PPC e300 Thomas Monjalon
2010-04-27 15:31 ` [Qemu-devel] [PATCH v2 1/5] target-ppc: fix processor versions (PVR) for e300 Thomas Monjalon
2010-04-27 15:31 ` [Qemu-devel] [PATCH v2 2/5] target-ppc: fix interrupt vectors for MPC603 and e300 Thomas Monjalon
2010-04-27 15:31 ` [Qemu-devel] [PATCH v2 3/5] target-ppc: exception model of 603e inherits from 603 Thomas Monjalon
2010-04-27 15:31 ` [Qemu-devel] [PATCH v2 4/5] target-ppc: fix RFI by clearing upper bytes of MSR Thomas Monjalon
2010-05-02 8:12 ` Alexander Graf
2010-05-18 14:00 ` Thomas Monjalon
2010-05-18 14:35 ` Alexander Graf [this message]
2010-05-18 15:17 ` Thomas Monjalon
2010-04-27 15:31 ` [Qemu-devel] [PATCH v2 5/5] ppc: remove dead code Thomas Monjalon
2010-04-27 18:47 ` [Qemu-devel] Re: [PATCH v2 0/5] fix & clean PPC e300 Blue Swirl
2010-04-27 21:18 ` Thomas Monjalon
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=4BF2A5CE.8020709@suse.de \
--to=agraf@suse.de \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=thomas_ml@monjalon.net \
/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).