All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Wei Yang <weiyang@linux.vnet.ibm.com>,
	gwshan@linux.vnet.ibm.com, benh@kernel.crashing.org
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH V4 0/6] Redesign SR-IOV on PowerNV
Date: Wed, 26 Aug 2015 15:11:28 +1000	[thread overview]
Message-ID: <55DD4A80.8030102@ozlabs.ru> (raw)
In-Reply-To: <1439949704-8023-1-git-send-email-weiyang@linux.vnet.ibm.com>

On 08/19/2015 12:01 PM, Wei Yang wrote:
> In original design, it tries to group VFs to enable more number of VFs in the
> system, when VF BAR is bigger than 64MB. This design has a flaw in which one
> error on a VF will interfere other VFs in the same group.
>
> This patch series change this design by using M64 BAR in Single PE mode to
> cover only one VF BAR. By doing so, it gives absolute isolation between VFs.

With or without this patchset, this fails with a horrible loop of EEHs:
rmmod mlx4_en mlx4_ib mlx4_core
modprobe mlx4_core num_vfs=4 probe_vf=4 port_type_array=2,2 debug_level=1

No guest is needed, just boot and do these commands. The EEH error is 
pointing to a broken DMA address. iommu=nobypass fixed it for 4 VFs case 
but when I try 16 VFs, none is created.

What is the correct base tree and what hardware did you use for the testing 
_exactly_?

Mine is "Ethernet controller: Mellanox Technologies MT27520 Family 
[ConnectX-3 Pro]" with 128MB BARs and that works (just double checked - can 
create all 16 VFs) with PowerKVM 3.1 so it is not a hardware issue.



>
> v4:
>     * rebase the code on top of v4.2-rc7
>     * switch back to use the dynamic version of pe_num_map and m64_map
>     * split the memory allocation and PE assignment of pe_num_map to make it
>       more easy to read
>     * check pe_num_map value before free PE.
>     * add the rename reason for pe_num_map and m64_map in change log
> v3:
>     * return -ENOSPC when a VF has non-64bit prefetchable BAR
>     * rename offset to pe_num_map and define it staticly
>     * change commit log based on comments
>     * define m64_map staticly
> v2:
>     * clean up iov bar alignment calculation
>     * change m64s to m64_bars
>     * add a field to represent M64 Single PE mode will be used
>     * change m64_wins to m64_map
>     * calculate the gate instead of hard coded
>     * dynamically allocate m64_map
>     * dynamically allocate PE#
>     * add a case to calculate iov bar alignment when M64 Single PE is used
>     * when M64 Single PE is used, compare num_vfs with M64 BAR available number
>       in system at first
>
>
>
> Wei Yang (6):
>    powerpc/powernv: don't enable SRIOV when VF BAR has non
>      64bit-prefetchable BAR
>    powerpc/powernv: simplify the calculation of iov resource alignment
>    powerpc/powernv: use one M64 BAR in Single PE mode for one VF BAR
>    powerpc/powernv: replace the hard coded boundary with gate
>    powerpc/powernv: boundary the total VF BAR size instead of the
>      individual one
>    powerpc/powernv: allocate sparse PE# when using M64 BAR in Single PE
>      mode
>
>   arch/powerpc/include/asm/pci-bridge.h     |    7 +-
>   arch/powerpc/platforms/powernv/pci-ioda.c |  328 +++++++++++++++--------------
>   2 files changed, 175 insertions(+), 160 deletions(-)
>


-- 
Alexey

  parent reply	other threads:[~2015-08-26  5:11 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-19  2:01 [PATCH V4 0/6] Redesign SR-IOV on PowerNV Wei Yang
2015-08-19  2:01 ` [PATCH V4 1/6] powerpc/powernv: don't enable SRIOV when VF BAR has non 64bit-prefetchable BAR Wei Yang
2015-10-02  8:55   ` Alexey Kardashevskiy
2015-10-08  6:29     ` Wei Yang
2015-08-19  2:01 ` [PATCH V4 2/6] powerpc/powernv: simplify the calculation of iov resource alignment Wei Yang
2015-10-02  8:58   ` Alexey Kardashevskiy
2015-10-08  6:39     ` Wei Yang
2015-08-19  2:01 ` [PATCH V4 3/6] powerpc/powernv: use one M64 BAR in Single PE mode for one VF BAR Wei Yang
2015-08-19  2:21   ` Gavin Shan
2015-10-02  9:29   ` Alexey Kardashevskiy
2015-10-08  7:06     ` Wei Yang
2015-08-19  2:01 ` [PATCH V4 4/6] powerpc/powernv: replace the hard coded boundary with gate Wei Yang
2015-08-19  2:01 ` [PATCH V4 5/6] powerpc/powernv: boundary the total VF BAR size instead of the individual one Wei Yang
2015-10-02  9:51   ` Alexey Kardashevskiy
2015-10-08  7:13     ` Wei Yang
2015-08-19  2:01 ` [PATCH V4 6/6] powerpc/powernv: allocate sparse PE# when using M64 BAR in Single PE mode Wei Yang
2015-08-19  2:21   ` Gavin Shan
2015-10-02 10:05   ` Alexey Kardashevskiy
2015-10-08  7:19     ` Wei Yang
2015-08-26  5:11 ` Alexey Kardashevskiy [this message]
2015-08-26  8:06   ` [PATCH V4 0/6] Redesign SR-IOV on PowerNV Alexey Kardashevskiy
2015-10-02 10:07 ` Alexey Kardashevskiy
2015-10-07  2:43   ` Michael Ellerman

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=55DD4A80.8030102@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=benh@kernel.crashing.org \
    --cc=gwshan@linux.vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs.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 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.