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

[jocelyn falempe <jocelyn.falempe@xxxxxxx>]

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 :
http://kdj0c.wordpress.com/2013/02/12/xen-pci-passthrough/

and another source :
http://gro.solexiv.de/2012/08/pci-passthrough-howto/

--

Jocelyn

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
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users