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.

[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 notifications@github.com 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 https://github.com/intel/gvt-linux/issues/23#issuecomment-653694024, 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 notifications@github.com 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 https://github.com/intel/gvt-linux/issues/23#issuecomment-704060982, 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 notifications@github.com 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 https://github.com/intel/gvt-linux/issues/23#issuecomment-706784591, 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.