On Jan 30, 2018, at 10:47 AM, Jd Lyons via OpenBIOS firstname.lastname@example.org wrote:
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan email@example.com wrote:
On Mon, 29 Jan 2018, Jd Lyons via OpenBIOS wrote:
Ok, with a little help for Paul at the kvm-ppc mailing list, it seems the issue maybe that the BootX or more likely mach_kernel it trying to write something to or probe for an L3 cache.
With kvm could be but on TCG it doesn't seem that way. Enabling some SPR debug options in target/ppc/translate_init.c I see this (with qemu git HEAD without other patches):
$ ppc-softmmu/qemu-system-ppc -cpu G4 -d int Write SPR 272 110 <= 07e00000 Read SPR 287 11f => 000c0209 Read SPR 25 019 => 07e00000 Read SPR 25 019 => 07e00000 Read SPR 287 11f => 000c0209 Raise exception at fff08978 => 00000003 (40000000) Write SPR 273 111 <= 07df7ff0 Write SPR 274 112 <= 20000004 Read SPR 272 110 => 07e00000 Read SPR 273 111 => 07df7ff0 Read SPR 274 112 => 20000004 Read SPR 26 01a => fff08978 Read SPR 27 01b => 40000030
$ ppc-softmmu/qemu-system-ppc -cpu 7447a -d int Write SPR 272 110 <= 07e00000 Read SPR 287 11f => 80030102 Read SPR 25 019 => 07e00000 Read SPR 25 019 => 07e00000 Read SPR 287 11f => 80030102 Raise exception at fff08978 => 0000004e (00)
So OpenBIOS gets unexpected exception very early right after reading the PVR so maybe it's a problem in OpenBIOS before it gets to what you're describing. Is this already fixed?
Regards, BALATON Zoltan
It looks like in TCG mode that it tries to read these invalid spr’s
1018 1011 1016 1012
This doesn’t cause a halt, as the kernel boots.
What I’m assuming is the kernel is trying to read the state of spr 1018 (r13), but it can’t read it. It does seem to exist for the 7447a it’s value is just zero( 0x00000000 ) and of course you can’t write anything there.
I don’t think the kernel is trying to write anything there, I think it’s just probing the state of the register to determine if the L3 cache exists. There are just too many references to the r13 in the xun source for me to figure out how to stop the kernel from trying to make a read here. Paul seems to suggest it could be fixed in KVM, but it seems like I could fix it in Qemu if I knew how to get Qemu to pass that spr( 1018 ) to the guest as readable with the value 0x00000000.
Would anyone be able to help me do that?