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

[Xen-devel] Re: VGA passthrough on unstable

  • To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
  • From: Liwei <xieliwei@xxxxxxxxx>
  • Date: Tue, 24 May 2011 23:35:25 +0800
  • Cc: Gennady Marchenko <gennady.marchenko@xxxxxxxxx>
  • Delivery-date: Tue, 24 May 2011 08:39:52 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; b=juweX3x306aD8+pbHzdqMhtBJvrRuKyaT5DFrwwhNP66gIB1D2Ff1sszly55Gkq7Ya pbSUmpcRqrL2C+HomHdjdmvc6NnFTPOtkhs7lap8cazLj6AO5nZK7kEzJvRedBJQrnYY mxeymXxNKh/RINCV3vG2ldh9ep9Po4eBtCLGw=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Hello all,
    I've made some progress after manually editing dsdt.asl to reserve
my card's memory ranges based on lspci, and fixing a bug in the
previous patch where a pair of braces were missing causing the wrong
video BIOS to be loaded. The fixed patch is attached. Do take note
that I've also removed the changes for secondary card passthrough.
    With those changes I am able to boot into Windows with the driver
installed (Fresh install with gfx_passthrough = 0). Logging in using
remote desktop, I can see that the driver is active. I also see that
screen spanning is active as I can move my mouse pointer between both
monitors. Everything looks good - until I tried to physically login.
    First two tries:
        The login screen disappears, leaving both screens black with
my cursor free to move around. After a few seconds, the whole system
(Dom0 + DomU) locks up. The reset button didn't work as normal;
usually pressing it will immediately reboot the PC, but this time it
had no response for a few seconds, then it shut down, and almost
immediately started again, returning back to normal. Weird.
        The logs from qemu and syslog didn't show anything special
happening before and up to the lockup. xl dmesg didn't throw up
anything interesting before the lockup either, though that was viewed
through a script that repeatedly calls xl dmesg over a ssh connection.

    After that, I tried to compare the memory ranges from Device
Manager to the ranges specified in dsdt.asl. Matches. But I also
noticed the original PCI memory reserve overlapped with the range of
the card. Not sure whether that was bad, but I pushed the range back
anyways and tried again.
    Third and subsequent tries:
        After logging in, but before the login screen disappears, the
DomU reboots. I didn't see any BSOD flash by but a minidump appears.
Analysing it gives me the following:
        VIDEO_TDR_FAILURE (116)
        Attempt to reset the display driver and recover from timeout failed.
        Arg1: fffffa8003bdb010, Optional pointer to internal TDR recovery
        Arg2: fffff8800f204520, The pointer into responsible device driver
module (e.g. owner tag).
        Arg3: 0000000000000000, Optional error code (NTSTATUS) of the last
failed operation.
        Arg4: 0000000000000002, Optional internal context dependent data.
        Also I noticed that if the display goes into suspend, it never
comes back. I'm still able to do stuff over remote desktop though.

    Sometimes I get the following minidump too, even in a remote
desktop session:
        USB Driver bugcheck, first parameter is USB bugcheck code.
        Arg1: 0000000000000008, USBBUGCODE_RESERVED_USBHUB
        Arg2: 0000000000000006, USBHUB_TRAP_FATAL_TIMEOUT
        Arg3: 0000000000000006, TimeoutCode: Timeout_PCE_Disable_Action -
PortData->PortChangeListDone - Timeout trying to set Disable bit
        Arg4: fffffa8003434000, TimeoutContext - PortData

    Also, if I give the DomU more than about 3GB of memory, windows
fails to boot with the non ACPI compliant BIOS BSOD. Also, windows
installer doesn't get past the "Starting Windows" part, the pulsating
logo also never appears.

    I'm basically learning what every part of the code I'm messing
with does as I go on, but this is really way too complex for one
person to go through in a reasonable timeframe. So most of the changes
I've made are pretty bruteforce-y. I'd really appreciate someone
giving me a hand in this.

    Also attached are dmesg and qemu logs.


Attachment: vga-pt-xen42-xieliwei-v3.patch
Description: Binary data

Attachment: qemu-dm-W7Test.log
Description: Binary data

Attachment: dmesg.log
Description: Binary data

Xen-devel mailing list



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