From: Alex Williamson <alex.williamson@redhat.com>
To: Sethi Varun-B16395 <B16395@freescale.com>
Cc: "iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"joro@8bytes.org" <joro@8bytes.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] iommu: amd/intel: Remove multifunction assumption around grouping
Date: Mon, 03 Jun 2013 09:10:17 -0600 [thread overview]
Message-ID: <1370272217.30975.283.camel@ul30vt.home> (raw)
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D56A9F4@039-SN2MPN1-013.039d.mgd.msft.net>
On Mon, 2013-06-03 at 07:28 +0000, Sethi Varun-B16395 wrote:
> > -----Original Message-----
> > From: iommu-bounces@lists.linux-foundation.org [mailto:iommu-
> > bounces@lists.linux-foundation.org] On Behalf Of Alex Williamson
> > Sent: Friday, May 31, 2013 12:09 AM
> > To: iommu@lists.linux-foundation.org; dwmw2@infradead.org;
> > joro@8bytes.org
> > Cc: linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: [PATCH] iommu: amd/intel: Remove multifunction assumption around
> > grouping
> >
> > If a device is multifunction and does not have ACS enabled then we assume
> > that the entire package lacks ACS and use function 0 as the base of the
> > group. The PCIe spec however states that components are permitted to
> > implement ACS on some, none, or all of their applicable functions. It's
> > therefore conceivable that function 0 may be fully independent and
> > support ACS while other functions do not. Instead use the lowest
> > function of the slot that does not have ACS enabled as the base of the
> > group. This may be the current device, which is intentional. So long as
> > we use a consistent algorithm, all the non-ACS functions will be grouped
> > together and ACS functions will get separate groups.
> >
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > ---
> > drivers/iommu/amd_iommu.c | 25 +++++++++++++++++++------
> > drivers/iommu/intel-iommu.c | 25 +++++++++++++++++++------
> > 2 files changed, 38 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index
> > 1d84be1..565c745 100644
> > --- a/drivers/iommu/amd_iommu.c
> > +++ b/drivers/iommu/amd_iommu.c
> > @@ -287,14 +287,27 @@ static struct pci_dev *get_isolation_root(struct
> > pci_dev *pdev)
> >
> > /*
> > * If it's a multifunction device that does not support our
> > - * required ACS flags, add to the same group as function 0.
> > + * required ACS flags, add to the same group as lowest numbered
> > + * function that also does not suport the required ACS flags.
> > */
> > if (dma_pdev->multifunction &&
> > - !pci_acs_enabled(dma_pdev, REQ_ACS_FLAGS))
> > - swap_pci_ref(&dma_pdev,
> > - pci_get_slot(dma_pdev->bus,
> > - PCI_DEVFN(PCI_SLOT(dma_pdev->devfn),
> > - 0)));
> > + !pci_acs_enabled(dma_pdev, REQ_ACS_FLAGS)) {
> > + u8 i, slot = PCI_SLOT(dma_pdev->devfn);
> > +
> > + for (i = 0; i < 8; i++) {
> > + struct pci_dev *tmp;
> > +
> > + tmp = pci_get_slot(dma_pdev->bus, PCI_DEVFN(slot, i));
> > + if (!tmp)
> > + continue;
> > +
> > + if (!pci_acs_enabled(tmp, REQ_ACS_FLAGS)) {
> > + swap_pci_ref(&dma_pdev, tmp);
> > + break;
> > + }
> > + pci_dev_put(tmp);
> > + }
> > + }
> >
> > /*
> > * Devices on the root bus go through the iommu. If that's not us,
> > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> > index b4f0e28..eec0d3e 100644
> > --- a/drivers/iommu/intel-iommu.c
> > +++ b/drivers/iommu/intel-iommu.c
> > @@ -4182,14 +4182,27 @@ static int intel_iommu_add_device(struct device
> > *dev)
> >
> > /*
> > * If it's a multifunction device that does not support our
> > - * required ACS flags, add to the same group as function 0.
> > + * required ACS flags, add to the same group as lowest numbered
> > + * function that also does not suport the required ACS flags.
> > */
> > if (dma_pdev->multifunction &&
> > - !pci_acs_enabled(dma_pdev, REQ_ACS_FLAGS))
> > - swap_pci_ref(&dma_pdev,
> > - pci_get_slot(dma_pdev->bus,
> > - PCI_DEVFN(PCI_SLOT(dma_pdev->devfn),
> > - 0)));
> > + !pci_acs_enabled(dma_pdev, REQ_ACS_FLAGS)) {
> > + u8 i, slot = PCI_SLOT(dma_pdev->devfn);
> > +
> > + for (i = 0; i < 8; i++) {
> [Sethi Varun-B16395] A macro like PCI_MAX_FUNCTIONS would improve code readability.
Ok, I see a couple defines of PCI_MAX_FUNCTION, I guess we could add one
to iommu/pci.h too.
> > + struct pci_dev *tmp;
> > +
> > + tmp = pci_get_slot(dma_pdev->bus, PCI_DEVFN(slot, i));
> > + if (!tmp)
> > + continue;
> > +
> > + if (!pci_acs_enabled(tmp, REQ_ACS_FLAGS)) {
> > + swap_pci_ref(&dma_pdev, tmp);
> > + break;
> > + }
> > + pci_dev_put(tmp);
> > + }
> > + }
>
> It would be nice if this code could be represented as a function in a common file like iommu/pci.c.
I agree, but I haven't gotten any feedback on iommu/pci.c yet and didn't
want this patch to depend on that series. There are probably more
opportunities to consolidate there. Thanks,
Alex
next prev parent reply other threads:[~2013-06-03 15:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-30 18:39 [PATCH] iommu: amd/intel: Remove multifunction assumption around grouping Alex Williamson
2013-06-03 7:28 ` Sethi Varun-B16395
2013-06-03 15:10 ` Alex Williamson [this message]
2013-06-20 15:22 ` Joerg Roedel
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=1370272217.30975.283.camel@ul30vt.home \
--to=alex.williamson@redhat.com \
--cc=B16395@freescale.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).