Re: [PATCH] powerpc: Ensure .mem(init|exit).text are within _stext/_etext

Hi, > In our linker script we open code the list of text sections, because > we need to include the __ftr_alt sections, which are arch-specific. > > This means we can't use TEXT_TEXT as defined in vmlinux.lds.h, and so > we don't have the MEM_KEEP() logic for memory hotplug sections. > > If we

[PATCH] powerpc: Ensure .mem(init|exit).text are within _stext/_etext

In our linker script we open code the list of text sections, because we need to include the __ftr_alt sections, which are arch-specific. This means we can't use TEXT_TEXT as defined in vmlinux.lds.h, and so we don't have the MEM_KEEP() logic for memory hotplug sections. If we build the kernel

Re: [PATCH] powerpc/64: whitelist unresolved modversions CRCs

Nicholas Piggin writes: > These are a symptom of CRC generation failure in generic > build code, and not powerpc specific. > > Signed-off-by: Nicholas Piggin Acked-by: Michael Ellerman cheers

Re: [PATCH 0/2] Enable MSR_TM lazily

On Wed, 14 Sep 2016 11:10:22 -0300 Carlos Eduardo Seo wrote: > On 9/14/16 8:28 AM, Nicholas Piggin wrote: > > > > How common it is for glibc to be built with elision? > > > > Not that common. We have it built with TLE support in Ubuntu (starting > in 15.04), SLES 12

Re: [PATCH] powerpc: Don't change the section in _GLOBAL()

On Thu, 15 Sep 2016 10:40:20 +1000 Michael Ellerman wrote: > Currently the _GLOBAL() macro unilaterally sets the assembler section to > ".text" at the start of the macro. This is rude as the caller may be > using a different section. > > So let the caller decide which

[PATCH 4/4] drivers/pci/hotplug: Support surprise hotplug

This supports PCI surprise hotplug. The design is highlighted as below: * The PCI slot's surprise hotplug capability is exposed through device node property "ibm,slot-surprise-pluggable", meaning PCI surprise hotplug will be disabled if skiboot doesn't support it yet. * The

[PATCH 3/4] powerpc/powernv: Unfreeze PE on allocation

This unfreezes PE when it's initialized because the PE might be put into frozen state in the last hot remove path. It's not harmful to do so if the PE is already in unfrozen state. Signed-off-by: Gavin Shan --- arch/powerpc/platforms/powernv/pci-ioda.c | 12

[PATCH 0/4] powerpc/powernv: PCI Surprise Hotplug Support

This series of patches supports PCI surprise hotplug on PowerNV platform. * This newly added functionality depends on skiboot's changes. However, the functionality is disabled simply when skiboot doesn't support it. For one specific slot, property "ibm,slot-surprise-pluggable" of the

[PATCH 2/4] powerpc/eeh: Export eeh_pe_state_mark()

This exports eeh_pe_state_mark(). It will be used to mark the surprise hot removed PE as isolated to avoid unexpected EEH error reporting in surprise remove path. Signed-off-by: Gavin Shan --- arch/powerpc/kernel/eeh_pe.c | 1 + 1 file changed, 1 insertion(+) diff

[PATCH 1/4] powerpc/eeh: Allow to freeze PE in eeh_pe_set_option()

Function eeh_pe_set_option() is used to apply the requested options (enable, disable, unfreeze) in EEH virtualization path. The semantics of this function isn't complete until freezing is supported. This allows to freeze the indicated PE. The new semantics is going to be used in PCI surprise hot

Re: [PATCH v5 1/5] kexec_file: Include the purgatory segment in the kexec image checksum.

Hello Stephen, Am Donnerstag, 15 September 2016, 11:43:08 schrieb Stephen Rothwell: > Hi Thiago, > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index 2a1f0ce7c59a..dcd1679f3005 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -1792,6 +1792,11 @@ config SECCOMP > >

Re: [PATCH v5 1/5] kexec_file: Include the purgatory segment in the kexec image checksum.

Hi Thiago, > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 2a1f0ce7c59a..dcd1679f3005 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1792,6 +1792,11 @@ config SECCOMP > > source kernel/Kconfig.hz > > +# x86 needs to relocate the purgatory after the checksum is

[PATCH v5 5/5] IMA: Demonstration code for kexec buffer passing.

