On Feb 1, 2018, at 1:13 AM, Thomas Huth <thuth@redhat.com> wrote:

On 31.01.2018 21:59, James Lyons via OpenBIOS wrote:


On 01/30/2018 11:14 AM, Jd Lyons wrote:

On Jan 30, 2018, at 10:47 AM, Jd Lyons via OpenBIOS
<openbios@openbios.org> wrote:



On Jan 30, 2018, at 9:10 AM, BALATON Zoltan <balaton@eik.bme.hu> 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

-- 
OpenBIOS                 http://openbios.org/
Mailinglist:  http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you
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?

Ok, I tried like this:

spr_register_kvm(env, SPR_L3CR, "L3CR",
                     SPR_NOACCESS, SPR_NOACCESS,
                     &spr_read_generic, &spr_write_generic,
                     KVM_REG_PPC_L3CR, 0x00000000);

And I defined:

#define KVM_REG_PPC_L3CR    (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0x3fa)

Did you also patch the kernel accordingly? The KVM code in the kernel
needs to be aware of this, too. grep for KVM_REG_PPC_ in
arch/powerpc/kvm/ to see some examples.

Thomas



Ok, thanks Thomas, that makes sense, I’ll see if I can make heads or tails of the code.


-- 
OpenBIOS                 http://openbios.org/
Mailinglist:  http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you