ThierryLC

Platform**: Unraid 6.12.54 / QEMU pc-q35-9.2 / macOS Ventura 13.x GPU: AMD Radeon Pro WX 7100 (Polaris 10, PCI 1002:67C4) Result: Full Metal 2 acceleration, physical DisplayPort output, stable across VM restarts Problem SummaryAfter setting up AMD GPU passthrough for macOS Ventura on Unraid/KVM, three distinct problems prevented the GPU from working: GPU not recognized by macOS (IOPCISlotDevicePresent = No) Kernel panic AMD9500Controller::detectPowerDown(): GPU is not found. NO MM PCI access!!! Network (ethernet) not visible in macOS (en0 absent) Root Causes and FixesProblem 1 — GPU Not Recognized (ACPI Hot-Plug Issue)Cause: macOS Ventura uses ACPI-based PCIe enumeration (IOPCIHPType = 0x21). QEMU generates ACPI hot-plug methods for all PCIe root ports, even with hotplug='off'. When macOS sees ACPI hot-plug methods on a root port, it defers device enumeration to runtime (no boot-time probe), resulting in IOPCISlotDevicePresent = No. Fix: Place the GPU directly on the PCIe root complex (bus 0), bypassing all root ports. <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0b' slot='0x00' function='0x0'/> </source> <!-- No rom bar='off' — use native ROM --> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0b' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/> </hostdev>Key points: bus='0x00' = root complex (not behind a root port) multifunction='on' on function 0 (GPU) so macOS sees the audio function 1 Do not use <rom bar='off'/> — native VBIOS is required Problem 2 — Kernel Panic: NO MM PCI accessPanic message: AMD9500Controller::detectPowerDown(): GPU is not found. NO MM PCI access!!! at ATIController.cpp:3170 Cause: AMD9500Controller::detectPowerDown() reads a GPU MMIO register early in driver initialization. On Polaris10/Ellesmere GPUs, if power gating is active at that moment, the register returns 0xFFFFFFFF (GPU appears powered down), triggering the panic. This is not a memory space enable (MSE) issue — it's a power gating race condition during the UEFI→OS transition. Fix: Add radpg=15 to OpenCore boot-args. radpg = Radeon Power Gating. Value 15 (0b1111) disables 4 power gating features, keeping the GPU in the active state during initialization so the MMIO register check returns a valid value. How to set it (via Unraid SSH, with OpenCore EFI mounted): # Mount OpenCore image (adjust partition offset as needed) mkdir -p /mnt/opencore_efi mount -o loop,offset=$((40*512)) /mnt/cache_nvme_1to/domains/Ventura/OpenCore-feb21-visual.img /mnt/opencore_efi python3 -c " import plistlib path = '/mnt/opencore_efi/EFI/OC/config.plist' with open(path, 'rb') as f: c = plistlib.load(f) nvram = c['NVRAM']['Add']['7C436110-AB2A-4BBB-A880-FE41995C9F82'] # Add radpg=15 to boot-args current = nvram.get('boot-args', '') if 'radpg' not in current: nvram['boot-args'] = current + ' radpg=15' with open(path, 'wb') as f: plistlib.dump(c, f) print('Done:', nvram['boot-args']) " umount /mnt/opencore_efiRequired boot-args: keepsyms=1 -v debug=0x100 serial=3 agdpmod=pikera radpg=15agdpmod=pikera — bypasses Apple GPU Device Policy (required for non-Apple GPUs as primary display) radpg=15 — disables Polaris power gating during init (fixes the panic) Problem 3 — Network Not Visible (vmxnet3 on Wrong Bus)Cause: Same ACPI hot-plug issue as above. Unraid VM Manager places the NIC on bus 0x01 (behind a root port) by default → macOS ignores it. Fix: Place the NIC on bus 0x00 (root complex), slot 0x03. <interface type='bridge'> <mac address='00:16:cb:43:ca:ed'/> <source bridge='br0'/> <model type='vmxnet3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> vmxnet3 is natively supported by macOS (no extra kext needed) and is the correct model for KVM/QEMU macOS VMs. Complete Working VM XML (relevant sections)<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>Ventura</name> <memory unit='KiB'>16777216</memory> <vcpu placement='static'>8</vcpu> <os> <type arch='x86_64' machine='pc-q35-9.2'>hvm</type> <loader readonly='yes' type='pflash' format='raw'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram format='raw'>/etc/libvirt/qemu/nvram/YOUR-UUID_VARS-pure-efi.fd</nvram> </os> <cpu mode='host-passthrough' check='none' migratable='on'> <topology sockets='1' dies='1' clusters='1' cores='4' threads='2'/> <cache mode='passthrough'/> <feature policy='require' name='topoext'/> </cpu> <devices> <!-- GPU: function 0 (video) — directly on bus 0 (root complex) --> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0b' slot='0x00' function='0x0'/> </source> <!-- No rom bar='off' — native VBIOS required for UEFI GOP + macOS init --> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/> </hostdev> <!-- GPU: function 1 (HDMI audio) --> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0b' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/> </hostdev> <!-- NIC: vmxnet3 on bus 0 (root complex) — mandatory for macOS to see it --> <interface type='bridge'> <mac address='00:16:cb:43:ca:ed'/> <source bridge='br0'/> <model type='vmxnet3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <!-- No VNC/QXL video device — GPU provides the display directly --> <memballoon model='none'/> </devices> <qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='************************'/> <qemu:arg value='-smbios'/> <qemu:arg value='type=2'/> <qemu:arg value='-cpu'/> <qemu:arg value='Skylake-Server,vendor=GenuineIntel,+hypervisor,+invtsc,kvm=on,+fma,+avx,+avx2,+aes,+ssse3,+sse4_2,+popcnt,+sse4a,+bmi1,+bmi2'/> </qemu:commandline> </domain>Required Unraid ModulesInstall vendor-reset (available in Community Apps): vendor-reset performs an AMD-specific BACO (Bus/Adapter CleAn Operation) reset when the VM stops, preventing the AMD Reset Bug from corrupting the GPU state for subsequent VM starts. Verify it's working: dmesg | grep AMD_POLARIS # Should show: performing reset, reset result = 0 # After VM shutdown, PC should show a valid value (e.g. 0x294c), NOT 0xffffffffResultsSystem Information Report — macOS Ventura Graphics/Displays: AMD Radeon Pro WX 7100: Chipset Model: AMD Radeon Pro WX 7100 VRAM (Total): 8 GB Vendor: AMD (0x1002) Device ID: 0x67c4 Metal Support: Metal 2 Displays: [Physical Monitor]: Resolution: 1680 x 1050 @ 60.00Hz Main Display: Yes Online: YesAMD kexts loaded: AMDSupport, AMD9500Controller, AMDRadeonX4000, AMDRadeonX4000HWLibs, AMDFramebuffer — all active, AMDFramebufferVIB registered (not just AtiFbStub). Why These Fixes Are Non-ObviousIssue Common Assumption Reality GPU not enumerated hotplug='off' fixes ACPI hot-plug QEMU still generates ACPI methods regardless — only bus 0 avoids them NO MM PCI access panic MSE bit not restored after UEFI handoff Power gating race condition — GPU enters low-power state during init NIC invisible vmxnet3 is not supported vmxnet3 is fully supported, but must be on bus 0 _Tested on Unraid 6.12.54, QEMU 9.2, macOS Ventura 13.7, OpenCore 1.x with WhateverGreen + Lilu kexts.

Environnement : Unraid 7.x, QEMU 9.2.3, machine virtuelle Q35, macOS Ventura 13.6.x, OpenCore 1.0.x (Macinabox) SymptômeLa VM macOS Ventura démarre et fonctionne, mais aucune interface réseau n'apparaît dans Préférences Système → Réseau. Pas de en0, pas d'en1. Ni vmxnet3, ni virtio, ni e1000-82545em ne donnent de réseau. Cause racinemacOS Ventura sur QEMU/KVM (machine Q35) n'énumère que les périphériques PCI directement sur le bus 0 (le root complex ICH9). Les devices placés derrière des PCIe root ports (bus 1, 2, 3…) sont silencieusement ignorés. Or, Unraid VM Manager place par défaut le NIC sur bus=0x01 (via un pcie-root-port), ce qui le rend invisible pour macOS. Concrètement, dans virsh qemu-monitor-command Ventura --hmp 'info pci' : Devices sur bus 0 (USB, VGA, SATA…) → BARs mappés, IRQ assigné → macOS les voit ✅ Device réseau sur bus 3 (via pci.1) → BAR: not mapped, IRQ=0 → macOS l'ignore ❌ Ce qui ne fonctionne pas (et pourquoi)Modèle NIC PCI ID Raison de l'échec e1000-82545em 8086:100F IntelMausi.kext ne supporte pas ce PCI ID (82545EM trop ancien) virtio 1AF4:1041 Pas de driver natif macOS x86 pour le mode non-transitional vmxnet3 sur bus 0x01 15AD:07B0 Bus invisible pour macOS → BARs not mapped FixDeux conditions nécessaires et suffisantes : Modèle NIC : vmxnet3 Driver natif intégré à macOS Ventura : AppleVmxnet3Ethernet.kext (dans IONetworkingFamily). Aucun kext supplémentaire. Adresse PCI : bus 0x00, slot 0x03 — directement sur le root complex Application du fixssh root@<IP_UNRAID> virsh edit VenturaChercher le bloc <interface type='bridge'> et modifier comme suit : <interface type='bridge'> <mac address='52:54:00:xx:xx:xx'/> <source bridge='br0'/> <model type='vmxnet3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>Puis redémarrer la VM : virsh destroy Ventura && virsh start VenturaVérificationDepuis Unraid, après le boot de macOS (~60s) : # IP obtenue par DHCP arp -n | grep <MAC_DU_NIC> # Ping ping -c 3 <IP_MACOS>Résultat attendu : IP DHCP attribuée, ping 0% packet loss. Piège à éviterUnraid VM Manager déplace automatiquement le NIC vers bus 0x01 lors de toute modification de la VM via l'interface web. Après chaque édition dans le VM Manager, vérifier et corriger l'adresse PCI : virsh dumpxml Ventura | grep -A8 'interface type'Si bus='0x01' apparaît → relancer le fix ci-dessus. Pour éviter ce problème, préférer virsh edit Ventura à l'interface Unraid pour toute modification future. Infos complémentairesTesté avec QEMU 9.2.3 (Unraid 7), machine Q35 (pc-q35-9.2), OpenCore 1.0.x La même cause (bus PCI) explique probablement les problèmes similaires signalés avec Monterey et Sonoma sur Macinabox Sur Proxmox, ce bug n'apparaît pas car le NIC est placé différemment par défaut dans les templates Proxmox

Plateforme :** Unraid + KVM/QEMU (pc-q35-9.2) + CPU AMD Ryzen 7 + Macinabox / KVM-Opencore v21 Symptômes de départ : logo Apple → retour au picker OpenCore, ou blocage silencieux sans aucun message, ou EXITBS:START ContexteAMD Ryzen sur KVM cumule plusieurs problèmes indépendants qui, combinés, rendent le boot de Ventura particulièrement difficile à diagnostiquer. Ce post documente chaque problème rencontré, sa cause racine, et la correction appliquée — dans l'ordre chronologique du debug. Problème 1 — Le CPU AMD fait planter XNU au démarrageSymptômeLa VM affiche le logo Apple, parfois une barre de progression partielle, puis revient au picker OpenCore sans aucun message d'erreur. En mode verbose (-v), on peut voir l'amorce du boot XNU puis un arrêt brutal. CausemacOS vérifie à l'initialisation que le CPU est un Intel compatible via l'instruction CPUID. Un Ryzen en host-passthrough brut expose un CPU AMD dont la signature CPUID ne correspond à aucune famille Intel reconnue par XNU. macOS refuse alors de continuer. Correction — Override CPU dans qemu:commandlineDans le XML libvirt, on garde host-passthrough pour la compatibilité KVM, mais on le surcharge via -cpu dans qemu:commandline pour présenter un CPU Intel à macOS : <cpu mode='host-passthrough' check='none' migratable='on'> <topology sockets='1' dies='1' clusters='1' cores='4' threads='2'/> <cache mode='passthrough'/> <feature policy='require' name='topoext'/> </cpu><qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='************************'/> <qemu:arg value='-smbios'/> <qemu:arg value='type=2'/> <qemu:arg value='-cpu'/> <qemu:arg value='Skylake-Server,vendor=GenuineIntel,+hypervisor,+invtsc,kvm=on,+fma,+avx,+aes,+ssse3,+sse4_2,+popcnt,+sse4a,+bmi1,+bmi2'/> </qemu:commandline>Le -cpu dans qemu:commandline écrase le host-passthrough défini dans <cpu> : c'est le comportement de QEMU quand on passe -cpu en argument direct. macOS voit un Skylake-Server GenuineIntel au lieu d'un Ryzen. Pourquoi Skylake-Server spécifiquement ? Il expose les bons flags SSE/AVX pour Ventura, est reconnu par la table CPUFAMILY d'XNU, et est supporté par les patches kernel AMD (voir plus bas). Problème 2 — Ventura 13.x refuse de booter sans AVX2 (CryptexFixup)SymptômeMême avec l'override CPU Intel, Ventura 13.x panique très tôt au démarrage. L'erreur, visible en verbose, est liée à Cryptex — le système de mise à jour encapsulée d'Apple. CauseVentura utilise un mécanisme appelé Cryptex pour livrer les mises à jour OS. Il existe deux variantes de l'image Cryptex : une optimisée AVX2 et une non-AVX2. Au démarrage, macOS détecte la présence du flag AVX2 dans le CPUID et choisit la variante correspondante. Sur un hack/VM, si vous activez AVX2 dans le CPU présenté à macOS mais que la variante AVX2 de la Cryptex est absente ou incohérente, vous obtenez un kernel panic. Correction — Ne PAS activer +avx2, utiliser CryptexFixup.kextLa ligne -cpu ne doit pas contenir +avx2 : Skylake-Server,vendor=GenuineIntel,+hypervisor,+invtsc,kvm=on,+fma,+avx,+aes,+ssse3,+sse4_2,+popcnt,+sse4a,+bmi1,+bmi2Sans +avx2, macOS sélectionne la variante non-AVX2 de la Cryptex. CryptexFixup.kext (de Lilu) complète ce mécanisme en patchant _apfs_filevault_allowed pour autoriser le boot avec la variante non-AVX2 : <!-- Dans config.plist, Kernel > Add --> <dict> <key>BundlePath</key> <string>CryptexFixup.kext</string> <key>Comment</key> <string>Support for non-AVX2 CPUs in Ventura/Sonoma</string> <key>Enabled</key> <true/> <key>MinKernel</key> <string>22.1.0</string> <key>MaxKernel</key> <string>23.99.99</string> </dict>Un patch kernel Force FileVault vient compléter CryptexFixup (du projet OCLP) : Base : _apfs_filevault_allowed Find : (vide) Replace : uAEAAADD (mov eax, 1 ; ret)Problème 3 — Les patches kernel AMD obligatoiresOpenCore KVM-Opencore v21 inclut 5 patches kernel essentiels pour AMD sur Ventura : Patch 1 & 2 — algrey/thenickdude : force CPUFAMILY_INTEL_PENRYNmacOS détermine la famille CPU via la fonction cpuid_set_cpufamily dans XNU. Même avec un CPUID Intel en entrée, XNU calcule une famille qui peut ne pas correspondre à CPUFAMILY_INTEL_PENRYN (la seule famille garantie compatible avec tous les chemins de code macOS). Ces patches forcent le retour de Penryn : Patch 1 : pour macOS 10.13–11.2 (MinKernel 17.0.0, MaxKernel 20.3.99) Patch 2 : pour macOS 11.3+ jusqu'à Sonoma (MinKernel 20.4.0, MaxKernel 23.99.99) — version thenickdude Patches 3 & 4 — SurPlus v1 : PRNG non-monotonic (Big Sur 11.3–11.4 seulement)Patchent _early_random et _register_and_init_prng pour Big Sur 11.3–11.4. Actifs sur MinKernel 20.4.0 / MaxKernel 21.1.0, inactifs sur Ventura mais doivent être présents dans le config. Patch 5 — FileVault / CryptexFixup (décrit ci-dessus)Problème 4 — Le crash silencieux : panic non-monotonic time sur AMDSymptômeLe plus difficile à diagnostiquer. La VM s'arrête brutalement sans aucune sortie visible. Même en mode verbose, rien ne s'affiche après un certain stade. La VM redémarre automatiquement (watchdog). On croit à un problème de configuration alors que le kernel a paniqué silencieusement. Méthode de debug — Serial log vers fichierLa clé pour voir ce qui se passe : rediriger la sortie série (console noyau) vers un fichier sur l'hôte Unraid. Dans le XML : <serial type='file'> <source path='/tmp/ventura_serial.log' append='on'/> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='file'> <source path='/tmp/ventura_serial.log' append='on'/> <target type='serial' port='0'/> </console>Et dans les boot-args OpenCore (NVRAM) : boot-args = keepsyms=1 debug=0x100 -v serial=3serial=3 active la sortie sur le port série. On peut ensuite surveiller en temps réel : tail -f /tmp/ventura_serial.log | tr -cd '[:print:]\n\t'Ce qu'on voit dans le logpanic(cpu 3 caller 0xffffff800f8b3c2a): "non-monotonic time: prev...Ou plus subtilement, la VM cesse de produire des messages alors que le boot était en cours. CauseLes CPU AMD Ryzen sous KVM ont un comportement du TSC (Time Stamp Counter) qui peut produire des valeurs non-monotoniques vues depuis les différents cœurs. XNU (le noyau macOS) considère cela comme un état impossible et appelle panic() dans les fonctions de scheduling : thread_quantum_expire thread_unblock thread_invoke thread_dispatch Correction — 2 patches kernel Visual (non-monotonic time)Ces deux patches, publiés par "Visual" sur les forums Hackintosh, neutralisent les vérifications de temps monotone dans XNU pour macOS 12.0+ (MinKernel 21.0.0) : Patch 6 — thread_quantum_expire / thread_unblock / thread_invoke (3 occurrences) <dict> <key>Comment</key> <string>Visual | thread_quantum_expire, thread_unblock, thread_invoke | Remove non-monotonic time panic | 12.0+</string> <key>Count</key> <integer>3</integer> <key>Enabled</key> <true/> <key>Find</key> <data>SAAAAAIAAEgAAFgAAAAPAAAAAAA=</data> <key>Identifier</key> <string>kernel</string> <key>Mask</key> <data>/wAAD/////8AAP8AAAD/AAAAAAA=</data> <key>MaxKernel</key> <string>25.99.99</string> <key>MinKernel</key> <string>21.0.0</string> <key>Replace</key> <data>AAAAAAAAAAAAAAAAAABmkGaQZpA=</data> <key>ReplaceMask</key> <data>AAAAAAAAAAAAAAAAAAD///////8=</data> </dict>Patch 7 — thread_invoke / thread_dispatch (2 occurrences) <dict> <key>Comment</key> <string>Visual | thread_invoke, thread_dispatch | Remove non-monotonic time panic | 12.0+</string> <key>Count</key> <integer>2</integer> <key>Enabled</key> <true/> <key>Find</key> <data>SAAAgAQAAA8AAAAAAA==</data> <key>Identifier</key> <string>kernel</string> <key>Mask</key> <data>SAAA8P////8AAAAAAA==</data> <key>MaxKernel</key> <string>25.99.99</string> <key>MinKernel</key> <string>21.0.0</string> <key>Replace</key> <data>AAAAAAAAAGaQZpBmkA==</data> <key>ReplaceMask</key> <data>AAAAAAAAAP///////w==</data> </dict>Ces deux patches sont absents du KVM-Opencore v21 de base et doivent être ajoutés manuellement dans le config.plist (monter l'image .img de l'EFI, éditer EFI/OC/config.plist). Configuration OpenCore complète — points critiquesBooter > QuirksQuirk Valeur Raison SetupVirtualMap False CRITIQUE sur KVM — macOS n'a pas besoin du remapping de la virtual map UEFI en environnement VM RebuildAppleMemoryMap False Cause des panics sur AMD KVM si activé SyncRuntimePermissions False Incompatible avec l'environnement KVM AMD AvoidRuntimeDefrag True Nécessaire ProvideCustomSlide True Nécessaire EnableSafeModeSlide True Nécessaire Kernel > QuirksQuirk Valeur ProvideCurrentCpuInfo True — fournit les informations CPU correctes à macOS, requis sur AMD DisableLinkeditJettison True ForceSecureBootScheme True Kernel > Emulate<key>Cpuid1Data</key> <data>VAYFAAAAAAAAAAAAAAAAAA==</data> <key>Cpuid1Mask</key> <data>////AAAAAAAAAAAAAAAAAA==</data> <key>DummyPowerManagement</key> <true/>Force un CPUID compatible Intel pour les couches OS qui lisent directement le registre (au-delà du patch cpuid_set_cpufamily). Misc > Security<key>SecureBootModel</key> <string>Disabled</string>Obligatoire en VM KVM (pas d'Apple T2/SEP). NVRAMboot-args : keepsyms=1 debug=0x100 -v serial=3 csr-active-config : 0x26 0x0f (SIP partiellement désactivé)PlatformInfoSMBIOS iMacPro1,1 — le profil machine qui correspond le mieux à la configuration Intel Xeon / KVM VM. Nécessite des MLB/SerialNumber valides générés avec GenSMBIOS. Kexts actifsKext Rôle Lilu Moteur de patches — requis par tous les autres CryptexFixup Support non-AVX2 pour Ventura/Sonoma WhateverGreen Patches GPU AppleALC Audio MCEReporterDisabler Désactive AppleMCEReporter qui panique sur CPU non-Apple USBPorts Mapping USB AGPMInjector Gestion GPU power BrcmFirmwareData + BrcmPatchRAM3 + BlueToolFixup Bluetooth (si carte BCM) MCEReporterDisabler est souvent oublié — sans lui, macOS panique sur multi-socket ou CPU non reconnu. Récapitulatif — Ordre de résolution des problèmes1. Boot → retour picker → Override CPU Skylake-Server sans AVX2 2. Panic Cryptex → CryptexFixup.kext + patch FileVault 3. Panic cpuid_set_cpufamily → Patches algrey/thenickdude 4. Crash silencieux sans log → Activer serial log + boot-args serial=3 5. Panic non-monotonic time → Patches Visual (patch 6 & 7) 6. Panic au boot (divers) → SetupVirtualMap=False + RebuildAppleMemoryMap=FalseCe qui fonctionne au finalAvec l'ensemble de ces corrections : OpenCore picker s'affiche correctement Sélection du disque installeur → barre de progression complète Boot jusqu'au Language Chooser / Setup Assistant sans kernel panic Système stable, pas de reboot en boucle La VM cible : Ryzen 7 (8 cœurs / 16 threads) présentés en 4c/2t à macOS, 8 Go RAM, stockage SATA raw, machine type Q35 9.2, OVMF pure-EFI. Liens utilesPatches AMD kernel : github.com/AMD-OSX/AMD_Vanilla CryptexFixup : github.com/acidanthera/CryptexFixup Patches Visual (non-monotonic time) : forums InsanelyMac / Hackintosh-Forum KVM-Opencore : github.com/thenickdude/KVM-Opencore OSX-KVM référence : [github.com/kholia/OSX-KVM

Plateforme : Unraid + KVM/QEMU (pc-q35-9.2) + CPU AMD Ryzen + OpenCore v21 + macOS Ventura 13.6 Symptôme : Pas de réseau, interface en0 absente, installateur affiche "An Internet connection is required" TL;DR — Le fixDans le XML de votre VM (mode Avancé dans Unraid), cherchez la section <interface> et assurez-vous que l'adresse PCI est sur bus='0x00' slot='0x08' : <interface type='bridge'> <mac address='52:54:00:xx:xx:xx'/> <source bridge='br0'/> <model type='vmxnet3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </interface>Si votre slot 0x08 est occupé, utilisez un slot libre sur Bus 0 (0x09, 0x0a, etc. — évitez 0x00–0x02, 0x07, 0x1e, 0x1f qui sont réservés). Le problème en détailAprès des heures de debug, j'ai identifié la cause racine via le monitor QEMU (virsh qemu-monitor-command Ventura --hmp "info pci"). Ce qu'on voit avec une mauvaise config (bus='0x01', '0x02', ou derrière un pcie-to-pci-bridge)Bus 2, device 0, function 0: Ethernet controller: PCI device 15ad:07b0 IRQ 0, pin A BAR0: 32 bit memory (not mapped) BAR1: 32 bit memory (not mapped) BAR2: 32 bit memory (not mapped)IRQ 0, tous les BARs "not mapped" = le device PCI existe dans QEMU mais OVMF n'a pas alloué de ressources mémoire. macOS trouve bien le device en scannant le bus PCI, mais le driver (AppleVmxnet3Ethernet) ne peut pas s'initialiser sans adresses MMIO valides. L'interface en0 n'est jamais créée. Ce qu'on voit avec la bonne config (bus='0x00' slot='0x08')Bus 0, device 8, function 0: Ethernet controller: PCI device 15ad:07b0 IRQ 20, pin A BAR0: 32 bit memory at 0x8c647000 [0x8c647fff] BAR1: 32 bit memory at 0x8c646000 [0x8c646fff] BAR2: 32 bit memory at 0x8c642000 [0x8c643fff]IRQ 20, BARs mappées = OVMF a correctement alloué les ressources. macOS charge AppleVmxnet3Ethernet, crée en0, DHCP fonctionne. Pourquoi OVMF ne mappe pas les BARs sur les bus PCIe downstream ?La machine virtuelle Q35 dispose de pcie-root-port (contrôleurs PCIe) qui créent des bus downstream (bus 1, 2, 3...). En théorie, un device vmxnet3 sur bus='0x01' devrait fonctionner. En pratique, avec la version de QEMU/OVMF embarquée dans Unraid actuel, les fenêtres mémoire de ces root ports sont configurées avec des plages invalides : Bus 0, device 1, function 1: (pcie-root-port pci.2) memory range [0xfff00000, 0x000fffff] ← base > limite = vide/désactivé prefetchable memory range [0xfffffffffff00000, 0x000fffff] ← idemRésultat : les devices derrière ces ports n'obtiennent aucune allocation MMIO. Seul le Bus 0 (root complex, géré directement par OVMF) reçoit des allocations correctes pour tous ses périphériques. Ce qui ne fonctionne PAS (et pourquoi)Config tentée Résultat Raison vmxnet3 sur bus='0x01' (pci.1 downstream) BARs not mapped OVMF window vide vmxnet3 sur bus='0x02' (pci.2 downstream) BARs not mapped OVMF window vide pcie-to-pci-bridge + vmxnet3 sur bus='0x08' Device invisible Bridge non configuré par OVMF (secondary bus=0) e1000-82545em à n'importe quel bus Driver absent AppleIntelE1000e retiré de Ventura e1000e (82574L) Driver absent IntelMausi ne supporte pas 0x10D3 IntelMausi.kext injecté via OpenCore Ne match pas Supporte seulement 82577LM (0x10EA+) et plus récents Cas particulier : l'installateur BaseSystemMême avec la bonne topologie PCI, l'installateur Ventura (BaseSystem) n'a pas de driver vmxnet3 : AppleVmxnet3Ethernet est absent de BaseSystemKernelExtensions.kc (uniquement présent dans le System KC complet). Conséquence : le message "An Internet connection is required to install macOS" dans l'installateur BaseSystem est inévitable avec vmxnet3, e1000 ou e1000e — aucun de ces drivers n'est compilé dans le KC de recovery/installation. Contournement : Booter depuis un macOS déjà installé (même ancien), puis faire "Reinstall macOS" depuis la Recovery de ce disque installé, qui charge le KC complet du disque système. Mémo sur AppleVmxnet3Ethernet dans Ventura 13.6Le kext existe dans /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleVmxnet3Ethernet.kext/ Il n'y a pas de binaire sur disque (stub uniquement, Info.plist seul) — c'est normal sous Ventura, le binaire est compilé dans BootKernelExtensions.kc / SystemKernelExtensions.kc MinSystemVersion: 13.6 — le driver est apparu en 13.6, pas avant IOPCIPrimaryMatch: 0x07b015ad = VMware vmxnet3 (vendor 0x15AD, device 0x07B0) OSBundleRequired: Network-Root — prévu pour le boot réseau, mais absent du BaseSystem KC malgré cette flag Config CPU pour AMD Ryzen (critique)Ne pas oublier le -cpu dans qemu:commandline. Le host-passthrough brut plante Ventura sur AMD. Il faut surcharger avec Skylake-Server sans avx2 (CryptexFixup requiert l'absence d'avx2 pour activer son stub non-AVX2) : <qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='************************'/> <qemu:arg value='-smbios'/> <qemu:arg value='type=2'/> <qemu:arg value='-cpu'/> <qemu:arg value='Skylake-Server,vendor=GenuineIntel,+hypervisor,+invtsc,kvm=on,+fma,+avx,+aes,+ssse3,+sse4_2,+popcnt,+sse4a,+bmi1,+bmi2'/> </qemu:commandline>Notez l'absence de +avx2 — intentionnelle. Environnement de testUnraid 6.x / QEMU pc-q35-9.2 CPU hôte : AMD Ryzen 7 OpenCore : KVM-Opencore v21 avec 7 patches kernel (5 AMD cpuid/SurPlus + 2 patches Visual pour non-monotonic time sur AMD) macOS : Ventura 13.6.0 OVMF : OVMF_CODE-pure-efi.fd (version Unraid stock) Espère que ça aide quelqu'un d'autre à éviter plusieurs heures de debug sur ce sujet !

@Rutj87 I used macinabox to create my first vms or get configuration templates to apply on Monterey or Ventura. Then I used the virt-manager docker to cleanly modify my configuration files. Your loop problem inspires me a question: is the disk image bootable? Did you copy an EFI folder from OpenCore to the hidden EFI partition? I use OpenCore Configurator in this step. You could connect this disk in another vm as a second disk and add/edit the EFI folder then reconnect this disk to Ventura. I already shared my confit.plist file yesterday in the EFI.zip archive

@ghost82 I have successfully implemented your Ventura topology on my Big Sur configuration, and I'm pleased to report that everything is functioning smoothly on BigSur, including the GPU passthrough of the USB PCI card with mouse and keyboard integration. 😀 I believe I have now achieved my highest level of hackintosh proficiency, and I am content with using this BigSur vm for the time being. However, I am eager to expand my knowledge of Python programming for future exciting projects. I need to quickly acquire the necessary skills to code in Python. Once again, I sincerely appreciate your assistance and the valuable contributions you make to the community. (Special thanks to ChatGPT for rewriting my poor english

@ghost82 Thanks anyway for your precious help which saved me hours and allowed me to correct my configuration errors. I will continue my research and share the solution here.

@ghost82 Wow! I modified the Ventura .xml in Unraid and replaced the EFI folder in Macos with yours. Now Ventura starts up normally, but the mouse and keyboard connected to the Fresco PCI card still don't work. 😔 Here is the new "report" provided by IORegistryExplorer :2023-02-21-1545_ventura.ioreg and the new diagnosis by Unraid : unraid-diagnostics-20230521-1553.zip

