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

[Matthias <matthias.kannenberg@xxxxxxxxxxxxxx>]

Hi,

sorry if i was unclear: I will test this tomorow, but i'm pretty sure
i can kill my windows 7 domU (has vga, usb controller and onboard
sound via pciback) via xm and afterwards booting it just fine again
with everything working like normal (also possible with linux domUs)..

It might be right that the dom0 can't actually use the hidden pci
devices, but I think that at least the xen itself has some abilities
to control it (hence for example listing the assignable devices via xm
in my opinion indicates an awareness).

But again, these are just my two cents on your theory.. i will test
this tomorrow with my setup..


2012/6/26 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