From: Bjorn Helgaas <helgaas@kernel.org>
To: Alexander Duyck <aduyck@mirantis.com>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] iov: Reset resources to 0 if totalVFs increases after enabling ARI
Date: Wed, 28 Oct 2015 11:37:47 -0500 [thread overview]
Message-ID: <20151028163747.GA29223@localhost> (raw)
In-Reply-To: <20151027205221.14626.8940.stgit@localhost.localdomain>
Hi Alex,
On Tue, Oct 27, 2015 at 01:52:21PM -0700, Alexander Duyck wrote:
> This patch forces us to reallocate VF BARs if the totalVFs value has
> increased after enabling ARI. This normally shouldn't occur, however I
> have seen some non-spec devices that shift between 7 and some value greater
> than 7 based on the ARI value and we want to avoid triggering any issues
> with such devices.
Can you include specifics about the devices? The value "7" is pretty
specific, so if we're going to include that level of detail, we should
have the actual device info to go with it.
I guess the problem is:
- Device supports 7 TotalVFs with ARI disabled, >7 with ARI enabled
- Firmware leaves ARI disabled in SRIOV_CTRL
- Firmware computes size based on 7 VFs
- Firmware allocates space and programs BARs for 7 VFs
- Linux enables ARI, reads >7 TotalVFs
- Linux computes size based on >7 VFs
- Increased size may overlap other resources
Right?
> Fixes: 3aa71da412fe ("PCI: Enable SR-IOV ARI Capable Hierarchy before reading TotalVFs")
> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
> ---
> drivers/pci/iov.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index 099050d78a39..238950412de0 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -393,7 +393,7 @@ static int sriov_init(struct pci_dev *dev, int pos)
> int rc;
> int nres;
> u32 pgsz;
> - u16 ctrl, total;
> + u16 ctrl, total, orig_total;
> struct pci_sriov *iov;
> struct resource *res;
> struct pci_dev *pdev;
> @@ -402,6 +402,7 @@ static int sriov_init(struct pci_dev *dev, int pos)
> pci_pcie_type(dev) != PCI_EXP_TYPE_ENDPOINT)
> return -ENODEV;
>
> + pci_read_config_word(dev, pos + PCI_SRIOV_TOTAL_VF, &orig_total);
> pci_read_config_word(dev, pos + PCI_SRIOV_CTRL, &ctrl);
> if (ctrl & PCI_SRIOV_CTRL_VFE) {
> pci_write_config_word(dev, pos + PCI_SRIOV_CTRL, 0);
> @@ -450,6 +451,14 @@ found:
> }
> iov->barsz[i] = resource_size(res);
> res->end = res->start + resource_size(res) * total - 1;
> +
> + /* force reallocation of BARs if total VFs increased */
> + if (orig_total < total) {
> + res->flags |= IORESOURCE_UNSET;
> + res->end -= res->start;
> + res->start = 0;
> + }
Two thoughts here:
1) Even if the required space increased, it's possible that firmware
placed the BAR somewhere where the extra space is available. In that
case, this forces reallocation unnecessarily.
2) This *feels* like something the PCI core should be doing anyway,
even without any help here. Shouldn't we fail in pci_claim_resource()
and set IORESOURCE_UNSET there?
OK, and a third: re-reading TotalVF is (I think) completely
unnecessary per spec, so if we're going to do it we should probably
have a one-line comment about why the code is doing something that
appears unnecessary, and really should have a concrete example device
in the changelog.
> +
> dev_info(&dev->dev, "VF(n) BAR%d space: %pR (contains BAR%d for %d VFs)\n",
> i, res, i, total);
> i += bar64;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2015-10-28 16:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-27 20:52 [PATCH 0/5] Various of SR-IOV fixes and cleanup Alexander Duyck
2015-10-27 20:52 ` [PATCH 1/5] iov: Update virtfn_max_buses to validate offset and stride Alexander Duyck
2015-10-28 16:32 ` Bjorn Helgaas
2015-10-28 17:57 ` Alexander Duyck
2015-10-28 18:43 ` Bjorn Helgaas
2015-10-28 21:46 ` Alexander Duyck
2015-10-29 19:50 ` Bjorn Helgaas
2015-10-27 20:52 ` [PATCH 2/5] iov: Reset resources to 0 if totalVFs increases after enabling ARI Alexander Duyck
2015-10-28 16:37 ` Bjorn Helgaas [this message]
2015-10-28 18:32 ` Alexander Duyck
2015-10-28 19:52 ` Bjorn Helgaas
2015-10-28 21:37 ` Alexander Duyck
2015-10-27 20:52 ` [PATCH 3/5] iov: Fix sriov_enable exception handling path Alexander Duyck
2015-10-29 16:32 ` Bjorn Helgaas
2015-10-29 16:54 ` Alex Duyck
2015-10-29 20:41 ` Bjorn Helgaas
2015-10-27 20:52 ` [PATCH 4/5] iov: Variable and loop cleanup for sriov_disable and sriov_enable Alexander Duyck
2015-10-29 21:43 ` Bjorn Helgaas
2015-10-29 23:19 ` Alexander Duyck
2015-10-27 20:52 ` [PATCH 5/5] iov: Update sriov_enable to correctly handle offset and stride Alexander Duyck
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=20151028163747.GA29223@localhost \
--to=helgaas@kernel.org \
--cc=aduyck@mirantis.com \
--cc=bhelgaas@google.com \
--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).