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

[Ricardo Jesus <ricardo.meb.jesus@xxxxxxxxx>]

Same here.

I have an AMD HD7850 powering a Windows 8 domU and an AMD HD5450
running a Debian Wheezy domU. The dom0 is Debian Wheezy with the
distribution's stock Xen 4.1.4, xm, pci_stub and no patches
whatsoever.

A while back I had a similar setup, this time with VGA Passthrough of
primary display adapter Intel HD4000. At the time I blogged the HowTo
at 
http://linux-bsd-sharing.blogspot.pt/2012/10/howto-xen-413-windows-8-hvm-domu-with.html.
The same principles apply to my current setup.

Best of luck,
Ricardo Jesus.


On Wed, Apr 3, 2013 at 8:39 PM, jocelyn falempe <jocelyn.falempe@xxxxxxx> wrote:
> 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

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users