On Mon, 2010-10-25 at 15:07 -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 25, 2010 at 12:50:41PM -0600, Nick Couchman wrote:
> > On Mon, 2010-10-25 at 14:48 -0400, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Oct 25, 2010 at 12:33:09PM -0600, Nick Couchman wrote:
> > > > On Mon, 2010-10-25 at 13:40 -0400, Konrad Rzeszutek Wilk wrote:
> > > >
> > > > >
> > > > > What do you see on your Xen serial output? I presume you cranked up
> > > > > logging:
> > > > > loglevel=all guest_lvl=all iommu=verbose on your Xen command line.
> > > > >
> > > > > Is there anything that shows up when you get the 'Failed to assign.."
> > > > > ?
> > > > >
> > > >
> > > > The only messages I get on the serial console after setting those
> > > > parameters on the xen.gz kernel line in grub (and rebooting, of course)
> > > > are the following:
> > > >
> > > > (XEN) [VT-D]iommu.c:1496: d0:PCI: unmap bdf = 2:0.0
> > > > (XEN) [VT-D]iommu.c:1364: d1:PCI: map bdf = 2:0.0
> > > > (XEN) domctl.c:848:d0 XEN_DOMCTL_assign_device: assign device (2:0.0)
> > > > failed
> > > > (XEN) event_channel.c:192:d0 EVTCHNOP failure: domain 1, error -22
> > >
> > > So, -EINVAL. How comfortable are you sticking a bunch of
> > > dprintk(VTDPREFIX, " in the drivers/passthrough/vtd/iommu.c file?
> > > Basically
> > > you need to figure which of the functions that are past line 1364
> > > are being called and return -EINVAL.
> >
> > I'm happy to give it a shot...it'll take a while to get the devel
> > environment configured, as I'm using packages right now and I don't even
> > think I have a compiler on this system. I'll report back once I get
> > that done and give that a try.
>
> Excellent. You might also want to CC Weidong (weidong.han@xxxxxxxxx) in the
> future
> who is right now on travel and he might have better suggestions. CC-ing him
> on this e-mail.
Okay, I've traced it down to this section of code in iommu.c:
/*
* Devices behind PCIe-to-PCI/PCIx bridge may generate
* different requester-id. It may originate from devfn=0
* on the secondary bus behind the bridge. Map that id
* as well.
*/
ret = domain_context_mapping_one(domain, drhd->iommu,
secbus, 0);
dprintk(XENLOG_ERR VTDPREFIX, "domain_conext_mapping_one
ret: %d\n", ret);
I guess that shouldn't surprise me, given this device is behind a
PCIe-to-PCI bridge. On to the domain_context_mapping_one function.
-Nick
--------
This e-mail may contain confidential and privileged material for the sole use
of the intended recipient. If this email is not intended for you, or you are
not responsible for the delivery of this message to the intended recipient,
please note that this message may contain SEAKR Engineering (SEAKR)
Privileged/Proprietary Information. In such a case, you are strictly
prohibited from downloading, photocopying, distributing or otherwise using this
message, its contents or attachments in any way. If you have received this
message in error, please notify us immediately by replying to this e-mail and
delete the message from your mailbox. Information contained in this message
that does not relate to the business of SEAKR is neither endorsed by nor
attributable to SEAKR.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home