OVMF / UEFI support?

[DocMAX]

When will it come for VT-d? What are the problems at the moment? What has to be modified? Will this ever work? Thanks.

[TerrenceXu]

GVT-d also support OVMT / UEFI VM, thanks. ☺ From: DocMAX [mailto:notifications@github.com] Sent: Friday, March 23, 2018 6:46 AM To: intel/gvt-linux <gvt-linux@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: [intel/gvt-linux] OVMF / UEFI support? (#23) When will it come for VT-d? What are the problems at the moment? What has to be modified? Will this ever work? Thanks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#23>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AYv0NMJHPuC4NBahfXZUuetYY3qx_UIsks5thCmrgaJpZM4S36PI>.

[jscinoz]

Is support for OVMF + GVT on the roadmap? At present it does not appear to work with either a Q35 or I440FX VM using OVMF (SeaBIOS does work, with both machine types)

[DocMAX]

any news?

[TerrenceXu]

Do you means GVT-g? GVT-g has support OVMF for a long time.

[DocMAX]

the classic gvt-d.... (non virtual gpu). doesnt work with ovmf... screen stays black. seabios works.

can somebody confirm that intel gpu passthrough is working with OVMF UEFI bios???

[DocMAX]

Any updates please?

[hyuan3]

Display doesn't work with OVMF bios. It's because display needs OpRegion which is not available to guest in OVMF bios scenario. Please use seabios or UPT mode.

[CuriousTommy]

Apparently it is possible to use the display on OVMF. Going from what this user has said, you can do the following:

• Patch the kernel
• Patch OVMF
• Extract the rom from vgpu_rom.c and apply it as a QEMU rom file.

Disclaimer: I haven't tested this.

[DocMAX]

thanks. works with gvt-g but not with gvt-d.

[CuriousTommy]

@DocMAX Did you only need the gvt_uefi.rom or did you also have to patch the OVMF file?

Also were you also able to see the OVMF screen on boot up, or did the screen only initialize after booting into the OS?

[DocMAX]

just the rom is enough. you only see a picture AFTER the guest operating system has initialized the display with the driver.

so this works for gvt-g:
-device vfio-pci,sysfsdev=/sys/bus/pci/devices/0000\:00\:02.0/59c57b6c-13ee-4055-846e-e4d3dc55d389,romfile=/opt/vm/bios/vbios/vbios_gvt_uefi.rom,display=on,x-igd-opregion=on

but this (gvt-d) is NOT working (black screen)
-device vfio-pci,host=$IOMMU_GPU,romfile=/opt/vm/bios/vbios/vbios_gvt_uefi.rom

special paramaters like x-vga=on dont work either.

[HouQiming]

@DocMAX Can you try GVT-d with a patched OVMF (attached) with neither romfile=foo or rombar=0 on the vfio-pci device? My gut feeling is that GVT-d needs both the OpRegion patch and the original VBIOS. So it won't do to apply the OpRegion patch as a rom file or a kernel patch.

ovmf.zip

[DocMAX]

thank you, but the patched ovmf doesn't work :-(. i'm on a thinkpad x1 carbon 2015 with broadwell cpu by the way.

[TerrenceXu]

@DocMAX, Canyou share your whole boot up GVT-d VM command?

[DocMAX]

Sure, here are my full lines including kernel parameters:

intel_iommu=on iommu=pt

IOMMU_GPU="0000:00:02.0"
IOMMU_GPU_AUDIO="0000:00:1b.0"

vfiobind() {
    modprobe vfio-pci
    for dev in $IOMMU_GPU $IOMMU_GPU_AUDIO; do
        vendor=$(cat /sys/bus/pci/devices/$dev/vendor)
        device=$(cat /sys/bus/pci/devices/$dev/device)
        if [ -e /sys/bus/pci/devices/$dev/driver ]; then
            echo $dev > /sys/bus/pci/devices/$dev/driver/unbind
        fi
        echo $vendor $device > /sys/bus/pci/drivers/vfio-pci/new_id
    done
}

vfiobind

qemu-system-x86_64
-nodefaults -display none -vga none -parallel none -serial none
-monitor unix:/run/qemu/win-monitor.sock,server,nowait
-cpu host,kvm=off,hv_vendor_id=nvidia43fix -smp $(nproc),sockets=1,cores=4,threads=1 -enable-kvm
-drive file=/opt/vm/qcow2/win.qcow2,if=virtio
-netdev bridge,br=br0,id=net0 -device virtio-net-pci,netdev=net0,mac=52:54:00:00:00:10
-m 4G
-drive if=pflash,format=raw,readonly,file=/opt/vm/bios/ovmf-patched/ovmf.fd
-device vfio-pci,host=$IOMMU_GPU
-device ich9-intel-hda -device hda-duplex
-object input-linux,id=kbd1,evdev=/dev/input/by-path/platform-i8042-serio-0-event-kbd,grab_all=on,repeat=on
-object input-linux,id=mouse1,evdev=/dev/input/by-path/platform-i8042-serio-1-event-mouse

[DocMAX]

OK, so can at least somebody confirm that GVT-d is not yet working with OVMF Bios? Even with the patches?

[elmeyer]

@HouQiming thanks for posting this file; I've made some success with it and a freshly built qemu from git-master using -device vfio-pci-nohotplug,display=on,ramfb=on,...
Can you share exactly which patches were applied to build the file you uploaded?

[HouQiming]

I built it with the opregion patch at: https://bugzilla.tianocore.org/attachment.cgi?id=168 Did you make success using GVT-d or GVT-g? My own attempt at GVT-d also failed like DocMAX.

…

On Mon, Mar 18, 2019 at 6:01 PM Lars Meyer ***@***.***> wrote: @HouQiming <https://github.com/HouQiming> thanks for posting this file; I've made some success with it and a freshly built qemu from git-master using -device vfio-pci-nohotplug,display=on,ramfb=on,... Can you share exactly which patches were applied to build the file you uploaded? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHrIF_ggWeoRRkRhr6KfpC3IuAjqD5hlks5vX2PhgaJpZM4S36PI> .

[elmeyer]

I'm using GVT-g. Is the kernel patch you posted mainlined in any version yet? Did you make no modifications to edk2/OVMF itself?

…

I built it with the opregion patch at: https://bugzilla.tianocore.org/attachment.cgi?id=168 Did you make success using GVT-d or GVT-g? My own attempt at GVT-d also failed like DocMAX. On Mon, Mar 18, 2019 at 6:01 PM Lars Meyer ***@***.***> wrote: > @HouQiming <https://github.com/HouQiming> thanks for posting this file; > I've made some success with it and a freshly built qemu from git-master > using -device vfio-pci-nohotplug,display=on,ramfb=on,... > Can you share exactly which patches were applied to build the file you > uploaded? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#23 (comment)>, or > mute > the thread > <https://github.com/notifications/unsubscribe-auth/AHrIF_ggWeoRRkRhr6KfpC3IuAjqD5hlks5vX2PhgaJpZM4S36PI> > . > -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #23 (comment)

[DocMAX]

with ramfb=on and gvt-g i get seg fault after os switches to its driver

[HouQiming]

@elmeyer the kernel patch is never mainlined. It's more of a temporary debugging patch. The kernel patch, the OVMF patch, and the VBIOS file posted on reddit are all equivalent. You can patch it in any of the three places. In the end I decided to do it in OVMF.

@DocMAX The seg fault you mention is a QEMU bug I fixed a while ago. You can check my fork at https://github.com/HouQiming/qemu/

Edit: for the sake of completeness - I also uploaded my patched OVMF to https://github.com/HouQiming/edk2

[DocMAX]

HouQiming: OK, but i think i will stay with the release from the arch repo. I think it's not worth the effort just to see the boot screen. Hoping the patch will come to mainstream.

[ddscentral]

I can also confirm GVT-d works with ROM file and stock (unpatched) OVMF UEFI. CPU is an i5-8400. Host is Ubuntu 18.04 with a stock 5.0 kernel.
Physical display only works with machine set to i440fx (aka. pc). Q35 machine does not work. Display only works for guest OS, not UEFI.
To avoid losing over 4 GB of RAM in Windows due to GMS, you will also need to add x-igd-gms setting to your iGPU's vfio-pci entry.

[EvanBenechoutsos]

@TheCatFelix what laptop is this? I am working to get proper passthrough on a Dell 5530 with a p2000. EDIT : Would you share your xml?
I have installed correctly drivers (no 43 anymore) for both p2000 and the 630 (dell supplied drivers) but when I try to open NVidia Control Panel im faced with "You are not currently using a display attached to an NVDIA GPU".
Because of that, I dont think that my Quadro is utilized at all by windows (Poor Unigine Superposition performance and I dont get real view graphics under Solidworks)

Have you got yours to work correctly?

[Simbaclaws]

Could someone create an example qemu script that would start such a GVT-g setup? I've created a script that looks like the following but gives me a black screen when starting up.

#!/bin/sh

# Enable basic sound output via pulseaudio
# Run "pacmd list-sinks | grep -e 'name:' -e 'index'" to find your QEMU_PA_SINK
export QEMU_AUDIO_DRV=pa
export QEMU_PA_SINK=alsa_output.pci-0000_00_1f.3.analog-stereo
export QEMU_PA_SOURCE=input

# Start QEMU
qemu-system-x86_64 \
    -enable-kvm \
    -pflash /home/simbaclaws/virtual-machines/bios.bin \
    -m 8G \
    -smp 6 \
    -cpu host,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \
    -machine type=q35,accel=kvm,kernel_irqchip=on \
    -global PIIX4_PM.disable_s3=1 \
    -global PIIX4_PM.disable_s4=1 \
    -name windows-10 \
    -soundhw hda \
    -audiodev pa,id=pa1,server=/run/user/1000/pulse/native \
    -usb \
    -device usb-tablet \
    -display gtk,gl=on \
    -device vfio-pci,sysfsdev=/sys/devices/pci0000:00/0000:00:02.0/4c376b9b-d1e9-46d9-aa56-97832abb98e8,x-igd-opregion=on,display=on,romfile=/home/simbaclaws/virtual-machines/vbios_gvt_uefi.rom \
    -drive file=/dev/disk/by-id/ata-WDC_WDS500G2B0B-00YS70_1837BA802845,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native \
    -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0 \
    -vga qxl \
    -nic none \

I haven't added the rom file cause I didn't know where to download it. Could someone send me a link? Where do I get vbios_gvt_uefi.rom from?

EDIT: Nevermind I found the file in the Arch wiki, however it's still displaying a black screen for me.

I think that might be my only thing standing in my way right now.

bios.bin is a copy from OVMF.fd
I passthrough a GVT-g gpu and a physical SSD

[HouQiming]

Try ramfb=on in your vfio-pci line so that you have display during boot. That way can tell when Windows decides to spend 5 minutes installing the driver, or when it's unhappy with your last failed VM boot and decides to chkdsk, or when you're stuck in the UEFI boot menu.

[Simbaclaws]

Thanks @HouQiming. however it seems I'm not getting any display when using ramfb either. Only when I remove my vgpu and remove the gl=on line in the gtk display will it display something on the screen. I'm currently also getting inaccessible boot device blue screen on windows. I'm currently making a backup to see if I can fix my blue screen issue.

If I have my windows vm working again I'll try to diagnose why I'm getting a black display with my vgpu on opengl.

Once I have a working configuration I'll post my qemu script.

[HouQiming]

Shameless advertisement: I made an improved "magic rom" that also provides a boot display without ramfb. Try it at:

https://github.com/HouQiming/i915ovmfPkg/releases/tag/v0.1

It's potentially dangerous on VT-d, but it should be pretty safe on GVT-g.

[tachang]

I managed to get this half working. Well top half anyway:

Maybe I forgot something but I am running this inside Proxmox. I am able to control the mouse and keyboard using the attached screen but it is black. Kind of interesting.

/usr/bin/kvm -id 104 -name magicrom -chardev socket,id=qmp,path=/var/run/qemu-server/104.qmp,server,nowait -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/104.pid -daemonize -smbios type=1,uuid=22fcca76-ede5-4fba-a9b0-8cfe5a388a99 -drive if=pflash,unit=0,format=raw,readonly,file=/usr/share/pve-edk2-firmware//OVMF_CODE.fd -drive if=pflash,unit=1,format=raw,id=drive-efidisk0,size=131072,file=/dev/pve/vm-104-disk-1 -smp 4,sockets=1,cores=4,maxcpus=4 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg -vnc unix:/var/run/qemu-server/104.vnc,password -cpu Penryn,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,vendor=GenuineIntel -m 5024 -readconfig /usr/share/qemu-server/pve-q35-4.0.cfg -device vmgenid,guid=7166b29a-cd15-4368-b750-6a2439cce443 -device usb-tablet,id=tablet,bus=ehci.0,port=1 -device vmware-svga,id=vga,bus=pcie.0,addr=0x1 -iscsi initiator-name=iqn.1993-08.org.debian:01:4f15f9461236 -drive file=/var/lib/vz/template/iso/Catalina-installer.iso,if=none,id=drive-ide0,cache=unsafe,format=raw,aio=threads,detect-zeroes=on -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0 -drive file=/var/lib/vz/template/iso/OpenCoreOVMF.iso,if=none,id=drive-ide2,cache=unsafe,format=raw,aio=threads,detect-zeroes=on -device ide-hd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=101 -device ahci,id=ahci0,multifunction=on,bus=pci.0,addr=0x7 -drive file=/dev/pve/vm-104-disk-0,if=none,id=drive-sata0,cache=unsafe,format=raw,aio=threads,detect-zeroes=on -device ide-hd,bus=ahci0.0,drive=drive-sata0,id=sata0,rotation_rate=1 -netdev type=tap,id=net0,ifname=tap104i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown -device vmxnet3,mac=1E:3C:65:C5:38:69,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300 -machine type=q35+pve0 -device vfio-pci,host=0000:00:02.0,id=hostpci0,bus=pci.0,addr=0x10,x-igd-opregion=on,romfile=/usr/share/kvm/i915ovmf.rom -device usb-kbd,bus=ehci.0,port=2 -device isa-applesmc,osk=REDACTED -smbios type=2 -cpu host,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+hypervisor,+invtsc

[HouQiming]

Looks amazing! It seems like the MacOS installer is utilizing some UEFI feature I didn't implement (most likely a higher default resolution requirement than Windows). This should be relatively easy to fix. Can you add a serial port "-serial file:foo.log" and post the resulting log? Also, what's the resolution of your monitor?

…

On Sat, Jul 4, 2020 at 7:17 AM Jeff Tchang ***@***.***> wrote: I managed to get this half working. Well top half anyway: [image: 20200703_161204] <https://user-images.githubusercontent.com/85011/86500778-63ed1c00-bd48-11ea-9265-49ac4790e7c2.jpg> Maybe I forgot something but I am running this inside Proxmox. I am able to control the mouse and keyboard using the attached screen but it is black. Kind of interesting. /usr/bin/kvm -id 104 -name magicrom -chardev socket,id=qmp,path=/var/run/qemu-server/104.qmp,server,nowait -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/104.pid -daemonize -smbios type=1,uuid=22fcca76-ede5-4fba-a9b0-8cfe5a388a99 -drive if=pflash,unit=0,format=raw,readonly,file=/usr/share/pve-edk2-firmware//OVMF_CODE.fd -drive if=pflash,unit=1,format=raw,id=drive-efidisk0,size=131072,file=/dev/pve/vm-104-disk-1 -smp 4,sockets=1,cores=4,maxcpus=4 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg -vnc unix:/var/run/qemu-server/104.vnc,password -cpu Penryn,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,vendor=GenuineIntel -m 5024 -readconfig /usr/share/qemu-server/pve-q35-4.0.cfg -device vmgenid,guid=7166b29a-cd15-4368-b750-6a2439cce443 -device usb-tablet,id=tablet,bus=ehci.0,port=1 -device vmware-svga,id=vga,bus=pcie.0,addr=0x1 -iscsi initiator-name=iqn.1993-08.org.debian:01:4f15f9461236 -drive file=/var/lib/vz/template/iso/Catalina-installer.iso,if=none,id=drive-ide0,cache=unsafe,format=raw,aio=threads,detect-zeroes=on -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0 -drive file=/var/lib/vz/template/iso/OpenCoreOVMF.iso,if=none,id=drive-ide2,cache=unsafe,format=raw,aio=threads,detect-zeroes=on -device ide-hd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=101 -device ahci,id=ahci0,multifunction=on,bus=pci.0,addr=0x7 -drive file=/dev/pve/vm-104-disk-0,if=none,id=drive-sata0,cache=unsafe,format=raw,aio=threads,detect-zeroes=on -device ide-hd,bus=ahci0.0,drive=drive-sata0,id=sata0,rotation_rate=1 -netdev type=tap,id=net0,ifname=tap104i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown -device vmxnet3,mac=1E:3C:65:C5:38:69,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300 -machine type=q35+pve0 -device vfio-pci,host=0000:00:02.0,id=hostpci0,bus=pci.0,addr=0x10,x-igd-opregion=on,romfile=/usr/share/kvm/i915ovmf.rom -device usb-kbd,bus=ehci.0,port=2 -device isa-applesmc,osk=REDACTED -smbios type=2 -cpu host,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+hypervisor,+invtsc — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5MQFYQZGT65MYEUR25E6DRZZRKFANCNFSM4EW7UPEA> .

[tachang]

@HouQiming Thanks! I actually got it all working. OVMF, Q35 (pc-q35-5.0) on Proxmox 6.2-6.

One thing slightly weird is that after a fresh boot of the host I can start the mac os VM. After I shut down the guest and try to start it again my entire host system freezes. Only thing I can do is unplug power and restart the whole host.

I think this has to be some sort of memory corruption. If I start another VM (I have a Win10) one with legacy passthrough and then go back to the magicrom you wrote it works fine.

If you have any thoughts on how I can provide better debug output would love to hear it.

Thank you so much for writing this.

[zaptrem]

@HouQiming Thanks! I actually got it all working. OVMF, Q35 (pc-q35-5.0) on Proxmox 6.2-6.

One thing slightly weird is that after a fresh boot of the host I can start the mac os VM. After I shut down the guest and try to start it again my entire host system freezes. Only thing I can do is unplug power and restart the whole host.

I think this has to be some sort of memory corruption. If I start another VM (I have a Win10) one with legacy passthrough and then go back to the magicrom you wrote it works fine.

If you have any thoughts on how I can provide better debug output would love to hear it.

Thank you so much for writing this.

@tachang
Would you mind explaining exactly what you did to get iGPU passthrough working on MacOS with q35/OVMF? Which ROMs/OMVF/etc files did you use? Did you use certain kexts? It seems like you are one of a few who have ever succeeded in this.

Thanks!

[zaptrem]

@tachang @HouQiming I used Hou's ROM file and tachang's qemu arg for the iGPU to boot Windows. It worked once (without HDMI output, though). When I restarted my PC vfio-pci stopped binding to the iGPU. In fact, nothing is binding to the iGPU (as I blacklisted all the drivers/framebuffers that could). Could this have been the ROM? Is there something I can do do diagnose this?

[HouQiming]

You can check your dmesg to see what happened. But since you mentioned you have Comet Lake in another thread, it would be a really bad idea to use my ROM with direct passthrough! I had all register addresses hard-coded to Skylake values and there's no telling what they will do to your hardware! Be safe and use the "original" opregion ROM. I'm hosting it here: http://120.25.59.132:3000/vbios_gvt_uefi.rom If it's screwed up badly (unblacklist i915 and it still doesn't load), going through a native Windows installation could hopefully fix it (by reflashing GPU firmware). You can discard the installed Windows without registering. If Windows doesn't work, you can try reflashing your BIOS (downgrade or upgrade it).

…

On Tue, Oct 6, 2020 at 2:31 PM zaptrem ***@***.***> wrote: @tachang <https://github.com/tachang> @HouQiming <https://github.com/HouQiming> I used Hou's ROM file and tachang's qemu arg for the iGPU to boot Windows. It worked once (without HDMI output, though). When I restarted my PC vfio-pci stopped binding to the iGPU. In fact, nothing is binding to the iGPU (as I blacklisted all the drivers/framebuffers that could). Could this have been the ROM? Is there something I can do do diagnose this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5MQF3OTGFDQFM5SW3VBNLSJK2ULANCNFSM4EW7UPEA> .

[zaptrem]

@HouQiming I figured out it was a weird Proxmox issue and got the GPU to bind again. I’ve been using your ROM for a few days (until you sent the above message). It Code-43s on Windows guests and seems to kinda-sorta work on MacOS (HDMI/DP outputs doesn’t work, hardware acceleration seems to work very slowly). How is “the original” different? It seems to do the same thing.

[zaptrem]

@HouQiming Using the “original” doesn’t seem to boot at all with MacOS, but that could be a driver issue ¯_(ツ)_/¯. I’ll stick with the fork of yours until a little more progress is made in this area.

[HouQiming]

The only difference between my rom and the original is an unaccelerated UEFI GOP framebuffer, which is usually used for boot display, and fallback display when the graphics driver fails to load. Your symptoms seem to indicate that your OS graphics drivers (both Windows and Mac) are not working, and the OS is displaying with the GOP framebuffer as a fallback. Maybe some more work is needed from the Mac side to get the OS driver working. With a fallback display, it could be easier now.

…

On Mon, Oct 12, 2020 at 7:25 AM zaptrem ***@***.***> wrote: @HouQiming <https://github.com/HouQiming> Using the “original” doesn’t seem to boot at all with MacOS, but that could be a driver issue ¯_(ツ)_/¯. I’ll stick with the fork of yours for now. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5MQF662D7LXPXBMUZOLTLSKI5GTANCNFSM4EW7UPEA> .

[zaptrem]

@HouQiming

The only difference between my rom and the original is an unaccelerated UEFI GOP framebuffer, which is usually used for boot display, and fallback display when the graphics driver fails to load. Your symptoms seem to indicate that your OS graphics drivers (both Windows and Mac) are not working, and the OS is displaying with the GOP framebuffer as a fallback. Maybe some more work is needed from the Mac side to get the OS driver working. With a fallback display, it could be easier now.
…
On Mon, Oct 12, 2020 at 7:25 AM zaptrem @.***> wrote: @HouQiming https://github.com/HouQiming Using the “original” doesn’t seem to boot at all with MacOS, but that could be a driver issue ¯_(ツ)_/¯. I’ll stick with the fork of yours for now. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5MQF662D7LXPXBMUZOLTLSKI5GTANCNFSM4EW7UPEA .

I have no clue why, but everything started working (mostly) fine one day a few weeks ago, so I went with it. However, it seems like the graphics begin to "deteriorate" after the VM is left on for a day or so and artifacts begin to appear. Shutting down the VM, passing the iGPU to another (empty) VM, and starting the Mac VM again makes them go away. Any idea what could be causing this?

Also, @zhenyw You referenced this issue in your commit. Does that imply there's progress being made toward an official solution?

[patmagauran]

@zaptrem Theoretically once the guest OS takes over, the ROM loses most control. If you are using GVT-G perhaps there is a slow memory issue dealing with the framebuffer. @HouQiming would be better for that part as they wrote that segment of code.

[DocMAX]

After years i tried again... and: UEFI Intel GVT-g works on a Thinkpad X1 Carbon 3rd gen with Win10 using provided UEFI vBios. Also doing Wifi bridging with parprouted and bcrelay. Works perfectly.