On Tue, 2016-05-10 at 09:55 +1000, Michael Ellerman wrote:
> On Thu, 2016-05-05 at 07:54:09 UTC, Oliver O'Halloran wrote:
> >
> > The mm zone mechanism was traditionally used by arch specific code to
> > partition memory into allocation zones. However there are several zones
> > that are managed b
On 11/05/16 15:03, Balbir Singh wrote:
On 11/05/16 14:55, Rashmica Gupta wrote:
The same logic for tm_abort appears twice, so pull it out into a
function.
Signed-off-by: Rashmica Gupta
---
arch/powerpc/mm/hash_utils_64.c | 47 ++---
1 file changed, 21
From: Zhaoxiu Zeng
When I do "grep parity -r linux", I found many parity calculations
distributed in many drivers.
This patch series does:
1. provide generic and architecture-specific parity calculations
2. remove drivers' local parity calculations, use bitops' parity
functions instead
The mm zone mechanism was traditionally used by arch specific code to
partition memory into allocation zones. However there are several zones
that are managed by the mm subsystem rather than the architecture. Most
architectures set the max PFN of these special zones to zero, however on
powerpc we s
From: Zhaoxiu Zeng
Use runtime patching for ppc64, lifted from hweight_64
Signed-off-by: Zhaoxiu Zeng
---
arch/powerpc/include/asm/bitops.h | 11 +++
arch/powerpc/lib/Makefile | 2 +-
arch/powerpc/lib/parity_64.S | 143 ++
arch/powerpc/lib/pp
On 03/15/2016 09:18 PM, Laurent Vivier wrote:
While writing some instruction tests for kvm-unit-tests for powerpc,
I've found that illegal instructions are not managed correctly with kvm-pr,
while it is fine with kvm-hv.
When an illegal instruction (like ".long 0") is processed by kvm-pr,
the ke
On Wed, 2016-05-11 at 17:44 +1000, Rashmica wrote:
> On 11/05/16 15:03, Balbir Singh wrote:
> > On 11/05/16 14:55, Rashmica Gupta wrote:
> > > The same logic for tm_abort appears twice, so pull it out into a
> > > function.
> > >
> > > diff --git a/arch/powerpc/mm/hash_utils_64.c
> > > b/arch/pow
On 11/05/2016 12:35, Alexander Graf wrote:
> On 03/15/2016 09:18 PM, Laurent Vivier wrote:
>> While writing some instruction tests for kvm-unit-tests for powerpc,
>> I've found that illegal instructions are not managed correctly with
>> kvm-pr,
>> while it is fine with kvm-hv.
>>
>> When an illeg
On Wed, May 11, 2016 at 11:15:55AM +1000, Gavin Shan wrote:
> When CONFIG_KVM_XICS is enabled, CPU_UP_PREPARE and other macros for
> CPU states in linux/cpu.h are needed by arch/powerpc/kvm/book3s_hv.c.
> Otherwise, build error as below is seen:
>
>gwshan@gwshan:~/sandbox/l$ make arch/powerpc/
On Fri, Apr 29, 2016 at 02:57:23PM +1000, Alexey Kardashevskiy wrote:
> When XICS_DBG is enabled, gcc produces format errors. This fixes
> formats to match passed values types.
>
> Signed-off-by: Alexey Kardashevskiy
Thanks, applied to my kvm-ppc-next branch.
Paul.
_
On Fri, Apr 08, 2016 at 06:05:00PM +0200, Laurent Vivier wrote:
> Until now, when we connect gdb to the QEMU gdb-server, the
> single-step mode is not managed.
>
> This patch adds this, only for kvm-pr:
>
> If KVM_GUESTDBG_SINGLESTEP is set, we enable single-step trace bit in the
> MSR (MSR_SE) j
On 05/11/2016 01:14 PM, Laurent Vivier wrote:
On 11/05/2016 12:35, Alexander Graf wrote:
On 03/15/2016 09:18 PM, Laurent Vivier wrote:
While writing some instruction tests for kvm-unit-tests for powerpc,
I've found that illegal instructions are not managed correctly with
kvm-pr,
while it is fi
Hi folks,
I introduced a fairly nasty bug into the recently merged Radix series.
It means a kernel built with RADIX=n crashes on boot on Hash MMU machines.
So I'm going to rebase powerpc#next to squash in a fix.
Hope that doesn't screw up anyone's work.
For reference the diff from old to new i
Signed-off-by: Philippe Bergheaud
---
drivers/misc/cxl/cxl.h| 15 +++
drivers/misc/cxl/guest.c | 11 ---
drivers/misc/cxl/irq.c| 27 +++
drivers/misc/cxl/native.c | 27 ++-
4 files changed, 68 insertions(+), 12 deletion
The purpose of this set of patches is to continue on TLB handling
optimisation on the 8xx with the handling of IMMR area as a
single 512k area instead of multiple 4k pages.
This set includes a rework of linear RAM mapping in order to not use
page table but direct linear mapping. The result is equi
Memory: 124428K/131072K available (3748K kernel code, 188K rwdata,
648K rodata, 508K init, 290K bss, 6644K reserved)
Kernel virtual memory layout:
* 0xfffdf000..0xf000 : fixmap
* 0xfde0..0xfe00 : consistent mem
* 0xfddf6000..0xfde0 : early ioremap
* 0xc900..0xfddf6000
Once the linear memory space has been mapped with 8Mb pages, as
seen in the related commit, we get 11 millions DTLB missed during
the reference 600s period. 77% of the misses are on user addresses
and 23% are on kernel addresses (1 fourth for linear address space
and 3 fourth for virtual address sp
IMMR is now mapped by a fixed 512k page managed by the TLB miss
handler so it is not anymore necessary to PIN TLBs
Signed-off-by: Christophe Leroy
---
v2: No change
arch/powerpc/Kconfig.debug | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.de
Bootloader may have pinned some TLB entries so the kernel must
unpin them before flushing TLBs with tlbia otherwise pinned TLB
entries won't get flushed
Signed-off-by: Christophe Leroy
---
v2: No change
arch/powerpc/kernel/head_8xx.S | 18 ++
1 file changed, 10 insertions(+), 8
Instead of using the first level page table to define mappings for
the linear memory space, we can use direct mapping from the TLB
handling routines. This has several advantages:
* No need to read the tables at each TLB miss
* No issue in 16k pages mode where the 1st level table maps 64 Mbytes
The
On recent kernels, with some debug options like for instance
CONFIG_LOCKDEP, the BSS requires more than 8M memory, allthough
the kernel code fits in the first 8M.
Today, it is necessary to activate CONFIG_PIN_TLB to get more than 8M
at startup, allthough pinning TLB is not necessary for that.
We c
CONFIG_PIN_TLB maps IMMR area and the first 24 Mbytes of memory.
In some circunstances it might be more interesting to not map
IMMR and to map 32 Mbytes of memory instead.
Therefore we add config option CONFIG_PIN_TLB_IMMR to select if
IMMR shall be pinned or not, hence whether we pin 24 or 32 Mby
Acked-by: Ian Munsie
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, 11 May 2016 06:29:06 +
"Tian, Kevin" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, May 05, 2016 11:05 PM
> >
> > On Thu, 5 May 2016 12:15:46 +
> > "Tian, Kevin" wrote:
> >
> > > > From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
>
Hi,
On Mon, Apr 25, 2016 at 09:19:17AM -0700, Khem Raj wrote:
> gcc-6 correctly warns about a out of bounds access
>
> arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset
> greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}'
> [-Warray-bounds]
> of
On Wed, 2016-05-11 at 17:03 +0200, Christophe Leroy wrote:
> Memory: 124428K/131072K available (3748K kernel code, 188K rwdata,
> 648K rodata, 508K init, 290K bss, 6644K reserved)
> Kernel virtual memory layout:
> * 0xfffdf000..0xf000 : fixmap
> * 0xfde0..0xfe00 : consistent mem
>
This patch adds binding information for IBM/AMCC/APM GPIO
Controllers of the PowerPC 4XX series and compatible SoCs.
The "PowerPC 405EP Embedded Processor Data Sheet" has the
following to say about the GPIO controllers: "
- Controller functions and GPIO registers are programmed
and accessed v
On Mon, Jun 22, 2015 at 10:18:43AM +0530, Bharata B Rao wrote:
While developing memory hotplug support in QEMU for PoweKVM, I
realized that guest kernel has specific checks to prevent hot addition
of memory to a memory-less node.
I am referring to arch/powerpc/mm/numa.c:hot_add_scn_to_nid() whic
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, May 11, 2016 11:54 PM
>
> On Wed, 11 May 2016 06:29:06 +
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Thursday, May 05, 2016 11:05 PM
> > >
> > > On Thu, 5 M
On Wed, 11 May 2016 16:47:11 +1000
Michael Ellerman wrote:
> Currently a kernel that is built with CONFIG_PPC_RADIX_MMU=n, and then
> booted on a 64-bit Hash MMU system will crash on the first SLB miss,
> typically with an oops something like:
>
> Unrecoverable exception 4100 at c09695
On Thu, 12 May 2016 01:19:44 +
"Tian, Kevin" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Wednesday, May 11, 2016 11:54 PM
> >
> > On Wed, 11 May 2016 06:29:06 +
> > "Tian, Kevin" wrote:
> >
> > > > From: Alex Williamson [mailto:alex.william...@redha
Michael Ellerman writes:
> Follow the example of the cpu feature code, and add a mask of possible
> MMU features, MMU_FTRS_POSSIBLE.
>
> This is used in mmu_has_feature(), which allows the possible mask to act
> as a shortcut for any features that are not possible, but still allows
> the feature
Michael Ellerman writes:
> Currently a kernel that is built with CONFIG_PPC_RADIX_MMU=n, and then
> booted on a 64-bit Hash MMU system will crash on the first SLB miss,
> typically with an oops something like:
>
> Unrecoverable exception 4100 at c0969504
> cpu 0x0: Vector: 4100 at [c
The same logic for tm_abort appears twice, so pull it out into a
function.
Signed-off-by: Rashmica Gupta
---
v2: Removed some #ifdefs from inside C code and changed the formatting of the
comment.
arch/powerpc/mm/hash_utils_64.c | 56 +++--
1 file changed, 26
On Thu, 12 May 2016 13:39:02 +1000
Rashmica Gupta wrote:
> The same logic for tm_abort appears twice, so pull it out into a
> function.
>
> Signed-off-by: Rashmica Gupta
> ---
> v2: Removed some #ifdefs from inside C code and changed the formatting of the
> comment.
>
> arch/powerpc/mm/hash_u
On Tue, May 03, 2016 at 03:41:45PM +1000, Gavin Shan wrote:
>The function pnv_pci_reset_secondary_bus() is called like below.
>It's impossible for call the function on root bus. So it's safe
>to remove the root bus case in the function. No functional changes
>introduced.
>
> pci_parent_bus_reset(
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, May 12, 2016 10:21 AM
>
> On Thu, 12 May 2016 01:19:44 +
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Wednesday, May 11, 2016 11:54 PM
> > >
> > > On Wed, 11
On Fri, Apr 08, 2016 at 05:54:11PM +0200, Thomas Huth wrote:
> The SIAR register is available twice, one time as SPR 780 (unprivileged,
> but read-only), and one time as SPR 796 (privileged, but read and write).
> The Linux kernel code currently uses SPR 780 - and while this is OK for
> reading, wr
On Mon, Apr 25, 2016 at 10:15:47AM +0200, Alexander Graf wrote:
>
> >> +#define SPRN_SIAR796
>
> I'm sure there's a reason (iSeries?) we used the r/o version before. Better
> introduce a new constant that gives us rw access and use that in the kvm
> entry/exit code.
I don't think we ever d
The pnv_pci_init_ioda_phb() helper allocates a blob to store auxilary
data such PE and M32/M64 segment allocation maps; this single blob has few
partitions, size of each is derived from the PE number -
phb->ioda.total_pe_num.
It was assumed that the minimum PE number is 8, however it is 4 for NPU
Before 3e68dc57 "powerpc/powernv: Remove DMA32 PE list", NPU PEs
were linked to the NPU PHB via phb->ioda.pe_dma_list; after that fix,
the phb->ioda.pe_list is used.
During the pe_dma_list removal, list_add_tail(&phb->ioda.pe_dma_list)
was removed, however no list_add() was added so does this patc
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
"next" branch sha1 e682e4c needs 3 fixes to get NVLink passthrough
working (in fact 4 but the last one is goind via VFIO tree),
two of them are in this patchset; also:
35a3a27 "powerpc/powernv: Exclude root bus in pnv_pci_reset_second
On Thu, May 12, 2016 at 03:47:10PM +1000, Alexey Kardashevskiy wrote:
>Before 3e68dc57 "powerpc/powernv: Remove DMA32 PE list", NPU PEs
>were linked to the NPU PHB via phb->ioda.pe_dma_list; after that fix,
>the phb->ioda.pe_list is used.
>
>During the pe_dma_list removal, list_add_tail(&phb->ioda.
On Thu, May 12, 2016 at 03:47:09PM +1000, Alexey Kardashevskiy wrote:
>The pnv_pci_init_ioda_phb() helper allocates a blob to store auxilary
>data such PE and M32/M64 segment allocation maps; this single blob has few
>partitions, size of each is derived from the PE number -
>phb->ioda.total_pe_num.
On 05/12/2016 04:09 PM, Gavin Shan wrote:
On Thu, May 12, 2016 at 03:47:09PM +1000, Alexey Kardashevskiy wrote:
The pnv_pci_init_ioda_phb() helper allocates a blob to store auxilary
data such PE and M32/M64 segment allocation maps; this single blob has few
partitions, size of each is derived fro
45 matches
Mail list logo
