Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Tue, 2016-06-21 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2016-06-21 at 09:21 +0100, Mark Cave-Ayland wrote:
> > A quick check with "info mtree" shows that this area of memory is
> > PCI
> > configuration space. There was a patch added to uninorth in order
> > to
> > suppress some PCI warnings on Darwin boot found by going over the
> > source
> > to the Darwin MacRISC driver which resulted in the patch at
> > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=98ae3b27d57b59c6dc9a
> > 74e6351e339523c16def.
> > Maybe it could be related to that?
> > 
> > > I'll still cleanup & submit my current crop of fixes in case
> > > somebody
> > > wants to have a look.
> > 
> > Not sure I can help much here, however I can give everything a good
> > test
> > and make sure that it doesn't break :)
> 
> I'll double check, I used to know that HW well and might even have
> access to some docs internally but that specific f280_ doesn't
> look
> like something that would mean anything on a machine with macio at
> 8000_ 
> 
You are right, it's PCI1 config space. I'll dig more later.

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Tue, 2016-06-21 at 09:21 +0100, Mark Cave-Ayland wrote:
> A quick check with "info mtree" shows that this area of memory is PCI
> configuration space. There was a patch added to uninorth in order to
> suppress some PCI warnings on Darwin boot found by going over the source
> to the Darwin MacRISC driver which resulted in the patch at
> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=98ae3b27d57b59c6dc9a74e6351e339523c16def.
> Maybe it could be related to that?
> 
> > I'll still cleanup & submit my current crop of fixes in case somebody
> > wants to have a look.
> 
> Not sure I can help much here, however I can give everything a good test
> and make sure that it doesn't break :)

I'll double check, I used to know that HW well and might even have
access to some docs internally but that specific f280_ doesn't look
like something that would mean anything on a machine with macio at
8000_ 

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Mark Cave-Ayland]

On 20/06/16 10:32, Benjamin Herrenschmidt wrote:

> On Mon, 2016-06-20 at 18:02 +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2016-06-20 at 17:08 +1000, Benjamin Herrenschmidt wrote:
>>>  
>>> That fixed, it dies elsewhere in something related to page faults,
>>> still digging.
>>>  
>> Next problem: Darwin kernel assumes DSISR is 0 on a 0x380 exception !
>>
>> qemu was leaving it to whatever value it had before. Kaboom.
>>
>> Now it crashes a bit further :-)
> 
> Right so it tries to load a MacRISC2 PE because we don't really emulate
> a MacRISC4 with U3 etc... and that isn't going to do it any good,
> really..
> 
> I'm not *actually* sure where MacOS gets itself into a spin, it seems
> to be poking at something at 0xf280_ which is somewhat odd as this
> would be the IO space and we have nothing there afaik, but I am not
> enough of a MacOS expert to figure out quite how to track down which
> kext it gets into etc...
> 
> In any case, the machine we give it is definitely nowhere near a real
> G5 and that might be the main reason. More work needed.

A quick check with "info mtree" shows that this area of memory is PCI
configuration space. There was a patch added to uninorth in order to
suppress some PCI warnings on Darwin boot found by going over the source
to the Darwin MacRISC driver which resulted in the patch at
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=98ae3b27d57b59c6dc9a74e6351e339523c16def.
Maybe it could be related to that?

> I'll still cleanup & submit my current crop of fixes in case somebody
> wants to have a look.

Not sure I can help much here, however I can give everything a good test
and make sure that it doesn't break :)


ATB,

Mark.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Alexander Graf]

On 06/20/2016 11:32 AM, Benjamin Herrenschmidt wrote:

On Mon, 2016-06-20 at 18:02 +1000, Benjamin Herrenschmidt wrote:

On Mon, 2016-06-20 at 17:08 +1000, Benjamin Herrenschmidt wrote:
  
That fixed, it dies elsewhere in something related to page faults,

still digging.
  

Next problem: Darwin kernel assumes DSISR is 0 on a 0x380 exception !

qemu was leaving it to whatever value it had before. Kaboom.

Now it crashes a bit further :-)

Right so it tries to load a MacRISC2 PE because we don't really emulate
a MacRISC4 with U3 etc... and that isn't going to do it any good,
really..

I'm not *actually* sure where MacOS gets itself into a spin, it seems
to be poking at something at 0xf280_ which is somewhat odd as this
would be the IO space and we have nothing there afaik, but I am not
enough of a MacOS expert to figure out quite how to track down which
kext it gets into etc...

In any case, the machine we give it is definitely nowhere near a real
G5 and that might be the main reason. More work needed.

I'll still cleanup & submit my current crop of fixes in case somebody
wants to have a look.


Since the patches do get you further along and get us closer to an 
actual 970, I guess it's a good idea to actually push them into the tree.


Alex

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Mon, 2016-06-20 at 18:02 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2016-06-20 at 17:08 +1000, Benjamin Herrenschmidt wrote:
> >  
> > That fixed, it dies elsewhere in something related to page faults,
> > still digging.
> >  
> Next problem: Darwin kernel assumes DSISR is 0 on a 0x380 exception !
> 
> qemu was leaving it to whatever value it had before. Kaboom.
> 
> Now it crashes a bit further :-)

Right so it tries to load a MacRISC2 PE because we don't really emulate
a MacRISC4 with U3 etc... and that isn't going to do it any good,
really..

I'm not *actually* sure where MacOS gets itself into a spin, it seems
to be poking at something at 0xf280_ which is somewhat odd as this
would be the IO space and we have nothing there afaik, but I am not
enough of a MacOS expert to figure out quite how to track down which
kext it gets into etc...

In any case, the machine we give it is definitely nowhere near a real
G5 and that might be the main reason. More work needed.

I'll still cleanup & submit my current crop of fixes in case somebody
wants to have a look.

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Mon, 2016-06-20 at 08:17 +0200, Cédric Le Goater wrote:
> 
> The current patch does not need fixing. I will send the OpenBIOS
> patch 
> shortly after I have looked at the FPU exception.
> 
> Linux ppc behaves the same on a 970. So we will need to fix the
> 'rfi's there also. 

What do you mean ? where ?

Linux should be only using rfid on 970...

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/20/2016 09:47 AM, Thomas Huth wrote:
> On 20.06.2016 08:17, Cédric Le Goater wrote:
>> On 06/20/2016 04:19 AM, David Gibson wrote:
>>> On Mon, Jun 20, 2016 at 07:12:38AM +1000, Benjamin Herrenschmidt wrote:
 On Sun, 2016-06-19 at 19:23 +0200, Cédric Le Goater wrote:
>> You can run a 32-bit OS or firmware on ppc64, but it needs to know that
>> it's running on a 64-bit chip and do a few things differently.
>
> yes sure but qemu would still allow rfi under 64bit CPUs, that is what 
> I was concerned about. Is that ok ? 

 Why ? A real CPU won't allow it, why should we ?
>>>
>>> We shouldn't.  However, I'm inclined to in for now, until we have an
>>> OpenBIOS fix actually committed.  I'd prefer to keep the existing
>>> setup sorta-working when the current situation is unlikely to break
>>> working code, even though it's definitely wrong.
>>>
>>> BenH or Cédric, if you want to resend the hrfi fix patch with the
>>> 64-bit rfi support left in for no, that would be good.
>>
>> The current patch does not need fixing. I will send the OpenBIOS patch 
>> shortly after I have looked at the FPU exception.
>>
>> Linux ppc behaves the same on a 970. So we will need to fix the 'rfi's
>> there also. 
> 
> Really? Wow, that surprises me. That OpenBIOS code likely never ran on a
> real 970 hardware, so that's not too much surprising that the "rfi"
> sneaked in there, but the Linux kernel certainly ran on a real 970 once,
> so I wonder why it's not properly using rfid for the 970 yet?

I just learned that the support for 970 was removed from the 32bit kernel
long time ago. False alarm, my bad.

C.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Mon, 2016-06-20 at 09:47 +0200, Thomas Huth wrote:
> > Linux ppc behaves the same on a 970. So we will need to fix the 'rfi's
> > there also. 
> 
> Really? Wow, that surprises me. That OpenBIOS code likely never ran on a
> real 970 hardware, so that's not too much surprising that the "rfi"
> sneaked in there, but the Linux kernel certainly ran on a real 970 once,
> so I wonder why it's not properly using rfid for the 970 yet?

