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

[Matthias <matthias.kannenberg@xxxxxxxxxxxxxx>]

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