Re: [Xen-users] VGA passthru troubleshooting

[Casey DeLorme <cdelorme@xxxxxxxxx>]

Chris,

I do not know if the late-binding method performs an ejection, but your logic is sound.  To my knowledge the ejection process is more specific to Windows and not Linux systems, but late ejection is different than a system reboot.

In either case, you should be able to use the safely remove hardware option in Windows to manually reset the card after Windows has loaded.  However this has to be done before you install or remove any drivers or open 3D applications.

If the driver already installed and is crashing, you may have to reinstall Windows.  I could post another two pages worth of case-study results in my attempts to fix BSoD's from failed installs, but trust me when I say a reinstallation is faster.

The diagram I made was only to depict Windows instances, as I have not even gotten passthrough working on Linux (currently at "mountall: disconnected from plymouth").  However, from what others have posted Linux performs an FLR and properly resets the card.

To my limited understanding FLR or Function Level Reset, is the virtual machine implementation for reseting physical devices, which makes sense since a virtual machine does not change the power-state of devices like a physical reboot would.

With Windows I see two possibilities.  One is that Windows is issuing an FLR at boot time, but because the device is passed as a secondary graphics card it is not attached when the event is issued.  It is equally possible that Windows does not issue an FLR, Microsoft doesn't exactly advocate running their OS as a virtual machine do they?

My speculations could be wildly inaccurate, but given the test results it is logically sound.  I encountered a 100% failure rate with driver installation, removal, and 3D applications if the card had already been used once prior to the current system boot.  Success during first-use of the card, and also when using Tobias Geiger's suggestion of the safely eject device feature.

If you get your Linux DomU working I wouldn't mind your notes on the process.

~Casey

On Sun, Jun 24, 2012 at 8:43 AM, Chris <kavefish@xxxxxxxxx> wrote:

On 6/23/12 8:28 PM, Casey DeLorme wrote:
> When you pass the card to a DomU, the card is initialized.  However,
> Windows does not reset the card.  So after that DomU is shutdown the
> card remains initialized.
>
> When a Windows 7 DomU boots if the card is already in an initialized
> state, and driver installation, removal, and 3D applications will fail.

That's interesting. If I understand, the passed gfx device must be reset
before being passed to any domU.

What you described leads me to conclude that one of the configuration
options (that I'm using) described on the Xen.org wiki may be broken.

In my case the dom0 pciback driver is built as a module, so I can't hide
the gfx device from dom0 at boot with xen-pciback.hide.  I'm using the
late binding approach, which means dom0 binds a driver to the device
(e.g. radeon), which I assume has the consequence of initializing the
card. Then I manually unbind the dom0 driver and assign the device to
pciback. Whether the card is reset during unbind is unclear, but I'd
guess not. So, a physical machine reboot currently wouldn't prevent the
gfx device from being initialized before being passed to a domU. (Is
anyone using the late binding approach with a gfx device successfully?)

The alternative I should try is to use modprobe.conf to blacklist the
radeon driver, so only pciback ever binds to the card. I'll give that a
try next. (Is anyone using the modprobe.conf approach with gfx
pass-through successfully?)

Though one thing about your theory is bugging me. My Linux domU was
repeatedly able to drive the gfx device without any physical machine
reboots. It had no 2D or 3D acceleration and - perhaps more importantly
- no driver was obviously bound to the device.

In any case, I'll give the modprobe.conf approach a try. If that fails
I'll rebuild the kernel to include pciback. (I'd be curious if there's
anyone out there with gfx pass-through working with pciback as a module.)

Cheers,
Chris

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