It's working, Cedric was looking at the 32-bit kernel :-)

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Mon, 2016-06-20 at 08:10 +0200, Cédric Le Goater wrote:
> That is how I feel also. So, why don't we just remove the op code in the 
> instruction sets from the 32bit CPUs instead of leaving it and testing 
> for PPC_SEGMENT_64B ? or is there some reasons we want to keep it around ? 

Ah no

Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Mon, 2016-06-20 at 17:08 +1000, Benjamin Herrenschmidt wrote:
> 
> That fixed, it dies elsewhere in something related to page faults,
> still digging.
> 
Next problem: Darwin kernel assumes DSISR is 0 on a 0x380 exception !

qemu was leaving it to whatever value it had before. Kaboom.

Now it crashes a bit further :-)

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Thomas Huth]

On 20.06.2016 08:17, Cédric Le Goater wrote:
> On 06/20/2016 04:19 AM, David Gibson wrote:
>> On Mon, Jun 20, 2016 at 07:12:38AM +1000, Benjamin Herrenschmidt wrote:
>>> On Sun, 2016-06-19 at 19:23 +0200, Cédric Le Goater wrote:
> You can run a 32-bit OS or firmware on ppc64, but it needs to know that
> it's running on a 64-bit chip and do a few things differently.

 yes sure but qemu would still allow rfi under 64bit CPUs, that is what 
 I was concerned about. Is that ok ? 
>>>
>>> Why ? A real CPU won't allow it, why should we ?
>>
>> We shouldn't.  However, I'm inclined to in for now, until we have an
>> OpenBIOS fix actually committed.  I'd prefer to keep the existing
>> setup sorta-working when the current situation is unlikely to break
>> working code, even though it's definitely wrong.
>>
>> BenH or Cédric, if you want to resend the hrfi fix patch with the
>> 64-bit rfi support left in for no, that would be good.
> 
> The current patch does not need fixing. I will send the OpenBIOS patch 
> shortly after I have looked at the FPU exception.
> 
> Linux ppc behaves the same on a 970. So we will need to fix the 'rfi's
> there also. 

Really? Wow, that surprises me. That OpenBIOS code likely never ran on a
real 970 hardware, so that's not too much surprising that the "rfi"
sneaked in there, but the Linux kernel certainly ran on a real 970 once,
so I wonder why it's not properly using rfid for the 970 yet?

 Thomas

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Alexander Graf]

On 20.06.16 09:08, Benjamin Herrenschmidt wrote:
> On Mon, 2016-06-20 at 08:35 +1000, Benjamin Herrenschmidt wrote:
>>  ,
>> Ok so Darwin uses some of the HSPRG etc... that we don't emulate on
>> the 970 so I suspect it never worked. I've added them but something
>> else breaks, I'll dig, I have the kernel source so it shouldn't be
>> too hard
>> ;-)
> 
> Well, it ended up being harder than I thought. In fact I'm not there
> yet ! So the Darwin VM layer dies early because HID5 isn't set
> properly, thus dcbz is doing 128 bytes clear instead of 32, clobbering
> things.
> 
> It looks like Apple's kernel doesn't set the right default in HID5, so
> we have to either do it in openbios or in qemu. Alex, what did you find

Uh, I'm fairy sure XNU sets HID5.

> out back in the day ? Or you never bothered running a 64-bit MacOS
> under PR KVM ?

I don't think I ever had 64bit Mac OS X working in TCG or KVM :).


Alex

> That fixed, it dies elsewhere in something related to page faults,
> still digging.
> 
> Cheers,
> Ben.
> 

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Mon, 2016-06-20 at 08:35 +1000, Benjamin Herrenschmidt wrote:
> ,
> Ok so Darwin uses some of the HSPRG etc... that we don't emulate on
> the 970 so I suspect it never worked. I've added them but something
> else breaks, I'll dig, I have the kernel source so it shouldn't be
> too hard
> ;-)

Well, it ended up being harder than I thought. In fact I'm not there
yet ! So the Darwin VM layer dies early because HID5 isn't set
properly, thus dcbz is doing 128 bytes clear instead of 32, clobbering
things.

It looks like Apple's kernel doesn't set the right default in HID5, so
we have to either do it in openbios or in qemu. Alex, what did you find
out back in the day ? Or you never bothered running a 64-bit MacOS
under PR KVM ?

That fixed, it dies elsewhere in something related to page faults,
still digging.

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/20/2016 04:19 AM, David Gibson wrote:
> On Mon, Jun 20, 2016 at 07:12:38AM +1000, Benjamin Herrenschmidt wrote:
>> On Sun, 2016-06-19 at 19:23 +0200, Cédric Le Goater wrote:
 You can run a 32-bit OS or firmware on ppc64, but it needs to know that
 it's running on a 64-bit chip and do a few things differently.
>>>
>>> yes sure but qemu would still allow rfi under 64bit CPUs, that is what 
>>> I was concerned about. Is that ok ? 
>>
>> Why ? A real CPU won't allow it, why should we ?
> 
> We shouldn't.  However, I'm inclined to in for now, until we have an
> OpenBIOS fix actually committed.  I'd prefer to keep the existing
> setup sorta-working when the current situation is unlikely to break
> working code, even though it's definitely wrong.
>
> BenH or Cédric, if you want to resend the hrfi fix patch with the
> 64-bit rfi support left in for no, that would be good.

The current patch does not need fixing. I will send the OpenBIOS patch 
shortly after I have looked at the FPU exception.

Linux ppc behaves the same on a 970. So we will need to fix the 'rfi's
there also. 

C.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/19/2016 11:12 PM, Benjamin Herrenschmidt wrote:
> On Sun, 2016-06-19 at 19:23 +0200, Cédric Le Goater wrote:
>>> You can run a 32-bit OS or firmware on ppc64, but it needs to know that
>>> it's running on a 64-bit chip and do a few things differently.
>>
>> yes sure but qemu would still allow rfi under 64bit CPUs, that is what 
>> I was concerned about. Is that ok ? 
> 
> Why ? A real CPU won't allow it, why should we ?

That is how I feel also. So, why don't we just remove the op code in the 
instruction sets from the 32bit CPUs instead of leaving it and testing 
for PPC_SEGMENT_64B ? or is there some reasons we want to keep it around ? 

Cheers,

C.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[David Gibson]

On Mon, Jun 20, 2016 at 07:12:38AM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2016-06-19 at 19:23 +0200, Cédric Le Goater wrote:
> > > You can run a 32-bit OS or firmware on ppc64, but it needs to know that
> > > it's running on a 64-bit chip and do a few things differently.
> > 
> > yes sure but qemu would still allow rfi under 64bit CPUs, that is what 
> > I was concerned about. Is that ok ? 
> 
> Why ? A real CPU won't allow it, why should we ?

We shouldn't.  However, I'm inclined to in for now, until we have an
OpenBIOS fix actually committed.  I'd prefer to keep the existing
setup sorta-working when the current situation is unlikely to break
working code, even though it's definitely wrong.

BenH or Cédric, if you want to resend the hrfi fix patch with the
64-bit rfi support left in for no, that would be good.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Mon, 2016-06-20 at 08:15 +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2016-06-19 at 19:21 +0200, Cédric Le Goater wrote:
> > But, I could not boot  ./darwinppc-602.cdr with on a 970. That
> > might
> > be another issue.
> 
> Right, the issue is that the kernel in Darwin 6.0.2 doesn't support
> the
> 970 :-)
> 
> I think the first MacOS X to support 970 was some special build of
> 10.2.8 or something along those lines, which is slightly after Darwin
> 6.0.2 was released.
> 
> Now that being said, Darwin 8.0.1 is also not booting in 970 and that
> is possible a real issue, but I don't think it's realted to those
> patches since that happens with current upstream7
> 
> I can look into it later (they both boot fine with a 7400).

Ok so Darwin uses some of the HSPRG etc... that we don't emulate on the
970 so I suspect it never worked. I've added them but something else
breaks, I'll dig, I have the kernel source so it shouldn't be too hard
;-)

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Sun, 2016-06-19 at 19:21 +0200, Cédric Le Goater wrote:
> But, I could not boot  ./darwinppc-602.cdr with on a 970. That might
> be another issue.

Right, the issue is that the kernel in Darwin 6.0.2 doesn't support the
970 :-)

I think the first MacOS X to support 970 was some special build of
10.2.8 or something along those lines, which is slightly after Darwin
6.0.2 was released.

Now that being said, Darwin 8.0.1 is also not booting in 970 and that
is possible a real issue, but I don't think it's realted to those
patches since that happens with current upstream7

I can look into it later (they both boot fine with a 7400).

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Sun, 2016-06-19 at 19:23 +0200, Cédric Le Goater wrote:
> > You can run a 32-bit OS or firmware on ppc64, but it needs to know that
> > it's running on a 64-bit chip and do a few things differently.
> 
> yes sure but qemu would still allow rfi under 64bit CPUs, that is what 
> I was concerned about. Is that ok ? 

Why ? A real CPU won't allow it, why should we ?

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/19/2016 04:08 PM, Benjamin Herrenschmidt wrote:
> On Sun, 2016-06-19 at 14:49 +0200, Cédric Le Goater wrote:
>>> So my test is correct in the context of what we emulate today.
>>
>> OK. so this is an openbios issue when run under a ppc64. shouldn't we 
>> be using an openbios-ppc64 in that case ?  
>>
>>
>> We could be more strict with the rfi instruction. 
> 
> Well, ppc64 isn't backward compatible with ppc32 at the supervisor
> level, at least not on server chips (it is on bookE chips). So yes it's
> an OpenBIOS problem but that doesn't mean we have to use openbios-ppc64 
> :-) 
> 
> You can run a 32-bit OS or firmware on ppc64, but it needs to know that
> it's running on a 64-bit chip and do a few things differently.

yes sure but qemu would still allow rfi under 64bit CPUs, that is what 
I was concerned about. Is that ok ? 

C.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/19/2016 03:00 PM, Alexander Graf wrote:
> 
> 
>> Am 19.06.2016 um 14:49 schrieb Cédric Le Goater :
>>
>>> On 06/19/2016 01:35 AM, Benjamin Herrenschmidt wrote:
 On Fri, 2016-06-17 at 16:32 +0200, Cédric Le Goater wrote:
 The instruction set PPC_POWER_BR contains nearly all the deleted 
 instructions from isa2. rfi is not part of it and should. Also, only 
 the cpus "PowerPC 601*" make a use of it in their insns_flags.
>>>
>>> Are you sure those arent the old POWER instructions as in pre-powerPC
>>> architecture that 601 (and only 601) supports ?
>>
>> OK. I get it now.  
>>
>> All the deleted instructions from POWER are/should be under the set 
>> PPC_POWER.
>>
>> All the deleted instructions from POWER2 are under the set PPC_POWER2.
>>
>> None of these sets are in use.
>>
>>
>> For the  "PowerPC 601*" cpus, we moved a couple from set PPC_POWER to 
>> subset PPC_POWER_BR.
>>
>> rfi is special. it is under PPC_FLOW and all CPUs can use it
>>
 So, we would want this set to be in all the "PowerPC {6,7}*" cpus. 
 Are there more ?
>>>
>>> All 32-bit hash based CPUs are arch 1.x and support rfi
>>>
>>> All 64-bit hash based CPUs we support (ie, POWER4 and later) are
>>> architecture 2.x and later.
>>>
>>> So my test is correct in the context of what we emulate today.
>>
>> OK. so this is an openbios issue when run under a ppc64. shouldn't we 
>> be using an openbios-ppc64 in that case ?  
> 
> No, openbios can run on both. Just add a runtime check in openbios for 
> rfi/rfid.


OK. 

How's that for a start ? Seems to work. 

But, I could not boot  ./darwinppc-602.cdr with on a 970. That might
be another issue.

Thanks,

C.

From: Cédric Le Goater 
Subject: [PATCH] ppc: use rfid when running under a CPU from the 970 family.
Date: Sun, 19 Jun 2016 15:48:41 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Cédric Le Goater 
---
 arch/ppc/qemu/start.S |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

Index: openbios.git/arch/ppc/qemu/start.S
===
--- openbios.git.orig/arch/ppc/qemu/start.S
+++ openbios.git/arch/ppc/qemu/start.S
@@ -148,7 +148,20 @@
ll  r31,(35 * ULONG_SIZE)(r1) ; \
 .endif ; \
ll  r1,(1 * ULONG_SIZE)(r1) ;   /* restore stack at last */ \
-   rfi
+   mtsprg1 r3 ; \
+   mfpvr r3 ; \
+   rlwinm  r3,r3,16,16,31 ; \
+   cmplwi  cr1,r3,0x0039 ; /* 970 CPUs */ \
+   beq- cr1,0f ; \
+   cmplwi  cr1,r3,0x003C ; /* 970fx CPUs */ \
+   beq- cr1,0f ; \
+   cmplwi  cr1,r3,0x0044 ; /* 970mp CPUs */ \
+   beq- cr1,0f ; \
+   mfsprg1 r3 ; \
+   rfi ; \
+0: ; \
+   mfsprg1 r3 ; \
+   rfid
 
 // PPC32
 

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Sun, 2016-06-19 at 14:49 +0200, Cédric Le Goater wrote:
> > So my test is correct in the context of what we emulate today.
> 
> OK. so this is an openbios issue when run under a ppc64. shouldn't we 
> be using an openbios-ppc64 in that case ?  
> 
> 
> We could be more strict with the rfi instruction. 

Well, ppc64 isn't backward compatible with ppc32 at the supervisor
level, at least not on server chips (it is on bookE chips). So yes it's
an OpenBIOS problem but that doesn't mean we have to use openbios-ppc64 
:-) 

You can run a 32-bit OS or firmware on ppc64, but it needs to know that
it's running on a 64-bit chip and do a few things differently.

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Alexander Graf]

> Am 19.06.2016 um 14:49 schrieb Cédric Le Goater :
> 
>> On 06/19/2016 01:35 AM, Benjamin Herrenschmidt wrote:
>>> On Fri, 2016-06-17 at 16:32 +0200, Cédric Le Goater wrote:
>>> The instruction set PPC_POWER_BR contains nearly all the deleted 
>>> instructions from isa2. rfi is not part of it and should. Also, only 
>>> the cpus "PowerPC 601*" make a use of it in their insns_flags.
>> 
>> Are you sure those arent the old POWER instructions as in pre-powerPC
>> architecture that 601 (and only 601) supports ?
> 
> OK. I get it now.  
> 
> All the deleted instructions from POWER are/should be under the set 
> PPC_POWER.
> 
> All the deleted instructions from POWER2 are under the set PPC_POWER2.
> 
> None of these sets are in use.
> 
> 
> For the  "PowerPC 601*" cpus, we moved a couple from set PPC_POWER to 
> subset PPC_POWER_BR.
> 
> rfi is special. it is under PPC_FLOW and all CPUs can use it
> 
>>> So, we would want this set to be in all the "PowerPC {6,7}*" cpus. 
>>> Are there more ?
>> 
>> All 32-bit hash based CPUs are arch 1.x and support rfi
>> 
>> All 64-bit hash based CPUs we support (ie, POWER4 and later) are
>> architecture 2.x and later.
>> 
>> So my test is correct in the context of what we emulate today.
> 
> OK. so this is an openbios issue when run under a ppc64. shouldn't we 
> be using an openbios-ppc64 in that case ?  

No, openbios can run on both. Just add a runtime check in openbios for rfi/rfid.

Alex

> 
> 
> We could be more strict with the rfi instruction. 
> 
> 
> C.
> 

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/19/2016 01:35 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2016-06-17 at 16:32 +0200, Cédric Le Goater wrote:
>> The instruction set PPC_POWER_BR contains nearly all the deleted 
>> instructions from isa2. rfi is not part of it and should. Also, only 
>> the cpus "PowerPC 601*" make a use of it in their insns_flags.
> 
> Are you sure those arent the old POWER instructions as in pre-powerPC
> architecture that 601 (and only 601) supports ?

OK. I get it now.  

All the deleted instructions from POWER are/should be under the set 
PPC_POWER.

All the deleted instructions from POWER2 are under the set PPC_POWER2.

None of these sets are in use.


For the  "PowerPC 601*" cpus, we moved a couple from set PPC_POWER to 
subset PPC_POWER_BR.

rfi is special. it is under PPC_FLOW and all CPUs can use it

>> So, we would want this set to be in all the "PowerPC {6,7}*" cpus. 
>> Are there more ? 
> 
> All 32-bit hash based CPUs are arch 1.x and support rfi
> 
> All 64-bit hash based CPUs we support (ie, POWER4 and later) are
> architecture 2.x and later.
> 
> So my test is correct in the context of what we emulate today.

OK. so this is an openbios issue when run under a ppc64. shouldn't we 
be using an openbios-ppc64 in that case ?  


We could be more strict with the rfi instruction. 


