Arch Linux

supertrampx

Member

Registered: 2015-06-07

Posts: 11

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Thanks for tips Nesousx I will give it a shot when I am off work this evening. This forum post is amazing Respect for everyone who put in the time here.

lersek

Member

Registered: 2015-03-15

Posts: 38

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

The second quote makes no sense because GOPs are exposed by, and are the standard interface of, device-specific UEFI video drivers. A UEFI GOP does not exist without a device-specific UEFI driver; at worst you can say that the actual driver is low quality or generic, because, while it recognizes the video card, it cannot utilize its full capabilities.

Who writes those UEFI drivers? Firmware-engineers(ASUS, Gigabyte, guys who produce the motherboards, etc.), vendors of the devices(EVGA, Sapphire, guys that don't produce motherboards etc.) or AMD/Intel themselves? Where they are stored? Are they hidden somewhere in the firmware(UEFI), or in the device ROM? If it's an intel iGPU, where that ROM with the device driver is located, as i can't recall intel GPUs being listed as a regular PCI device?

From a UEFI perspective, it doesn't matter where the UEFI driver binary comes from. It can be part of the system flash chip (soldered to the motherboard), it can be part of the PCI oprom (in case of a discrete graphics card), but you can also load it from a FAT32 filesystem (eg. USB pendrive or EFI system partition), from the UEFI shell, or with a Driver#### variable.

In practice, for discrete graphics card, "PCI oprom" is the only sensible answer -- ie. you get the driver when you buy the card. For integrated graphics cards, I think it's usually part of the system firmware.

And..
Why does emulated QXL can't go beyond 1024x768... even with an extended amount of VRAM given?

The UEFI GOP installed for QXL can very well go beyond 1024x768. You can see the supported resolutions here:

https://github.com/tianocore/edk2/blob/ … ize.c#L211

I use QXL resolutions higher than 1024x768 in my guests all the time.

I think you are conflating two things here. The 1024x768 resolution limit is in place for *Windows 7* only, and that's because Windows 7 is *not* a UEFI operating system when it comes to its builtin video driver. Windows 7 will boot on a UEFI platform, yes, even without a CSM, but its builtin video driver is broken in the sense that it will *only* look for the legacy video bios services (the VBE, VESA BIOS Extansion). It won't even look for a preconfigured framebuffer, it *insists* on the legacy BIOS video services (Int10h). A fully conformant UEFI operating system is not permitted to do this, and this is also why you can run Windows 7 on physical UEFI platforms only if you enter the UEFI setup utility during boot, and enable the CSM or "VBIOS" support or whatever the vendor in question calls it.

We disliked Windows 7's dependency on a full-blown CSM, and worked around it in OVMF. Namely, OVMF's video driver provides, fully independently of the multi-resolution UEFI GOP, a very limited VESA BIOS Extension too, even without incorporating the CSM. We call this the "Int10h shim". It is a shim because it provides a minimal set of VBE services, which are expected to be interpreted *only* by the Windows 7 real mode emulator. It is written in assembly, and it is placed in memory, and provides only the services, so that Windows 7 can be installed.

https://github.com/tianocore/edk2/blob/ … beShim.asm
https://github.com/tianocore/edk2/blob/ … VbeShim.sh
https://github.com/tianocore/edk2/blob/ … /VbeShim.c
https://github.com/tianocore/edk2/blob/ … /VbeShim.h

Summary: the UEFI GOP that OVMF provides for QXL has a nice list of resolutions, dependent on QXL vram size, and it is available to *actually* UEFI compliant OSes, like many Linux versions and Windows 8 and later. Windows 7 is not such an operating system, it cannot use the GOP, it insists on legacy video BIOS services, hence OVMF fakes the absolute minimum of legacy video BIOS services just for Windows 7's sake, even if you build OVMF without a CSM. This "fake" is called the Int10h shim, and the resolution limitation pertains only to the Int10h shim, not the UEFI GOP.

Duelist

Member

Registered: 2014-09-22

Posts: 358

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

@lersek: Well, that clears up a lot...
And how do i change the display resolution initiated by OVMF? Some EFI shell command, i guess?
I just remember the time i've tried to install windows8 - it inherited that 1024x768 mode from OVMF, and there was a huge fail, because it couldn't raise the resolution and refused to launch internet exploder due to low resolution, and there was no way of downloading the proper drivers without using some external storage.

And what about... the installation disc? Windows7 seems to work fine while you're installing it(so i guess it inherits the videomode from OVMF, and works with GOP), but when the installation is done and it's time to show that colourful 4-piece logo animation - it hangs. Maybe there are multiple videodrivers, and we can swap them?

...hmm, it's possible to load the EFI driver from a fat32 partition.. I guess the file should be .efi, and i must load it manually from the UEFI-shell.. Since i have a modified ROM for my asus cards which has an almost 3rd party EFI-driver embedded in it, maybe i wouldn't need it.. Still haven't flashed it physically, heh.

Last edited by Duelist (2015-06-08 14:34:07)

---

The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.

supertrampx

Member

Registered: 2015-06-07

Posts: 11

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Many thanks to Nesousx first for his awesome fix.
I was able to successfully boot windows today, with networking, usb keyboard and mouse. I installed the Nvidia 970gtx drivers and have some white lines running across the screen. Anything I can do to fix this?

lersek

Member

Registered: 2015-03-15

Posts: 38

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

@lersek: Well, that clears up a lot...
And how do i change the display resolution initiated by OVMF? Some EFI shell command, i guess?

IIRC this has been discussed before. It's certainly described in the OVMF whitepaper, subsection "Platform Driver". Press ESC at the TianoCore splash screen, Navigate to Device Manager | OVMF Platform Configuration, select the preferred resolution from the drop-down list, commit changes, then reboot. (You can reboot by: (a) forcing it from the qemu monitor or virt-manager, (b), going to the EFI shell and issuing "reset -c", (c) going to Boot Maintenance Manager and selecting Reset System.)

I just remember the time i've tried to install windows8 - it inherited that 1024x768 mode from OVMF, and there was a huge fail, because it couldn't raise the resolution and refused to launch internet exploder due to low resolution, and there was no way of downloading the proper drivers without using some external storage.

Correct. That's exactly the case when you change the resolution in the firmware as I described at the top.

And what about... the installation disc? Windows7 seems to work fine while you're installing it (so i guess it inherits the videomode from OVMF, and works with GOP)

As long as the UEFI boot loader of Windows 7 (which is a UEFI application) is running, it uses the GOP natively. It could even switch resolutions if it wanted to.

but when the installation is done and it's time to show that colourful 4-piece logo animation - it hangs.

That's when the handover to the runtime OS happens, and the builtin kernel mode video driver takes control. It does not hang (it should not, anyway).

Instead, on a BIOS machine (or a UEFI+CSM machine), you'd see a 640x480, 16 color, planar VGA mode. (The most basic VGA mode.) With some messages.

This planar VGA mode was way too complex to implement in the Int10h shim, so we return "success" for the request, but do nothing. (Search the ASM file linked earlier for "SetModeLegacy".)

Two of us tried to implement this mode, but it's not really possible, because Windows 7 massages the legacy VGA CRTC registers manually, and seemed to interfere with whatever we tried to do. So, you get a blank screen, but it does not last long, and these screens are not interactive. At some point the builtin kernel mode video driver decides to look for VBE modes (better resolution, true color), and then it finds the "fake" 1024x768x32 mode, and asks the shim to switch to it. Which we do, and then you get the first green (or blue) screen (dependent on Windows Server 2008 R2 vs. Windows 7), with the mouse etc.

It might take a few tens of seconds for this screen to show up, especially if you have the guest on a spindle disk.

Duelist

Member

Registered: 2014-09-22

Posts: 358

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

As long as the UEFI boot loader of Windows 7 (which is a UEFI application) is running, it uses the GOP natively. It could even switch resolutions if it wanted to.

but when the installation is done and it's time to show that colourful 4-piece logo animation - it hangs.

That's when the handover to the runtime OS happens, and the builtin kernel mode video driver takes control. It does not hang (it should not, anyway).

So there's two possible ways of "patching" windows 7:
1. Changing the bootloader to something else. As i feel it(yep, i have a strange feeling not based on any research) the windows setup and the windows core don't differ much, and it may be possible to swap them. Also, maybe there's some weird third-party-influenced way of loading the windows, but that's way beyond our scope... and win10 is coming, so win7 is becoming obsolete in some years.
2. Changing the "builtin kernel mode video driver", as you've called it. That should be somewhat more simple, as i remember some OEM reinstall images for certain notebooks which had a system image with GPU drivers incorporated into them.

Any suggestions? Maybe i'll take a look on that, but i'm just somewhat busy with the life, books and installing gentoo into a prefix to install gentoo on rasp.pi...

---

The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.

dRaiser

Member

From: Poland

Registered: 2013-05-20

Posts: 51

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Hi. I've finally changed my guest GPU - temporarily to GTX 960, from Radeon 4850. Coming from Radeon I knew that it wouldn't work without problems - but I can't overcome them at this moment. I got dreaded 'Code 43' on Nvidia GPU. I've disabled hyperv extensions and set kvm hidden state to off. I'm now checking if kernel update to linux-vfio could help with anything, but it would be great if you could give me some tips.

I use Nvidia 9800 GTX+ with nvidia blob for host, have i3-550 CPU and AsRock Z77 Extreme4. All kvm-related things enabled (as I was running it properly with Radeon working on machine). I have 8 GiB total and 3 passed for machine.

960 GPU plus it's audio adapter are in pci-stubs and added to machine config.

<domain type='kvm'>
  <name>wintendo</name>
  <uuid>bf6bda0e-2664-4bab-998a-aac4dc255c83</uuid>
  <memory unit='KiB'>3145728</memory>
  <currentMemory unit='KiB'>3145728</currentMemory>
  <vcpu placement='static'>3</vcpu>
  <os>
    <type arch='x86_64' machine='pc-i440fx-2.1'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
    <kvm>
      <hidden state='on'/>
    </kvm>
  </features>
  <cpu mode='custom' match='exact'>
    <model fallback='allow'>SandyBridge</model>
    <vendor>Intel</vendor>
    <topology sockets='1' cores='3' threads='1'/>
    <feature policy='require' name='vme'/>
    <feature policy='require' name='dtes64'/>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='erms'/>
    <feature policy='require' name='xtpr'/>
    <feature policy='require' name='smep'/>
    <feature policy='require' name='pcid'/>
    <feature policy='require' name='est'/>
    <feature policy='require' name='monitor'/>
    <feature policy='require' name='smx'/>
    <feature policy='require' name='tm'/>
    <feature policy='require' name='acpi'/>
    <feature policy='require' name='osxsave'/>
    <feature policy='require' name='ht'/>
    <feature policy='require' name='pdcm'/>
    <feature policy='require' name='fsgsbase'/>
    <feature policy='require' name='f16c'/>
    <feature policy='require' name='ds'/>
    <feature policy='require' name='invtsc'/>
    <feature policy='require' name='tm2'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='pbe'/>
    <feature policy='require' name='ds_cpl'/>
    <feature policy='require' name='rdrand'/>
  </cpu>
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/sbin/qemu-system-x86_64</emulator>
    <disk type='block' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/sr0'/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/d2/50.raw'/>
      <target dev='vdd' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/d2/d2.img'/>
      <target dev='vde' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:17:65:a1'/>
      <source bridge='br0'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' autoport='yes'/>
    <video>
      <model type='cirrus' vram='16384' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x045e'/>
        <product id='0x0719'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x1532'/>
        <product id='0x0016'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </hostdev>
    <redirdev bus='usb' type='spicevmc'>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
    </redirdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </memballoon>
  </devices>
</domain>

Last edited by dRaiser (2015-06-10 18:11:50)

Duelist

Member

Registered: 2014-09-22

Posts: 358

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Hi. I've finally changed my guest GPU - temporarily to GTX 960, from Radeon 4850. Coming from Radeon I knew that it wouldn't work without problems - but I can't overcome them at this moment. I got dreaded 'Code 43' on Nvidia GPU. I've disabled hyperv extensions and set kvm hidden state to off. I'm now checking if kernel update to linux-vfio could help with anything, but it would be great if you could give me some tips.

I use Nvidia 9800 GTX+ with nvidia blob for host, have i3-550 CPU and AsRock Z77 Extreme4. All kvm-related things enabled (as I was running it properly with Radeon working on machine). I have 8 GiB total and 3 passed for machine.

960 GPU plus it's audio adapter are in pci-stubs and added to machine config.

<domain type='kvm'>
  <name>wintendo</name>
  <uuid>bf6bda0e-2664-4bab-998a-aac4dc255c83</uuid>
  <memory unit='KiB'>3145728</memory>
  <currentMemory unit='KiB'>3145728</currentMemory>
  <vcpu placement='static'>3</vcpu>
  <os>
    <type arch='x86_64' machine='pc-i440fx-2.1'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
    <kvm>
      <hidden state='on'/>
    </kvm>
  </features>
  <cpu mode='custom' match='exact'>
    <model fallback='allow'>SandyBridge</model>
    <vendor>Intel</vendor>
    <topology sockets='1' cores='3' threads='1'/>
    <feature policy='require' name='vme'/>
    <feature policy='require' name='dtes64'/>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='erms'/>
    <feature policy='require' name='xtpr'/>
    <feature policy='require' name='smep'/>
    <feature policy='require' name='pcid'/>
    <feature policy='require' name='est'/>
    <feature policy='require' name='monitor'/>
    <feature policy='require' name='smx'/>
    <feature policy='require' name='tm'/>
    <feature policy='require' name='acpi'/>
    <feature policy='require' name='osxsave'/>
    <feature policy='require' name='ht'/>
    <feature policy='require' name='pdcm'/>
    <feature policy='require' name='fsgsbase'/>
    <feature policy='require' name='f16c'/>
    <feature policy='require' name='ds'/>
    <feature policy='require' name='invtsc'/>
    <feature policy='require' name='tm2'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='pbe'/>
    <feature policy='require' name='ds_cpl'/>
    <feature policy='require' name='rdrand'/>
  </cpu>
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/sbin/qemu-system-x86_64</emulator>
    <disk type='block' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/sr0'/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/d2/50.raw'/>
      <target dev='vdd' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/d2/d2.img'/>
      <target dev='vde' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:17:65:a1'/>
      <source bridge='br0'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' autoport='yes'/>
    <video>
      <model type='cirrus' vram='16384' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x045e'/>
        <product id='0x0719'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x1532'/>
        <product id='0x0016'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </hostdev>
    <redirdev bus='usb' type='spicevmc'>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
    </redirdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </memballoon>
  </devices>
</domain>

Try force-disabling hyper-V enlightenments, maybe they're enabled by default now. That would be strange, however.

Also, you could try swapping the host and the guest cards(to see if it's not the host nvidia-guest nvidia related conflict, but a card-related problem), and maybe try using nouveau with 9800GTX+(aka GTS250 btw, you can reflash it that way for lulz)
Oh, and i think you should use host-passthrough CPU for the true cpu id being shown for GeForce Experience App to work right. That'll cut all those feature requests stuff you have there now.
Also you have Cirrus VGA enabled, ensure that you really need it(QXL is recommended for Windows7, not cirrus).

Last edited by Duelist (2015-06-10 18:34:48)

---

The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.

dRaiser

Member

From: Poland

Registered: 2013-05-20

Posts: 51

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Hi. I've finally changed my guest GPU - temporarily to GTX 960, from Radeon 4850. Coming from Radeon I knew that it wouldn't work without problems - but I can't overcome them at this moment. I got dreaded 'Code 43' on Nvidia GPU. I've disabled hyperv extensions and set kvm hidden state to off. I'm now checking if kernel update to linux-vfio could help with anything, but it would be great if you could give me some tips.

I use Nvidia 9800 GTX+ with nvidia blob for host, have i3-550 CPU and AsRock Z77 Extreme4. All kvm-related things enabled (as I was running it properly with Radeon working on machine). I have 8 GiB total and 3 passed for machine.

960 GPU plus it's audio adapter are in pci-stubs and added to machine config.

<domain type='kvm'>
  <name>wintendo</name>
  <uuid>bf6bda0e-2664-4bab-998a-aac4dc255c83</uuid>
  <memory unit='KiB'>3145728</memory>
  <currentMemory unit='KiB'>3145728</currentMemory>
  <vcpu placement='static'>3</vcpu>
  <os>
    <type arch='x86_64' machine='pc-i440fx-2.1'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
    <kvm>
      <hidden state='on'/>
    </kvm>
  </features>
  <cpu mode='custom' match='exact'>
    <model fallback='allow'>SandyBridge</model>
    <vendor>Intel</vendor>
    <topology sockets='1' cores='3' threads='1'/>
    <feature policy='require' name='vme'/>
    <feature policy='require' name='dtes64'/>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='erms'/>
    <feature policy='require' name='xtpr'/>
    <feature policy='require' name='smep'/>
    <feature policy='require' name='pcid'/>
    <feature policy='require' name='est'/>
    <feature policy='require' name='monitor'/>
    <feature policy='require' name='smx'/>
    <feature policy='require' name='tm'/>
    <feature policy='require' name='acpi'/>
    <feature policy='require' name='osxsave'/>
    <feature policy='require' name='ht'/>
    <feature policy='require' name='pdcm'/>
    <feature policy='require' name='fsgsbase'/>
    <feature policy='require' name='f16c'/>
    <feature policy='require' name='ds'/>
    <feature policy='require' name='invtsc'/>
    <feature policy='require' name='tm2'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='pbe'/>
    <feature policy='require' name='ds_cpl'/>
    <feature policy='require' name='rdrand'/>
  </cpu>
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/sbin/qemu-system-x86_64</emulator>
    <disk type='block' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/sr0'/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/d2/50.raw'/>
      <target dev='vdd' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/d2/d2.img'/>
      <target dev='vde' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:17:65:a1'/>
      <source bridge='br0'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' autoport='yes'/>
    <video>
      <model type='cirrus' vram='16384' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x045e'/>
        <product id='0x0719'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x1532'/>
        <product id='0x0016'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </hostdev>
    <redirdev bus='usb' type='spicevmc'>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
    </redirdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </memballoon>
  </devices>
</domain>

Try force-disabling hyper-V enlightenments, maybe they're enabled by default now. That would be strange, however.

I've tried both versions (completely deleted and off) without luck.

Also, you could try swapping the host and the guest cards(to see if it's not the host nvidia-guest nvidia related conflict, but a card-related problem), and maybe try using nouveau with 9800GTX+(aka GTS250 btw, you can reflash it that way for lulz)

Oh, and i think you should use host-passthrough CPU for the true cpu id being shown for GeForce Experience App to work right. That'll cut all those feature requests stuff you have there now.

Thanks, I didn't know that. However it won't help resolve main issue, am I right?

Also you have Cirrus VGA enabled, ensure that you really need it(QXL is recommended for Windows7, not cirrus).

I've just switched between both without any difference. It's feasible for testing and didn't caused any problems before, but I'll try disabling completely.

Last edited by dRaiser (2015-06-10 18:43:30)

aw

Member

Registered: 2013-10-04

Posts: 921

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

@dRaiser

Emulated primary graphics + secondary nvidia is not how GeForce works, nvidia should be your only graphics.  The mode you're trying works fine for Quadro.  Also, since you have host and guest nvidia with the host nvidia proprietary drivers, double check that you're successfully preventing the host nvidia driver from binding to resources on the guest card.  Nvidia does not support unbinding their driver from the device and is known to not release resources.  There's often dmesg errors when launching the vm if this happens.

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

dRaiser

Member

From: Poland

Registered: 2013-05-20

Posts: 51

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

@dRaiser

Emulated primary graphics + secondary nvidia is not how GeForce works, nvidia should be your only graphics.  The mode you're trying works fine for Quadro.  Also, since you have host and guest nvidia with the host nvidia proprietary drivers, double check that you're successfully preventing the host nvidia driver from binding to resources on the guest card.  Nvidia does not support unbinding their driver from the device and is known to not release resources.  There's often dmesg errors when launching the vm if this happens.

Ok, I've removed emulated graphics, but now can't see anything at all (so I don't know any windows errors and such).

I have pci-stubs in kernel line and vfio-bind configured. No dmesg errors after starting up machine, but it's not continuing booting properly, so I suspect it can't use card.

From lspci --nk I see this lines:

02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM206 [GeForce GTX 960] [10de:1401] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:3201]
	Kernel driver in use: vfio-pci
	Kernel modules: nouveau, nvidia

I think it's correct, but I'll ask for confirmation anyway.

Quick test:

sudo qemu-system-x86_64 -enable-kvm -m 1024 -cpu host,kvm=off -smp 4,sockets=1,cores=4,threads=1 -device vfio-pci,host=02:00.0,x-vga=on -device vfio-pci,host=02:00.1 -vga none

also works properly. So I think that 960 should be accessible for VM. Maybe I'll struggle and try run new Windows install...

Edit:

.. but it won't work when machines don't get video output at all. I wonder what's wrong. When I have emulated video enabled, then 960's discovered correctly (I've installed driver this way without problem).
I've switched host driver to nouveau and to newer kelner. Nothing changed.

Last edited by dRaiser (2015-06-10 21:51:16)

supplicant0x90

Member

Registered: 2015-06-10

Posts: 2

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

[aw] et al -

Your guides have been hugely valuable to me. I can't thank you enough for taking the time to share your research with us.

I've gotten everything else working through those (and days of doc review), but I can't figure out how get my (Windows 8.1) guest to instantiate with a vmx flag on the vcpu (to be clear, I mean for nested virtualization; the host already has it enabled and working fine).

How do you enable VT-x in the guest through virt-manager or virsh? I tried doing

host-passthrough

on the cpu, since the host supports it, but the vmx flag doesn't come through. I also tried passing a

<feature policy='force' name='vmx'>

argument in the cpu settings of the config using "virsh edit $vm" (along with other options to confirm it works), and some of the other cpu flags do pop as expected, but vmx does not.

Is there some special setting I've overlooked? I see 'man qemu' says you can call it using 'iommu=on|off' as a qemu-system-x86_64 argument, but I can't find anything else in the libvirt, virsh, or virt-manager docs.

Does it matter whether the guest uses BIOS or UEFI?

Apps on the guest confirm it's not a display issue:

Duelist

Member

Registered: 2014-09-22

Posts: 358

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

.. but it won't work when machines don't get video output at all. I wonder what's wrong. When I have emulated video enabled, then 960's discovered correctly (I've installed driver this way without problem).
I've switched host driver to nouveau and to newer kelner. Nothing changed.

That's sad, i wanted to suggest you to grep vgaarb in dmesg to see if there's any problems with that.

And..
You're not using OVMF, are you?
AW descriped some qemu wrapper script to append x-vga option to the device bound to vfio-pci and used by libvirt. libvirt will never allow x-vga to be on. So you'll need a wrapper script.

Or you could use ovmf to avoid VGA problems at all. You don't need to have any support of UEFI in your hardware except the GPU, and your 9XX geforce surely does support UEFI.

---

The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.

aw

Member

Registered: 2013-10-04

Posts: 921

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Quick test:

sudo qemu-system-x86_64 -enable-kvm -m 1024 -cpu host,kvm=off -smp 4,sockets=1,cores=4,threads=1 -device vfio-pci,host=02:00.0,x-vga=on -device vfio-pci,host=02:00.1 -vga none

also works properly. So I think that 960 should be accessible for VM. Maybe I'll struggle and try run new Windows install...

Edit:

.. but it won't work when machines don't get video output at all. I wonder what's wrong. When I have emulated video enabled, then 960's discovered correctly (I've installed driver this way without problem).
I've switched host driver to nouveau and to newer kelner. Nothing changed.

You're using x-vga=on here, but making no attempt to do so in your xml.  See part 5 of my how-to for a wrapper script around your qemu binary to add x-vga.

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

aw

Member

Registered: 2013-10-04

Posts: 921

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

I've gotten everything else working through those (and days of doc review), but I can't figure out how get my (Windows 8.1) guest to instantiate with a vmx flag on the vcpu (to be clear, I mean for nested virtualization; the host already has it enabled and working fine).

Are you loading kvm-intel with nested=1?

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

Duelist

Member

Registered: 2014-09-22

Posts: 358

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

How do you enable VT-x in the guest through virt-manager or virsh? I tried doing

host-passthrough

on the cpu, since the host supports it, but the vmx flag doesn't come through. I also tried passing a

<feature policy='force' name='vmx'>

argument in the cpu settings of the config using "virsh edit $vm" (along with other options to confirm it works), and some of the other cpu flags do pop as expected, but vmx does not.

I don't know about intel, but on AMD we have

options kvm-amd npt=1 nested=0

module options.

[user@crossfire ~]$ modinfo kvm-intel
filename:       /lib/modules/4.0.4-202.fc21.x86_64/kernel/arch/x86/kvm/kvm-intel.ko.xz
license:        GPL
author:         Qumranet
alias:          cpu:type:x86,ven*fam*mod*:feature:*0085*
depends:        kvm
intree:         Y
vermagic:       4.0.4-202.fc21.x86_64 SMP mod_unload 
signer:         Fedora kernel signing key
sig_key:        EC:B8:61:B3:8D:2D:A2:6D:43:B0:15:C1:0B:16:34:C7:33:4F:DD:D3
sig_hashalgo:   sha256
parm:           vpid:bool
parm:           flexpriority:bool
parm:           ept:bool
parm:           unrestricted_guest:bool
parm:           eptad:bool
parm:           emulate_invalid_guest_state:bool
parm:           vmm_exclusive:bool
parm:           fasteoi:bool
parm:           enable_apicv:bool
parm:           enable_shadow_vmcs:bool
parm:           nested:bool
parm:           pml:bool
parm:           ple_gap:int
parm:           ple_window:int
parm:           ple_window_grow:int
parm:           ple_window_shrink:int
parm:           ple_window_max:int

As you can see, you have a module option called nested too! ensure that you've enabled that.

@aw, you should put a notice somewhere on your blog saying that you're the one(almost?) who wrote vfio-pci, i have a feeling people massively miss that point.

---

The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.

Duelist

Member

Registered: 2014-09-22

Posts: 358

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Alright, this is getting awkward. Second-in-second. Dude. That's insane.

---

The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.

supplicant0x90

Member

Registered: 2015-06-10

Posts: 2

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

aw/Duelist:

Are you loading kvm-intel with nested=1?

No. I didn't see that anywhere. I'll research it from here and report back. Thank you!

Last edited by supplicant0x90 (2015-06-10 23:05:19)

dRaiser

Member

From: Poland

Registered: 2013-05-20

Posts: 51

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Thanks, aw and Duelist.

I couldn't utilize aw's wrapper as virsh edit shouts about wrong binary, so I've made simple check with qemu-commandline parameters (I know, it's ugly, but that was just to figure out..)

<qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=02:00.0,x-vga=on'/>
  </qemu:commandline>

I could launch machine with it, but no deal. Still black screen and windows doesn't even boot (I can't hear startup). So I assume x-vga doesn't actually help.

I was going to try OVMF as Duelist suggested, but it won't boot to my prepared earlier disk... Do I need to redo install if I want to use it? Sigh. If we can't find any other cure, I'll probably try with new OVMF install then...

--

One more patient test later: after few minutes of waiting Windows loads, I've got startup sound and *device connected* sounds, but no screen image. So near, so far...

--

Success! Worked when added also "multifunction" to qemu arg line. Tommorow I'll post whole xml again for future.

Last edited by dRaiser (2015-06-11 01:49:55)

aw

Member

Registered: 2013-10-04

Posts: 921

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Thanks, aw and Duelist.

I couldn't utilize aw's wrapper as virsh edit shouts about wrong binary, so I've made simple check with qemu-commandline parameters (I know, it's ugly, but that was just to figure out..)

<qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=02:00.0,x-vga=on'/>
  </qemu:commandline>

NNNNNNNNNNNOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!

EDIT: did you chmod the wrapper to make it executable?

Last edited by aw (2015-06-11 01:56:39)

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

dRaiser

Member

From: Poland

Registered: 2013-05-20

Posts: 51

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Thanks, aw and Duelist.

I couldn't utilize aw's wrapper as virsh edit shouts about wrong binary, so I've made simple check with qemu-commandline parameters (I know, it's ugly, but that was just to figure out..)

<qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=02:00.0,x-vga=on'/>
  </qemu:commandline>

NNNNNNNNNNNOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!

EDIT: did you chmod the wrapper to make it executable?

Sorry ...but it works...

Yes, I did chmod. I've also corrected path to qemu in its content (as it wasn't valid location for qemu on my system), I was able to run it by hand by console, but virsh validation couldn't accept it as correct binary. I'll post specific error later if you'd like.

DanaGoyette

Member

Registered: 2014-01-03

Posts: 46

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

I just got around to trying out the Hawaii bus reset patch -- it works wonderfully.  Huge thanks for getting that in!
Now I can finally do what I set out to do when building this system: consolidate multiple systems into one. 

I had to disable AppArmor in libvirt, though.  The AppArmor "helper" suddenly decided to act completely un-helpful.
It complained that it was "unable to load profile" ("no such file or directory"), without telling me WHAT "file or directory" it can't find. 
It also couldn't seem to comprehend the split images, and denied write access to the "vars" file.  (Right now, I'm back to using a single image.)

