linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Wei Yang <weiyang@linux.vnet.ibm.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: Don't update VF's BAR
Date: Tue, 14 Jul 2015 17:15:11 -0500	[thread overview]
Message-ID: <20150714221511.GM24416@google.com> (raw)
In-Reply-To: <1435649834-3148-1-git-send-email-weiyang@linux.vnet.ibm.com>

On Tue, Jun 30, 2015 at 03:37:14PM +0800, Wei Yang wrote:
> VF BARs are RO zero, so updating VF BARs will not take any effect.
> See the SR-IOV spec r1.1, sec 3.4.1.11.
> 
> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
> ---
>  drivers/pci/setup-res.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> index 232f925..334b394 100644
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -37,6 +37,13 @@ void pci_update_resource(struct pci_dev *dev, int resno)
>  	struct resource *res = dev->resource + resno;
>  
>  	/*
> +	 * Per SRIOV SPEC 3.4.1.11, VF BARs are RO zero.
> +	 * If this is a VF, just return.
> +	 */
> +	if (dev->is_virtfn)
> +		return;

Does this fix a problem?  Are you seeing the "BAR %d: error updating"
message?

I wouldn't think we would even call pci_update_resource() for VFs, except
for pci_restore_bars().  Maybe we should check there?

If the PCI core is assigning space directly to VF BARs and trying to update
them, I'd like to know about that rather than silently ignoring it.

> +
> +	/*
>  	 * Ignore resources for unimplemented BARs and unused resource slots
>  	 * for 64 bit BARs.
>  	 */
> -- 
> 1.7.9.5
> 

  reply	other threads:[~2015-07-14 22:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30  7:37 [PATCH] PCI: Don't update VF's BAR Wei Yang
2015-07-14 22:15 ` Bjorn Helgaas [this message]
2015-07-15  1:38   ` Wei Yang
2015-07-29  8:52   ` [PATCH v2] " Wei Yang
2015-08-27 17:27     ` Bjorn Helgaas
2015-08-28  3:51       ` Richard Yang

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=20150714221511.GM24416@google.com \
    --to=bhelgaas@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=weiyang@linux.vnet.ibm.com \
    /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).