C.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Fri, 2016-06-17 at 16:32 +0200, Cédric Le Goater wrote:
> The instruction set PPC_POWER_BR contains nearly all the deleted 
> instructions from isa2. rfi is not part of it and should. Also, only 
> the cpus "PowerPC 601*" make a use of it in their insns_flags.

Are you sure those arent the old POWER instructions as in pre-powerPC
architecture that 601 (and only 601) supports ?

> So, we would want this set to be in all the "PowerPC {6,7}*" cpus. 
> Are there more ? 

All 32-bit hash based CPUs are arch 1.x and support rfi

All 64-bit hash based CPUs we support (ie, POWER4 and later) are
architecture 2.x and later.

So my test is correct in the context of what we emulate today.

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Fri, 2016-06-17 at 13:02 +0200, Thomas Huth wrote:
> According to the PPC970FX user manual that I have:
> 
> "The 970FX does not provide support for the following optional or
>  obsolete instructions (or instruction forms).
>  Attempted use of these will result in an illegal instruction type
>  program interrupt.
>   [...]
>   · rfi - Return from interrupt (obsolete) "
> 
> So if OpenBIOS is using this instruction in 970 mode, it's maybe
> OpenBIOS that should be fixed instead?

Right, I was about to say that ... This instruction *might* have
existed on POWER3 which we don't emulate, but definitely not on
POWER4 and later.

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

<1465795496-15071-2-git-send-email-...@kaod.org>


<20160616010702.gi28...@voom.fritz.box>


<20160617022731.ga19...@voom.fritz.box> <57639095.5010...@kaod.org>


<576392b1.6030...@kaod.org> <5763a258.2010...@redhat.com>
 <5763d3ef.6060...@kaod.org>
Organization: IBM Australia
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.20.3 (3.20.3-1.fc24) 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

On Fri, 2016-06-17 at 12:41 +0200, Cédric Le Goater wrote:
> 
> This is too brutal :
> 
> +    /* This instruction doesn't exist anymore on 64-bit server
> +     * processors compliant with arch 2.x
> +     */
> +    if (ctx->insns_flags & PPC_SEGMENT_64B) {
> +        gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
> +        return;
> +    }
>         
> 
> There are a couple of instructions which have been deleted from 
> ISA 2.x. rfi is one of them. Could we use a insn_flag to filter
> them  ? 

Why is it too brutal ? We don't really support pre-arch 2.0 64-bit
processors do we ?

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/17/2016 01:02 PM, Thomas Huth wrote:
> On 17.06.2016 12:41, Cédric Le Goater wrote:
>> On 06/17/2016 09:10 AM, Thomas Huth wrote:
>>> On 17.06.2016 08:03, Cédric Le Goater wrote:
 On 06/17/2016 07:54 AM, Cédric Le Goater wrote:
> On 06/17/2016 04:27 AM, David Gibson wrote:
>> On Thu, Jun 16, 2016 at 11:07:02AM +1000, David Gibson wrote:
>>> On Mon, Jun 13, 2016 at 07:24:47AM +0200, Cédric Le Goater wrote:
 From: Benjamin Herrenschmidt 

 This reworks emulation of the various "rfi" variants. I removed
 some masking bits that I couldn't make sense of, the only bit that
 I am aware we should mask here is POW, the CPU's MSR mask should
 take care of the rest.

 This also fixes some problems when running 32-bit userspace under
 a 64-bit kernel.
>>
>> he.
>>
 Signed-off-by: Benjamin Herrenschmidt 
 Reviewed-by: David Gibson 
>>>
>>> I've merged this patch to ppc-for-2.7.
>>
>> ..and now I've removed it again.  It seems that this breaks Thomas'
>> new test that OpenBIOS runs on the mac machine types.  Not sure why,
>> but we need to figure that out before I apply.
>
> Just this patch ? I booted a macosx image with it. but maybe just a mac99.
> I will check today.

 With your branch ppc-for-2.7 (at commit aba2e6258d86) + the 
 "ppc: Fix rfi/rfid/hrfi/... emulation" patch, these guests : 

qemu-system-ppc -cdrom ./darwinppc-602.cdr -boot d 
qemu-system-ppc -M mac99 -cdrom ./darwinppc-602.cdr -boot d 
>>>^
>>>|
>>> You're missing the "64" here ;-)
>>>
 reach the installer macosx installer.
>>>
>>> It seems to be only failing for the 64-bit builds - and there only for
>>> the PPC970 CPU (which is the default for the mac99 machine in 64-bit
>>> builds):
>>>
>>> qemu-system-ppc64 -nographic -cpu 750 -M mac99 ==> works fine
>>>
>>> qemu-system-ppc64 -nographic -cpu 970 -M mac99 ==> hangs
>>
>>
>> This is too brutal :
>>
>> +/* This instruction doesn't exist anymore on 64-bit server
>> + * processors compliant with arch 2.x
>> + */
>> +if (ctx->insns_flags & PPC_SEGMENT_64B) {
>> +gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
>> +return;
>> +}
>>
>> There are a couple of instructions which have been deleted from 
>> ISA 2.x. rfi is one of them. Could we use a insn_flag to filter
>> them  ? 
> 
> According to the PPC970FX user manual that I have:
> 
> "The 970FX does not provide support for the following optional or
>  obsolete instructions (or instruction forms).
>  Attempted use of these will result in an illegal instruction type
>  program interrupt.
>   [...]
>   · rfi - Return from interrupt (obsolete) "
> 
> So if OpenBIOS is using this instruction in 970 mode, it's maybe
> OpenBIOS that should be fixed instead?

Both, then :) rfi is considered implemented for all cpu. But it should 
not. 

The instruction set PPC_POWER_BR contains nearly all the deleted 
instructions from isa2. rfi is not part of it and should. Also, only 
the cpus "PowerPC 601*" make a use of it in their insns_flags.

So, we would want this set to be in all the "PowerPC {6,7}*" cpus. 
Are there more ? 

Thanks,

C. 

dc->desc = "PowerPC 401";
dc->desc = "PowerPC 401x2";
dc->desc = "PowerPC 401x3";
dc->desc = "IOP480";
dc->desc = "PowerPC 403";
dc->desc = "PowerPC 403 GCX";
dc->desc = "PowerPC 405";
dc->desc = "PowerPC 440 EP";
dc->desc = "PowerPC 440 GP";
dc->desc = "PowerPC 440x4";
dc->desc = "PowerPC 440x5";
dc->desc = "PowerPC 440x5 with double precision FPU";
dc->desc = "PowerPC 460 (guessed)";
dc->desc = "PowerPC 460F (guessed)";
dc->desc = "Freescale 5xx cores (aka RCPU)";
dc->desc = "Freescale 8xx cores (aka PowerQUICC)";
dc->desc = "PowerPC G2";
dc->desc = "PowerPC G2LE";
dc->desc = "e200 core";
dc->desc = "e300 core";
dc->desc = "e500v1 core";
dc->desc = "e500v2 core";
dc->desc = "e500mc core";
dc->desc = "e5500 core";
dc->desc = "POWER";
dc->desc = "PowerPC 601";
pcc->insns_flags = PPC_INSNS_BASE | PPC_STRING | PPC_POWER_BR |
dc->desc = "PowerPC 601v";
pcc->insns_flags = PPC_INSNS_BASE | PPC_STRING | PPC_POWER_BR |
dc->desc = "PowerPC 602";
dc->desc = "PowerPC 603";
dc->desc = "PowerPC 603e";
dc->desc = "PowerPC 604";
dc->desc = "PowerPC 604E";
dc->desc = "PowerPC 740";
dc->desc = "PowerPC 750";
dc->desc = "PowerPC 750 CL";
dc->desc = "PowerPC 750CX";
dc->desc = "PowerPC 750FX";
dc->desc = "PowerPC 750GX";
dc->desc = "PowerPC 745";
dc->desc = "PowerPC 755";
dc->desc = "PowerPC 7400 (aka G4)";
dc->desc = "PowerPC 7410 (aka G4)";
dc->desc = "PowerPC 7440 (aka G4)";
dc->desc = "PowerPC 7450 (aka G4)";

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Alexander Graf]

On 17.06.16 13:02, Thomas Huth wrote:
> On 17.06.2016 12:41, Cédric Le Goater wrote:
>> On 06/17/2016 09:10 AM, Thomas Huth wrote:
>>> On 17.06.2016 08:03, Cédric Le Goater wrote:
 On 06/17/2016 07:54 AM, Cédric Le Goater wrote:
> On 06/17/2016 04:27 AM, David Gibson wrote:
>> On Thu, Jun 16, 2016 at 11:07:02AM +1000, David Gibson wrote:
>>> On Mon, Jun 13, 2016 at 07:24:47AM +0200, Cédric Le Goater wrote:
 From: Benjamin Herrenschmidt 

 This reworks emulation of the various "rfi" variants. I removed
 some masking bits that I couldn't make sense of, the only bit that
 I am aware we should mask here is POW, the CPU's MSR mask should
 take care of the rest.

 This also fixes some problems when running 32-bit userspace under
 a 64-bit kernel.
>>
>> he.
>>
 Signed-off-by: Benjamin Herrenschmidt 
 Reviewed-by: David Gibson 
>>>
>>> I've merged this patch to ppc-for-2.7.
>>
>> ..and now I've removed it again.  It seems that this breaks Thomas'
>> new test that OpenBIOS runs on the mac machine types.  Not sure why,
>> but we need to figure that out before I apply.
>
> Just this patch ? I booted a macosx image with it. but maybe just a mac99.
> I will check today.

 With your branch ppc-for-2.7 (at commit aba2e6258d86) + the 
 "ppc: Fix rfi/rfid/hrfi/... emulation" patch, these guests : 

qemu-system-ppc -cdrom ./darwinppc-602.cdr -boot d 
qemu-system-ppc -M mac99 -cdrom ./darwinppc-602.cdr -boot d 
>>>^
>>>|
>>> You're missing the "64" here ;-)
>>>
 reach the installer macosx installer.
>>>
>>> It seems to be only failing for the 64-bit builds - and there only for
>>> the PPC970 CPU (which is the default for the mac99 machine in 64-bit
>>> builds):
>>>
>>> qemu-system-ppc64 -nographic -cpu 750 -M mac99 ==> works fine
>>>
>>> qemu-system-ppc64 -nographic -cpu 970 -M mac99 ==> hangs
>>
>>
>> This is too brutal :
>>
>> +/* This instruction doesn't exist anymore on 64-bit server
>> + * processors compliant with arch 2.x
>> + */
>> +if (ctx->insns_flags & PPC_SEGMENT_64B) {
>> +gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
>> +return;
>> +}
>>
>> There are a couple of instructions which have been deleted from 
>> ISA 2.x. rfi is one of them. Could we use a insn_flag to filter
>> them  ? 
> 
> According to the PPC970FX user manual that I have:
> 
> "The 970FX does not provide support for the following optional or
>  obsolete instructions (or instruction forms).
>  Attempted use of these will result in an illegal instruction type
>  program interrupt.
>   [...]
>   · rfi - Return from interrupt (obsolete) "
> 
> So if OpenBIOS is using this instruction in 970 mode, it's maybe
> OpenBIOS that should be fixed instead?

If 970 doesn't implement rfi, OpenBIOS shouldn't use it, yes :).


Alex

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Thomas Huth]

On 17.06.2016 12:41, Cédric Le Goater wrote:
> On 06/17/2016 09:10 AM, Thomas Huth wrote:
>> On 17.06.2016 08:03, Cédric Le Goater wrote:
>>> On 06/17/2016 07:54 AM, Cédric Le Goater wrote:
 On 06/17/2016 04:27 AM, David Gibson wrote:
> On Thu, Jun 16, 2016 at 11:07:02AM +1000, David Gibson wrote:
>> On Mon, Jun 13, 2016 at 07:24:47AM +0200, Cédric Le Goater wrote:
>>> From: Benjamin Herrenschmidt 
>>>
>>> This reworks emulation of the various "rfi" variants. I removed
>>> some masking bits that I couldn't make sense of, the only bit that
>>> I am aware we should mask here is POW, the CPU's MSR mask should
>>> take care of the rest.
>>>
>>> This also fixes some problems when running 32-bit userspace under
>>> a 64-bit kernel.
> 
> he.
> 
>>> Signed-off-by: Benjamin Herrenschmidt 
>>> Reviewed-by: David Gibson 
>>
>> I've merged this patch to ppc-for-2.7.
>
> ..and now I've removed it again.  It seems that this breaks Thomas'
> new test that OpenBIOS runs on the mac machine types.  Not sure why,
> but we need to figure that out before I apply.

 Just this patch ? I booted a macosx image with it. but maybe just a mac99.
 I will check today.
>>>
>>> With your branch ppc-for-2.7 (at commit aba2e6258d86) + the 
>>> "ppc: Fix rfi/rfid/hrfi/... emulation" patch, these guests : 
>>>
>>> qemu-system-ppc -cdrom ./darwinppc-602.cdr -boot d 
>>> qemu-system-ppc -M mac99 -cdrom ./darwinppc-602.cdr -boot d 
>>^
>>|
>> You're missing the "64" here ;-)
>>
>>> reach the installer macosx installer.
>>
>> It seems to be only failing for the 64-bit builds - and there only for
>> the PPC970 CPU (which is the default for the mac99 machine in 64-bit
>> builds):
>>
>> qemu-system-ppc64 -nographic -cpu 750 -M mac99 ==> works fine
>>
>> qemu-system-ppc64 -nographic -cpu 970 -M mac99 ==> hangs
> 
> 
> This is too brutal :
> 
> +/* This instruction doesn't exist anymore on 64-bit server
> + * processors compliant with arch 2.x
> + */
> +if (ctx->insns_flags & PPC_SEGMENT_64B) {
> +gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
> +return;
> +}
> 
> There are a couple of instructions which have been deleted from 
> ISA 2.x. rfi is one of them. Could we use a insn_flag to filter
> them  ? 

According to the PPC970FX user manual that I have:

"The 970FX does not provide support for the following optional or
 obsolete instructions (or instruction forms).
 Attempted use of these will result in an illegal instruction type
 program interrupt.
  [...]
  · rfi - Return from interrupt (obsolete) "

So if OpenBIOS is using this instruction in 970 mode, it's maybe
OpenBIOS that should be fixed instead?

 Thomas

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/17/2016 09:10 AM, Thomas Huth wrote:
> On 17.06.2016 08:03, Cédric Le Goater wrote:
>> On 06/17/2016 07:54 AM, Cédric Le Goater wrote:
>>> On 06/17/2016 04:27 AM, David Gibson wrote:
 On Thu, Jun 16, 2016 at 11:07:02AM +1000, David Gibson wrote:
> On Mon, Jun 13, 2016 at 07:24:47AM +0200, Cédric Le Goater wrote:
>> From: Benjamin Herrenschmidt 
>>
>> This reworks emulation of the various "rfi" variants. I removed
>> some masking bits that I couldn't make sense of, the only bit that
>> I am aware we should mask here is POW, the CPU's MSR mask should
>> take care of the rest.
>>
>> This also fixes some problems when running 32-bit userspace under
>> a 64-bit kernel.

he.

>> Signed-off-by: Benjamin Herrenschmidt 
>> Reviewed-by: David Gibson 
>
> I've merged this patch to ppc-for-2.7.

 ..and now I've removed it again.  It seems that this breaks Thomas'
 new test that OpenBIOS runs on the mac machine types.  Not sure why,
 but we need to figure that out before I apply.
>>>
>>> Just this patch ? I booted a macosx image with it. but maybe just a mac99.
>>> I will check today.
>>
>> With your branch ppc-for-2.7 (at commit aba2e6258d86) + the 
>> "ppc: Fix rfi/rfid/hrfi/... emulation" patch, these guests : 
>>
>>  qemu-system-ppc -cdrom ./darwinppc-602.cdr -boot d 
>>  qemu-system-ppc -M mac99 -cdrom ./darwinppc-602.cdr -boot d 
>^
>|
> You're missing the "64" here ;-)
> 
>> reach the installer macosx installer.
> 
> It seems to be only failing for the 64-bit builds - and there only for
> the PPC970 CPU (which is the default for the mac99 machine in 64-bit
> builds):
> 
> qemu-system-ppc64 -nographic -cpu 750 -M mac99 ==> works fine
> 
> qemu-system-ppc64 -nographic -cpu 970 -M mac99 ==> hangs


This is too brutal :

+/* This instruction doesn't exist anymore on 64-bit server
+ * processors compliant with arch 2.x
+ */
+if (ctx->insns_flags & PPC_SEGMENT_64B) {
+gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
+return;
+}


There are a couple of instructions which have been deleted from 
ISA 2.x. rfi is one of them. Could we use a insn_flag to filter
them  ? 

Thanks,

