Re: [PATCH v2] perf/probe: Search both .eh_frame and .debug_frame sections for probe location

[Hemant Kumar]

On 01/12/2016 04:34 PM, 平松雅巳 / HIRAMATU，MASAMI wrote:

Hi Hemant,


From: Hemant Kumar [mailto:hem...@linux.vnet.ibm.com]

perf probe through debuginfo__find_probes() in util/probe-finder.c
checks for the functions' frame descriptions in either .eh_frame section
of an ELF or the .debug_frame. The check is based on whether either one
of these sections is present. Depending on distro, toolchain defaults,
architetcutre, build flags, etc., CFI might be found in either .eh_frame
and/or .debug_frame. Sometimes, it may happen that, .eh_frame, even if
present, may not be complete and may miss some descriptions. Therefore,
to be sure, to find the CFI covering an address we will always have to
investigate both if available.

OK, so we'd better check both cfi's.
  [...]

+/* Find probe points from debuginfo */
+static int debuginfo__find_probes(struct debuginfo *dbg,
+ struct probe_finder *pf)
+{
+   int ret = 0;
+
+#if _ELFUTILS_PREREQ(0, 142)
+   Elf *elf;
+   GElf_Ehdr ehdr;
+   GElf_Shdr shdr;
+
+   if (pf->cfi_eh || pf->cfi_dbg)
+   return debuginfo__find_probe_location(dbg, pf);
+
+   /* Get the call frame information from this dwarf */
+   elf = dwarf_getelf(dbg->dbg);
+   if (elf == NULL)
+   return -EINVAL;
+
+   if (gelf_getehdr(elf, ) == NULL)
+   return -EINVAL;
+
+   if (elf_section_by_name(elf, , , ".eh_frame", NULL) &&
+   shdr.sh_type == SHT_PROGBITS) {
+   pf->cfi_eh = dwarf_getcfi_elf(elf);
+   } else {
+   pf->cfi_dbg = dwarf_getcfi(dbg->dbg);
+   }

Hmm, if you want to check both of those cfi's, don't we have to do below?

if (elf_section_by_name(elf, , , ".eh_frame", NULL) &&
shdr.sh_type == SHT_PROGBITS)
pf->cfi_eh = dwarf_getcfi_elf(elf);

pf->cfi_dbg = dwarf_getcfi(dbg->dbg);

Then, both of pf->cfi_* will be filled (if the elf has ".eh_frame").

Thanks!


Ah, right. Fixed in v3.






--
Thanks,
Hemant Kumar

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] dts/spi: Change compatible to use right device name

[Zhiqiang Hou]

From: Hou Zhiqiang 

On the t208xrdb and t1040rdb, the SPI devices is n25q512ax3
instead of n25q512a.

Signed-off-by: Hou Zhiqiang 
---
 arch/powerpc/boot/dts/fsl/t104xrdb.dtsi | 2 +-
 arch/powerpc/boot/dts/fsl/t208xrdb.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi 
b/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi
index 830ea48..27758ff 100644
--- a/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi
@@ -103,7 +103,7 @@
flash@0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "micron,n25q512a";
+   compatible = "micron,n25q512ax3";
reg = <0>;
spi-max-frequency = <1000>; /* input clock 
*/
};
diff --git a/arch/powerpc/boot/dts/fsl/t208xrdb.dtsi 
b/arch/powerpc/boot/dts/fsl/t208xrdb.dtsi
index 693d2a8..4a17150 100644
--- a/arch/powerpc/boot/dts/fsl/t208xrdb.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t208xrdb.dtsi
@@ -113,7 +113,7 @@
flash@0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "micron,n25q512a";
+   compatible = "micron,n25q512ax3";
reg = <0>;
spi-max-frequency = <1000>; /* input clock 
*/
};
-- 
2.1.0.27.g96db324

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] ASoC: fsl: imx-sgtl5000: make audmux optional for imx sound driver

[Lothar Waßmann]

Hi,

> On Tue, Jan 12, 2016 at 07:13:30PM +0100, Lothar Waßmann wrote:
> 
> > i.MX6UL does not have the audio multiplexer (AUDMUX) like e.g. i.MX6Q,
> > but apart from that can use the same audio driver. Make audmux
> > optional for the imx-sgtl5000 driver, so it can be used on i.MX6UL
> > too. Also i.MX6UL requires use of the SAI interface rather than SSI.
> 
> If it doesn't have the audmux can you use simple-card?
>
I'll have a look at it. Thanks for the hint.


Lothar Waßmann
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH V1 15/33] powerpc/mm: Use helper for finding pte filter mask for gup

[Denis Kirjanov]

On 1/12/16, Aneesh Kumar K.V  wrote:
> Signed-off-by: Aneesh Kumar K.V 
> ---
>  arch/powerpc/include/asm/book3s/32/pgtable.h | 8 
>  arch/powerpc/include/asm/book3s/64/hash.h| 9 +
>  arch/powerpc/include/asm/nohash/pgtable.h| 9 +
>  arch/powerpc/mm/hugetlbpage.c| 5 +
>  4 files changed, 27 insertions(+), 4 deletions(-)

This can be also placed to some common header to avoid code duplication

