[Qemu-ppc,01/10] ppc: Fix rfi/rfid/hrfi/... emulation

On 06/19/2016 03:00 PM, Alexander Graf wrote:
> 
> 
>> Am 19.06.2016 um 14:49 schrieb Cédric Le Goater <clg@kaod.org>:
>>
>>> 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 <clg@kaod.org>
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 <clg@kaod.org>
---
 arch/ppc/qemu/start.S |   15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

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.

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.

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.

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.
>

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.

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_0000 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.

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_0000 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

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_0000 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.

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_0000 doesn't look
like something that would mean anything on a machine with macio at
8000_0000.... 

Cheers,
Ben.

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_0000 doesn't
> look
> like something that would mean anything on a machine with macio at
> 8000_0000.... 
> 
You are right, it's PCI1 config space. I'll dig more later.

Cheers,
Ben.