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

Re: [Xen-devel] Need help to debug win7 BSOD on IGD 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.
>
I did a quick grep in the list, it seems that Jean was trying to
submit the patch.
http://lists.xen.org/archives/html/xen-devel/2012-01/msg01129.html
http://lists.xen.org/archives/html/xen-devel/2012-01/msg01128.html

I guess this is lost accidentally? I don't see obvious negative
feedback on the thread.
Adding Jean, and Stefano who reviewed the patch.

Will try this out tomorrow. Hope the patch can work without big modification.

Jean, do you remember if there are other related patches to make gfx
passthrough working with windows?
I would like to check if there are more missed.

>>
>> 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.
>
Jean, do you happen to know if the igfx card rely on 1:1 MMIO bar
mapping to work on windows?

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


 


Rackspace

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