Xen VGA Passthrough Tested Adapters: Difference between revisions

From Xen
Jump to navigationJump to search
m (Reformat to activate link)
 
(12 intermediate revisions by the same user not shown)
Line 35: Line 35:
</pre>
</pre>


* Intel HD Graphics 4600 IGD (Haswell i5-4590S CPU)
* Intel HD Graphics 4600 Integrated Graphics Device (IGD) (on a Haswell i5-4590S CPU)
ASRock B85M-Pro4 motherboard, Primary adapter, also passed through the onboard PCI sound card and PCI USB 3.0 controller.
ASRock B85M-Pro4 motherboard, Primary adapter (gfx_passthru = 1), also passed through the onboard PCI sound card and PCI USB 3.0 controller.
ASRock Version 2.50 of BIOS (earlier versions also worked, beta version 2.60 with updated CPU microcode not tested).
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
Working (In all cases reported here, the bios setting in the domain configuration file is unset or set to seabios):
Working:
Xen 4.4.x, Headless Debian jessie Dom0 with qemu traditional device model, and the default Debian jessie 3.16.x kernel. (Note that Debian does not provide either the traditional device model or hvmloader with rombios support, so qemu-dm and hvmloader with rombios support binaries must be built from source for Debian or these two binaries could probably be extracted from compatible Ubuntu Xen packages and added as device model and bios overrides in xl.cfg).
Xen 4.4.x, Headless Debian jessie Dom0 with qemu traditional device model, and the default Debian jessie 3.16.x kernel. (Note that Debian does not provide either the traditional device model or hvmloader with rombios support, so qemu-dm and hvmloader with rombios support binaries must be built from source for Debian or these two binaries could probably be extracted from compatible Ubuntu Xen packages and added as device model and bios overrides in xl.cfg, qemu-dm was built from the qemu-xen-traditional.git repository at xenbits.xen.org).
Xen 4.11.x Headless Debian buster Dom0 with either qemu traditional or Debian's Qemu 3.1 package as the upstream qemu-xen device model, and the default Debian buster 4.19.x kernel.
Xen 4.11.x Headless Debian buster Dom0 with either qemu traditional or Debian's Qemu 3.1 package as the upstream qemu-xen device model, and the default Debian buster 4.19.x kernel.
Xen 4.14.x Headless Debian bullseye Dom0 with Debian's Qemu 5.2 package as the upstream qemu-xen device model, and the default Debian bullseye 5.10.x kernel.
Xen 4.16.x Headless Debian unstable Dom0 with Debian's Qemu 7.0 package as the upstream qemu-xen device model, and the default Debian unstable 5.16.x kernel. With Linux kernel 5.17 and greater, Dom0 does not boot on some older Intel hardware due to an unpatched regression in the Linux kernel. A [https://lore.kernel.org/lkml/9385fa60-fa5d-f559-a137-6608408f88b0@suse.com/ patch] for the Linux kernel is available for this problem and it is now fixed in Linux 5.19.6 and higher.
PCI slot 2 problem (this problem only applies to Qemu upstream, Qemu traditional does not have this problem):
In some cases, VGA passthrough of the Intel IGD does not work without a [https://lists.xenproject.org/archives/html/xen-devel/2022-10/msg01820.html patch to reserve PCI slot 2 for the Intel IGD] that has been proposed to Qemu upstream that hopefully will make it into a later version of Qemu. If VGA passthrough of the Intel IGD does not work, try the patch to Qemu upstream (backports of the patch all the way back to Qemu 5.2 for Debian 11 bullseye have been tested), and the patch does fix the problem. The exact conditions that trigger the need for the patch have not been identified, but it seems related to whether or not seabios tries to load the legacy VGA bios, and if it does, it expects the Intel IGD to be at PCI slot 2. It is possible to workaround the problem by patching (or in some cases not patching) seabios to prevent seabios from loading the VGA bios instead of applying the patch to upstream Qemu that reserves PCI slot 2 for the Intel IGD.
Not Working:
Not Working:
Line 48: Line 57:
With the aforementioned patch applied to the Debian stretch Xen 4.8 hypervisor package, it worked with the qemu traditional device model.
With the aforementioned patch applied to the Debian stretch Xen 4.8 hypervisor package, it worked with the qemu traditional device model.
In all the configurations with Debian listed above, Windows 7/8/8.1/10 x86/x64 DomUs all work well on the HDMI output with the Intel drivers provided by ASRock.
In all the configurations with Debian listed above, Windows 7/8/8.1/10 x86/x64 HVM guest DomUs all work well on the HDMI output with the Intel drivers provided by ASRock provided that the aforementioned patch to Qemu upstream to reserve PCI slot 2 for the Intel IGD is applied. Qemu traditional has a patch that reserves slot 2 for the Intel IGD so Qemu traditional can be used as a workaround until the patch is applied to Qemu upstream.
Debian Linux DomUs did not always work - worked with Debian jessie Dom0 and Debian jessie DomU and the traditional device model on the HDMI output and worked with a Debian buster Dom0 with the traditional device model and Debian Linux DomUs, but only on the VGA output, not the HDMI output in the latter configuration. Does not work well with a Debian buster Dom0 (Xen 4.11), the upstream device model, and Debian Linux Domus, not even after trying many different tweaks to the configuration.
Debian Linux HVM guest DomUs did not always work - worked with Debian jessie Dom0 and Debian jessie DomU and the traditional device model on the HDMI output and worked with a Debian buster Dom0 with the traditional device model and Debian Linux DomUs, but only on the VGA output, not the HDMI output in the latter configuration. Does not work well with a Debian buster or bullseye Dom0 (Xen 4.11 or Xen 4.14), the upstream device model, and Debian Linux Domus, not even after trying many different tweaks to the configuration. The problem when using the upstream Qemu device model is that there was an unpatched bug in the upstream Qemu device model that prevented the guest from setting up IRQs from the passed through devices. A [https://gitlab.com/qemu-project/qemu/-/commit/be9c61da9fc57eb7d293f380d0805ca6f46c2657 patch] has been committed to the master Qemu upstream branch and Qemu upstream version 7.1 and higher has the fix. The problem when using the traditional device model is that there is a missing hypercall that is needed to grant the Linux HVM guest permission to access the Intel OpRegion. A [https://lists.xenproject.org/archives/html/xen-devel/2022-03/msg01024.html patch] to fix this problem for the traditional Qemu device model is available on xen-devel but it will not be committed due to the fact that the old traditional Qemu device model is no longer recommended for modern versions of Xen.
For Xen 4.8 (with the critical patch applied) and Xen 4.11, the xl.cfg file needed the following setting for the PCI passthrough configuration:
For Xen 4.8 (with the critical patch applied) and Xen 4.11, the xl.cfg file needed the following setting for the PCI passthrough configuration:
rdm = "strategy=host,policy=relaxed"
rdm = "strategy=host,policy=relaxed"
For Xen 4.14 and Xen 4.16 the xl.cfg file needed the following settings for the PCI passthrough configuration to successfully pass through the USB 3.0 controller with the Intel IGD and integrated sound device:
With the Debian buster Dom0, the Xen 4.11 hypervisor command line options were:
# rdm = "strategy=host,policy=relaxed"
pci = [ '00:1b.0','00:14.0,rdm_policy=relaxed','00:02.0' ]
If the memory assigned to the guest is greater than around 3.5 GB (memory = '3584'), it might be necessary to increase the mmio_hole setting in the domain configuration file. The default is 256 MB, and increasing it to 512 MB enabled memory to be greater than 4 GB:
mmio_hole = '512'
With either the Debian buster, the Debian bullseye, or the Debian unstable Dom0, the Xen hypervisor command line options were:
dom0_mem=2G,max:2G smt=false pv-l1tf=false iommu=1 no-real-mode edd=off
dom0_mem=2G,max:2G smt=false pv-l1tf=false iommu=1 no-real-mode edd=off



Latest revision as of 20:02, 16 December 2022


Icon Info.png We only recently started collecting this information and rely on you to let us know how it works for you!


List of tested graphics adapters for Xen VGA Passthrough

Please send an email to xen-devel or xen-users with all the details about your VGA graphics passthru experience. If you are confident that your adaptor works, feel free to just add it to this page.

Please include the following details in the email:

  • Xen version
  • Dom0 kernel version, and if it's pvops or xenlinux based
  • "lspci" output for the graphics card to get the PCI IDs and model information
  • Did you passthru all the PCI IDs or just one?
  • Was it primary or secondary graphics adapter?
  • Motherboard vendor/model and BIOS version.
  • Guest OS and driver version.
  • How did it work.. did you have some issues?

Xen VGA graphics passthru has been tested to work with these graphics adapters:

Intel display adapters

User reported working adapters:

  • Intel 82Q35 Express IGC
Xen 4.0.0, OpenSuse 11.2 xenlinux 2.6.31.12-0.2 dom0 kernel. Dell Optiplex 755 desktop. 
Windows XP HVM guest, Dell provided Intel graphics driver. Primary adapter. Passthru for both PCI IDs. 

00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02) 
00:02.1 Display controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)
  • Intel HD Graphics 4600 Integrated Graphics Device (IGD) (on a Haswell i5-4590S CPU)
