The UTM Thread

[adespoton]

Now that more and more people are moving to M1 Macs, UTM is going to become the de-facto front end for a lot of people emulating various versions of Mac OS. Useful that it appears to track the emaculation builds (it uses the Screamer fork for qemu-ppc).

So here's a thread to discuss UTM-related tips, tricks and issues

[adespoton]

First off: anyone know if UTM supports the new m68k Quadra800 builds for 7.x and A/UX?

Second off: slightly off-topic for a qemu-ppc area, but UTM can be configured to run x86 OS X from 10.4 through macOS 12.0.1: https://khronokernel.github.io/apple/si ... MU-AS.html
-- I figure we'll probably want to create an x86 Emulation section on the board soon to cover this sort of thing, now that x86 is very seriously deprecated for Macs.

[Bruninho]

UTM is always on latest QEMU (stable) version. As far as I know, it does have a Quadra 800 emulation, but MacOS (for m68k) currently will not fully boot. I found this in a documentation:

Running Mac OS
Note: Mac OS currently will not fully boot on qemu-system-m68k

To boot Mac OS, you need a Macintosh Quadra 800 rom. This rom is found when placed in the pc-bios folder and named MacROM.bin, or can be selected by using the -bios command line option.

./qemu-system-m68k -boot d -L pc-bios \
-M q800 -m 64 \
-serial stdio \
-bios Quadra800.rom \
-cdrom 7.6.iso
The parameter ram (pram) can be saved and loaded from a file:

-drive file=pram.img,format=raw,if=mtd
Where pram.img is a file of exactly 256 bytes long. You can create such a file with e.g., "dd if=/dev/zero of=pram.img bs=256 count=1" or "qemu-img create -f raw pram.img 256"

I love UTM and I find it very good, but two things keep me from using this:

1) UTM currently does not run a VM from any other folder or external drive
2) It does not have Glide/MESA passthrough for DOS/Windows games. There's a patch on GitHub for that, but only for vanilla QEMU. I asked the UTM dev once for it, but... he does have his reasons (understandable). He prefers to stick to upstream QEMU as much as possible, Screamer patch was only an exception because it was so well developed that it could (almost) be pushed to upstream one day.

EDIT: Now that I am on a M1 MacBook Air, I'll have to use UTM more for an arm64 linux web server and play with an arm64 Windows 11. Meanwhile my MacOS 9.2.2 VM is still going strong and stable. I plan to try some Leopard builds later. Someone on MacRumors is working on an unofficial update for PPC Leopard, called "Sorbet Leopard".

[adespoton]

UTM is always on latest QEMU (stable) version. As far as I know, it does have a Quadra 800 emulation, but MacOS (for m68k) currently will not fully boot. I found this in a documentation:

That's the official statement. However, back in August, UTM was using MCAyland's Screamer fork of QEMU-PPC, which is definitely NOT the stable build (as it's incompatible with snapshotting at the moment).

Since they jumped on Screamer, I thought they might opt to do the same type of fork hopping for 7.x and A/UX emulation of the m68k core.

[Cat_7]

I thought they might opt to do the same type of fork hopping for 7.x and A/UX emulation of the m68k core.

It will not be long now before support for those is in main repository.

Best,
Cat_7

[Bruninho]

UTM is always on latest QEMU (stable) version. As far as I know, it does have a Quadra 800 emulation, but MacOS (for m68k) currently will not fully boot. I found this in a documentation:

That's the official statement. However, back in August, UTM was using MCAyland's Screamer fork of QEMU-PPC, which is definitely NOT the stable build (as it's incompatible with snapshotting at the moment).

Since they jumped on Screamer, I thought they might opt to do the same type of fork hopping for 7.x and A/UX emulation of the m68k core.

Yeah, I think it was me who pointed the dev to the screamer fork before, in early 2020 (unless he has heard about it before I came in). But in general, the direction UTM is headed now (especially with Apple Silicon transition) is more towards newer, modern virtual machines than retro machines. He has been doing work to get virgl 3D running (works only for linux vms), by porting another patch from akihikodaki's GitHub repo.

I think the dev has seen that UTM is a very good competitor for Parallels and VMware on M1 machines, and this explains his focus on modern vms.

That said, I wouldn't expect something from him for m68k emulation soon. Unless QEMU devs get it working on main repository, but if the initial support is there, they will most certainly get it to work, though it's not their priority right now. The ball is on QEMU devs court. They have to play it so the UTM dev could upgrade his QEMU build.

[mcayland]

As the author of both the screamer and q800 patches, the ultimate aim is to try and get them merged upstream. However I should also add that I am a QEMU maintainer (able to send PRs) and the reason they haven't been merged yet is because they either contain hacks that need further fixes (q800) or cause regressions for some guest OSs (screamer). Of course bug reports are welcome, however investigating these issues takes time: help from others who understand Apple hardware and who can help debug and provide fixes is always gratefully received.

[Bruninho]

So, what’s the best OS X version to run in UTM? I have been considering the following and want to choose just one, for a better focus:

- OS X Tiger 10.4 (PPC)
- OS X Leopard 10.5 (PPC)
- OS X Snow Leopard (Intel)

Sorbet Leopard (custom PPC Leopard version) from macRumors forums is good, but needs RAM and more than 1gb RAM means that I’ll not have sound

I am leaning towards Tiger, but I like Leopards theme more. Leopard needs optimization (and RAM) though. Tiger is speedy, but needs a few tweaks because I can’t stand the brushed metal Finder theme…

This is where Snow Leopard enters the chat even though it is for Intel.

[adespoton]

So, what’s the best OS X version to run in UTM? I have been considering the following and want to choose just one, for a better focus:

- OS X Tiger 10.4 (PPC)
- OS X Leopard 10.5 (PPC)
- OS X Snow Leopard (Intel)

Sorbet Leopard (custom PPC Leopard version) from macRumors forums is good, but needs RAM and more than 1gb RAM means that I’ll not have sound

I am leaning towards Tiger, but I like Leopards theme more. Leopard needs optimization (and RAM) though. Tiger is speedy, but needs a few tweaks because I can’t stand the brushed metal Finder theme…

This is where Snow Leopard enters the chat even though it is for Intel.

If you only want one, Tiger gives you Classic as well, so most software from the original Mac OS through 10.4 should work. If instead you want to run OS X PPC and 32-bit Intel software, 10.6 is the right choice. 10.5 is more for actual hardware that needs the more recent architectures but is PPC (G5 and high end G4 Macs).

[Bruninho]

If you only want one, Tiger gives you Classic as well, so most software from the original Mac OS through 10.4 should work. If instead you want to run OS X PPC and 32-bit Intel software, 10.6 is the right choice. 10.5 is more for actual hardware that needs the more recent architectures but is PPC (G5 and high end G4 Macs).

Yeah, its an interesting take. Tiger IMHO is possibly the "turning point" for OS X history, being the first ever OS X with an Intel build (10.4.4), even though in reality Leopard is the real turning point, but given the conditions I listed above, Tiger is the closest I can get to it. Plus with some themes I can reduce the influence of brushed metal theme (I must confess that I like the pinstripe theme). I think I will have to boot both Tiger (PPC) and Snow Leopard (Intel) and choose one later, based on performance. Here's my take:

Although I fell in love with macOS 9.2, having never used it before, my first real (and only one to this date) experience with PPC was at uni, around 2003/2004, when they had one of these colorful macs (I think it was an early imac?) and I had to use Tiger or Panther, I vaguely remember it because it had the pinstripe theme, and Photoshop (I studied advertising/marketing) which I used for my designs. Hopefully I can find a G4 Mac Mini or G4 Cube when I move to Spain in 2022, so I can have a real taste of how the PPC Macs were.

My first real Mac was the Mid 2010 Intel Core2Duo MacBook Pro 13", and it had Snow Leopard. To this date, I was only happy with the following MacOS versions: Snow Leopard and Mountain Lion. I am satisfied with Big Sur/Monterey so far, but Apple's quality standard has dropped since Jobs death.

I'll take your advice, but I'll boot Tiger and SL to choose one and move forward with it. I'll start with Snow Leopard, so if it demands a lot of performance I can quickly discard it and move to Tiger.

So far I have the following VMs: DOS/Win311, Win98, WinXP, macOS 9, so I can cover the 90's of my childhood days and games easily. And now I need one for 2000/2010's. And I have more modern OSes like Ubuntu (arm64) and Win10 (x86) for work related stuff.

QEMU is really proving itself a great tool for emulation/hypervisor these days, particularly in M1 Macs. Parallels is not worried because they have a good gaming solution, but they are in a grey area with regards to Win10/11 arm64 licenses, and VMware is stuck at the same point only providing linux arm64 support. UTM is really very good and QEMU devs could give more support to it so QEMU can benefit from a greater adoption of its software thanks to UTM.

EDIT: Couldn't install Snow Leopard, so I went for Tiger.

EDIT 2: I basically gave up on both. Sound stutters A LOT on Tiger and Leopard PPC, with all the sound types I can use (AC97, USB-Audio, Screamer). I went to cornica.org and I played some movie trailers. I had even downloaded one and played it on QuickTime to make sure it was not connection speed. Same output: When people talks in video, sound is clear, but when there is background music, the stuttering is unbearable. Well, I guess that I will have to wait a bit longer until it is improved (or if it will be). Personally I don't see much difference between Tiger, Leopard and current modern MacOS, so probably there is not much point in emulating them, except for historical purposes. I'll just focus on my MacOS 9.2.1 install which has been working flawlessly. Thanks for the tips, though.

[adespoton]

EDIT: Couldn't install Snow Leopard, so I went for Tiger.

EDIT 2: I basically gave up on both. Sound stutters A LOT on Tiger and Leopard PPC, with all the sound types I can use (AC97, USB-Audio, Screamer). I went to cornica.org and I played some movie trailers. I had even downloaded one and played it on QuickTime to make sure it was not connection speed. Same output: When people talks in video, sound is clear, but when there is background music, the stuttering is unbearable. Well, I guess that I will have to wait a bit longer until it is improved (or if it will be). Personally I don't see much difference between Tiger, Leopard and current modern MacOS, so probably there is not much point in emulating them, except for historical purposes. I'll just focus on my MacOS 9.2.1 install which has been working flawlessly. Thanks for the tips, though.

The only useful audio for OS X PPC is Screamer. Unfortunately, there are still some FPU math issues that seem to cause stuttering on the audio; it's WAY better than it used to be, but still not fixed. It doesn't appear to be a CPU cycles issue, but something in the emulation itself and how audio interacts with the FPU. There's a build of QEMU-PPC on here that has modified FPU emulation that helps this significantly. However, doing that makes the FPU results unreliable (for spreadsheets and the like) and Screamer still has some compatibility issues with the main QEMU-PPC branch that are being worked out.

Hopefully someone will crack the audio issue one of these days, and be able to roll all the changes back into the main branch. Then the UTM guys can just use that, and we'll have simplicity, reliability AND performance in one package.

[Bruninho]

Yeah, I agree. Let’s hope that with the time and work, devs will be able to make it better. Meanwhile, I’m perfectly fine with what I have so far with UTM.

[Bruninho]

Has anyone ever managed to passthrough an iPod Nano 1st gen (Black 2GB) from USB to macOS 9.2.2 on UTM? I am trying to do that to sync some music from iTunes.

EDIT: Nevermind. Apparently the minimum OS to sync is Mac: 10.3.9 or Windows: 2000, and iTunes 7 or later. I'll have to use the XP SP3 VM I was using on VMware from my intel Mac and converted to QEMU; But this is not on UTM, it's vanilla QEMU with 3dfx patch fork. I'll have to manually add the device to the command line before firing up the VM. Thanks anyway

[adespoton]

So, I've been slowly picking away at working around UTM's defaults to get things working.

As per https://github.com/adespoton/utmconfigs ... /README.md I've got almost everything booting from Mac OS 9.0.4 through macOS 12, with a few exceptions.

Oddly, UTM is doing something in the default CUDA profile that prevents keyboard detection; adding a USB keyboard via -usbdevice keyboard or -usb -device usb-kbd doesn't do anything.

Mouse capture is a bit wonky on some configs, needing to press cmd-opt a few times before it hooks correctly. Once you get the hang of it, it's pretty fast to get working though.

So... our in-house builds of qemu-system-ppc and qemu-system-ppc-screamer both work with CUDA and keyboard support, but UTM doesn't. So they've done something novel in their default config, assuming something's present that isn't.

If any of us can figure out what that is, I'll submit a bug report and get it fixed.

I'll get the PPC pre-built configurations for the fully working setups added to the repository sometime this week. I've also added screenshots and custom icons to the configs, and will be adding extra details to the notes section

[Cat_7]

Our builds have their issues with usb and adb as well

Mac OS 9.0.4 wil not boot with mac99,via=pmu (which defaults to usb bus with usb-mouse and usb-kbd)
It will also have a problem with mac99 (which defaults to adb with adb-mouse and adb-kbb) and additional usb bus: -usb -device usb-mouse -device kbd (here only the device mentioned first on the command line will work
When adding only -usb -device usb-mouse you can see it fall back to the adb mouse until you use e.g. usb prober from the DDK to get the mouse going.

Same issue with 10.0 and 10.1. Mac OS 9.1 and particularly 9.2 do better.

Only recently I took this up with Mark again when I traced usb traffic on the bus, and he replied:
"It looks like adding the extra USB arguments to the command line is adding additional
input devices and also a USB hub. My guess is that QEMU/OpenBIOS end up choosing the
wrong input device in these cases so the chosen device doesn't match the one that
gets connected to QEMU's host keyboard/mouse handlers."

Too bad UTM does not run without Metal support, otherwise I could try in one of my VMs.

I assume UTM defaults to the safe mac99 option, as only 10.5 requires via=pmu. And so you run into the problem I described above when adding a usb bus and devices

With which Mac OS versions do you have issues?
I believe UTM allows you to see the qemu command line it uses? Can you provide two command lines? One with mac99 and and one mac99,via=pmu?

Best,
Cat_7

[adespoton]

Our builds have their issues with usb and adb as well

Mac OS 9.0.4 wil not boot with mac99,via=pmu (which defaults to usb bus with usb-mouse and usb-kbd)
It will also have a problem with mac99 (which defaults to adb with adb-mouse and adb-kbb) and additional usb bus: -usb -device usb-mouse -device kbd (here only the device mentioned first on the command line will work
When adding only -usb -device usb-mouse you can see it fall back to the adb mouse until you use e.g. usb prober from the DDK to get the mouse going.

Same issue with 10.0 and 10.1. Mac OS 9.1 and particularly 9.2 do better.

Only recently I took this up with Mark again when I traced usb traffic on the bus, and he replied:
"It looks like adding the extra USB arguments to the command line is adding additional
input devices and also a USB hub. My guess is that QEMU/OpenBIOS end up choosing the
wrong input device in these cases so the chosen device doesn't match the one that
gets connected to QEMU's host keyboard/mouse handlers."

Too bad UTM does not run without Metal support, otherwise I could try in one of my VMs.

I assume UTM defaults to the safe mac99 option, as only 10.5 requires via=pmu. And so you run into the problem I described above when adding a usb bus and devices

With which Mac OS versions do you have issues?
I believe UTM allows you to see the qemu command line it uses? Can you provide two command lines? One with mac99 and and one mac99,via=pmu?

Best,
Cat_7

Thanks Cat_7; I've got configurations using our builds that all run just fine. It's when I try running those in UTM with the same custom flags that things start to break. Mark's comment about the USB hub is the same conclusion I came to -- UTM uses -nodefaults but then explicitly adds in a USB hub and a bunch of USB routing. The mouse and keyboard appear to be grabbed by the first set of (non-working) bindings every time.

UTM defaults to all the least safe options for mac99 -- it has screamer compiled in, and defaults to via=pmu instead of the default via=cuda. If you remove via=pmu from the options, the resulting flag passed to qemu is "-M mac99," -- so I've explicitly added via=cuda so qemu is happy.

Under PPC, it's the usual suspects that have issues -- the ones that require CUDA instead of PMU: 9.0.x, 10.0.x and 10.1.x. Interestingly, mouse input is captured functionally -- in fact, you can't change the mouse input no matter what you put as extra arguments, although sometimes for some host hardware adding -usbdevice tablet seems to fix mouse input when it's totally unresponsive, despite the UTM pre-set USB framework already having a tablet entry.

Also interestingly, UTM has an option for "Legacy (PS/2) Mode" that when checked, sends the mouse pointer flying to the bottom right of the screen, like has been described in our forums.

Here's a sample config for OS X 10.0:

Code: Select all

Running:  -L /Applications/UTM.app/Contents/Resources/qemu -S -qmp tcp:127.0.0.1:4000,server,nowait -nodefaults -vga none -spice "unix=on,addr=/Users/ludgates/Library/Group Containers/WDNLXAD4W8.com.utmapp.UTM/4D6EFE89-3FF4-4110-8E05-7FE7A930FE6D.spice,disable-ticketing=on,image-compression=off,playback-compression=off,streaming-video=off,gl=off" -device VGA -smp cpus=1,sockets=1,cores=1,threads=1 -machine mac99,via=cuda -accel tcg,tb-size=64 -boot menu=on -m 256 -audiodev coreaudio,id=audio0 -name "OS X Server 10.0" -usb -device usb-tablet,bus=usb-bus.0 -device usb-mouse,bus=usb-bus.0 -device usb-kbd,bus=usb-bus.0 -device ich9-usb-ehci1,id=usb-controller-0 -device ich9-usb-uhci1,masterbus=usb-controller-0.0,firstport=0,multifunction=on -device ich9-usb-uhci2,masterbus=usb-controller-0.0,firstport=2,multifunction=on -device ich9-usb-uhci3,masterbus=usb-controller-0.0,firstport=4,multifunction=on -chardev spicevmc,name=usbredir,id=usbredirchardev0 -device usb-redir,chardev=usbredirchardev0,id=usbredirdev0,bus=usb-controller-0.0 -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=usb-controller-0.0 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=usb-controller-0.0 -device ide-hd,bus=ide.0,drive=drive0,bootindex=0 -drive "if=none,media=disk,id=drive0,file=~/Library/Containers/com.utmapp.UTM/Data/Documents/OS X Server 10.0.utm/Images/OS X 10.0 Server.qcow2,cache=writethrough" -device ide-cd,bus=ide.1,drive=drive1,bootindex=1 -drive if=none,media=cdrom,id=drive1 -device sungem,mac=C6:F8:CC:03:A4:E2,netdev=net0 -netdev user,id=net0 -uuid 4D6EFE89-3FF4-4110-8E05-7FE7A930FE6D -rtc base=localtime -g 1280x720x32 -usbdevice keyboard

- this results in a functional mouse (takes a few tries to capture it correctly -- possibly it's cycling through the different possible input/output combinations? -- but never results in a functional keyboard.

Under x86, it's 10.4 through 10.6 that I'm having issues with. Despite OpenCore documentation saying they should be able to use one of two particular configurations of a Penryn architecture for 32 or 64 bit mode, they all lock up during the initial bootload process.

macOS 11 also has issues with a kernel panic; I haven't isolated what the issue is there yet.

[Cat_7]

Oh lovely: nodefaults

It is obvious from the issue I described above, usb should not be used for clients 9.0 and 10.0, 10.1

When you say: "takes a few tries to capture it correctly -- possibly it's cycling through the different possible input/output combinations?" you mean you have to wiggle the mouse a bit to get it to continue to boot?

"-M mac99," -- so I've explicitly added via=cuda so qemu is happy."
mac99 already defaults to via=cuda, so is that needed?

"- this results in a functional mouse but never results in a functional keyboard". Yes that is explained above. If you reverse keyboard and mouse entries, you get a kbd, but no mouse.

I'm surprised it boots 9.0 and 9.1 at all with the screamer enabled.
A tablet driver only became available somewhere in the 10.2 versions, or perhaps in 10.3 (but there now also is one for 9.x, but obviously only functional for those guest that have no usb issues)

It looks like UTM is trying to cater for all Mac OS PPC guests, but that is not possible with either via=cuda or via=pmu with the default consequences of having an usb bus or not.
For 9.0 and 10.0, 10.1, you could try with mac99,via=cuda,usb=off

Best,
Cat_7

[adespoton]

Oh lovely: nodefaults

It is obvious from the issue I described above, usb should not be used for clients 9.0 and 10.0, 10.1

Yeah; unfortunately the USB bits are hard-coded into the UTM system. I've raised a bug about it.

When you say: "takes a few tries to capture it correctly -- possibly it's cycling through the different possible input/output combinations?" you mean you have to wiggle the mouse a bit to get it to continue to boot?

When using UTM, you can do manual mouse and keyboard capture by pressing a hot key combo -- by default, it's control-option. In order for capture to result in a movable mouse, sometimes you need to press that combination once to toggle on, once off, once on, once off, once on, in order to actually get a movable mouse in the guest.

Interestingly, the mouse works fine with no capture on 10.4 and above. On 10.3, the mouse vanishes until capture is cycled on and off, and then is captured incorrectly, resulting in two mouse pointers in very different locations at different ramping speeds; capturing again fixes this. On 10.2 and below, the mouse needs to be captured for mouse and keyboard to work at all. This is all the case no matter which via is selected.

You got me thinking though, and I went back and tested 10.2 and 10.3 with CUDA instead of PMU. And they behave exactly the same with CUDA as they do with PMU. The dodgy behaviour with USB contention only crops up on 9.0.4, 10.0.x and 10.1.x, no matter whether PMU or CUDA is used.

"-M mac99," -- so I've explicitly added via=cuda so qemu is happy."
mac99 already defaults to via=cuda, so is that needed?

I figured due to -nodefaults I shouldn't assume any default actions, and there's a trailing comma after mac99, so I wanted to ensure it wasn't attempting to feed a null or similar. Essentially, it's my way of ensuring that even with the custom build and config, I'm certain we're using CUDA because it will either work or QEMU will fail to load with a complaint about the option.

"- this results in a functional mouse but never results in a functional keyboard".
Yes that is explained above. If you reverse keyboard and mouse entries, you get a kbd, but no mouse.

That's the odd thing here; probably due to the baked-in USB setup, swapping the custom flag values at the end, or leaving the mouse entry off altogether, still results in the same mouse behaviour and no keyboard.

I'm surprised it boots 9.0 and 9.1 at all with the screamer enabled.
A tablet driver only became available somewhere in the 10.2 versions, or perhaps in 10.3 (but there now also is one for 9.x, but obviously only functional for those guest that have no usb issues)

Me too. I'm guessing the tablet being on the bus but also a mouse being on the bus is what's enabling mouse input, but the keyboard input is being bound to the wrong device. I should see if I can force in a qemu debug flag so I can dump the device tree to see what qemu thinks is being presented. Unfortunately, UTM doesn't seem to provide access to the monitor (or the ability to properly eject floppy disk images, but that's a different issue).

It looks like UTM is trying to cater for all Mac OS PPC guests, but that is not possible with either via=cuda or via=pmu with the default consequences of having an usb bus or not.
For 9.0 and 10.0, 10.1, you could try with mac99,via=cuda,usb=off

Best,
Cat_7

It's worse than just attempting to cater for all Mac OS PPC guests... the same config is also used for all UTM hosts: that is, it's set up the same for macOS x86, macOS M1, iOS and iPadOS.

I tried using mac99,via=cuda,usb=off, and it didn't change the behaviour at all on 9.0, 10.0 or 10.1. Still need the triple capture, still no keyboard communication.

I'll capture all this for the bug report though; while it doesn't present a solution, it DOES eliminate a number of things that could possibly be going wrong.

[edit]

UTM doesn't appear to have bindings to trigger the qemu monitor, but it does have the ability to switch from video output to a "console output", which provides the following info on first boot:

C>> annot manage 'EHCI USB controller' PCI device type 'usb':
>> 8086 293a (c 3 20)
>> Cannot manage 'UHCI USB controller' PCI device type 'usb':
>> 8086 2934 (c 3 0)
>> Cannot manage 'UHCI USB controller' PCI device type 'usb':
>> 8086 2935 (c 3 0)
>> Cannot manage 'UHCI USB controller' PCI device type 'usb':
>> 8086 2936 (c 3 0)

So possibly UTM is binding the keyboard to one of these, and QEMU is rejecting it?

[Cat_7]

C>> annot manage 'EHCI USB controller' PCI device type 'usb':
>> 8086 293a (c 3 20)
>> Cannot manage 'UHCI USB controller' PCI device type 'usb':
>> 8086 2934 (c 3 0)
>> Cannot manage 'UHCI USB controller' PCI device type 'usb':
>> 8086 2935 (c 3 0)
>> Cannot manage 'UHCI USB controller' PCI device type 'usb':
>> 8086 2936 (c 3 0)

I believe this just means these devices are not in the openbios pci devices list.
To my knowledge, Mac OS 9.x to 10.2. 8 only supports an ohci controller with usb 1.1 speed. One is added with -usb.
(For usb pass-through to work you can add an ehci controller from 10.2.8 upwards. With ohci, usb pass-through works only for some devices with transfer methods that do not require multiple active endpoints.
This has been diagnosed, but not fixed)

Mark showed me the usb issue through a dump in the monitor with "info qtree"
-M mac99,via=pmu:

dev: pci-ohci, id ""
masterbus = ""
num-ports = 3 (0x3)
firstport = 0 (0x0)
addr = 0d.0
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
class USB controller, addr 00:0d.0, pci id 106b:003f (sub 1af4:1100)
bar 0: mem at 0xffffffffffffffff [0xfe]
bus: usb-bus.0
type usb-bus
dev: usb-mouse, id ""
usb_version = 2 (0x2)
port = ""
serial = ""
msos-desc = true
pcap = ""
addr 0.0, port 2, speed 12, name QEMU USB Mouse, attached
dev: usb-kbd, id ""
usb_version = 2 (0x2)
display = ""
port = ""
serial = ""
msos-desc = true
pcap = ""
addr 0.0, port 1, speed 12, name QEMU USB Keyboard, attached

-M mac99,via=pmu -usb -device usb-kbd:

dev: pci-ohci, id ""
masterbus = ""
num-ports = 3 (0x3)
firstport = 0 (0x0)
addr = 0d.0
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
class USB controller, addr 00:0d.0, pci id 106b:003f (sub 1af4:1100)
bar 0: mem at 0x80080000 [0x800800ff]
bus: usb-bus.0
type usb-bus
dev: usb-hub, id ""
ports = 8 (0x8)
port-power = false
port = ""
serial = ""
msos-desc = true
pcap = ""
addr 0.3, port 3, speed 12, name QEMU USB Hub, attached
dev: usb-kbd, id ""
usb_version = 2 (0x2)
display = ""
port = ""
serial = ""
msos-desc = true
pcap = ""
addr 0.0, port 3.1, speed 12, name QEMU USB Keyboard, attached
dev: usb-mouse, id ""
usb_version = 2 (0x2)
port = ""
serial = ""
msos-desc = true
pcap = ""
addr 0.2, port 2, speed 12, name QEMU USB Mouse, attached
dev: usb-kbd, id ""
usb_version = 2 (0x2)
display = ""
port = ""
serial = ""
msos-desc = true
pcap = ""
addr 0.1, port 1, speed 12, name QEMU USB Keyboard, attached

It's worse than just attempting to cater for all Mac OS PPC guests... the same config is also used for all UTM hosts: that is, it's set up the same for macOS x86, macOS M1, iOS and iPadOS.

I can imagine it becoming a nightmare to support various qemu versions separately, but part of the problem is in Qemu.

When using UTM, you can do manual mouse and keyboard capture by pressing a hot key combo -- by default, it's control-option. In order for capture to result in a movable mouse, sometimes you need to press that combination once to toggle on, once off, once on, once off, once on, in order to actually get a movable mouse in the guest.

Interestingly, the mouse works fine with no capture on 10.4 and above. On 10.3, the mouse vanishes until capture is cycled on and off, and then is captured incorrectly, resulting in two mouse pointers in very different locations at different ramping speeds; capturing again fixes this. On 10.2 and below, the mouse needs to be captured for mouse and keyboard to work at all. This is all the case no matter which via is selected.

Is this grab option the same as default Qemu Ctrl-Alt-G?

[adespoton]

When using UTM, you can do manual mouse and keyboard capture by pressing a hot key combo -- by default, it's control-option. In order for capture to result in a movable mouse, sometimes you need to press that combination once to toggle on, once off, once on, once off, once on, in order to actually get a movable mouse in the guest.

Interestingly, the mouse works fine with no capture on 10.4 and above. On 10.3, the mouse vanishes until capture is cycled on and off, and then is captured incorrectly, resulting in two mouse pointers in very different locations at different ramping speeds; capturing again fixes this. On 10.2 and below, the mouse needs to be captured for mouse and keyboard to work at all. This is all the case no matter which via is selected.

Is this grab option the same as default Qemu Ctrl-Alt-G?

It seems subtly different; it doesn't behave quite the same way, but the general concept seems the same. That could be down to the USB device tree that's pre-loaded though. UTM lets you choose between control-option and command-option. Neither really seems like a good choice, as you lose those modifier key combos; there's a ticket in about that.

[Cat_7]

I read up a bit on the Spice server/client "remote desktop" protocol which seems to be used, or at least started with that command line you provided.
Spice requires that usb tablet for accurate positioning of the mouse. Spice documentation also outlines some of the problems you seem to be having.

Mouse modes
Spice supports two mouse modes: server and client. The mode can be changed dynamically and is negotiated between the client and the server.

Server mouse
When a user clicks inside the Spice client window, the client mouse is captured and set invisible. In this mode, the server controls the mouse position on display. However, it might be problematic on WAN or on a loaded server, where mouse cursor might have some latency or non-responsiveness.

Client mouse
Not captured and is used as the effective pointing device. To enable client mouse, the VDI host application must register an absolute pointing device (e.g. USB tablet in QEMU). This mode is appropriate for WAN or for a loaded server, since cursor has smooth motion and responsiveness. However, the cursor might lose synchronization (position and shape) for a while.

Is UTM running the Spice client to access the VM?

[Bruninho]

Newer OS like Win 7+ guests require the installation of SPICE tools for that to work better.

Linux guest users must install it from apt-get.

modern macOS i believe does not have any SPICE tools?

old OS are left out, no SPICE tools for them.

[adespoton]

Hmm... not sure I quite understand the source enough yet to answer that question. Signals are being sent via XPC, but it appears CocoaSpice is being used to manage hardware and the display has been linked through CocoaSpice to Metal; not certain that the spice client is actually being used to connect and grab the data, but the server is definitely being used to manage things.

The behaviour I've been seeing for mouse management appears to reflect both the SPICE tablet management AND the mouse capture from regular QEMU.

On OS X 10.4+, it appears host mouse is used by default, and guest mouse is hidden. On 10.3, SPICE mouse capture appears to be used (host mouse vanishes on click). On 10.2, click does nothing, and I need to use the grab mouse combo instead. This is the same for all OSes below 10.2, no matter whether I'm using CUDA, PMU or PMU-ADB.

Your guess is likely correct, and the issue is between SPICE and CUDA, not specifically UTM. It would be interesting to see what happens to the default keyboard bindings in all these configurations, but UTM currently doesn't link to the monitor, so there's no easy way to tell.

Osy has just updated one of my tickets to say that there ARE plans in the works to support PTY for serial forwarding, and he suggested he could make the monitor a serial port option. Once that's actually implemented, debugging things like this will become significantly easier, as we can see exactly what's presented inside QEMU as the runtime flags are adjusted.

[Cat_7]

You can install the Mac OS 9.x tablet driver and see what happens to those guests.

https://github.com/kanjitalk755/macos9-usb-tablet

As said above, a tablet driver coming with the OS was only available from 10.2.8 or even 10.3 upwards

Best,
Cat_7

[adespoton]

Newer OS like Win 7+ guests require the installation of SPICE tools for that to work better.

Linux guest users must install it from apt-get.

modern macOS i believe does not have any SPICE tools?

old OS are left out, no SPICE tools for them.

UTM is using the SPICE server and client framework to manage a lot of the hardware, irrespective of what features are available in the guest environment.

This means that while clipboard sharing, host filesystem sharing and some of the virtual displays aren't available on macOS because the SPICE tools aren't present for macOS integration, the mouse and keyboard interface, as well as serial communications, virtual disk management, virtual network management, virtual display management are all still handled by SPICE -- it's just that the guest environment doesn't need any specific drivers (other than USB for the mouse and keyboard) to handle this, as SPICE is presenting interfaces the guest OS already understands.

One of the tickets I opened is for integration of 9P virtual drives into UTM, because as of macOS 14.4, the OS has a 9P filesystem driver built-in. This doesn't help for PPC guests though; they're limited to SMB shares and in some circumstances SPICE-WebDAV, both of which QEMU (and by extension UTM) supports.

This bit is something that's perked Osy's interest, as the Quickemu project has already implemented this and a host of other "nice to have" features on Linux with QEMU+SPICE binaries, and documented exactly how to implement the various components.

This means we might see more macOS integration in UTM 3.1 or later -- but it doesn't solve the CUDA/SPICE/USB issues.

You've given me an idea for another possible solution for clipboard sharing and mouse integration though: UTM has the ability to run in "Console Mode" which just presents a TTY and no video. If this can actually boot, but just boots "headless", then I can run VNC or Remote Access, and use the mouse/keyboard/clipboard control from there I'll have to test this and see if it actually works.