C.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/17/2016 09:10 AM, Thomas Huth wrote:
> On 17.06.2016 08:03, Cédric Le Goater wrote:
>> On 06/17/2016 07:54 AM, Cédric Le Goater wrote:
>>> On 06/17/2016 04:27 AM, David Gibson wrote:
 On Thu, Jun 16, 2016 at 11:07:02AM +1000, David Gibson wrote:
> On Mon, Jun 13, 2016 at 07:24:47AM +0200, Cédric Le Goater wrote:
>> From: Benjamin Herrenschmidt 
>>
>> This reworks emulation of the various "rfi" variants. I removed
>> some masking bits that I couldn't make sense of, the only bit that
>> I am aware we should mask here is POW, the CPU's MSR mask should
>> take care of the rest.
>>
>> This also fixes some problems when running 32-bit userspace under
>> a 64-bit kernel.
>>
>> Signed-off-by: Benjamin Herrenschmidt 
>> Reviewed-by: David Gibson 
>
> I've merged this patch to ppc-for-2.7.

 ..and now I've removed it again.  It seems that this breaks Thomas'
 new test that OpenBIOS runs on the mac machine types.  Not sure why,
 but we need to figure that out before I apply.
>>>
>>> Just this patch ? I booted a macosx image with it. but maybe just a mac99.
>>> I will check today.
>>
>> With your branch ppc-for-2.7 (at commit aba2e6258d86) + the 
>> "ppc: Fix rfi/rfid/hrfi/... emulation" patch, these guests : 
>>
>>  qemu-system-ppc -cdrom ./darwinppc-602.cdr -boot d 
>>  qemu-system-ppc -M mac99 -cdrom ./darwinppc-602.cdr -boot d 
>^
>|
> You're missing the "64" here ;-)

ah ! I never use the 64 bit version for these but I should. I will give
a try.

Thanks,

C.

>> reach the installer macosx installer.
> 
> It seems to be only failing for the 64-bit builds - and there only for
> the PPC970 CPU (which is the default for the mac99 machine in 64-bit
> builds):
> 
> qemu-system-ppc64 -nographic -cpu 750 -M mac99 ==> works fine
> 
> qemu-system-ppc64 -nographic -cpu 970 -M mac99 ==> hangs
> 
>  Thomas
> 

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Thomas Huth]

On 17.06.2016 08:03, Cédric Le Goater wrote:
> On 06/17/2016 07:54 AM, Cédric Le Goater wrote:
>> On 06/17/2016 04:27 AM, David Gibson wrote:
>>> On Thu, Jun 16, 2016 at 11:07:02AM +1000, David Gibson wrote:
 On Mon, Jun 13, 2016 at 07:24:47AM +0200, Cédric Le Goater wrote:
> From: Benjamin Herrenschmidt 
>
> This reworks emulation of the various "rfi" variants. I removed
> some masking bits that I couldn't make sense of, the only bit that
> I am aware we should mask here is POW, the CPU's MSR mask should
> take care of the rest.
>
> This also fixes some problems when running 32-bit userspace under
> a 64-bit kernel.
>
> Signed-off-by: Benjamin Herrenschmidt 
> Reviewed-by: David Gibson 

 I've merged this patch to ppc-for-2.7.
>>>
>>> ..and now I've removed it again.  It seems that this breaks Thomas'
>>> new test that OpenBIOS runs on the mac machine types.  Not sure why,
>>> but we need to figure that out before I apply.
>>
>> Just this patch ? I booted a macosx image with it. but maybe just a mac99.
>> I will check today.
> 
> With your branch ppc-for-2.7 (at commit aba2e6258d86) + the 
> "ppc: Fix rfi/rfid/hrfi/... emulation" patch, these guests : 
> 
>   qemu-system-ppc -cdrom ./darwinppc-602.cdr -boot d 
>   qemu-system-ppc -M mac99 -cdrom ./darwinppc-602.cdr -boot d 
   ^
   |
You're missing the "64" here ;-)

> reach the installer macosx installer.

It seems to be only failing for the 64-bit builds - and there only for
the PPC970 CPU (which is the default for the mac99 machine in 64-bit
builds):

qemu-system-ppc64 -nographic -cpu 750 -M mac99 ==> works fine

qemu-system-ppc64 -nographic -cpu 970 -M mac99 ==> hangs

 Thomas

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/17/2016 08:28 AM, David Gibson wrote:
> On Fri, Jun 17, 2016 at 08:03:29AM +0200, Cédric Le Goater wrote:
>> On 06/17/2016 07:54 AM, Cédric Le Goater wrote:
>>> On 06/17/2016 04:27 AM, David Gibson wrote:
 On Thu, Jun 16, 2016 at 11:07:02AM +1000, David Gibson wrote:
> On Mon, Jun 13, 2016 at 07:24:47AM +0200, Cédric Le Goater wrote:
>> From: Benjamin Herrenschmidt 
>>
>> This reworks emulation of the various "rfi" variants. I removed
>> some masking bits that I couldn't make sense of, the only bit that
>> I am aware we should mask here is POW, the CPU's MSR mask should
>> take care of the rest.
>>
>> This also fixes some problems when running 32-bit userspace under
>> a 64-bit kernel.
>>
>> Signed-off-by: Benjamin Herrenschmidt 
>> Reviewed-by: David Gibson 
>
> I've merged this patch to ppc-for-2.7.

 ..and now I've removed it again.  It seems that this breaks Thomas'
 new test that OpenBIOS runs on the mac machine types.  Not sure why,
 but we need to figure that out before I apply.
