On Jan 26, 2018, at 8:00 PM, Segher Boessenkool
On Fri, Jan 26, 2018 at 05:04:02AM -0500, Jd Lyons wrote:
25, 2018, at 1:38 PM, Segher Boessenkool <segher(a)kernel.crashing.org> wrote:
On Thu, Jan 25, 2018 at 11:09:31AM -0500, Jd Lyons wrote:
Segher, if you have some of the old White Papers
on the CPU’s that shipped in Mac’s, or the upgrades offered by third parties, I’d like to
get a look at them, if your not under NDA.
You can download this CPU documentation from NPX (who bought it from
FSL, and before it was Motorola). Those are good docs.
Thanks, I did a few half hearted google searches, that didn’t yield the docs, I figured
they we still around somewhere. Sometimes goole is obtuse, it’s like the computer from the
Hitchhikers Guide, it matters how you ask the question.
(It probably does not help that is mistyped NXP).
7447a filetype:pdf is an easy way to find it (you want the "reference
I wonder, in specific to emulating caches if that
yields any performance increase.
Probably not. Your host's memory access do not get any faster, and the
increased bookkeeping will not help.
32 bit PPC is never going to get any faster,
Most (all?) 64-bit PowerPC cores can run 32-bit code just fine.
With qemu-ppc I find the integer performance very
well maintained, it seems to scale well with the host cpu, tho the FPU and the Vec units
are woeful and need a lot of work.
The FPU can not be cheaply emulated at all on x86 (probably not on Arm
either, not sure). The most obvious thing that cannot be cheaply emulated
is fmadd (fused multiply add).
Some vector operations are hard to do, too (in addition to the float ones).
It seems like it could be a challenge to emulate
caches, I’ll have to dig deeper into qemu and see how the issue is dealt with.
Well, it probably should at least make the L2CR etc. registers work as
expected; they do not necessarily actually have to *do* anything, esp. not
if you only want to emulate the architectural state (so don't care about
for example emulating cache invalidate correctly where that is undefined
behaviour in the architecture, etc.)
Seems I’m back to this, for some reason BootX or mach_kernel is:
When I try to boot OS X in qemu-system-ppc with
-enable-kvm -cpu host Apple’s BootX hangs at Call Kernel!
I’m using a PowerBook6,8 with a 7447a v1.5 and Kernel 4.4.111.
When BootX hangs, I get this in dmesg:
kvmppc_handle_exit_pr: emulation at 92808 failed ( 7dbafaa6 )
7dbaffa6 is mfspr r13,1018, and SPR 1018 on the 7447A is L3CR, the
level 3 cache control register. The boot code is presumably wanting
to do something to the L3 cache configuration.
Can anyone help explain what this error means, so I
can figure out what it triggering it, and hopefully fix the issue.
You could try adding code to kvmppc_core_emulate_mfspr_pr() and
kvmppc_core_emulate_mtspr_pr() to implement it as a dummy SPR that
ignores writes and returns zero when read. That should work unless
the BootX code does something like waiting for some bit to come back
as a 1.
I’m not really sure, meaning I have no idea to do what Paul is suggesting, but I assume it
means recompiling my kernel, as I didn’t build KVM as a module. Even then, I just don’t
know how to do create a dummy SPR.
I was hoping I could take a shortcut, with some Openbios hacks.
To start with I want to create a child to the CPU, the L2 cache, and see if that is enough
to get OS X to stop trying to access an L3 cache that doesn’t exist. I checked the L3CR,
and it is, of course not writable.
So the properties of the L2 I need to add are:
Under the CPU:
“ /cpus/PowerPC,G4@0/l2-cache” encode-string “ l2-cache” property
80000000 encode-int “ l2cr” property
Segher, this doesn’t seem quite right, as it does create the l2-cache property, but it’s
in quotes. I think what I need to do here is create and alias rather than a string?
The l2cr property seems correct.
The I need to create a child to the CPU, but I’m not sure how to do that, Segher?
The child needs to have these properties:
I’m pretty sure I know how to create these properties, I just don’t know how to create the
l2-cache node as a child to the cpu@0.