[Xen-devel] Xen 4.3 Release VGA Passthrough Questions

[Casey DeLorme <cdelorme@xxxxxxxxx>]

Hello xen-devel,

I was hoping to ask some VGA passthrough questions with regards to the 4.3 release, and going forward. ÂI love Xen, and want to help iron out the problems in relation to passthrough. ÂI am very impressed with the performance of upstream qemu, especially network management.

I use Debian as my Dom0, as it is the linux distro I am most familiar with. ÂMy key hardware includes an Intel Core i7 3770 IvyBridge CPU, ASRock Z77 Extreme9 Motherboard, and an AMD Radeon HD 6870 GPU. ÂMy system has 32GB of RAM and I have been running an average of 4 virtual machines at a time when I was using Xen 4.2.

The problems I would like to address area:

- RAM Limitations /w Upstream Qemu

- Performance Degredation

- Primary Passthrough

Upstream Qemu and VGA Passthrough limits my supplied RAM. ÂIn my case supplying anything more than 3584MB and the machine boots but the graphics card is not used (but does exist). ÂI tried applying a patch that was sent around the xen-users list, but with that patch my Windows HVM (even without any changes to RAM) goes to an infinite boot screen in windows (as seen through sdl or vnc).

While I am able to overcome these limitations by switching to qemu traditional, I have other problems that occassionally kill my network when I hit heavy traffic. ÂThese may be related to GPLPV and not Xen, but attempting to re-enable the adpater fails, the adapter disappears from the system, and my only option is to reboot. ÂDisabling the adapter with upstream and GPLPV has the same issue, but I have not encountered the same problem with the network adapter crashing under load.

The performance degradation problem exists in both upstream and traditional, and may have nothing to do with Xen. ÂI don't expect the devels to solve this, but it would be nice if they could share some knowledge since my understanding of linux is likely vastly inferior.

A change with upstream is ejecting the card in Windows does not automatically re-attach, in fact it disappears from the DomU. ÂThe degredation is gone when I reboot, so I can do these before rebooting instead of after like with traditional, but the difference is worth noting.

Ideally I want to find a way to reset the card from Dom0, and thus far I have tried several things in sysfs unsuccessfully. ÂIf anyone has suggestions I would be glad to try them.

Finally, I tried primary passthrough as suggested on the xen-users list. ÂAfter a bit of struggling trying to apply the patch (due to stubdom not building) I ended up with this process:

  make world

  cd tools

  make clean

  cd ..

  cat ../xen-* | patch -p1

  make dist-tools

  fakeroot sh ./tools/misc/mkdeb /home/cdelorme/git/xen 4.3.0

The patch applied and I was able to use a .deb for easy install and removal. ÂI don't know if there is a solution to the lack of a sys/io.h in stubdom, but any suggestions are welcomed.

I can boot machines the same as I used to prior to this patch, both traditional and upstream appear to work normally. ÂHowever, the degradation still occurs, and primary passthrough fails. ÂFrom what I can tell the vCPU's never even spin up.

I have created a pastebin with my windows config, the output of xl -vvv create, the qemu log, and the xl list showing 1 vcpu of the 4 supplied:

http://pastebin.com/YmqkY8qS

I hope that I can be of use going forward, and that someone in the devel list has some ideas for me to try out.

Thanks for your time,

~Casey

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