>>>
>>> Just this patch ? I booted a macosx image with it. but maybe just a mac99.
>>> I will check today.
>>
>> With your branch ppc-for-2.7 (at commit aba2e6258d86) + the 
>> "ppc: Fix rfi/rfid/hrfi/... emulation" patch, these guests : 
>>
>>  qemu-system-ppc -cdrom ./darwinppc-602.cdr -boot d 
>>  qemu-system-ppc -M mac99 -cdrom ./darwinppc-602.cdr -boot d 
>>
>> reach the installer macosx installer.
> 
> But the prom-env-test from make check fails :(.
> 

I do not see the issue on ppc-for-2.7 (commit aba2e6258d86) + the 
"ppc: Fix rfi/rfid/hrfi/... emulation" patch. 

I will update during the day and let you know.

Cheers,

C.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[David Gibson]

On Fri, Jun 17, 2016 at 08:03:29AM +0200, Cédric Le Goater wrote:
> On 06/17/2016 07:54 AM, Cédric Le Goater wrote:
> > On 06/17/2016 04:27 AM, David Gibson wrote:
> >> On Thu, Jun 16, 2016 at 11:07:02AM +1000, David Gibson wrote:
> >>> On Mon, Jun 13, 2016 at 07:24:47AM +0200, Cédric Le Goater wrote:
>  From: Benjamin Herrenschmidt 
> 
>  This reworks emulation of the various "rfi" variants. I removed
>  some masking bits that I couldn't make sense of, the only bit that
>  I am aware we should mask here is POW, the CPU's MSR mask should
>  take care of the rest.
> 
>  This also fixes some problems when running 32-bit userspace under
>  a 64-bit kernel.
> 
>  Signed-off-by: Benjamin Herrenschmidt 
>  Reviewed-by: David Gibson 
> >>>
> >>> I've merged this patch to ppc-for-2.7.
> >>
> >> ..and now I've removed it again.  It seems that this breaks Thomas'
> >> new test that OpenBIOS runs on the mac machine types.  Not sure why,
> >> but we need to figure that out before I apply.
> > 
> > Just this patch ? I booted a macosx image with it. but maybe just a mac99.
> > I will check today.
> 
> With your branch ppc-for-2.7 (at commit aba2e6258d86) + the 
> "ppc: Fix rfi/rfid/hrfi/... emulation" patch, these guests : 
> 
>   qemu-system-ppc -cdrom ./darwinppc-602.cdr -boot d 
>   qemu-system-ppc -M mac99 -cdrom ./darwinppc-602.cdr -boot d 
> 
> reach the installer macosx installer.

But the prom-env-test from make check fails :(.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/17/2016 07:54 AM, Cédric Le Goater wrote:
> On 06/17/2016 04:27 AM, David Gibson wrote:
>> On Thu, Jun 16, 2016 at 11:07:02AM +1000, David Gibson wrote:
>>> On Mon, Jun 13, 2016 at 07:24:47AM +0200, Cédric Le Goater wrote:
 From: Benjamin Herrenschmidt 

 This reworks emulation of the various "rfi" variants. I removed
 some masking bits that I couldn't make sense of, the only bit that
 I am aware we should mask here is POW, the CPU's MSR mask should
 take care of the rest.

 This also fixes some problems when running 32-bit userspace under
 a 64-bit kernel.

 Signed-off-by: Benjamin Herrenschmidt 
 Reviewed-by: David Gibson 
>>>
>>> I've merged this patch to ppc-for-2.7.
>>
>> ..and now I've removed it again.  It seems that this breaks Thomas'
>> new test that OpenBIOS runs on the mac machine types.  Not sure why,
>> but we need to figure that out before I apply.
> 
> Just this patch ? I booted a macosx image with it. but maybe just a mac99.
> I will check today.

With your branch ppc-for-2.7 (at commit aba2e6258d86) + the 
"ppc: Fix rfi/rfid/hrfi/... emulation" patch, these guests : 

qemu-system-ppc -cdrom ./darwinppc-602.cdr -boot d 
qemu-system-ppc -M mac99 -cdrom ./darwinppc-602.cdr -boot d 

reach the installer macosx installer.

C.

>>> The reset of the series I'd like to see a respin for, even if it's
>>> just to clean up the commit messages.
>>>
 ---
  target-ppc/excp_helper.c | 51 
 +++-
  target-ppc/translate.c   |  7 +++
  2 files changed, 27 insertions(+), 31 deletions(-)

 diff --git a/target-ppc/excp_helper.c b/target-ppc/excp_helper.c
 index 30e960e30b63..aa0b63f4b0de 100644
 --- a/target-ppc/excp_helper.c
 +++ b/target-ppc/excp_helper.c
 @@ -922,25 +922,20 @@ void helper_store_msr(CPUPPCState *env, target_ulong 
 val)
  }
  }
  
 -static inline void do_rfi(CPUPPCState *env, target_ulong nip, 
 target_ulong msr,
 -  target_ulong msrm, int keep_msrh)
 +static inline void do_rfi(CPUPPCState *env, target_ulong nip, 
 target_ulong msr)
  {
  CPUState *cs = CPU(ppc_env_get_cpu(env));
  
 +/* MSR:POW cannot be set by any form of rfi */
 +msr &= ~(1ULL << MSR_POW);
 +
  #if defined(TARGET_PPC64)
 -if (msr_is_64bit(env, msr)) {
 -nip = (uint64_t)nip;
 -msr &= (uint64_t)msrm;
 -} else {
 +/* Switching to 32-bit ? Crop the nip */
 +if (!msr_is_64bit(env, msr)) {
  nip = (uint32_t)nip;
 -msr = (uint32_t)(msr & msrm);
 -if (keep_msrh) {
 -msr |= env->msr & ~((uint64_t)0x);
 -}
  }
  #else
  nip = (uint32_t)nip;
 -msr &= (uint32_t)msrm;
  #endif
  /* XXX: beware: this is false if VLE is supported */
  env->nip = nip & ~((target_ulong)0x0003);
 @@ -959,26 +954,24 @@ static inline void do_rfi(CPUPPCState *env, 
 target_ulong nip, target_ulong msr,
  
  void helper_rfi(CPUPPCState *env)
  {
 -if (env->excp_model == POWERPC_EXCP_BOOKE) {
 -do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1],
 -   ~((target_ulong)0), 0);
 -} else {
 -do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1],
 -   ~((target_ulong)0x783F), 1);
 -}
 +do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1] & 0xul);
  }
  
 +#define MSR_BOOK3S_MASK
  #if defined(TARGET_PPC64)
  void helper_rfid(CPUPPCState *env)
  {
 -do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1],
 -   ~((target_ulong)0x783F), 0);
 +/* The architeture defines a number of rules for which bits
 + * can change but in practice, we handle this in hreg_store_msr()
 + * which will be called by do_rfi(), so there is no need to filter
 + * here
 + */
 +do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1]);
  }
  
  void helper_hrfid(CPUPPCState *env)
  {
 -do_rfi(env, env->spr[SPR_HSRR0], env->spr[SPR_HSRR1],
 -   ~((target_ulong)0x783F), 0);
 +do_rfi(env, env->spr[SPR_HSRR0], env->spr[SPR_HSRR1]);
  }
  #endif
  
 @@ -986,28 +979,24 @@ void helper_hrfid(CPUPPCState *env)
  /* Embedded PowerPC specific helpers */
  void helper_40x_rfci(CPUPPCState *env)
  {
 -do_rfi(env, env->spr[SPR_40x_SRR2], env->spr[SPR_40x_SRR3],
 -   ~((target_ulong)0x), 0);
 +do_rfi(env, env->spr[SPR_40x_SRR2], env->spr[SPR_40x_SRR3]);
  }
  
  void helper_rfci(CPUPPCState *env)
  {
 -do_rfi(env, env->spr[SPR_BOOKE_CSRR0], 

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/17/2016 04:27 AM, David Gibson wrote:
> On Thu, Jun 16, 2016 at 11:07:02AM +1000, David Gibson wrote:
>> On Mon, Jun 13, 2016 at 07:24:47AM +0200, Cédric Le Goater wrote:
>>> From: Benjamin Herrenschmidt 
>>>
>>> This reworks emulation of the various "rfi" variants. I removed
>>> some masking bits that I couldn't make sense of, the only bit that
>>> I am aware we should mask here is POW, the CPU's MSR mask should
>>> take care of the rest.
>>>
>>> This also fixes some problems when running 32-bit userspace under
>>> a 64-bit kernel.
>>>
>>> Signed-off-by: Benjamin Herrenschmidt 
>>> Reviewed-by: David Gibson 
>>
>> I've merged this patch to ppc-for-2.7.
> 
> ..and now I've removed it again.  It seems that this breaks Thomas'
> new test that OpenBIOS runs on the mac machine types.  Not sure why,
> but we need to figure that out before I apply.

Just this patch ? I booted a macosx image with it. but maybe just a mac99.
I will check today.

C. 

>> The reset of the series I'd like to see a respin for, even if it's
>> just to clean up the commit messages.
>>
>>> ---
>>>  target-ppc/excp_helper.c | 51 
>>> +++-
>>>  target-ppc/translate.c   |  7 +++
>>>  2 files changed, 27 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/target-ppc/excp_helper.c b/target-ppc/excp_helper.c
>>> index 30e960e30b63..aa0b63f4b0de 100644
>>> --- a/target-ppc/excp_helper.c
>>> +++ b/target-ppc/excp_helper.c
>>> @@ -922,25 +922,20 @@ void helper_store_msr(CPUPPCState *env, target_ulong 
>>> val)
>>>  }
>>>  }
>>>  
>>> -static inline void do_rfi(CPUPPCState *env, target_ulong nip, target_ulong 
>>> msr,
>>> -  target_ulong msrm, int keep_msrh)
>>> +static inline void do_rfi(CPUPPCState *env, target_ulong nip, target_ulong 
>>> msr)
>>>  {
>>>  CPUState *cs = CPU(ppc_env_get_cpu(env));
>>>  
>>> +/* MSR:POW cannot be set by any form of rfi */
>>> +msr &= ~(1ULL << MSR_POW);
>>> +
>>>  #if defined(TARGET_PPC64)
>>> -if (msr_is_64bit(env, msr)) {
>>> -nip = (uint64_t)nip;
>>> -msr &= (uint64_t)msrm;
>>> -} else {
>>> +/* Switching to 32-bit ? Crop the nip */
>>> +if (!msr_is_64bit(env, msr)) {
>>>  nip = (uint32_t)nip;
>>> -msr = (uint32_t)(msr & msrm);
>>> -if (keep_msrh) {
>>> -msr |= env->msr & ~((uint64_t)0x);
>>> -}
>>>  }
>>>  #else
>>>  nip = (uint32_t)nip;
>>> -msr &= (uint32_t)msrm;
>>>  #endif
>>>  /* XXX: beware: this is false if VLE is supported */
>>>  env->nip = nip & ~((target_ulong)0x0003);
>>> @@ -959,26 +954,24 @@ static inline void do_rfi(CPUPPCState *env, 
>>> target_ulong nip, target_ulong msr,
>>>  
>>>  void helper_rfi(CPUPPCState *env)
>>>  {
>>> -if (env->excp_model == POWERPC_EXCP_BOOKE) {
>>> -do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1],
>>> -   ~((target_ulong)0), 0);
>>> -} else {
>>> -do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1],
>>> -   ~((target_ulong)0x783F), 1);
>>> -}
>>> +do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1] & 0xul);
>>>  }
>>>  
>>> +#define MSR_BOOK3S_MASK
>>>  #if defined(TARGET_PPC64)
>>>  void helper_rfid(CPUPPCState *env)
>>>  {
>>> -do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1],
>>> -   ~((target_ulong)0x783F), 0);
>>> +/* The architeture defines a number of rules for which bits
>>> + * can change but in practice, we handle this in hreg_store_msr()
>>> + * which will be called by do_rfi(), so there is no need to filter
>>> + * here
>>> + */
>>> +do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1]);
>>>  }
>>>  
>>>  void helper_hrfid(CPUPPCState *env)
>>>  {
>>> -do_rfi(env, env->spr[SPR_HSRR0], env->spr[SPR_HSRR1],
>>> -   ~((target_ulong)0x783F), 0);
>>> +do_rfi(env, env->spr[SPR_HSRR0], env->spr[SPR_HSRR1]);
>>>  }
>>>  #endif
>>>  
>>> @@ -986,28 +979,24 @@ void helper_hrfid(CPUPPCState *env)
>>>  /* Embedded PowerPC specific helpers */
>>>  void helper_40x_rfci(CPUPPCState *env)
>>>  {
>>> -do_rfi(env, env->spr[SPR_40x_SRR2], env->spr[SPR_40x_SRR3],
>>> -   ~((target_ulong)0x), 0);
>>> +do_rfi(env, env->spr[SPR_40x_SRR2], env->spr[SPR_40x_SRR3]);
>>>  }
>>>  
>>>  void helper_rfci(CPUPPCState *env)
>>>  {
>>> -do_rfi(env, env->spr[SPR_BOOKE_CSRR0], env->spr[SPR_BOOKE_CSRR1],
>>> -   ~((target_ulong)0), 0);
>>> +do_rfi(env, env->spr[SPR_BOOKE_CSRR0], env->spr[SPR_BOOKE_CSRR1]);
>>>  }
>>>  
>>>  void helper_rfdi(CPUPPCState *env)
>>>  {
>>>  /* FIXME: choose CSRR1 or DSRR1 based on cpu type */
>>> -do_rfi(env, env->spr[SPR_BOOKE_DSRR0], env->spr[SPR_BOOKE_DSRR1],
>>> -   ~((target_ulong)0), 0);
>>> +do_rfi(env, env->spr[SPR_BOOKE_DSRR0], env->spr[SPR_BOOKE_DSRR1]);
>>>  }
>>>  
>>>  void 

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[David Gibson]

On Thu, Jun 16, 2016 at 11:07:02AM +1000, David Gibson wrote:
> On Mon, Jun 13, 2016 at 07:24:47AM +0200, Cédric Le Goater wrote:
> > From: Benjamin Herrenschmidt 
> > 
> > This reworks emulation of the various "rfi" variants. I removed
> > some masking bits that I couldn't make sense of, the only bit that
> > I am aware we should mask here is POW, the CPU's MSR mask should
> > take care of the rest.
> > 
> > This also fixes some problems when running 32-bit userspace under
> > a 64-bit kernel.
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > Reviewed-by: David Gibson 
> 
> I've merged this patch to ppc-for-2.7.

..and now I've removed it again.  It seems that this breaks Thomas'
new test that OpenBIOS runs on the mac machine types.  Not sure why,
but we need to figure that out before I apply.

> The reset of the series I'd like to see a respin for, even if it's
> just to clean up the commit messages.
> 
> > ---
> >  target-ppc/excp_helper.c | 51 
> > +++-
> >  target-ppc/translate.c   |  7 +++
> >  2 files changed, 27 insertions(+), 31 deletions(-)
> > 
> > diff --git a/target-ppc/excp_helper.c b/target-ppc/excp_helper.c
> > index 30e960e30b63..aa0b63f4b0de 100644
> > --- a/target-ppc/excp_helper.c
> > +++ b/target-ppc/excp_helper.c
> > @@ -922,25 +922,20 @@ void helper_store_msr(CPUPPCState *env, target_ulong 
> > val)
> >  }
> >  }
> >  
> > -static inline void do_rfi(CPUPPCState *env, target_ulong nip, target_ulong 
> > msr,
> > -  target_ulong msrm, int keep_msrh)
> > +static inline void do_rfi(CPUPPCState *env, target_ulong nip, target_ulong 
> > msr)
> >  {
> >  CPUState *cs = CPU(ppc_env_get_cpu(env));
> >  
> > +/* MSR:POW cannot be set by any form of rfi */
> > +msr &= ~(1ULL << MSR_POW);
> > +
> >  #if defined(TARGET_PPC64)
> > -if (msr_is_64bit(env, msr)) {
> > -nip = (uint64_t)nip;
> > -msr &= (uint64_t)msrm;
> > -} else {
> > +/* Switching to 32-bit ? Crop the nip */
> > +if (!msr_is_64bit(env, msr)) {
> >  nip = (uint32_t)nip;
> > -msr = (uint32_t)(msr & msrm);
> > -if (keep_msrh) {
> > -msr |= env->msr & ~((uint64_t)0x);
> > -}
> >  }
> >  #else
> >  nip = (uint32_t)nip;
> > -msr &= (uint32_t)msrm;
> >  #endif
> >  /* XXX: beware: this is false if VLE is supported */
> >  env->nip = nip & ~((target_ulong)0x0003);
> > @@ -959,26 +954,24 @@ static inline void do_rfi(CPUPPCState *env, 
> > target_ulong nip, target_ulong msr,
> >  
> >  void helper_rfi(CPUPPCState *env)
> >  {
> > -if (env->excp_model == POWERPC_EXCP_BOOKE) {
> > -do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1],
> > -   ~((target_ulong)0), 0);
> > -} else {
> > -do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1],
> > -   ~((target_ulong)0x783F), 1);
> > -}
> > +do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1] & 0xul);
> >  }
> >  
> > +#define MSR_BOOK3S_MASK
> >  #if defined(TARGET_PPC64)
> >  void helper_rfid(CPUPPCState *env)
> >  {
> > -do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1],
> > -   ~((target_ulong)0x783F), 0);
> > +/* The architeture defines a number of rules for which bits
> > + * can change but in practice, we handle this in hreg_store_msr()
> > + * which will be called by do_rfi(), so there is no need to filter
> > + * here
> > + */
> > +do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1]);
> >  }
> >  
> >  void helper_hrfid(CPUPPCState *env)
> >  {
> > -do_rfi(env, env->spr[SPR_HSRR0], env->spr[SPR_HSRR1],
> > -   ~((target_ulong)0x783F), 0);
> > +do_rfi(env, env->spr[SPR_HSRR0], env->spr[SPR_HSRR1]);
> >  }
> >  #endif
> >  
> > @@ -986,28 +979,24 @@ void helper_hrfid(CPUPPCState *env)
> >  /* Embedded PowerPC specific helpers */
> >  void helper_40x_rfci(CPUPPCState *env)
> >  {
> > -do_rfi(env, env->spr[SPR_40x_SRR2], env->spr[SPR_40x_SRR3],
> > -   ~((target_ulong)0x), 0);
> > +do_rfi(env, env->spr[SPR_40x_SRR2], env->spr[SPR_40x_SRR3]);
> >  }
> >  
> >  void helper_rfci(CPUPPCState *env)
> >  {
> > -do_rfi(env, env->spr[SPR_BOOKE_CSRR0], env->spr[SPR_BOOKE_CSRR1],
> > -   ~((target_ulong)0), 0);
> > +do_rfi(env, env->spr[SPR_BOOKE_CSRR0], env->spr[SPR_BOOKE_CSRR1]);
> >  }
> >  
> >  void helper_rfdi(CPUPPCState *env)
> >  {
> >  /* FIXME: choose CSRR1 or DSRR1 based on cpu type */
> > -do_rfi(env, env->spr[SPR_BOOKE_DSRR0], env->spr[SPR_BOOKE_DSRR1],
> > -   ~((target_ulong)0), 0);
> > +do_rfi(env, env->spr[SPR_BOOKE_DSRR0], env->spr[SPR_BOOKE_DSRR1]);
> >  }
> >  
> >  void helper_rfmci(CPUPPCState *env)
> >  {
> >  /* FIXME: choose CSRR1 or MCSRR1 based on cpu type */
> > -do_rfi(env, env->spr[SPR_BOOKE_MCSRR0],