CocoaSpice seems to drive USB sharing to QEMU backed machines on the same thread it reads macOS clipboard which means when a clipboard provider stalls for any reason, USB devices in the VM stall and fail their transfers.
This is easily reproducible by running the test Swift file which creates a clipboard provider with an intentional sleep.
This may seem an unrealistic issue but in reality many providers are not instant (Apple's Screen Sharing for example).
- Have a Linux VM, QEMU backend, clipboard sharing enabled and spice guest agent running
- Attach a USB device to the VM, preferably one with active transfers.
- Watch dmesg for kernel issues around USB with e.g.
sudo dmesg -wT.
- Run the provided Swift script to produce a provider that stalls
- See USB errors in Linux kernel log + USB actually failing to behave.
Edit: heh, I focused on USB since my workflow is heavily revolved around that, but seems like the entire UI of the VM is stalled during that time. So the USB story doesn't even matter. Hope I'll get around submitting a proper PR
import AppKit
import Foundation
class BrokenClipboardPromise: NSObject, NSPasteboardItemDataProvider {
func pasteboard(_ pasteboard: NSPasteboard?, item: NSPasteboardItem, provideDataForType type: NSPasteboard.PasteboardType) {
print("provider promise called, sleeping 10 sec")
sleep(10)
print("done")
exit(0)
}
}
let item = NSPasteboardItem()
item.setDataProvider(BrokenClipboardPromise(), forTypes: [
NSPasteboard.PasteboardType("public.utf8-plain-text")
])
NSPasteboard.general.clearContents()
NSPasteboard.general.writeObjects([item])
print("Published broken promised clipboard item")
RunLoop.main.run()
Configuration
- UTM Version: 5.0.3
- macOS Version: 26.5
- Mac Chip: M4 Pro
CocoaSpice seems to drive USB sharing to QEMU backed machines on the same thread it reads macOS clipboard which means when a clipboard provider stalls for any reason, USB devices in the VM stall and fail their transfers.
This is easily reproducible by running the test Swift file which creates a clipboard provider with an intentional sleep.
This may seem an unrealistic issue but in reality many providers are not instant (Apple's Screen Sharing for example).
sudo dmesg -wT.Edit: heh, I focused on USB since my workflow is heavily revolved around that, but seems like the entire UI of the VM is stalled during that time. So the USB story doesn't even matter. Hope I'll get around submitting a proper PR
Configuration