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

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

>> Also you should try to remove the OpRegion patch all together and see
>> if the system is more stable after that.
> I started my xen journey with version 4.1.3, which does not have the
> OpRegion patch.
> But I don't think the windows domU is better with that version.
>
> Currently the linux domU works just fine with the OpRegion patch.
> So I don't believe this is causing issues. But anyway I'll give it a
> shot if I can't solve it in other ways.
>
>> 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.
>
> Thanks for this hint. I don't remember the number and need to check it
> out tonight.
> Could you clarify if it will cause problem for exact 4GB of RAM?
> It's not likely that I give it 4GB+, but 4GB is a possible number.

I'm so glad to report that the win7 64 bit domU works with the following steps:
1. Vendor caps fix.
2. Memory limited to 3GB.

Actually I'm not sure if #1 is required for the gfx driver since I did
not try #2 alone.
What I can confirm is that #2 is absolutely required and #1 + #2
produces a working system.

As I can observe, #2 fixes random BSOD without igfx drivers.
My original number is 4048MB.
So it appears that there are something wrong in the guest address
range of [0xc0000000 ~ 0xfd000000).

I would like to do some investigation since 3GB is a big limitation
for a 64 bit domU.
I remember traditionally most of the 3G ~ 4G range are reserved for
PCI config region.
My first guess is that some exposed PCI device appears to be buggy to windows.
Any suggestions how to investigate? I'm not very familiar with this.


For the vendor caps patch, I had to do some tweak to make it compile
sine that was a bit ancient.
I also find some small issues in that patch. Actually there is a CAPS
bit in the status register (0x6).
Without asserting this bit, lspci will not try to check the vendor
caps. I'm not sure if this is required
by the igfx windows driver, but this at least better adhere to the spec.

Apart from the Vender cap fix, I also find a gfx reset patch lost in the list.
http://lists.xen.org/archives/html/xen-devel/2012-01/msg02755.html
http://lists.xen.org/archives/html/xen-devel/2012-01/msg02754.html
Without this fix, the screen would flash during domU boot (start from
the second boot).
This can be worked around by bind the device to i915 driver and then
to pciback each time launching a new guest.
But this workaround does not work for rebooting guest.


So I've accumulated many local fixes to make intel gpu passthrough work.
If you believe they are worthwhile, I'll clean up the fix and submit the patch.

List of local fixes:
1. Stefano's intel pch init fix, patch submitted and acked by Stefano.
Not sure if accepted && submitted.
2. Patch for un-aligned OpRegion. Got feedback on security concern.
The impact is not yet clear.
3. Vendor cap fix. Jean && Ross's patch about one year ago, lost in
the devel list.
4. igfx reset fix. Jean's patch about one year ago, lost in the devel list.

I think devel list is not the best way to track issue && fixes. I
wounder if there are public bug tracking systems.

Thanks,
Timothy

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