Re: Failure on latest GIT - implicit declaration of function ‘pte_swp_clear_soft_dirty’
Pranith Kumar writes: > On Sun, Jan 31, 2016 at 8:01 PM, Mike wrote: >> Building on ppc32 >> >> In file included from fs/proc/task_mmu.c:14:0: >> include/linux/swapops.h: In function ‘pte_to_swp_entry’: >> include/linux/swapops.h:69:6: error: implicit declaration of function >> ‘pte_swp_soft_dirty’ [-Werror=implicit-function-declaration] >> if (pte_swp_soft_dirty(pte)) >> ^ >> include/linux/swapops.h:70:9: error: implicit declaration of function >> ‘pte_swp_clear_soft_dirty’ [-Werror=implicit-function-declaration] >>pte = pte_swp_clear_soft_dirty(pte); >> ^ > > Can you try the patch posted here: https://lkml.org/lkml/2016/1/25/554 > This patch didn't work for you ? http://mid.gmane.org/1454086969-21074-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/mm: Enable HugeTLB page migration
On 01/29/2016 02:45 PM, Anshuman Khandual wrote:
> On 01/28/2016 08:14 PM, Aneesh Kumar K.V wrote:
>> > Anshuman Khandual writes:
>> >
>>> >> This enables HugeTLB page migration for PPC64_BOOK3S systems which
>>> >> implement
>>> >> HugeTLB page at the PMD level. It enables the kernel configuration option
>>> >> CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION by default which turns on the
>>> >> function
>>> >> hugepage_migration_supported() during migration. After the recent changes
>>> >> to the PTE format, HugeTLB page migration happens successfully.
>>> >>
>>> >> Signed-off-by: Anshuman Khandual
>>> >> ---
>>> >> arch/powerpc/Kconfig | 4
>>> >> 1 file changed, 4 insertions(+)
>>> >>
>>> >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>> >> index e4824fd..65d52a0 100644
>>> >> --- a/arch/powerpc/Kconfig
>>> >> +++ b/arch/powerpc/Kconfig
>>> >> @@ -82,6 +82,10 @@ config GENERIC_HWEIGHT
>>> >> config ARCH_HAS_DMA_SET_COHERENT_MASK
>>> >> bool
>>> >>
>>> >> +config ARCH_ENABLE_HUGEPAGE_MIGRATION
>>> >> +def_bool y
>>> >> +depends on PPC_BOOK3S_64 && HUGETLB_PAGE && MIGRATION
>>> >> +
>>> >> config PPC
>>> >> bool
>>> >> default y
>> >
>> >
>> > Are you sure this is all that is needed ? We will get a FOLL_GET with
>> > hugetlb
>> > migration and our follow_huge_addr will BUG_ON on that. Look at
>> > e66f17ff71772b209eed39de35aaa99ba819c93d (" mm/hugetlb: take page table
>> > lock in follow_huge_pmd()").
> HugeTLB page migration was successful without any error and data integrity
> check passed on them as well. But yes there might be some corner cases which
> trigger the race condition we have not faced yet. Will try to understand the
> situation there and get back.
Aneesh,
The current test which passed successfully in moving HugeTLB pages is
driven from the soft offline sysfs interface taking PFN (from pagemap
interface) as the argument. Its kind of directly calls migrate_pages()
handing out the page struct list as the argument. But the sample test
case in commit e66f17ff71772b ("mm/hugetlb: take page table lock in
follow_huge_pmd()") is able to crash the kernel at the BUG_ON as you
had mentioned before.
CPU: 2 PID: 6386 Comm: movepages Not tainted 4.5.0-rc2-2-gc3ac0a3 #3
task: c003e8792400 ti: c003f65cc000 task.ti: c003f65cc000
NIP: c01f485c LR: c01f4844 CTR:
REGS: c003f65cfa20 TRAP: 0700 Not tainted (4.5.0-rc2-2-gc3ac0a3)
MSR: 80010282b033 CR: 28044488
XER:
CFAR: c0050310 SOFTE: 1
GPR00: c01f4844 c003f65cfca0 c0d82e00 f0ec
GPR04: 3efff600 c003f65cfc74 c003f65cfc70 0001
GPR08: f000 f000
GPR12: 4400 cea70800 fff2 c003d333
GPR16: 0a00 c003f65cfd30 c003d333
GPR20: c0239f50 0100 f000 01320122
GPR24: c003ed267ee8 c003f65cfd70 3efff600 c003f65cfd80
GPR28: 008c c003ed267e80 c003ed2299d0 0004
NIP [c01f485c] follow_page_mask+0x7c/0x440
LR [c01f4844] follow_page_mask+0x64/0x440
Call Trace:
[c003f65cfca0] [c01f4844] follow_page_mask+0x64/0x440 (unreliable)
[c003f65cfd10] [c023d2d8] SyS_move_pages+0x518/0x820
[c003f65cfe30] [c0009260] system_call+0x38/0xd0
Instruction dump:
7cdb3378 7c9a2378 eba30040 9126 7fa3eb78 4be5b9f9 6000 3940f000
7fa35040 41dd0044 57ff077a 7bff0020 <0b1f> 38210070 e8010010 eae1ffb8
In the function follow_page_mask() we have this code block right at the
front where it fails.
page = follow_huge_addr(mm, address, flags & FOLL_WRITE);
if (!IS_ERR(page)) {
BUG_ON(flags & FOLL_GET);
return page;
}
As you mentioned, currently we dont implement CONFIG_ARCH_WANT_GENERAL_HUGETLB.
So we define follow_huge_addr() function which returns a valid page struct
for any given address. But then dont understand why we bug on for FOLL_GET.
move_pages() had called follow_page() with FOLL_GET flag at the first place.
So this condition is going to be true all the time. I am still digging into
this but meanwhile if you can throw some light on why we have BUG_ON for
FOLL_GET flag it will really be helpful. Did not get much clues looking into
the previous commit which added this BUG_ON.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/powernv: Remove support for p5ioc2
On Wed, Jan 13, 2016 at 05:10:31PM +1100, Russell Currey wrote:
>"p5ioc2 is used by approximately 2 machines in the world, and has never
>ever been a supported configuration."
>
>The code for p5ioc2 is essentially unused and complicates what is already
>a very complicated codebase. Its removal is essentially a "free win" in
>the effort to simplify the powernv PCI code.
>
>In addition, support for p5ioc2 has been dropped from skiboot. There's no
>reason to keep it around in the kernel.
>
>Signed-off-by: Russell Currey
>---
>Tested on a P7IOC machine and a PHB3 machine.
>
>Skiboot p5ioc2 removal patch: https://patchwork.ozlabs.org/patch/544898/
>---
> arch/powerpc/platforms/powernv/Makefile | 2 +-
> arch/powerpc/platforms/powernv/pci-p5ioc2.c | 271
> arch/powerpc/platforms/powernv/pci.c| 15 +-
> arch/powerpc/platforms/powernv/pci.h| 12 +-
> 4 files changed, 5 insertions(+), 295 deletions(-)
> delete mode 100644 arch/powerpc/platforms/powernv/pci-p5ioc2.c
>
>diff --git a/arch/powerpc/platforms/powernv/Makefile
>b/arch/powerpc/platforms/powernv/Makefile
>index 1c8cdb6..8a65c9c 100644
>--- a/arch/powerpc/platforms/powernv/Makefile
>+++ b/arch/powerpc/platforms/powernv/Makefile
>@@ -4,7 +4,7 @@ obj-y += rng.o opal-elog.o opal-dump.o
>opal-sysparam.o opal-sensor.o
> obj-y += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
>
> obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o
>-obj-$(CONFIG_PCI) += pci.o pci-p5ioc2.o pci-ioda.o
>+obj-$(CONFIG_PCI) += pci.o pci-ioda.o
> obj-$(CONFIG_EEH) += eeh-powernv.o
> obj-$(CONFIG_PPC_SCOM)+= opal-xscom.o
> obj-$(CONFIG_MEMORY_FAILURE) += opal-memory-errors.o
>diff --git a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
>b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
>deleted file mode 100644
>index f2bdfea..000
>--- a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
>+++ /dev/null
>@@ -1,271 +0,0 @@
>-/*
>- * Support PCI/PCIe on PowerNV platforms
>- *
>- * Currently supports only P5IOC2
>- *
>- * Copyright 2011 Benjamin Herrenschmidt, IBM Corp.
>- *
>- * This program is free software; you can redistribute it and/or
>- * modify it under the terms of the GNU General Public License
>- * as published by the Free Software Foundation; either version
>- * 2 of the License, or (at your option) any later version.
>- */
>-
>-#include
>-#include
>-#include
>-#include
>-#include
>-#include
>-#include
>-#include
>-#include
>-
>-#include
>-#include
>-#include
>-#include
>-#include
>-#include
>-#include
>-#include
>-#include
>-#include
>-
>-#include "powernv.h"
>-#include "pci.h"
>-
>-/* For now, use a fixed amount of TCE memory for each p5ioc2
>- * hub, 16M will do
>- */
>-#define P5IOC2_TCE_MEMORY 0x0100
>-
>-#ifdef CONFIG_PCI_MSI
>-static int pnv_pci_p5ioc2_msi_setup(struct pnv_phb *phb, struct pci_dev *dev,
>- unsigned int hwirq, unsigned int virq,
>- unsigned int is_64, struct msi_msg *msg)
>-{
>- if (WARN_ON(!is_64))
>- return -ENXIO;
>- msg->data = hwirq - phb->msi_base;
>- msg->address_hi = 0x1000;
>- msg->address_lo = 0;
>-
>- return 0;
>-}
>-
>-static void pnv_pci_init_p5ioc2_msis(struct pnv_phb *phb)
>-{
>- unsigned int count;
>- const __be32 *prop = of_get_property(phb->hose->dn,
>- "ibm,opal-msi-ranges", NULL);
>- if (!prop)
>- return;
>-
>- /* Don't do MSI's on p5ioc2 PCI-X are they are not properly
>- * verified in HW
>- */
>- if (of_device_is_compatible(phb->hose->dn, "ibm,p5ioc2-pcix"))
>- return;
>- phb->msi_base = be32_to_cpup(prop);
>- count = be32_to_cpup(prop + 1);
>- if (msi_bitmap_alloc(&phb->msi_bmp, count, phb->hose->dn)) {
>- pr_err("PCI %d: Failed to allocate MSI bitmap !\n",
>- phb->hose->global_number);
>- return;
>- }
>- phb->msi_setup = pnv_pci_p5ioc2_msi_setup;
>- phb->msi32_support = 0;
>- pr_info(" Allocated bitmap for %d MSIs (base IRQ 0x%x)\n",
>- count, phb->msi_base);
>-}
>-#else
>-static void pnv_pci_init_p5ioc2_msis(struct pnv_phb *phb) { }
>-#endif /* CONFIG_PCI_MSI */
>-
>-static struct iommu_table_ops pnv_p5ioc2_iommu_ops = {
>- .set = pnv_tce_build,
>-#ifdef CONFIG_IOMMU_API
>- .exchange = pnv_tce_xchg,
>-#endif
>- .clear = pnv_tce_free,
>- .get = pnv_tce_get,
>-};
>-
>-static void pnv_pci_p5ioc2_dma_dev_setup(struct pnv_phb *phb,
>- struct pci_dev *pdev)
>-{
>- struct iommu_table *tbl = phb->p5ioc2.table_group.tables[0];
>-
>- if (!tbl->it_map) {
>- tbl->it_ops = &pnv_p5ioc2_iommu_ops;
>- iommu_init_table(tbl, phb->hose->node);
>- iommu_register_group(&phb->p5ioc2.table_group,
>-
Re: [RFCv2 3/9] arch/powerpc: Handle removing maybe-present bolted HPTEs
On Mon, Feb 01, 2016 at 11:28:54AM +0530, Anshuman Khandual wrote: > On 01/29/2016 10:53 AM, David Gibson wrote: > > At the moment the hpte_removebolted callback in ppc_md returns void and > > will BUG_ON() if the hpte it's asked to remove doesn't exist in the first > > place. This is awkward for the case of cleaning up a mapping which was > > partially made before failing. > > > > So, we add a return value to hpte_removebolted, and have it return ENOENT > > in the case that the HPTE to remove didn't exist in the first place. > > > > In the (sole) caller, we propagate errors in hpte_removebolted to its > > caller to handle. However, we handle ENOENT specially, continuing to > > complete the unmapping over the specified range before returning the error > > to the caller. > > > > This means that htab_remove_mapping() will work sanely on a partially > > present mapping, removing any HPTEs which are present, while also returning > > ENOENT to its caller in case it's important there. > > Yeah makes sense. > > > > > There are two callers of htab_remove_mapping(): > >- In remove_section_mapping() we already WARN_ON() any error return, > > which is reasonable - in this case the mapping should be fully > > present > > Right. > > >- In vmemmap_remove_mapping() we BUG_ON() any error. We change that to > > just a WARN_ON() in the case of ENOENT, since failing to remove a > > mapping that wasn't there in the first place probably shouldn't be > > fatal. > > Provided the caller of vmemmap_remove_mapping() which is memory hotplug > path must be handling the returned -ENOENT error correctly. vmemmap_remove_mapping() is void, so there's no -ENOENT returned, just the WARN_ON(). > Just curious > and want to make sure that any of the memory sections or pages inside the > section must not be left in a state which makes the next call in the > hotplug path fail. So, this situation shouldn't happen - the mapping should be complete - but there's nothing obvious that the caller should do extra. It asked that the mapping be removed, and we discovered that some of it wasn't there to begin with. Whether we can continue safely depends on what exactly caused the mapping not to be fully present in the first place, and whether that had other conseuqences, but we have no way of knowing that here. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFCv2 5/9] arch/powerpc: Split hash page table sizing heuristic into a helper
On Mon, Feb 01, 2016 at 12:34:32PM +0530, Anshuman Khandual wrote:
> On 01/29/2016 10:53 AM, David Gibson wrote:
> > htab_get_table_size() either retrieve the size of the hash page table (HPT)
> > from the device tree - if the HPT size is determined by firmware - or
> > uses a heuristic to determine a good size based on RAM size if the kernel
> > is responsible for allocating the HPT.
> >
> > To support a PAPR extension allowing resizing of the HPT, we're going to
> > want the memory size -> HPT size logic elsewhere, so split it out into a
> > helper function.
> >
> > Signed-off-by: David Gibson
> > ---
> > arch/powerpc/include/asm/mmu-hash64.h | 3 +++
> > arch/powerpc/mm/hash_utils_64.c | 30 +-
> > 2 files changed, 20 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/mmu-hash64.h
> > b/arch/powerpc/include/asm/mmu-hash64.h
> > index 7352d3f..cf070fd 100644
> > --- a/arch/powerpc/include/asm/mmu-hash64.h
> > +++ b/arch/powerpc/include/asm/mmu-hash64.h
> > @@ -607,6 +607,9 @@ static inline unsigned long get_kernel_vsid(unsigned
> > long ea, int ssize)
> > context = (MAX_USER_CONTEXT) + ((ea >> 60) - 0xc) + 1;
> > return get_vsid(context, ea, ssize);
> > }
> > +
> > +unsigned htab_shift_for_mem_size(unsigned long mem_size);
> > +
> > #endif /* __ASSEMBLY__ */
> >
> > #endif /* _ASM_POWERPC_MMU_HASH64_H_ */
> > diff --git a/arch/powerpc/mm/hash_utils_64.c
> > b/arch/powerpc/mm/hash_utils_64.c
> > index e88a86e..d63f7dc 100644
> > --- a/arch/powerpc/mm/hash_utils_64.c
> > +++ b/arch/powerpc/mm/hash_utils_64.c
> > @@ -606,10 +606,24 @@ static int __init htab_dt_scan_pftsize(unsigned long
> > node,
> > return 0;
> > }
> >
> > -static unsigned long __init htab_get_table_size(void)
> > +unsigned htab_shift_for_mem_size(unsigned long mem_size)
> > {
> > - unsigned long mem_size, rnd_mem_size, pteg_count, psize;
> > + unsigned memshift = __ilog2(mem_size);
> > + unsigned pshift = mmu_psize_defs[mmu_virtual_psize].shift;
> > + unsigned pteg_shift;
> > +
> > + /* round mem_size up to next power of 2 */
> > + if ((1UL << memshift) < mem_size)
> > + memshift += 1;
> > +
> > + /* aim for 2 pages / pteg */
>
> While here I guess its a good opportunity to write couple of lines
> about why one PTE group for every two physical pages on the system,
Well, that don't really know, it's just copied from the existing code.
> why minimum (1UL << 11 = 2048) number of PTE groups required,
Ok.
> why
> (1U << 7 = 128) entries per PTE group
Um.. what? Because that's how big a PTEG is, I don't think
re-explaining the HPT structure here is useful.
> and also remove the existing
> confusing comments above ? Just a suggestion.
Not sure which comment you mean.
>
> > + pteg_shift = memshift - (pshift + 1);
> > +
> > + return max(pteg_shift + 7, 18U);
> > +}
> >
> > +static unsigned long __init htab_get_table_size(void)
> > +{
> > /* If hash size isn't already provided by the platform, we try to
> > * retrieve it from the device-tree. If it's not there neither, we
> > * calculate it now based on the total RAM size
> > @@ -619,17 +633,7 @@ static unsigned long __init htab_get_table_size(void)
> > if (ppc64_pft_size)
> > return 1UL << ppc64_pft_size;
> >
> > - /* round mem_size up to next power of 2 */
> > - mem_size = memblock_phys_mem_size();
> > - rnd_mem_size = 1UL << __ilog2(mem_size);
> > - if (rnd_mem_size < mem_size)
> > - rnd_mem_size <<= 1;
> > -
> > - /* # pages / 2 */
> > - psize = mmu_psize_defs[mmu_virtual_psize].shift;
> > - pteg_count = max(rnd_mem_size >> (psize + 1), 1UL << 11);
> > -
> > - return pteg_count << 7;
> > + return htab_shift_for_mem_size(memblock_phys_mem_size());
>
> Would it be 1UL << htab_shift_for_mem_size(memblock_phys_mem_size())
> instead ? It was returning the size of the HPT not the shift of HPT
> originally or I am missing something here.
Oops, yes. That would have broken all non-LPAR platforms.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFCv2 6/9] pseries: Add hypercall wrappers for hash page table resizing
On Mon, Feb 01, 2016 at 12:41:31PM +0530, Anshuman Khandual wrote:
> On 01/29/2016 10:54 AM, David Gibson wrote:
> > This adds the hypercall numbers and wrapper functions for the hash page
> > table resizing hypercalls.
> >
> > These are experimental "platform specific" values for now, until we have a
> > formal PAPR update.
> >
> > It also adds a new firmware feature flat to track the presence of the
> > HPT resizing calls.
>
> Its a flag ... ^^^ here.
Oops, thanks.
>
> >
> > Signed-off-by: David Gibson
> > ---
> > arch/powerpc/include/asm/firmware.h | 5 +++--
> > arch/powerpc/include/asm/hvcall.h | 2 ++
> > arch/powerpc/include/asm/plpar_wrappers.h | 12
> > arch/powerpc/platforms/pseries/firmware.c | 1 +
> > 4 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/firmware.h
> > b/arch/powerpc/include/asm/firmware.h
> > index b062924..32435d2 100644
> > --- a/arch/powerpc/include/asm/firmware.h
> > +++ b/arch/powerpc/include/asm/firmware.h
> > @@ -42,7 +42,7 @@
> > #define FW_FEATURE_SPLPAR ASM_CONST(0x0010)
> > #define FW_FEATURE_LPARASM_CONST(0x0040)
> > #define FW_FEATURE_PS3_LV1 ASM_CONST(0x0080)
> > -/* FreeASM_CONST(0x0100) */
> > +#define FW_FEATURE_HPT_RESIZE ASM_CONST(0x0100)
> > #define FW_FEATURE_CMO ASM_CONST(0x0200)
> > #define FW_FEATURE_VPHNASM_CONST(0x0400)
> > #define FW_FEATURE_XCMOASM_CONST(0x0800)
> > @@ -66,7 +66,8 @@ enum {
> > FW_FEATURE_MULTITCE | FW_FEATURE_SPLPAR | FW_FEATURE_LPAR |
> > FW_FEATURE_CMO | FW_FEATURE_VPHN | FW_FEATURE_XCMO |
> > FW_FEATURE_SET_MODE | FW_FEATURE_BEST_ENERGY |
> > - FW_FEATURE_TYPE1_AFFINITY | FW_FEATURE_PRRN,
> > + FW_FEATURE_TYPE1_AFFINITY | FW_FEATURE_PRRN |
> > + FW_FEATURE_HPT_RESIZE,
> > FW_FEATURE_PSERIES_ALWAYS = 0,
> > FW_FEATURE_POWERNV_POSSIBLE = FW_FEATURE_OPAL,
> > FW_FEATURE_POWERNV_ALWAYS = 0,
> > diff --git a/arch/powerpc/include/asm/hvcall.h
> > b/arch/powerpc/include/asm/hvcall.h
> > index e3b54dd..195e080 100644
> > --- a/arch/powerpc/include/asm/hvcall.h
> > +++ b/arch/powerpc/include/asm/hvcall.h
> > @@ -293,6 +293,8 @@
> >
> > /* Platform specific hcalls, used by KVM */
> > #define H_RTAS 0xf000
> > +#define H_RESIZE_HPT_PREPARE 0xf003
> > +#define H_RESIZE_HPT_COMMIT0xf004
>
> This sound better and matches FW_FEATURE_HPT_RESIZE ?
I'm not quite sure what you're suggesting here.
> #define H_HPT_RESIZE_PREPARE 0xf003
> #define H_HPT_RESIZE_COMMIT 0xf004
>
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFCv2 0/9] PAPR hash page table resizing (guest side)
On Mon, Feb 01, 2016 at 11:20:03AM +0530, Anshuman Khandual wrote: > On 01/29/2016 10:53 AM, David Gibson wrote: > > Here's a second prototype of the guest side work for runtime resizing > > of the has page table in PAPR guests. > > > > This is now feature complete. It implements the resizing, advertises > > it with CAS, and will automatically invoke it to maintain a good HPT > > size when memory is hot-added or hot-removed. > > > > Patches 1-5 are standalone prerequisite cleanups that I'll be pushing > > concurrently. > > > > David Gibson (9): > > memblock: Don't mark memblock_phys_mem_size() as __init > > arch/powerpc: Clean up error handling for htab_remove_mapping > > arch/powerpc: Handle removing maybe-present bolted HPTEs > > arch/powerpc: Clean up memory hotplug failure paths > > arch/powerpc: Split hash page table sizing heuristic into a helper > > A small nit. Please start the above commit message headers as > "powerpc/mm:" instead, which sounds more clear and uniform with > patch series related to other subsystems. Ok. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fix kgdb on little endian ppc64le
On Mon, 1 Feb 2016 21:39:00 +1100 Andrew Donnellan wrote: > On 01/02/16 17:03, Balbir Singh wrote: > > From: Balbir Singh > > > > I spent some time trying to use kgdb and debugged my inability to > > resume from kgdb_handle_breakpoint(). NIP is not incremented > > and that leads to a loop in the debugger. > > > > I've tested this lightly on a virtual instance with KDB enabled. > > After the patch, I am able to get the "go" command to work as > > expected > > > > Signed-off-by: Balbir Singh > > Should this be Cc'd to stable? > > Good suggestion, Michael? I can repost this to stable if required? Balbir Singh. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/ifc: Segregate IFC fcm and runtime registers
On Mon, 2016-02-01 at 16:16 +0530, Raghav Dogra wrote:
> /*
> * IFC Controller Registers
> */
> -struct fsl_ifc_regs {
> +struct fsl_ifc_fcm {
> __be32 ifc_rev;
> u32 res1[0x2];
> struct {
This struct is not specific to fcm (i.e. nand). Please choose a better name,
such as fsl_ifc_global (which would match "gregs").
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults
On Mon, Feb 01, 2016 at 10:30:53PM +0100, Maciej S. Szmigiero wrote: > On 01.02.2016 22:10, Mark Brown wrote: > > No, that's completely broken. We can't do a raw read from a regmap that > > doesn't offer raw access and we shouldn't pretend to do so. If the > > caller is capable of substituting a register by register read the caller > > should take responsibility for that. > So can regcache initialization be changed to use register by register read > in case raw read fails? Well, we *do* have full source code access! I'm just blind writing a patch to do that. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults
On Mon, Feb 1, 2016 at 7:30 PM, Maciej S. Szmigiero wrote: > So can regcache initialization be changed to use register by register read > in case raw read fails? > > Since other option for drivers like SSI which are memory mapped and > don't offer ability to reset their register values to default would be to > explicitly write driver hardcoded defaults also by doing > register by register write on probe time. Yes, I had to do the same for sgtl5000: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/sound/soc/codecs/sgtl5000.c?id=af8ee11209e749c75eabf32b2a4ca631f396acf8 Would this approach work here too? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults
On 01.02.2016 22:10, Mark Brown wrote: > On Mon, Feb 01, 2016 at 05:58:06PM +0100, Maciej S. Szmigiero wrote: > >> Looks like a possible solution would be to change >> regmap_raw_read() to do read using _regmap_read in >> case the cache is bypassed and there is no ->read >> callback defined for regmap implementation. > > No, that's completely broken. We can't do a raw read from a regmap that > doesn't offer raw access and we shouldn't pretend to do so. If the > caller is capable of substituting a register by register read the caller > should take responsibility for that. So can regcache initialization be changed to use register by register read in case raw read fails? Since other option for drivers like SSI which are memory mapped and don't offer ability to reset their register values to default would be to explicitly write driver hardcoded defaults also by doing register by register write on probe time. But this would force driver to keep the defaults which I think is bad (especially for driver that supports multiple generations of hardware like fsl_ssi which may have different default values). Maciej ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults
On Mon, Feb 01, 2016 at 05:58:06PM +0100, Maciej S. Szmigiero wrote: > Looks like a possible solution would be to change > regmap_raw_read() to do read using _regmap_read in > case the cache is bypassed and there is no ->read > callback defined for regmap implementation. No, that's completely broken. We can't do a raw read from a regmap that doesn't offer raw access and we shouldn't pretend to do so. If the caller is capable of substituting a register by register read the caller should take responsibility for that. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/ifc: Segregate IFC fcm and runtime registers
On Mon, Feb 01, 2016 at 01:41:45PM -0600, Li Yang wrote: > On Mon, Feb 1, 2016 at 4:46 AM, Raghav Dogra wrote: > > A general comment is that you should include the linux-mtd mailing > list and it's maintainers for this set of patches. Although the > MAINTAINERS file doesn't specify a maintainer for drivers/memory > directory, it should be most related to linux-mtd, IMO. Yes, please resend. This is especially odd, considering that it appears your resending here is in direct response to my comments on the linux-mtd mailing list, and neither I nor linux-mtd were CC'd on this iteration... > > IFC has two set of registers viz FCM (Flash control machine) > > aka global and run time registers. These set are defined in two > > memory map PAGES. Upto IFC 1.4 PAGE size is 4 KB and from IFC2.0 > > PAGE size is 64KB > > So I guess this patch is the critical change to make the fsl_ifc > driver work with the version 2.0 hardware block? If so, it will be > better to mention this in the patch title. I made a similar comment on the 1st version. But I can't see the patch this time :( > > Signed-off-by: Jaiprakash Singh > > Signed-off-by: Raghav Dogra > > --- > > drivers/memory/fsl_ifc.c| 251 > > +--- > > drivers/mtd/nand/fsl_ifc_nand.c | 72 ++-- > > include/linux/fsl_ifc.h | 48 +--- > > 3 files changed, 203 insertions(+), 168 deletions(-) Brian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failure on latest GIT - implicit declaration of function ‘pte_swp_clear_soft_dirty’
Thanks! Applied and it built this time, sadly i missed RC-2 and will just have to test and see if the radeon r300 is un-broken and rebuild, doing dpkg kernel build and was lazy with the .config so it takes a day building on this single core g4! Cheers Mike On 1 February 2016 at 01:05, Pranith Kumar wrote: > On Sun, Jan 31, 2016 at 8:01 PM, Mike wrote: > > Building on ppc32 > > > > In file included from fs/proc/task_mmu.c:14:0: > > include/linux/swapops.h: In function ‘pte_to_swp_entry’: > > include/linux/swapops.h:69:6: error: implicit declaration of function > > ‘pte_swp_soft_dirty’ [-Werror=implicit-function-declaration] > > if (pte_swp_soft_dirty(pte)) > > ^ > > include/linux/swapops.h:70:9: error: implicit declaration of function > > ‘pte_swp_clear_soft_dirty’ [-Werror=implicit-function-declaration] > >pte = pte_swp_clear_soft_dirty(pte); > > ^ > > Can you try the patch posted here: https://lkml.org/lkml/2016/1/25/554 > > Thanks! > -- > Pranith > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/ifc: Segregate IFC fcm and runtime registers
On Mon, Feb 1, 2016 at 4:46 AM, Raghav Dogra wrote: A general comment is that you should include the linux-mtd mailing list and it's maintainers for this set of patches. Although the MAINTAINERS file doesn't specify a maintainer for drivers/memory directory, it should be most related to linux-mtd, IMO. > IFC has two set of registers viz FCM (Flash control machine) > aka global and run time registers. These set are defined in two > memory map PAGES. Upto IFC 1.4 PAGE size is 4 KB and from IFC2.0 > PAGE size is 64KB So I guess this patch is the critical change to make the fsl_ifc driver work with the version 2.0 hardware block? If so, it will be better to mention this in the patch title. > > Signed-off-by: Jaiprakash Singh > Signed-off-by: Raghav Dogra > --- > drivers/memory/fsl_ifc.c| 251 > +--- > drivers/mtd/nand/fsl_ifc_nand.c | 72 ++-- > include/linux/fsl_ifc.h | 48 +--- > 3 files changed, 203 insertions(+), 168 deletions(-) Regards, Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] drivers: macintosh: rack-meter: fix bogus memsets
Fix bogus memsets pointed out by sparse: linux-v4.3/drivers/macintosh/rack-meter.c:157:15: warning: memset with byte count of 0 linux-v4.3/drivers/macintosh/rack-meter.c:158:15: warning: memset with byte count of 0 Probably "&" is mistyped "*"; use ARRAY_SIZE to make it more safe. Signed-off-by: Aaro Koskinen --- drivers/macintosh/rack-meter.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/macintosh/rack-meter.c b/drivers/macintosh/rack-meter.c index ba7e330..465c522 100644 --- a/drivers/macintosh/rack-meter.c +++ b/drivers/macintosh/rack-meter.c @@ -154,8 +154,8 @@ static void rackmeter_do_pause(struct rackmeter *rm, int pause) DBDMA_DO_STOP(rm->dma_regs); return; } - memset(rdma->buf1, 0, SAMPLE_COUNT & sizeof(u32)); - memset(rdma->buf2, 0, SAMPLE_COUNT & sizeof(u32)); + memset(rdma->buf1, 0, ARRAY_SIZE(rdma->buf1)); + memset(rdma->buf2, 0, ARRAY_SIZE(rdma->buf2)); rm->dma_buf_v->mark = 0; -- 2.4.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] drivers: macintosh: rack-meter: limit idle ticks to total ticks
Limit idle ticks to total ticks. This prevents the annoying rackmeter leds fully ON / OFF blinking state that happens on fully idling G5 Xserve systems. Signed-off-by: Aaro Koskinen --- drivers/macintosh/rack-meter.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/macintosh/rack-meter.c b/drivers/macintosh/rack-meter.c index caaec65..ba7e330 100644 --- a/drivers/macintosh/rack-meter.c +++ b/drivers/macintosh/rack-meter.c @@ -227,6 +227,7 @@ static void rackmeter_do_timer(struct work_struct *work) total_idle_ticks = get_cpu_idle_time(cpu); idle_ticks = (unsigned int) (total_idle_ticks - rcpu->prev_idle); + idle_ticks = min(idle_ticks, total_ticks); rcpu->prev_idle = total_idle_ticks; /* We do a very dumb calculation to update the LEDs for now, -- 2.4.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc64 boot: Wait for boot cpu to show up if nr_cpus limit is about to hit.
Hi Mahesh,
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.5-rc2 next-20160201]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Mahesh-J-Salgaonkar/ppc64-boot-Wait-for-boot-cpu-to-show-up-if-nr_cpus-limit-is-about-to-hit/20160202-012114
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allnoconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
arch/powerpc/kernel/prom.c: In function 'early_init_dt_scan_cpus':
>> arch/powerpc/kernel/prom.c:345:14: error: lvalue required as left operand of
>> assignment
nr_cpu_ids = _ALIGN_UP(nr_cpu_ids, nthreads);
^
vim +345 arch/powerpc/kernel/prom.c
339
340 /*
341 * Now that we know threads per core lets align nr_cpu_ids to
342 * correct SMT value.
343 */
344 if (nr_cpu_ids % nthreads) {
> 345 nr_cpu_ids = _ALIGN_UP(nr_cpu_ids, nthreads);
346 pr_info("Aligned nr_cpus to SMT=%d, nr_cpu_ids = %d\n",
347 nthreads, nr_cpu_ids);
348 }
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ppc64 boot: Wait for boot cpu to show up if nr_cpus limit is about to hit.
From: Mahesh Salgaonkar
The kernel boot parameter 'nr_cpus=' allows one to specify number of
possible cpus in the system. In the normal scenario the first cpu (cpu0)
that shows up is the boot cpu and hence it gets covered under nr_cpus
limit.
But this assumption will be broken in kdump scenario where kdump kenrel
after a crash can boot up on an non-zero boot cpu. The paca structure
allocation depends on value of nr_cpus and is indexed using logical cpu
ids. This definetly will be an issue if boot cpu id > nr_cpus
This patch modifies allocate_pacas() and smp_setup_cpu_maps() to
accommodate boot cpu for the case where boot_cpuid > nr_cpu_ids.
This change would help to reduce the memory reservation requirement for
kdump on ppc64.
Signed-off-by: Mahesh Salgaonkar
---
arch/powerpc/include/asm/paca.h|3 +++
arch/powerpc/include/asm/smp.h |1 +
arch/powerpc/kernel/paca.c | 23 ++
arch/powerpc/kernel/prom.c | 37 +++-
arch/powerpc/kernel/setup-common.c | 25
5 files changed, 83 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 70bd438..9be48b4 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -41,6 +41,9 @@ extern unsigned int debug_smp_processor_id(void); /* from
linux/smp.h */
#define get_lppaca() (get_paca()->lppaca_ptr)
#define get_slb_shadow() (get_paca()->slb_shadow_ptr)
+/* Maximum number of threads per core. */
+#defineMAX_SMT 8
+
struct task_struct;
/*
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 825663c..0a5b99f 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -30,6 +30,7 @@
#include
extern int boot_cpuid;
+extern int boot_hw_cpuid;
extern int spinning_secondaries;
extern void cpu_die(void);
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 01ea0ed..96e5715 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -206,6 +206,7 @@ void __init allocate_pacas(void)
{
u64 limit;
int cpu;
+ int nr_cpus;
limit = ppc64_rma_size;
@@ -218,20 +219,32 @@ void __init allocate_pacas(void)
limit = min(0x1000ULL, limit);
#endif
- paca_size = PAGE_ALIGN(sizeof(struct paca_struct) * nr_cpu_ids);
+ /*
+* Always align up the nr_cpu_ids to SMT threads and allocate
+* the paca. This will help us to prepare for a situation where
+* boot cpu id > nr_cpus_id. We will use the last nthreads
+* slots (nthreads == threads per core) to accommodate a core
+* that contains boot cpu thread.
+*
+* Do not change nr_cpu_ids value here. Let us do that in
+* early_init_dt_scan_cpus() where we know exact value
+* of threads per core.
+*/
+ nr_cpus = _ALIGN_UP(nr_cpu_ids, MAX_SMT);
+ paca_size = PAGE_ALIGN(sizeof(struct paca_struct) * nr_cpus);
paca = __va(memblock_alloc_base(paca_size, PAGE_SIZE, limit));
memset(paca, 0, paca_size);
printk(KERN_DEBUG "Allocated %u bytes for %d pacas at %p\n",
- paca_size, nr_cpu_ids, paca);
+ paca_size, nr_cpus, paca);
- allocate_lppacas(nr_cpu_ids, limit);
+ allocate_lppacas(nr_cpus, limit);
- allocate_slb_shadows(nr_cpu_ids, limit);
+ allocate_slb_shadows(nr_cpus, limit);
/* Can't use for_each_*_cpu, as they aren't functional yet */
- for (cpu = 0; cpu < nr_cpu_ids; cpu++)
+ for (cpu = 0; cpu < nr_cpus; cpu++)
initialise_paca(&paca[cpu], cpu);
}
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 7030b03..9d1568f 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -291,6 +291,29 @@ static void __init check_cpu_feature_properties(unsigned
long node)
}
}
+/*
+ * Adjust the logical id of a boot cpu to fall under nr_cpu_ids. Map it to
+ * last core slot in the allocated paca array.
+ *
+ * e.g. on SMT=8 system, kernel booted with nr_cpus=1 and boot cpu = 33,
+ * align nr_cpu_ids to MAX_SMT value 8. Allocate paca array to hold up-to
+ * MAX_SMT=8 cpus. Since boot cpu 33 is greater than nr_cpus (8), adjust
+ * its logical id so that new id becomes less than nr_cpu_ids. Make sure
+ * that boot cpu's new logical id is aligned to its thread id and falls
+ * under last nthreads slots available in paca array. In this case the
+ * boot cpu 33 is adjusted to new boot cpu id 1.
+ *
+ */
+static inline void adjust_boot_cpuid(int nthreads, int phys_id)
+{
+ boot_hw_cpuid = phys_id;
+ if (boot_cpuid >= nr_cpu_ids) {
+ boot_cpuid = (boot_cpuid % nthreads) + (nr_cpu_ids - nthreads);
+ pr_info("Adjusted logical boot cpu id: logical %d physical
%d\n",
+ boo
Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults
On 01.02.2016 13:25, Maciej S. Szmigiero wrote:
> On 01.02.2016 13:13, Fabio Estevam wrote:
>> Hi Maciej,
>>
>> On Mon, Feb 1, 2016 at 10:07 AM, Maciej S. Szmigiero
>> wrote:
>>> Is regmap patch from
>>> http://www.spinics.net/lists/kernel/msg2161934.html
>>> applied to the tested tree?
>>
>> Yes, linux-next 20160201 contains this patch.
>
> Hmm, I will try to build this tree on UDOO board
> today and see what happens.
Looks like the problem occurs because commit
922a9f936e40 ("regmap: mmio: Convert to regmap_bus and fix accessor usage")
has removed ->read callback from MMIO regmap
implementation but it is used (via regmap_raw_read()) by
regcache code to initialize cache if reg default values
weren't provided explicitly.
If I revert this commit the SSI probes successfully again.
Looks like a possible solution would be to change
regmap_raw_read() to do read using _regmap_read in
case the cache is bypassed and there is no ->read
callback defined for regmap implementation.
Maciej
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] lib: fix callers of strtobool to use char array
On Thu, Jan 28, 2016 at 4:17 PM, Kees Cook wrote:
> Some callers of strtobool were passing a pointer to unterminated strings.
> This fixes the issue and consolidates some logic in cifs.
My comments below.
First of all I don't think currently there is an issue in cifs, since
strbool checks only first character of the input string, or are you
talking about something else?
> diff --git a/drivers/net/wireless/marvell/mwifiex/debugfs.c
> b/drivers/net/wireless/marvell/mwifiex/debugfs.c
> index 0b9c580af988..76af60899c69 100644
> --- a/drivers/net/wireless/marvell/mwifiex/debugfs.c
> +++ b/drivers/net/wireless/marvell/mwifiex/debugfs.c
> @@ -880,13 +880,13 @@ mwifiex_reset_write(struct file *file,
> {
> struct mwifiex_private *priv = file->private_data;
> struct mwifiex_adapter *adapter = priv->adapter;
> - char cmd;
> + char cmd[2] = { '\0' };
> bool result;
>
> - if (copy_from_user(&cmd, ubuf, sizeof(cmd)))
> + if (copy_from_user(cmd, ubuf, sizeof(char)))
> return -EFAULT;
>
> - if (strtobool(&cmd, &result))
> + if (strtobool(cmd, &result))
> return -EINVAL;
Can we do strtobool_from_user() instead like kstrto*from_user() and
similar helpers are done?
>
> if (!result)
> diff --git a/fs/cifs/cifs_debug.c b/fs/cifs/cifs_debug.c
> index 50b268483302..2f7ffcc9e364 100644
> --- a/fs/cifs/cifs_debug.c
> +++ b/fs/cifs/cifs_debug.c
> @@ -251,11 +251,29 @@ static const struct file_operations
> cifs_debug_data_proc_fops = {
> .release= single_release,
> };
>
> +static int get_user_bool(const char __user *buffer, bool *store)
> +{
> + char c[2] = { '\0' };
> + bool bv;
> + int rc;
> +
> + rc = get_user(c[0], buffer);
> + if (rc)
> + return rc;
> +
> + rc = strtobool(c, &bv);
> + if (rc)
> + return rc;
> +
> + *store = bv;
> +
> + return 0;
> +}
> +
> #ifdef CONFIG_CIFS_STATS
> static ssize_t cifs_stats_proc_write(struct file *file,
> const char __user *buffer, size_t count, loff_t *ppos)
> {
> - char c;
> bool bv;
> int rc;
> struct list_head *tmp1, *tmp2, *tmp3;
> @@ -263,34 +281,32 @@ static ssize_t cifs_stats_proc_write(struct file *file,
> struct cifs_ses *ses;
> struct cifs_tcon *tcon;
>
> - rc = get_user(c, buffer);
> + rc = get_user_bool(buffer, &bv);
> if (rc)
> return rc;
>
> - if (strtobool(&c, &bv) == 0) {
> #ifdef CONFIG_CIFS_STATS2
I would suggest to do a separate patch which just changes a pattern
and thus indentation without changing anything in functionality.
> - atomic_set(&totBufAllocCount, 0);
> - atomic_set(&totSmBufAllocCount, 0);
> + atomic_set(&totBufAllocCount, 0);
> + atomic_set(&totSmBufAllocCount, 0);
> #endif /* CONFIG_CIFS_STATS2 */
> - spin_lock(&cifs_tcp_ses_lock);
> - list_for_each(tmp1, &cifs_tcp_ses_list) {
> - server = list_entry(tmp1, struct TCP_Server_Info,
> - tcp_ses_list);
> - list_for_each(tmp2, &server->smb_ses_list) {
> - ses = list_entry(tmp2, struct cifs_ses,
> -smb_ses_list);
> - list_for_each(tmp3, &ses->tcon_list) {
> - tcon = list_entry(tmp3,
> - struct cifs_tcon,
> - tcon_list);
> - atomic_set(&tcon->num_smbs_sent, 0);
> - if (server->ops->clear_stats)
> -
> server->ops->clear_stats(tcon);
> - }
> + spin_lock(&cifs_tcp_ses_lock);
> + list_for_each(tmp1, &cifs_tcp_ses_list) {
> + server = list_entry(tmp1, struct TCP_Server_Info,
> + tcp_ses_list);
> + list_for_each(tmp2, &server->smb_ses_list) {
> + ses = list_entry(tmp2, struct cifs_ses,
> +smb_ses_list);
> + list_for_each(tmp3, &ses->tcon_list) {
> + tcon = list_entry(tmp3,
> + struct cifs_tcon,
> + tcon_list);
> + atomic_set(&tcon->num_smbs_sent, 0);
> + if (server->ops->clear_stats)
> + server->ops->clear_stats(tcon);
> }
> }
> - spin_unlock(&cifs_tcp_ses_lock);
> }
> + spin_unlock(&cifs_tcp_ses_lock);
>
>
Re: [PATCH 0/2] Two patches regarding EEH availability checks - DLPAR/DDW
Hello Michael and Benjamin, any news on this one? Quick correction in this email subject: it was cropped because it's too long. The full title was "[PATCH 0/2] Two patches regarding EEH availability checks - DLPAR/DDW crash avoidance" ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults
On 01.02.2016 13:13, Fabio Estevam wrote: > Hi Maciej, > > On Mon, Feb 1, 2016 at 10:07 AM, Maciej S. Szmigiero > wrote: >> Is regmap patch from >> http://www.spinics.net/lists/kernel/msg2161934.html >> applied to the tested tree? > > Yes, linux-next 20160201 contains this patch. Hmm, I will try to build this tree on UDOO board today and see what happens. Maciej ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults
Hi Maciej, On Mon, Feb 1, 2016 at 10:07 AM, Maciej S. Szmigiero wrote: > Is regmap patch from > http://www.spinics.net/lists/kernel/msg2161934.html > applied to the tested tree? Yes, linux-next 20160201 contains this patch. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults
Hi Fabio,
On 01.02.2016 13:05, Fabio Estevam wrote:
> Hi Maciej,
>
> On Mon, Jan 18, 2016 at 5:07 PM, Maciej S. Szmigiero
> wrote:
>> There is no guarantee that on fsl_ssi module load
>> SSI registers will have their power-on-reset values.
>>
>> In fact, if the driver is reloaded the values in
>> registers will be whatever they were set to previously.
>>
>> However, the cache needs to be fully populated at probe
>> time to avoid non-atomic allocations during register
>> access.
>>
>> Special case here is imx21-class SSI, since
>> according to datasheet it don't have SACC{ST,EN,DIS}
>> regs.
>>
>> This fixes hard lockup on fsl_ssi module reload,
>> at least in AC'97 mode.
>>
>> Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to
>> support MEGA Fast")
>>
>> Signed-off-by: Maciej S. Szmigiero
>
> I know I have already tested this and it worked fine on a mx6sabresd,
> but running linux-next 20160201 on a mx6sl-evk the ssi driver does not
> probe anymore:
>
> [2.216954] fsl-asoc-card sound: ASoC: CPU DAI (null) not registered
> [2.223412] fsl-asoc-card sound: snd_soc_register_card failed (-517)
> [2.230258] imx-wm8962 sound: ASoC: CPU DAI 202c000.ssi not registered
> [2.236806] imx-wm8962 sound: snd_soc_register_card failed (-517)
> [2.244782] snvs_rtc 20cc000.snvs:snvs-rtc-lp: setting system clock
> to 1970-01-01 00:01:14 UTC (74)
> [2.285864] fsl-asoc-card sound: ASoC: CPU DAI (null) not registered
> [2.292335] fsl-asoc-card sound: snd_soc_register_card failed (-517)
> [2.299572] imx-wm8962 sound: ASoC: CPU DAI 202c000.ssi not registered
> [2.306121] imx-wm8962 sound: snd_soc_register_card failed (-517)
>
> Reverting this patch fixes the problem.
>
> Wandboard also has the same issue:
>
> http://arm-soc.lixom.net/bootlogs/next/next-20160201/wandboard-arm-imx_v6_v7_defconfig.html
>
> Any suggestions?
>
> Thanks
>
Is regmap patch from
http://www.spinics.net/lists/kernel/msg2161934.html
applied to the tested tree?
Best regards,
Maciej
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: remove explicit register defaults
Hi Maciej,
On Mon, Jan 18, 2016 at 5:07 PM, Maciej S. Szmigiero
wrote:
> There is no guarantee that on fsl_ssi module load
> SSI registers will have their power-on-reset values.
>
> In fact, if the driver is reloaded the values in
> registers will be whatever they were set to previously.
>
> However, the cache needs to be fully populated at probe
> time to avoid non-atomic allocations during register
> access.
>
> Special case here is imx21-class SSI, since
> according to datasheet it don't have SACC{ST,EN,DIS}
> regs.
>
> This fixes hard lockup on fsl_ssi module reload,
> at least in AC'97 mode.
>
> Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support
> MEGA Fast")
>
> Signed-off-by: Maciej S. Szmigiero
I know I have already tested this and it worked fine on a mx6sabresd,
but running linux-next 20160201 on a mx6sl-evk the ssi driver does not
probe anymore:
[2.216954] fsl-asoc-card sound: ASoC: CPU DAI (null) not registered
[2.223412] fsl-asoc-card sound: snd_soc_register_card failed (-517)
[2.230258] imx-wm8962 sound: ASoC: CPU DAI 202c000.ssi not registered
[2.236806] imx-wm8962 sound: snd_soc_register_card failed (-517)
[2.244782] snvs_rtc 20cc000.snvs:snvs-rtc-lp: setting system clock
to 1970-01-01 00:01:14 UTC (74)
[2.285864] fsl-asoc-card sound: ASoC: CPU DAI (null) not registered
[2.292335] fsl-asoc-card sound: snd_soc_register_card failed (-517)
[2.299572] imx-wm8962 sound: ASoC: CPU DAI 202c000.ssi not registered
[2.306121] imx-wm8962 sound: snd_soc_register_card failed (-517)
Reverting this patch fixes the problem.
Wandboard also has the same issue:
http://arm-soc.lixom.net/bootlogs/next/next-20160201/wandboard-arm-imx_v6_v7_defconfig.html
Any suggestions?
Thanks
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] driver/memory: Update dependency of IFC for Layerscape
IFC NAND is not working on ARM layescape platform due to undefined macro FSL_SOC. This patch fixes the dependency to enable NAND. Signed-off-by: Raghav Dogra --- drivers/memory/Kconfig | 2 +- drivers/memory/fsl_ifc.c | 4 +++- drivers/mtd/nand/Kconfig | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 6f31546..7365ecf 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -103,7 +103,7 @@ config FSL_CORENET_CF config FSL_IFC bool - depends on FSL_SOC + depends on FSL_SOC || ARCH_LAYERSCAPE config JZ4780_NEMC bool "Ingenic JZ4780 SoC NEMC driver" diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c index 054809e..f82a245 100644 --- a/drivers/memory/fsl_ifc.c +++ b/drivers/memory/fsl_ifc.c @@ -31,7 +31,9 @@ #include #include #include -#include +#include +#include +#include struct fsl_ifc_ctrl *fsl_ifc_ctrl_dev; EXPORT_SYMBOL(fsl_ifc_ctrl_dev); diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 2896640..0c460e4 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -436,7 +436,7 @@ config MTD_NAND_FSL_ELBC config MTD_NAND_FSL_IFC tristate "NAND support for Freescale IFC controller" - depends on MTD_NAND && FSL_SOC + depends on MTD_NAND && (FSL_SOC || ARCH_LAYERSCAPE) select FSL_IFC select MEMORY help -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFCv2 7/9] pseries: Add support for hash table resizing
On Mon, Feb 01, 2016 at 02:01:09PM +0530, Anshuman Khandual wrote:
> On 01/29/2016 10:54 AM, David Gibson wrote:
>
> > +
> > +static int pseries_lpar_resize_hpt_commit(void *data)
> > +{
> > + struct hpt_resize_state *state = data;
> > +
> > + state->commit_rc = plpar_resize_hpt_commit(0, state->shift);
> > + if (state->commit_rc != H_SUCCESS)
> > + return -EIO;
> > +
> > + /* Hypervisor has transitioned the HTAB, update our globals */
> > + ppc64_pft_size = state->shift;
> > + htab_size_bytes = 1UL << ppc64_pft_size;
> > + htab_hash_mask = (htab_size_bytes >> 7) - 1;
> > +
> > + return 0;
> > +}
> > +
>
> snip
>
> > +/* Must be called in user context */
> > +static int pseries_lpar_resize_hpt(unsigned long shift)
> > +{
> > + struct hpt_resize_state state = {
> > + .shift = shift,
> > + .commit_rc = H_FUNCTION,
>
> > +
> > + rc = stop_machine(pseries_lpar_resize_hpt_commit, &state, NULL);
>
> With my limited knowledge of stop_machine, wondering if the current
> or any future version of 'pseries_lpar_resize_hpt_commit' function
> can cause HPT change (page fault path) while stop is executing it.
It can, but the H_RESIZE_HPT_COMMIT hypercall is synchronous so the
cpu executing it can't make any HPT updates during it. The
stop_machine() prevents any other cpus doing HPT updates.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFCv2 9/9] pseries: Automatically resize HPT for memory hot add/remove
On Mon, Feb 01, 2016 at 02:21:46PM +0530, Anshuman Khandual wrote:
> On 01/29/2016 10:54 AM, David Gibson wrote:
> > #ifdef CONFIG_MEMORY_HOTPLUG
> > +void resize_hpt_for_hotplug(unsigned long new_mem_size)
> > +{
> > + unsigned target_hpt_shift;
> > +
> > + if (!ppc_md.resize_hpt)
> > + return;
> > +
> > + target_hpt_shift = htab_shift_for_mem_size(new_mem_size);
> > +
> > + /*
> > +* To avoid lots of HPT resizes if memory size is fluctuating
> > +* across a boundary, we deliberately have some hysterisis
>
>
> What do you mean by 'memory size is fluctuating across a boundary' ?
> Through memory hotplug interface ? Why some one will do that ?
I was thinking it might be possible to have some management system
that automatically adjusts memory size based on load, and if that
happened to land on a boundary you could get nasty behaviour.
> I
> can understand why we dont have this check in the sysfs debug path
> as we would like to test any memory HPT re sizing scenario we want
> in any sequence of increase or decrease we want.
>
> Overall the RFC V2 looks pretty good. Looking forward to see the
> host side of the code for this feature.
The qemu host side has been posted to qemu-de...@nongnu.org already.
I haven't started on a KVM HV implementation yet.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] mtd/ifc: Segregate IFC fcm and runtime registers
IFC has two set of registers viz FCM (Flash control machine)
aka global and run time registers. These set are defined in two
memory map PAGES. Upto IFC 1.4 PAGE size is 4 KB and from IFC2.0
PAGE size is 64KB
Signed-off-by: Jaiprakash Singh
Signed-off-by: Raghav Dogra
---
drivers/memory/fsl_ifc.c| 251 +---
drivers/mtd/nand/fsl_ifc_nand.c | 72 ++--
include/linux/fsl_ifc.h | 48 +---
3 files changed, 203 insertions(+), 168 deletions(-)
diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c
index f82a245..e2bd85b 100644
--- a/drivers/memory/fsl_ifc.c
+++ b/drivers/memory/fsl_ifc.c
@@ -63,11 +63,11 @@ int fsl_ifc_find(phys_addr_t addr_base)
{
int i = 0;
- if (!fsl_ifc_ctrl_dev || !fsl_ifc_ctrl_dev->regs)
+ if (!fsl_ifc_ctrl_dev || !fsl_ifc_ctrl_dev->gregs)
return -ENODEV;
for (i = 0; i < fsl_ifc_ctrl_dev->banks; i++) {
- u32 cspr = ifc_in32(&fsl_ifc_ctrl_dev->regs->cspr_cs[i].cspr);
+ u32 cspr = ifc_in32(&fsl_ifc_ctrl_dev->gregs->cspr_cs[i].cspr);
if (cspr & CSPR_V && (cspr & CSPR_BA) ==
convert_ifc_address(addr_base))
return i;
@@ -79,7 +79,7 @@ EXPORT_SYMBOL(fsl_ifc_find);
static int fsl_ifc_ctrl_init(struct fsl_ifc_ctrl *ctrl)
{
- struct fsl_ifc_regs __iomem *ifc = ctrl->regs;
+ struct fsl_ifc_fcm __iomem *ifc = ctrl->gregs;
/*
* Clear all the common status and event registers
@@ -108,7 +108,7 @@ static int fsl_ifc_ctrl_remove(struct platform_device *dev)
irq_dispose_mapping(ctrl->nand_irq);
irq_dispose_mapping(ctrl->irq);
- iounmap(ctrl->regs);
+ iounmap(ctrl->gregs);
dev_set_drvdata(&dev->dev, NULL);
kfree(ctrl);
@@ -126,7 +126,7 @@ static DEFINE_SPINLOCK(nand_irq_lock);
static u32 check_nand_stat(struct fsl_ifc_ctrl *ctrl)
{
- struct fsl_ifc_regs __iomem *ifc = ctrl->regs;
+ struct fsl_ifc_runtime __iomem *ifc = ctrl->rregs;
unsigned long flags;
u32 stat;
@@ -161,7 +161,7 @@ static irqreturn_t fsl_ifc_nand_irq(int irqno, void *data)
static irqreturn_t fsl_ifc_ctrl_irq(int irqno, void *data)
{
struct fsl_ifc_ctrl *ctrl = data;
- struct fsl_ifc_regs __iomem *ifc = ctrl->regs;
+ struct fsl_ifc_fcm __iomem *ifc = ctrl->gregs;
u32 err_axiid, err_srcid, status, cs_err, err_addr;
irqreturn_t ret = IRQ_NONE;
@@ -219,6 +219,7 @@ static int fsl_ifc_ctrl_probe(struct platform_device *dev)
{
int ret = 0;
int version, banks;
+ void __iomem *addr;
dev_info(&dev->dev, "Freescale Integrated Flash Controller\n");
@@ -229,22 +230,13 @@ static int fsl_ifc_ctrl_probe(struct platform_device *dev)
dev_set_drvdata(&dev->dev, fsl_ifc_ctrl_dev);
/* IOMAP the entire IFC region */
- fsl_ifc_ctrl_dev->regs = of_iomap(dev->dev.of_node, 0);
- if (!fsl_ifc_ctrl_dev->regs) {
+ fsl_ifc_ctrl_dev->gregs = of_iomap(dev->dev.of_node, 0);
+ if (!fsl_ifc_ctrl_dev->gregs) {
dev_err(&dev->dev, "failed to get memory region\n");
ret = -ENODEV;
goto err;
}
- version = ifc_in32(&fsl_ifc_ctrl_dev->regs->ifc_rev) &
- FSL_IFC_VERSION_MASK;
- banks = (version == FSL_IFC_VERSION_1_0_0) ? 4 : 8;
- dev_info(&dev->dev, "IFC version %d.%d, %d banks\n",
- version >> 24, (version >> 16) & 0xf, banks);
-
- fsl_ifc_ctrl_dev->version = version;
- fsl_ifc_ctrl_dev->banks = banks;
-
if (of_property_read_bool(dev->dev.of_node, "little-endian")) {
fsl_ifc_ctrl_dev->little_endian = true;
dev_dbg(&dev->dev, "IFC REGISTERS are LITTLE endian\n");
@@ -253,8 +245,9 @@ static int fsl_ifc_ctrl_probe(struct platform_device *dev)
dev_dbg(&dev->dev, "IFC REGISTERS are BIG endian\n");
}
- version = ioread32be(&fsl_ifc_ctrl_dev->regs->ifc_rev) &
+ version = ifc_in32(&fsl_ifc_ctrl_dev->gregs->ifc_rev) &
FSL_IFC_VERSION_MASK;
+
banks = (version == FSL_IFC_VERSION_1_0_0) ? 4 : 8;
dev_info(&dev->dev, "IFC version %d.%d, %d banks\n",
version >> 24, (version >> 16) & 0xf, banks);
@@ -262,6 +255,14 @@ static int fsl_ifc_ctrl_probe(struct platform_device *dev)
fsl_ifc_ctrl_dev->version = version;
fsl_ifc_ctrl_dev->banks = banks;
+ addr = fsl_ifc_ctrl_dev->gregs;
+ if (version >= FSL_IFC_VERSION_2_0_0)
+ fsl_ifc_ctrl_dev->rregs =
+ (struct fsl_ifc_runtime *)(addr + PGOFFSET_64K);
+ else
+ fsl_ifc_ctrl_dev->rregs =
+ (struct fsl_ifc_runtime *)(addr + PGOFFSET_4K);
+
/* get the Controller level irq */
fsl_ifc_ctrl_dev->irq = irq_of_parse_and_map(dev->dev.of_n
[PATCH 1/3] driver/memory: Removal of deprecated NO_IRQ
Replacing the NO_IRQ macro with 0. If there is no interrupt,
returned value will be 0 regardless of what NO_IRQ is defined.
Signed-off-by: Raghav Dogra
---
This patchset is dependent on the IFC deep sleep patch:
https://patchwork.ozlabs.org/patch/564785/
drivers/memory/fsl_ifc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c
index f5186fa..054809e 100644
--- a/drivers/memory/fsl_ifc.c
+++ b/drivers/memory/fsl_ifc.c
@@ -262,7 +262,7 @@ static int fsl_ifc_ctrl_probe(struct platform_device *dev)
/* get the Controller level irq */
fsl_ifc_ctrl_dev->irq = irq_of_parse_and_map(dev->dev.of_node, 0);
- if (fsl_ifc_ctrl_dev->irq == NO_IRQ) {
+ if (fsl_ifc_ctrl_dev->irq == 0) {
dev_err(&dev->dev, "failed to get irq resource "
"for IFC\n");
ret = -ENODEV;
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fix kgdb on little endian ppc64le
On 01/02/16 17:03, Balbir Singh wrote: From: Balbir Singh I spent some time trying to use kgdb and debugged my inability to resume from kgdb_handle_breakpoint(). NIP is not incremented and that leads to a loop in the debugger. I've tested this lightly on a virtual instance with KDB enabled. After the patch, I am able to get the "go" command to work as expected Signed-off-by: Balbir Singh Should this be Cc'd to stable? -- Andrew Donnellan Software Engineer, OzLabs andrew.donnel...@au1.ibm.com Australia Development Lab, Canberra +61 2 6201 8874 (work)IBM Australia Limited ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 3/5] PCI: Add host bridge attribute to indicate filtering of MSIs is supported
On 2016/1/30 3:05, Alex Williamson wrote:
- Original Message -
On 2016/1/29 6:46, Alex Williamson wrote:
On Fri, 2016-01-15 at 15:06 +0800, Yongji Xie wrote:
MSI-X tables are not allowed to be mmapped in vfio-pci
driver in case that user get to touch this directly.
This will cause some performance issues when when PCI
adapters have critical registers in the same page as
the MSI-X table.
However, some kind of PCI host bridge such as IODA bridge
on Power support filtering of MSIs, which can ensure that a
given pci device can only shoot the MSIs assigned for it.
So we think it's safe to expose the MSI-X table to userspace
if filtering of MSIs is supported because the exposed MSI-X
table can't be used to do harm to other memory space.
To support this case, this patch adds a pci_host_bridge
attribute to indicate if this PCI host bridge supports
filtering of MSIs.
Signed-off-by: Yongji Xie
---
drivers/pci/host-bridge.c |6 ++
include/linux/pci.h |3 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index 5f4a2e0..c029267 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -96,3 +96,9 @@ void pcibios_bus_to_resource(struct pci_bus *bus, struct
resource *res,
res->end = region->end + offset;
}
EXPORT_SYMBOL(pcibios_bus_to_resource);
+
+bool pci_host_bridge_msi_filtered_enabled(struct pci_dev *pdev)
+{
+ return pci_find_host_bridge(pdev->bus)->msi_filtered;
+}
+EXPORT_SYMBOL_GPL(pci_host_bridge_msi_filtered_enabled);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index b640d65..b952b78 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -412,6 +412,7 @@ struct pci_host_bridge {
void (*release_fn)(struct pci_host_bridge *);
void *release_data;
unsigned int ignore_reset_delay:1; /* for entire hierarchy */
+ unsigned int msi_filtered:1;/* support filtering of MSIs */
/* Resource alignment requirements */
resource_size_t (*align_resource)(struct pci_dev *dev,
const struct resource *res,
@@ -430,6 +431,8 @@ void pci_set_host_bridge_release(struct
pci_host_bridge *bridge,
int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge);
+bool pci_host_bridge_msi_filtered_enabled(struct pci_dev *pdev);
+
/*
* The first PCI_BRIDGE_RESOURCE_NUM PCI bus resources (those that
correspond
* to P2P or CardBus bridge windows) go in a table. Additional ones
(for
Don't we already have a flag for this in the IOMMU space?
enum iommu_cap {
IOMMU_CAP_CACHE_COHERENCY, /* IOMMU can enforce cache
coherent DMA
transactions */
--->IOMMU_CAP_INTR_REMAP, /* IOMMU supports interrupt
isolation */
IOMMU_CAP_NOEXEC, /* IOMMU_NOEXEC flag */
};
I saw this flag had been enabled in x86 and ARM arch.
I'm not sure whether we can mmap MSI-X table in those archs. I just
verify it on PPC64 arch.
Unfortunately that's not a very good excuse for creating an alternate
implementation. When x86 implements interrupt remapping, we get fine grained
isolation of MSI vectors and we've always taken this flag to mean that the
system is isolated from devices that may perform DoS attacks with MSI writes.
I'm not entirely sure whether ARM really provides that degree of isolation, but
they would be incorrect is exposing the capability if they do not. Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OK, I will use this flag in next version. Thanks.
Regards,
Yongji Xie
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFCv2 9/9] pseries: Automatically resize HPT for memory hot add/remove
On 01/29/2016 10:54 AM, David Gibson wrote:
> #ifdef CONFIG_MEMORY_HOTPLUG
> +void resize_hpt_for_hotplug(unsigned long new_mem_size)
> +{
> + unsigned target_hpt_shift;
> +
> + if (!ppc_md.resize_hpt)
> + return;
> +
> + target_hpt_shift = htab_shift_for_mem_size(new_mem_size);
> +
> + /*
> + * To avoid lots of HPT resizes if memory size is fluctuating
> + * across a boundary, we deliberately have some hysterisis
What do you mean by 'memory size is fluctuating across a boundary' ?
Through memory hotplug interface ? Why some one will do that ? I
can understand why we dont have this check in the sysfs debug path
as we would like to test any memory HPT re sizing scenario we want
in any sequence of increase or decrease we want.
Overall the RFC V2 looks pretty good. Looking forward to see the
host side of the code for this feature.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 1/5] PCI: Add support for enforcing all MMIO BARs to be page aligned
On 2016/1/30 3:01, Alex Williamson wrote:
On Fri, 2016-01-29 at 18:37 +0800, Yongji Xie wrote:
On 2016/1/29 6:46, Alex Williamson wrote:
On Fri, 2016-01-15 at 15:06 +0800, Yongji Xie wrote:
When vfio passthrough a PCI device of which MMIO BARs
are smaller than PAGE_SIZE, guest will not handle the
mmio accesses to the BARs which leads to mmio emulations
in host.
This is because vfio will not allow to passthrough one
BAR's mmio page which may be shared with other BARs.
To solve this performance issue, this patch adds a kernel
parameter "pci=resource_page_aligned=on" to enforce
the alignment of all MMIO BARs to be at least PAGE_SIZE,
so that one BAR's mmio page would not be shared with other
BARs. We can also disable it through kernel parameter
"pci=resource_page_aligned=off".
For the default value of the parameter, we think it should be
arch-independent, so we add a macro
HAVE_PCI_DEFAULT_RESOURCES_PAGE_ALIGNED to change it. And we
define this macro to enable this parameter by default on PPC64
platform which can easily hit this performance issue because
its PAGE_SIZE is 64KB.
Note that the kernel parameter won't works if kernel doesn't do
resources reallocation.
And where do you account for this so that we know whether it's really in
effect?
We can check the flag PCI_PROBE_ONLY to know whether kernel do
resources reallocation. Then we know if the kernel parameter is really
in effect.
enum {
/* Force re-assigning all resources (ignore firmware
* setup completely)
*/
PCI_REASSIGN_ALL_RSRC= 0x0001,
/* Re-assign all bus numbers */
PCI_REASSIGN_ALL_BUS= 0x0002,
/* Do not try to assign, just use existing setup */
--->PCI_PROBE_ONLY= 0x0004,
And I will add this to commit log.
We need more than a commit log entry for this, what's the purpose of the
pci_resources_share_page() function if we don't know if this is in
effect?
It seems the parameter will be always in effect if we reuse the
re-aligning code
of parameter "resource_alignment=" in pci_reassigndev_resource_alignment().
Signed-off-by: Yongji Xie
---
Documentation/kernel-parameters.txt |5 +
arch/powerpc/include/asm/pci.h | 11 +++
drivers/pci/pci.c | 35
+++
drivers/pci/pci.h |8 +++-
include/linux/pci.h |4
5 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 742f69d..3f2a7c9 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2857,6 +2857,11 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
PAGE_SIZE is used as alignment.
PCI-PCI bridge can be specified, if resource
windows need to be expanded.
+ resource_page_aligned= Enable/disable enforcing the alignment
+ of all PCI devices' memory resources to be
+ at least PAGE_SIZE if resources reallocation
+ is done by kernel.
+ Format: { "on" | "off" }
ecrc= Enable/disable PCIe ECRC (transaction layer
end-to-end CRC checking).
bios: Use BIOS/firmware settings. This is the
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 3453bd8..2d2b3ef 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -136,6 +136,17 @@ extern pgprot_tpci_phys_mem_access_prot(struct file
*file,
unsigned long pfn,
unsigned long size,
pgprot_t prot);
+#ifdef CONFIG_PPC64
+
+/* For PPC64, We enforce all PCI MMIO BARs to be page aligned
+ * by default. This would be helpful to improve performance
+ * when we passthrough a PCI device of which BARs are smaller
+ * than PAGE_SIZE(64KB). And we can use kernel parameter
+ * "pci=resource_page_aligned=off" to disable it.
+ */
+#define HAVE_PCI_DEFAULT_RESOURCES_PAGE_ALIGNED1
+
+#endif
#define HAVE_ARCH_PCI_RESOURCE_TO_USER
extern void pci_resource_to_user(const struct pci_dev *dev, int bar,
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 314db8c..7b21238 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -99,6 +99,9 @@ u8 pci_cache_line_size;
*/
unsigned int pcibios_max_latency = 255;
+bool pci_resources_page_aligned =
+ IS_ENABLED(HAVE_PCI_DEFAULT_RESOURCES_PAGE_ALIGNED);
I don't think this is proper use of IS_ENABLED, which seems to be
targeted at CONFIG_ type options. You could define this as that in an
arch Kconfig.
Is
Re: [RFCv2 8/9] pseries: Advertise HPT resizing support via CAS
On 01/29/2016 10:54 AM, David Gibson wrote: > The hypervisor needs to know a guest is capable of using the HPT resizing > PAPR extension in order to make full advantage of it for memory hotplug. > > If the hypervisor knows the guest is HPT resize aware, it can size the > initial HPT based on the initial guest RAM size, relying on the guest to > resize the HPT when more memory is hot-added. Without this, the hypervisor > must size the HPT for the maximum possible guest RAM, which can lead to > a huge waste of space if the guest never actually expends to that maximum > size. > > This patch advertises the guest's support for HPT resizing via the > ibm,client-architecture-support OF interface. Obviously, the actual > encoding in the CAS vector is tentative until the extension is officially > incorporated into PAPR. For now we use bit 0 of (previously unused) byte 8 > of option vector 5. > > Signed-off-by: David Gibson Reviewed-by: Anshuman Khandual ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFCv2 7/9] pseries: Add support for hash table resizing
On 01/29/2016 10:54 AM, David Gibson wrote:
> +
> +static int pseries_lpar_resize_hpt_commit(void *data)
> +{
> + struct hpt_resize_state *state = data;
> +
> + state->commit_rc = plpar_resize_hpt_commit(0, state->shift);
> + if (state->commit_rc != H_SUCCESS)
> + return -EIO;
> +
> + /* Hypervisor has transitioned the HTAB, update our globals */
> + ppc64_pft_size = state->shift;
> + htab_size_bytes = 1UL << ppc64_pft_size;
> + htab_hash_mask = (htab_size_bytes >> 7) - 1;
> +
> + return 0;
> +}
> +
snip
> +/* Must be called in user context */
> +static int pseries_lpar_resize_hpt(unsigned long shift)
> +{
> + struct hpt_resize_state state = {
> + .shift = shift,
> + .commit_rc = H_FUNCTION,
> +
> + rc = stop_machine(pseries_lpar_resize_hpt_commit, &state, NULL);
With my limited knowledge of stop_machine, wondering if the current
or any future version of 'pseries_lpar_resize_hpt_commit' function
can cause HPT change (page fault path) while stop is executing it.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
