[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] PCI/VGA passthrough: differences between Xen and ESXi?

if you have 2 graphics cards, I would suggest to use PCI passthrough instead of VGA passthrough. no patches needed, you can start/stop the VM when you want. you can even play 3D game at the same time on the Dom0 and the DomU.

you can find more details on the setup on my blog :

and another source :



On 04/03/2013 06:01 PM, Eric Shelton wrote:
1) I applied the patch to 4.3 unstable (back in February).  I recall
it applying cleanly (thanks to Dr. Wettstein's work in updating the
original patches).  However, there is a build issue when the patched
files are used to build minios, as its libraries do not provide
iopl().  On my initial pass, I may have #ifdef-ed out the iopl() calls
during minios build time, on the presumption that this code path is
not exercised by minios.  However, not being fully confident in that
presumption, in some later work I  identified a more appropriate
mechanism: an existing hypervisor call for iopl.  I think revised code
was written, but remains untested.

2) I am using what I saw as the core aspects of that script:
unbind_devices(), re-enabling the devices, and the use of vbetool to
reinitialize the display (which returns the text console in my case).
Although I am doing passthrough of a USB3 controller as well, I did
not bother with rebinding the USB driver, as I simply surrendered use
of those ports for Windows.  I also am not waiting for the VM to exit;
instead, I split it the single script into before and after scripts
that were manually invoked.

I think the runtime unbind, bind, and vbetool, versus giving the PCI
devices over to pciback at boot time, makes a difference in terms of
whether you can stop & restart the passthrough VM.  With this config,
it is no problem for me.  I heard many reports of people starting up
the Windows VM once, but not again without a reboot.

3+) Tonight I can pull together what I am using and post it up here.
Very little modification of Dr. Wettstein's patch was done.  However,
at this stage, it seems to be the little things that make the
difference between GPU passthrough working or not.

My understanding is that there are many intentional quirks in GPUs to
be in compliance with certain HDCP requirements.  Unfortunately, I
think the universe of possible secret register access sequences, etc.
will make it impossible, even with 1:1 mapping in addition, to 100%
convince the display driver, which would be needed to get to
virtualized HDCP compliance (I am interested in a virtualized HTPC
environment).  It sounds like, from what I have heard of your work,
that NVidia's quirks are especially difficult to deal with (not
necessarily intentionally).  It was enough to make me abandon by
existing NVidia GPU in favor of an AMD solution.

Also, as I think I noted in an earlier post, one of the qemu
developers has, perhaps independently, implemented the necessary
quirks for AMD cards.  His code effects pretty much the same things as
the patch I used.  I think there is at least a patch against mainline
qemu in qemu-devel, if it has not been incorporated already.  He has
also been doing a fair amount of PCIe work, which I think may be
important for NVidia, assuming their use of extended config space is
causing some of the difficulties.

It would be nice to see enough code get into Xen 4.3 to get AMD cards
working, but with the switch away from qemu-traditional, which is what
the patch is for, this may now be more reliant on the work already
being done in qemu-devel being mainlined into qemu.

- Eric

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.