QEMU accel=kvm not able to boot guest Mac OS X

[Logout]

Hello everyone!

I wonder if anyone else ever had the same problem as I do: I'm not able to boot any Mac OS X version with KVM accelerator enabled.
More details:

Machine: 8-core Blackbird, 32G RAM
Kernel&host OS: right now 5.10.6 under Riscy Slack, but before that whatever was current in Void Linux during last months, kvm and kvm_pr both present and loaded
QEMU: 5.2.0, but also 4.1.1 and 5.0.0
Mac OS X: 10.3, 10.4, 10.5, 10.5.2

What happens? MacOS X starts booting, after a while it reaches the point where it reports BSD root: disk0s3, major 14, minor 2 and hangs there. I discovered how to make qemu report errors, this is what happens:

Invalid access at addr 0x80000000, size 4, region '(null)', reason: rejected
Invalid access at addr 0x80000030, size 4, region '(null)', reason: rejected
Invalid access at addr 0x80000034, size 4, region '(null)', reason: rejected
Invalid access at addr 0x80000038, size 4, region '(null)', reason: rejected
Invalid access at addr 0x8000003C, size 4, region '(null)', reason: rejected
Invalid access at addr 0x80000040, size 4, region '(null)', reason: rejected
Invalid access at addr 0x80000044, size 4, region '(null)', reason: rejected
Invalid access at addr 0x80000048, size 4, region '(null)', reason: rejected
Invalid access at addr 0x8000004C, size 4, region '(null)', reason: rejected
dbdma_unassigned_flush: use of unassigned channel 0
dbdma_unassigned_flush: use of unassigned channel 0
Invalid access at addr 0x80000038, size 4, region '(null)', reason: rejected
Invalid access at addr 0x8000003C, size 4, region '(null)', reason: rejected
Invalid access at addr 0x80000044, size 4, region '(null)', reason: rejected
Invalid access at addr 0x80000040, size 4, region '(null)', reason: rejected
Invalid access at addr 0x80000040, size 4, region '(null)', reason: rejected
PMU: Unsupported READ_PMU_RAM, args: 80 02 03
PMU: Unsupported READ_PMU_RAM, args: 80 02 03
PMU: POWER EVENTS unknown subcommand 0x07
PMU: POWER EVENTS unknown subcommand 0x08

The commandline is: taskset -a -c 0-3 ./qemu-system-ppc -cpu nitro -M mac99,accel=kvm,via=pmu -m 512 -prom-env boot-args=-v -boot c -drive file=leopard.img,format=qcow2,l2-cache-size=4M -usb -device usb-tablet -g 1280x1024x32  -d unimp,guest_errors

The tcg accelerator works, I installed the system from DVD through it as with KVM not even that boots. Thanks for any advice!

[ClassicHasClass]

Grrr, that sounds like kvm_pr got broken again. I'll take a look.

[Logout]

To dig the thread a bit up: In Gentoo Linux, with kernel 5.4.80, the KVM-PR seems to be working. I was even able to install the Mac OS X in the accell=kvm mode, even though it was painfully slow. I will see how already installed system will perform...

Update: even though everything seems to be running, I still get occasional watchdog: BUG: soft lockup - CPU#13 stuck for 23s!

[ClassicHasClass]

That happens if you have threads bound across CPUs. I wonder if your taskset didn't stick or something.

[Logout]

OK, I had the taskset wrong, this problem is now gone. But there is something different: even though the KVM works (no errors when using it, the kvm_pr is loaded, etc.), it's painfully slow and I haven't been able to install the 10.5.8 update - it says that the package couldn't be verified after almost 14 hours of trying to do so. The package works on all my other machines, it's just the standard combo update from Apple. Any suggestions, what might be wrong this time?

(It almost seems that to get to my photos, it would be faster to export everything from my old iPhoto library to filesystem and abandon the app altogether. Or emulate an Intel Mac. But I hate to do either, it's 15 years of photos.)

[ClassicHasClass]

I've seen that with Tiger updates. I think there is some glitch or inefficiency with supervisor level code (which makes sense with KVM-PR). I've had the best luck doing installs with TCG instead of KVM, which is most reliable, and then switching back.

Also note right now that as long as we advertise to the OS as a G4/7410, it will select the wrong dcbz size, which has memory impacts. I have code to monkeypatch the operating system but this is not suitable for mainline KVM. We could monkeypatch the kernel permanently in the disk image but this would have to be after all your updates are done.

The definitive solution is to advertise to the OS we're a G5, and then the right cache line size is used. However, this locks up the computer right now ...