On 2015/3/26 13:19, Daniel Axtens wrote:
> Hi Yijing,
>
> Pulled.
>
> I'm now getting build errors:
>
> /scratch/dja/linux-patches/arch/powerpc/kernel/pci-common.c: In function
> 'pcibios_scan_phb':
> /scratch/dja/linux-patches/arch/powerpc/kernel/pci-common.c:1638:14: error:
> 'bus' undeclare
On 03/26/2015 06:06 AM, Michael Ellerman wrote:
> On Wed, 2015-03-25 at 17:02 +0530, Anshuman Khandual wrote:
>> On 03/25/2015 10:58 AM, Michael Ellerman wrote:
>>> On Wed, 2015-03-18 at 16:04 +1100, Michael Ellerman wrote:
On Tue, 2015-03-17 at 11:35 +0530, Anshuman Khandual wrote:
> On 0
Peter Zijlstra [pet...@infradead.org] wrote:
|
| Is there a down-side to always doing the txn based group read? If an
| arch does not implement the read txn support it'll fall back to doing
| independent read ops, but we end up doing those anyway.
|
| That way we get less special case code.
We c
The patch adds one more EEH sub-command (VFIO_EEH_PE_INJECT_ERR)
to inject the specified EEH error, which is represented by
(struct vfio_eeh_pe_err), to the indicated PE for testing purpose.
Signed-off-by: Gavin Shan
Reviewed-by: David Gibson
---
Documentation/vfio.txt| 12
There are two equivalent sets of PE state constants, defined in
arch/powerpc/include/asm/eeh.h and include/uapi/linux/vfio.h.
Though the names are different, their corresponding values are
exactly same. The former is used by EEH core and the latter is
used by userspace.
The patch moves those const
The patch defines PCI error types and functions in uapi/asm/eeh.h
and exports function eeh_pe_inject_err(), which will be called by
VFIO driver to inject the specified PCI error to the indicated
PE for testing purpose.
Signed-off-by: Gavin Shan
Reviewed-by: David Gibson
---
arch/powerpc/include
The series of patches are extention to EEH support for VFIO PCI devices,
which allows to inject EEH errors to VFIO PCI devices from userspace
for testing purpose.
Changelog
=
v4 -> v5:
* Adjusted commit log for PATCH[1]
* Dropped the last patch which deletes VFIO_EEH_PE_STA
Hi Yijing,
Pulled.
I'm now getting build errors:
/scratch/dja/linux-patches/arch/powerpc/kernel/pci-common.c: In function
'pcibios_scan_phb':
/scratch/dja/linux-patches/arch/powerpc/kernel/pci-common.c:1638:14: error:
'bus' undeclared (first use in this function)
/scratch/dja/linux-patches/arc
On Thu, 2015-26-02 at 00:04:47 UTC, Dave Olson wrote:
> @@ -324,14 +335,33 @@ static bool cache_node_is_unified(const struct
> device_node *np)
> return of_get_property(np, "cache-unified", NULL);
> }
>
> +/*
> + * Handle unified caches that have two different types of tags. Most
> embe
Peter Zijlstra [pet...@infradead.org] wrote:
| On Wed, Mar 04, 2015 at 12:35:05AM -0800, Sukadev Bhattiprolu wrote:
| > In addition to using the transaction interface to schedule events
| > on a PMU, we will use it to also read a group of counters at once.
| > Accordingly, add a flags parameter to
On Wed, 2015-03-25 at 11:41 -0700, Sukadev Bhattiprolu wrote:
> Michael Ellerman [m...@ellerman.id.au] wrote:
> | On Sun, 2015-15-02 at 09:42:57 UTC, Li Zhong wrote:
> | > This patch moves the three events groups to the end of the attr groups,
> | > and if create_events_from_catalog() fails to set
On Wed, Mar 25, 2015 at 07:55:41PM -0600, Alex Williamson wrote:
>On Thu, 2015-03-26 at 11:59 +1100, Gavin Shan wrote:
>> On Wed, Mar 25, 2015 at 06:46:28PM -0600, Alex Williamson wrote:
>> >On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
>> >> The set of constants for PE states defined in uap
On Thu, 2015-03-26 at 13:29 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the powerpc-mpe tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
>
> In file included from arch/powerpc/platforms/powernv/setup.c:36:0:
> arch/powerpc/include/asm/opal.h:214:17: e
Hi all,
After merging the powerpc-mpe tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from arch/powerpc/platforms/powernv/setup.c:36:0:
arch/powerpc/include/asm/opal.h:214:17: error: 'enum OpalMessageType' declared
inside parameter list [-Werror]
On Thu, Mar 26, 2015 at 11:59:03AM +1100, Gavin Shan wrote:
> On Wed, Mar 25, 2015 at 06:46:28PM -0600, Alex Williamson wrote:
> >On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
> >> The set of constants for PE states defined in uapi/linux/vfio.h is
> >> duplicated to uapi/asm/eeh.h. The patch
On Thu, 2015-03-26 at 11:59 +1100, Gavin Shan wrote:
> On Wed, Mar 25, 2015 at 06:46:28PM -0600, Alex Williamson wrote:
> >On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
> >> The set of constants for PE states defined in uapi/linux/vfio.h is
> >> duplicated to uapi/asm/eeh.h. The patch remove
On Thu, Mar 26, 2015 at 12:01:57PM +1100, David Gibson wrote:
>On Wed, Mar 25, 2015 at 06:46:28PM -0600, Alex Williamson wrote:
>> On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
>> > The set of constants for PE states defined in uapi/linux/vfio.h is
>> > duplicated to uapi/asm/eeh.h. The patc
On 2015/3/26 6:13, Daniel Axtens wrote:
> Hi Yijing,
>
> I wasn't quite sure I understood your comments, so I was trying to apply
> your patch series and test it, but patch 3 doesn't apply cleanly to
> 4.0-rc5 or master. Can you respin the series?
Hi Daniel,
Could you pull the series from Bjor
On Wed, Mar 25, 2015 at 06:46:28PM -0600, Alex Williamson wrote:
> On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
> > The set of constants for PE states defined in uapi/linux/vfio.h is
> > duplicated to uapi/asm/eeh.h. The patch removes the set from the
> > former.
> >
> > Signed-off-by: Gav
On Wed, Mar 25, 2015 at 06:46:28PM -0600, Alex Williamson wrote:
>On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
>> The set of constants for PE states defined in uapi/linux/vfio.h is
>> duplicated to uapi/asm/eeh.h. The patch removes the set from the
>> former.
>>
>> Signed-off-by: Gavin Sha
On Wed, 2015-03-25 at 21:43 -0300, casca...@linux.vnet.ibm.com wrote:
> On Mon, Mar 23, 2015 at 10:15:08PM -0400, David Miller wrote:
> > From: Benjamin Herrenschmidt
> > Date: Tue, 24 Mar 2015 13:08:10 +1100
> >
> > > For the large pool, we don't keep a hint so we don't know it's
> > > wrapped,
On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
> The set of constants for PE states defined in uapi/linux/vfio.h is
> duplicated to uapi/asm/eeh.h. The patch removes the set from the
> former.
>
> Signed-off-by: Gavin Shan
> ---
> include/uapi/linux/vfio.h | 5 -
> 1 file changed, 5 de
On Mon, Mar 23, 2015 at 10:15:08PM -0400, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Tue, 24 Mar 2015 13:08:10 +1100
>
> > For the large pool, we don't keep a hint so we don't know it's
> > wrapped, in fact we purposefully don't use a hint to limit
> > fragmentation on it, but the
On Wed, 2015-03-25 at 17:02 +0530, Anshuman Khandual wrote:
> On 03/25/2015 10:58 AM, Michael Ellerman wrote:
> > On Wed, 2015-03-18 at 16:04 +1100, Michael Ellerman wrote:
> >> On Tue, 2015-03-17 at 11:35 +0530, Anshuman Khandual wrote:
> >>> On 03/17/2015 04:34 AM, Michael Ellerman wrote:
>
There are two equivalent sets of constants for PE states, defined
in arch/powerpc/include/asm/eeh.h and include/uapi/linux/vfio.h.
The former is used by EEH core and the latter is used by userspace.
The patch moves those constants from arch/powerpc/include/asm/eeh.h
to arch/powerpc/include/uapi/asm
The series of patches are extention to EEH support for VFIO PCI devices,
which allows to inject EEH errors to VFIO PCI devices from userspace
for testing purpose.
Changelog
=
v3 -> v4:
* Move constants for EEH PE states defined in uapi/linux/vfio.h
to uapi/asm/eeh.h.
v2 -
The patch adds one more EEH sub-command (VFIO_EEH_PE_INJECT_ERR)
to inject the specified EEH error, which is represented by
(struct vfio_eeh_pe_err), to the indicated PE for testing purpose.
Signed-off-by: Gavin Shan
Reviewed-by: David Gibson
---
Documentation/vfio.txt| 12
The set of constants for PE states defined in uapi/linux/vfio.h is
duplicated to uapi/asm/eeh.h. The patch removes the set from the
former.
Signed-off-by: Gavin Shan
---
include/uapi/linux/vfio.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/lin
The patch defines PCI error types and functions in uapi/asm/eeh.h
and exports function eeh_pe_inject_err(), which will be called by
VFIO driver to inject the specified PCI error to the indicated
PE for testing purpose.
Signed-off-by: Gavin Shan
Reviewed-by: David Gibson
---
arch/powerpc/include
Cédric Le Goater writes:
> Currently, when a sensor value is read, the kernel calls OPAL, which in
> turn builds a message for the FSP, and waits for a message back.
>
> The new device tree for OPAL sensors [1] adds new sensors that can be
> read synchronously (core temperatures for instance) an
Hi Yijing,
I wasn't quite sure I understood your comments, so I was trying to apply
your patch series and test it, but patch 3 doesn't apply cleanly to
4.0-rc5 or master. Can you respin the series?
Thanks,
Daniel
> Hi Daniel, thanks for your review and comments. We want to make a generic
> pci
On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> * Ingo Molnar wrote:
>
> > > +#define __HAVE_ARCH_REMAP
> > > +static inline void arch_remap(struct mm_struct *mm,
> > > + unsigned long old_start, unsigned long old_end,
> > > + unsigned long new_
On Wed, 2015-03-25 at 19:33 +0100, Ingo Molnar wrote:
> * Laurent Dufour wrote:
>
> > +static inline void arch_unmap(struct mm_struct *mm,
> > + struct vm_area_struct *vma,
> > + unsigned long start, unsigned long end)
> > +{
> > + if (start <= mm->context.vd
On Wed, 2015-03-25 at 14:12 -0400, David Miller wrote:
> From: Sowmini Varadhan
> Date: Wed, 25 Mar 2015 13:34:45 -0400
>
> > Changes from patchv6: moved pool_hash initialization to
> > lib/iommu-common.c and cleaned up code duplication from
> > sun4v/sun4u/ldc.
>
> Looks good to me.
>
> Powe
Michael Ellerman [m...@ellerman.id.au] wrote:
| On Sun, 2015-15-02 at 09:42:57 UTC, Li Zhong wrote:
| > This patch moves the three events groups to the end of the attr groups,
| > and if create_events_from_catalog() fails to set their attributes, we
| > set them to NULL in attr_groups.
|
| But why
* Ingo Molnar wrote:
> > +#define __HAVE_ARCH_REMAP
> > +static inline void arch_remap(struct mm_struct *mm,
> > + unsigned long old_start, unsigned long old_end,
> > + unsigned long new_start, unsigned long new_end)
> > +{
> > + /*
> > +* mr
* Laurent Dufour wrote:
> +static inline void arch_unmap(struct mm_struct *mm,
> + struct vm_area_struct *vma,
> + unsigned long start, unsigned long end)
> +{
> + if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> + mm->c
From: Sowmini Varadhan
Date: Wed, 25 Mar 2015 13:34:45 -0400
> Changes from patchv6: moved pool_hash initialization to
> lib/iommu-common.c and cleaned up code duplication from
> sun4v/sun4u/ldc.
Looks good to me.
PowerPC folks, what do you think?
_
Currently, when a sensor value is read, the kernel calls OPAL, which in
turn builds a message for the FSP, and waits for a message back.
The new device tree for OPAL sensors [1] adds new sensors that can be
read synchronously (core temperatures for instance) and that don't need
to wait for a re
On (03/24/15 18:16), David Miller wrote:
> Generally this looks fine to me.
>
> But about patch #2, I see no reason to have multiple iommu_pool_hash
> tables. Even from a purely sparc perspective, we can always just do
> with just one of them.
>
> Furthermore, you can even probably move it down
Note that this conversion is only being done to consolidate the
code and ensure that the common code provides the sufficient
abstraction. It is not expected to result in any noticeable
performance improvement, as there is typically one ldc_iommu
per vnet_port, and each one has 8k entries, with a ty
Investigation of multithreaded iperf experiments on an ethernet
interface show the iommu->lock as the hottest lock identified by
lockstat, with something of the order of 21M contentions out of
27M acquisitions, and an average wait time of 26 us for the lock.
This is not efficient. A more scalable
Changes from patchv6: moved pool_hash initialization to
lib/iommu-common.c and cleaned up code duplication from
sun4v/sun4u/ldc.
Sowmini (2):
Break up monolithic iommu table/lock into finer graularity pools and
lock
Make sparc64 use scalable lib/iommu-common.c functions
Sowmini Varadha
In iperf experiments running linux as the Tx side (TCP client) with
10 threads results in a severe performance drop when TSO is disabled,
indicating a weakness in the software that can be avoided by using
the scalable IOMMU arena DMA allocation.
Baseline numbers before this patch:
with default
On Sat, Dec 20, 2014 at 09:08:51AM -0800, Florian Fainelli wrote:
> 2014-12-18 19:49 GMT-08:00 Lennart Sorensen :
> > I have been trying to move an 8360 based system from a 3.0 kernel to a
> > 3.12 (on the way to 3.14 with ipipe/xenomai) kernel and encountered an
> > oops in the ucc_geth driver whe
On Mon, 23 Mar 2015 15:06:35 +1100
, Benjamin Herrenschmidt
wrote:
> On Mon, 2015-03-23 at 14:50 +1100, Michael Ellerman wrote:
> > On Mon, 2015-23-03 at 03:16:38 UTC, Benjamin Herrenschmidt wrote:
> > > The "sdc" node is missing the ranges property, it needs to be treated
> > > as having an empt
Signed-off-by: Emil Medve
---
v3: Rebased and updated due to upstream changes since v2
v2: Rebased and updated due to upstream changes since v1
arch/powerpc/include/asm/io.h | 2 +-
arch/powerpc/include/asm/page.h| 2 +-
arch/powerpc/include/asm/pgalloc-32.h | 2 +-
arch/powe
Some processes (CRIU) are moving the vDSO area using the mremap system
call. As a consequence the kernel reference to the vDSO base address is
no more valid and the signal return frame built once the vDSO has been
moved is not pointing to the new sigreturn address.
This patch handles vDSO remappin
Some architecture would like to be triggered when a memory area is moved
through the mremap system call.
This patch is introducing a new arch_remap mm hook which is placed in the
path of mremap, and is called before the old area is unmapped (and the
arch_unmap hook is called).
The architectures w
CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.
However some architectures like powerpc are keeping a reference to the vDSO
base address to build th
We can disable a THP split or a hugepage collapse by disabling irq.
We do send IPI to all the cpus in the early part of split/collapse,
and disabling local irq ensure we don't make progress with
split/collapse. If the THP is getting split we return NULL from
find_linux_pte_or_hugepte(). For all the
This patch remove helpers which we had used only once in the code.
Limiting page table walk variants help in ensuring that we won't
end up with code walking page table with wrong assumptions.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/pgtable.h | 21 -
arch/powerpc
pte can get updated from other CPUs as part of multiple activities
like THP split, huge page collapse, unmap. We need to make sure we
don't reload the pte value again and again for different checks.
Signed-off-by: Aneesh Kumar K.V
---
NOTE:
The series depends on the patch
[PATCH 4/6] powerpc: Fi
Hi,
Ignore this series, I used a wrong directory when sending out the
patchset. Will send a v3.
-aneesh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 25/03/2015 13:11, Ingo Molnar wrote:
>
> * Laurent Dufour wrote:
>
>> Some processes (CRIU) are moving the vDSO area using the mremap system
>> call. As a consequence the kernel reference to the vDSO base address is
>> no more valid and the signal return frame built once the vDSO has been
>>
* Laurent Dufour wrote:
> Some processes (CRIU) are moving the vDSO area using the mremap system
> call. As a consequence the kernel reference to the vDSO base address is
> no more valid and the signal return frame built once the vDSO has been
> moved is not pointing to the new sigreturn address
On 03/25/2015 10:58 AM, Michael Ellerman wrote:
> On Wed, 2015-03-18 at 16:04 +1100, Michael Ellerman wrote:
>> On Tue, 2015-03-17 at 11:35 +0530, Anshuman Khandual wrote:
>>> On 03/17/2015 04:34 AM, Michael Ellerman wrote:
What are you seeing exactly?
>>>
>>> I am running on a BE PKVM guest b
We can disable a THP split or a hugepage collapse by disabling irq.
We do send IPI to all the cpus in the early part of split/collapse,
and disabling local irq ensure we don't make progress with
split/collapse. If the THP is getting split we return NULL from
find_linux_pte_or_hugepte(). For all the
pte can get updated from other CPUs as part of multiple activities
like THP split, huge page collapse, unmap. We need to make sure we
don't reload the pte value again and again for different checks.
Signed-off-by: Aneesh Kumar K.V
---
NOTE: The patch is on top of
"[PATCH 4/6] powerpc: Fix compile
pte can get updated from other CPUs as part of multiple activities
like THP split, huge page collapse, unmap. We need to make sure we
don't reload the pte value again and again for different checks.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_book3s_64.h | 5 -
arch/pow
Some processes (CRIU) are moving the vDSO area using the mremap system
call. As a consequence the kernel reference to the vDSO base address is
no more valid and the signal return frame built once the vDSO has been
moved is not pointing to the new sigreturn address.
This patch handles vDSO remappin
Some architecture would like to be triggered when a memory area is moved
through the mremap system call.
This patch is introducing a new arch_remap mm hook which is placed in the
path of mremap, and is called before the old area is unmapped (and the
arch_unmap hook is called).
The architectures w
CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.
However some architectures like powerpc are keeping a reference to the vDSO
base address to build th
- Original Message -
> From: "Michael Ellerman"
> To: "Jan Stancek" , linuxppc-dev@lists.ozlabs.org
> Cc: linux-ker...@vger.kernel.org, pau...@samba.org, an...@samba.org,
> t...@kernel.org, c...@linux.com, jo...@redhat.com,
> jstan...@redhat.com, j...@jms.id.au
> Sent: Wednesday, 25 Mar
On Sun, 2015-15-02 at 09:42:57 UTC, Li Zhong wrote:
> sysfs_create_groups() creates groups one by one in the attr_groups array
> before a NULL entry is encountered. But if an error is seen, it stops
> and removes all the groups already created:
> for (i = 0; groups[i]; i++) {
>
On Wed, 2015-03-25 at 16:46 +1100, Stewart Smith wrote:
> Michael Ellerman writes:
>
> > The powernv code has some conditional support for running on bare metal
> > machines that have no OPAL firmware, but provide RTAS.
> >
> > No released machines ever supported that, and even in the lab it was
On Mon, 2015-03-23 at 13:44 +0200, Purcareata Bogdan wrote:
> On 27.02.2015 22:54, Benjamin Herrenschmidt wrote:
> > On Fri, 2015-02-27 at 09:28 +0200, Purcareata Bogdan wrote:
> >> Ping?
> >
> > What is the ping for ?
> >
> > Ben.
>
> Hello Ben,
>
> I just wanted to check with you what's the cur
On Wed, 2015-03-25 at 10:18 +0100, Christian Borntraeger wrote:
> Am 25.03.2015 um 10:11 schrieb Michael Ellerman:
> > If STRICT_MM_TYPECHECKS is enabled the generic gup code fails to build
> > because we are using ACCESS_ONCE on non-scalar types.
> >
> > Convert all uses to READ_ONCE.
>
> There
Am 25.03.2015 um 10:11 schrieb Michael Ellerman:
> If STRICT_MM_TYPECHECKS is enabled the generic gup code fails to build
> because we are using ACCESS_ONCE on non-scalar types.
>
> Convert all uses to READ_ONCE.
There is a similar patch from Jason Low in Andrews patch.
If that happens in 4.0-rc,
The argument for making this an option was that gcc produced inferior
code with it enabled. That doesn't seem to be the case anymore (gcc
4.9), so turn it on always.
Signed-off-by: Michael Ellerman
---
arch/powerpc/Kconfig.debug | 8 ---
arch/powerpc/include/asm/page.h
If STRICT_MM_TYPECHECKS is enabled the generic gup code fails to build
because we are using ACCESS_ONCE on non-scalar types.
Convert all uses to READ_ONCE.
Cc: a...@linux-foundation.org
Cc: kirill.shute...@linux.intel.com
Cc: aarca...@redhat.com
Cc: borntrae...@de.ibm.com
Cc: steve.cap...@linaro.
Signed-off-by: Aneesh Kumar K.V
[mpe: Fix the 32-bit code also]
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/kvm_book3s_64.h | 12 +++-
arch/powerpc/mm/dma-noncoherent.c| 2 +-
arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
arch/powerpc/mm/hugepage-hash64.c
The callers of setbat() are actually passing a pgprot_t for the flags
parameter. This doesn't matter unless STRICT_MM_TYPECHECKS is enabled.
So we can turn that on without breaking the build, change setbat() to
take a pgprot_t and have it convert it to an unsigned long internally.
Signed-off-by: M
The STRICT_MM_TYPECHECKS code has bit-rotted over the years. To make it
possible to easily build test it, make it a CONFIG option.
Signed-off-by: Michael Ellerman
---
arch/powerpc/Kconfig.debug | 8
arch/powerpc/include/asm/page.h | 4 +---
arch/powerpc/include/as
This is already declared in mmu_decl.h, so we don't need a second
version in the C file.
Signed-off-by: Michael Ellerman
---
arch/powerpc/mm/pgtable_32.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 03b1a3b0fbd5..72555ab1
In order to enable SRIOV on PowerNV platform, the PF's IOV BAR needs to be
adjusted:
1. size expanded
2. aligned to M64BT size
This patch documents this change on the reason and how.
[bhelgaas: reformat, clarify, expand]
Signed-off-by: Wei Yang
---
.../powerpc/pci_iov_resource_on_power
In struct pci_dn, the pcidev field is assigned but not used, so remove it.
Signed-off-by: Wei Yang
Acked-by: Gavin Shan
---
arch/powerpc/include/asm/pci-bridge.h |1 -
arch/powerpc/platforms/powernv/pci-ioda.c |1 -
2 files changed, 2 deletions(-)
diff --git a/arch/powerpc/include/
When IOV BAR is big, each is covered by 4 M64 windows. This leads to
several VF PE sits in one PE in terms of M64.
Group VF PEs according to the M64 allocation.
[bhelgaas: use dev_printk() when possible]
Signed-off-by: Wei Yang
---
arch/powerpc/include/asm/pci-bridge.h |2 +-
arch/powe
M64 aperture size is limited on PHB3. When the IOV BAR is too big, this
will exceed the limitation and failed to be assigned.
Introduce a different mechanism based on the IOV BAR size:
- if IOV BAR size is smaller than 64MB, expand to total_pe
- if IOV BAR size is bigger than 64MB, roundup p
On PowerNV platform, resource position in M64 BAR implies the PE# the
resource belongs to. In some cases, adjustment of a resource is necessary
to locate it to a correct position in M64 BAR .
This patch adds pnv_pci_vf_resource_shift() to shift the 'real' PF IOV BAR
address according to an offset.
Implement pcibios_iov_resource_alignment() on powernv platform.
On PowerNV platform, there are 3 cases for the IOV BAR:
1. initial state, the IOV BAR size is multiple times of VF BAR size
2. after expanded, the IOV BAR size is expanded to meet the M64 segment size
3. sizing stage, the IOV BAR is t
On PHB3, PF IOV BAR will be covered by M64 BAR to have better PE isolation.
M64 BAR is a type of hardware resource in PHB3, which could map a range of
MMIO to PE numbers on powernv platform. And this range is divided equally
by the number of total_pe with each divided range mapping to a PE number.
Previously the iommu_table had the same lifetime as a struct pnv_ioda_pe
and was embedded in it. The pnv_ioda_pe was assigned to a PE on the bootup
stage. Since PEs are based on the hardware layout which is static in the
system, they will never get released. This means the iommu_table in the
pnv_io
Flag PCI_REASSIGN_ALL_RSRC is used to ignore resources information setup by
firmware, so that kernel would re-assign all resources of pci devices.
On powerpc arch, this happens in a header fixup function
pcibios_fixup_resources(), which will clean up the resources if this flag
is set. This works f
From: Gavin Shan
pci_dn is the extension of PCI device node and is created from device node.
Unfortunately, VFs are enabled dynamically by PF's driver and they don't
have corresponding device nodes and pci_dn, which is required to access
VFs' config spaces.
The patch creates pci_dn for VFs in pc
When sizing and assigning resources, we divide the resources into two
lists: the requested list and the additional list. We don't consider the
alignment of additional VF(n) BAR space.
This is because the alignment required for the VF(n) BAR space is the size
of an individual VF BAR, not the size
Per the SR-IOV spec r1.1, sec 3.3.14, the required alignment of a PF's IOV
BAR is the size of an individual VF BAR, and the size consumed is the
individual VF BAR size times NumVFs.
The PowerNV platform has additional alignment requirements to help support
its Partitionable Endpoint device isolati
VFs are dynamically created when a driver enables them. On some platforms,
like PowerNV, special resources are necessary to enable VFs.
Add platform hooks for enabling and disabling VFs.
Signed-off-by: Wei Yang
Acked-by: Bjorn Helgaas
---
drivers/pci/iov.c | 19 +++
1 file c
On PowerNV, some resource reservation is needed for SR-IOV VFs that don't
exist at the bootup stage. To do the match between resources and VFs, the
code need to get the VF's BDF in advance.
Rename virtfn_bus() and virtfn_devfn() to pci_iov_virtfn_bus() and
pci_iov_virtfn_devfn() and export them.
An SR-IOV device can change its First VF Offset and VF Stride based on the
values of ARI Capable Hierarchy and NumVFs. The number of buses required
for all VFs is determined by NumVFs, First VF Offset, and VF Stride (see
SR-IOV spec r1.1, sec 2.1.2).
Previously pci_iov_bus_range() computed how ma
The First VF Offset and VF Stride fields depend on the NumVFs setting, so
refresh the cached fields in struct pci_sriov when updating NumVFs. See
the SR-IOV spec r1.1, sec 3.3.9 and 3.3.10.
[bhelgaas: changelog, remove kernel-doc comment marker]
Signed-off-by: Wei Yang
Acked-by: Bjorn Helgaas
-
From: Bjorn Helgaas
Most of PCI uses "res = &dev->resource[i]", not "res = dev->resource + i".
Use that style in iov.c also.
No functional change.
Signed-off-by: Bjorn Helgaas
Acked-by: Wei Yang
---
drivers/pci/iov.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --gi
Currently we don't store the individual VF BAR size. We calculate it when
needed by dividing the PF's IOV resource size (which contains space for
*all* the VFs) by total_VFs or by reading the BAR in the SR-IOV capability
again.
Keep the individual VF BAR size in struct pci_sriov.barsz[], add
pci_
When we size VF BAR0, VF BAR1, etc., from the SR-IOV Capability of a PF, we
learn the alignment requirement and amount of space consumed by a single
VF. But when VFs are enabled, *each* of the NumVFs consumes that amount of
space, so the total size of the PF resource is "VF BAR size * NumVFs".
Ad
From: Bjorn Helgaas
If we don't have space for all the bus numbers required to enable VFs,
print the largest bus number required and the range available.
No functional change; improved error message only.
Signed-off-by: Bjorn Helgaas
Acked-by: Wei Yang
---
drivers/pci/iov.c |7 +--
1
This patchset enables the SRIOV on POWER8.
The general idea is put each VF into one individual PE and allocate required
resources like MMIO/DMA/MSI. The major difficulty comes from the MMIO
allocation and adjustment for PF's IOV BAR.
On P8, we use M64BT to cover a PF's IOV BAR, which could make a
On 2015/3/25 7:58, Daniel Axtens wrote:
> On Tue, 2015-03-24 at 11:34 +0800, Yijing Wang wrote:
>> Now we could use pci_scan_host_bridge() to scan
>> pci buses, provide powerpc specific pci_host_bridge_ops.
>>
>> Signed-off-by: Yijing Wang
>> CC: Benjamin Herrenschmidt
>> CC: linuxppc-dev@lists.o
Hi Daniel,
On Wed, 25 Mar 2015 16:35:35 +1100 Daniel Axtens wrote:
>
> Previously, find_and_init_phbs() was used in both PowerNV and pSeries
> setup. However, since RTAS support has been dropped from PowerNV, we
> can move it into a platform-specific file.
>
> This patch depends on the patch to
98 matches
Mail list logo
