Re: [PATCH] rtas: Validate rtas entry before calling enter_rtas

[Michael Ellerman]

On Sat, 2015-10-17 at 10:04 +0530, Vasant Hegde wrote:
> On 10/16/2015 11:49 PM, Denis Kirjanov wrote:
> > On 10/16/15, Vasant Hegde  wrote:
> > > On 10/16/2015 04:02 PM, Denis Kirjanov wrote:
> > > > On 10/16/15, Vasant Hegde  wrote:
> > > > > Currently we do not validate rtas entry before calling enter_rtas().
> > > > 
> > > > have you figured out why we have null entry?

> > > Yes... On PowerNV platform we don't have RTAS.. Hence it's not 
> > > initialized.

> > But why do we have CONFIG_PPC_RTAS on OPAL machines then?
 
> Today we use single config to build kernel for both PowerNV and PAPR guest. So
> that same ISO can be used in different environment (PAPR LPAR, PowerNV host,
> guest). I believe most distro also following this method. Hence we need this
> validation.

Yes that's right.

Many of our platforms can coexist. So for example you can build a 64-bit big
endian kernel with support for G5, pSeries, Powernv, PS3, IBM Cell Blades,
Pasemi, & Maple (Bimini).

That means code that is #ifdef'ed to depend on one of those platforms, may end
up running on another platform. So we usually also need a runtime check to make
sure code doesn't run in the wrong places.

You'll see a lot of initcalls are machine_xxx_initcalls(), which means they
only run if the correct platform was detected. There's also
firmware_has_feature() checks, and then also device tree based detection.

This one seems to have slipped through the cracks because the tools that call
sys_rtas() are not used on powernv machines, so no one has though to call that
syscall. And on pseries machines rtas is always present, though obviously the
code should have still checked rtas.entry to be safe.

cheers

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

Re: [PATCH v2] powerpc/prom: Avoid reference to potentially freed memory

[Michael Ellerman]

On Fri, 2015-10-16 at 23:38 +0200, Christophe JAILLET wrote:

> of_get_property() is used inside the loop, but then the reference to the
> node is dropped before dereferencing the prop pointer, which could by then
> point to junk if the node has been freed.
> 
> Instead use of_property_read_u32() to actually read the property
> value before dropping the reference.
> 
> Signed-off-by: Christophe JAILLET 
> ---
> v2: Fix missing '{'
> *** COMPILE-TESTED ONLY ***

Thanks, this looks good. I'll test it on real hardware.

Can you send me a follow up which does the of_get_next_parent() conversion?

cheers

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

Re: [PATCH] powerpc/prom: Avoid reference to potentially freed memory

[Michael Ellerman]

On Fri, 2015-10-16 at 22:09 +0200, Christophe JAILLET wrote:

> Le 16/10/2015 12:02, Michael Ellerman a écrit :

> > As the kbuild robot detected you have left an extra "}" here.
> > 
> > I don't mind too much if you send patches that aren't compile tested, but 
> > you
> > might save yourself some time by compiling them.
> 
> Sorry about it, and thanks for your patience.
> IMHO, this should never happen and patches should be at least 
> compile-tested.

Preferably yes. But for these sort of cleanup patches, where you're touching
lots of different arches, I realise it can be tedious to find all the various
cross compilers. So I'm willing to cut you a bit of slack :)

> I will be more careful and compile-test any new patch I submit.

Thanks.

cheers

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

Re: [PATCH V4 00/31] powerpc/mm: Update page table format for book3s 64

[Aneesh Kumar K.V]

Benjamin Herrenschmidt  writes:

> On Sat, 2015-10-17 at 15:38 +0530, Aneesh Kumar K.V wrote:
>> Hi All,
>> 
>> This patch series attempt to update book3s 64 linux page table format to
>> make it more flexible. Our current pte format is very restrictive and we
>> overload multiple pte bits. This is due to the non-availability of free bits
>> in pte_t. We use pte_t to track the validity of 4K subpages. This patch
>> series free up pte_t of 11 bits by moving 4K subpage tracking to the
>> lower half of PTE page. The pte format is updated such that we have a
>> better method for identifying a pte entry at pmd level. This will also enable
>> us to implement hugetlb migration(not yet done in this series). 
>
> I still have serious concerns about the fact that we now use 4 times
> more memory for page tables than strictly necessary. We were using
> twice as much before.
>
> We need to find a way to not allocate all those "other halves" when not
> needed.
>
> I understand it's tricky, we tend to notice we need the second half too
> late...
>
> Maybe if we could escalate the hash miss into a minor fault when the
> second half is needed and not present, we can then allocate it from the
>
> For demotion of the vmap space, we might have to be a bit smarter,
> maybe detect at ioremap/vmap time and flag the mm as needed second
> halves for everything (and allocate them).
>
> Of course if the machine doesn't do hw 64k, we would always allocate
> the second half.
>

I am now trying to do the conditional alloc and one of the unpleasant
side effect of that is spreading of subpage 4k information all around
the code. We have the below cases

1) subpage protection:
This will result in demotion of segment when we call sys_subpage_prot.
New allocation of pgtable_t will result in subpage tracking page
allocation by checking in pte_alloc_one as below

pte_t *page_table_alloc(struct mm_struct *mm, unsigned long vmaddr, int kernel)
{
pte_t *pte;

pte = get_from_cache(mm);
if (pte)
goto out;

pte = __alloc_for_cache(mm, kernel);
out:
if (REGIOND_ID(vmaddr) == USER_REGION_ID) {
int slice_psize;

slice_psize = get_slice_psize(mm, vmaddr);
/*
 * 64K linux page size with 4K segment base page size. Allocate
 * the 4k subpage track page
 */
if (slice_psize == MMU_PAGE_4K)
alloc_and_update_4k(pte);
}
return pte;
}

Existing allocation when trying to insert a 4K hpte will push the fault
to handle_mm_fault and I am looking at adding the below in update_mmu_cache

/*
 * The fault was sent to us because, we didn't had the subpage
 * tracking page
 */
if (pte_val(*ptep) & _PAGE_COMBO)
alloc_and_update_4k(ptep);

We would have marked the pte _PAGE_COMBO in __hash_page_4k

2) ioremap with cache inhibited restrictions:
We can handle that in map_kernel_page
/*
 * if pte is non-cacheable and we have restrictions on
 * using non cacheable large pages, we will have to use
 * 4K subpages. Allocate the 4K region, but skip the
 * segment demote
 */
if (mmu_ci_restrictions && (flags & _PAGE_NO_CACHE)) {
alloc_and_update_4k(ptep);
}

3) remap_4k_pfn:
Can we mark the segment demoted here ?. if so the pte alloc will handle
that if the remap address is in user region.

4) vmalloc space demotion because somebody did a remap_4k_pfn to an address
in that range:
Not yet sure about this 

5) Anything else I missed ?
you mention about vmap space. I was not able to find out when we would
demote an address in 0xf region ?

I will try to see if there is a better way to isolate the subpage
handling, but it looks like, we are making the code more complex by
doing the above ?

Also how do I evaluate the impact of doubling the pgtable_t size ?
Looking at the above i am wondering if this is really a issue we need
worry about ? We are better than other arch with 4K page size in-terms
of pte pages. We allocate one pte page per 128MB of address range and
for 4K page size architectures that is one per every 2MB ?

-aneesh

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

Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

[Peter Zijlstra]

On Mon, Oct 19, 2015 at 09:17:18AM +0800, Boqun Feng wrote:
> This is confusing me right now. ;-)
> 
> Let's use a simple example for only one primitive, as I understand it,
> if we say a primitive A is "fully ordered", we actually mean:
> 
> 1.The memory operations preceding(in program order) A can't be
>   reordered after the memory operations following(in PO) A.
> 
> and
> 
> 2.The memory operation(s) in A can't be reordered before the
>   memory operations preceding(in PO) A and after the memory
>   operations following(in PO) A.
> 
> If we say A is a "full barrier", we actually means:
> 
> 1.The memory operations preceding(in program order) A can't be
>   reordered after the memory operations following(in PO) A.
> 
> and
> 
> 2.The memory ordering guarantee in #1 is visible globally.
> 
> Is that correct? Or "full barrier" is more strong than I understand,
> i.e. there is a third property of "full barrier":
> 
> 3.The memory operation(s) in A can't be reordered before the
>   memory operations preceding(in PO) A and after the memory
>   operations following(in PO) A.
> 
> IOW, is "full barrier" a more strong version of "fully ordered" or not?

Yes, that was how I used it.

Now of course; the big question is do we want to promote this usage or
come up with a different set of words describing this stuff.

I think separating the ordering from the transitivity is useful, for we
can then talk about and specify them independently.

That is, we can say:

LOAD-ACQUIRE: orders LOAD->{LOAD,STORE}
  weak transitivity (RCpc)

MB: orders {LOAD,STORE}->{LOAD,STORE} (fully ordered)
strong transitivity (RCsc)

etc..

Also, in the above I used weak and strong transitivity, but that too is
of course up for grabs.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: Add run_cmd function to boot wrapper

[Geoff Levand]

Add a boot wrapper script function run_cmd which will run a shell command
quietly and only print the output if either V=1 or an error occurs.

Also, run the ps3 dd commands with run_cmd to clean up the build output.

Signed-off-by: Geoff Levand 
---
Hi Michael,

How about something like this?  It seems a little cleaner.

-Geoff

 arch/powerpc/boot/wrapper | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 3f50c27..ceaa75d 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -63,6 +63,23 @@ usage() {
 exit 1
 }
 
+run_cmd() {
+if [ "$V" = 1 ]; then
+$* 2>&1
+else
+local msg
+
+set +e
+msg=$($* 2>&1)
+
+if [ $? -ne "0" ]; then
+echo $msg
+exit 1
+fi
+set -e
+fi
+}
+
 while [ "$#" -gt 0 ]; do
 case "$1" in
 -o)
@@ -456,12 +473,12 @@ ps3)
 
 ${CROSS}objcopy -O binary "$ofile" "$ofile.bin"
 
-dd if="$ofile.bin" of="$ofile.bin" conv=notrunc   \
-skip=$overlay_dest seek=$system_reset_kernel  \
+run_cmd dd if="$ofile.bin" of="$ofile.bin" conv=notrunc   \
+skip=$overlay_dest seek=$system_reset_kernel  \
 count=$overlay_size bs=1
 
-dd if="$ofile.bin" of="$ofile.bin" conv=notrunc   \
-skip=$system_reset_overlay seek=$overlay_dest \
+run_cmd dd if="$ofile.bin" of="$ofile.bin" conv=notrunc   \
+skip=$system_reset_overlay seek=$overlay_dest \
 count=$overlay_size bs=1
 
 odir="$(dirname "$ofile.bin")"
-- 
2.5.0

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

Re: [PATCH 04/17] powerpc: mpic: use IRQCHIP_SKIP_SET_WAKE instead of redundant mpic_irq_set_wake

[Scott Wood]

On Mon, 2015-10-19 at 18:35 +0100, Sudeep Holla wrote:
> Hi Ben,
> 
> On 23/09/15 05:06, Scott Wood wrote:
> > On Mon, 2015-09-21 at 16:47 +0100, Sudeep Holla wrote:
> > > mpic_irq_set_wake return -ENXIO for non FSL MPIC and sets 
> > > IRQF_NO_SUSPEND
> > > flag for FSL ones. enable_irq_wake already returns -ENXIO if irq_set_wak
> > > is not implemented. Also there's no need to set the IRQF_NO_SUSPEND flag
> > > as it doesn't guarantee wakeup for that interrupt.
> > > 
> > > This patch removes the redundant mpic_irq_set_wake and sets the
> > > IRQCHIP_SKIP_SET_WAKE for only FSL MPIC.
> > > 
> > > Cc: Benjamin Herrenschmidt 
> > > Cc: Paul Mackerras 
> > > Cc: Michael Ellerman 
> > > Cc: Scott Wood 
> > > Cc: Hongtao Jia 
> > > Cc: Marc Zyngier 
> > > Cc: linuxppc-dev@lists.ozlabs.org
> > > Signed-off-by: Sudeep Holla 
> > > ---
> > >   arch/powerpc/sysdev/mpic.c | 23 ---
> > >   1 file changed, 4 insertions(+), 19 deletions(-)
> > 
> > Acked-by: Scott Wood 
> > 
> 
> Can you pick this up via your tree ?

OK.

-Scott

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

Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

[Nishanth Aravamudan]

On 15.10.2015 [15:52:19 -0700], Nishanth Aravamudan wrote:
> On 14.10.2015 [08:42:51 -0700], Christoph Hellwig wrote:
> > Hi Nishanth,
> > 
> > sorry for the late reply.
> > 
> > > > On Power, since it's technically variable, we'd need a function. So are
> > > > you suggesting define'ing it to a function just on Power and leaving it
> > > > a constant elsewhere?
> > > > 
> > > > I noticed that sparc has a IOMMU_PAGE_SHIFT already, fwiw.
> > > 
> > > Sorry, I should have been more specific -- I'm ready to spin out a v3,
> > > with a sparc-specific function.
> > > 
> > > Are you ok with leaving it a function for now (the only caller is in
> > > NVMe obviously).
> > 
> > 
> > I guess we do indeed need a function then.  I'll take a look at your
> > patch, but as long you found a way to avoid adding too much boilerplate
> > code it should be fine.
> 
> Ok, so I've got the moved function (include/linux/dma-mapping.h
> instead of dma-mapping-common.h) ready to go, which should only
> involve changing the first patch in the series. But I'm really
> mystified by what to do for sparc, which defines IOMMU_PAGE_SHIFT and
> IO_PAGE_SHIFT in arch/sparc/kernel/iommu_common.h.
> 
> 1) Which constant reflects the value we mean for this function on
> sparc?  I assume it should be IOMMU_PAGE_SHIFT, but they are the same
> value and I want to make sure I get the semantics right.
> 
> 2) Where would I put sparc's definition of dma_get_page_shift()?
> Should it be in a asm/dma-mapping.h? Should we move some of the
> constants from arch/sparc/kernel/iommu_common.h to
> arch/sparc/include/asm/iommu_common.h and then #include that in
> asm/dma-mapping.h?
> 
> Dave M., any opinions/insights? Essentially, this helper function
> assists the NVMe driver in determining what page size it should use to
> satisfy both the device and IOMMU's requirements. Maybe I
> misunderstand the constants on sparc and PAGE_SHIFT is fine there too?

Anyone with sparc knowledge have an opinion/input?

-Nish

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

Re: [PATCH 04/17] powerpc: mpic: use IRQCHIP_SKIP_SET_WAKE instead of redundant mpic_irq_set_wake

[Sudeep Holla]

Hi Ben,

On 23/09/15 05:06, Scott Wood wrote:

On Mon, 2015-09-21 at 16:47 +0100, Sudeep Holla wrote:

mpic_irq_set_wake return -ENXIO for non FSL MPIC and sets IRQF_NO_SUSPEND
flag for FSL ones. enable_irq_wake already returns -ENXIO if irq_set_wak
is not implemented. Also there's no need to set the IRQF_NO_SUSPEND flag
as it doesn't guarantee wakeup for that interrupt.

This patch removes the redundant mpic_irq_set_wake and sets the
IRQCHIP_SKIP_SET_WAKE for only FSL MPIC.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Scott Wood 
Cc: Hongtao Jia 
Cc: Marc Zyngier 
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Sudeep Holla 
---
  arch/powerpc/sysdev/mpic.c | 23 ---
  1 file changed, 4 insertions(+), 19 deletions(-)


Acked-by: Scott Wood 



Can you pick this up via your tree ?

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

Re: [PATCH] powerpc: Add run_cmd function to boot wrapper

[Michael Ellerman]

On Mon, 2015-10-19 at 10:53 -0700, Geoff Levand wrote:

> Add a boot wrapper script function run_cmd which will run a shell command
> quietly and only print the output if either V=1 or an error occurs.
> 
> Also, run the ps3 dd commands with run_cmd to clean up the build output.
> 
> Signed-off-by: Geoff Levand 
> ---
> Hi Michael,
> 
> How about something like this?  It seems a little cleaner.

Yeah great that's nice, I'll take it.

cheers

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

[PATCH v3 13/17] powerpc/book3e-64: Don't limit paca to 256 MiB

[Scott Wood]

This limit only makes sense on book3s, and on book3e it can cause
problems with kdump if we don't have any memory under 256 MiB.

Signed-off-by: Scott Wood 
---
v3: Fix book3s build error

 arch/powerpc/kernel/paca.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 5a23b69..01ea0ed 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -204,14 +204,19 @@ static int __initdata paca_size;
 
 void __init allocate_pacas(void)
 {
-   int cpu, limit;
+   u64 limit;
+   int cpu;
 
+   limit = ppc64_rma_size;
+
+#ifdef CONFIG_PPC_BOOK3S_64
/*
 * We can't take SLB misses on the paca, and we want to access them
 * in real mode, so allocate them within the RMA and also within
 * the first segment.
 */
-   limit = min(0x1000ULL, ppc64_rma_size);
+   limit = min(0x1000ULL, limit);
+#endif
 
paca_size = PAGE_ALIGN(sizeof(struct paca_struct) * nr_cpu_ids);
 
-- 
2.1.4

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

Re: [PATCH] selfttest/powerpc: Add memory page migration tests

[Anshuman Khandual]

On 10/16/2015 05:09 PM, Aneesh Kumar K.V wrote:
> Anshuman Khandual  writes:
> 
>> On 10/15/2015 09:16 PM, Anshuman Khandual wrote:
>>> This adds two tests for memory page migration. One for normal page
>>> migration which works for both 4K or 64K base page size kernel and
>>> the other one is for 16MB huge page migration which will work both
>>> 4K or 64K base page sized 16MB huge pages as and when we support
>>> huge page migration.
>>>
>>> Signed-off-by: Anshuman Khandual 
>>> ---
>>> - Works for normal page migration on both 64K and 4K base pages
>>> - Works for 16MB huge page migration (64K) on Aneesh's V2 PTE changes
>>>
>>> +
>>> +int test_migration(unsigned long length)
>>> +{
>>> +   unsigned long failed;
>>> +   void *addr;
>>> +   int ret;
>>> +
>>> +   addr = mmap(MMAP_ADDR, length, MMAP_PROT, MMAP_FLAGS, -1, 0);
>>> +   if (addr == MAP_FAILED) {
>>> +   perror("mmap() failed");
>>> +   exit(-1);
>>> +   }
>>
>> Will add a mlock() call here as well. Some times soft offline
>> fails while trying to move a huge chunk of memory on a system
>> because of swapping. With a mlock() in there the problem gets
>> resolved.
> 
> Is that with respect to hugetlb pages ? I doubt, because hugetlb pages
> are not swapped out.

Thats correct. It is related to normal pages (4K or 64K). Have not
seen this swap problem of HugeTLB pages.

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

linux-next: build warning after merge of the powerpc tree

[Stephen Rothwell]

Hi all,

After merging the powerpc tree, today's linux-next build (powerpc
allyesconfig) produced this warning:

WARNING: vmlinux.o(.text+0x9367c): Section mismatch in reference from the 
function .msi_bitmap_alloc() to the function 
.init.text:.memblock_virt_alloc_try_nid()
The function .msi_bitmap_alloc() references
the function __init .memblock_virt_alloc_try_nid().
This is often because .msi_bitmap_alloc lacks a __init
annotation or the annotation of .memblock_virt_alloc_try_nid is wrong.

Introduced (probably) by commit

  cb2d3883c603 ("powerpc/msi: Free the bitmap if it was slab allocated")

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC][PATCH 3/3]perf/powerpc :add support for sampling intr machine state

[Madhavan Srinivasan]

On Monday 19 October 2015 05:48 PM, Anju T wrote:
> From: Anju 
>
> The registers to sample are passed through the sample_regs_intr bitmask.
> The name and bit position for each register is defined in asm/perf_regs.h.
> This feature can be enabled by using -I option with perf  record command.
> To display the sampled register values use perf script -D.
> The kernel uses the "PERF" register ids to find offset of the register in 
> 'struct pt_regs'.
> CONFIG_HAVE_PERF_REGS will enable sampling of the interrupted machine state.
>
> Signed-off-by: Anju T 
> ---
>  arch/powerpc/Kconfig  |  1 +
>  arch/powerpc/perf/Makefile|  2 +-
>  arch/powerpc/perf/perf_regs.c | 85 
> +++
>  tools/perf/config/Makefile|  4 ++
>  4 files changed, 91 insertions(+), 1 deletion(-)
>  create mode 100644 arch/powerpc/perf/perf_regs.c
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 9a7057e..c4ce60d 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -119,6 +119,7 @@ config PPC
>   select GENERIC_ATOMIC64 if PPC32
>   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>   select HAVE_PERF_EVENTS
> + select HAVE_PERF_REGS
>   select HAVE_REGS_AND_STACK_ACCESS_API
>   select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
>   select ARCH_WANT_IPC_PARSE_VERSION
> diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
> index f9c083a..8e7f545 100644
> --- a/arch/powerpc/perf/Makefile
> +++ b/arch/powerpc/perf/Makefile
> @@ -7,7 +7,7 @@ obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o 
> power5-pmu.o \
>  power5+-pmu.o power6-pmu.o power7-pmu.o \
>  power8-pmu.o
>  obj32-$(CONFIG_PPC_PERF_CTRS)+= mpc7450-pmu.o
> -
> +obj-$(CONFIG_PERF_EVENTS)+= perf_regs.o
>  obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
>  obj-$(CONFIG_FSL_EMB_PERF_EVENT_E500) += e500-pmu.o e6500-pmu.o
>
> diff --git a/arch/powerpc/perf/perf_regs.c b/arch/powerpc/perf/perf_regs.c
> new file mode 100644
> index 000..7a71de2
> --- /dev/null
> +++ b/arch/powerpc/perf/perf_regs.c
> @@ -0,0 +1,85 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PT_REGS_OFFSET(id, r) [id] = offsetof(struct pt_regs, r)
> +
> +#define REG_RESERVED (~((1ULL << PERF_REG_POWERPC_MAX) - 1))
> +
> +static unsigned int pt_regs_offset[PERF_REG_POWERPC_MAX] = {
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR0, gpr[0]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR1, gpr[1]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR2, gpr[2]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR3, gpr[3]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR4, gpr[4]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR5, gpr[5]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR6, gpr[6]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR7, gpr[7]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR8, gpr[8]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR9, gpr[9]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR10, gpr[10]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR11, gpr[11]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR12, gpr[12]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR13, gpr[13]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR14, gpr[14]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR15, gpr[15]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR16, gpr[16]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR17, gpr[17]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR18, gpr[18]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR19, gpr[19]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR20, gpr[20]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR21, gpr[21]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR22, gpr[22]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR23, gpr[23]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR24, gpr[24]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR25, gpr[25]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR26, gpr[26]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR27, gpr[27]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR28, gpr[28]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR29, gpr[29]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR30, gpr[30]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR31, gpr[31]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_NIP, nip),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_MSR, msr),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_ORIG_R3, orig_gpr3),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_CTR, ctr),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_LNK, link),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_XER, xer),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_CCR, ccr),
> +#ifdef __powerpc64__
> + PT_REGS_OFFSET(PERF_REG_POWERPC_SOFTE, softe),
> +#else
> + PT_REGS_OFFSET(PERF_REG_POWERPC_MQ, mq),
> +#endif
> + PT_REGS_OFFSET(PERF_REG_POWERPC_TRAP, trap),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_DAR, dar),
> + 

Re: [PATCH 1/3] perf/powerpc:add ability to sample intr machine state in power

[Madhavan Srinivasan]

On Monday 19 October 2015 05:48 PM, Anju T wrote:
> From: Anju 
>
> The enum definition assigns an 'id' to each register in power.

I guess it should be "each register in "struct pt_regs" of arch/powerpc
> The order of these values in the enum definition are based on
> the corresponding macros in arch/powerpc/include/uapi/asm/ptrace.h .
>
> Signed-off-by: Anju T 
> ---
>  arch/powerpc/include/uapi/asm/perf_regs.h | 55 
> +++
>  1 file changed, 55 insertions(+)
>  create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h
>
> diff --git a/arch/powerpc/include/uapi/asm/perf_regs.h 
> b/arch/powerpc/include/uapi/asm/perf_regs.h
> new file mode 100644
> index 000..b97727c
> --- /dev/null
> +++ b/arch/powerpc/include/uapi/asm/perf_regs.h
> @@ -0,0 +1,55 @@
> +#ifndef _ASM_POWERPC_PERF_REGS_H
> +#define _ASM_POWERPC_PERF_REGS_H
> +
> +enum perf_event_powerpc_regs {
> + PERF_REG_POWERPC_GPR0,
> + PERF_REG_POWERPC_GPR1,
> + PERF_REG_POWERPC_GPR2,
> + PERF_REG_POWERPC_GPR3,
> + PERF_REG_POWERPC_GPR4,
> + PERF_REG_POWERPC_GPR5,
> + PERF_REG_POWERPC_GPR6,
> + PERF_REG_POWERPC_GPR7,
> + PERF_REG_POWERPC_GPR8,
> + PERF_REG_POWERPC_GPR9,
> + PERF_REG_POWERPC_GPR10,
> + PERF_REG_POWERPC_GPR11,
> + PERF_REG_POWERPC_GPR12,
> + PERF_REG_POWERPC_GPR13,
> + PERF_REG_POWERPC_GPR14,
> + PERF_REG_POWERPC_GPR15,
> + PERF_REG_POWERPC_GPR16,
> + PERF_REG_POWERPC_GPR17,
> + PERF_REG_POWERPC_GPR18,
> + PERF_REG_POWERPC_GPR19,
> + PERF_REG_POWERPC_GPR20,
> + PERF_REG_POWERPC_GPR21,
> + PERF_REG_POWERPC_GPR22,
> + PERF_REG_POWERPC_GPR23,
> + PERF_REG_POWERPC_GPR24,
> + PERF_REG_POWERPC_GPR25,
> + PERF_REG_POWERPC_GPR26,
> + PERF_REG_POWERPC_GPR27,
> + PERF_REG_POWERPC_GPR28,
> + PERF_REG_POWERPC_GPR29,
> + PERF_REG_POWERPC_GPR30,
> + PERF_REG_POWERPC_GPR31,
> + PERF_REG_POWERPC_NIP,
> + PERF_REG_POWERPC_MSR,
> + PERF_REG_POWERPC_ORIG_R3,
> + PERF_REG_POWERPC_CTR,
> + PERF_REG_POWERPC_LNK,
> + PERF_REG_POWERPC_XER,
> + PERF_REG_POWERPC_CCR,
> +#ifdef __powerpc64__
> + PERF_REG_POWERPC_SOFTE,
> +#else
> + PERF_REG_POWERPC_MQ,
> +#endif
> + PERF_REG_POWERPC_TRAP,
> + PERF_REG_POWERPC_DAR,
> + PERF_REG_POWERPC_DSISR,
> + PERF_REG_POWERPC_RESULT,
> + PERF_REG_POWERPC_MAX,
> +};
> +#endif /* _ASM_POWERPC_PERF_REGS_H */

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