Re: [PATCH v3] powerpc: Fix PTE page address mismatch in pgtable ctor/dtor
Benjamin Herrenschmidt writes:
> On Sat, 2013-12-07 at 09:06 -0500, Hong H. Pham wrote:
>
>> diff --git a/arch/powerpc/include/asm/pgalloc-32.h
>> b/arch/powerpc/include/asm/pgalloc-32.h
>> index 27b2386..842846c 100644
>> --- a/arch/powerpc/include/asm/pgalloc-32.h
>> +++ b/arch/powerpc/include/asm/pgalloc-32.h
>> @@ -84,10 +84,8 @@ static inline void pgtable_free_tlb(struct mmu_gather
>> *tlb,
>> static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t table,
>>unsigned long address)
>> {
>> -struct page *page = page_address(table);
>> -
>> tlb_flush_pgtable(tlb, address);
>> -pgtable_page_dtor(page);
>> -pgtable_free_tlb(tlb, page, 0);
>> +pgtable_page_dtor(table);
>> +pgtable_free_tlb(tlb, page_address(table), 0);
>> }
>
> Ok so your description of the problem confused me a bit, but I see that
> in the !64K page, pgtable_t is already a struct page so yes, the
> page_address() call here is bogus.
>
> However, I also noticed that in the 64k page case, we don't call the dto
> at all. Is that a problem ?
>
> Also, Aneesh, shouldn't we just fix the disconnect here and have
> pgtable_t always be the same type ? The way this is now is confusing
> and error prone...
With pte page fragments that may not be possible right ?. With PTE fragments,
we share the page allocated with multiple pmd entries
5c1f6ee9a31cbdac90bbb8ae1ba4475031ac74b4 should have more details
>
>> #endif /* _ASM_POWERPC_PGALLOC_32_H */
>> diff --git a/arch/powerpc/include/asm/pgalloc-64.h
>> b/arch/powerpc/include/asm/pgalloc-64.h
>> index f65e27b..256d6f8 100644
>> --- a/arch/powerpc/include/asm/pgalloc-64.h
>> +++ b/arch/powerpc/include/asm/pgalloc-64.h
>> @@ -144,11 +144,9 @@ static inline void pgtable_free_tlb(struct mmu_gather
>> *tlb,
>> static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t table,
>>unsigned long address)
>> {
>> -struct page *page = page_address(table);
>> -
>> tlb_flush_pgtable(tlb, address);
>> -pgtable_page_dtor(page);
>> -pgtable_free_tlb(tlb, page, 0);
>> +pgtable_page_dtor(table);
>> +pgtable_free_tlb(tlb, page_address(table), 0);
>> }
>>
>> #else /* if CONFIG_PPC_64K_PAGES */
>
> Ben.
-aneesh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc: Fix PTE page address mismatch in pgtable ctor/dtor
"Hong H. Pham" writes:
> From: "Hong H. Pham"
>
> In pte_alloc_one(), pgtable_page_ctor() is passed an address that has
> not been converted by page_address() to the newly allocated PTE page.
>
> When the PTE is freed, __pte_free_tlb() calls pgtable_page_dtor()
> with an address to the PTE page that has been converted by page_address().
> The mismatch in the PTE's page address causes pgtable_page_dtor() to access
> invalid memory, so resources for that PTE (such as the page lock) is not
> properly cleaned up.
>
> On PPC32, only SMP kernels are affected.
>
> On PPC64, only SMP kernels with 4K page size are affected.
>
> This bug was introduced by commit d614bb041209fd7cb5e4b35e11a7b2f6ee8f62b8
> "powerpc: Move the pte free routines from common header".
>
> On a preempt-rt kernel, a spinlock is dynamically allocated for each
> PTE in pgtable_page_ctor(). When the PTE is freed, calling
> pgtable_page_dtor() with a mismatched page address causes a memory leak,
> as the pointer to the PTE's spinlock is bogus.
>
> On mainline, there isn't any immediately obvious symptoms, but the
> problem still exists here.
>
> Fixes: d614bb041209fd7c "powerpc: Move the pte free routes from common header"
> Cc: Paul Mackerras
> Cc: Aneesh Kumar K.V
> Cc: Benjamin Herrenschmidt
> Cc: linux-stable # v3.10+
> Signed-off-by: Hong H. Pham
Reviewed-by: Aneesh Kumar K.V
> ---
> arch/powerpc/include/asm/pgalloc-32.h | 6 ++
> arch/powerpc/include/asm/pgalloc-64.h | 6 ++
> 2 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/pgalloc-32.h
> b/arch/powerpc/include/asm/pgalloc-32.h
> index 27b2386..842846c 100644
> --- a/arch/powerpc/include/asm/pgalloc-32.h
> +++ b/arch/powerpc/include/asm/pgalloc-32.h
> @@ -84,10 +84,8 @@ static inline void pgtable_free_tlb(struct mmu_gather *tlb,
> static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t table,
> unsigned long address)
> {
> - struct page *page = page_address(table);
> -
> tlb_flush_pgtable(tlb, address);
> - pgtable_page_dtor(page);
> - pgtable_free_tlb(tlb, page, 0);
> + pgtable_page_dtor(table);
> + pgtable_free_tlb(tlb, page_address(table), 0);
> }
> #endif /* _ASM_POWERPC_PGALLOC_32_H */
> diff --git a/arch/powerpc/include/asm/pgalloc-64.h
> b/arch/powerpc/include/asm/pgalloc-64.h
> index f65e27b..256d6f8 100644
> --- a/arch/powerpc/include/asm/pgalloc-64.h
> +++ b/arch/powerpc/include/asm/pgalloc-64.h
> @@ -144,11 +144,9 @@ static inline void pgtable_free_tlb(struct mmu_gather
> *tlb,
> static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t table,
> unsigned long address)
> {
> - struct page *page = page_address(table);
> -
> tlb_flush_pgtable(tlb, address);
> - pgtable_page_dtor(page);
> - pgtable_free_tlb(tlb, page, 0);
> + pgtable_page_dtor(table);
> + pgtable_free_tlb(tlb, page_address(table), 0);
> }
>
> #else /* if CONFIG_PPC_64K_PAGES */
> --
> 1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
MPC8641 BASED Custom designed Board Linux stucks after Mounting cache hash table entries
Hii All, I am trying to port linux 2.6.34 to mpc8641d based custom designed board but I am facing kernel oops after mounting hash table entries. can anybody was facing this kind of issue while porting or can give me some light on this. Any pointer/direction will be very helpfull. Here I am showing the snapshot of the problem for more understanding this issue.. bootm 160 60 140 ## Booting kernel from Legacy Image at 0160 ... Image Name: Linux-2.6.34 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:2615699 Bytes = 2.5 MiB Load Address: Entry Point: Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 0060 ... Image Name: rootfs Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:8043648 Bytes = 7.7 MiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 0140 Booting using the fdt blob at 0x0140 Uncompressing Kernel Image ... OK Loading Ramdisk to 1f6fb000, end 1fea6c80 ... OK Loading Device Tree to 007fb000, end 007ff919 ... OK Using MPC86xx HPCN machine description Total memory = 512MB; using 1024kB for hash table (at cff0) Linux version 2.6.34 (ashish@ashish-virtual-machine) (gcc version 4.7.2 (GCC) ) #1 Fri Dec 6 10:38:44 IST 2013 Found initrd at 0xdf6fb000:0xdfea6c80 bootconsole [udbg0] enabled setup_arch: bootmem mpc86xx_hpcn_setup_arch() MPC86xx HPCN board from Freescale Semiconductor arch: exit Zone PFN ranges: DMA 0x -> 0x0002 Normal empty HighMem empty Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x -> 0x0002 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: mem=512m root=/dev/ram console=ttyS0,115200 PID hash table entries: 2048 (order: 1, 8192 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 505540k/524288k available (4976k kernel code, 18748k reserved, 196k data, 160k bss, 192k init) Kernel virtual memory layout: * 0xfffd..0xf000 : fixmap * 0xff80..0xffc0 : highmem PTEs * 0xff7fe000..0xff80 : early ioremap * 0xe100..0xff7fe000 : vmalloc & ioremap SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. NR_IRQS:512 nr_irqs:512 mpic: Setting up MPIC " MPIC " version 1.2 at f804, max 2 CPUs mpic: ISU size: 256, shift: 8, mask: ff mpic: Initializing for 256 sources clocksource: timebase mult[200] shift[22] registered Console: colour dummy device 80x25 Mount-cache hash table entries: 512 Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc00179c8 Oops: Kernel access of bad area, sig: 11 [#1] MPC86xx HPCN last sysfs file: Modules linked in: NIP: c00179c8 LR: c00d69ec CTR: 0008 REGS: c0507e40 TRAP: 0300 Not tainted (2.6.34) MSR: 9032 CR: 8428 XER: DAR: , DSISR: 4000 TASK = c04de410[0] 'swapper' THREAD: c0506000 GPR00: c00d6da0 c0507ef0 c04de410 0064 df01d0e0 GPR08: 000d c0503194 4422 f8af 200c9000 GPR16: fbbfdffb 0024 1fea8b08 1fea8d24 GPR24: 1fffa2e4 4000 1ffcd66c dfffed30 df01d080 NIP [c00179c8] strcmp+0x10/0x24 LR [c00d69ec] duplicate_name+0x3c/0x74 Call Trace: [c0507ef0] [c07fc440] 0xc07fc440 (unreliable) [c0507f00] [c00d6da0] proc_device_tree_add_node+0xfc/0x144 [c0507f20] [c00d6ce4] proc_device_tree_add_node+0x40/0x144 [c0507f40] [c00d6ce4] proc_device_tree_add_node+0x40/0x144 [c0507f60] [c00d6ce4] proc_device_tree_add_node+0x40/0x144 [c0507f80] [c00d6ce4] proc_device_tree_add_node+0x40/0x144 [c0507fa0] [c04bdcd4] proc_device_tree_init+0x68/0x94 [c0507fb0] [c04bd6f8] proc_root_init+0xd0/0x108 [c0507fc0] [c04ac728] start_kernel+0x2b4/0x2cc [c0507ff0] [3444] 0x3444 Instruction dump: 2c00 4082fff8 38a5 8c040001 2c00 9c050001 4082fff4 4e800020 38a3 3884 8c650001 2c83 <8c040001> 7c601851 4d860020 4182ffec ---[ end trace 31fd0ba7d8756001 ]--- Kernel panic - not syncing: Attempted to kill the idle task! Rebooting in 180 seconds.. Regards Ashish Kumar Khetan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix up the kdump base cap to 128M
From: Mahesh Salgaonkar The current logic sets the kdump base to min of 2G or ppc64_rma_size/2. On PowerNV kernel the first memory block 'memory@0' can be very large, equal to the DIMM size with ppc64_rma_size value capped to 1G. Hence on PowerNV, kdump base is set to 512M resulting kdump to fail while allocating paca array. This is because, paca need its memory from RMA region capped at 256M (see allocate_pacas()). This patch lowers the kdump base cap to 128M so that kdump kernel can successfully get memory below 256M for paca allocation. Signed-off-by: Mahesh Salgaonkar --- arch/powerpc/kernel/machine_kexec.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c index 88a7fb4..75d4f73 100644 --- a/arch/powerpc/kernel/machine_kexec.c +++ b/arch/powerpc/kernel/machine_kexec.c @@ -148,7 +148,7 @@ void __init reserve_crashkernel(void) * a small SLB (128MB) since the crash kernel needs to place * itself and some stacks to be in the first segment. */ - crashk_res.start = min(0x8000ULL, (ppc64_rma_size / 2)); + crashk_res.start = min(0x800ULL, (ppc64_rma_size / 2)); #else crashk_res.start = KDUMP_KERNELBASE; #endif ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/44x: fix ocm_block allocation
Hi Ilia Mirkin,
Thanks for your info. I did investigated why our test didn't detect it and
found out that the struct ocm_block is only used on ocm_debugfs_show
function when we want to know information about ocm and it's available when
we enable debugfs. But our test only tried to use the OCM block functions
and didn't care about the OCM information. So I think we should apply your
patch to solve this issue instead of removing ocm part.
On Sat, Dec 7, 2013 at 7:43 AM, Ilia Mirkin wrote:
> Allocate enough memory for the ocm_block structure, not just a pointer
> to it.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> I have neither the hardware to test nor the toolchain to even build-test
> this. However this seems like a fairly obvious fix (and I have to wonder
> how
> this ever worked at all). Found with spatch.
>
> Actually further investigation makes it seem like this function is never
> called, perhaps it should just be removed? If it is kept around though,
> would
> be nice to apply this patch so that tools don't trip over this wrong code.
>
> arch/powerpc/sysdev/ppc4xx_ocm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/sysdev/ppc4xx_ocm.c
> b/arch/powerpc/sysdev/ppc4xx_ocm.c
> index b7c4345..85d9e37 100644
> --- a/arch/powerpc/sysdev/ppc4xx_ocm.c
> +++ b/arch/powerpc/sysdev/ppc4xx_ocm.c
> @@ -339,7 +339,7 @@ void *ppc4xx_ocm_alloc(phys_addr_t *phys, int size,
> int align,
> if (IS_ERR_VALUE(offset))
> continue;
>
> - ocm_blk = kzalloc(sizeof(struct ocm_block *), GFP_KERNEL);
> + ocm_blk = kzalloc(sizeof(struct ocm_block), GFP_KERNEL);
> if (!ocm_blk) {
> printk(KERN_ERR "PPC4XX OCM: could not allocate
> ocm block");
> rh_free(ocm_reg->rh, offset);
> --
> 1.8.3.2
>
>
--
*Vinh Nguyen Huu Tuong **|** Staff SW Engineer*
C: 090.335.7841 | O: 083.770.0640 ext: 3719
F: 083.770.0641 | vhtngu...@apm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/44x: fix ocm_block allocation
On Mon, Dec 9, 2013 at 3:38 AM, Vinh Huu Tuong Nguyen wrote:
>
> Hi Ilia Mirkin,
> Thanks for your info. I did investigated why our test didn't detect it and
> found out that
> the struct ocm_block is only used on ocm_debugfs_show function when we want to
> know information about ocm and it's available when we enable debugfs. But our
> test
> only tried to use the OCM block functions and didn't care about the OCM
> information.
> So I think we should apply your patch to solve this issue instead of removing
> ocm part.
>
OK, perhaps there's something clever gong on. However on my git tree
(updated as of a few days ago):
$ git grep ppc4xx_ocm_alloc
arch/powerpc/include/asm/ppc4xx_ocm.h:void
*ppc4xx_ocm_alloc(phys_addr_t *phys, int size, int align,
arch/powerpc/include/asm/ppc4xx_ocm.h:#define ppc4xx_ocm_alloc(phys,
size, align, flags, owner) NULL
arch/powerpc/sysdev/ppc4xx_ocm.c:void *ppc4xx_ocm_alloc(phys_addr_t
*phys, int size, int align,
So... no users. Unless there's macro-related cleverness going on (I'll
freely admit to not having read/understood the full code, so could
well be.) Perhaps it was meant to be used but the call got lost?
-ilia
>
>
>
> On Sat, Dec 7, 2013 at 7:43 AM, Ilia Mirkin wrote:
>>
>> Allocate enough memory for the ocm_block structure, not just a pointer
>> to it.
>>
>> Signed-off-by: Ilia Mirkin
>> ---
>>
>> I have neither the hardware to test nor the toolchain to even build-test
>> this. However this seems like a fairly obvious fix (and I have to wonder how
>> this ever worked at all). Found with spatch.
>>
>> Actually further investigation makes it seem like this function is never
>> called, perhaps it should just be removed? If it is kept around though, would
>> be nice to apply this patch so that tools don't trip over this wrong code.
>>
>> arch/powerpc/sysdev/ppc4xx_ocm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/sysdev/ppc4xx_ocm.c
>> b/arch/powerpc/sysdev/ppc4xx_ocm.c
>> index b7c4345..85d9e37 100644
>> --- a/arch/powerpc/sysdev/ppc4xx_ocm.c
>> +++ b/arch/powerpc/sysdev/ppc4xx_ocm.c
>> @@ -339,7 +339,7 @@ void *ppc4xx_ocm_alloc(phys_addr_t *phys, int size, int
>> align,
>> if (IS_ERR_VALUE(offset))
>> continue;
>>
>> - ocm_blk = kzalloc(sizeof(struct ocm_block *), GFP_KERNEL);
>> + ocm_blk = kzalloc(sizeof(struct ocm_block), GFP_KERNEL);
>> if (!ocm_blk) {
>> printk(KERN_ERR "PPC4XX OCM: could not allocate ocm
>> block");
>> rh_free(ocm_reg->rh, offset);
>> --
>> 1.8.3.2
>>
>
>
>
> --
>
> Vinh Nguyen Huu Tuong | Staff SW Engineer
>
> C: 090.335.7841 | O: 083.770.0640 ext: 3719
>
> F: 083.770.0641 | vhtngu...@apm.com
>
>
>
>
>
>
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powernv: fix VFIO support with PHB3
I have recently found out that no iommu_groups could be found under /sys/ on a P8. That prevents PCI passthrough from working. During my investigation, I found out there seems to be a missing iommu_register_group for PHB3. The following patch seems to fix the problem. After applying it, I see iommu_groups under /sys/kernel/iommu_groups/, and can also bind vfio-pci to an adapter, which gives me a device at /dev/vfio/. Signed-off-by: Thadeu Lima de Souza Cascardo --- This is now applied on top of benh's tree, branch next. Alexey, is this now OK for you? Thanks. Cascardo. --- arch/powerpc/platforms/powernv/pci-ioda.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c index 614356c..f0e6871 100644 --- a/arch/powerpc/platforms/powernv/pci-ioda.c +++ b/arch/powerpc/platforms/powernv/pci-ioda.c @@ -720,6 +720,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb, tbl->it_type = TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE; } iommu_init_table(tbl, phb->hose->node); + iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number); if (pe->pdev) set_iommu_table_base_and_group(&pe->pdev->dev, tbl); -- 1.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix "attempt to move .org backwards" error
From: Mahesh Salgaonkar With recent machine check patch series changes, The exception vectors starting from 0x4300 are now overflowing with allyesconfig. Fix that by moving machine_check_common and machine_check_handle_early code out of that region to make enough room for exception vector area. Fixes this build error reportes by Stephen: arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:958: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:959: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:983: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:984: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1003: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1013: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1014: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1015: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1016: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1017: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1018: Error: attempt to move .org backwards Signed-off-by: Mahesh Salgaonkar --- arch/powerpc/kernel/exceptions-64s.S | 280 +- 1 file changed, 140 insertions(+), 140 deletions(-) diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S index 862b9dd..b5c3313 100644 --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -768,146 +768,6 @@ kvmppc_skip_Hinterrupt: STD_EXCEPTION_COMMON(0x100, system_reset, .system_reset_exception) - /* -* Machine check is different because we use a different -* save area: PACA_EXMC instead of PACA_EXGEN. -*/ - .align 7 - .globl machine_check_common -machine_check_common: - - mfspr r10,SPRN_DAR - std r10,PACA_EXGEN+EX_DAR(r13) - mfspr r10,SPRN_DSISR - stw r10,PACA_EXGEN+EX_DSISR(r13) - EXCEPTION_PROLOG_COMMON(0x200, PACA_EXMC) - FINISH_NAP - DISABLE_INTS - ld r3,PACA_EXGEN+EX_DAR(r13) - lwz r4,PACA_EXGEN+EX_DSISR(r13) - std r3,_DAR(r1) - std r4,_DSISR(r1) - bl .save_nvgprs - addir3,r1,STACK_FRAME_OVERHEAD - bl .machine_check_exception - b .ret_from_except - -#define MACHINE_CHECK_HANDLER_WINDUP \ - /* Clear MSR_RI before setting SRR0 and SRR1. */\ - li r0,MSR_RI; \ - mfmsr r9; /* get MSR value */ \ - andcr9,r9,r0; \ - mtmsrd r9,1; /* Clear MSR_RI */ \ - /* Move original SRR0 and SRR1 into the respective regs */ \ - ld r9,_MSR(r1);\ - mtspr SPRN_SRR1,r9; \ - ld r3,_NIP(r1);\ - mtspr SPRN_SRR0,r3; \ - ld r9,_CTR(r1);\ - mtctr r9; \ - ld r9,_XER(r1);\ - mtxer r9; \ - ld r9,_LINK(r1); \ - mtlrr9; \ - REST_GPR(0, r1);\ - REST_8GPRS(2, r1); \ - REST_GPR(10, r1); \ - ld r11,_CCR(r1); \ - mtcrr11;\ - /* Decrement paca->in_mce. */ \ - lhz r12,PACA_IN_MCE(r13); \ - subir12,r12,1; \ - sth r12,PACA_IN_MCE(r13); \ - REST_GPR(11, r1); \ - REST_2GPRS(12, r1); \ - /* restore original r1. */ \ - ld r1,GPR1(r1) - - /* -* Handle machine check early in real mode. We come here with -* ME=1, MMU (IR=0 and DR=0) off and using MC emergency stack. -*/ - .align 7 - .globl machine_check_handle_early -machine_check_handle_early: -BEGIN_FTR_SECTION - std r0,GPR0(r1) /* Save r0 */ - EXCEPTION_PROLOG_COMMON_3(0x200) - bl .save_nvgprs - addir3,r1,STACK_FRAME_OVERHEAD - bl .machine_check_early - ld r12,_MSR(r1) -#ifdef CONFIG_PPC_P7_NAP - /* -* Check if thread was in power saving mode. We come here when any -* of the following is true: -* a. thread wasn't in power saving mode -* b. thread was in pow
[PATCH] powerpc/52xx: re-enable bestcomm driver in defconfigs
The bestcomm driver has been moved to drivers/dma, so to select this driver by default additionally CONFIG_DMADEVICES has to be enabled. Currently it is not enabled in the config despite existing CONFIG_PPC_BESTCOMM=y in the config files. Fix it. Signed-off-by: Anatolij Gustschin --- arch/powerpc/configs/52xx/cm5200_defconfig|3 ++- arch/powerpc/configs/52xx/lite5200b_defconfig |3 ++- arch/powerpc/configs/52xx/motionpro_defconfig |3 ++- arch/powerpc/configs/52xx/pcm030_defconfig|3 ++- arch/powerpc/configs/52xx/tqm5200_defconfig |3 ++- arch/powerpc/configs/mpc5200_defconfig|3 ++- 6 files changed, 12 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/configs/52xx/cm5200_defconfig b/arch/powerpc/configs/52xx/cm5200_defconfig index 69b57da..0b88c7b 100644 --- a/arch/powerpc/configs/52xx/cm5200_defconfig +++ b/arch/powerpc/configs/52xx/cm5200_defconfig @@ -12,7 +12,6 @@ CONFIG_EXPERT=y CONFIG_PPC_MPC52xx=y CONFIG_PPC_MPC5200_SIMPLE=y # CONFIG_PPC_PMAC is not set -CONFIG_PPC_BESTCOMM=y CONFIG_SPARSE_IRQ=y CONFIG_PM=y # CONFIG_PCI is not set @@ -71,6 +70,8 @@ CONFIG_USB_DEVICEFS=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_HCD_PPC_OF_BE=y CONFIG_USB_STORAGE=y +CONFIG_DMADEVICES=y +CONFIG_PPC_BESTCOMM=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set diff --git a/arch/powerpc/configs/52xx/lite5200b_defconfig b/arch/powerpc/configs/52xx/lite5200b_defconfig index f3638ae..104a332 100644 --- a/arch/powerpc/configs/52xx/lite5200b_defconfig +++ b/arch/powerpc/configs/52xx/lite5200b_defconfig @@ -15,7 +15,6 @@ CONFIG_PPC_MPC52xx=y CONFIG_PPC_MPC5200_SIMPLE=y CONFIG_PPC_LITE5200=y # CONFIG_PPC_PMAC is not set -CONFIG_PPC_BESTCOMM=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_SPARSE_IRQ=y @@ -59,6 +58,8 @@ CONFIG_I2C_CHARDEV=y CONFIG_I2C_MPC=y # CONFIG_HWMON is not set CONFIG_VIDEO_OUTPUT_CONTROL=m +CONFIG_DMADEVICES=y +CONFIG_PPC_BESTCOMM=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set diff --git a/arch/powerpc/configs/52xx/motionpro_defconfig b/arch/powerpc/configs/52xx/motionpro_defconfig index 0c7de96..0d13ad7 100644 --- a/arch/powerpc/configs/52xx/motionpro_defconfig +++ b/arch/powerpc/configs/52xx/motionpro_defconfig @@ -12,7 +12,6 @@ CONFIG_EXPERT=y CONFIG_PPC_MPC52xx=y CONFIG_PPC_MPC5200_SIMPLE=y # CONFIG_PPC_PMAC is not set -CONFIG_PPC_BESTCOMM=y CONFIG_SPARSE_IRQ=y CONFIG_PM=y # CONFIG_PCI is not set @@ -84,6 +83,8 @@ CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_DS1307=y +CONFIG_DMADEVICES=y +CONFIG_PPC_BESTCOMM=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set diff --git a/arch/powerpc/configs/52xx/pcm030_defconfig b/arch/powerpc/configs/52xx/pcm030_defconfig index 22e7195..430aa18 100644 --- a/arch/powerpc/configs/52xx/pcm030_defconfig +++ b/arch/powerpc/configs/52xx/pcm030_defconfig @@ -21,7 +21,6 @@ CONFIG_MODULE_UNLOAD=y CONFIG_PPC_MPC52xx=y CONFIG_PPC_MPC5200_SIMPLE=y # CONFIG_PPC_PMAC is not set -CONFIG_PPC_BESTCOMM=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_HZ_100=y @@ -87,6 +86,8 @@ CONFIG_USB_OHCI_HCD_PPC_OF_BE=y CONFIG_USB_STORAGE=m CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_PCF8563=m +CONFIG_DMADEVICES=y +CONFIG_PPC_BESTCOMM=y CONFIG_EXT2_FS=m CONFIG_EXT3_FS=m # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set diff --git a/arch/powerpc/configs/52xx/tqm5200_defconfig b/arch/powerpc/configs/52xx/tqm5200_defconfig index 716a37b..7af4c5b 100644 --- a/arch/powerpc/configs/52xx/tqm5200_defconfig +++ b/arch/powerpc/configs/52xx/tqm5200_defconfig @@ -17,7 +17,6 @@ CONFIG_PPC_MPC52xx=y CONFIG_PPC_MPC5200_SIMPLE=y CONFIG_PPC_MPC5200_BUGFIX=y # CONFIG_PPC_PMAC is not set -CONFIG_PPC_BESTCOMM=y CONFIG_PM=y # CONFIG_PCI is not set CONFIG_NET=y @@ -86,6 +85,8 @@ CONFIG_USB_STORAGE=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_DS1307=y CONFIG_RTC_DRV_DS1374=y +CONFIG_DMADEVICES=y +CONFIG_PPC_BESTCOMM=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set diff --git a/arch/powerpc/configs/mpc5200_defconfig b/arch/powerpc/configs/mpc5200_defconfig index 6640a35..8b682d1c 100644 --- a/arch/powerpc/configs/mpc5200_defconfig +++ b/arch/powerpc/configs/mpc5200_defconfig @@ -15,7 +15,6 @@ CONFIG_PPC_MEDIA5200=y CONFIG_PPC_MPC5200_BUGFIX=y CONFIG_PPC_MPC5200_LPBFIFO=m # CONFIG_PPC_PMAC is not set -CONFIG_PPC_BESTCOMM=y CONFIG_SIMPLE_GPIO=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y @@ -125,6 +124,8 @@ CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_DS1307=y CONFIG_RTC_DRV_DS1374=y CONFIG_RTC_DRV_PCF8563=m +CONFIG_DMADEVICES=y +CONFIG_PPC_BESTCOMM=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull 'merge' branch of 5xxx tree
Hi Ben ! Please pull a device tree fix for v3.13. The booting on mpc512x is broken since v3.13-rc1, this patch repairs it. Thanks, Anatolij The following changes since commit 721cb59e9d95eb7f47ec73711ed35ef85e1ea1ca: powerpc/windfarm: Fix XServe G5 fan control Makefile issue (2013-11-27 11:35:47 +1100) are available in the git repository at: git://git.denx.de/linux-2.6-agust.git merge for you to fetch changes up to c65ec135960e4555f65d8c9243f65b2fb88ac071: powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node (2013-12-07 09:43:28 +0100) Gerhard Sittig (1): powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node arch/powerpc/boot/dts/mpc5121.dtsi |1 - 1 file changed, 1 deletion(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: questions: second of the 2 pcie controllers does not scan the bus.
On Fri, 2013-12-06 at 18:48 -0600, Ruchika wrote:
> Hi,
> I am working with an p4080 based board. I am trying to get 2 PCIE
> controllers probed properly.
>
> In uboot I have no problems scanning and discovering what is connected
> to both controllers/PCI bridges.
>
> For both PCIE1/2 uboot sets up the Primary, secondary and Subordinate
> bus numbers to 0,1,1 respectively.
>
> When linux boots up and probes the controllers, PCIE1 is probed and the
> bridge scanned properly but PCIE2 is probed at the bridge but not
> attempted a scan.
> I see this message
> "pci 0001:02:00.0: bridge configuration invalid ([bus 01-01]), reconfiguring
> "
>
> I updated uboot to set the secondary and subordinate numbers to 2 (left
> the primary number to 0) and a subsequent kernel boot scanned the bus
> for PCIE2 successfully.
> I found these numbers to be very critical since the device tree blob
> (bus-range) for pci is also based off these.
>
> I'd like to get a good fix rather than the uboot hack and get better
> understanding of the problem. If there are any pointers someone could
> provide it would be awesome.
This is the code that prints that:
/* Check if setup is sensible at all */
if (!pass &&
(primary != bus->number || secondary <= bus->number ||
secondary > subordinate)) {
dev_info(&dev->dev, "bridge configuration invalid ([bus %02x-%0
secondary, subordinate);
broken = 1;
}
Start by printing out more information to determine which of those
checks is failing (e.g. what is primary and bus->number). If it turns
out that U-Boot is configuring the PCI bus incorrectly, send e-mail to
the U-Boot list. Be sure to mention what version of Linux and U-Boot
you're using.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix "attempt to move .org backwards" error
Hi, On Tue, 10 Dec 2013 00:40:15 +0530 Mahesh J Salgaonkar wrote: > > From: Mahesh Salgaonkar > > With recent machine check patch series changes, The exception vectors > starting from 0x4300 are now overflowing with allyesconfig. Fix that by > moving machine_check_common and machine_check_handle_early code out of > that region to make enough room for exception vector area. > > Fixes this build error reportes by Stephen: > > arch/powerpc/kernel/exceptions-64s.S: Assembler messages: > arch/powerpc/kernel/exceptions-64s.S:958: Error: attempt to move .org > backwards > arch/powerpc/kernel/exceptions-64s.S:959: Error: attempt to move .org > backwards > arch/powerpc/kernel/exceptions-64s.S:983: Error: attempt to move .org > backwards > arch/powerpc/kernel/exceptions-64s.S:984: Error: attempt to move .org > backwards > arch/powerpc/kernel/exceptions-64s.S:1003: Error: attempt to move .org > backwards > arch/powerpc/kernel/exceptions-64s.S:1013: Error: attempt to move .org > backwards > arch/powerpc/kernel/exceptions-64s.S:1014: Error: attempt to move .org > backwards > arch/powerpc/kernel/exceptions-64s.S:1015: Error: attempt to move .org > backwards > arch/powerpc/kernel/exceptions-64s.S:1016: Error: attempt to move .org > backwards > arch/powerpc/kernel/exceptions-64s.S:1017: Error: attempt to move .org > backwards > arch/powerpc/kernel/exceptions-64s.S:1018: Error: attempt to move .org > backwards > > Signed-off-by: Mahesh Salgaonkar Reported-by: Stephen Rothwell Tested-by: Stephen Rothwell Works for me. Thanks. I will add this to linux-next today if Ben doesn't add it to his tree. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpgJ6p2sDaOU.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix "attempt to move .org backwards" error
On Tue, 2013-12-10 at 10:10 +1100, Stephen Rothwell wrote: > Reported-by: Stephen Rothwell > Tested-by: Stephen Rothwell > > Works for me. Thanks. I will add this to linux-next today if Ben > doesn't add it to his tree. I will but probably not soon enough for your cut today Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pasemi: turn on devtmpfs in defconfig
At least some distros expect it these days; turn it on. Also, random churn from doing a savedefconfig for the first time in a year or so. Signed-off-by: Olof Johansson --- arch/powerpc/configs/pasemi_defconfig |7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/configs/pasemi_defconfig b/arch/powerpc/configs/pasemi_defconfig index bd8a6f7..cec044a 100644 --- a/arch/powerpc/configs/pasemi_defconfig +++ b/arch/powerpc/configs/pasemi_defconfig @@ -2,7 +2,6 @@ CONFIG_PPC64=y CONFIG_ALTIVEC=y CONFIG_SMP=y CONFIG_NR_CPUS=2 -CONFIG_EXPERIMENTAL=y CONFIG_SYSVIPC=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y @@ -45,8 +44,9 @@ CONFIG_INET_AH=y CONFIG_INET_ESP=y # CONFIG_IPV6 is not set CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y CONFIG_MTD=y -CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_SLRAM=y CONFIG_MTD_PHRAM=y @@ -88,7 +88,6 @@ CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=y CONFIG_NETDEVICES=y CONFIG_DUMMY=y -CONFIG_MII=y CONFIG_TIGON3=y CONFIG_E1000=y CONFIG_PASEMI_MAC=y @@ -174,8 +173,8 @@ CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_CRC_CCITT=y CONFIG_PRINTK_TIME=y -CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_FS=y +CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_KERNEL=y CONFIG_DETECT_HUNG_TASK=y # CONFIG_SCHED_DEBUG is not set -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9] PCI: Use dev_is_pci() to check whether it is pci device
[+cc arch lists]
On Thu, Dec 05, 2013 at 07:52:53PM +0800, Yijing Wang wrote:
> Use dev_is_pci() instead of directly compare
> pci_bus_type to check whether it is pci device.
>
> Signed-off-by: Yijing Wang
I applied all these to my pci/yijing-dev_is_pci branch for v3.14, thanks!
Browse them here:
http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/yijing-dev_is_pci
This should be no functional change.
arch/alpha/kernel/pci_iommu.c|2 +-
arch/arm/common/it8152.c |4 ++--
arch/arm/mach-ixp4xx/common-pci.c|6 +++---
arch/ia64/hp/common/sba_iommu.c |2 +-
arch/ia64/sn/pci/pci_dma.c | 24
arch/parisc/kernel/drivers.c | 22 +-
arch/powerpc/sysdev/fsl_pci.c|2 +-
arch/sparc/include/asm/dma-mapping.h | 10 --
arch/sparc/kernel/iommu.c|2 +-
arch/sparc/kernel/ioport.c |4 +---
arch/x86/kernel/acpi/boot.c |4 +---
drivers/pci/pci-acpi.c |2 +-
12 files changed, 33 insertions(+), 51 deletions(-)
Bjorn
> ---
> drivers/pci/pci-acpi.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> index 577074e..e0431f1 100644
> --- a/drivers/pci/pci-acpi.c
> +++ b/drivers/pci/pci-acpi.c
> @@ -358,7 +358,7 @@ static void pci_acpi_cleanup(struct device *dev)
>
> static bool pci_acpi_bus_match(struct device *dev)
> {
> - return dev->bus == &pci_bus_type;
> + return dev_is_pci(dev);
> }
>
> static struct acpi_bus_type acpi_pci_bus = {
> --
> 1.7.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pseries: Don't try to register pseries cpu hotplug on non-pseries
This results in oddball messages at boot on other platforms telling us that CPU hotplug isn't supported even when it is. Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c index a8ef932..171b0c7 100644 --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c @@ -420,4 +420,4 @@ static int __init pseries_cpu_hotplug_init(void) return 0; } -arch_initcall(pseries_cpu_hotplug_init); +machine_arch_initcall(pseries, pseries_cpu_hotplug_init); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are a handful of powerpc fixes for 3.13. The patches are reasonably trivial and self contained. Note the offb patches outside of arch/powerpc, they are LE fixes for our open-firmware "dumb" framebuffer. Cheers, Ben. The following changes since commit 721cb59e9d95eb7f47ec73711ed35ef85e1ea1ca: powerpc/windfarm: Fix XServe G5 fan control Makefile issue (2013-11-27 11:35:47 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to e641eb03ab2b0f065fa5e64b4202fb5b0441b427: powerpc: Fix up the kdump base cap to 128M (2013-12-10 11:28:39 +1100) Anatolij Gustschin (1): powerpc/52xx: Re-enable bestcomm driver in defconfigs Cedric Le Goater (2): offb: Little endian fixes offb: Add palette hack for little endian Gerhard Sittig (1): powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node Hong H. Pham (1): powerpc: Fix PTE page address mismatch in pgtable ctor/dtor Ilia Mirkin (1): powerpc/44x: Fix ocm_block allocation Mahesh Salgaonkar (1): powerpc: Fix up the kdump base cap to 128M Michael Ellerman (1): powerpc: Fix build break with PPC_EARLY_DEBUG_BOOTX=y Olof Johansson (1): powerpc/pasemi: Turn on devtmpfs in defconfig Thadeu Lima de Souza Cascardo (1): powernv: Fix VFIO support with PHB3 arch/powerpc/boot/dts/mpc5121.dtsi| 1 - arch/powerpc/configs/52xx/cm5200_defconfig| 3 ++- arch/powerpc/configs/52xx/lite5200b_defconfig | 3 ++- arch/powerpc/configs/52xx/motionpro_defconfig | 3 ++- arch/powerpc/configs/52xx/pcm030_defconfig| 3 ++- arch/powerpc/configs/52xx/tqm5200_defconfig | 3 ++- arch/powerpc/configs/mpc5200_defconfig| 3 ++- arch/powerpc/configs/pasemi_defconfig | 7 +++ arch/powerpc/include/asm/pgalloc-32.h | 6 ++ arch/powerpc/include/asm/pgalloc-64.h | 6 ++ arch/powerpc/kernel/machine_kexec.c | 2 +- arch/powerpc/kernel/misc_64.S | 5 - arch/powerpc/platforms/powernv/pci-ioda.c | 1 + arch/powerpc/sysdev/ppc4xx_ocm.c | 2 +- drivers/video/offb.c | 29 +++ 15 files changed, 47 insertions(+), 30 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pseries: Don't try to register pseries cpu hotplug on non-pseries
On Tue, 2013-12-10 at 11:31 +1100, Benjamin Herrenschmidt wrote: > This results in oddball messages at boot on other platforms telling us > that CPU hotplug isn't supported even when it is. We have a bunch more. Most are probably safe because they rely on the device tree but we should probably convert them anyway? $ git grep initcall arch/powerpc/platforms/pseries/ | grep -v machine_ arch/powerpc/platforms/pseries/dtl.c:arch_initcall(dtl_init); arch/powerpc/platforms/pseries/eeh_pseries.c:early_initcall(eeh_pseries_init); arch/powerpc/platforms/pseries/hotplug-cpu.c:arch_initcall(pseries_cpu_hotplug_init); arch/powerpc/platforms/pseries/hvCall_inst.c:__initcall(hcall_inst_init); arch/powerpc/platforms/pseries/mobility.c:device_initcall(mobility_sysfs_init); arch/powerpc/platforms/pseries/msi.c:arch_initcall(rtas_msi_init); arch/powerpc/platforms/pseries/power.c:core_initcall(pm_init); arch/powerpc/platforms/pseries/power.c:__initcall(apo_pm_init); arch/powerpc/platforms/pseries/ras.c:subsys_initcall(init_ras_IRQ); arch/powerpc/platforms/pseries/reconfig.c:__initcall(proc_ppc64_create_ofdt); arch/powerpc/platforms/pseries/rng.c:subsys_initcall(rng_init); arch/powerpc/platforms/pseries/setup.c:early_initcall(alloc_dispatch_log_kmem_cache); arch/powerpc/platforms/pseries/suspend.c:__initcall(pseries_suspend_init); cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pseries: Don't try to register pseries cpu hotplug on non-pseries
On Tue, 2013-12-10 at 13:02 +1100, Michael Ellerman wrote: > On Tue, 2013-12-10 at 11:31 +1100, Benjamin Herrenschmidt wrote: > > This results in oddball messages at boot on other platforms telling us > > that CPU hotplug isn't supported even when it is. > > We have a bunch more. Most are probably safe because they rely on the device > tree but we should probably convert them anyway? Possibly :-) This one I spotted specifically because I was looking at a boot log on powernv and it was insulting me ! > $ git grep initcall arch/powerpc/platforms/pseries/ | grep -v machine_ > arch/powerpc/platforms/pseries/dtl.c:arch_initcall(dtl_init); > arch/powerpc/platforms/pseries/eeh_pseries.c:early_initcall(eeh_pseries_init); > arch/powerpc/platforms/pseries/hotplug-cpu.c:arch_initcall(pseries_cpu_hotplug_init); > arch/powerpc/platforms/pseries/hvCall_inst.c:__initcall(hcall_inst_init); > arch/powerpc/platforms/pseries/mobility.c:device_initcall(mobility_sysfs_init); > arch/powerpc/platforms/pseries/msi.c:arch_initcall(rtas_msi_init); > arch/powerpc/platforms/pseries/power.c:core_initcall(pm_init); > arch/powerpc/platforms/pseries/power.c:__initcall(apo_pm_init); > arch/powerpc/platforms/pseries/ras.c:subsys_initcall(init_ras_IRQ); > arch/powerpc/platforms/pseries/reconfig.c:__initcall(proc_ppc64_create_ofdt); > arch/powerpc/platforms/pseries/rng.c:subsys_initcall(rng_init); > arch/powerpc/platforms/pseries/setup.c:early_initcall(alloc_dispatch_log_kmem_cache); > arch/powerpc/platforms/pseries/suspend.c:__initcall(pseries_suspend_init); > > cheers > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pseries: Select ARCH_RANDOM on pseries
We have a driver for the ARCH_RANDOM hook in rng.c, so we should select ARCH_RANDOM on pseries. Without this the build breaks if you turn ARCH_RANDOM off. This hasn't broken the build because pseries_defconfig doesn't specify a value for PPC_POWERNV, which is default y, and selects ARCH_RANDOM. Signed-off-by: Michael Ellerman --- arch/powerpc/platforms/pseries/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index 62b4f80..c8fe7be 100644 --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -20,6 +20,7 @@ config PPC_PSERIES select PPC_DOORBELL select HAVE_CONTEXT_TRACKING select HOTPLUG_CPU if SMP + select ARCH_RANDOM default y config PPC_SPLPAR -- 1.8.3.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Mon, Dec 9, 2013 at 5:57 PM, Benjamin Herrenschmidt wrote: > > Here are a handful of powerpc fixes for 3.13. Grr. I've pulled it, but looking at that history, it's just pure and utter f*cking garbage. It was rebased *minutes* before sending it, as far as I can tell. Why? And it has a pointless merge that you must have created with "--no-ff" for no apparent good reason. WTF? What the hell happened here, and why? As mentioned, it's in my tree, but I was *this* close to just unpulling and saying "fuck that" when I started looking at it. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9] PCI: Use dev_is_pci() to check whether it is pci device
On Mon, 2013-12-09 at 17:01 -0700, Bjorn Helgaas wrote:
> [+cc arch lists]
>
> On Thu, Dec 05, 2013 at 07:52:53PM +0800, Yijing Wang wrote:
> > Use dev_is_pci() instead of directly compare
> > pci_bus_type to check whether it is pci device.
> >
> > Signed-off-by: Yijing Wang
>
> I applied all these to my pci/yijing-dev_is_pci branch for v3.14, thanks!
>
> Browse them here:
> http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/yijing-dev_is_pci
Ah ok. I also have the powerpc one in powerpc -next, no biggie though
Cheers,
Ben.
> This should be no functional change.
>
> arch/alpha/kernel/pci_iommu.c|2 +-
> arch/arm/common/it8152.c |4 ++--
> arch/arm/mach-ixp4xx/common-pci.c|6 +++---
> arch/ia64/hp/common/sba_iommu.c |2 +-
> arch/ia64/sn/pci/pci_dma.c | 24
> arch/parisc/kernel/drivers.c | 22 +-
> arch/powerpc/sysdev/fsl_pci.c|2 +-
> arch/sparc/include/asm/dma-mapping.h | 10 --
> arch/sparc/kernel/iommu.c|2 +-
> arch/sparc/kernel/ioport.c |4 +---
> arch/x86/kernel/acpi/boot.c |4 +---
> drivers/pci/pci-acpi.c |2 +-
> 12 files changed, 33 insertions(+), 51 deletions(-)
>
> Bjorn
>
> > ---
> > drivers/pci/pci-acpi.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> > index 577074e..e0431f1 100644
> > --- a/drivers/pci/pci-acpi.c
> > +++ b/drivers/pci/pci-acpi.c
> > @@ -358,7 +358,7 @@ static void pci_acpi_cleanup(struct device *dev)
> >
> > static bool pci_acpi_bus_match(struct device *dev)
> > {
> > - return dev->bus == &pci_bus_type;
> > + return dev_is_pci(dev);
> > }
> >
> > static struct acpi_bus_type acpi_pci_bus = {
> > --
> > 1.7.1
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> ___
> 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: [git pull] Please pull powerpc.git merge branch
On Mon, 2013-12-09 at 19:58 -0800, Linus Torvalds wrote: > On Mon, Dec 9, 2013 at 5:57 PM, Benjamin Herrenschmidt > wrote: > > > > Here are a handful of powerpc fixes for 3.13. > > Grr. > > I've pulled it, but looking at that history, it's just pure and utter > f*cking garbage. > > It was rebased *minutes* before sending it, as far as I can tell. Why? It was *created* shortly before sending it: Basically I put that thing together as a patchwork bundle which I grew over this week. Today I just applied them to my git, ran my build testers, booted a machine to dbl check and sent. I tend to not let things linger long in git when it's just fixes like that. > And it has a pointless merge that you must have created with "--no-ff" > for no apparent good reason. Oh that's my fault. I thought you preferred that way to keep track of cases where I pull from somebody since then the patch don't have my s-o-b... my bad for misunderstanding that part of the process. > WTF? What the hell happened here, and why? As mentioned, it's in my > tree, but I was *this* close to just unpulling and saying "fuck that" > when I started looking at it. Heh sorry. Cheers, Ben. > > Linus > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
> -Original Message- > From: Wood Scott-B07421 > Sent: Saturday, December 07, 2013 12:55 AM > To: Bhushan Bharat-R65777 > Cc: Alex Williamson; linux-...@vger.kernel.org; ag...@suse.de; Yoder Stuart- > B08248; io...@lists.linux-foundation.org; bhelg...@google.com; linuxppc- > d...@lists.ozlabs.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU) > > On Thu, 2013-12-05 at 22:17 -0600, Bharat Bhushan wrote: > > > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Friday, December 06, 2013 5:31 AM > > > To: Bhushan Bharat-R65777 > > > Cc: Alex Williamson; linux-...@vger.kernel.org; ag...@suse.de; Yoder > > > Stuart- B08248; io...@lists.linux-foundation.org; > > > bhelg...@google.com; linuxppc- d...@lists.ozlabs.org; > > > linux-ker...@vger.kernel.org > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale > > > IOMMU (PAMU) > > > > > > On Sun, 2013-11-24 at 23:33 -0600, Bharat Bhushan wrote: > > > > > > > > > -Original Message- > > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > > > Sent: Friday, November 22, 2013 2:31 AM > > > > > To: Wood Scott-B07421 > > > > > Cc: Bhushan Bharat-R65777; linux-...@vger.kernel.org; > > > > > ag...@suse.de; Yoder Stuart-B08248; > > > > > io...@lists.linux-foundation.org; bhelg...@google.com; linuxppc- > > > > > d...@lists.ozlabs.org; linux-ker...@vger.kernel.org > > > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale > > > > > IOMMU (PAMU) > > > > > > > > > > On Thu, 2013-11-21 at 14:47 -0600, Scott Wood wrote: > > > > > > They can interfere. > > > > > > > > Want to be sure of how they can interfere? > > > > > > If more than one VFIO user shares the same MSI group, one of the > > > users can send MSIs to another user, by using the wrong interrupt > > > within the bank. Unexpected MSIs could cause misbehavior or denial of > service. > > > > > > > >> With this hardware, the only way to prevent that > > > > > > is to make sure that a bank is not shared by multiple protection > contexts. > > > > > > For some of our users, though, I believe preventing this is > > > > > > less important than the performance benefit. > > > > > > > > So should we let this patch series in without protection? > > > > > > No, there should be some sort of opt-in mechanism similar to > > > IOMMU-less VFIO -- but not the same exact one, since one is a much > > > more serious loss of isolation than the other. > > > > Can you please elaborate "opt-in mechanism"? > > The system should be secure by default. If the administrator wants to relax > protection in order to accomplish some functionality, that should require an > explicit request such as a write to a sysfs file. > > > > > > I think we need some sort of ownership model around the msi banks > > > > > then. > > > > > Otherwise there's nothing preventing another userspace from > > > > > attempting an MSI based attack on other users, or perhaps even > > > > > on the host. VFIO can't allow that. Thanks, > > > > > > > > We have very few (3 MSI bank on most of chips), so we can not > > > > assign one to each userspace. > > > > > > That depends on how many users there are. > > > > What I think we can do is: > > - Reserve one MSI region for host. Host will not share MSI region with > > Guest. > > - For upto 2 Guest (MAX msi with host - 1) give then separate MSI sub > > regions > > - Additional Guest will share MSI region with other guest. > > > > Any better suggestion are most welcome. > > If the administrator does not opt into this partial loss of isolation, then > once > you run out of MSI groups, new users should not be able to set up MSIs. So mean vfio should use Legacy when out of MSI banks? Thanks -Bharat > > -Scott > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Saturday, December 07, 2013 1:00 AM > To: Wood Scott-B07421 > Cc: Bhushan Bharat-R65777; linux-...@vger.kernel.org; ag...@suse.de; Yoder > Stuart-B08248; io...@lists.linux-foundation.org; bhelg...@google.com; > linuxppc- > d...@lists.ozlabs.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU) > > On Fri, 2013-12-06 at 12:59 -0600, Scott Wood wrote: > > On Thu, 2013-12-05 at 22:11 -0600, Bharat Bhushan wrote: > > > > > > > -Original Message- > > > > From: Wood Scott-B07421 > > > > Sent: Friday, December 06, 2013 5:52 AM > > > > To: Bhushan Bharat-R65777 > > > > Cc: Alex Williamson; linux-...@vger.kernel.org; ag...@suse.de; > > > > Yoder Stuart- B08248; io...@lists.linux-foundation.org; > > > > bhelg...@google.com; linuxppc- d...@lists.ozlabs.org; > > > > linux-ker...@vger.kernel.org > > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale > > > > IOMMU (PAMU) > > > > > > > > On Thu, 2013-11-28 at 03:19 -0600, Bharat Bhushan wrote: > > > > > > > > > > > -Original Message- > > > > > > From: Bhushan Bharat-R65777 > > > > > > Sent: Wednesday, November 27, 2013 9:39 PM > > > > > > To: 'Alex Williamson' > > > > > > Cc: Wood Scott-B07421; linux-...@vger.kernel.org; > > > > > > ag...@suse.de; Yoder Stuart- B08248; > > > > > > io...@lists.linux-foundation.org; bhelg...@google.com; > > > > > > linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org > > > > > > Subject: RE: [PATCH 0/9 v2] vfio-pci: add support for > > > > > > Freescale IOMMU (PAMU) > > > > > > > > > > > > If we just provide the size of MSI bank to userspace then > > > > > > userspace cannot do anything wrong. > > > > > > > > > > So userspace does not know address, so it cannot mmap and cause > > > > > any > > > > interference by directly reading/writing. > > > > > > > > That's security through obscurity... Couldn't the malicious user > > > > find out the address via other means, such as experimentation on > > > > another system over which they have full control? What would > > > > happen if the user reads from their device's PCI config space? Or > > > > gets the information via some back door in the PCI device they > > > > own? Or pokes throughout the address space looking for something that > generates an interrupt to its own device? > > > > > > So how to solve this problem, Any suggestion ? > > > > > > We have to map one window in PAMU for MSIs and a malicious user can > > > ask its device to do DMA to MSI window region with any pair of > > > address and data, which can lead to unexpected MSIs in system? > > > > I don't think there are any solutions other than to limit each bank to > > one user, unless the admin turns some knob that says they're OK with > > the partial loss of isolation. > > Even if the admin does opt-in to an allow_unsafe_interrupts options, it should > still be reasonably difficult for one guest to interfere with the other. I > don't think we want to rely on the blind luck of making the full MSI bank > accessible to multiple guests and hoping they don't step on each other. Not sure how to solve in this case (sharing MSI page) > That probably means that vfio needs to manage the space rather than the > guest. What you mean by " vfio needs to manage the space rather than the guest"? Thanks -Bharat > Thanks, > > Alex > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
On Tue, 2013-12-10 at 05:37 +, bharat.bhus...@freescale.com wrote: > > > -Original Message- > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Saturday, December 07, 2013 1:00 AM > > To: Wood Scott-B07421 > > Cc: Bhushan Bharat-R65777; linux-...@vger.kernel.org; ag...@suse.de; Yoder > > Stuart-B08248; io...@lists.linux-foundation.org; bhelg...@google.com; > > linuxppc- > > d...@lists.ozlabs.org; linux-ker...@vger.kernel.org > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU) > > > > On Fri, 2013-12-06 at 12:59 -0600, Scott Wood wrote: > > > On Thu, 2013-12-05 at 22:11 -0600, Bharat Bhushan wrote: > > > > > > > > > -Original Message- > > > > > From: Wood Scott-B07421 > > > > > Sent: Friday, December 06, 2013 5:52 AM > > > > > To: Bhushan Bharat-R65777 > > > > > Cc: Alex Williamson; linux-...@vger.kernel.org; ag...@suse.de; > > > > > Yoder Stuart- B08248; io...@lists.linux-foundation.org; > > > > > bhelg...@google.com; linuxppc- d...@lists.ozlabs.org; > > > > > linux-ker...@vger.kernel.org > > > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale > > > > > IOMMU (PAMU) > > > > > > > > > > On Thu, 2013-11-28 at 03:19 -0600, Bharat Bhushan wrote: > > > > > > > > > > > > > -Original Message- > > > > > > > From: Bhushan Bharat-R65777 > > > > > > > Sent: Wednesday, November 27, 2013 9:39 PM > > > > > > > To: 'Alex Williamson' > > > > > > > Cc: Wood Scott-B07421; linux-...@vger.kernel.org; > > > > > > > ag...@suse.de; Yoder Stuart- B08248; > > > > > > > io...@lists.linux-foundation.org; bhelg...@google.com; > > > > > > > linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org > > > > > > > Subject: RE: [PATCH 0/9 v2] vfio-pci: add support for > > > > > > > Freescale IOMMU (PAMU) > > > > > > > > > > > > > > If we just provide the size of MSI bank to userspace then > > > > > > > userspace cannot do anything wrong. > > > > > > > > > > > > So userspace does not know address, so it cannot mmap and cause > > > > > > any > > > > > interference by directly reading/writing. > > > > > > > > > > That's security through obscurity... Couldn't the malicious user > > > > > find out the address via other means, such as experimentation on > > > > > another system over which they have full control? What would > > > > > happen if the user reads from their device's PCI config space? Or > > > > > gets the information via some back door in the PCI device they > > > > > own? Or pokes throughout the address space looking for something that > > generates an interrupt to its own device? > > > > > > > > So how to solve this problem, Any suggestion ? > > > > > > > > We have to map one window in PAMU for MSIs and a malicious user can > > > > ask its device to do DMA to MSI window region with any pair of > > > > address and data, which can lead to unexpected MSIs in system? > > > > > > I don't think there are any solutions other than to limit each bank to > > > one user, unless the admin turns some knob that says they're OK with > > > the partial loss of isolation. > > > > Even if the admin does opt-in to an allow_unsafe_interrupts options, it > > should > > still be reasonably difficult for one guest to interfere with the other. I > > don't think we want to rely on the blind luck of making the full MSI bank > > accessible to multiple guests and hoping they don't step on each other. > > Not sure how to solve in this case (sharing MSI page) > > > That probably means that vfio needs to manage the space rather than the > > guest. > > What you mean by " vfio needs to manage the space rather than the guest"? I mean there needs to be some kernel component managing the contents of the MSI page rather than just handing it out to the user and hoping for the best. The user API also needs to remain the same whether the user has the MSI page exclusively or it's shared with others (kernel or users). Thanks, Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4 08/10] powerpc, perf: Enable SW filtering in branch stack sampling framework
On 12/09/2013 11:51 AM, Michael Ellerman wrote:
> This code was already in need of some unindentation, and now it's just
> ridiculous.
>
> To start with at the beginning of this routine we have:
>
> while (..) {
> if (!val)
> break;
> else {
> // Bulk of the logic
> ...
> }
> }
>
> That should almost always become:
>
> while (..) {
> if (!val)
> break;
>
> // Bulk of the logic
> ...
> }
>
>
> But in this case that's not enough. Please send a precursor patch which moves
> this logic out into a helper function.
Hey Michael,
I believe this patch should be able to take care of this.
commit d66d729715cabe0cfd8e34861a6afa8ad639ddf3
Author: Anshuman Khandual
Date: Tue Dec 10 11:10:06 2013 +0530
power, perf: Clean up BHRB processing
This patch cleans up some indentation problem and re-organizes the
BHRB processing code with an additional helper function.
Signed-off-by: Anshuman Khandual
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 29b89e8..9ae96c5 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -400,11 +400,20 @@ static __u64 power_pmu_bhrb_to(u64 addr)
return target - (unsigned long)&instr + addr;
}
+void update_branch_entry(struct cpu_hw_events *cpuhw, int u_index, u64 from,
u64 to, int pred)
+{
+ cpuhw->bhrb_entries[u_index].from = from;
+ cpuhw->bhrb_entries[u_index].to = to;
+ cpuhw->bhrb_entries[u_index].mispred = pred;
+ cpuhw->bhrb_entries[u_index].predicted = ~pred;
+ return;
+}
+
/* Processing BHRB entries */
void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
{
u64 val;
- u64 addr;
+ u64 addr, tmp;
int r_index, u_index, pred;
r_index = 0;
@@ -415,62 +424,54 @@ void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
if (!val)
/* Terminal marker: End of valid BHRB entries */
break;
- else {
- addr = val & BHRB_EA;
- pred = val & BHRB_PREDICTION;
- if (!addr)
- /* invalid entry */
- continue;
+ addr = val & BHRB_EA;
+ pred = val & BHRB_PREDICTION;
- /* Branches are read most recent first (ie. mfbhrb 0 is
-* the most recent branch).
-* There are two types of valid entries:
-* 1) a target entry which is the to address of a
-*computed goto like a blr,bctr,btar. The next
-*entry read from the bhrb will be branch
-*corresponding to this target (ie. the actual
-*blr/bctr/btar instruction).
-* 2) a from address which is an actual branch. If a
-*target entry proceeds this, then this is the
-*matching branch for that target. If this is not
-*following a target entry, then this is a branch
-*where the target is given as an immediate field
-*in the instruction (ie. an i or b form branch).
-*In this case we need to read the instruction from
-*memory to determine the target/to address.
+ if (!addr)
+ /* invalid entry */
+ continue;
+
+ /* Branches are read most recent first (ie. mfbhrb 0 is
+* the most recent branch).
+* There are two types of valid entries:
+* 1) a target entry which is the to address of a
+*computed goto like a blr,bctr,btar. The next
+*entry read from the bhrb will be branch
+*corresponding to this target (ie. the actual
+*blr/bctr/btar instruction).
+* 2) a from address which is an actual branch. If a
+*target entry proceeds this, then this is the
+*matching branch for that target. If this is not
+*following a target entry, then this is a branch
+*where the target is given as an immediate field
+*in the instruction (ie. an i or b form branch).
+*In this case we need to read the instruction from
+*memory to determine the target/to address.
+*/
+ if (val & BHRB_TARGET) {
+ /* Target branches use two entries
+* (ie. computed gotos/XL form)
*/
+ tmp = addr;
+ /* Ge
Re: [PATCH V4 07/10] powerpc, lib: Add new branch instruction analysis support functions
On 12/09/2013 11:51 AM, Michael Ellerman wrote: > On Wed, 2013-04-12 at 10:32:39 UTC, Anshuman Khandual wrote: >> Generic powerpc branch instruction analysis support added in the code >> patching library which will help the subsequent patch on SW based >> filtering of branch records in perf. This patch also converts and >> exports some of the existing local static functions through the header >> file to be used else where. >> >> diff --git a/arch/powerpc/include/asm/code-patching.h >> b/arch/powerpc/include/asm/code-patching.h >> index a6f8c7a..8bab417 100644 >> --- a/arch/powerpc/include/asm/code-patching.h >> +++ b/arch/powerpc/include/asm/code-patching.h >> @@ -22,6 +22,36 @@ >> #define BRANCH_SET_LINK 0x1 >> #define BRANCH_ABSOLUTE 0x2 >> >> +#define XL_FORM_LR 0x4C20 >> +#define XL_FORM_CTR 0x4C000420 >> +#define XL_FORM_TAR 0x4C000460 >> + >> +#define BO_ALWAYS0x0280 >> +#define BO_CTR 0x0200 >> +#define BO_CRBI_OFF 0x0080 >> +#define BO_CRBI_ON 0x0180 >> +#define BO_CRBI_HINT 0x0040 >> + >> +/* Forms of branch instruction */ >> +int instr_is_branch_iform(unsigned int instr); >> +int instr_is_branch_bform(unsigned int instr); >> +int instr_is_branch_xlform(unsigned int instr); >> + >> +/* Classification of XL-form instruction */ >> +int is_xlform_lr(unsigned int instr); >> +int is_xlform_ctr(unsigned int instr); >> +int is_xlform_tar(unsigned int instr); >> + >> +/* Branch instruction is a call */ >> +int is_branch_link_set(unsigned int instr); >> + >> +/* BO field analysis (B-form or XL-form) */ >> +int is_bo_always(unsigned int instr); >> +int is_bo_ctr(unsigned int instr); >> +int is_bo_crbi_off(unsigned int instr); >> +int is_bo_crbi_on(unsigned int instr); >> +int is_bo_crbi_hint(unsigned int instr); > > > I think this is the wrong API. > > We end up with all these micro checks, which don't actually encapsulate much, > and don't implement the logic perf needs. If we had another user for this > level > of detail then it might make sense, but for a single user I think we're better > off just implementing the semantics it wants. > Having a comprehensive list of branch instruction analysis APIs which some other user can also use in the future does not make it wrong. Being more elaborate and detailed makes this one a better choice than the API you have suggested below. > So that would be something more like: > > bool instr_is_return_branch(unsigned int instr); > bool instr_is_conditional_branch(unsigned int instr); > bool instr_is_func_call(unsigned int instr); > bool instr_is_indirect_func_call(unsigned int instr); > > > These would then encapsulate something like the logic in your 8/10 patch. You > can hopefully also optimise the checking logic in each routine because you > know > the exact semantics you're implementing. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: set default kernel thread priority to medium-low
All the important PThread locking occurs in GLIBC libpthread.so
For scaling to large core counts we need to stay out of the kernel and
scheduler as much as possible which implies increasing the spin time in user
mode. For POWER implementations with SMT this implies that user mode needs to
manage SMT priority for spinning and active (in the critical region) threads.
Libpthread must be able to raise and lower the the SMT priority versus the
default to be effective.
This lowers the default kernel thread priority from medium to medium-low.
Signed-off-by: Philippe Bergheaud
---
arch/powerpc/include/asm/exception-64s.h|2 +-
arch/powerpc/include/asm/ppc_asm.h |4 ++--
arch/powerpc/include/asm/processor.h|2 +-
arch/powerpc/include/asm/spinlock.h |8
arch/powerpc/kernel/entry_64.S |2 +-
arch/powerpc/kernel/exceptions-64s.S|4 ++--
arch/powerpc/kernel/head_64.S |4 ++--
arch/powerpc/kernel/idle.c |2 +-
arch/powerpc/kernel/prom_init.c |2 +-
arch/powerpc/kernel/time.c |2 +-
arch/powerpc/kvm/book3s_hv.c|2 +-
arch/powerpc/kvm/book3s_hv_rmhandlers.S |4 ++--
arch/powerpc/lib/locks.c|2 +-
arch/powerpc/platforms/cell/beat_hvCall.S | 16
arch/powerpc/platforms/powernv/opal-takeover.S |2 +-
arch/powerpc/platforms/pseries/hvCall.S | 10 +-
arch/powerpc/platforms/pseries/processor_idle.c |4 ++--
17 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/include/asm/exception-64s.h
index 402c1c4..30bedd9 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -135,7 +135,7 @@ END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,941)
*/
#define HMT_MEDIUM_PPR_DISCARD \
BEGIN_FTR_SECTION_NESTED(942) \
- HMT_MEDIUM; \
+ HMT_MEDIUM_LOW; \
END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,0,942) /*non P7*/
/*
diff --git a/arch/powerpc/include/asm/ppc_asm.h
b/arch/powerpc/include/asm/ppc_asm.h
index ce05bba..22d4ba4 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -478,9 +478,9 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
* PPR restore macros used in entry_64.S
* Used for P7 or later processors
*/
-#define HMT_MEDIUM_LOW_HAS_PPR \
+#define HMT_LOW_HAS_PPR
\
BEGIN_FTR_SECTION_NESTED(944) \
- HMT_MEDIUM_LOW; \
+ HMT_LOW;\
END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,944)
#define SET_DEFAULT_THREAD_PPR(ra, rb) \
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index b4a3045..2f8625b 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -387,7 +387,7 @@ static inline unsigned long __pack_fe01(unsigned int fpmode)
}
#ifdef CONFIG_PPC64
-#define cpu_relax()do { HMT_low(); HMT_medium(); barrier(); } while (0)
+#define cpu_relax()do { HMT_low(); HMT_medium_low(); barrier(); } while (0)
#else
#define cpu_relax()barrier()
#endif
diff --git a/arch/powerpc/include/asm/spinlock.h
b/arch/powerpc/include/asm/spinlock.h
index 5f54a74..b047a6a 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -120,7 +120,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
if (SHARED_PROCESSOR)
__spin_yield(lock);
} while (unlikely(lock->slock != 0));
- HMT_medium();
+ HMT_medium_low();
}
}
@@ -140,7 +140,7 @@ void arch_spin_lock_flags(arch_spinlock_t *lock, unsigned
long flags)
if (SHARED_PROCESSOR)
__spin_yield(lock);
} while (unlikely(lock->slock != 0));
- HMT_medium();
+ HMT_medium_low();
local_irq_restore(flags_dis);
}
}
@@ -240,7 +240,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
if (SHARED_PROCESSOR)
__rw_yield(rw);
} while (unlikely(rw->lock < 0));
- HMT_medium();
+ HMT_medium_low();
}
}
@@ -254,7 +254,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
Re: [PATCH 1/9] PCI: Use dev_is_pci() to check whether it is pci device
On 2013/12/10 8:01, Bjorn Helgaas wrote:
> [+cc arch lists]
>
> On Thu, Dec 05, 2013 at 07:52:53PM +0800, Yijing Wang wrote:
>> Use dev_is_pci() instead of directly compare
>> pci_bus_type to check whether it is pci device.
>>
>> Signed-off-by: Yijing Wang
>
> I applied all these to my pci/yijing-dev_is_pci branch for v3.14, thanks!
>
> Browse them here:
> http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/yijing-dev_is_pci
Thanks!
Bjorn, I sent the "[patch v2 4/9] sparc/PCI: Use dev_is_pci() to identify PCI
devices" to
correct build error found by kbuild test, Because I have no sparc platform, I
guess the build error was introduced
by I remove the CONFIG_PCI #ifdef in that patch. Now I keep the CONFIG_PCI code
and that patch should be no functional change.
>
> This should be no functional change.
>
> arch/alpha/kernel/pci_iommu.c|2 +-
> arch/arm/common/it8152.c |4 ++--
> arch/arm/mach-ixp4xx/common-pci.c|6 +++---
> arch/ia64/hp/common/sba_iommu.c |2 +-
> arch/ia64/sn/pci/pci_dma.c | 24
> arch/parisc/kernel/drivers.c | 22 +-
> arch/powerpc/sysdev/fsl_pci.c|2 +-
> arch/sparc/include/asm/dma-mapping.h | 10 --
> arch/sparc/kernel/iommu.c|2 +-
> arch/sparc/kernel/ioport.c |4 +---
> arch/x86/kernel/acpi/boot.c |4 +---
> drivers/pci/pci-acpi.c |2 +-
> 12 files changed, 33 insertions(+), 51 deletions(-)
>
> Bjorn
>
>> ---
>> drivers/pci/pci-acpi.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
>> index 577074e..e0431f1 100644
>> --- a/drivers/pci/pci-acpi.c
>> +++ b/drivers/pci/pci-acpi.c
>> @@ -358,7 +358,7 @@ static void pci_acpi_cleanup(struct device *dev)
>>
>> static bool pci_acpi_bus_match(struct device *dev)
>> {
>> -return dev->bus == &pci_bus_type;
>> +return dev_is_pci(dev);
>> }
>>
>> static struct acpi_bus_type acpi_pci_bus = {
>> --
>> 1.7.1
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>
--
Thanks!
Yijing
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
