Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding PCI Passthrough?!

["Ren, Yongjie" <yongjie.ren@xxxxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Konrad Rzeszutek
> Wilk
> Sent: Tuesday, August 21, 2012 7:30 AM
> To: Tobias Geiger
> Cc: xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding PCI
> Passthrough?!
> 
> On Mon, Aug 06, 2012 at 12:16:33PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jul 25, 2012 at 09:43:57AM -0400, Konrad Rzeszutek Wilk
> wrote:
> > > On Wed, Jul 25, 2012 at 02:30:00PM +0200, Tobias Geiger wrote:
> > > > Hi!
> > > >
> > > > i notice a serious regression with 3.5 as Dom0 kernel (3.4 was rock
> > > > stable):
> > > >
> > > > 1st: only the GPU PCI Passthrough works, the PCI USB Controller is
> > > > not recognized within the DomU (HVM Win7 64)
> > > > Dom0 cmdline is:
> > > > ro root=LABEL=dom0root
> xen-pciback.hide=(08:00.0)(08:00.1)(00:1d.0)(00:1d.1)(00:1d.2)(00:1d.7)
> > > > security=apparmor noirqdebug nouveau.msi=1
> > > >
> > > > Only 8:00.0 and 8:00.1 get passed through without problems, all the
> > > > USB Controller IDs are not correctly passed through and get a
> > > > exclamation mark within the win7 device manager ("could not be
> > > > started").
> > >
> > > Ok, but they do get passed in though? As in, QEMU sees them.
> > > If you boot a Live Ubuntu/Fedora CD within the guest with the PCI
> > > passed in devices do you see them? Meaning lspci shows them?
> > >
> > >
> > > Is the lspci -vvv output in dom0 different from 3.4 vs 3.5?
> > >
> > > >
> > > >
> > > > 2nd: After DomU shutdown , Dom0 panics (100% reproducable) -
> sorry
> > > > that i have no full stacktrace, all i have is a "screenshot" which i
> > > > uploaded here:
> > > >
> http://imageshack.us/photo/my-images/52/img20120724235921.jpg/
> > >
> > > Ugh, that looks like somebody removed a large chunk of a pagetable.
> > >
> > > Hmm. Are you using dom0_mem=max parameter? If not, can you try
> > > that and also disable ballooning in the xm/xl config file pls?
> > >
> > > >
> > > >
> > > > With 3.4 both issues were not there - everything worked perfectly.
> > > > Tell me which debugging info you need, i may be able to re-install
> > > > my netconsole to get the full stacktrace (but i had not much luck
> > > > with netconsole regarding kernel panics - rarely this info gets sent
> > > > before the "panic"...)
> >
> > So I am able to reproduce this with a Windows 7 with an ATI 4870 and
> > an Intel 82574L NIC. The video card still works, but the NIC stopped
> > working. Same version of hypervisor/toolstack/etc, only change is the
> > kernel (v3.4.6->v3.5).
> >
> > Time to get my hands greasy with this..
> 
> And its due to a patch I added in v3.4
> (cd9db80e5257682a7f7ab245a2459648b3c8d268)
> - which did not work properly in v3.4, but with v3.5 got it working
> (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes v3.5 to now
> work
> anymore.
> 
> Anyhow, for right now jsut revert
> cd9db80e5257682a7f7ab245a2459648b3c8d268
> and it should work for you.
> 
Also, our team reported a VT-d bug 2 months ago.
http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
We found "3bb07f1b73ea6313b843807063e183e168c9182a" is the bad commit in linux 
tree.
Linux3.4.7 works fine; but Linux 3.5 has this issue.
Seem Tobias has the same issue as that in the bug.
But we didn't meet Dom0 panic when shutting down the DomU.


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