If you pass through a raw disk via virtio, do TRIM commands get passed through, as well?
I found an article about hole-punching via TRIM on virtio-scsi with file-backed drives, but I'd be using virtio and a raw disk.

For the moment, I'm giving the virtual machine the ASMedia SATA controller, and using a hack to make it bootable..
I have a small IDE boot partition with rEFInd installed, so rEFInd can load AHCI.efi (a driver packaged with the "XPC" bootloader).

Something else I've noticed: if I try to use my Xonar U7 (USB Audio Class 2.0) on the passed-through XHCI controller, the entire audio stack hangs after a while.
I have to unplug the sound card and plug it back in again.  For now, I'm passing through the onboard Realtek audio and using the USB sound card on the host.

Last edited by DanaGoyette (2015-06-11 03:37:49)

Nesousx

Member

Registered: 2012-03-27

Posts: 46

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Something else I've noticed: if I try to use my Xonar U7 (USB Audio Class 2.0) on the passed-through XHCI controller, the entire audio stack hangs after a while.
I have to unplug the sound card and plug it back in again.  For now, I'm passing through the onboard Realtek audio and using the USB sound card on the host.

Hi,

Just so you know I had issues for months with the Xonar U7. IIRC I also had issues with this card I posted about in this thread, but can't really remember what. Finally, the "clicking" noise of the U7 when you plug / unplug it made me crazy.

