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

Re: [Xen-users] ATI VGA Passthrough / Xen 4.2 / Linux 3.8.10



David, Gordan,

On May 9, 2013, at 12:10 PM, David Sutton <kantras@xxxxxxxxx> wrote:

Gordan,

  For reference, I went the 'Asus Sabertooth + AMD 8 core' route - ASUS Sabertooth 990FX (rev 1.0) and an AMD 8350. I've got a Radeon HD 6770 passed through as a secondary screen to a Windows 7 DomU (the primary card is currently a Radeon HD 7750, also used a Nvidia GTX 550 Ti). Its usually stable (unless I have to reboot it a lot) but i'm currently stuck at Xen 4.2.1 as the IVRS table is exporting bad information (it has an entry for one IO-APIC, with a handle of 0x0). This is using the xl toolset.

Regards,

  David

I can report a similar experience here.  To date, the best luck I've had with Passthrough is actually on a 990FX system with an 8 core CPU as well.  It ran Xen pretty well, but back when I did that, I always had issues with the xm toolstack throwing errors at me.  My current work with the xl stack has me thinking it'd smooth things out.  The box is running ESXi at the moment, but I guess the real point is that with ~12 passed-through devices (VGA, HDMI audio, and one USB controller each) it runs like a champ, and is so rock solid that, while I've had issues, I think they've actually all been related to lack of FLR support on the cards... But that's just speculation.  I have to do some weird vm shuffling to piss it off :P

-Andrew



On Thu, May 9, 2013 at 10:28 AM, Gordan Bobic <gordan@xxxxxxxxxx> wrote:
On Thu, 9 May 2013 14:20:20 +0000, Casey DeLorme <cdelorme@xxxxxxxxx> wrote:
Thanks for posting the results Gordan, unfortunate that it isn't
working as well as we hoped.

I haven't given up _quite_ yet.

I discovered yesterday that it _looks liks_ one of my PCIe slots is
actually duff (two different GPUs both fail to detect properly in it
but work fine in other slots).

If it turns out to be a duff slot, there's no telling what else
might be duff on the motherboard and how it might affect various
things, even though several days of full load stability testing
passed.

So some more bare-metal testing seems to be called for - right now I
am not prepared to disregard the possibility that maybe I have a
hardware issue somewhere that despite EDAC and ECC on everything,
remains undetected and unreported in the logs.


  2) My motherboard's PCIe slots are behind NF200 PCIe bridges (yes,
EVGA have decided in their infinite wisdom to put all 7 PCIe slots
behind NF200s, none are directly attached to the Intel NB).

 I'm so sorry :P. NF200 has probably caused a lot of xen tinkerers to
 utter a few dozen cuss words a piece.

 I can believe that. What is the solution, though?

 The thing that drives me really nuts about the issues I'm seeing
(which may or may not be specifically related to the NF200) is that it
is so intermittent. It works well enough to boot up and work with a
gaming type load for a few minutes. Then something happens that causes
the VGA card to require a reset, and it all falls apart.

My solution was to buy another motherboard, I had no luck at all
passing the devices behind the NF200, and similar to your situation
all but one PCIe slot on that board was behind that bridge.

Did you not manage to get it working at all? Or was it just
intermittent like in my case? I can typically get about 5 minutes of
gaming out of my ATI card before it all goes wrong.

Ironically, I was thinking about an Asus Sabertooth with an 8-core AMD,
but opted to go for broke and get a couple of 6-core Xeons and an
EVGA SR-2. It turns out, a solution that is 4x more expensive isn't
actually better... :(

  What about with PCIe devices behind NF200 bridges? I know the NF200s
don't support PCI ACS, but that is a security feature (which I have
disabled enforcement of to get this far), and AFAIK shouldn't actually
affect the basic PCI passthrough capability.

 Question: how'd you disable ACS?  I think it may be causing me some
issues.

 Put:

 (pci-passthrough-strict-check no)
 (pci-dev-assign-strict-check no)

 in /etc/xen/xend-config.sxp

 If it was causing you issues, however, I'd expect you to find errors
in logs pointing at it.

As I understand the xend-config.sxp [1] is for the xm toolstack and
deprecated Xend service.

xm toolstack and xend are what I am using. I have read reports of issues
with VGA passthrough using the xl stack so I didn't even attempt to use it.


Perhaps I am confused, or things changed while I wasn't looking, but
for me enabling Xend breaks the xl toolstack.  My understanding is it
was for the xm toolstack only and deprecated with 4.2.  Any chance
you can share how you configured it to work?  Apparently it is
required to get libvirt working, which I also did not know was
compatible with Xen 4.2.

It is possible I'm the one doing it wrong. I'm on EL6, and using
virt-manager (at least for things it is willing to do), and that
defaults to the xm stack and xend.

For what it's worth, it works for the most part - apart from VGA
passthrough crashing within 5 minutes of gaming.


Gordan

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

 


Rackspace

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