ASRock B85M-Pro4 motherboard, Primary adapter (gfx_passthru = 1), also passed through the onboard PCI sound card and PCI USB 3.0 controller.
ASRock Version 2.50 of BIOS (earlier versions also worked, beta version 2.60 with updated CPU microcode not tested).
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)

Working (In all cases reported here, the bios setting in the domain configuration file is unset or set to seabios):

Xen 4.4.x, Headless Debian jessie Dom0 with qemu traditional device model, and the default Debian jessie 3.16.x kernel. (Note that Debian does not provide either the traditional device model or hvmloader with rombios support, so qemu-dm and hvmloader with rombios support binaries must be built from source for Debian or these two binaries could probably be extracted from compatible Ubuntu Xen packages and added as device model and bios overrides in xl.cfg, qemu-dm was built from the qemu-xen-traditional.git repository at xenbits.xen.org).

Xen 4.11.x Headless Debian buster Dom0 with either qemu traditional or Debian's Qemu 3.1 package as the upstream qemu-xen device model, and the default Debian buster 4.19.x kernel.

Xen 4.14.x Headless Debian bullseye Dom0 with Debian's Qemu 5.2 package as the upstream qemu-xen device model, and the default Debian bullseye 5.10.x kernel. 

Xen 4.16.x Headless Debian unstable Dom0 with Debian's Qemu 7.0 package as the upstream qemu-xen device model, and the default Debian unstable 5.16.x kernel. With Linux kernel 5.17 and greater, Dom0 does not boot on some older Intel hardware due to an unpatched regression in the Linux kernel. A patch for the Linux kernel is available for this problem and it is now fixed in Linux 5.19.6 and higher.

PCI slot 2 problem (this problem only applies to Qemu upstream, Qemu traditional does not have this problem):
In some cases, VGA passthrough of the Intel IGD does not work without a patch to reserve PCI slot 2 for the Intel IGD that has been proposed to Qemu upstream that hopefully will make it into a later version of Qemu. If VGA passthrough of the Intel IGD does not work, try the patch to Qemu upstream (backports of the patch all the way back to Qemu 5.2 for Debian 11 bullseye have been tested), and the patch does fix the problem. The exact conditions that trigger the need for the patch have not been identified, but it seems related to whether or not seabios tries to load the legacy VGA bios, and if it does, it expects the Intel IGD to be at PCI slot 2. It is possible to workaround the problem by patching (or in some cases not patching) seabios to prevent seabios from loading the VGA bios instead of applying the patch to upstream Qemu that reserves PCI slot 2 for the Intel IGD.

Not Working:
Xen 4.8.x, Debian stretch Dom0, Debian stretch 4.9.x kernel. A critical patch to the hypervisor to support Intel IGD passthrough was needed for Xen 4.8 but never backported to the Xen 4.8 hypervisor: https://www.mail-archive.com/xen-devel@lists.xen.org/msg96096.html
With the aforementioned patch applied to the Debian stretch Xen 4.8 hypervisor package, it worked with the qemu traditional device model.

