> On 15 Jun 2023, at 00.40, Alexander Graf <g...@amazon.com> wrote: > > This patch set introduces a new ARM and HVF specific machine type > called "vmapple". It mimicks the device model that Apple's proprietary > Virtualization.Framework exposes, but implements it in QEMU. > > With this new machine type, you can run macOS guests on Apple Silicon > systems via HVF. To do so, you need to first install macOS using > Virtualization.Framework onto a virtual disk image using a tool like > macosvm (https://github.com/s-u/macosvm) > > $ macosvm --disk disk.img,size=32g --aux aux.img \ > --restore UniversalMac_12.0.1_21A559_Restore.ipsw vm.json > > Then, extract the ECID from the installed VM: > > $ cat "$DIR/macosvm.json" | python3 -c \ > 'import json,sys;obj=json.load(sys.stdin);print(obj["machineId"]) | \ > base64 -d | plutil -extract ECID raw -
Beware, that the file will be called 'vm.json' and DIR is undefined following the previous line. Also, it's missing a single-quote at the end of `["machineId"])`. > In addition, cut off the first 16kb of the aux.img: > > $ dd if=aux.img of=aux.img.trimmed bs=$(( 0x4000 )) skip=1 > > Now, you can just launch QEMU with the bits generated above: > > $ qemu-system-aarch64 -serial mon:stdio \ > -m 4G \ > -M vmapple,uuid=6240349656165161789 \ > -bios /Sys*/Lib*/Fra*/Virtualization.f*/R*/AVPBooter.vmapple2.bin \ > -pflash aux.img.trimmed \ > -pflash disk.img \ > -drive file=disk.img,if=none,id=root \ > -device virtio-blk-pci,drive=root,x-apple-type=1 \ > -drive file=aux.img.trimmed,if=none,id=aux \ > -device virtio-blk-pci,drive=aux,x-apple-type=2 \ > -accel hvf -no-reboot Just for clarity, I'd add that the 'vmapple,uuid=...' has to be set to the ECID the previous step. You haven't defined a display, but I'm not sure if that is on purpose to show a minimal setup. I had to add '-display sdl' for it to fully work. > There are a few limitations with this implementation: > > - Only runs on macOS because it relies on > ParavirtualizesGraphics.Framework > - Something is not fully correct on interrupt delivery or > similar - the keyboard does not work > - No Rosetta in the guest because we lack the private > entitlement to enable TSO Would it be possible to mitigate the keyboard issue using an emulated USB keyboard? I tried poking around with it, but with no success. > Over time, I hope that some of the limitations above could cease to exist. > This device model would enable very nice use cases with KVM on an Asahi > Linux device.