>
> diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h
> b/arch/powerpc/include/asm/book3s/32/pgtable.h
> index 77adada2f3b4..c0898e26ed4a 100644
> --- a/arch/powerpc/include/asm/book3s/32/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
> @@ -483,6 +483,14 @@ static inline unsigned long pte_io_cache_bits(void)
>   return _PAGE_NO_CACHE | _PAGE_GUARDED;
>  }
>
> +static inline unsigned long gup_pte_filter(int write)
> +{
> + unsigned long mask;
> + mask = _PAGE_PRESENT | _PAGE_USER;
> + if (write)
> + mask |= _PAGE_RW;
> + return mask;
> +}
>  #endif /* !__ASSEMBLY__ */
>
>  #endif /*  _ASM_POWERPC_BOOK3S_32_PGTABLE_H */
> diff --git a/arch/powerpc/include/asm/book3s/64/hash.h
> b/arch/powerpc/include/asm/book3s/64/hash.h
> index 1b27c0c8effa..ee8dd7e561b0 100644
> --- a/arch/powerpc/include/asm/book3s/64/hash.h
> +++ b/arch/powerpc/include/asm/book3s/64/hash.h
> @@ -583,6 +583,15 @@ static inline unsigned long pte_io_cache_bits(void)
>   return _PAGE_NO_CACHE | _PAGE_GUARDED;
>  }
>
> +static inline unsigned long gup_pte_filter(int write)
> +{
> + unsigned long mask;
> + mask = _PAGE_PRESENT | _PAGE_USER;
> + if (write)
> + mask |= _PAGE_RW;
> + return mask;
> +}
> +
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  extern void hpte_do_hugepage_flush(struct mm_struct *mm, unsigned long
> addr,
>  pmd_t *pmdp, unsigned long old_pmd);
> diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
> b/arch/powerpc/include/asm/nohash/pgtable.h
> index 8c4bb8fda0de..e4173cb06e5b 100644
> --- a/arch/powerpc/include/asm/nohash/pgtable.h
> +++ b/arch/powerpc/include/asm/nohash/pgtable.h
> @@ -229,6 +229,15 @@ static inline unsigned long pte_io_cache_bits(void)
>   return _PAGE_NO_CACHE | _PAGE_GUARDED;
>  }
>
> +static inline unsigned long gup_pte_filter(int write)
> +{
> + unsigned long mask;
> + mask = _PAGE_PRESENT | _PAGE_USER;
> + if (write)
> + mask |= _PAGE_RW;
> + return mask;
> +}
> +
>  #ifdef CONFIG_HUGETLB_PAGE
>  static inline int hugepd_ok(hugepd_t hpd)
>  {
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index 26fb814f289f..4e970f58f8d9 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -417,10 +417,7 @@ int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned
> long addr,
>   end = pte_end;
>
>   pte = READ_ONCE(*ptep);
> - mask = _PAGE_PRESENT | _PAGE_USER;
> - if (write)
> - mask |= _PAGE_RW;
> -
> + mask = gup_pte_filter(write);
>   if ((pte_val(pte) & mask) != mask)
>   return 0;
>
> --
> 2.5.0
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/eeh: Validate arch in eeh_add_device_early()

[Michael Ellerman]

On Sun, 2016-01-10 at 01:08 -0200, Guilherme G. Piccoli wrote:

> Commit 89a51df5ab1d ("powerpc/eeh: Fix crash in eeh_add_device_early() on 
> Cell")
> added a check on function eeh_add_device_early(): since in Cell arch eeh_ops
> is NULL, that code used to crash on Cell. The commit's approach was validate
> if EEH was available by checking the result of function eeh_enabled().
> 
> Since the function eeh_add_device_early() is used to perform EEH
> initialization in devices added later on the system, like in hotplug/DLPAR
> scenarios, we might reach a case in which no PCI devices are present on boot
> and so EEH is not initialized. Then, if a device is added via DLPAR for
> example, eeh_add_device_early() fails because eeh_enabled() is false.
> 
> We can hit a kernel oops on pSeries arch if eeh_add_device_early() fails:
> if we have no PCI devices on machine at boot time, and then we add a PCI 
> device
> via DLPAR operation, the function query_ddw() triggers the oops on NULL 
> pointer
> dereference in the line "cfg_addr = edev->config_addr;". It happens because
> config_addr in edev is NULL, since the function eeh_add_device_early() was not
> completed successfully.
> 
> This patch just changes the way the arch checking is done in function
> eeh_add_device_early(): we use no more eeh_enabled(), but instead we check the
> running architecture by using the macro machine_is(). If we are running on
> pSeries or PowerNV, the EEH mechanism can be enabled; otherwise, we bail out
> the function. This way, we don't enable EEH on Cell and we don't hit the oops
> on DLPAR either.

But eeh_enabled() is still false? That seems like it's liable to cause breakage
elsewhere.

Shouldn't the PCI hotplug code instead be taught to initialise EEH correctly
when the first device is added?

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH V1 03/33] powerpc/mm: Switch book3s 64 with 64K page size to 4 level page table

[Balbir Singh]

On Tue, 12 Jan 2016 12:45:38 +0530
"Aneesh Kumar K.V"  wrote:

> This is needed so that we can support both hash and radix page table
> using single kernel. Radix kernel uses a 4 level table.
> 
> Signed-off-by: Aneesh Kumar K.V 
> ---
>  arch/powerpc/Kconfig  |  1 +
>  arch/powerpc/include/asm/book3s/64/hash-4k.h  | 33
> +--
> arch/powerpc/include/asm/book3s/64/hash-64k.h | 20 +---
> arch/powerpc/include/asm/book3s/64/hash.h |  8 +++
> arch/powerpc/include/asm/book3s/64/pgtable.h  | 25
> +++- arch/powerpc/include/asm/pgalloc-64.h |
> 24 --- arch/powerpc/include/asm/pgtable-types.h
> | 13 +++ arch/powerpc/mm/init_64.c | 21
> - 8 files changed, 90 insertions(+), 55 deletions(-)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 378f1127ca98..618afea4c9fc 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -303,6 +303,7 @@ config ZONE_DMA32

snip
> -
>  #define PTE_INDEX_SIZE  8
> -#define PMD_INDEX_SIZE  10
> -#define PUD_INDEX_SIZE   0
> +#define PMD_INDEX_SIZE  5
> +#define PUD_INDEX_SIZE   5
>  #define PGD_INDEX_SIZE  12
>  

OK, so PMD index split from 10 to 5 and 5 to PMD/PUD? What is the plan
for huge pages, I saw you mentioned it was a TODO

>  #define PTRS_PER_PTE (1 << PTE_INDEX_SIZE)
>  #define PTRS_PER_PMD (1 << PMD_INDEX_SIZE)
> +#define PTRS_PER_PUD (1 << PUD_INDEX_SIZE)
>  #define PTRS_PER_PGD (1 << PGD_INDEX_SIZE)
>  
>  /* With 4k base page size, hugepage PTEs go at the PMD level */
> @@ -20,8 +19,13 @@
>  #define PMD_SIZE (1UL << PMD_SHIFT)
>  #define PMD_MASK (~(PMD_SIZE-1))
>  
> +/* PUD_SHIFT determines what a third-level page table entry can map
> */ +#define PUD_SHIFT (PMD_SHIFT + PMD_INDEX_SIZE)
> +#define PUD_SIZE (1UL << PUD_SHIFT)
> +#define PUD_MASK (~(PUD_SIZE-1))
> +
>  /* PGDIR_SHIFT determines what a third-level page table entry can
> map */ -#define PGDIR_SHIFT   (PMD_SHIFT + PMD_INDEX_SIZE)
> +#define PGDIR_SHIFT  (PUD_SHIFT + PUD_INDEX_SIZE)
>  #define PGDIR_SIZE   (1UL << PGDIR_SHIFT)
>  #define PGDIR_MASK   (~(PGDIR_SIZE-1))
>  
> @@ -61,6 +65,8 @@
>  #define PMD_MASKED_BITS  (PTE_FRAG_SIZE - 1)
>  /* Bits to mask out from a PGD/PUD to get to the PMD page */

The comment looks like it applied to PMD and not PUD.
>  #define PUD_MASKED_BITS  0x1ff

Given that PUD is now 5 bits, this should be 0x1f?

> +/* FIXME!! check this */
> +#define PGD_MASKED_BITS  0
>  

PGD_MASKED_BITS is 0? Shouldn't it be 0xfe

>  #ifndef __ASSEMBLY__
>  
> @@ -130,11 +136,9 @@ extern bool __rpte_sub_valid(real_pte_t rpte,
> unsigned long index); #else
>  #define PMD_TABLE_SIZE   (sizeof(pmd_t) << PMD_INDEX_SIZE)
>  #endif
> +#define PUD_TABLE_SIZE   (sizeof(pud_t) << PUD_INDEX_SIZE)
>  #define PGD_TABLE_SIZE   (sizeof(pgd_t) << PGD_INDEX_SIZE)
>  
> -#define pgd_pte(pgd) (pud_pte(((pud_t){ pgd })))
> -#define pte_pgd(pte) ((pgd_t)pte_pud(pte))
> -
>  #ifdef CONFIG_HUGETLB_PAGE
>  /*
>   * We have PGD_INDEX_SIZ = 12 and PTE_INDEX_SIZE = 8, so that we can
> have diff --git a/arch/powerpc/include/asm/book3s/64/hash.h
> b/arch/powerpc/include/asm/book3s/64/hash.h index
> f46974d0134a..9ff1e056acef 100644 ---
> a/arch/powerpc/include/asm/book3s/64/hash.h +++
> b/arch/powerpc/include/asm/book3s/64/hash.h @@ -226,6 +226,7 @@
>  #define pud_page_vaddr(pud)  (pud_val(pud) & ~PUD_MASKED_BITS)
>  
>  #define pgd_index(address) (((address) >> (PGDIR_SHIFT)) &
> (PTRS_PER_PGD - 1)) +#define pud_index(address) (((address) >>
> (PUD_SHIFT)) & (PTRS_PER_PUD - 1)) #define pmd_index(address)
> (((address) >> (PMD_SHIFT)) & (PTRS_PER_PMD - 1)) #define
> pte_index(address) (((address) >> (PAGE_SHIFT)) & (PTRS_PER_PTE - 1)) 
> @@ -354,8 +355,15 @@ static inline void __ptep_set_access_flags(pte_t
> *ptep, pte_t entry) :"cc");
>  }
>  
> +static inline int pgd_bad(pgd_t pgd)
> +{
> + return (pgd_val(pgd) == 0);
> +}
> +
>  #define __HAVE_ARCH_PTE_SAME
>  #define pte_same(A,B)(((pte_val(A) ^ pte_val(B)) &
> ~_PAGE_HPTEFLAGS) == 0) +#define pgd_page_vaddr(pgd)
> (pgd_val(pgd) & ~PGD_MASKED_BITS) +
>  
>  /* Generic accessors to PTE bits */
>  static inline int pte_write(pte_t pte)
> { return !!(pte_val(pte) & _PAGE_RW);} diff --git
> a/arch/powerpc/include/asm/book3s/64/pgtable.h
> b/arch/powerpc/include/asm/book3s/64/pgtable.h index
> e7162dba987e..8f639401c7ba 100644 ---
> a/arch/powerpc/include/asm/book3s/64/pgtable.h +++
> b/arch/powerpc/include/asm/book3s/64/pgtable.h @@ -111,6 +111,26 @@
> static inline void pgd_set(pgd_t *pgdp, unsigned long val) *pgdp =
> __pgd(val); } 
> +static inline void pgd_clear(pgd_t *pgdp)
> +{
> + *pgdp = __pgd(0);
> +}
> +
> +#define pgd_none(pgd)(!pgd_val(pgd))
> +#define pgd_present(pgd) (!pgd_none(pgd))
> +
> +static inline 

[PATCH v3] perf/probe: Search both .eh_frame and .debug_frame sections for probe location

[Hemant Kumar]

perf probe through debuginfo__find_probes() in util/probe-finder.c
checks for the functions' frame descriptions in either .eh_frame section
of an ELF or the .debug_frame. The check is based on whether either one
of these sections is present. Depending on distro, toolchain defaults,
architetcutre, build flags, etc., CFI might be found in either .eh_frame
and/or .debug_frame. Sometimes, it may happen that, .eh_frame, even if
present, may not be complete and may miss some descriptions. Therefore,
to be sure, to find the CFI covering an address we will always have to
investigate both if available.

For e.g., in powerpc, this may happen :
 $ gcc -g bin.c -o bin

 $ objdump --dwarf ./bin
 <1><145>: Abbrev Number: 7 (DW_TAG_subprogram)
<146>   DW_AT_external: 1
<146>   DW_AT_name: (indirect string, offset: 0x9e): main
<14a>   DW_AT_decl_file   : 1
<14b>   DW_AT_decl_line   : 39
<14c>   DW_AT_prototyped  : 1
<14c>   DW_AT_type: <0x57>
<150>   DW_AT_low_pc  : 0x17b8

If the .eh_frame and .debug_frame are checked for the same binary, we
will find that, .eh_frame (although present) doesn't contain a
description for "main" function.
But, .debug_frame has a description :

00d8 0024  FDE cie= pc=17b8..1838
  DW_CFA_advance_loc: 16 to 17c8
  DW_CFA_def_cfa_offset: 144
  DW_CFA_offset_extended_sf: r65 at cfa+16
...

Due to this (since, perf checks whether .eh_frame is present and goes on
searching for that address inside that frame), perf is unable to process
the probes :
 # perf probe -x ./bin main
Failed to get call frame on 0x17b8
  Error: Failed to add events.

To avoid this issue, we need to check both the sections (.eh_frame and
.debug_frame), which is done in this patch.

Note that, we can always force everything into both .eh_frame and
.debug_frame by :
 $ gcc bin.c -fasynchronous-unwind-tables  -fno-dwarf2-cfi-asm -g -o bin

Signed-off-by: Hemant Kumar 
---
Changes since v2:
- Fixed an issue related to filling up both the CFIs (Suggested by Masami).

Changes since v1:
- pf->cfi is now cached as pf->cfi_eh and pf->cfi_dbg depending on the source 
of CFI
  (Suggested by Mark Wielard).

 tools/perf/util/probe-finder.c | 62 +-
 tools/perf/util/probe-finder.h |  5 +++-
 2 files changed, 41 insertions(+), 26 deletions(-)

diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 05012bb..e4d0498 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -685,9 +685,10 @@ static int call_probe_finder(Dwarf_Die *sc_die, struct 
probe_finder *pf)
pf->fb_ops = NULL;
 #if _ELFUTILS_PREREQ(0, 142)
} else if (nops == 1 && pf->fb_ops[0].atom == DW_OP_call_frame_cfa &&
-  pf->cfi != NULL) {
+  (pf->cfi_eh != NULL || pf->cfi_dbg != NULL)) {
Dwarf_Frame *frame;
-   if (dwarf_cfi_addrframe(pf->cfi, pf->addr, ) != 0 ||
+   if ((dwarf_cfi_addrframe(pf->cfi_eh, pf->addr, ) != 0 &&
+(dwarf_cfi_addrframe(pf->cfi_dbg, pf->addr, ) != 0)) 
||
dwarf_frame_cfa(frame, >fb_ops, ) != 0) {
pr_warning("Failed to get call frame on 0x%jx\n",
   (uintmax_t)pf->addr);
@@ -1013,8 +1014,7 @@ static int pubname_search_cb(Dwarf *dbg, Dwarf_Global 
*gl, void *data)
return DWARF_CB_OK;
 }
 
-/* Find probe points from debuginfo */
-static int debuginfo__find_probes(struct debuginfo *dbg,
+static int debuginfo__find_probe_location(struct debuginfo *dbg,
  struct probe_finder *pf)
 {
struct perf_probe_point *pp = >pev->point;
@@ -1023,27 +1023,6 @@ static int debuginfo__find_probes(struct debuginfo *dbg,
Dwarf_Die *diep;
int ret = 0;
 
-#if _ELFUTILS_PREREQ(0, 142)
-   Elf *elf;
-   GElf_Ehdr ehdr;
-   GElf_Shdr shdr;
-
-   /* Get the call frame information from this dwarf */
-   elf = dwarf_getelf(dbg->dbg);
-   if (elf == NULL)
-   return -EINVAL;
-
-   if (gelf_getehdr(elf, ) == NULL)
-   return -EINVAL;
-
-   if (elf_section_by_name(elf, , , ".eh_frame", NULL) &&
-   shdr.sh_type == SHT_PROGBITS) {
-   pf->cfi = dwarf_getcfi_elf(elf);
-   } else {
-   pf->cfi = dwarf_getcfi(dbg->dbg);
-   }
-#endif
-
off = 0;
pf->lcache = intlist__new(NULL);
if (!pf->lcache)
@@ -1106,6 +1085,39 @@ found:
return ret;
 }
 
+/* Find probe points from debuginfo */
+static int debuginfo__find_probes(struct debuginfo *dbg,
+ struct probe_finder *pf)
+{
+   int ret = 0;
+
+#if _ELFUTILS_PREREQ(0, 142)
+   Elf *elf;
+   GElf_Ehdr ehdr;
+   GElf_Shdr shdr;
+
+   if (pf->cfi_eh || pf->cfi_dbg)
+   return 

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

[Will Deacon]

On Tue, Jan 12, 2016 at 12:45:14PM -0800, Leonid Yegoshin wrote:
> >The issue I have with the SYNC description in the text above is that it
> >describes the single CPU (program order) and the dual-CPU (confusingly
> >named global order) cases, but then doesn't generalise any further. That
> >means we can't sensibly reason about transitivity properties when a third
> >agent is involved. For example, the WRC+sync+addr test:
> >
> >
> >P0:
> >Wx = 1
> >
> >P1:
> >Rx == 1
> >SYNC
> >Wy = 1
> >
> >P2:
> >Ry == 1
> >
> >Rx = 0
> >
> >
> >I can't find anything to forbid that, given the text. The main problem
> >is having the SYNC on P1 affect the write by P0.
> 
> As I understand that test, the visibility of P0: W[x] = 1 is identical to P1
> and P2 here. If P1 got X before SYNC and write to Y after SYNC then
> instruction source register dependency tracking in P2 prevents a speculative
> load of X before P2 obtains Y from the same place as P0/P1 and calculate
> address of X. If some load of X in P2 happens before address dependency
> calculation it's result is discarded.

I don't think the address dependency is enough on its own. By that
reasoning, the following variant (WRC+addr+addr) would work too:


P0:
Wx = 1

P1:
Rx == 1

Wy = 1

P2:
Ry == 1

Rx = 0


So are you saying that this is also forbidden?
Imagine that P0 and P1 are two threads that share a store buffer. What
then?

> Yes, you can't find that in MIPS SYNC instruction description, it is more
> likely in CM (Coherence Manager) area. I just pointed our arch team member
> responsible for documents and he will think how to explain that.

I tried grepping the linked documents for "coherence manager" but couldn't
find anything. Is the description you refer to available anywhere?

Will
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [1/2] scripts/recordmcount.pl: support data in text section on powerpc

[Michael Ellerman]

On Tue, 2016-12-01 at 12:14:22 UTC, Michael Ellerman wrote:
> From: Ulrich Weigand 
> 
> If a text section starts out with a data blob before the first
> function start label, disassembly parsing doing in recordmcount.pl
> gets confused on powerpc, leading to creation of corrupted module
> objects.
> 
> This was not a problem so far since the compiler would never create
> such text sections.  However, this has changed with a recent change
> in GCC 6 to support distances of > 2GB between a function and its
> assoicated TOC in the ELFv2 ABI, exposing this problem.
> 
> There is already code in recordmcount.pl to handle such data blobs
> on the sparc64 platform.  This patch uses the same method to handle
> those on powerpc as well.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Ulrich Weigand 
> Signed-off-by: Michael Ellerman 
> Acked-by: Steven Rostedt 

Applied to powerpc next.

https://git.kernel.org/powerpc/c/2e50c4bef77511b42cc226865d

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [2/2] powerpc/module: Handle R_PPC64_ENTRY relocations

[Michael Ellerman]

On Tue, 2016-12-01 at 12:14:23 UTC, Michael Ellerman wrote:
> From: Ulrich Weigand 
> 
> GCC 6 will include changes to generated code with -mcmodel=large,
> which is used to build kernel modules on powerpc64le.  This was
> necessary because the large model is supposed to allow arbitrary
> sizes and locations of the code and data sections, but the ELFv2
> global entry point prolog still made the unconditional assumption
> that the TOC associated with any particular function can be found
> within 2 GB of the function entry point:
> 
> func:
>   addis r2,r12,(.TOC.-func)@ha
>   addi  r2,r2,(.TOC.-func)@l
>   .localentry func, .-func
> 
> To remove this assumption, GCC will now generate instead this global
> entry point prolog sequence when using -mcmodel=large:
> 
>   .quad .TOC.-func
> func:
>   .reloc ., R_PPC64_ENTRY
>   ldr2, -8(r12)
>   add   r2, r2, r12
>   .localentry func, .-func
> 
> The new .reloc triggers an optimization in the linker that will
> replace this new prolog with the original code (see above) if the
> linker determines that the distance between .TOC. and func is in
> range after all.
> 
> Since this new relocation is now present in module object files,
> the kernel module loader is required to handle them too.  This
> patch adds support for the new relocation and implements the
> same optimization done by the GNU linker.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Ulrich Weigand 
> Signed-off-by: Michael Ellerman 

Applied to powerpc next.

https://git.kernel.org/powerpc/c/a61674bdfc7c2bf909c4010699

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/eeh: Validate arch in eeh_add_device_early()

[Guilherme G. Piccoli]

On 01/13/2016 08:38 AM, Michael Ellerman wrote:

But eeh_enabled() is still false? That seems like it's liable to cause breakage
elsewhere.


Yes, eeh_enabled() is false as expected. Notice that eeh_enabled() is 
telling if EEH is enabled or not, and since it's not (because there's no 
PCI adapters on machine yet!), makes sense it returns false.


At the end of runs of eeh_add_device_early(), the devices are probed and 
EEH is enabled, so the function will reflect this. Notice that the 
problem addressed by this patch is the use of eeh_enabled() in hotplug 
operations only, which in my opinion is not correct. I checked every 
other use of eeh_enable() in the code, and they all seems appropriate, 
so I expect no errors at all.




Shouldn't the PCI hotplug code instead be taught to initialise EEH correctly
when the first device is added?


Well, for sure there are other ways to achieve this patch's goal, like 
refactor PCI hotplug code in lots of places. But notice although the 
proposed solution is simple, it solves the issue because 
eeh_add_device_early() is ultimately the function used by PCI hotplug 
mechanism (no matter if pseries/cell/etc or the type of hotplug) to 
initialize EEH by probing the devices at the moment they are added to 
the system. In my opinion, this is exactly the location we want to 
change code to address this issue.


What do you think? Thanks very much for the review.

Cheers,


Guilherme

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH 2/2] ASoC: fsl: select SND_SOC_FSL_SAI or SND_SOC_FSL_SSI depending on SoC type

[Lothar Waßmann]

Hi,

> On Tue, Jan 12, 2016 at 4:13 PM, Lothar Waßmann  
> wrote:
> 
> > diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
> > index 14dfdee..c128823 100644
> > --- a/sound/soc/fsl/Kconfig
> > +++ b/sound/soc/fsl/Kconfig
> > @@ -258,7 +258,8 @@ config SND_SOC_IMX_SGTL5000
> > select SND_SOC_SGTL5000
> > select SND_SOC_IMX_PCM_DMA
> > select SND_SOC_IMX_AUDMUX
> > -   select SND_SOC_FSL_SSI
> > +   select SND_SOC_FSL_SAI if SOC_IMX6UL
> > +   select SND_SOC_FSL_SSI if SOC_IMX6Q || SOC_IMX6SL || SOC_IMX6SX
> 
> MX6SX has SSI and SAI interfaces.
>
I chose the settings, so that the default behaviour before this patch is
not changed. The other interface can still be enabled by the user.
[Yes, I know this is a case of the frowned-upon use of 'select' with
user-visible symbols, but this is as things currently are]


Lothar Waßmann
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/eeh: Validate arch in eeh_add_device_early()

[Guilherme G. Piccoli]

On 01/13/2016 04:04 AM, Benjamin Herrenschmidt wrote:

On Sun, 2016-01-10 at 01:08 -0200, Guilherme G. Piccoli wrote:weust changes the 
way the arch checking is done in function


This patch jeeh_add_device_early(): we use no more eeh_enabled(), but instead 
we check the running architecture by using the macro machine_is(). If we are 
running on
pSeries or PowerNV, the EEH mechanism can be enabled; otherwise, we bail out
the function. This way, we don't enable EEH on Cell and we don't hit the oops
on DLPAR either.


Can't we just check for eeh_ops being NULL ?

Cheers,
Ben.


Sure, we can. I prefer the arch checking just because I think it's more 
"logical", so it's easier to understand why it's there. The "cost" is 
the same in practice, since the arch checking is just a macro that 
checks a struct member.


What do you think it's better? Thanks for the review.

Cheers,


Guilherme

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] ASoC: fsl: select SND_SOC_FSL_SAI or SND_SOC_FSL_SSI depending on SoC type

[Lothar Waßmann]

Hi,

> Lothar Waßmann wrote:
> > -   select SND_SOC_FSL_SSI
> > +   select SND_SOC_FSL_SAI if SOC_IMX6UL
> > +   select SND_SOC_FSL_SSI if SOC_IMX6Q || SOC_IMX6SL || SOC_IMX6SX
> 
> I don't think this is compatible with a multiarch kernel.
>
Why? If more than one of the IMX6 SoCs are selected, both interfaces
may be selected at the same time without any harm.


Lothar Waßmann
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: Wire up sys_copy_file_range()

[Michael Ellerman]

Lightly tested on 64 bit little endian.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/systbl.h  | 1 +
 arch/powerpc/include/asm/unistd.h  | 2 +-
 arch/powerpc/include/uapi/asm/unistd.h | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/systbl.h 
b/arch/powerpc/include/asm/systbl.h
index 5654ece02c0d..3fa9df70aa20 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -383,3 +383,4 @@ SYSCALL(ni_syscall)
 SYSCALL(ni_syscall)
 SYSCALL(ni_syscall)
 SYSCALL(mlock2)
+SYSCALL(copy_file_range)
diff --git a/arch/powerpc/include/asm/unistd.h 
b/arch/powerpc/include/asm/unistd.h
index 4b6b8ace18e0..2f9cd737b529 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -12,7 +12,7 @@
 #include 
 
 
-#define __NR_syscalls  379
+#define __NR_syscalls  380
 
 #define __NR__exit __NR_exit
 #define NR_syscalls__NR_syscalls
diff --git a/arch/powerpc/include/uapi/asm/unistd.h 
b/arch/powerpc/include/uapi/asm/unistd.h
index 12a05652377a..940290d45b08 100644
--- a/arch/powerpc/include/uapi/asm/unistd.h
+++ b/arch/powerpc/include/uapi/asm/unistd.h
@@ -389,5 +389,6 @@
 #define __NR_userfaultfd   364
 #define __NR_membarrier365
 #define __NR_mlock2378
+#define __NR_copy_file_range   379
 
 #endif /* _UAPI_ASM_POWERPC_UNISTD_H_ */
-- 
2.5.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH 2/2] ASoC: fsl: select SND_SOC_FSL_SAI or SND_SOC_FSL_SSI depending on SoC type

[Fabio Estevam]

On Tue, Jan 12, 2016 at 4:13 PM, Lothar Waßmann  
wrote:

> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
> index 14dfdee..c128823 100644
> --- a/sound/soc/fsl/Kconfig
> +++ b/sound/soc/fsl/Kconfig
> @@ -258,7 +258,8 @@ config SND_SOC_IMX_SGTL5000
> select SND_SOC_SGTL5000
> select SND_SOC_IMX_PCM_DMA
> select SND_SOC_IMX_AUDMUX
> -   select SND_SOC_FSL_SSI
> +   select SND_SOC_FSL_SAI if SOC_IMX6UL
> +   select SND_SOC_FSL_SSI if SOC_IMX6Q || SOC_IMX6SL || SOC_IMX6SX

MX6SX has SSI and SAI interfaces.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: powerpc/powernv: Fix OPAL_CONSOLE_FLUSH prototype and usages

[Michael Ellerman]

On Wed, 2016-13-01 at 01:04:32 UTC, Russell Currey wrote:
> The recently added OPAL API call, OPAL_CONSOLE_FLUSH, originally took no
> parameters and returned nothing.  The call was updated to accept the
> terminal number to flush, and returned various values depending on the
> state of the output buffer.
> 
> The prototype has been updated and its usage in the OPAL kmsg dumper has
> been modified to support its new behaviour as an incremental flush.
> 
> Signed-off-by: Russell Currey 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/c88c5d43732a0356f99e5e4d1a

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

[Peter Zijlstra]

On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote:

> I ask HW team about it but I have a question - has it any relationship with
> replacing MIPS SYNC with lightweight SYNCs (SYNC_WMB etc)?

Of course. If you cannot explain the semantics of the primitives you
introduce, how can we judge the patch.

This barrier business is hard enough as it is, but magic unexplained
hardware makes it impossible.

Rest assured, you (MIPS) isn't the first (nor likely the last) to go
through all this. We've had these discussions (and to a certain extend
are still having them) for x86, PPC, Alpha, ARM, etc..

Any every time new barriers instructions get introduced we had better
have a full and comprehensive explanation to go along with them.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/eeh: Validate arch in eeh_add_device_early()

[Michael Ellerman]

On Wed, 2016-01-13 at 10:08 -0200, Guilherme G. Piccoli wrote:
> On 01/13/2016 08:38 AM, Michael Ellerman wrote:
> > But eeh_enabled() is still false? That seems like it's liable to cause 
> > breakage
> > elsewhere.
>
> Yes, eeh_enabled() is false as expected. Notice that eeh_enabled() is
> telling if EEH is enabled or not, and since it's not (because there's no
> PCI adapters on machine yet!), makes sense it returns false.
>
> At the end of runs of eeh_add_device_early(), the devices are probed and
> EEH is enabled, so the function will reflect this. Notice that the
> problem addressed by this patch is the use of eeh_enabled() in hotplug
> operations only, which in my opinion is not correct. I checked every
> other use of eeh_enable() in the code, and they all seems appropriate,
> so I expect no errors at all.

OK.

> > Shouldn't the PCI hotplug code instead be taught to initialise EEH correctly
> > when the first device is added?
>
> Well, for sure there are other ways to achieve this patch's goal, like
> refactor PCI hotplug code in lots of places. But notice although the
> proposed solution is simple, it solves the issue because
> eeh_add_device_early() is ultimately the function used by PCI hotplug
> mechanism (no matter if pseries/cell/etc or the type of hotplug) to
> initialize EEH by probing the devices at the moment they are added to
> the system. In my opinion, this is exactly the location we want to
> change code to address this issue.
>
> What do you think? Thanks very much for the review.

I'm still not sure. I'm certainly happy for the fix to be simple, it will need
to be backported after all.

But for example what happens if the user boots with eeh=off on the command
line, and then hotplugs a device. It looks like because you're not using
eeh_enabled() you will incorrectly initialise EEH anyway?

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v7,49/50] drivers/of: Export OF changeset functions

[Wolfram Sang]

On Thu, Jan 14, 2016 at 08:18:06AM +1100, Michael Ellerman wrote:
> On Wed, 2016-01-13 at 14:54 +0100, Wolfram Sang wrote:
> > On Thu, Nov 05, 2015 at 12:12:49AM +1100, Gavin Shan wrote:
> > > The PowerNV PCI hotplug driver is going to use the OF changeset
> > > to manage the changed device sub-tree. This exports those OF
> > > changeset functions for that.
> > > 
> > > Signed-off-by: Gavin Shan 
> > > Acked-by: Rob Herring 
> > 
> > I needed something like this, too [1] and rebased my series on top of
> > this patch. So:
> > 
> > Acked-by: Wolfram Sang 
> > Tested-by: Wolfram Sang 
> 
> OK. This series is kind of in limbo, it might hit 4.6, but it might not. So if
> you need this patch before then you should probably pull it in to your series,
> or ask Rob to merge it pre-emptively.

Yup, this is what I had in mind, too.

Thanks,

   Wolfram



signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

[Leonid Yegoshin]

On 01/13/2016 02:45 AM, Will Deacon wrote:

On Tue, Jan 12, 2016 at 12:45:14PM -0800, Leonid Yegoshin wrote:



I don't think the address dependency is enough on its own. By that
reasoning, the following variant (WRC+addr+addr) would work too:


P0:
Wx = 1

P1:
Rx == 1

Wy = 1

P2:
Ry == 1

Rx = 0


So are you saying that this is also forbidden?
Imagine that P0 and P1 are two threads that share a store buffer. What
then?



I ask HW team about it but I have a question - has it any relationship 
with replacing MIPS SYNC with lightweight SYNCs (SYNC_WMB etc)? You use 
any barrier or do not use it and I just voice an intention to use a more 
efficient instruction instead of bold hummer (SYNC instruction). If you 
don't use any barrier here then it is a different issue.


May be it has sense to return back to original issue?

- Leonid
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/5] misc: cxl: use kobj_to_dev()

[Michael Ellerman]

On Wed, 2016-01-13 at 23:30 +0800, Geliang Tang wrote:
> Use kobj_to_dev() instead of open-coding it.
>
> Signed-off-by: Geliang Tang 
> ---
>  drivers/misc/cxl/sysfs.c | 5 ++---

Looks fine. Do you want me to merge it or just ack it?

Acked-by: Michael Ellerman 

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

[Leonid Yegoshin]

On 01/13/2016 12:48 PM, Peter Zijlstra wrote:

On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote:


I ask HW team about it but I have a question - has it any relationship with
replacing MIPS SYNC with lightweight SYNCs (SYNC_WMB etc)?

Of course. If you cannot explain the semantics of the primitives you
introduce, how can we judge the patch.


You missed a point - it is a question about replacement of SYNC with 
lightweight primitives. It is NOT a question about multithread system 
behavior without any SYNC. The answer on a latest Will's question lies 
in different area.


- Leonid.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v7,49/50] drivers/of: Export OF changeset functions

[Michael Ellerman]

On Wed, 2016-01-13 at 14:54 +0100, Wolfram Sang wrote:
> On Thu, Nov 05, 2015 at 12:12:49AM +1100, Gavin Shan wrote:
> > The PowerNV PCI hotplug driver is going to use the OF changeset
> > to manage the changed device sub-tree. This exports those OF
> > changeset functions for that.
> > 
> > Signed-off-by: Gavin Shan 
> > Acked-by: Rob Herring 
> 
> I needed something like this, too [1] and rebased my series on top of
> this patch. So:
> 
> Acked-by: Wolfram Sang 
> Tested-by: Wolfram Sang 

OK. This series is kind of in limbo, it might hit 4.6, but it might not. So if
you need this patch before then you should probably pull it in to your series,
or ask Rob to merge it pre-emptively.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v7,49/50] drivers/of: Export OF changeset functions

[Wolfram Sang]

> Given this has been on the list some time and still works, I've
> applied this for 4.5. That should simplify dependencies for 4.6.

Cool, thanks Rob!



signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

[Leonid Yegoshin]

On 01/13/2016 02:45 AM, Will Deacon wrote:



I don't think the address dependency is enough on its own. By that
reasoning, the following variant (WRC+addr+addr) would work too:


P0:
Wx = 1

P1:
Rx == 1

Wy = 1

P2:
Ry == 1

Rx = 0


So are you saying that this is also forbidden?
Imagine that P0 and P1 are two threads that share a store buffer. What
then?


OK, I collected answers and it is:

In MIPS R6 this test passes OK, I mean - P2: Rx = 1 if Ry is read 
as 1. By design.


However, it is unclear that happens in MIPS R2 1004K.

Moreover, there are voices against guarantee that it will be in 
future and that voices point me to Documentation/memory-barriers.txt 
section "DATA DEPENDENCY BARRIERS" examples which require SYNC_RMB 
between loading address/index and using that for loading data based on 
that address or index for shared data (look on CPU2 pseudo-code):

To deal with this, a data dependency barrier or better must be inserted
between the address load and the data load:

CPU 1 CPU 2
===   ===
{ A == 1, B == 2, C = 3, P == , Q ==  }
B = 4;

WRITE_ONCE(P, );
  Q = READ_ONCE(P);
   <--- 
SYNC_RMB is here

  D = *Q;

...
Another example of where data dependency barriers might be required is 
where a
number is read from memory and then used to calculate the index for an 
array

access:

CPU 1 CPU 2
===   ===
{ M[0] == 1, M[1] == 2, M[3] = 3, P == 0, Q == 3 }
M[1] = 4;

WRITE_ONCE(P, 1);
  Q = READ_ONCE(P);
   < 
SYNC_RMB is here

  D = M[Q];


That voices say that there is a legitimate reason to relax HW here for 
performance if SYNC_RMB is needed anyway to work with this sequence of 
shared data.



And all that is out-of-topic here in my mind. I just want to be sure 
that this patchset still provides a use of a specific lightweight SYNCs 
on MIPS vs bold and heavy generalized "SYNC 0" in any case.


- Leonid.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: cxl: Fix DSI misses when the context owning task exits

[Vaibhav Jain]

Hi David,


David Laight  writes:

> I don't even claim to understand the linux model for handling process
> address maps, nor what the cxl driver is doing, but the above looks
> more than dodgy.
>
>   David

Thanks for reviewing the patch.

Yes, It does look dodgy but is needed to handle a very corner case wherein
the task_struct that had originally allocated the cxl context exit
without freeing it. In case of a multi threaded user-space process this
context can still be used by other threads.

A cxl_context holds pid of the task that allocated it since we need
access to the mm_struct associated with the task to handle storage
faults reported by the capi accelerator. Now in case of a MT process if
the thread that allocated the context exits the pid becomes invalid and
we are no more able to handle faults from the accelerator even though
the process is still alive.

In such a case the patch tries to use the task group leader pid to find
the next alive task in the task group which can be used to handle the
storage fault.

We could have instead used only the task group leader for handling the
faults but there is a possibility that even the task group leader has
exited in which case the mm_struct associated with it will also be NULL.

Hope this clarifies things,

Cheers,
~ Vaibhav

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 2/2] KVM: PPC: Exit guest upon MCE when FWNMI capability is enabled

[David Gibson]

On Wed, Jan 13, 2016 at 12:38:09PM +0530, Aravinda Prasad wrote:
> Enhance KVM to cause a guest exit with KVM_EXIT_NMI
> exit reasons upon a machine check exception (MCE) in
> the guest address space if the KVM_CAP_PPC_FWNMI
> capability is enabled (instead of delivering 0x200
> interrupt to guest). This enables QEMU to build error
> log and deliver machine check exception to guest via
> guest registered machine check handler.
> 
> This approach simplifies the delivering of machine
> check exception to guest OS compared to the earlier
> approach of KVM directly invoking 0x200 guest interrupt
> vector. In the earlier approach QEMU was enhanced to
> patch the 0x200 interrupt vector during boot. The
> patched code at 0x200 issued a private hcall to pass
> the control to QEMU to build the error log.
> 
> This design/approach is based on the feedback for the
> QEMU patches to handle machine check exception. Details
> of earlier approach of handling machine check exception
> in QEMU and related discussions can be found at:
> 
> https://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg00813.html
> 
> Signed-off-by: Aravinda Prasad 

Reviewed-by: David Gibson 

> ---
>  arch/powerpc/kvm/book3s_hv.c|   12 ++--
>  arch/powerpc/kvm/book3s_hv_rmhandlers.S |   48 
> +++
>  2 files changed, 26 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index a7352b5..4fa03d0 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -858,15 +858,9 @@ static int kvmppc_handle_exit_hv(struct kvm_run *run, 
> struct kvm_vcpu *vcpu,
>   r = RESUME_GUEST;
>   break;
>   case BOOK3S_INTERRUPT_MACHINE_CHECK:
> - /*
> -  * Deliver a machine check interrupt to the guest.
> -  * We have to do this, even if the host has handled the
> -  * machine check, because machine checks use SRR0/1 and
> -  * the interrupt might have trashed guest state in them.
> -  */
> - kvmppc_book3s_queue_irqprio(vcpu,
> - BOOK3S_INTERRUPT_MACHINE_CHECK);
> - r = RESUME_GUEST;
> + /* Exit to guest with KVM_EXIT_NMI as exit reason */
> + run->exit_reason = KVM_EXIT_NMI;
> + r = RESUME_HOST;
>   break;
>   case BOOK3S_INTERRUPT_PROGRAM:
>   {
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
> b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index 3c6badc..84e32a3 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -133,21 +133,18 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
>   stb r0, HSTATE_HWTHREAD_REQ(r13)
>  
>   /*
> -  * For external and machine check interrupts, we need
> -  * to call the Linux handler to process the interrupt.
> -  * We do that by jumping to absolute address 0x500 for
> -  * external interrupts, or the machine_check_fwnmi label
> -  * for machine checks (since firmware might have patched
> -  * the vector area at 0x200).  The [h]rfid at the end of the
> -  * handler will return to the book3s_hv_interrupts.S code.
> -  * For other interrupts we do the rfid to get back
> -  * to the book3s_hv_interrupts.S code here.
> +  * For external interrupts we need to call the Linux
> +  * handler to process the interrupt. We do that by jumping
> +  * to absolute address 0x500 for external interrupts.
> +  * The [h]rfid at the end of the handler will return to
> +  * the book3s_hv_interrupts.S code. For other interrupts
> +  * we do the rfid to get back to the book3s_hv_interrupts.S
> +  * code here.
>*/
>   ld  r8, 112+PPC_LR_STKOFF(r1)
>   addir1, r1, 112
>   ld  r7, HSTATE_HOST_MSR(r13)
>  
> - cmpwi   cr1, r12, BOOK3S_INTERRUPT_MACHINE_CHECK
>   cmpwi   r12, BOOK3S_INTERRUPT_EXTERNAL
>   beq 11f
>   cmpwi   r12, BOOK3S_INTERRUPT_H_DOORBELL
> @@ -162,7 +159,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
>   mtmsrd  r6, 1   /* Clear RI in MSR */
>   mtsrr0  r8
>   mtsrr1  r7
> - beq cr1, 13f/* machine check */
>   RFI
>  
>   /* On POWER7, we have external interrupts set to use HSRR0/1 */
> @@ -170,8 +166,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
>   mtspr   SPRN_HSRR1, r7
>   ba  0x500
>  
> -13:  b   machine_check_fwnmi
> -
>  14:  mtspr   SPRN_HSRR0, r8
>   mtspr   SPRN_HSRR1, r7
>   b   hmi_exception_after_realmode
> @@ -2390,15 +2384,13 @@ machine_check_realmode:
>   ld  r9, HSTATE_KVM_VCPU(r13)
>   li  r12, BOOK3S_INTERRUPT_MACHINE_CHECK
>   /*
> -  * Deliver unhandled/fatal (e.g. UE) MCE errors to guest through
> -  * machine check 

Re: [PATCH 2/5] misc: cxl: use kobj_to_dev()

[Andrew Donnellan]

On 14/01/16 02:30, Geliang Tang wrote:

Use kobj_to_dev() instead of open-coding it.

Signed-off-by: Geliang Tang 


Good simplification.

Reviewed-by: Andrew Donnellan 

--
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: [PATCH V2] powerpc/powernv: Remove support for p5ioc2

[Andrew Donnellan]

On 13/01/16 18:04, 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 
---
V2: Remove pointless union and rebase on -next


Thanks for the changes.

Reviewed-by: Andrew Donnellan 

--
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: [PATCH v3 1/2] KVM: PPC: New capability to control MCE behaviour

[David Gibson]

On Thu, Jan 14, 2016 at 11:02:39AM +1100, David Gibson wrote:
> On Wed, Jan 13, 2016 at 12:37:59PM +0530, Aravinda Prasad wrote:
> > This patch introduces a new KVM capability to control
> > how KVM behaves on machine check exception (MCE).
> > Without this capability, KVM redirects machine check
> > exceptions to guest's 0x200 vector if the address in
> > error belongs to the guest. With this capability KVM
> > causes a guest exit with NMI exit reason.
> > 
> > This is required to avoid problems if a new kernel/KVM
> > is used with an old QEMU for guests that don't issue
> > "ibm,nmi-register". As old QEMU does not understand the
> > NMI exit type, it treats it as a fatal error. However,
> > the guest could have handled the machine check error
> > if the exception was delivered to guest's 0x200 interrupt
> > vector instead of NMI exit in case of old QEMU.
> > 
> > QEMU part can be found at:
> > http://lists.nongnu.org/archive/html/qemu-ppc/2015-12/msg00199.html
> > 
> > Change Log v3:
> >   - Split the patch into 2. First patch introduces the
> > new capability while the second one enhances KVM to
> > redirect MCE.
> >   - Fix access width bug
> >   - Rebased to v4.4-rc7
> > 
> > Change Log v2:
> >   - Added KVM capability
> > 
> > Signed-off-by: Aravinda Prasad 
> > ---
> >  arch/powerpc/include/asm/kvm_host.h |1 +
> >  arch/powerpc/kernel/asm-offsets.c   |1 +
> >  arch/powerpc/kvm/powerpc.c  |7 +++
> >  include/uapi/linux/kvm.h|1 +
> >  4 files changed, 10 insertions(+)
> > 
> > diff --git a/arch/powerpc/include/asm/kvm_host.h 
> > b/arch/powerpc/include/asm/kvm_host.h
> > index cfa758c..9ac2b84 100644
> > --- a/arch/powerpc/include/asm/kvm_host.h
> > +++ b/arch/powerpc/include/asm/kvm_host.h
> > @@ -243,6 +243,7 @@ struct kvm_arch {
> > int hpt_cma_alloc;
> > struct dentry *debugfs_dir;
> > struct dentry *htab_dentry;
> > +   u8 fwnmi_enabled;
> 
> Um.. I don't see anything in this patch or 2/2 which actually tests
> this flag...

Sorry, I missed it in the asm, spotted it now.

Reviewed-by: David Gibson 

> 
> >  #endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
> >  #ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
> > struct mutex hpt_mutex;
> > diff --git a/arch/powerpc/kernel/asm-offsets.c 
> > b/arch/powerpc/kernel/asm-offsets.c
> > index 221d584..6a4e81a 100644
> > --- a/arch/powerpc/kernel/asm-offsets.c
> > +++ b/arch/powerpc/kernel/asm-offsets.c
> > @@ -506,6 +506,7 @@ int main(void)
> > DEFINE(KVM_ENABLED_HCALLS, offsetof(struct kvm, arch.enabled_hcalls));
> > DEFINE(KVM_LPCR, offsetof(struct kvm, arch.lpcr));
> > DEFINE(KVM_VRMA_SLB_V, offsetof(struct kvm, arch.vrma_slb_v));
> > +   DEFINE(KVM_FWNMI, offsetof(struct kvm, arch.fwnmi_enabled));
> > DEFINE(VCPU_DSISR, offsetof(struct kvm_vcpu, arch.shregs.dsisr));
> > DEFINE(VCPU_DAR, offsetof(struct kvm_vcpu, arch.shregs.dar));
> > DEFINE(VCPU_VPA, offsetof(struct kvm_vcpu, arch.vpa.pinned_addr));
> > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> > index 6fd2405..a8399b5 100644
> > --- a/arch/powerpc/kvm/powerpc.c
> > +++ b/arch/powerpc/kvm/powerpc.c
> > @@ -570,6 +570,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long 
> > ext)
> > r = 1;
> > break;
> >  #endif
> > +   case KVM_CAP_PPC_FWNMI:
> > +   r = 1;
> > +   break;
> > default:
> > r = 0;
> > break;
> > @@ -1132,6 +1135,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu 
> > *vcpu,
> > break;
> > }
> >  #endif /* CONFIG_KVM_XICS */
> > +   case KVM_CAP_PPC_FWNMI:
> > +   r = 0;
> > +   vcpu->kvm->arch.fwnmi_enabled = true;
> > +   break;
> > default:
> > r = -EINVAL;
> > break;
> > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > index 03f3618..d8a07b5 100644
> > --- a/include/uapi/linux/kvm.h
> > +++ b/include/uapi/linux/kvm.h
> > @@ -831,6 +831,7 @@ struct kvm_ppc_smmu_info {
> >  #define KVM_CAP_GUEST_DEBUG_HW_WPS 120
> >  #define KVM_CAP_SPLIT_IRQCHIP 121
> >  #define KVM_CAP_IOEVENTFD_ANY_LENGTH 122
> > +#define KVM_CAP_PPC_FWNMI 123
> >  
> >  #ifdef KVM_CAP_IRQ_ROUTING
> >  
> > 
> 



-- 
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: [v7,49/50] drivers/of: Export OF changeset functions

[Rob Herring]

On Wed, Jan 13, 2016 at 3:20 PM, Wolfram Sang  wrote:
> On Thu, Jan 14, 2016 at 08:18:06AM +1100, Michael Ellerman wrote:
>> On Wed, 2016-01-13 at 14:54 +0100, Wolfram Sang wrote:
>> > On Thu, Nov 05, 2015 at 12:12:49AM +1100, Gavin Shan wrote:
>> > > The PowerNV PCI hotplug driver is going to use the OF changeset
>> > > to manage the changed device sub-tree. This exports those OF
>> > > changeset functions for that.
>> > >
>> > > Signed-off-by: Gavin Shan 
>> > > Acked-by: Rob Herring 
>> >
>> > I needed something like this, too [1] and rebased my series on top of
>> > this patch. So:
>> >
>> > Acked-by: Wolfram Sang 
>> > Tested-by: Wolfram Sang 
>>
>> OK. This series is kind of in limbo, it might hit 4.6, but it might not. So 
>> if
>> you need this patch before then you should probably pull it in to your 
>> series,
>> or ask Rob to merge it pre-emptively.
>
> Yup, this is what I had in mind, too.

Given this has been on the list some time and still works, I've
applied this for 4.5. That should simplify dependencies for 4.6.

Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: Wire up copy_file_range() syscall

[Michael Ellerman]

On Wed, 2016-01-13 at 22:20 +0530, Chandan Rajendra wrote:

> Test runs on a ppc64 BE guest succeeded.

Were the tests built 64-bit or 32-bit?

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 1/2] KVM: PPC: New capability to control MCE behaviour

[David Gibson]

On Wed, Jan 13, 2016 at 12:37:59PM +0530, Aravinda Prasad wrote:
> This patch introduces a new KVM capability to control
> how KVM behaves on machine check exception (MCE).
> Without this capability, KVM redirects machine check
> exceptions to guest's 0x200 vector if the address in
> error belongs to the guest. With this capability KVM
> causes a guest exit with NMI exit reason.
> 
> This is required to avoid problems if a new kernel/KVM
> is used with an old QEMU for guests that don't issue
> "ibm,nmi-register". As old QEMU does not understand the
> NMI exit type, it treats it as a fatal error. However,
> the guest could have handled the machine check error
> if the exception was delivered to guest's 0x200 interrupt
> vector instead of NMI exit in case of old QEMU.
> 
> QEMU part can be found at:
> http://lists.nongnu.org/archive/html/qemu-ppc/2015-12/msg00199.html
> 
> Change Log v3:
>   - Split the patch into 2. First patch introduces the
> new capability while the second one enhances KVM to
> redirect MCE.
>   - Fix access width bug
>   - Rebased to v4.4-rc7
> 
> Change Log v2:
>   - Added KVM capability
> 
> Signed-off-by: Aravinda Prasad 
> ---
>  arch/powerpc/include/asm/kvm_host.h |1 +
>  arch/powerpc/kernel/asm-offsets.c   |1 +
>  arch/powerpc/kvm/powerpc.c  |7 +++
>  include/uapi/linux/kvm.h|1 +
>  4 files changed, 10 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/kvm_host.h 
> b/arch/powerpc/include/asm/kvm_host.h
> index cfa758c..9ac2b84 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -243,6 +243,7 @@ struct kvm_arch {
>   int hpt_cma_alloc;
>   struct dentry *debugfs_dir;
>   struct dentry *htab_dentry;
> + u8 fwnmi_enabled;

Um.. I don't see anything in this patch or 2/2 which actually tests
this flag...

>  #endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
>  #ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
>   struct mutex hpt_mutex;
> diff --git a/arch/powerpc/kernel/asm-offsets.c 
> b/arch/powerpc/kernel/asm-offsets.c
> index 221d584..6a4e81a 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -506,6 +506,7 @@ int main(void)
>   DEFINE(KVM_ENABLED_HCALLS, offsetof(struct kvm, arch.enabled_hcalls));
>   DEFINE(KVM_LPCR, offsetof(struct kvm, arch.lpcr));
>   DEFINE(KVM_VRMA_SLB_V, offsetof(struct kvm, arch.vrma_slb_v));
> + DEFINE(KVM_FWNMI, offsetof(struct kvm, arch.fwnmi_enabled));
>   DEFINE(VCPU_DSISR, offsetof(struct kvm_vcpu, arch.shregs.dsisr));
>   DEFINE(VCPU_DAR, offsetof(struct kvm_vcpu, arch.shregs.dar));
>   DEFINE(VCPU_VPA, offsetof(struct kvm_vcpu, arch.vpa.pinned_addr));
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 6fd2405..a8399b5 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -570,6 +570,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long 
> ext)
>   r = 1;
>   break;
>  #endif
> + case KVM_CAP_PPC_FWNMI:
> + r = 1;
> + break;
>   default:
>   r = 0;
>   break;
> @@ -1132,6 +1135,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu 
> *vcpu,
>   break;
>   }
>  #endif /* CONFIG_KVM_XICS */
> + case KVM_CAP_PPC_FWNMI:
> + r = 0;
> + vcpu->kvm->arch.fwnmi_enabled = true;
> + break;
>   default:
>   r = -EINVAL;
>   break;
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 03f3618..d8a07b5 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -831,6 +831,7 @@ struct kvm_ppc_smmu_info {
>  #define KVM_CAP_GUEST_DEBUG_HW_WPS 120
>  #define KVM_CAP_SPLIT_IRQCHIP 121
>  #define KVM_CAP_IOEVENTFD_ANY_LENGTH 122
> +#define KVM_CAP_PPC_FWNMI 123
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> 

-- 
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 1/3] Powernv: Remove the usage of PACAR1 from opal wrappers

[Mahesh J Salgaonkar]

From: Mahesh Salgaonkar 

OPAL_CALL wrapper code sticks the r1 (stack pointer) into PACAR1 purely
for debugging purpose only. The power7_wakeup* functions relies on stack
pointer saved in PACAR1. Any opal call made using opal wrapper (directly
or in-directly) before we fall through power7_wakeup*, then it ends up
replacing r1 in PACAR1(r13) leading to kernel panic. So far we don't see
any issues because we have never made any opal calls using OPAL wrapper
before power7_wakeup*. But the subsequent HMI patch would need to invoke
C calls during cpu wakeup/idle path that in-directly makes opal call using
opal wrapper. This patch facilitates the subsequent HMI patch by removing
usage of PACAR1 from opal call wrapper.

Signed-off-by: Mahesh Salgaonkar 
---
 arch/powerpc/platforms/powernv/opal-wrappers.S |2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S 
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index b7a464f..62fe496 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -64,7 +64,6 @@ END_FTR_SECTION(0, 1);
\
OPAL_BRANCH(opal_tracepoint_entry) \
mfcrr12;\
stw r12,8(r1);  \
-   std r1,PACAR1(r13); \
li  r11,0;  \
mfmsr   r12;\
ori r11,r11,MSR_EE; \
@@ -127,7 +126,6 @@ opal_tracepoint_entry:
mfcrr12
std r11,16(r1)
stw r12,8(r1)
-   std r1,PACAR1(r13)
li  r11,0
mfmsr   r12
ori r11,r11,MSR_EE

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3] perf/probe: Search both .eh_frame and .debug_frame sections for probe location

[平松雅巳 / HIRAMATU，MASAMI]

From: Hemant Kumar [mailto:hem...@linux.vnet.ibm.com]
>
>perf probe through debuginfo__find_probes() in util/probe-finder.c
>checks for the functions' frame descriptions in either .eh_frame section
>of an ELF or the .debug_frame. The check is based on whether either one
>of these sections is present. Depending on distro, toolchain defaults,
>architetcutre, build flags, etc., CFI might be found in either .eh_frame
>and/or .debug_frame. Sometimes, it may happen that, .eh_frame, even if
>present, may not be complete and may miss some descriptions. Therefore,
>to be sure, to find the CFI covering an address we will always have to
>investigate both if available.
>
>For e.g., in powerpc, this may happen :
> $ gcc -g bin.c -o bin
>
> $ objdump --dwarf ./bin
> <1><145>: Abbrev Number: 7 (DW_TAG_subprogram)
><146>   DW_AT_external: 1
><146>   DW_AT_name: (indirect string, offset: 0x9e): main
><14a>   DW_AT_decl_file   : 1
><14b>   DW_AT_decl_line   : 39
><14c>   DW_AT_prototyped  : 1
><14c>   DW_AT_type: <0x57>
><150>   DW_AT_low_pc  : 0x17b8
>
>If the .eh_frame and .debug_frame are checked for the same binary, we
>will find that, .eh_frame (although present) doesn't contain a
>description for "main" function.
>But, .debug_frame has a description :
>
>00d8 0024  FDE cie= pc=17b8..1838
>  DW_CFA_advance_loc: 16 to 17c8
>  DW_CFA_def_cfa_offset: 144
>  DW_CFA_offset_extended_sf: r65 at cfa+16
>...
>
>Due to this (since, perf checks whether .eh_frame is present and goes on
>searching for that address inside that frame), perf is unable to process
>the probes :
> # perf probe -x ./bin main
>Failed to get call frame on 0x17b8
>  Error: Failed to add events.
>
>To avoid this issue, we need to check both the sections (.eh_frame and
>.debug_frame), which is done in this patch.
>
>Note that, we can always force everything into both .eh_frame and
>.debug_frame by :
> $ gcc bin.c -fasynchronous-unwind-tables  -fno-dwarf2-cfi-asm -g -o bin
>
>Signed-off-by: Hemant Kumar 

Looks good to me:)

Acked-by: Masami Hiramatsu 

Thanks!