In all the configurations with Debian listed above, Windows 7/8/8.1/10 x86/x64 HVM guest DomUs all work well on the HDMI output with the Intel drivers provided by ASRock provided that the aforementioned patch to Qemu upstream to reserve PCI slot 2 for the Intel IGD is applied. Qemu traditional has a patch that reserves slot 2 for the Intel IGD so Qemu traditional can be used as a workaround until the patch is applied to Qemu upstream.

Debian Linux HVM guest DomUs did not always work - worked with Debian jessie Dom0 and Debian jessie DomU and the traditional device model on the HDMI output and worked with a Debian buster Dom0 with the traditional device model and Debian Linux DomUs, but only on the VGA output, not the HDMI output in the latter configuration. Does not work well with a Debian buster or bullseye Dom0 (Xen 4.11 or Xen 4.14), the upstream device model, and Debian Linux Domus, not even after trying many different tweaks to the configuration. The problem when using the upstream Qemu device model is that there was an unpatched bug in the upstream Qemu device model that prevented the guest from setting up IRQs from the passed through devices. A patch has been committed to the master Qemu upstream branch and Qemu upstream version 7.1 and higher has the fix. The problem when using the traditional device model is that there is a missing hypercall that is needed to grant the Linux HVM guest permission to access the Intel OpRegion. A patch to fix this problem for the traditional Qemu device model is available on xen-devel but it will not be committed due to the fact that the old traditional Qemu device model is no longer recommended for modern versions of Xen.

For Xen 4.8 (with the critical patch applied) and Xen 4.11, the xl.cfg file needed the following setting for the PCI passthrough configuration:
rdm = "strategy=host,policy=relaxed"

For Xen 4.14 and Xen 4.16 the xl.cfg file needed the following settings for the PCI passthrough configuration to successfully pass through the USB 3.0 controller with the Intel IGD and integrated sound device:
# rdm = "strategy=host,policy=relaxed"
pci = [ '00:1b.0','00:14.0,rdm_policy=relaxed','00:02.0' ]

If the memory assigned to the guest is greater than around 3.5 GB (memory = '3584'), it might be necessary to increase the mmio_hole setting in the domain configuration file. The default is 256 MB, and increasing it to 512 MB enabled memory to be greater than 4 GB:
mmio_hole = '512'

With either the Debian buster, the Debian bullseye, or the Debian unstable Dom0, the Xen hypervisor command line options were:
dom0_mem=2G,max:2G smt=false pv-l1tf=false iommu=1 no-real-mode edd=off

Nvidia display adapters

Note that Nvidia officially supports only Quadro FX 3800, 4800 and 5800 for graphics passthrough usage (they've tested and verified their binary drivers for these graphics cards in combination with graphics passthrough).

In addition, Nvidia lists the following graphics adapters as "Multi-OS" capable: Quadro 6000, 5000, 4000, 2000. "Multi-OS" allows VGA passthrough to fully virtualized guests. Note: The Nvidia Quadro 600 is not supported.

GeForce 7 Series (7xxx), 8 Series 8xxx), 400 Series and 600 Series should work as primary adapter after patching MMIO BARs of gfx for 1:1 mapping. But this work only with Windows XP DomU, and only with specific drivers version (Jean David Techer Blog [1]). Most "non-Multi-OS" capable adapter won't work this way with Windows Vista/7/8.

