Re: [Xen-devel] Need help to debug win7 BSOD on IGD passthrough

["G.R." <firemeteor@xxxxxxxxxxxxxxxxxxxxx>]

Hi Ross,
Let's reuse this thread to discuss the win7 64bit BSOD issue in gfx
passthrough env.
I started this thread but later switched my focus to linux domU. It's
time to pick it up again.

Quoting your reply from the opregion patch thread:
>> Hmm, I found a similar issue with BSODs like this and I tacked it down to 
>> the Windows igfx drivers expecting to find vendor capabilities in the GMCH 
>> device (the root device at 00:00.0). It was actually looking there for 
>> capabilities specific to the gfx card. We fixed this by patching qemu to 
>> pass in the vendor capabilities on that device. I am not sure if that made 
>> it upstream - I will have to check.
>
> Great news to hear. It'll be great if you can locate that patch for me.
> I'm not sure which upstream you are referring to?
> I'm using the qemu-xen 4.2.1 version. I remember the upstream qemu
> does not support gfx-passthrough.

So here is the lspci -vvv -s 00:00.0 output from the dom0:
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
processor DRAM Controller (rev 09)
        Subsystem: ASRock Incorporation Device 0150
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ >SERR- <PERR- INTx-
        Latency: 0
        Capabilities: [e0] Vendor Specific Information: Len=0c <?>

And Linux domU:
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
processor DRAM Controller (rev 09)
        Subsystem: ASRock Incorporation Device 0150
        Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0

One notable difference is the 'Vendor Specific Information' line in
the host is missing in the domU.
Is it the fix you mention in your comment?

But the fix you mention seems to be igfx driver specific.
But I also observe BSOD without it -- I guess the system run with
basic VGA driver in that case.
Is it the expected behavior?

One more question: does the windows igfx passthrough rely on 1:1
mapping of MMIO bars?
According to tutorials, nvidia cards require such trick.
But it seems that igfx linux driver does not require this -- the lspci
output shows different memory region on dom0 vs domU.

Is there any info you are interested?

Thanks,
Timothy

On Tue, Dec 11, 2012 at 5:26 PM, G.R. <firemeteor@xxxxxxxxxxxxxxxxxxxxx> wrote:
> Hi guys,
> I met win7 vga passthrough problem and would like to analysis the memory
> dump to identify the issues. Could anybody lend me a hand when I'm in
> trouble?
>
> Some details below and would post follow up later.
> Any suggestion on the triage / experiment direction would be appreciated.
>
> I have a working build for passing through intel HD4000 to a debian domU.
> But win7 does not quite work. Issues I've randomly met so far:
> 1) black screen after windows loading files
> 2) failed to access install media (I access install media / virtual disk
> through NFS)
> 3) BSOD memory_mangement during boot
> 4) BSOD system_service_exception during boot
> As I continuously try restarting the domU, syndrome keeps change randomly.
>
> At first glance, these appear to be irrelevant. But they only happens when I
> try IGD passthrough.
> And these appear both during installation and, if I finish install by
> temporally disable vga passthrough, during reboot after video driver
> install.
>
> I'm now going to download windows SDK to analysis the memory dump.
> Will likely need your expertise later.
>
> Thanks,
> Timothy

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel