>
> 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
>
>
