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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Sun, 6 Jan 2013, G.R. wrote:
> >> 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.

Ian Jackson is responsible for applying patches to the
qemu-xen-traditional tree.

However if you care to forward port the patches to upstream QEMU, that
now has PCI passthrough support but it is still completely missing gfx
passthrough, I would be happy to commit them and send them upstream.

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