This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: VGA passthrough on unstable

To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Re: VGA passthrough on unstable
From: Liwei <xieliwei@xxxxxxxxx>
Date: Tue, 24 May 2011 23:44:20 +0800
Delivery-date: Tue, 24 May 2011 08:52:00 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=5+tEkcC8un9OIl7yYRQ2aIeQkeeGHx+wbBtHV1ItljM=; b=gpEjaXcCS/FdDQOTuzHcQgT7eVrK+1S7OsSyHEB6HfwqgpTUSy95ry0LFiG/7CUrJ3 b3pJTPgH8ektOTzraM0ED3QRES33C/p4fh3meL+f899brx0un8nnru8m9BF1BFD+EJjo 84WNLOjsbcH3DnppG0LvmTW74BYHfAz/d1jgI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=f3PIcQ3GyA4GKasb60EkMz9c6SDtDSqA3LwqSCxixj3GL8mTHIE5jtZC5ZEpzSk7kG B5J2abFEQImq1EXdC6NUSMMZyv+5zHSdS39PN0Z9nZIQGPhAfzykApXRPc+A6m+6enER Eh7wvgmxgpLug0y/NkaykRDwnHTqeCzS80uAI=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BANLkTi=bbaAhhM3ATfdrodU1t=ThdFzxoA@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <BANLkTi=bbaAhhM3ATfdrodU1t=ThdFzxoA@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Oh, I forgot to mention that there was a kernel bugcheck logged after
the first two tries. See attached.

On 24 May 2011 23:35, Liwei <xieliwei@xxxxxxxxx> wrote:
> 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.
>        Arguments:
>        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:
>        BUGCODE_USB_DRIVER (fe)
>        USB Driver bugcheck, first parameter is USB bugcheck code.
>        Arguments:
>        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.
> Thanks

Attachment: messages.cat.log
Description: Binary data

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

Xen-devel mailing list