I sold it and bought a cheap USB card, everything works as expected. A part from the fact that I have to "lock" the USB card in the host.. but this is udev related as far as understand it, and will happen with any USB card.

Edit : page 138, post #3437. Now I remember my issue. Sometimes, totally randomly the sound will stutter and make everything lags for a 1 sec or 2 when the card was used via USB. Then when I emulated the audio while using USB on host I always had a very small delay before sounds occurs. This delay didn't exist when I emulated sound via the onboard (or others USB) cards.

Last edited by Nesousx (2015-06-11 09:00:47)

mqddb

Member

Registered: 2015-04-24

Posts: 5

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Dear ALL:
     intel IGD is not supported YET. But, I asked software engineer of KVMGT project, they say intel IGD can be passthrough to VM. I want know why intel IGD can't supported, Is this problem can be fix?

aw

Member

Registered: 2013-10-04

Posts: 921

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Dear ALL:
     intel IGD is not supported YET. But, I asked software engineer of KVMGT project, they say intel IGD can be passthrough to VM. I want know why intel IGD can't supported, Is this problem can be fix?

You can assign it, but it won't work until Intel releases a driver that doesn't depend on passing through random op-regions, registers on other devices, and modifying device IDs on other components in the VM.  IGD is not confined to the device at 00:02.0, it's smeared across the chipset.  Ask them when that driver is coming.  Even then, I believe the current plan requires some modifications to the guest BIOS.  It's also not clear if that driver will require VGA access and therefore permanently lock VGA arbitration for the rest of the system or support UEFI.  Even if it were to support UEFI, I don't think current Intel IGD hardware can fully disable claiming VGA transactions without disabling parts of the device, which might still require permanently locking arbitration for the duration of the VM.

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users