Virtualisierung unter macOS Ventura auf Alder Lake (Intel Core i5 12400F)

    Hallo liebe Community!


    Ich habe ein Problem, welches mir etwas Kopfzerbrechen bereitet. Ich habe mir einen Hackintosh gebastelt mit folgenden Komponenten

    • Motherboard: Gigabyte B760M Gaming X DDR4
    • CPU: Intel Core i5 12400F
    • RAM: 16GB 3200Mzh DDR4
    • GPU: AMD Radeon RX5700
    • PC Case: PowerMac G4 QuickSilver Gehäuse (umgebaut auf mATX)


    Es läuft alles wunderbar und ich habe mich dabei an den OpenCore-Installguide gehalten. Soweit alles super, PCI-Information injected (Kosmetik), USB Mapping usw. erstellt, hardwaremäßig läuft da eigentlich alles sauber.

    Ich stehe nun vor folgendem Problem:
    Ich bin Software- und Appentwickler und habe meine gewöhnlichen IDEs etc. installiert, man kennts ja. Ich habe nun alles eingerichtet: XCode, Android Studio usw, und bin dann auf folgendes Problem gestossen:

    Kein einziges Android-Emulator Device möchte laufen. Ich bekomme immer eine schwarzen Bildschirm und bekomme dann eine Fehlermeldung "300s Time-Out" und dass die Emulation nicht geklappt hat. Des Weiteren verzeichnet der Service qemu-system_x86-64 ganze 300% CPU Auslastung!! Unter xCode funktioniert der iOS Simulator einwandfrei, auch Tools wie Docker etc. funktionieren eigentlich tadellos. Ich nehme an, dass das es hier möglicherweise ein Problem mit der Virtualisierung gibt. Weiß da vielleicht jemand etwas darüber bzw. hat ähnliche Erfahrung gemacht?

    Noch eine kleine Info am Rande: Wenn ich den Emulator mit x86 verwende, funktioniert das ganze einwandfrei, ich kann jedoch keine x86_64 Images nutzen!


    Noch zum Thema BIOS Setup: VT-d ist enabled (für Windows), hab aber auch die entsprechende Flag 'DisableIoMapper' auf 'true' gesetzt.

    Ich würde mich über eine Antwort freuen!

    LG und schönen Abend!

    VT-D kannst du an lassen und DisableIOMapper auch auf false setzen.


    Wenn du eine Reserved Memory Region in der DSDT bzw. ACPI hast müsstest du die dann raus bauen und eine angepasste SSDT DMAR einbinden.


    Damit einhegend hast du dann AppleVTD, vielleicht geht der Kram denn bei dir dann.


    AQUANTIA AQC107 Monterey 12.5.1 läuft nicht


    kurz: DMAR table suchen, anpassen, speichern. Originale Tabelle „droppen“ und angepasste laden.


    VT-D an und DisableIOMapper auf false setzen.


    IORegistry checken ob ein AppleVTD Device da ist…

    Vielen Dank für die schnelle Rückmeldung, ich werde das ganze probieren und dann berichten.


    LG

    Also, kleine Zwischeninformation:

    Ich habe mir Clover auf einen USB geholt um die nativen ACPI-Tables zu droppen und mir die native DMAR.aml zu holen. In dieser DMAR.aml sind folgende Dinge enthalten:


    Allerdings finde ich hier keine Reserved Memory Region. Daher muss ich hier wahrscheinlich nichts löschen bzw. die native Tabelle nicht droppen, oder?

    Soll ich trotzdem DisableIOMapper auf false setzen?


    EDIT:

    Kurzes Update: Habe die SSDT-DMAR.aml so genommen wie sie ist und sie über OC eingebunden und DisableIOMapper auf "false" gesetzt. AppleVTD scheint nun im IORegistryExplorer auf. Das Issue mit dem schwarzen Bildschirm des Android Emulators mit x86_64 Image und der hohen CPU Auslastung ist allerdings immer noch vorhanden.

    Für die vollständige Nutzung von Apple vt-d muss im ACPI ein DMA-Controller (DMAC) aktiviert sein.

    Ich starte mal eben meinen Big Mac.

    Vielen Dank für die schnelle Rückmeldung, ich werde mir das gleich mal anschauen und probieren, DMAC zum Laufen zu bekommen. Eine SSDT-DMAC hab ich bis jetzt noch nicht inkludiert gehabt, daher erscheint das DMAC Device auch nicht im IOReg. Mal sehen, ob sich das Problem dann behebt. :gänsefuss:



    Also: Es hat etwas länger gedauert, mein PowerHack G4 QuickSilver rennt nun mit Sonoma (hat länger gedauert, da die WiFi Patches nicht auf Anhieb funktioniert haben (Stichwort: Reihenfolge der Kexte). Da nun das geht, hab ich mir die SSDT-DMAC geholt und überarbeitet: Hab PCI0 gegen PC00 ausgetauscht, da dies notwendig war.


    AppleVTD:


    DMAC:


    Das Problem ist jedoch weiterhin da, immer noch eine extrem hohe CPU Auslastung von qemu-86_64 und nur ein schwarzer Bildschirm auf dem Android Emulator wenn ich ein x86_64 image verwende. :think:

    Einmal editiert, zuletzt von nullpointerexception ()

    Es scheint so, dass viele Nutzer damit Probleme haben. Auch mit echten Macs.


    https://www.google.com/search?…oid+studio+cpu+high+usage


    Die vorgeschlagenen Lösungen dazu sind mannigfaltig.


    - Herabsetzen der Auflösung

    - Herabsetzen der Monitorfrequenz

    - Abstellen von Audio

    - und, und, und ...


    Du solltest eines im Hinterkopf behalten.

    - Du hast ein System, welches von Apple so nie gebaut wurde.

    - Ein Alderlake wurde von Apple nie verbaut und er ist Mac OS auch bis heute nicht bekannt.

    - Es könnte möglich sein, dass durch das Fake-CPU Inkompatibilitäten entstehen.

    - Kann gut möglich sein, dass Xcode damit umgehen, aber Quemu nicht.


    Fragen über Fragen ...


    Um Gewissheit zu finden, ob es sich bei dir um ein Hardware- oder Softwareproblem handelt, müsste man mal eine Installation auf einem Rechner mit Cometlake testen.

    Ich habe Xcode und Android Studio auf meinem Big Mac laufen.

    Ein Gigabyte GA-Z490-Vision G mit Intel I7-10700K und 64 GB RAM.

    Gibt es da irgendwelche freien Repostories auf GitHub oder Subversion zum Testen?


    Läuft auch nicht besser auf meinem Cometlake:trost:


    Die Auslastung variiert stark.

    Bilder

    Spoiler anzeigen

    Vielen Dank erneut für die schnelle Rückmeldung!


    Das mit der hohen CPU Auslastung wäre mir eigentlich egal, aber dass die x86_64 Images nicht funktionieren ist halt sehr blöd, da ich ansonsten nur x86 Images verwenden kann und da ist die neuste Android Version leider nur Android (11) -> würde gerne meine Apps auch unter Android 14 testen, da ich mit Flutter cross-platform Apps entwickle und die auch gerne unter Android 14 deployen und testen würde. Ich bekomme immer noch den schwarzen Screen wenn ich ein x86_64 Image verwenden will, x86 Images funktionieren, wie bereits erwähnt, einwandfrei.. :think:

    Allerdings habe ich ein anderes Problem welches mich etwas quält. Ich habe nun über 3 verschiedene Arten USB Mapping gemacht:


    - 1x Manuell:

    wie im OpenCore Guide beschrieben (musste SSDT-RHUB einbinden, da ansonsten meine USB 3.0 Devices nicht erkannt wurden beim Mappen).

    SSDT-RHUB in ACPI vorhanden, USB-Map.kext auch vorhanden

    IOReg sieht nun so aus:


    Bluetooth PCIe Karte ist an Port HS07 -> auf "Internal" eingestellt.


    System-Profiler:



    Was ich besonders interessant fand, ist, dass scheinbar 4 Ports auf der Rückseite vom PC über einen USB Hub auf meinem Motherboard miteinander verknüpft sind. Immer wenn ich an einen dieser 4 Ports ein Device anhänge, wird es an den gleichen Port "HS05" gebunden und unter den einzelnen AppleUSB20HubPort dann aufgelistet.

    Meine Frage: Muss ich da auch irgendwas individuell mappen oder passt das so?


    Ebenfalls hab ich dieses komische "ITE Device" auf "Internal" gemappt, da dies sicher intern auf dem Motherboard ist (ich habe sonst keine Devices via USB 2.0 (Ausnahme Bluetooth USB Header für BT/WiFi PCIe Karte) oder USB 3.0 Header auf dem Motherboard verbunden, ich verwende nur die Rear IO USB Ports und den einen USB Header am Motherboard für die WiFi/Bluetooth PCI Karte.

    - Über USBToolbox:

    Ich habe mir auch einen USBMap.kext über USB Toolbox erstellen lassen, auch hier funktionieren alle Ports und ich hab auch die Internal Ports definiert.

    Jedoch zum eigentlichen Problem:
    Mein Hackintosh hat eines der bekannten Sleep-Probleme: Wenn ich ihn in den Sleep schicke, wacht er sofort auf. Ich konnte das ganze Problem mit der SSDT-GPRW.aml beheben, jedoch geht dann der Wake über USB nicht (was eh klar ist, da diese .aml den USB disabled). Ich kann ihn eigentlich nur über den Power-Button aufwachen lassen. Ich konnte auch das Problem finden: Wenn ich den USB-Header von der WiFi/USB PCIe Karte abziehe, funktioniert Sleep einwandfrei. Daher ist eben meine Vermutung, dass ich doch möglicherweise irgendein Problem mit dem USB Mapping habe. Ich kann aber nicht sagen, was das Problem ist, da die Ports, welche nicht in am Rear-IO sind, eigentlich auf "Internal" gemappt sind. Meine Vermutung ist, dass das der Bluetooth USB Host Controller nicht direkt an den Port gebunden ist sondern dieser USB 2.0 Hub dazwischen hängt, aber das ist nur eine vage Vermutung....

    Weiß jemand möglicherweise was ich hier falsch gemacht habe?

    LG

    2 Mal editiert, zuletzt von nullpointerexception ()