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

[Gordan Bobic <gordan@xxxxxxxxxx>]

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
> 7.9.
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
>
> (https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-pci)](https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-pci
> [3])
>
> 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
> driver
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. :(

Gordan

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