[PATCH v2 6/6] IMA: Demonstration code for kexec buffer passing.

This patch is not intended to be committed. It shows how kernel code can use the kexec buffer passing mechanism to pass information to the next kernel. Signed-off-by: Thiago Jung Bauermann --- include/linux/ima.h | 11 + kernel/kexec_file.c

[PATCH v2 5/6] kexec: Share logic to copy segment page contents.

Make kimage_load_normal_segment and kexec_update_segment share code which they currently duplicate. Signed-off-by: Thiago Jung Bauermann --- kernel/kexec_core.c | 159 +++- 1 file changed, 95 insertions(+), 64

[PATCH v2 4/6] kexec_file: Add mechanism to update kexec segments.

kexec_update_segment allows a given segment in kexec_image to have its contents updated. This is useful if the current kernel wants to send information to the next kernel that is up-to-date at the time of reboot. Signed-off-by: Thiago Jung Bauermann ---

[PATCH v2 3/6] kexec_file: Allow skipping checksum calculation for some segments.

Adds checksum argument to kexec_add_buffer specifying whether the given segment should be part of the checksum calculation. The next patch will add a way to update segments after a kimage is loaded. Segments that will be updated in this way should not be checksummed, otherwise they will cause the

[PATCH v2 2/6] powerpc: kexec_file: Add buffer hand-over support for the next kernel

The buffer hand-over mechanism allows the currently running kernel to pass data to kernel that will be kexec'd via a kexec segment. The second kernel can check whether the previous kernel sent data and retrieve it. This is the architecture-specific part. Signed-off-by: Thiago Jung Bauermann

[PATCH v2 1/6] kexec_file: Add buffer hand-over support for the next kernel

The buffer hand-over mechanism allows the currently running kernel to pass data to kernel that will be kexec'd via a kexec segment. The second kernel can check whether the previous kernel sent data and retrieve it. This is the architecture-independent part of the feature. Signed-off-by: Thiago

[PATCH v2 0/6] kexec_file: Add buffer hand-over for the next kernel

Hello, This patch series implements a mechanism which allows the kernel to pass on a buffer to the kernel that will be kexec'd. This buffer is passed as a segment which is added to the kimage when it is being prepared by kexec_file_load. How the second kernel is informed of this buffer is

Re: [PATCH] powerpc/32: Remove one insn in __bswapdi2

On Thu, Aug 11, 2016 at 05:11:19PM -0500, Segher Boessenkool wrote: > On Thu, Aug 11, 2016 at 11:34:37PM +0200, Gabriel Paubert wrote: > > On the other hand gcc did at the time a very poor job (quite an > > understatement) at bswapdi when compiling for 64 bit processors > > (see the example). > >

Re: [PATCH v2 2/2] kexec: extend kexec_file_load system call

Hello Balbir, Thank you for the review! Am Freitag, 12 August 2016, 18:17:39 schrieb Balbir Singh: > On Thu, Aug 11, 2016 at 08:03:58PM -0300, Thiago Jung Bauermann wrote: > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > index 3523bf62f328..847d9c31f428 100644 > > ---

Re: [PATCH] powerpc: populate the default bus with machine_arch_initcall

On Fri, Aug 12, 2016 at 12:49 AM, Kevin Hao wrote: > On Fri, Aug 12, 2016 at 02:39:32PM +1000, Michael Ellerman wrote: >> Kevin Hao writes: [...] >> Every one of those initcall changes could be introducing a bug, by >> changing the order vs other init

Re: [PATCH 3/4] powerpc/mm: allow memory hotplug into a memoryless node

On Fri, Aug 12, 2016 at 11:50:43AM +1000, Balbir Singh wrote: On 09/08/16 04:27, Reza Arbab wrote: Remove the check which prevents us from hotplugging into an empty node. Do we want to do this only for ibm,hotplug-aperture compatible ranges? We could, but since past discussions and current

[PATCH 6/6] powerpc/8xx: implementation of huge pages

The 8xx has 512k and 8M pages. This patch implements hugepages using those sizes. On the 8xx, the size of pages is in the PGD entry, using PS field (bits 28-29): 00 : Small pages (4k or 16k) 01 : 512k pages 10 : reserved 11 : 8M pages The implementation uses a mix of what is used on BOOKS and

[PATCH 5/6] powerpc/8xx: make user addr DTLB miss the short path

User space DTLB miss represent approximatly 90% of TLB misses so make it the shortest path. Also remove an unneccessary double jump in FixupDAR Before this patch, we spend 3.3 TB ticks in the handler for each user address miss and 3.4 TB ticks for each kernel address miss After this patch, we

