From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Brian Woods <brian.woods@amd.com>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH v4 4/5] amd/iommu: assign iommu devices to Xen
Date: Thu, 15 Nov 2018 17:00:50 +0100 [thread overview]
Message-ID: <20181115160050.n5chpgcq2qjye7ht@mac> (raw)
In-Reply-To: <5BED921402000078001FC78F@prv1-mh.provo.novell.com>
On Thu, Nov 15, 2018 at 08:34:44AM -0700, Jan Beulich wrote:
> >>> On 14.11.18 at 12:57, <roger.pau@citrix.com> wrote:
> > --- a/xen/drivers/passthrough/amd/iommu_init.c
> > +++ b/xen/drivers/passthrough/amd/iommu_init.c
> > @@ -993,6 +993,16 @@ static void * __init allocate_ppr_log(struct amd_iommu *iommu)
> >
> > static int __init amd_iommu_init_one(struct amd_iommu *iommu)
> > {
> > + struct pci_dev *pdev;
> > +
> > + pcidevs_lock();
> > + pdev = pci_get_pdev(iommu->seg, PCI_BUS(iommu->bdf),
> > + PCI_DEVFN2(iommu->bdf));
> > + if ( pdev )
> > + /* Assign the IOMMU PCI device to Xen */
> > + pdev->domain = dom_xen;
> > + pcidevs_unlock();
>
> Why do you kind of open-code pci_hide_device()? It would need
> extending to cope with a non-zero segment number, but I'd much
> prefer if there could be one central place where the logic lives.
> That way list addition would also not be omitted, like you do.
Sure, expanding pci_hide_device is better, I just didn't realize this
function existed in the first place.
> As to the hiding in general, also considering Andrew's objection:
> Are these devices representing the IOMMU and nothing else? As
> mentioned by Andrew something similar would be needed on the
> VT-d side, but iirc there's less clear of a relationship there in any
> event (which causes me to wonder about the situation on the
> AMD side). I'm asking not the least because iirc at the time
> pci_hide_device() was introduced I think it was considered to
> hide the AMD IOMMU devices; I don't recall why we didn't in the
> end, though.
I think this would be easier if I give more context about the issue
I'm hitting here, which is very similar to the issue patch 5/5
attempts to address.
The problem is that the IOMMU PCI device itself is obviously not
behind an IOMMU, and update_paging_mode will return an error if it
finds any such device in the domain list when attempting to expand the
IOMMU page tables:
...
iommu = find_iommu_for_device(pdev->seg, bdf);
if ( !iommu )
{
AMD_IOMMU_DEBUG("%s Fail to find iommu.\n", __func__);
return -ENODEV;
}
...
Another option is to allow the hardware domain to have assigned
devices that a not behind an IOMMU, but I would consider this more
like a workaround rather than a real fix.
I'm not sure whether the IOMMU AMD PCI device could also represent
something else, Maybe Brian can provide more insight on whether there
might be other platform devices encompassed in the same PCI device as
the IOMMU.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-11-15 16:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-14 11:57 [PATCH v4 0/5] x86/pvh: fix fixes for PVH Dom0 Roger Pau Monne
2018-11-14 11:57 ` [PATCH v4 1/5] vpci: fix updating the command register Roger Pau Monne
2018-11-16 12:00 ` Jan Beulich
2018-11-16 14:32 ` Roger Pau Monné
2018-11-19 8:26 ` Jan Beulich
2018-11-19 11:09 ` Roger Pau Monné
2018-11-19 11:31 ` Jan Beulich
2018-11-14 11:57 ` [PATCH v4 2/5] vpci: fix deferral of long operations Roger Pau Monne
2018-11-14 12:08 ` Paul Durrant
2018-11-16 12:11 ` Jan Beulich
2018-11-16 14:57 ` Roger Pau Monné
2018-11-19 8:27 ` Jan Beulich
2018-11-14 11:57 ` [PATCH v4 3/5] vpci/msix: carve p2m hole for MSIX MMIO regions Roger Pau Monne
2018-11-19 14:56 ` Jan Beulich
2018-11-20 14:35 ` Roger Pau Monné
2018-11-14 11:57 ` [PATCH v4 4/5] amd/iommu: assign iommu devices to Xen Roger Pau Monne
2018-11-14 12:33 ` Andrew Cooper
2018-11-14 13:53 ` Jan Beulich
2018-11-14 16:09 ` Roger Pau Monné
2018-11-15 15:34 ` Jan Beulich
2018-11-15 16:00 ` Roger Pau Monné [this message]
2018-11-14 11:57 ` [PATCH v4 5/5] amd/iommu: skip bridge devices when updating IOMMU page tables Roger Pau Monne
2018-11-15 15:40 ` Jan Beulich
2018-11-15 15:48 ` Roger Pau Monné
2018-11-15 16:13 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181115160050.n5chpgcq2qjye7ht@mac \
--to=roger.pau@citrix.com \
--cc=JBeulich@suse.com \
--cc=brian.woods@amd.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.