>---
>Changes since v2:
>- Fixed an issue related to filling up both the CFIs (Suggested by Masami).
>
>Changes since v1:
>- pf->cfi is now cached as pf->cfi_eh and pf->cfi_dbg depending on the source 
>of CFI
>  (Suggested by Mark Wielard).
>
> tools/perf/util/probe-finder.c | 62 +-
> tools/perf/util/probe-finder.h |  5 +++-
> 2 files changed, 41 insertions(+), 26 deletions(-)
>
>diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
>index 05012bb..e4d0498 100644
>--- a/tools/perf/util/probe-finder.c
>+++ b/tools/perf/util/probe-finder.c
>@@ -685,9 +685,10 @@ static int call_probe_finder(Dwarf_Die *sc_die, struct 
>probe_finder *pf)
>   pf->fb_ops = NULL;
> #if _ELFUTILS_PREREQ(0, 142)
>   } else if (nops == 1 && pf->fb_ops[0].atom == DW_OP_call_frame_cfa &&
>- pf->cfi != NULL) {
>+ (pf->cfi_eh != NULL || pf->cfi_dbg != NULL)) {
>   Dwarf_Frame *frame;
>-  if (dwarf_cfi_addrframe(pf->cfi, pf->addr, ) != 0 ||
>+  if ((dwarf_cfi_addrframe(pf->cfi_eh, pf->addr, ) != 0 &&
>+   (dwarf_cfi_addrframe(pf->cfi_dbg, pf->addr, ) != 0)) 
>||
>   dwarf_frame_cfa(frame, >fb_ops, ) != 0) {
>   pr_warning("Failed to get call frame on 0x%jx\n",
>  (uintmax_t)pf->addr);
>@@ -1013,8 +1014,7 @@ static int pubname_search_cb(Dwarf *dbg, Dwarf_Global 
>*gl, void *data)
>   return DWARF_CB_OK;
> }
>
>-/* Find probe points from debuginfo */
>-static int debuginfo__find_probes(struct debuginfo *dbg,
>+static int debuginfo__find_probe_location(struct debuginfo *dbg,
> struct probe_finder *pf)
> {
>   struct perf_probe_point *pp = >pev->point;
>@@ -1023,27 +1023,6 @@ static int debuginfo__find_probes(struct debuginfo *dbg,
>   Dwarf_Die *diep;
>   int ret = 0;
>
>-#if _ELFUTILS_PREREQ(0, 142)
>-  Elf *elf;
>-  GElf_Ehdr ehdr;
>-  GElf_Shdr shdr;
>-
>-  /* Get the call frame information from this dwarf */
>-  elf = dwarf_getelf(dbg->dbg);
>-  if (elf == NULL)
>-  return -EINVAL;
>-
>-  if (gelf_getehdr(elf, ) == NULL)
>-  return -EINVAL;
>-
>-  if (elf_section_by_name(elf, , , ".eh_frame", NULL) &&
>-  shdr.sh_type == SHT_PROGBITS) {
>-  pf->cfi = dwarf_getcfi_elf(elf);
>-  } else {
>-  pf->cfi = dwarf_getcfi(dbg->dbg);
>-  }
>-#endif
>-
>   off = 0;
>   pf->lcache = intlist__new(NULL);
>   if (!pf->lcache)
>@@ -1106,6 +1085,39 @@ found:
>   return ret;
> }
>
>+/* Find probe points from debuginfo */
>+static int debuginfo__find_probes(struct debuginfo *dbg,
>+

[PATCH 2/3] powerpc/book3s: Fix TB corruption in guest exit path on HMI interrupt.

[Mahesh J Salgaonkar]

From: Mahesh Salgaonkar 

When a guest is assigned to a core it converts the host Timebase (TB)
into guest TB by adding guest timebase offset before entering into
guest. During guest exit it restores the guest TB to host TB. This means
under certain conditions (Guest migration) host TB and guest TB can differ.

When we get an HMI for TB related issues the opal HMI handler would
try fixing errors and restore the correct host TB value. With no guest
running, we don't have any issues. But with guest running on the core
we run into TB corruption issues.

If we get an HMI while in the guest, the current HMI handler invokes opal
hmi handler before forcing guest to exit. The guest exit path subtracts
the guest TB offset from the current TB value which may have already
been restored with host value by opal hmi handler. This leads to incorrect
host and guest TB values.

With split-core, things become more complex. With split-core, TB also gets
split and each subcore gets its own TB register. When a hmi handler fixes
a TB error and restores the TB value, it affects all the TB values of
sibling subcores on the same core. On TB errors all the thread in the core
gets HMI. With existing code, the individual threads call opal hmi handle
independently which can easily throw TB out of sync if we have guest
running on subcores. Hence we will need to co-ordinate with all the
threads before making opal hmi handler call followed by TB resync.

This patch introduces a sibling subcore state structure (shared by all
threads in the core) in paca which holds information about whether sibling
subcores are in Guest mode or host mode. An array in_guest[] of size
MAX_SUBCORE_PER_CORE=4 is used to maintain the state of each subcore.
The subcore id is used as index into in_guest[] array. Only primary
thread entering/exiting the guest is responsible to set/unset its
designated array element.

On TB error, we get HMI interrupt on every thread on the core. Upon HMI,
this patch will now force guest to vacate the core/subcore. Primary
thread from each subcore will then turn off its respective bit
from the above bitmap during the guest exit path just after the
guest->host partition switch is complete.

All other threads that have just exited the guest OR were already in host
will wait until all other subcores clears their respective bit.
Once all the subcores turn off their respective bit, all threads will
will make call to opal hmi handler.

It is not necessary that opal hmi handler would resync the TB value for
every HMI interrupts. It would do so only for the HMI caused due to
TB errors. For rest, it would not touch TB value. Hence to make things
simpler, primary thread would call TB resync explicitly once for each
core immediately after opal hmi handler instead of subtracting guest
offset from TB. TB resync call will restore the TB with host value.
Thus we can be sure about the TB state.

One of the primary threads exiting the guest will take up the
responsibility of calling TB resync. It will use one of the top bits
(bit 63) from subcore state flags bitmap to make the decision. The first
primary thread (among the subcores) that is able to set the bit will
have to call the TB resync. Rest all other threads will wait until TB
resync is complete.  Once TB resync is complete all threads will then
proceed.

Signed-off-by: Mahesh Salgaonkar 
---
 arch/powerpc/include/asm/hmi.h  |   45 
 arch/powerpc/include/asm/paca.h |6 +
 arch/powerpc/kernel/Makefile|2 
 arch/powerpc/kernel/exceptions-64s.S|4 +
 arch/powerpc/kernel/hmi.c   |   56 ++
 arch/powerpc/kernel/idle_power7.S   |5 +
 arch/powerpc/kernel/traps.c |5 +
 arch/powerpc/kvm/book3s_hv.c|   37 +++
 arch/powerpc/kvm/book3s_hv_ras.c|  176 +++
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |   50 +
 10 files changed, 381 insertions(+), 5 deletions(-)
 create mode 100644 arch/powerpc/include/asm/hmi.h
 create mode 100644 arch/powerpc/kernel/hmi.c

diff --git a/arch/powerpc/include/asm/hmi.h b/arch/powerpc/include/asm/hmi.h
new file mode 100644
index 000..88b4901
--- /dev/null
+++ b/arch/powerpc/include/asm/hmi.h
@@ -0,0 +1,45 @@
+/*
+ * Hypervisor Maintenance Interrupt header file.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.
+ *
+ 

[PATCH 3/3] KVM: PPC: Book3S HV: Fix soft lockups in KVM on HMI for time base errors

[Mahesh J Salgaonkar]

From: Mahesh Salgaonkar 

When secondaries are napping in kvm_unsplit_nap() with hwthread_req = 1,
the HMI goes ignored even though subcores are already exited the guest.
Hence HMI keeps waking up secondaries from nap in a loop and secondaries
always go back to nap since no vcore is assigned to them. This makes
impossible for primary thread to get hold of secondary threads resulting
into a soft lockup in KVM path.

This patch fixes this by adding a HMI check just before the thread goes
to unsplit nap.

Signed-off-by: Mahesh Salgaonkar 
---
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index e8a456e..c5d43b9 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -440,6 +440,12 @@ kvm_no_guest:
  * whole-core mode, so we need to nap.
  */
 kvm_unsplit_nap:
+   /* Before we head down to nap, check if HMI is pending and handle it */
+   cmpwi   r12, BOOK3S_INTERRUPT_HMI
+   bne 55f
+   li  r3, 0   /* NULL argument */
+   bl  hmi_exception_realmode
+55:
/*
 * Ensure that secondary doesn't nap when it has
 * its vcore pointer set.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: Wire up copy_file_range() syscall

[Chandan Rajendra]

On Thursday 14 Jan 2016 09:53:31 Michael Ellerman wrote:
> On Wed, 2016-01-13 at 22:20 +0530, Chandan Rajendra wrote:
> > Test runs on a ppc64 BE guest succeeded.
> 
> Were the tests built 64-bit or 32-bit?
> 

The test tool (xfs_io to be precise) was built as a 64-bit binary.

-- 
chandan

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/5] misc: cxl: use kobj_to_dev()

[Geliang Tang]

Use kobj_to_dev() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/misc/cxl/sysfs.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/cxl/sysfs.c b/drivers/misc/cxl/sysfs.c
index 02006f71..038af5d 100644
--- a/drivers/misc/cxl/sysfs.c
+++ b/drivers/misc/cxl/sysfs.c
@@ -386,8 +386,7 @@ static ssize_t afu_eb_read(struct file *filp, struct 
kobject *kobj,
   struct bin_attribute *bin_attr, char *buf,
   loff_t off, size_t count)
 {
-   struct cxl_afu *afu = to_cxl_afu(container_of(kobj,
- struct device, kobj));
+   struct cxl_afu *afu = to_cxl_afu(kobj_to_dev(kobj));
 
return cxl_afu_read_err_buffer(afu, buf, off, count);
 }
@@ -467,7 +466,7 @@ static ssize_t afu_read_config(struct file *filp, struct 
kobject *kobj,
   loff_t off, size_t count)
 {
struct afu_config_record *cr = to_cr(kobj);
-   struct cxl_afu *afu = to_cxl_afu(container_of(kobj->parent, struct 
device, kobj));
+   struct cxl_afu *afu = to_cxl_afu(kobj_to_dev(kobj->parent));
 
u64 i, j, val;
 
-- 
2.5.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] ASoC: fsl: select SND_SOC_FSL_SAI or SND_SOC_FSL_SSI depending on SoC type

[Timur Tabi]

Lothar Waßmann wrote:

Why? If more than one of the IMX6 SoCs are selected, both interfaces
may be selected at the same time without any harm.


Oh, ok.  I thought the point behind the patch was that you *souldn't* 
enable the the SSI driver on an i.MX6UL.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: Wire up sys_copy_file_range()

[kbuild test robot]

Hi Michael,

[auto build test ERROR on v4.4-rc8]
[cannot apply to powerpc/next next-20160113]
[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/Michael-Ellerman/powerpc-Wire-up-sys_copy_file_range/20160113-205819
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/built-in.o: In function `sys_call_table':
>> (.rodata+0x900): undefined reference to `sys_copy_file_range'

---
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

Re: [v7,49/50] drivers/of: Export OF changeset functions

[Wolfram Sang]

On Thu, Nov 05, 2015 at 12:12:49AM +1100, Gavin Shan wrote:
> The PowerNV PCI hotplug driver is going to use the OF changeset
> to manage the changed device sub-tree. This exports those OF
> changeset functions for that.
> 
> Signed-off-by: Gavin Shan 
> Acked-by: Rob Herring 

I needed something like this, too [1] and rebased my series on top of
this patch. So:

Acked-by: Wolfram Sang 
Tested-by: Wolfram Sang 

Thanks,

   Wolfram

[1] https://lkml.org/lkml/2016/1/6/385



signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: Wire up copy_file_range() syscall

[Chandan Rajendra]

Test runs on a ppc64 BE guest succeeded.

Signed-off-by: Chandan Rajendra 
---
The "yet to be upstreamed" fstests test
(https://github.com/chandanr/xfstests/commit/c2ce6196711e02792b434448e29f45b5f9a955f6)
was used to test the syscall. The test in turn depends on the usage of xfs_io's
copy_file_range command.
(https://github.com/chandanr/xfsprogs-dev/commit/9222b48a3d03fb9d690323b460d882e559bd1080)
I will post these patches to the respective mailing lists once this patch is
mainlined.

 arch/powerpc/include/asm/systbl.h  | 1 +
 arch/powerpc/include/asm/unistd.h  | 2 +-
 arch/powerpc/include/uapi/asm/unistd.h | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/systbl.h 
b/arch/powerpc/include/asm/systbl.h
index 5654ece..3fa9df7 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -383,3 +383,4 @@ SYSCALL(ni_syscall)
 SYSCALL(ni_syscall)
 SYSCALL(ni_syscall)
 SYSCALL(mlock2)
+SYSCALL(copy_file_range)
diff --git a/arch/powerpc/include/asm/unistd.h 
b/arch/powerpc/include/asm/unistd.h
index 6a5ace5..1f2594d 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -12,7 +12,7 @@
 #include 
 
 
-#define NR_syscalls379
+#define NR_syscalls380
 
 #define __NR__exit __NR_exit
 
diff --git a/arch/powerpc/include/uapi/asm/unistd.h 
b/arch/powerpc/include/uapi/asm/unistd.h
index 12a0565..940290d 100644
--- a/arch/powerpc/include/uapi/asm/unistd.h
+++ b/arch/powerpc/include/uapi/asm/unistd.h
@@ -389,5 +389,6 @@
 #define __NR_userfaultfd   364
 #define __NR_membarrier365
 #define __NR_mlock2378
+#define __NR_copy_file_range   379
 
 #endif /* _UAPI_ASM_POWERPC_UNISTD_H_ */
-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev