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