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

Re: [Xen-users] PCI Passthrough, Radeon 7950 and Windows 7 64-bit


I am fairly certain you are experiencing the second-boot degradation, probably combined with a half-working driver installation.

I will try to explain it but the topic is fairly complex and difficult to comprehend without a solid understanding of what is happening.

I have attached a flowchart as a visual aid to depict the problem.

When Xen, the physical machine, boots the card is passed and the state remains "uninitialized". ÂIf the card were to be initialized normally, rebooting the physical machine would reset the state due to a change in power supplied to the card.

So the question to ask is how does a virtual machine reset physical hardware? ÂTobias Geiger wrote up an email on the subject of FLR (Function Level Reset), which I believe is the virtual machine solution to resetting device state.

Windows fails to issue an FLR to passed GPU's.

The first pass to Windows works great because it is the first time the card is "initialized", but Windows does not reset the device when you shutdown or restart it.

With me so far?

His email chains also suggested a solution, which was to use the safely remove hardware menu when the system has started back up, this restores the state of the card (your monitor will go black for a few seconds as the card resets).

However, now you are stuck at the crossroads because you can't get to the second restart due to a BlueScreen.

I would be almost certain that you are receiving a bluescreen because the driver installation was run on a second boot previously, where the card state had been initialized during a previous boot of the system.

This "first boot" is still under investigation, I believe it initializes if you pass it to another VM, or if you pass it during the installation process, but I haven't spent the time to verify this.

Most people will boot into safe mode and remove the drivers via VNC Console, but if you do this during a second boot without resetting the card first, you will end up with leftover .NET data that prevents ATI Driver Installation AND cannot be removed, meaning you would need to reinstall Windows.

So, my suggestion to you is to reboot the physical system, boot Windows and remove the drivers. ÂReboot the physical system a second time to be sure, and install the drivers again during first boot of Windows.

Then give it another spin.

If this did not make sense, please let me know where I lost you and I will try to explain it better.


On Mon, Jun 25, 2012 at 11:32 AM, Radoslaw Szkodzinski <astralstorm@xxxxxxxxx> wrote:
On Mon, Jun 25, 2012 at 5:21 PM, Matthias
<matthias.kannenberg@xxxxxxxxxxxxxx> wrote:
> Maybe you should give xm a try just to see if it does the trick. I
> never got vga passthrough working with xl (and from my understanding,
> it's a lot mor complicated there with compiling the vga bios into xen
> and manual calculating vga adress ranges.. with xm, I'm doing neither
> of it).

Why? I'm not using the VGA Passthrough, The card is set up as a secondary.
That shouldn't need any VGA BIOS. Also, it works fine for the first
boot very well!

The problem occurs on the second start of the same VM.

> Also, do you increase the log level for xen? my kernel line is:
> multiboot /boot/xen.gz dom0_mem=2048M iommu=1 loglvl=all guest_loglvl=all

Will do. (except dom0_mem)

> What kernel are you using? If you want i can provide my build commands
> for the xen-patched openSuse Kernel..

I don't want to use the XenLinux kernel. PVOps only please.
Unless the Xen kernel is actually Pvops-based, in which case why would
I want to use OpenSUSE one instead of vanilla?

As I've mentioned, vanilla 3.4.1.

RadosÅaw SzkodziÅski

Xen-users mailing list

Attachment: Diagrams.pdf
Description: Adobe PDF document

Xen-users mailing list



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