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

[Jean Guyader <jean.guyader@xxxxxxxxx>]

On Fri, Jan 4, 2013 at 8:30 AM, G.R. <firemeteor@xxxxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>> 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.
>

Ho right I remember those patch, I thought they went in but I guess I was
wrong. Have you tried intel vga passthrough with those patches, does that
make any difference?
Also you should try to remove the OpRegion patch all together and see
if the system is more stable after that.
How much RAM do you give to your guest? We were seeing random BSOD
with the Windows driver when the guest had more than 4G of RAM.
To play it safe you should use 3G for your guest.

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

The windows igfx driver doesn't require the bar to be 1:1, it requires the
device to be at the same BDF though.

Jean

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