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

[Ross Philipson <Ross.Philipson@xxxxxxxxxx>]

> -----Original Message-----
> From: firemeteor.guo@xxxxxxxxx [mailto:firemeteor.guo@xxxxxxxxx] On
> Behalf Of G.R.
> Sent: Friday, January 04, 2013 8:50 AM
> To: xen-devel; Ross Philipson
> Subject: Re: Need help to debug win7 BSOD on IGD passthrough
> 
> 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?

Yes that is exactly what I am talking about. The igfx Windows driver
reads those vendor caps and does a bunch of internal driver setup
using them. We found crashes directly related to their absence.
I am not sure how to account for the crashes w/o the igfx
drivers - perhaps that is a different crash or perhaps the 
crash is unrelated to those capabilities.

The original patch I made (>2yrs ago) is completely out of date with
newer versions of qemu. But it basically followed the caps chain out
of register 0x34 and if it the value requested was vendor types
caps (type 0x09) on the host bridge it read them directly.

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

It sounds right that it doesn't need to be but I am not
sure; maybe someone else can confirm.

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