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

Re: [Xen-users] Xen 4.3 Passthrough Problems & Documentation

On Sun, 14 Jul 2013 17:58:46 -0400, Casey DeLorme <cdelorme@xxxxxxxxx> wrote:

- Upstream qemu fails to load virtual machines with VGA passthrough
and a large amount of memory (3600MB+ in my case breaks the DomU).

I may be wrong, but my understanding is that the PCI passthrough
related BAR memory patch was for qemu-traditional, not upstream.

- Does anyone know exactly what Windows device ejection does to the
hardware, or how we can do the same from Linux (such as Dom0)?

I suspect it does "whatever the driver does", rather than something
defined by a standard of some sort.

FWIW, ejecting a device only ever even succeeded for me on Win7.
If I try to eject a GPU in XP, it refuses to do so because the
"device is busy".

**A note on GPLPV:**

Using the latest GPLPV, and so far it works excellent. ÂTo be honest
I don't notice a different with regards to disk IO, solid state is
already fast, but the Windows Experience index jumps from a 6.6 to a

Really? I found the difference is _enormous_. Booting domU takes
seconds rather than minutes, and running any kind of anti-virus
grinds the machine to a halt without PV disk drivers.

Testing sysfs reset:

Modern linux kernel sysfs comes with reset files that can be used to
reset (some) PCI devices manually:

- [Kernel Docs


I decided to give this a try to see if it would allow me to reset the
adapter from within Linux, where I could then tie a script to automate
the reset process when a DomU is rebooted.

The planned scenario:

- Windows boots and initializes the graphics card
- I shut down windows and the card remains initialized
- I reset the graphics card state by:
 Â Â - Unbinding from pciback
  - issuing a reset
  - rebinding it
- Booting windows should initialize a fresh card

I think you'll find this process is entirely at the mercy of
what the driver does in domU. Quadro drivers seem to handle
this very gracefully.

Primary passthrough might work better because it re-executes
the BIOS which may well get the card to a clean state, but
I am purely guessing since I have given up on ATI cards
some time ago for number of reasons.

- I am to believe that Windows ejection is probably working because it
is using AMD drivers.

Ejecting a Quadro card on Win7 "worked" for me, but I never
actually saw any benefit from doing so with Quadro cards
since they work fine after a domU reboot anyway.

- The reset in Linux fails when it has no drivers so the reset
probably triggers a driver operation

You have a reset option under /sys/ when the driver is loaded?
I've never seen that. I thought it was specifically related
to FLreset PCI level functionality.

- The driver operation probably fails because it is not tied to an AMD

And you have definitely confirmed that it does something (or even
exists) when the fglrx driver is claiming the device?

Another option I have not yet tested would be loading the radon driver
to bind and unbind it before adding it back to pciback, which may
cause the proper reset chain to occur. ÂI didn't see it in the
drivers list though and wouldn't know where to begin loading it
without causing problems.

Well, you can modprobe fglrx and see if/what it breaks. :)

If anyone knows how to cause a D0>D3>D0 power change to a device
through sysfs let me know because I would like to try that next.

Hmm... Abusing power management - I like the idea. :)
It is not likely to work if the card takes auxiliary power
input, though. :(


Xen-users mailing list



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