Virtualized Hackintosh with Intel GVT-g ?

[scorpion81]

Hello, 

I am struggeling with this topic for a few weeks now.

Background Info:

1. I have successfully installed a mac OS Virtual Machine with Docker-OSX. (https://github.com/sickcodes/Docker-OSX). After the installation process I extracted the harddisk images from docker and run them directly on my host.
2. I have been successfully been able to pass through the USB Controller and the WIFI chip (both on pci level) and with the help of AirportItlwm.kext the wifi chip is functional.
   Why this is important ? It allows you to attach your IPhone via USB (once) and then use it via WIFI connection as Xcode target device.
3. I also have been able to passthru the audio controller (due to stupidly laid out iommu groups i had to pass through the whole group, 4 different controllers) and with layout id = 71 for Acer laptops that worked too.
4. Now... the great prize. Hardware-accelerated Graphics in the VM with the help of Intel GVT-g
   That is the challenge what i have been trying to solve.
   With the help of this great piece of software (https://github.com/patmagauran/i915ovmfPkg) i915ovmfPkg I have been able to workaround some qemu shenanigans to pass thru the device to the guest os.
   And the guest even boots with only this iGPU attached and shows output.
   But. Internally some default framebuffer seems to be chosen, and no hardware acceleration is available.

 

So I came to the thought... what would happen if I apply some hackintosh procedures to a virtual machine ???
First i have been trying with Whatevergreen alone. Was attempting to use device-id A53E0000 for whiskey lake and alternatively 16590000 for kaby lake 
Additionally i did specify AAPL,ig-platform-id with 0000A53E and 00001659 respectively. That was the correct bit inversion, right ?
This led to force wake up errors like a panic being thrown by Whatevergreen or later on, with the use of the aforementioned rom file, the boot process being stuck because no framebuffer will be accessible, but the driver tried to initialize
itself for about 5 minutes.
Qemu threw a few error lines then, so did dmesg on the linux host (some intel gvt stuff, all the details about my attempts so far can be read here https://github.com/acidanthera/bugtracker/issues/1914 (for reference))
My last attempt so far involved igfxfw=2 and igfxpavp=1 in order to load the Apple firmware. But here i am stuck now with IMEI issues. Aka since this is a virtual machine, there is no IMEI at hand, but the apple driver needs one to "Wake it up"
So i have been trying to create a fake one via config.plist, SSDT_IMEI.dsl and some device-id. But for some reason no IMEI device is being created.
Please see also the attached boot log. Thanks in advance

I would appreciate every hint or suggestion what else i could try in order to solve this puzzling problem.

boot_log.txt

Edited January 9, 2022 by scorpion81
forgot to mention that I work outside docker

[scorpion81]

Thanks for the hint  I just tried it, but the problem unfortunately still persists:
 

[IGFB][INFO   ] accelWillLoadGuC: initializing...
[IGPU] Unsupported AuxiliaryID. Firmware may not load!
[IGPU] Unsupported AuxiliaryID. Firmware may not load!
[IGPU] Begin Gfx firmware load process
[IGPU] Begin Gfx firmware load process
[IGPU]    ForceWake Multithread = 0x20002
[IGPU]    ForceWake Multithread = 0x20002
[IGPU]    CONFIG0 (0xD00)       = 0x80000000
[IGPU]    CONFIG0 (0xD00)       = 0x80000000
[IGPU]    GT_THREAD_STATUS      = 0x0
[IGPU]    GT_THREAD_STATUS      = 0x0
[IGPU]    Doing retry #0
[IGPU]    Doing retry #0
[IGPU] Failed to wake the ME.
[IGPU] Failed to wake the ME.

and some lines before it:

 

[IGFB][ERROR  ] ME PCI ACPI device not found - PAVP services will be disabled - add IMEI to EFI / ACPI device list
[IGFB][ERROR  ] Failed to create MEI service
GTrace synchronization point 3
[AGPM][INFO ][CONTROLLGTEraRce   sy][cncrhreonizateaAGPtion point M4
Class         ] macGhTines_dict->greace synchrontObject(modelName iMacPro1,1)
[AGPM]i[zation point 5
INFO ][CONTROLLER  ][createAGPMClass         ] machines_dict->getObject(modelName iMacPro1,1)
[AGPM][INFO ][CONTROLLER  ][createAGPMClass         ] machines_dict->getObject(modelName iMacPro1,1)
[AGPM][INFO ][CONTROLLER  ][createAGPMClass         ] gpuDict IGPU
[AGPM][INFO ][CONTROLLER  ][createAGPMClass         ] gpuDict IGPU
[AGPM][INFO ][CONTROLLER  ][createAGPMClass         ] build gpuDict by GPU IGPU.
[AGPM][INFO ][CONTROLLER  ][createAGPMClass         ] gpuDict IGPU
[AGPM][WARN ][CONTROLLER  ][createAGPMClass         ] GPU = IGPU unknownPlatform (no matching vendor_id+device_id or GPU name); don't create AGPM class
[AGPM][INFO ][CONTROLLER  ][createAGPMClass         ] build gpuDict by GPU IGPU.
[AGPM][INFO ][CONTROLLER  ][start                   ] fIsExternalGPU 0
[AGPM][INFO ][CONTROLLER  ][createAGPMClass         ] build gpuDict by GPU IGPU.
[AGPM][WARN ][CONTROLLER  ][createAGPMClass         ] GPU = IGPU unknownPlatform (no matching vendor_id+device_id or GPU name); don't create AGPM class

I wonder where i can get such a fake IMEI device from.... hmmm. Do not ask why iMacPro1,1 lol... it was just a working default from docker-osx

[scorpion81]

Could I make a fake IMEI device this way ?
Found that in the acidanthera github repos...
 

/*
 * Only necessary when no IMEI device (with any name) is present in the DSDT and a custom device-id
 * is needed to be set via DeviceProperties (some Sandy Bridge or Ivy Bridge configurations).
 */
DefinitionBlock ("", "SSDT", 2, "ACDT", "IMEI", 0x00000000)
{
    External (_SB_.PCI0, DeviceObj)

    Scope (_SB.PCI0)
    {
        Device (IMEI)
        {
            Name (_ADR, 0x00160000)  // _ADR: Address
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (_OSI ("Darwin"))
                {
                    Return (0x0F)
                }
                Else
                {
                    Return (Zero)
                }
            }
        }
    }
}

I saved it as SSDT_IMEI.dsl and compiled it with iasl to SSDT_IMEI.aml. Then I added an entry in config.plist under ACPI -> Add -> with Path SSDT_IMEI.aml and Enabled true. Furthermore there is an entry under DeviceProperties. See also the plist config so far (screenshot with the relevant parts expanded)


But when i boot to mac OS with my working backup config, then there is no IMEI device... is that not the correct route to follow ?

[scorpion81]

Update: hmm the IMEI device showed up now, i had some typo in the filename. But that made no difference. I also have been trying with the UHD 630 Framebuffer and Driver, which is closest to the UHD 620, but it is different still.

And i removed the igfxfw=2 start parameter again. But even then it fails to create a usable framebuffer, being stuck before the macOS handover.
I even started looking into Intel's programming references and the linux i915 driver documentation. I still cannot figure out what exactly goes wrong according to the qemu error messages, the dmesg messages and the bootlog messages, unfortunately.
I assume it must be related to wake up the GPU via pci commands or so in the first instance. I really really would appreciate it if the whatevergreen devs may take a look at the boot logs and other error messages too
Maybe it can be solved with some custom patching, but i really am afraid one would need to code a custom uhd 620 compatible (opensource) driver for mac os... but here my knowledge definitely ends  

 

Edit: Now that looks definitively interesting (igfxfw=1 and the rom loaded)

Happens when serial output is redirected to stdio. Thank god I was helped to find out how that works
 

[IGPU] Ring Size: 32 KB
[IGPU] Ring Size: 32 KB
[IGPU] Graphics Scheduler Preemption Enabled!
[IGPU] Graphics Scheduler Preemption Enabled!
[IGPU] Setting preemptionDelayIntervalUS to 400 microseconds
[IGPU] Setting preemptionDelayIntervalUS to 400 microseconds
[IGPU] Setting preemptionTimerIntervalUS to 2000 microseconds
[IGPU] Setting preemptionTimerIntervalUS to 2000 microseconds
[IGPU] Will NOT fallback to host-side scheduling if graphics firmware fails to load
[IGPU] Will NOT fallback to host-side scheduling if graphics firmware fails to load
[IGPU] Scheduler Tail Coalescing Enabled.
[IGPU] Scheduler Tail Coalescing Enabled.
[IGPU] Scheduler Page Fault Handling Enabled.
[IGPU] Scheduler Page Fault Handling Enabled.
[IGPU] Scheduler Single Channel Index Disabled
[IGPU] Scheduler Single Channel Index Disabled
[IGPU] Scheduler Channel Wait For Complete Disabled
[IGPU] Scheduler Channel Wait For Complete Disabled
[IGPU] Scheduler: Process CSB using HWS.
[IGPU] Scheduler: Process CSB using HWS.
[IGPU] Scheduler: PM notify enabled
[IGPU] Scheduler: PM notify enabled
[IGPU] Forced to use Reference Firmware Scheduler
[IGPU] Forced to use Reference Firmware Scheduler
[IGPU] [RefFirmware] Forcing SingleChannelIndex=1
[IGPU] [RefFirmware] Forcing SingleChannelIndex=1
qemu-system-x86_64: vfio_pci_write_config(9085644c-8cf8-4df0-900e-0c1362deddea, 0x4, 0x100407, 0x4) failed: Ung?ltige Adresse
qemu-system-x86_64: vfio_pci_write_config(9085644c-8cf8-4df0-900e-0c1362deddea, 0x4, 0x100407, 0x4) failed: Ung?ltige Adresse
[IGPU] Graphics Address: PPGTT, Separate Address Space
[IGPU] Graphics Address: PPGTT, Separate Address Space
[IGPU] MultiForceWake Enabled: Using 3D Driver
[IGPU] MultiForceWake Enabled: Using 3D Driver
[IGPU] Render Compression Enabled.
[IGPU] Render Compression Enabled.
[IGPU] Render Compression for IOSurface is Enabled.
[IGPU] Render Compression for IOSurface is Enabled.
qemu-system-x86_64: vfio_region_write(9085644c-8cf8-4df0-900e-0c1362deddea:region0+0x2080, 0x402a4000,4) failed: Ung?ltige Adresse
qemu-system-x86_64: vfio_region_write(9085644c-8cf8-4df0-900e-0c1362deddea:region0+0x12080, 0x402a5000,4) failed: Ung?ltige Adresse
qemu-system-x86_64: vfio_region_write(9085644c-8cf8-4df0-900e-0c1362deddea:region0+0x22080, 0x402a6000,4) failed: Ung?ltige Adresse
qemu-system-x86_64: vfio_region_write(9085644c-8cf8-4df0-900e-0c1362deddea:region0+0x1a080, 0x402a7000,4) failed: Ung?ltige Adresse

Looks like those IGPU calls trigger the according errors !
Graphics Address, MultiForceWake, Render Compression and RenderCompression for IOSurface... those seem to result in faulty responses of the host gvt driver.

Seems also Forcing the Scheduler triggers the vfio_pci_write errors.... hmmmmmmm.... now lets consult the Intel manuals what this could mean in code / addresses notation.

Edited January 10, 2022 by scorpion81
interesting coincidence ?

[scorpion81]

Hello, some more investigation results:

If you just use the vbios_gvt_uefi.rom, the boot process will crash when trying to force wake the GPU (according to the apple crash log) and at the same time dmesg will report that GVT-g is not supported (because the GVT-g magic is not at register 0x78000 aka PV_INFO)

The latter is being set up by i915ovmfPkg. BUT... there is still something missing. I assume some base address still is mislocated. For exampe the vfio_pci_write_config error at offset 0x4, with count 0x4 is being interpreted as a write access to the PCI Command register. But if that really was such an access the count must be maximal 2. So i think it is a memory access. But the value (0x100407) Indeed is being found already in the PCI Command register. I assume since it tries to WRITE it again, it must have been read before somewhere and being misinterpreted as some value from a memory access. I wonder what the apple driver attempted there. Perhaps the mapping from virtual gpu to host gpu mmio base / memory ballooning etc is all not yet set up correctly by i915ovmfPkg.

The vfio_region writes try to access the Ring buffer base registers, but they again hit some nonpriv / non whitelisted ones. I assume because some MMIO base is still incorrect, since 24d8, 24dc are offsets only. The ring is the RCS0 one. And there is more with the mm type, guest context LRCA and such (I am still investigating how this is supposed to work) 

I mean if you do not fake the device-id with your UHD 620 being a kaby lake GPU aka A53E0000, the apple driver stays inactive and your vm will boot successfully. But you dont get hardware acceleration then. If you fake it, the Apple driver initializes but struggles with an "unexpected" virtual gpu setup i guess. So there is some layer missing which makes the apple driver believe everything is OK, we have a physical GPU here while in truth this is a virtual one. (with some address remapping)

[kocoman]

Any updates/progress?