This shows how kernel code can use the kexec buffer passing mechanism to pass information to the next kernel. This patch is not intended to be committed. [a...@linux-foundation.org: coding-style fixes] Signed-off-by: Thiago Jung Bauermann Signed-off-by: Andrew

[PATCH v5 4/5] 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. Before modifying the segment the image checksum is verified, and after the segment

[PATCH v5 3/5] 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 v5 2/5] 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 v5 1/5] kexec_file: Include the purgatory segment in the kexec image checksum.

Currently, the purgatory segment is skipped from the kexec image checksum because it is modified to include the calculated digest. By putting the digest in a separate kexec segment, we can include the purgatory segment in the kexec image verification since it won't need to be modified anymore.

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

Hello, This version of the patch series fixes two issues: 1. The previous version modified struct kexec_segment, but that broke the ABI for at least 32-bit ARM. 2. The previous version didn't include the hand-over buffer in the kexec image checksum verification. Now the kexec image

[PATCH] powerpc: Don't change the section in _GLOBAL()

Currently the _GLOBAL() macro unilaterally sets the assembler section to ".text" at the start of the macro. This is rude as the caller may be using a different section. So let the caller decide which section to emit the code into. On big endian we do need to switch to the ".opd" section to emit

Re: [PATCH] powerpc/64: whitelist unresolved modversions CRCs

Hi Nick, On Wed, 14 Sep 2016 12:45:07 +1000 Nicholas Piggin wrote: > > These are a symptom of CRC generation failure in generic > build code, and not powerpc specific. > > Signed-off-by: Nicholas Piggin This fixes my build problems. Tested-by: Stephen

Re: [PATCH] powerpc/64: whitelist unresolved modversions CRCs

Hi Nick, On Wed, 14 Sep 2016 12:45:07 +1000 Nicholas Piggin wrote: > > These are a symptom of CRC generation failure in generic > build code, and not powerpc specific. > > Signed-off-by: Nicholas Piggin OK, so I will use this as a merge fix patch for the

[PATCH v2 3/3] mm: enable CONFIG_MOVABLE_NODE on powerpc

Onlining memory into ZONE_MOVABLE requires CONFIG_MOVABLE_NODE. Enable the use of this config option on PPC64 platforms. Signed-off-by: Reza Arbab --- Documentation/kernel-parameters.txt | 2 +- mm/Kconfig | 2 +- 2 files changed, 2

[PATCH v2 1/3] drivers/of: recognize status property of dt memory nodes

Respect the standard dt "status" property when scanning memory nodes in early_init_dt_scan_memory(), so that if the property is present and not "okay", no memory will be added. The use case at hand is accelerator or device memory, which may be unusable until post-boot initialization of the memory

[PATCH v2 2/3] powerpc/mm: allow memory hotplug into a memoryless node

Remove the check which prevents us from hotplugging into an empty node. This limitation has been questioned before [1], and judging by the response, there doesn't seem to be a reason we can't remove it. No issues have been found in light testing. [1]

[PATCH v2 0/3] powerpc/mm: movable hotplug memory nodes

These changes enable onlining memory into ZONE_MOVABLE on power, and the creation of discrete nodes of movable memory. We provide a way to describe the extents and numa associativity of such a node in the device tree, yet still defer the memory addition to take place post-boot through hotplug.

[PATCH V5 8/8] powerpc: Enable support for new DRC devtree properties

prom_init.c: Enable support for new DRC device tree properties "ibm,drc-info" and "ibm,dynamic-memory-v2" in initial handshake between the Linux kernel and the front end processor. [V2: Revise constant names.] [V3: No change.] [V4: Update comments] [V5: Resynchronize/resubmit] Signed-off-by:

[PATCH V5 7/8] powerpc: Check arch.vec earlier during boot for memory features

architecture.vec5 features: The boot-time memory management needs to know the form of the "ibm,dynamic-memory-v2" property early during scanning of the flattened device tree. This patch moves execution of the function pseries_probe_fw_features() early enough to be before the scanning of the

[PATCH V5 6/8] hotplug/drc-info: Add code to search new devtree properties

rpadlpar_core.c: Provide parallel routines to search the older device- tree properties ("ibm,drc-indexes", "ibm,drc-names", "ibm,drc-types" and "ibm,drc-power-domains"), or the new property "ibm,drc-info". The interface to examine the DRC information is changed from a "get" function that returns