@Rutj87 Sorry, I misunderstood your original request. I followed the instructions available here: https://github.com/kholia/OSX-KVM from this step : « Clone this repository on your QEMU system.… » I stumbled on the image conversion step with dmg2img because I couldn't install it with the unraid terminal. I think I got around the obstacle by converting the image within another BigSur virtual machine. I don't remember that part very well. I adapted the macOS-libvirt-Catalina.xml file to my configuration, placed the various disk images in the indicated directories and found the correct pci topology. but I would have done better to use its automatic installation script ./OpenCore-Boot.sh

@ghost82 Hi, here is my EFI folder : EFI.zip Your comment reminds me that during my attempts to fix the USB on my Ventura, I read a tip on the net and used Kext Wizard to install a kext named USBInjectAll thinking that it would solve my problem. In vain! But now I can't find this kext in my System/Library/Extensions folder 🤔

@Rutj87 Hi, From memory, Monterey always crashed on the Macos boot picker screen right after I clicked on the boot disk icon. I was getting an error message in several languages (white letters on black background). I gave up after hours of trying, succeeded easily with BigSur and Sierra with the AMD graphics card passthrough, then with difficulty with Ventura after I realized that the IOMMU grouping had meanwhile been unchecked, probably after adding the USB PCIe card on the motherboard which had changed the PCI topology. For Ventura, connected in VNC, I applied OpenCore Legacy Patcher I also applied the last Ventura update, and tried other complicated procedures (after duplicating the Ventura disk image of course) that I believe are useless since the problem in my case was the unintentional disabling of IOMMU grouping. I attach my Ventura config.plist just in case: 2023-05-21_ventura.plist Good luck! Translated with DeepL

@ghost82 Hi, I tried your modified qemu config without success : no keyboard & mouse on Ventura I attached the files you asked for : 2023-05-21_Ventura.ioreg & unraid-diagnostics-20230521-1209.zip Thanks again to spend your time on my difficulties.

@Rutj87hi, i have a Ryzen 3700 and the install of Monterey crashes. No problem with BigSur and Ventura.

Thanks I'm not at home right now. I'll continue this conversation tomorrow if you don't mind. Have a good evening

@ghost82 Perhaps this file is more clear :iMac.ioreg