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

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

On Sun, Jan 06, 2013 at 10:16:33PM +0800, 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.

That's good to hear! Thanks for all the debugging!

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

Yep! Please send all of the fixes as separate patches, against xen-unstable,
with Signed-Off-By lines etc.

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

There's the xen.org bugzilla, but it's not very much used..
It's better to just submit all the patches and get them merged to xen-unstable!


-- Pasi

Xen-devel mailing list



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