[PATCH V5 5/8] pseries/drc-info: Search new DRC properties for CPU indexes

pseries/drc-info: Provide parallel routines to convert between drc_index and CPU numbers at runtime, using the older device-tree properties ("ibm,drc-indexes", "ibm,drc-names", "ibm,drc-types" and "ibm,drc-power-domains"), or the new property "ibm,drc-info". [V2: Revise contant names.] [V3: No

[PATCH V5 4/8] pseries/hotplug init: Convert new DRC memory property for hotplug runtime

hotplug_init: Simplify the code needed for runtime memory hotplug and maintenance with a conversion routine that transforms the compressed property "ibm,dynamic-memory-v2" to the form of "ibm,dynamic-memory" within the "ibm,dynamic-reconfiguration-memory" property. Thus only a single set of

[PATCH V5 2/8] powerpc/memory: Parse new memory property to register blocks.

powerpc/memory: Add parallel routines to parse the new property "ibm,dynamic-memory-v2" property when it is present, and then to register the relevant memory blocks with the operating system. This property format is intended to provide a more compact representation of memory when communicating

[PATCH V5 3/8] powerpc/memory: Parse new memory property to initialize structures.

powerpc/memory: Add parallel routines to parse the new property "ibm,dynamic-memory-v2" property when it is present, and then to finish initialization of the relevant memory structures with the operating system. This code is shared between the boot-time initialization functions and the runtime

[PATCH V5 1/8] powerpc/firmware: Add definitions for new firmware features.

Firmware Features: Define new bit flags representing the presence of new device tree properties "ibm,drc-info", and "ibm,dynamic-memory-v2". These flags are used to tell the front end processor when the Linux kernel supports the new properties, and by the front end processor to tell the Linux

[Patch V5 0/8] powerpc/devtree: Add support for 2 new DRC properties

Several properties in the DRC device tree format are replaced by more compact representations to allow, for example, for the encoding of vast amounts of memory, and or reduced duplication of information in related data structures. "ibm,drc-info": This property, when present, replaces the

Re: [PATCH 3/6] cxlflash: Fix to avoid EEH and host reset collisions

> "Uma" == Uma Krishnan writes: Applied patches 3 through 6 to 4.9/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH V2 1/7] dt-bindings: Update QorIQ TMU thermal bindings

On Wed, Jun 8, 2016 at 2:52 PM, Rob Herring wrote: > On Tue, Jun 07, 2016 at 11:27:34AM +0800, Jia Hongtao wrote: >> For different types of SoC the sensor id and endianness may vary. >> "#thermal-sensor-cells" is used to provide sensor id information. >> "little-endian" property

Re: [PATCH 0/2] Enable MSR_TM lazily

On 9/14/16 8:28 AM, Nicholas Piggin wrote: How common it is for glibc to be built with elision? Not that common. We have it built with TLE support in Ubuntu (starting in 15.04), SLES 12 (since SP2) and AT 9.0-0. However, it is only enabled by default in Ubuntu. For SLES and AT 9.0, the

Re: [PATCH] drivers/dma: NO_IRQ removal from powerpc-only drivers

On Sat, Sep 10, 2016 at 07:56:04PM +1000, Michael Ellerman wrote: > We'd like to eventually remove NO_IRQ on powerpc, so remove usages of it > from powerpc-only drivers. Applied after fixing subsystem name -- ~Vinod

Re: [PATCH 0/2] Enable MSR_TM lazily

On 14 Sep. 2016 10:12 pm, "Nicholas Piggin" wrote: > > On Wed, 14 Sep 2016 21:46:39 +1000 > Michael Neuling wrote: > > > On Wed, 2016-09-14 at 21:28 +1000, Nicholas Piggin wrote: > > > Cc'ing Carlos > > > > > > On Wed, 14 Sep 2016 18:02:14 +1000 > > I think

Re: [PATCH 0/2] Enable MSR_TM lazily

On Wed, 14 Sep 2016 21:46:39 +1000 Michael Neuling wrote: > On Wed, 2016-09-14 at 21:28 +1000, Nicholas Piggin wrote: > > Cc'ing Carlos > > > > On Wed, 14 Sep 2016 18:02:14 +1000 > > Cyril Bur wrote: > > > > > > > > Currently the kernel checks to see

