[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

[DocMAX]

PERFECT!!! Thank you very much my friend!!! Will try later on a 3rd gen X1 Carbon ThinkPad (Broadwell) and Report back. Can you try a Q35 machine Setup with OVMF to see if it works?

Perhaps we can add gvt kernel + gvt qemu in the AUR repo? Wondering why there isn't allready one.

[ghost]

That's great. Will try and report how it worked soon.

[DocMAX]

I get:

(123..) ioctl VFIO_DEVICE_QUERY_GFX_PLANE(primary): Invalid arument

On QEMU display i see "Guest has not initialized the display (yet)

[XaeroVincent]

DocMAX, Qemu will say that until the Windows guest is booted and the Intel guest driver is initialized.

I ended up using '-vga qxl' to install the quest and get everything up and running first. It's also a good idea to use Display Driver Uninstaller in safe mode to remove the default installed Windows Intel GFX drivers, which can cause BSOD in the guest with VFIO.

https://www.wagnardsoft.com/

After you install the official 15.45 or 15.65 Intel graphics drivers from Intels website, then you can change it back to '-vga none'. Be sure to shutdown the guest before making changes, of course.

[DocMAX]

XaeroVincent, can you please check if Q35 and OVMF works on your system?

[XaeroVincent]

Q35 machine profile works but re-installing the guest with OVMF/Tianocore UEFI seems to break the Dmabuf support. I guess we'll just have to use the default QEMU SeaBIOS with Q35/ICH9 or the default I440FX chipset emulation until that's fixed? Maybe one of the Intel devs can investigate this.

BTW, if you are having garbled /staticky sound, if using the HDA sound device in QEMU (when using the pulseaudio sound driver), setting the Windows playback device sample rate to 44100 Hz seems to clear it up. I think it's because default pulseaudio server sample rate on Linux is set to 44100 Hz.

[DocMAX]

I'm trying to run macOS with GVT-g. At the moment i get this error. maybe someone tries to accomplish the same and share findings.

[IGPU] Graphics driver failed to load:could not register with Framebuffer driver

[XaeroVincent]

Well in addition to the host Linux kernel and QEMU needing modifications for GVT, the guest graphics drivers also need modifications to support GVT. It has been mentioned by a dev on here that the Linux and Windows drivers have said support. However, there is no reason to believe that the built-in macOS graphics drivers also contain this support too, since IIRC, Apple's EULA only permits macOS virtualization guests on macOS hosts, running on Macintosh systems and this project's scope doesn't seem to encompass macOS host use cases.

[oscarbg]

@XaeroVincent some questions:

1)Phoronix says all needed kernel bits are in 4.16 (in 4.16rc1 already?).. it's true? I installed it on ubuntu form kernel ppa (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.16-rc1/) in case yes.. 4.16 kernel has to have any non default kernel option enabled at build? I say because I can see in /boot/config-4.16.0-041600rc1-generic file if Ubuntu is enabling that option..

regarding Qemu phoronix says it will probably be upstreamed in 2.12 already.. anybody seeing this thread can say if it's expected to be true, i.e. that's the plan? if yes then can probably wait a month for first RC builds and non build custom Qemu branch..

2) any interest on doing the same for Ubuntu.. ie. provide precompiled packages via .deb files or setup a PPA?