Some GeForce adapters with the same chipset as Quadro Multi-OS capable adapters can be modified into their Quadro/Grid counterparts, and subsequently work with passthrough in domU. Reports of successful passthrough with modified cards include:

  • GeForce GTX670/680/690 to Quadro GridK2 / K5000 (GK104) (Australian crazy guy [2]).
  • GeForce GTS450 to Quadro 2000 (GF106) (See here for details on how to modify a GeForce 4xx card into an equivalent Quadro)
  • GeForce GTX460 to Quadro 4000M (GF104)
  • GeForce GTX470 to Quadro 5000 (GF100)
  • GeForce GTX480 to Quadro 6000 (GF100)

User reported working adapters:

  • nVidia Quadro 2000, as secondary display adapter, Linux Mint 13 dom0, Xen 4.1.2, Windows 7 guest with Nvidia driver 305.93.
  • nVidia G92 (GeForce 8800 GTS 512), as primary adapter, Xen 4.0.0-rc8, pvops xen/stable-2.6.32.x dom0, Linux HVM guest with nv driver.
  • nVidia GTS450 modified into a Quadro 2000 (GF106), secondary passthrough, EL6, 4.2.x, 4.3.x, XP64 domU drivers ~295+
  • nVidia GTX460 modified into a Quadro 4000M (GF104), Windows 7 32-bit guest
  • nVidia GTS470 modified into a Quadro 5000 (GF100), secondary passthrough, EL6, 4.2.x, 4.3.x, XP64 domU drivers ~295+
  • nVidia GTS480 modified into a Quadro 6000 (GF100), secondary passthrough, EL6, 4.2.x, 4.3.x, XP64 domU drivers ~295+
  • nVidia GTX670, GTX680 modified into a Grid K2 or Quadro K5000 (GK104), secondary passthrough, EL6, 4.2.x, 4.3.x, XP64 domU drivers ~300+

domU reboots reportedly work seamlessly for most users of the Nvidia Fermi and Kepler GPUs listed above, both with genuine Quadros and GeForce cards modified into Quadros/Grids.

User reported _NOT_ working adapters:

  • nVidia Quadro NVS 295, Xen 4.2.1, Ubuntu 12.04 LTS dom0, xen-pciback.hide, Win Vista x64 HVM, either as primary or secondary adapter. As secondary adapter VM start, but windows stays with the SDL display. As primary adapter VM don't start, even after patching for identity memory I/O regions mapping and inserting VGA-rom in Xen 4.2.1.
  • nVidia GeForce GTX580 modified to Quadro 7000 (GF110) (Note: Quadro 7000 is not listed as MultiOS compatible)

ATI/AMD display adapters

AMD sent patch enabling VGA passthrough on AMD/ATI Radeon/FirePro graphics adapters on 2010-10-07: http://lists.xensource.com/archives/html/xen-devel/2010-10/msg00284.html .

Remember to install the graphics drivers in the DomU first, before expecting secondary passthrough to work.

Tested adapters by AMD:

User reported working adapters:

All Radeon HD4xxx, HD6xxx and HD7xxx should work out-of-the-box as secondary adapter with Xen 4.2.1

  • ATI ES1000, as primary adapter, Xen 4.2-unstable 25099, RedHat6.2 vmlinux-3.1.0-rc7 dom0, RedHat6.2 HVM guest.
  • AMD Radeon HD4550
  • AMD Radeon HD4770, Fedora 12 dom0, WinXP HVM, Win7 HVM
  • AMD Radeon HD4890, as secondary adapter, Xen 4.2.1, Ubuntu 12.04 LTS dom0, Win Vista x64 HVM (this card do _not_ support Function Level Reset)
  • AMD Radeon HD5750, Win7 32bit HVM (Catalyst 10-9)
  • AMD Radeon HD5770
  • AMD Radeon HD5850
  • AMD Radeon HD6450/HD7450, Xen 4.2.1, xm, EL6, dom0, Win7 64bit HVM domU
  • AMD Radeon HD6450, as secondary adapter, Xen 4.4.1, xl toolstack, Ubuntu 14.04 LTS dom0, Linux Kernel 3.16.1 in dom0, Windows 7 Ultimate 64-bit HVM domU, Windows 8.1 Enterprise 64-bit HVM domU, Catalyst Control Center Installed (reported by Teo En Ming)
  • AMD Radeon HD6570
  • AMD Radeon HD6770, Xen 4.1.2 and 4.1.3, pciback, WinXP HVM
  • AMD Radeon HD6850, WinXP HVM, Win7 HVM
  • AMD Radeon HD6870, Xen 4.2 (only with xl tools), Win7 64bit HVM
  • AMD Radeon HD6870, Xen 4.2 unstable 25167, Xen 4.1.2, 4.1.3, Debian Wheezy dom0 Kernel 3.3.2 and 3.3.0
  • AMD Radeon HD6950, Win7 64bit HVM
  • AMD Radeon HD6970, Win7 64bit HVM
  • AMD Radeon HD7750, as secondary adapter, Xen 4.1.3, Mint 14 (kernel 3.7) dom0, Windows 8 Pro HVM
  • AMD Radeon HD7770 as secondary adapter, Xen 4.2.1, Debian dom0 kernel 3.2.0, Debian (kernel 3.14) HVM, xm tools, qemu traditional
  • AMD Radeon HD7850 as secondary adapter, Xen 4.2.1, Debian dom0 kernel 3.2.0, Windows 7 Ultimate HVM, xm tools, qemu traditional
  • AMD Radeon HD7870
  • AMD Radeon HD7950, Xen 4.2 (pciback), Arch Linux 64bit (Catalyst 12.11) dom0, Win7 64bit HVM (Catalyst 12.10)
  • AMD Radeon HD7950 as secondary adapter, Xen 4.2 (xen modules built into kernel 3.8.1-201), Fedora 18 64bit dom0, Win7 64bit HVM (Catalyst 13.3 Beta * drivers only, catalyst not installed) --- [3] portuguese howto --- [4] youtube video --- [5] compiled and used kernel
  • AMD Radeon HD7970, Win7 HVM
  • AMD Radeon R9 200 family, Xen 4.2, Linux kernel 3.4.9 (reported by Kelly Zytaruk, AMD Engineer)
  • AMD Radeon R9 390, Xen 4.3.1, Linux kernel 3.12.1 (reported by Christopher Law, TA / Developer)

There are certain user-reports that the Catalyst Control Center (ccc.exe) should be _not_ installed when installing the Catalyst Driver - for unknown reasons it may cause a BSOD. The GPU Driver itself works without problems when not installing CCC.

There are widespread reports of ATI/AMD cards causing major problems when the domU is rebooted, including severely degraded performance, domU crashes and complete host dom0 crashes.

User reported _NOT_ working adapters:

  • ATI Radeon x1950, Xen 4.2.1, Ubuntu 12.04 LTS dom0, Win Vista x64 HVM, either as primary or secondary adapter.

Matrox display adapters

User reported working adapters:

  • MGA G200e
Xen 4.2-unstable changeset 25099, RedHat6.2 vmlinux-3.1.0-rc7 dom0 kernel. Intel Romley-EP, Integrated graphics. 
Windows8 Beta HVM guest, RedHat6.2 HVM guest Integrated graphics. Primary adapter. Passthru single PCI ID, hidden from dom0: xen-pciback.hide=(0a:00.0). 

0a:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 04)

Links

See XenVGAPassthrough wiki page for more information about Xen VGA graphics passthru in general.