linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Wei Yang <weiyang@linux.vnet.ibm.com>,
	gwshan@linux.vnet.ibm.com, aik@ozlabs.ru
Cc: linuxppc-dev@ozlabs.org, mpe@ellerman.id.au
Subject: Re: [PATCH V5 1/6] powerpc/powernv: don't enable SRIOV when VF BAR has non 64bit-prefetchable BAR
Date: Fri, 09 Oct 2015 19:15:19 +1100	[thread overview]
Message-ID: <1444378519.2845.14.camel@kernel.crashing.org> (raw)
In-Reply-To: <1444358816-8163-2-git-send-email-weiyang@linux.vnet.ibm.com>

On Fri, 2015-10-09 at 10:46 +0800, Wei Yang wrote:
> On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
> a SRIOV device's IOV BAR is not 64bit-prefetchable, this is not assigned
> from 64bit prefetchable window, which means M64 BAR can't work on it.

Won't this cause a lot of devices to become unsupported for us ? Or do
all devices we care about have their BARs marked prefetchable ?

> The reason is PCI bridges support only 2 windows and the kernel code
> programs bridges in the way that one window is 32bit-nonprefetchable and
> the other one is 64bit-prefetchable. So if devices' IOV BAR is 64bit and
> non-prefetchable, it will be mapped into 32bit space and therefore M64
> cannot be used for it.
> 
> This patch makes this explicit.

So PCIe allows for non-prefetchable BARs to be put under prefetchable
bridge windows as long as the mapping done by the CPU doesn't prefetch,
I believe. Well it's a natural conclusion of the weird note "Additional
Guidance on the Prefetchable Bit in Memory Space BARs" page 596 of PCIe
spec v3.0... it also says that devices should be pretty much free to
set their prefetchable bit even if they have side effects so.

So maybe we should have that option, rather than just not using the
devices, allow them to be allocate via the prefetchable window...

> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> Acked-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>  arch/powerpc/platforms/powernv/pci-ioda.c | 25 +++++++++----------------
>  1 file changed, 9 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 85cbc96..8c031b5 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -908,9 +908,6 @@ static int pnv_pci_vf_resource_shift(struct pci_dev *dev, int offset)
>  > 	> 	> if (!res->flags || !res->parent)
>  > 	> 	> 	> continue;
>  
> -> 	> 	> if (!pnv_pci_is_mem_pref_64(res->flags))
> -> 	> 	> 	> continue;
> -
>  > 	> 	> /*
>  > 	> 	>  * The actual IOV BAR range is determined by the start address
>  > 	> 	>  * and the actual size for num_vfs VFs BAR.  This check is to
> @@ -939,9 +936,6 @@ static int pnv_pci_vf_resource_shift(struct pci_dev *dev, int offset)
>  > 	> 	> if (!res->flags || !res->parent)
>  > 	> 	> 	> continue;
>  
> -> 	> 	> if (!pnv_pci_is_mem_pref_64(res->flags))
> -> 	> 	> 	> continue;
> -
>  > 	> 	> size = pci_iov_resource_size(dev, i + PCI_IOV_RESOURCES);
>  > 	> 	> res2 = *res;
>  > 	> 	> res->start += size * offset;
> @@ -1221,9 +1215,6 @@ static int pnv_pci_vf_assign_m64(struct pci_dev *pdev, u16 num_vfs)
>  > 	> 	> if (!res->flags || !res->parent)
>  > 	> 	> 	> continue;
>  
> -> 	> 	> if (!pnv_pci_is_mem_pref_64(res->flags))
> -> 	> 	> 	> continue;
> -
>  > 	> 	> for (j = 0; j < vf_groups; j++) {
>  > 	> 	> 	> do {
>  > 	> 	> 	> 	> win = find_next_zero_bit(&phb->ioda.m64_bar_alloc,
> @@ -1510,6 +1501,12 @@ int pnv_pci_sriov_enable(struct pci_dev *pdev, u16 num_vfs)
>  > 	> pdn = pci_get_pdn(pdev);
>  
>  > 	> if (phb->type == PNV_PHB_IODA2) {
> +> 	> 	> if (!pdn->vfs_expanded) {
> +> 	> 	> 	> dev_info(&pdev->dev, "don't support this SRIOV device"
> +> 	> 	> 	> 	> " with non 64bit-prefetchable IOV BAR\n");
> +> 	> 	> 	> return -ENOSPC;
> +> 	> 	> }
> +
>  > 	> 	> /* Calculate available PE for required VFs */
>  > 	> 	> mutex_lock(&phb->ioda.pe_alloc_mutex);
>  > 	> 	> pdn->offset = bitmap_find_next_zero_area(
> @@ -2775,9 +2772,10 @@ static void pnv_pci_ioda_fixup_iov_resources(struct pci_dev *pdev)
>  > 	> 	> if (!res->flags || res->parent)
>  > 	> 	> 	> continue;
>  > 	> 	> if (!pnv_pci_is_mem_pref_64(res->flags)) {
> -> 	> 	> 	> dev_warn(&pdev->dev, " non M64 VF BAR%d: %pR\n",
> +> 	> 	> 	> dev_warn(&pdev->dev, "Don't support SR-IOV with"
> +> 	> 	> 	> 	> 	> " non M64 VF BAR%d: %pR. \n",
>  > 	> 	> 	> 	>  i, res);
> -> 	> 	> 	> continue;
> +> 	> 	> 	> return;
>  > 	> 	> }
>  
>  > 	> 	> size = pci_iov_resource_size(pdev, i + PCI_IOV_RESOURCES);
> @@ -2796,11 +2794,6 @@ static void pnv_pci_ioda_fixup_iov_resources(struct pci_dev *pdev)
>  > 	> 	> res = &pdev->resource[i + PCI_IOV_RESOURCES];
>  > 	> 	> if (!res->flags || res->parent)
>  > 	> 	> 	> continue;
> -> 	> 	> if (!pnv_pci_is_mem_pref_64(res->flags)) {
> -> 	> 	> 	> dev_warn(&pdev->dev, "Skipping expanding VF BAR%d: %pR\n",
> -> 	> 	> 	> 	>  i, res);
> -> 	> 	> 	> continue;
> -> 	> 	> }
>  
>  > 	> 	> dev_dbg(&pdev->dev, " Fixing VF BAR%d: %pR to\n", i, res);
>  > 	> 	> size = pci_iov_resource_size(pdev, i + PCI_IOV_RESOURCES);

  reply	other threads:[~2015-10-09  8:15 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-09  2:46 [PATCH V5 0/6] Redesign SR-IOV on PowerNV Wei Yang
2015-10-09  2:46 ` [PATCH V5 1/6] powerpc/powernv: don't enable SRIOV when VF BAR has non 64bit-prefetchable BAR Wei Yang
2015-10-09  8:15   ` Benjamin Herrenschmidt [this message]
2015-10-09  9:02     ` David Laight
2015-10-12  3:16       ` Wei Yang
2015-10-12  2:58     ` Wei Yang
2015-10-12  6:55       ` Benjamin Herrenschmidt
2015-10-13  2:30         ` Wei Yang
2015-10-13  0:01   ` Gavin Shan
2015-10-13  1:49     ` Wei Yang
2015-10-13  3:20       ` Gavin Shan
2015-10-13  3:50         ` Wei Yang
2015-10-09  2:46 ` [PATCH V5 2/6] powerpc/powernv: simplify the calculation of iov resource alignment Wei Yang
2015-10-13  0:13   ` Gavin Shan
2015-10-13  2:45     ` Wei Yang
2015-10-13  3:27       ` Gavin Shan
2015-10-13  3:56         ` Wei Yang
2015-10-14  1:22           ` Gavin Shan
2015-10-09  2:46 ` [PATCH V5 3/6] powerpc/powernv: use one M64 BAR in Single PE mode for one VF BAR Wei Yang
2015-10-12 23:55   ` Gavin Shan
2015-10-13  2:50     ` Wei Yang
2015-10-13  3:32       ` Gavin Shan
2015-10-13  5:29         ` Wei Yang
2015-10-14  1:15           ` Gavin Shan
2015-10-15  7:29             ` Wei Yang
2015-10-09  2:46 ` [PATCH V5 4/6] powerpc/powernv: replace the hard coded boundary with gate Wei Yang
2015-10-09  2:46 ` [PATCH V5 5/6] powerpc/powernv: boundary the total VF BAR size instead of the individual one Wei Yang
2015-10-09  2:46 ` [PATCH V5 6/6] powerpc/powernv: allocate sparse PE# when using M64 BAR in Single PE mode Wei Yang
  -- strict thread matches above, loose matches on Subject: below --
2015-09-03  1:29 [PATCH V5 0/6] Redesign SR-IOV on PowerNV Wei Yang
2015-09-03  1:29 ` [PATCH V5 1/6] powerpc/powernv: don't enable SRIOV when VF BAR has non 64bit-prefetchable BAR Wei 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=1444378519.2845.14.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=aik@ozlabs.ru \
    --cc=gwshan@linux.vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --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).