3) have you tested some modern Android x86 ISO (ex: http://www.android-x86.org/releases/releasenote-7-1-r1) to see if all this works also in addition to Linux and Windows.. it should work as they ship with modern Linux kernel and Mesa drivers underneath.. 7.1r1 ships with: LTS kernel 4.9.80 notes from older 7.1rc1: Support OpenGL ES 3.x hardware acceleration for Intel/AMD/Nvidia, VMware and QEMU(virgl) by Mesa 17.1.2. from 7.1rc2: Improve QEMU virgl stability. *Update Mesa to 17.1.10

if that not recent enough you can test Android 8.1 (Oreo) experimental builds provided by @maurossi here: https://drive.google.com/drive/folders/0B_OFHiIqgpSFTFpkQWc1eXV3ME0 which ship with latest kernel 4.16rc1+Mesa18.1dev using LLVM6.0 for amdgpu..

please someone share findings of success using Android x86 as guest..

[oscarbg]

Thanks for all info.. Sadly anbox seems to have issues on Ubuntu.. tried various times within a year and never worked for me or much other people.. anbox github issues site is full of people on recent Ubuntu versions having anbox dont’ working.. Also sad is Android x86 ISO’s have opengl es 3.2 support so very recent apps work.. and the latest Oreo iso even has vulkan Anvil support albeit don’t working for many apps only vulkancapsviwer.. that can’t be done very fast by anbox people.. even Android emulator started recently having gles 3.0 support.. and last also even beignet Intel opencl driver support Android although no Android x86 ISOs currently include it in future could be.. there are some apps using in on store.. finally even hardware accel video decding via va API (and encoding?) is included on Isos.. so Intel must support it.. now I remember someone sometime ago used gvt on Andrroid x86 so maybe what you are referring need X.org conf is for new dma_buf functionality we are talking after all, right?

[oscarbg]

I just opened an issue: https://github.com/intel/Igvtg-qemu/issues/3 asking if QEMU GVT dma_buf support will be ready for QEMU 2.12..

[newperson1746]

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...

[DocMAX]

Great! Keep me posted on any updates! Can't wait to see dma-buf working stable on OSX guest!

[newperson1746]

I'm gonna try InjectEDID and CustomEDID to see if I can at least trick macOS into acceleration remotely. I know, I can't wait either. This will be the first time a virtualized macOS has qe/ci without dedicating a vfio-pci gpu for it.

[newperson1746]

Also, while I try and debug macOS, to get a serial console: add -serial telnet:127.0.0.1:4444,server,nowait to qemu, and macos boot-args="debug=0x8 console=3" will give you a console on serial port on macos.

[newperson1746]

I posted an issue about dma-buf not working (black screen) on ubuntu. If I had arch I could be testing this right now, but I am out of storage.

[ozeidan]

Hi guys, could anybody explain how to use this from virt-manager? I added to my windows10.xml:

<qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:00:02.0/6f8c2453-2896-4cb3-82ce-c2bbdcb943de,rombar=0'/>
</qemu:commandline>

It fails with errormessage:

qemu-system-x86_64: -device vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:00:02.0/6f8c2453-2896-4cb3-82ce-c2bbdcb943de,rombar=0: vfio error: 6f8c2453-2896-4cb3-82ce-c2bbdcb943de: failed to open /dev/vfio/0: Operation not permitted

When starting with qemu directly, it seems to start fine. But I am too dumb to setup the networking in qemu. (Or maybe it doesn't work on my machine because libvirt already set up some networking stuff.) I would really appreciate help on this. Thanks

[DocMAX]

try to add a udev rule like this: SUBSYSTEM=="vfio", OWNER="root", GROUP="kvm"

[XaeroVincent]

Newperson1746 ,

That's impressive Newperson1746! I stand corrected. Dma-Buf doesn't appear to support QEMU UEFI yet, only SeaBIOS.

Perhaps one thing you can try is to patch your macOS guest to run on BIOS+MBR based partitions then macOS can boot with QEMU using SeaBIOS?

http://www.insanelymac.com/forum/files/file/762-high-sierra-mbr-and-firmware-check-patch/?st=50#commentsStart

[newperson1746]

I will try that. However, even with seabios, this does not work. I posted all the info on a new issue, so that it can be better organized.

[newperson1746]

Ok. I stand corrected myself. With a copy of Android Oreo, the virtual gpu works fine in both UEFI grubx64.efi with OVMF and the regular isolinux (i think.) What happens is that i915_drm (I think) is loaded way early in boot, therefore allowing me to see the linux kernel booting. In macOS however, the driver gets loaded but doesn't know what to do beyond that, it just sees an HD 6000 without any display outputs, and disables OpenGL (same issue as headless macs, google it.) In early boot, macOS utilizes the EFI framebuffer console to output text/graphics, not the gpu-specific driver, as apple can expect its hardware to have the efi framebuffer available. Apple_ would need to explicitly support dma-buf in their drivers too, which is a virtually unrealistic expectation of them. I don't know whether or not intel compiles or has access to the source code for "GPUDrivers-Intel" (internal name in binary kext, I used grep to find it). If they do, I hope they can add support, because as of right now, it does not work (unless on the qemu-side of things the developers implement the dma-buf display output as a standard HDMI/DP/VGA output with an EDID attached, as that is what the macOS drivers are expecting/checking for) If somehow we can make the VGPU available as a standard display output that is then dma-buffed to qemu, then acceleration will work. If we can trick macOS into thinking a display is there and enabling OpenGL, we can screenshare into macOS and access the GPU as well, just like the old way in Windows (before dma-buf worked.) So there's three paths: 1) Add an option for dma-buf to appear as a standard display output with a standard EDID attached to a "physical" display output port, thereby not only allowing macOS/non-specifically fixed drivers to use gvtg, but also allowing UEFI/BIOS POST screens to work, as then gvtg would then support the basic EFI framebuffer/vesa modes, or... 2) Fix the macOS intel gpu drivers themselves, which is the way it is currently done on linux and windows. This is why you have to wait for the OS drivers to initialize. Because the drivers themselves handle output to dma-buf, not qemu. (So dma-buf is a special output mode, not masquerading as an HDMI out or similar) However I do not think Apple would be willing to do this, considering their past history. lastly... 3) Trick macOS (and drivers) into enabling OpenGL for the headless virtual display that is there for screensharing purposes. By default if macOS sees no physical displays then it creates a virtual framebuffer with a resolution of 1280x1024, but disables OpenGL, thereby making the menubar lose its translucency and the dock lose its transparency effects. (I can currently get that far, macOS boots with HD 6000 graphics loaded and drivers loaded, but we have the "headless mac" issue that occurs with real macs if headless, except that we cannot use a headless fake display HDMI adapter or etc) If we can trick macOS into thinking there's a physical display attached, we can then screen-share into macOS itself and access full QE/CI. (Even if we can't directly see the "tricked" display's output, we can access its framebuffer which does have QE/CI enabled) Hope that clarifies things. I am not even a developer, so this is all gathered from observation, however I'm sure a quick glance at i915 code would either prove or disprove this.

[oscarbg]

@newperson1746 are you telling me that Oreo ISO works out the box? In LIVE MODE also (without installing to a virtual disk)? if yes the we have good news for today.. also what ISO? are using the experimental ISO "oreo_x86_64_k416rc1_amd_dc_llvm60_mesa-18.1.0devel_vulkan.iso" I linked in earlier post?

[newperson1746]

Yes, sir. Exactly that one, if booted live, or installed, will work OOB. I will provide a screenshot, one sec.

[oscarbg]

@newperson1746 great!!! can I please ask to include a screenshot of VulkanCapsViewer app from Play store (https://play.google.com/store/apps/details?id=de.saschawillems.vulkancapsviewer) to see Vulkan driver from this ISO is working correctly under GVT-g and also one of either OpenGL extensions Viewer app or https://play.google.com/store/apps/details?id=de.saschawillems.glescapsviewer to see identifies corerctly as Mesa 18.1dev with OpenGL ES 3.2 support..

[newperson1746]

sure one sec. screenshot: (oops 1920x1200 framebuffer is larger than my little laptop screen)

[oscarbg]

@newperson1746 I'm not fluent enough in all this tech.. may I ask you to provide complete qemu arguments list to test that ISO is working on my system with Ubuntu 18.04dev+ 4.16rc1 +custom built QEMU+dma_buf by myself?

[newperson1746]

I switched out to the 1024x768 one. I'm setting up. One sec please.

[newperson1746]

opengles extensions: right here vulkan: (vulkan crashed when submitting report)

[oscarbg]

@newperson1746 thanks for being so fast.. note vulkan support is very early and even on native mode crashes sending submitting report.. it's says something about extensions string parsing right?

[newperson1746]

I am installing it, upgrading my 7.0 install so I can use vgpu. just a few minutes, I apologize for the delay. (But i want to be able to save apps i installed, not go away on reboot)

[oscarbg]

sure can wait.. no pressure.. please just don't forget my request to post some detailed QEMU arguments for launching for a noob in QEMU like me so I can't replicate your efforts and assure kernel 4.16rc1 Ubuntu provides in ppa is good enough for this..

[XaeroVincent]

@newperson1746 Oh that's interesting. It must be that UEFI & Dma-buf doesn't work with Windows guests for reason. Good to know it works on Android / Linux guests, though. Yes, the kernel loads the graphics driver really early for KMS support.

Well as far as macOS guests go, I don't think any virtualization products on market support hardware acceleration with it in a guest? IIRC, even VMware Fusion and Parallels Desktop don't accelerate macOS guests because Quartz Compositor using the Metal rendering engine in Sierra and High Sierra?

Have you tried checking to see what EDID information Qemu exposes to the macOS guest?

Interesting as it appears that that the Intel driver inside Qemu w/ GVT+Dmabuf is exposing a fake monitor EDID, based off a real Hewlett-Packard 24" LCD monitor (ZR2440w) and shows that it's connected and active.

[newperson1746]

Ok... so please run ls -lh /sys/devices/pci0000:00/0000:00:02.0/mdev_supported_types to find out what you have... if there are directories present, then run this: for f in /sys/devices/pci0000:00/0000:00:02.0/mdev_supported_types/*/description; do echo "$f"; cat "$f"; done That will tell you the descriptions of the GVTg devices you have available. Then, choose the one you want to use. Run the command: sudo bash -c 'echo a297db4a-f4c2-11e6-90f6-d3b88d6c9525 > /sys/devices/pci0000:00/0000:00:02.0/mdev_supported_types/WHATEVER_DEVICE_YOU_CHOSE/create' That will create the GVTg device. check dmesg to make sure that it was created by i915. Once done, do whatever qemu command you were using to run whatever OS before, but then add somewhere: -device vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:00:02.0/a297db4a-f4c2-11e6-90f6-d3b88d6c9525,x-display=on,x-igd-opregion=on -display gtk,gl=on and then if you do not already have a -vga present then for the first few times you test add: -vga qxl to have a gpu that you can use to see POST messages. The Intel won't display anything until: a) i915_drm is loaded, which is very quickly for linux, or until the intel driver for windows is loaded, which takes a while because it finishes loading only after windows has finished booting. (Linux loads the drm console driver early, windows just uses the efifb/vesa modes until it finishes booting, and the GVTg only supports the driver accelerated mode) Then, just boot into your os and look at the new device. Once you get to that point, just reply back with some details of your setup so I can help you more with final setup.

[newperson1746]

@XaeroVincent yes, you are entirely correct. The commercial virtualization products do not support macOS because a) IOKit (the c++ subset used by macOS for drivers) for graphics/opengl is undocumented, and b) Apple wants to sell real macs. By not providing acceleration in virtualized machines, Apple ensures that you cannot use a VM for actual mac-specific applications, as those all require an accelerated gpu. The goal I think is to make a virtualized machine work, but be unusable for productivity, to force you to get a real mac. As for Quartz Compositor (located in CoreGraphics.framework as WindowServer,) it uses OpenGL mostly to render, and you are correct in that it uses metal for supported graphics cards. dma-buf does work with uefi with linux, however I have not touched a Windows install in years, since I just don't game and don't use microsoft office. It should work, however, just like linux worked in both legacy and OVMF. macOS is really picky on EDID's. I am sure that qemu is exposing some kind of EDID interface, but macOS doesn't pick it up. Hackintoshes use a bootloader called Clover, and it can inject arbitrary EDID's. I will test that soon. I can't thank all of you enough for the work you do in this. It truly is something amazing. I will have to boot up some non-android linux and run xrandr to find out what exactly it is exposed as. Thanks again for your hard, hard work.

[oscarbg]

well all is not lost, after I recall reading sometime ago some people have had success doing a dedicated GPU passthrough for Macos right?

[newperson1746]

Oh yeah. And this is not impossible. Just gotta get around to testing all scenarios, since we have a hackintosh bootloader (clover) at our hands - can fake pretty much anything, including edid.

[DocMAX]

@oscarbg Right, i'm running macOS High Sierra with full passthrough on nVidia GTX970

[oscarbg]

@DocMAX nice! never tried by myself Nvidia GPU passthrough.. as I also have a GTX 970 I'm just asking a thing: seems for doing a Nvidia Geforce GPU passthrough for Windows guest (note I say Geforces not Quadros) seems we need to patch the NV Windows driver installing correctly on the guest.. i.e. for not getting NV driver error install with code 43.. https://github.com/sk1080/nvidia-kvm-patcher (Generic fix to NVIDIA Code 43 on Virtual Machines) or https://github.com/Matoking/NVIDIA-vBIOS-VFIO-Patcher

so we need some fix similar to Nvidia for full passthrough on nVidia GTX970 on High Sierra? also have you tried Windows passthrough and needed some of the patches mentioned earlier or already don't needed? thanks..

[DocMAX]

Win7/10 works too! The patch isn't required if kvm hidden option is set.

[ozeidan]

Hey guys, could you share how you setup your networking on a laptop with qemu? The bridging doesn't work for me because I am using a wifi card.

Edit: I got it to work! macvtap ftw

But now I have the problem that the window doesn't really fit into my screen. Did you guys experience that? I can't downscale it. When using the 'zoom out' option of the menu, the window gets smaller but then the mouse doesn't point to the position it shows.

Also it seems to be really unstable :/

[XaeroVincent]

@ozeidan Could you share how you used macvtap to make bridge networking work?

I have Ethernet bridging somewhat working but it disconnects my Linux host from the Internet. I want to make WiFi bridging work too, as well as still be able to access the internet from within the Linux host, not just from within the guest.

BTW, if you're having crackling sound on the guest, change the playback device to use 44100 Hz sound in sound properties.

Turn on mouse trails in the Windows mouse settings then just reduce the trail size to the shortest setting.

[DocMAX]

@ozeidan Wifi doesn't work with bridging. My workaround:

                ip link add name br0 type bridge
                ip addr add 172.20.0.1/16 dev br0
                ip link set br0 up
                dnsmasq --interface=br0 --bind-interfaces --dhcp-range=172.20.0.2,172.20.255.254
                modprobe tun
                ip tuntap add dev tap0 mode tap user docmax
                ip link set tap0 up promisc on
                ip link set tap0 master br0
                sysctl net.ipv4.ip_forward=1
                sysctl net.ipv6.conf.default.forwarding=1
                sysctl net.ipv6.conf.all.forwarding=1
                iptables -t nat -A POSTROUTING -o wlp4s0 -j MASQUERADE
                iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
                iptables -A FORWARD -i tap0 -o wlp4s0 -j ACCEPT

If somebody has a better solution with no extra subnet (172.20.0.0/24), please tell us

[oscarbg]

@XaeroVincent have you tested 2.12rc0? seems to have all the required dmabuf bits so seems QEMU 2.12 will have support for it!

[DocMAX]

can someone confirm that dmabuf is still NOT included with qemu 2.12? i get internal error: qemu unexpectedly closed the monitor: 2018-05-19T08:30:59.328066Z qemu-system-x86_64: -device vfio-pci,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/59c57b6c-13ee-4055-846e-e4d3dc55d389,bus=pci.0,addr=0x4: Property '.x-display' not found

[TerrenceXu]

Qemu 2.12 renamed “x-display” -> “display”

From: DocMAX [mailto:notifications@github.com] Sent: Saturday, May 19, 2018 4:37 PM To: intel/gvt-linux gvt-linux@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [intel/gvt-linux] [Download] Pre-built GVT+Dmabuf QEMU package for Archlinux (#20)

can someone confirm that dmabuf is still NOT included with qemu 2.12? i get internal error: qemu unexpectedly closed the monitor: 2018-05-19T08:30:59.328066Z qemu-system-x86_64: -device vfio-pci,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/59c57b6c-13ee-4055-846e-e4d3dc55d389,bus=pci.0,addr=0x4: Property '.x-display' not found

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/intel/gvt-linux/issues/20#issuecomment-390389803, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYv0NFJphxdqlhMmSsNlXEZJV23ZVA4Sks5tz9mOgaJpZM4SDLex.

[FanFansfan]

so dma_buf has been upstreamed in qemu 2.12?

[TerrenceXu]

Yes. ☺

From: 麦文俊 [mailto:notifications@github.com] Sent: Thursday, June 7, 2018 2:35 PM To: intel/gvt-linux gvt-linux@noreply.github.com Cc: Xu, Terrence terrence.xu@intel.com; Comment comment@noreply.github.com Subject: Re: [intel/gvt-linux] [Download] Pre-built GVT+Dmabuf QEMU package for Archlinux (#20)

so dma_buf has been upstreamed in qemu 2.12?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/intel/gvt-linux/issues/20#issuecomment-395309103, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYv0NGuz210JIgiguGMZLJtu3ekr0hJzks5t6MmDgaJpZM4SDLex.

[Spargeltarzan]

I use qemu 2.12 and libvirt 4.3 and I struggle with booting my Windows machine with the mdev Intel vgpu attached. My issue is also "Guest has not initialized the display (yet)" like from DocMAX, but the proposed solution to attach a qxl graphics card lead to black screen for me. I tried to connect with virt-manager and virt-viewer, both without success.

I can only boot with graphical output when I remove the mdev vgpu again, but than Windows does not let me install the Intel graphics driver: "The system does not fulfil the minimum requirements" - obviously because no Intel vgpu is attached.

Help is very much appreciated!

[PSzczepanski1996]

I have similar issue here: https://github.com/intel/gvt-linux/issues/48

Also I installed Intel driver inside, but was messing with monitor settings and... this happened. Probably vfio-pci is not working at all, since it gets detected (what other device as display would be detected and gave black screen on GTK display?), so I can't do anything on my vm.

Screenshot on qxl-vga: Screenshot on vfio-pci: My config:

#!/bin/sh

# QEMU
qemu-system-x86_64 \
        -enable-kvm \
        -m 4G \
        -smp cores=2,threads=1,sockets=1,maxcpus=2 \
        -machine type=pc,accel=kvm,kernel_irqchip=on \
        -global PIIX4_PM.disable_s3=1 \
        -global PIIX4_PM.disable_s4=1 \
        -name windows10-gvt-g \
        -soundhw ac97 \
        -usb \
        -device usb-tablet \
        -display gtk,gl=on \
        -device vfio-pci,sysfsdev=/sys/devices/pci0000:00/0000:00:02.0/56fdd4da-ade1-11e8-98d0-529269fb1459,x-igd-opregion=on,display=on \
        -drive file=/home/hoshi/windows10/win10.qcow2,format=qcow2,l2-cache-size=8M \
        -cdrom /home/hoshi/windows10/win_install.iso \
        -vga qxl \
        -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd \
        -drive if=pflash,format=raw,file=/usr/share/ovmf/x64/OVMF_VARS.fd

[joyqing]

Just show the VM MacOS render HW acceleration It's not gvt-g. It's directly iGPU passthrough like RX580. Specs below: Asrock Z370 Pro4, i7 8700k, rx580, 2080ti, Manjaro kde kernel 5.2, qemu 4.0.0-2, libvirt 5.4.0-1. pass through rx580+UHD630+SATA. Add -disablefxframware in Clover. SMBios must be iMac pro 1.1. FCPX is 10.4.6 works as same as the host. Only one MacOS partition in HD.Either VM or Host can all boot from the same MacOS par. Issue: VM POST needs very long time. This is not fully solution because iGPU doesn't work just acts as "headless". GVT-g is the future. Hope someone can open a new thread to discuss iGPU passthrough for MacOS.