[Download] Pre-built GVT+Dmabuf QEMU package for Archlinux

[XaeroVincent]

Update: Please use Linux 4.16rc2 or newer kernels to have the kernel-side GVT + Dmabuf components. A patched QEMU is still needed.

I went ahead and packaged up QEMU 2.10 with GVT-g and Dmabuf support that I compiled on my system. The QEMU package is hosted on my OneDrive account. This package is only designed for use with Archlinux and derivative distributions and can be installed with 'pacman -U'. Be sure to follow the applicable parts of the official guide and add the proper qemu and kernel boot options for VFIO GPU passthrough to work.

Download (Built from 'stable-2.10.0' git as of 2/20/2018): https://1drv.ms/u/s!Am9uPEIZtbF9g1vFKo3-yNuiU8Vb

Optional: Source code

[jembhz]

Ey, how did you achieve that, I'm struggling with Proxmox (Based on QEMU/KVM) to get that done, to put the iGPU as headless, I have a RX580 as well and everything is working so far on MacOS Mojave but iGPU passthrouhg as headless, when I try it MacOS reboots forever, if you can give me some advice I will really appreciate!

[oscarbg]

@joyqing just noticed the "gpustat" MacOS command line tool you use which seems to report GPU clocks, utlization,etc.. I can't find anywhere.. it's custom made? can share source code or which Mac APIs you use to query such information from your apps? thanks..

[mateHD]

I have macOS High Sierra as well (real mac, actually on ubuntu 16.04.3) it is a macbookair with hd 6000 (bdw) graphics. Since the dma-buf doesn't seem to work (for me, it just says cursor plane not initialized by guest) I have -serial stdio with tianocore uefi, which allows me to navigate clover bootloader via the serial port! Then I just wait a long time until macos boots, and I get this: (via port forwarding 5900 to 5800 for screen sharing host-side) since the dma-buf doesn't work, I just use macos screen sharing. As you can see, the bdw kexts are loaded, but, just like a real headless mac, unless there is an edid detected on a port, qe/ci still gets disabled. We are really close here, all that needs to happen is: a) get the dma-buf to work with tianocore uefi, or b) we get clover to fake a display. b) is actually possible, we can inject an edid (meant for laptops with monitor issues) which will trick appleintelbdwgraphics into enabling acceleration, and we screen-share in until dma-buf works wiith uefi. Note: this is all on real macbookair7,2...

Hi, Do you have any news about this project? Any success? Thanks

[trevor403]

This issue is linked in Arch Wiki, the have some options for using OVMF UEFI to work for guests. This would enable Clover to use the OpRom for gvt https://wiki.archlinux.org/index.php/Intel_GVT-g#Using_DMA-BUF_with_UEFI/OVMF

Note that DMA-BUF will never work on macOS unless a (fairly complex) kext patch were to be developed. Less likely would be official GVT DMA-BUF support distributed by Apple. However I would love to see EDID faking to gain headless HW acceleration.

I hope Clover can help make this possible!

[danwdart]

Is this mainlined in 4.2 or 5.0?

[scorpion81]

Hi everyone,

With the help of a locally modified version of https://github.com/patmagauran/i915ovmfPkg i had partial success with GVT-g and macOS in qemu. The VM boots up and you can see the Guest IGPU displayed in MacOS BUT... if you attempt to load the (in my case) KabyLake or CoffeeLake apple drivers, booting takes very long and there are a few error messages in qemu, the host linux's dmesg (Manjaro with kernel 5.10.89) and the boot gets stuck when trying to access the frame buffer.

See here for more details and the mentioned error messages:

https://github.com/acidanthera/bugtracker/issues/1914#issuecomment-1008007535

The relevant bits here are (dmesg):

[ 2466.228805] i915 0000:00:02.0: drm_WARN_ON(bytes > 2)
[ 2466.228844] WARNING: CPU: 4 PID: 22460 at drivers/gpu/drm/i915/gvt/cfg_space.c:325 intel_vgpu_emulate_cfg_write+0x3a3/0x4c0 [i915] 

--snip, see the link above for the stacktrace of that warning--

[ 2466.288841] gvt: vgpu(1) Invalid FORCE_NONPRIV write 7034 at offset 24d8
[ 2466.288846] gvt: vgpu(1) Invalid FORCE_NONPRIV write 7008 at offset 24dc
[ 2466.288856] gvt: vgpu 1: write invalid HWSP address, reg:0x2080, value:0x402a4000
[ 2466.288857] gvt: vgpu 1: fail to emulate MMIO write 00002080 len 4
[ 2466.288879] gvt: vgpu 1: write invalid HWSP address, reg:0x12080, value:0x402a5000
[ 2466.288879] gvt: vgpu 1: fail to emulate MMIO write 00012080 len 4
[ 2466.288909] gvt: vgpu 1: write invalid HWSP address, reg:0x22080, value:0x402a6000
[ 2466.288909] gvt: vgpu 1: fail to emulate MMIO write 00022080 len 4
[ 2466.288918] gvt: vgpu 1: write invalid HWSP address, reg:0x1a080, value:0x402a7000
[ 2466.288918] gvt: vgpu 1: fail to emulate MMIO write 0001a080 len 4
[ 2466.292585] gvt: vgpu 1: invalid mm type: 0 gma 402aa000
[ 2466.292586] gvt: vgpu 1: invalid guest context LRCA: 402a9
[ 2466.292587] gvt: vgpu 1: failed to submit desc 0
[ 2466.292588] gvt: vgpu 1: fail submit workload on ring rcs0
[ 2466.292588] gvt: vgpu 1: fail to emulate MMIO write 00002230 len 4

and qemu:

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
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
qemu-system-x86_64: vfio_region_write(9085644c-8cf8-4df0-900e-0c1362deddea:region0+0x2230, 0x402a9119,4) failed: Ung?ltige Adresse 

the MMIO(24d8) and MMIO(24dc) are not "whitelisted" and there seem to be issues with the gtt/aperture size (some address range is being validated, but seems to fail), but i didnt have luck to solve it and not enough understanding of the nuts and bolts of the Intel driver terminology.... all those crazy shortcuts... :slightly_frowning_face:

So, what relevant bits are missing here in gvt which seem not to be passed further to the "Host" i915 ?