Re: [PATCH 0/2] Enable MSR_TM lazily

On Wed, 2016-09-14 at 21:28 +1000, Nicholas Piggin wrote: > Cc'ing Carlos > > On Wed, 14 Sep 2016 18:02:14 +1000 > Cyril Bur wrote: > > > > > Currently the kernel checks to see if the hardware is transactional > > memory capable and always enables the MSR_TM bit. The

Re: [PATCH] powernv/pci: Fix m64 checks for SR-IOV and window alignment

On Wed, Sep 14, 2016 at 05:51:08PM +1000, Benjamin Herrenschmidt wrote: >On Wed, 2016-09-14 at 16:37 +1000, Russell Currey wrote: >> Commit 5958d19a143e checks for prefetchable m64 BARs by comparing the >> addresses instead of using resource flags.  This broke SR-IOV as the >> m64 >> check in

Re: [PATCH 0/2] Enable MSR_TM lazily

Cc'ing Carlos On Wed, 14 Sep 2016 18:02:14 +1000 Cyril Bur wrote: > Currently the kernel checks to see if the hardware is transactional > memory capable and always enables the MSR_TM bit. The problem with > this is that the TM related SPRs become available to userspace, >

Re: [V2] powerpc/Kconfig: Update config option based on page size.

Michael Ellerman writes: On Fri, 2016-19-02 at 05:38:47 UTC, Rashmica Gupta wrote: Currently on PPC64 changing kernel pagesize from 4K to 64K leaves FORCE_MAX_ZONEORDER set to 13 - which produces a compile error. ... So, update the range of FORCE_MAX_ZONEORDER from

Re: [PATCH] powernv/pci: Fix m64 checks for SR-IOV and window alignment

On Wed, 2016-09-14 at 16:37 +1000, Russell Currey wrote: > Commit 5958d19a143e checks for prefetchable m64 BARs by comparing the > addresses instead of using resource flags.  This broke SR-IOV as the > m64 > check in pnv_pci_ioda_fixup_iov_resources() fails. > > The condition in

[PATCH 1/2] powerpc: tm: Add TM Unavailable Exception

If the kernel disables transactional memory (TM) and userspace still tries TM related actions (TM instructions or TM SPR accesses) TM aware hardware will cause the kernel to take a facility unavailable exception. Add checks for the exception being caused by illegal TM access in userspace.

[PATCH 2/2] powerpc: tm: Enable transactional memory (TM) lazily for userspace

Currently the MSR TM bit is always set if the hardware is TM capable. This adds extra overhead as it means the TM SPRS (TFHAR, TEXASR and TFAIR) must be swapped for each process regardless of if they use TM. For processes that don't use TM the TM MSR bit can be turned off allowing the kernel to

[PATCH 0/2] Enable MSR_TM lazily

Currently the kernel checks to see if the hardware is transactional memory capable and always enables the MSR_TM bit. The problem with this is that the TM related SPRs become available to userspace, requiring them to be switched between processes. It turns out these SPRs are expensive to read and

Re: [PATCH] powernv/pci: Fix m64 checks for SR-IOV and window alignment

On 14/09/16 16:37, Russell Currey wrote: > Commit 5958d19a143e checks for prefetchable m64 BARs by comparing the > addresses instead of using resource flags. This broke SR-IOV as the m64 > check in pnv_pci_ioda_fixup_iov_resources() fails. > > The condition in pnv_pci_window_alignment() also

Re: [PATCH v14 00/15] selftests/powerpc: Add ptrace tests for ppc registers

Cyril Bur writes: > Its messy but I think the accepted solution for kselftests is to do: > > #include "../../../../../usr/include/linux/elf.h" > > which I believe will get the headers generated for the target by `make > headers_install` and therefore should match that for

[PATCH] powernv/pci: Fix m64 checks for SR-IOV and window alignment

Commit 5958d19a143e checks for prefetchable m64 BARs by comparing the addresses instead of using resource flags. This broke SR-IOV as the m64 check in pnv_pci_ioda_fixup_iov_resources() fails. The condition in pnv_pci_window_alignment() also changed to checking only IORESOURCE_MEM_64 instead of