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

[Casey DeLorme <cdelorme@xxxxxxxxx>]

If you are passing the card to xen-pciback then Dom0 has nothing to do with the device. ÂShort of physically resetting the device via power-cycling the physical system, then yes that is exactly what I am implying.

Please understand, I only ran tests with Windows, I have yet to setup passthrough with Linux or Unix, so the results may vary if you are using aa DomU with a different operating system.

To my understanding Xen does not inform the card that it needs to reset, I am pretty sure it was remarked in the aforementioned email chain that this is the responsibility of the DomU. ÂI can only hazard a guess as to why, either it isn't sending one because Windows isn't exactly advocating running their system as a Virtual Machine, OR because we are using secondary passthrough the card is not available at early boot time, and perhaps that is when Windows is issuing a reset. ÂAgain, no facts supporting either of those, only wild speculation.

I don't think IRQ is relative but I could be wrong. ÂTo my understanding IRQ gives the OS a way to send signals to the card, it doesn't tell the OS what signals to send to the card, which would mean the OS chooses whether to send the reset signal.

If the card is passed using xen-pciback then Dom0 never bothers the device. ÂWith late binding this may be an entirely different story. ÂI have yet to hear of a Windows Dom0, so again not something my tests can yield conclusions on. ÂHowever, to my understanding Dom0 is tied to Xen, I haven't heard of anyone restarting Dom0 without rebooting the physical machine, and going back to our original logic, resetting the machine changes the power which physically resets devices attached to the machine (this would include devices sent to xen-pciback).

Another speculation of mine is that the reason behind the performance drop is at second initialization the card has been told to serve two owners, which throws a wrench into its operations.

I am no expert, I am only supplying my attempt at drawing a logical conclusion from the problem and my tests. ÂI could supply the exact same flowchart without terms like FLR and device State, and it wouldn't change as the process and logic remain the same.

Let me know if that helps clear things up any.

On Mon, Jun 25, 2012 at 7:29 PM, Matthias <matthias.kannenberg@xxxxxxxxxxxxxx> wrote:

Interesting explanation, but wouldn't that imply that the domU is the
only thing responsible for resetting the graphic card?
I'm asking because I can simply kill my domU via xm destroy and still
be able to boot the domU just fine afterwards (actually, this was an
issue up till 3 or so month ago but then was fixed in one of the
change sets in the testing repo).

i actually remember an IRQ warning after killing the domU,but xen can
recover this, so if i understand your explanation correctly, there
have to be a mechanism within the dom0 to reset pci devices, too..

2012/6/26 Casey DeLorme <cdelorme@xxxxxxxxx>:

> Hello,
>
> 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.
>
> ~Casey
>
> 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
>> 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