[PATCH 4/6] powerpc/8xx: Move additional DTLBMiss handlers out of exception area

When all options are activated, there is not enough space for the DTLBMiss handlers that handles IMMR area and linear RAM pages in the exception area. So lets move them after .0x2000 Signed-off-by: Christophe Leroy --- arch/powerpc/kernel/head_8xx.S | 84

[PATCH 3/6] powerpc/8xx: use r3 to scratch CR in ITLBmiss

Signed-off-by: Christophe Leroy --- arch/powerpc/kernel/head_8xx.S | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index 43ddaae..708fd43 100644 ---

[PATCH 2/6] powerpc: fix usage of _PAGE_RO in hugepage

fixes: a7b9f671f2d14 ("powerpc32: adds handling of _PAGE_RO") Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/book3s/64/pgtable.h | 2 ++ arch/powerpc/mm/hugetlbpage.c| 2 ++ 2 files changed, 4 insertions(+) diff --git

[PATCH 1/6] powerpc: port 64 bits pgtable_cache to 32 bits

Today powerpc64 uses a set of pgtable_caches while powerpc32 uses standard pages when using 4k pages and a single pgtable_cache if using other size pages. In addition powerpc32 uses another cache when handling huge pages. In preparation of implementing huge pages on the 8xx, this patch replaces

[PATCH 0/6] powerpc/8xx: implementation of huge pages

This set provides implementation of huge pages on the 8xx Christophe Leroy (6): powerpc: port 64 bits pgtable_cache to 32 bits powerpc: fix usage of _PAGE_RO in hugepage powerpc/8xx: use r3 to scratch CR in ITLBmiss powerpc/8xx: Move additional DTLBMiss handlers out of exception area

Re: debug problems on ppc 83xx target due to changed struct task_struct

On 08/12/2016 08:47 AM, Holger Brunck wrote: > On 12/08/16 17:14, Dave Hansen wrote: >> On 08/12/2016 07:50 AM, Holger Brunck wrote: >>> When I try to debug our multithreaded userspace application with gdb I get >>> stuck when trying to single step code. >> >> Can you clarify "stuck"? Like the

Re: debug problems on ppc 83xx target due to changed struct task_struct

Thanks for the quick answer! On 12/08/16 17:14, Dave Hansen wrote: > On 08/12/2016 07:50 AM, Holger Brunck wrote: >> When I try to debug our multithreaded userspace application with gdb I get >> stuck when trying to single step code. > > Can you clarify "stuck"? Like the instructions don't

Re: [PATCH kernel 14/15] vfio/spapr_tce: Export container API for external users

On Fri, 12 Aug 2016 15:46:01 +1000 David Gibson wrote: > On Wed, Aug 10, 2016 at 10:46:30AM -0600, Alex Williamson wrote: > > On Wed, 10 Aug 2016 15:37:17 +1000 > > Alexey Kardashevskiy wrote: > > > > > On 09/08/16 22:16, Alex Williamson wrote:

Re: debug problems on ppc 83xx target due to changed struct task_struct

On 08/12/2016 07:50 AM, Holger Brunck wrote: > When I try to debug our multithreaded userspace application with gdb I get > stuck when trying to single step code. Can you clarify "stuck"? Like the instructions don't advance? Have you been able to find a root cause for this? > Does anyone have

debug problems on ppc 83xx target due to changed struct task_struct

Hi all, we are currently trying to update from kernel 3.10 to latest stable kernel 4.4 and we encounter the following problem. When I try to debug our multithreaded userspace application with gdb I get stuck when trying to single step code. Due to the fact that our ppc 8360 target is mainlined

Re: [RFC PATCH] powerpc/Makefile: Add option to build with gold

On Fri, 12 Aug 2016 21:30:21 +1000 Michael Ellerman wrote: > This adds a Kconfig option which can be turned on to enable use of the > gold linker. It depends on DEBUG_KERNEL to hopefully hide it from users > who don't really care about it, and also !COMPILE_TEST so that it

[RFC PATCH 2/2] powerpc/prom: Switch to using structs for ibm_architecture_vec

Now that we've defined structures to describe each of the client architecture vectors, we can use those to construct the value we pass to firmware. This avoids the tricks we previously played with the W() macro, allows us to properly endian annotate fields, and should help to avoid bugs

[RFC PATCH 1/2] powerpc/prom: Define structs for client architecture vectors

The "client architecture vectors" are a series of structures we pass to firmware to define various things, such as what processors we support and many other options. Each structure is entirely different so we have to define a different struct for each one, but that's OK. Signed-off-by: Michael

[pasemi] Internal CompactFlash (CF) card device not recognised after the powerpc-4.8-1 merge

Hi All, I compiled the RC1 of kernel 4.8 with Olof's CompactFlash driver for PA Semi Electra boards today. Unfortunately this driver doesn't detect our CF device. dmesg | grep -i pasemi [0.00] mpic: Setting up MPIC "PASEMI-OPIC" version 1.3 at fc00, max 2 CPUs [2.937676]

[PATCH] powerpc/prom: Fix sub-processor option passed to ibm, client-architecture-support

When booting from an OpenFirmware which supports it, we use the "ibm,client-architecture-support" firmware call to communicate our capabilities to firmware. The format of the structure we pass to firmware is specified in PAPR (Power Architecture Platform Requirements), or the public version

Re: [PATCH v4] powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb)

Michael, On 08/12/2016 02:54 AM, Gavin Shan wrote: > I don't have more obvious comments except below one nitpicky: I just addressed/replied this in the other e-mail; i think it's OK, and Andrew/cxl is OK w/ it too. > Reviewed-by: Gavin Shan On 08/12/2016 03:06 AM,

Re: [PATCH v4] powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb)

On 08/12/2016 03:03 AM, Andrew Donnellan wrote: On 12/08/16 15:54, Gavin Shan wrote: It might be nicer for users to implement their own pcibios_free_controller_deferred(), meaning pSeries needs its own implementation for now. The reason is more user (pSeries) specific objects can be released

[RFC PATCH] powerpc/Makefile: Add option to build with gold

This adds a Kconfig option which can be turned on to enable use of the gold linker. It depends on DEBUG_KERNEL to hopefully hide it from users who don't really care about it, and also !COMPILE_TEST so that it will be turned off for allyes/modconfig builds. In the wrapper script we currently

[GIT PULL] Please pull powerpc/linux.git powerpc-4.8-3 tag

Hi Linus, Please pull some powerpc fixes for 4.8: The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git

[pasemi] Internal CompactFlash (CF) card device not recognised after the powerpc-4.8-1 merge

I meant, I reverted the setup.c. - Christian On 12 August 2016 at 11:00 AM, Christian Zigotzky wrote: Hi All, I reverted the commit https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/platforms/pasemi/setup.c?id=bad60e6f259a01cf9f29a1ef8d435ab6c60b2de9. It

[pasemi] Internal CompactFlash (CF) card device not recognised after the powerpc-4.8-1 merge

Hi All, I reverted the commit https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/platforms/pasemi/setup.c?id=bad60e6f259a01cf9f29a1ef8d435ab6c60b2de9. It boots but it doesn't find any partitions. Cheers, Christian On 11 August 2016 at 5:03 PM, Christian

Re: [PATCH v2 2/2] kexec: extend kexec_file_load system call

On Thu, Aug 11, 2016 at 08:03:58PM -0300, Thiago Jung Bauermann wrote: > From: AKASHI Takahiro > > Device tree blob must be passed to a second kernel on DTB-capable > archs, like powerpc and arm64, but the current kernel interface > lacks this support. > > This patch

Re: [PATCH] soc: fsl/qe: fix Oops on CPM1 (and likely CPM2)

Le 12/08/2016 à 01:29, Scott Wood a écrit : On Mon, 2016-08-08 at 18:08 +0200, Christophe Leroy wrote: Commit 0e6e01ff694ee ("CPM/QE: use genalloc to manage CPM/QE muram") has changed the way muram is managed. genalloc uses kmalloc(), hence requires the SLAB to be up and running. On powerpc

Re: [PATCH kernel 14/15] vfio/spapr_tce: Export container API for external users

On 12/08/16 15:46, David Gibson wrote: > On Wed, Aug 10, 2016 at 10:46:30AM -0600, Alex Williamson wrote: >> On Wed, 10 Aug 2016 15:37:17 +1000 >> Alexey Kardashevskiy wrote: >> >>> On 09/08/16 22:16, Alex Williamson wrote: On Tue, 9 Aug 2016 15:19:39 +1000 Alexey

Re: [PATCH v4] powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb)

On 12/08/16 06:25, Mauricio Faria de Oliveira wrote: This patch leverages 'struct pci_host_bridge' from the PCI subsystem in order to free the pci_controller only after the last reference to its devices is dropped (avoiding an oops in pcibios_release_device() if the last reference is dropped

Re: [PATCH v4] powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb)

On 12/08/16 15:54, Gavin Shan wrote: It might be nicer for users to implement their own pcibios_free_controller_deferred(), meaning pSeries needs its own implementation for now. The reason is more user (pSeries) specific objects can be released together with the PHB. However, I'm still fine