[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/9] target/ppc: add errp to kvmppc_read_int_cpu_dt()

From: BALATON Zoltan
Subject: Re: [PATCH 2/9] target/ppc: add errp to kvmppc_read_int_cpu_dt()
Date: Mon, 11 Jul 2022 14:05:17 +0200 (CEST)

On Mon, 11 Jul 2022, Mark Cave-Ayland wrote:
On 06/07/2022 08:45, Cédric Le Goater wrote:
I gave KVM a try on a :

     cpu        : PPC970MP, altivec supported
     clock    : 2000.000000MHz
     revision    : 1.0 (pvr 0044 0100)
     processor    : 1
     cpu        : PPC970MP, altivec supported
     clock    : 2000.000000MHz
     revision    : 1.0 (pvr 0044 0100)
     timebase    : 33333333
     platform    : PowerMac
     model    : PowerMac11,2
     machine    : PowerMac11,2
     motherboard    : PowerMac11,2 MacRISC4 Power Macintosh
     detected as    : 337 (PowerMac G5 Dual Core)
     pmac flags    : 00000000
     L2 cache    : 1024K unified
     pmac-generation    : NewWorld

running debian with kernel 5.18.0-2-powerpc64. With the installed QEMU 7.0.0,

     qemu-system-ppc64 -M mac99 -cpu host -accel kvm ...

doesn't go very far. Program exception is quickly reached and host says:

     [56450.118422] Couldn't emulate instruction 0x00000000 (op 0 xop 0)
    [56450.119060] kvmppc_exit_pr_progint: emulation at 100 failed (00000000)

Maybe try with -d unimp,guest_errors at least or some more debug options to find why it gets a 0 opcode. It probably takes a wrong exception somewhere? But with KVM maybe this does not give more info and you need to enable KVM tracing or run in a debgger instead?

In the past I've managed to run Linux on qemu-system-ppc64 -M mac99 with TCG and trace KVM-PR guest within that but I forgot the details. If I remember correctly I've found there's some problem with emulated KVM and nobody replied on the list so I could not go further. It's also quite slow that way so not the best way to test.

Anything special I should know ?

As I don't have access to a G5 I've never tried that, however the qemu-system-ppc64 mac99 is wired differently to the qemu-system-ppc mac99 machine so I wouldn't be surprised if something is broken there.

I think you can get the 32 bit version with qemu-system-ppc64 by adding -cpu G4 as it decides based on CPU type what to emulate. By default -M mac99 with qemu-system-ppc64 is a G5 Mac but OpenBIOS still gives it the same device-tree as the G4 one so guests might be confused by this. Linux did not seem to care that much though.

My normal test for MacOS is something like:

  qemu-system-ppc -M mac99 -accel kvm -hda macos104.img

This should really be -M mac99,via=pmu as that is the closest to real hardware currently.

This mac99 machine is quite confusing and maybe the only reason we need separate ppc and ppc64 qemu executables. What do you think about deprecating it and splitting it into something like powermac3_1 for mac99,via=pmu with G4 CPU, powermac7_2 for the G5 one and maybe some powerbookX_Y for the mac99 with CUDA instead of PMU but I don't know if that actually exists in real hardware? Also rename g3beige to the actual model name at the same time. This would clear this up and avoid the confusing options that we have now because of everything emulated by the single mac99 machine.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]