[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] PCI Passthrough Problems/Questions
I can confirm that Jan's patch fixes the problem! Thanks for the help! -Nick On Wed, 2010-11-03 at 09:01 +0800, Weidong Han wrote: > Nick Couchman wrote: > >>> > >>> > >> The logs look no problem. I'm wondering if the device implies PCI > >> standard. At last, I think you can try: only assign 02:00.0 > >> (pci=[02:00.0]), or assign them as multiple devices in guest > >> (pci=[02:00.0-1]). > >> > >> Regards, > >> Weidong > >> > > > > Should have tried that on my own. Forwarding just 02:00.0 through > > worked just fine! > > > > So, the patch you had me apply to the Xen 4 source - is that a final > > version of the patch, or is there still some work to do to come up with > > a final fix for this? > > > > > The patch is just for your testing. I think Jan's patch should fix the > issue. Jan sent it out in xen-devel mailing list yesterday, I attached > it here, pls try with it. > > Regards, > Weidong > plain text document attachment (vtd-check-secbus-devfn.patch) > If the device at <secbus>:00.0 is the device the mapping operation was > initiated for, trying to map it a second time will fail, and hence > this second mapping attempt must be prevented (as was done prior to > said c/s). > > Once at it, simplify the code a little, too. > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> > > --- a/xen/drivers/passthrough/vtd/iommu.c > +++ b/xen/drivers/passthrough/vtd/iommu.c > @@ -1371,23 +1371,16 @@ static int domain_context_mapping(struct > if ( find_upstream_bridge(&bus, &devfn, &secbus) < 1 ) > break; > > - /* PCIe to PCI/PCIx bridge */ > - if ( pdev_type(bus, devfn) == DEV_TYPE_PCIe2PCI_BRIDGE ) > - { > - ret = domain_context_mapping_one(domain, drhd->iommu, bus, > devfn); > - if ( ret ) > - return ret; > + ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn); > > - /* > - * 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. > - */ > + /* > + * 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 if we didn't already. > + */ > + if ( !ret && pdev_type(bus, devfn) == DEV_TYPE_PCIe2PCI_BRIDGE && > + (secbus != pdev->bus || pdev->devfn != 0) ) > ret = domain_context_mapping_one(domain, drhd->iommu, secbus, 0); > - } > - else /* Legacy PCI bridge */ > - ret = domain_context_mapping_one(domain, drhd->iommu, bus, > devfn); > > break; > -------- 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |