[PATCH RFC 2/2] powerpc/mm: Enable page parallel initialisation

From: Li Zhang Parallel initialisation has been enabled for X86, boot time is improved greatly. On Power8, for small memory, it is improved greatly. Here is the result from my test on Power8 platform: For 4GB memory: 57% is improved For 50GB memory: 22% is improve

[PATCH RFC 1/2] mm: meminit: initialise more memory for inode/dentry hash tables in early boot

From: Li Zhang This patch is based on Mel Gorman's old patch in the mailing list, https://lkml.org/lkml/2015/5/5/280 which is dicussed but it is fixed with a completion to wait for all memory initialised in page_alloc_init_late(). It is to fix the oom problem on X86

[PATCH RFC 0/2] mm: Enable page parallel initialisation for Power

From: Li Zhang Uptream has supported page parallel initialisation for X86 and the boot time is improved greately. Some tests have been done for Power. Here is the result I have done with different memory size. * 4GB memory: boot time is as the following:

[RFC][PATCH][v2] Enable livepatching for powerpc

Changelog: 1. Implement review comments by Michael 2. The previous version compared _NIP from the wrong location to check for whether we are going to a patched location This applies on top of the patches posted by Michael

Re: [PATCH v3 1/8] powerpc: Create a helper for getting the kernel toc value

* Michael Ellerman [2016-03-03 15:26:53]: > Move the logic to work out the kernel toc pointer into a header. This is > a good cleanup, and also means we can use it elsewhere in future. > > Reviewed-by: Kamalesh Babulal > Reviewed-by: Torsten

[PATCH] powerpc/fsl-book3e: Avoid lbarx on e5500

lbarx/stbcx. are implemented on e6500, but not on e5500. Likewise, SMT is on e6500, but not on e5500. So, avoid executing an unimplemented instruction by only locking when needed (i.e. in the presence of SMT). Signed-off-by: Scott Wood --- This fixes a regression that was

Re: Problems with swapping in v4.5-rc on POWER

On Wed, 2016-03-02 at 12:49 -0800, Hugh Dickins wrote: > On Fri, 26 Feb 2016, Hugh Dickins wrote: > > On Thu, 25 Feb 2016, Hugh Dickins wrote: > > > On Wed, 24 Feb 2016, Hugh Dickins wrote: > > > > On Thu, 25 Feb 2016, Aneesh Kumar K.V wrote: > > > > > > > > > > Can you test the impact of the

Re: [PATCH v5 16/18] cxl: Support the cxl kernel API from a guest

> +static int guest_afu_cr_write32(struct cxl_afu *afu, int cr, u64 off, u32 in) > +{ > +/* config record is not writable from guest */ > +return -EPERM; Thanks. Acked-by: Ian Munsie ___ Linuxppc-dev mailing list

Re: [PATCH v5 08/18] cxl: IRQ allocation for guests

> +/* > + * The very first interrupt of range 0 is > + * always the PSL interrupt, but we only > + * need to connect a handler for guests, > + * because there's one PSL interrupt per > + * context. > +

Re: [PATCH v5 13/18] cxl: sysfs support for guests

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

Re: [PATCH v5 12/18] cxl: Add guest-specific code

> +static int read_vpd(struct cxl *adapter, struct cxl_afu *afu) ... > +if (rc > 0) { > +cxl_dump_debug_buffer(vpd, rc); Much nicer than including all that inline - thanks :) Acked-by: Ian Munsie ___ Linuxppc-dev

Re: [PATCH v5 05/18] cxl: Rename some bare-metal specific functions

Excerpts from Frederic Barrat's message of 2016-02-24 03:21:46 +1100: > Rename a few functions, changing the 'cxl_' prefix to either > 'cxl_pci_' or 'cxl_native_', to make clear that the implementation is > bare-metal specific. Thanks, that's a clearer commit message now. Acked-by: Ian Munsie

Re: [PATCH v5 14/18] cxl: Support to flash a new image on the adapter from a guest

(Dangit! My email client crashed and I lost the response I was typing!) @mpe I'd still like it if you weighed in on this one. It's looking pretty good to me now aside from one pointer used in structure passed to the new ioctl (and once that is addressed you may consider this Acked-By: me), but

[PATCH v3 8/8] powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel

From: Torsten Duwe Firstly we add logic to Kconfig to allow a user to choose if they want mprofile-kernel. This has to be user-selectable because only some current toolchains support it. If we enabled it unconditionally we would prevent some users from building the kernel entirely.

[PATCH v3 7/8] powerpc/ftrace: Add support for -mprofile-kernel ftrace ABI

From: Torsten Duwe The gcc switch -mprofile-kernel defines a new ABI for calling _mcount() very early in the function with minimal overhead. Although mprofile-kernel has been available since GCC 3.4, there were bugs which were only fixed recently. Currently it is known to work in

[PATCH v3 6/8] powerpc/ftrace: Use $(CC_FLAGS_FTRACE) when disabling ftrace

From: Torsten Duwe Rather than open-coding -pg whereever we want to disable ftrace, use the existing $(CC_FLAGS_FTRACE) variable. This has the advantage that it will work in future when we use a different set of flags to enable ftrace. Signed-off-by: Torsten Duwe

[PATCH v3 5/8] powerpc/ftrace: Use generic ftrace_modify_all_code()

From: Torsten Duwe Convert powerpc's arch_ftrace_update_code() from its own version to use the generic default functionality (without stop_machine -- our instructions are properly aligned and the replacements atomic). With this we gain error checking and the much-needed

[PATCH v3 4/8] powerpc/module: Create a special stub for ftrace_caller()

In order to support the new -mprofile-kernel ABI, we need to be able to call from the module back to ftrace_caller() (in the kernel) without using the module's r2. That is because the function in this module which is calling ftrace_caller() may not have setup r2, if it doesn't otherwise need it

[PATCH v3 3/8] powerpc/module: Mark module stubs with a magic value

When a module is loaded, calls out to the kernel go via a stub which is generated at runtime. One of these stubs is used to call _mcount(), which is the default target of tracing calls generated by the compiler with -pg. If dynamic ftrace is enabled (which it typically is), another stub is used

[PATCH v3 2/8] powerpc/module: Only try to generate the ftrace_caller() stub once

Currently we generate the module stub for ftrace_caller() at the bottom of apply_relocate_add(). However apply_relocate_add() is potentially called more than once per module, which means we will try to generate the ftrace_caller() stub multiple times. Although the current code deals with that

[PATCH v3 1/8] powerpc: Create a helper for getting the kernel toc value

Move the logic to work out the kernel toc pointer into a header. This is a good cleanup, and also means we can use it elsewhere in future. Reviewed-by: Kamalesh Babulal Reviewed-by: Torsten Duwe Signed-off-by: Michael Ellerman ---

Re: [PATCH v5 11/18] cxl: Separate bare-metal fields in adapter and AFU data structures

Excerpts from Frederic Barrat's message of 2016-02-24 03:21:52 +1100: > static int pci_init_afu(struct cxl *adapter, int slice, struct pci_dev *dev) > { > struct cxl_afu *afu; > -int rc; > +int rc = -ENOMEM; > > afu = cxl_alloc_afu(adapter, slice); > if (!afu) >

Re: [PATCH v5 10/18] cxl: New hcalls to support cxl adapters

> +#define H_CONTROL_CA_FUNCTION_SUSPEND_PROCESS 2 /* suspend a process > from being executed */ > +#define H_CONTROL_CA_FUNCTION_RESUME_PROCESS 3 /* resume a process > to be executed */ Thanks for fixing that :) > +static char *afu_op_names[] = { ... Much nicer, thanks :) >

Re: [PATCH v5 03/18] cxl: Define process problem state area at attach time only

Thanks for addressing my comments on this one - looks good :) Acked-by: Ian Munsie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH V2] powerpc/mm: Move hash page table related functions to pgtable-hash64.c

This moves kernel page mapping, page table cache init and vmemmap routines to hash64 file. For hash we don't create linux page table entries for linear mapping and having then in a separate file like pgtable-hash64.c helps. This also help in adding radix routines later. Signed-off-by: Aneesh

[RFC 16/18] powerpc/kvm: HPT resizing stub implementation

This patch adds a stub (always failing) implementation of the hypercalls for the HPT resizing PAPR extension. For now we include a hack which makes it safe for qemu to call ENABLE_HCALL on these hypercalls, although it will have no effect. That should go away once the PAPR change is formalized

[RFC 18/18] powerpc/kvm: Outline of HPT resizing implementation

This adds an outline (not yet working) of an implementation for the HPT resizing PAPR extension. Specifically it adds the work function which will see through the resizing workflow, and adds in the synchronization between this and the HPT resizing hypercalls. Signed-off-by: David Gibson

[RFC 13/18] powerpc/kvm: Don't store values derivable from HPT order

Currently the kvm_hpt_info structure stores the hashed page table's order, and also the number of HPTEs it contains and a mask for its size. The last two can be easily derived from the order, so remove them and just calculate them as necessary with a couple of helper inlines. Signed-off-by:

[RFC 12/18] powerpc/kvm: Gather HPT related variables into sub-structure

Currently, the powerpc kvm_arch structure contains a number of variables tracking the state of the guest's hashed page table (HPT) in KVM HV. This patch gathers them all together into a single kvm_hpt_info substructure. This makes life more convenient for the upcoming HPT resizing implementation.

[RFC 14/18] powerpc/kvm: Split HPT allocation from activation

Currently, kvmppc_alloc_hpt() both allocates a new hashed page table (HPT) and sets it up as the active page table for a VM. For the upcoming HPT resize implementation we're going to want to allocate HPTs separately from activating them. So, split the allocation itself out into

[RFC 17/18] powerpc/kvm: Advertise availablity of HPT resizing on KVM HV

This updates the KVM_CAP_SPAPR_RESIZE_HPT capability to advertise the presence of in-kernel HPT resizing on KVM HV. In fact the HPT resizing isn't fully implemented, but this allows us to experiment with what's there. Signed-off-by: David Gibson ---

[RFC 15/18] powerpc/kvm: Allow KVM_PPC_ALLOCATE_HTAB ioctl() to change HPT size

The KVM_PPC_ALLOCATE_HTAB ioctl() is used to set the size of hashed page table (HPT) that userspace expects a guest VM to have, and is also used to clear that HPT when necessary (e.g. guest reboot). At present, once the ioctl() is called for the first time, the HPT size can never be changed

[RFC 09/18] powerpc/kvm: Corectly report KVM_CAP_PPC_ALLOC_HTAB

At present KVM on powerpc always reports KVM_CAP_PPC_ALLOC_HTAB as enabled. However, the ioctl() it advertises (KVM_PPC_ALLOCATE_HTAB) only actually works on KVM HV. On KVM PR it will fail with ENOTTY. qemu already has a workaround for this, so it's not breaking things in practice, but it would

[RFC 08/18] pseries: Automatically resize HPT for memory hot add/remove

We've now implemented code in the pseries platform to use the new PAPR interface to allow resizing the hash page table (HPT) at runtime. This patch uses that interface to automatically attempt to resize the HPT when memory is hot added or removed. This tries to always keep the HPT at a

[RFC 06/18] pseries: Add support for hash table resizing

This adds support for using experimental hypercalls to change the size of the main hash page table while running as a PAPR guest. For now these hypercalls are only in experimental qemu versions. The interface is two part: first H_RESIZE_HPT_PREPARE is used to allocate and prepare the new hash

[RFC 07/18] pseries: Advertise HPT resizing support via CAS

The hypervisor needs to know a guest is capable of using the HPT resizing PAPR extension in order to make full advantage of it for memory hotplug. If the hypervisor knows the guest is HPT resize aware, it can size the initial HPT based on the initial guest RAM size, relying on the guest to resize

[RFC 11/18] powerpc/kvm: Rename kvm_alloc_hpt() for clarity

The difference between kvm_alloc_hpt() and kvmppc_alloc_hpt() is not at all obvious from the name. In practice kvmppc_alloc_hpt() allocates an HPT by whatever means, and clals kvm_alloc_hpt() which will attempt to allocate it with CMA only. To make this less confusing, rename kvm_alloc_hpt() to

[RFC 10/18] powerpc/kvm: Add capability flag for hashed page table resizing

This adds a new powerpc-specific KVM_CAP_SPAPR_RESIZE_HPT capability to advertise whether KVM is capable of handling the PAPR extensions for resizing the hashed page table during guest runtime. At present, HPT resizing is possible with KVM PR without kernel modification, since the HPT is managed

[RFC 03/18] powerpc/mm: Clean up memory hotplug failure paths

This makes a number of cleanups to handling of mapping failures during memory hotplug on Power: For errors creating the linear mapping for the hot-added region: * This is now reported with EFAULT which is more appropriate than the previous EINVAL (the failure is unlikely to be related to

[RFC 01/18] powerpc/mm: Clean up error handling for htab_remove_mapping

Currently, the only error that htab_remove_mapping() can report is -EINVAL, if removal of bolted HPTEs isn't implemeted for this platform. We make a few clean ups to the handling of this: * EINVAL isn't really the right code - there's nothing wrong with the function's arguments - use ENODEV

[RFC 02/18] powerpc/mm: Handle removing maybe-present bolted HPTEs

At the moment the hpte_removebolted callback in ppc_md returns void and will BUG_ON() if the hpte it's asked to remove doesn't exist in the first place. This is awkward for the case of cleaning up a mapping which was partially made before failing. So, we add a return value to hpte_removebolted,

[RFC 05/18] pseries: Add hypercall wrappers for hash page table resizing

This adds the hypercall numbers and wrapper functions for the hash page table resizing hypercalls. These are experimental "platform specific" values for now, until we have a formal PAPR update. It also adds a new firmware feature flag to track the presence of the HPT resizing calls.

[RFC 00/18] PAPR HPT resizing, guest side & host side preliminaries

This is an incomplete implementation of the kernel parts of the PAPR hashed page table (HPT) resizing extension. It contains a complete guest-side implementation - or as complete as it can be until we have a final PAPR change. It also contains preliminary patches towards a host side

[RFC 04/18] powerpc/mm: Split hash page table sizing heuristic into a helper

htab_get_table_size() either retrieve the size of the hash page table (HPT) from the device tree - if the HPT size is determined by firmware - or uses a heuristic to determine a good size based on RAM size if the kernel is responsible for allocating the HPT. To support a PAPR extension allowing

Re: Problems with swapping in v4.5-rc on POWER

On Fri, 26 Feb 2016, Hugh Dickins wrote: > On Thu, 25 Feb 2016, Hugh Dickins wrote: > > On Wed, 24 Feb 2016, Hugh Dickins wrote: > > > On Thu, 25 Feb 2016, Aneesh Kumar K.V wrote: > > > > > > > > Can you test the impact of the merge listed below ?(ie, revert the > > > > merge and see if > > > >

Re: [PATCH 0/2] Tracking user space vDSO remaping

Hi, On 03/20/2015 11:53 AM, Laurent Dufour wrote: > CRIU is recreating the process memory layout by remapping the checkpointee > memory area on top of the current process (criu). This includes remapping > the vDSO to the place it has at checkpoint time. > > However some architectures like

[PATCH RESEND 2/2] drivers: macintosh: rack-meter: fix bogus memsets

Fix bogus memsets pointed out by sparse: linux-v4.3/drivers/macintosh/rack-meter.c:157:15: warning: memset with byte count of 0 linux-v4.3/drivers/macintosh/rack-meter.c:158:15: warning: memset with byte count of 0 Probably "&" is mistyped "*"; use ARRAY_SIZE to make it more safe.

[PATCH RESEND 1/2] drivers: macintosh: rack-meter: limit idle ticks to total ticks

Limit idle ticks to total ticks. This prevents the annoying rackmeter leds fully ON / OFF blinking state that happens on fully idling G5 Xserve systems. Signed-off-by: Aaro Koskinen --- drivers/macintosh/rack-meter.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH] cxl: Ignore probes for virtual afu pci devices

Hi Vaibhav, Looks ok to me. Reviewed-by: fbar...@linux.vnet.ibm.com Fred Le 29/02/2016 06:40, Vaibhav Jain a écrit : Add a check at the beginning of cxl_probe function to ignore virtual pci devices created for each afu registered. This fixes the the errors messages logged about missing CXL

[PATCH] selftests/powerpc: Fix out of bounds access in TM signal test

Gcc helpfully points out that we're accessing past the end of the gprs array: tm-signal-msr-resv.c: In function 'signal_usr1': tm-signal-msr-resv.c:43:37: error: array subscript is above array bounds [-Werror=array-bounds] ucp->uc_mcontext.regs->gpr[PT_MSR] |= (7ULL); We haven't noticed

[RFC PATCH v3 3/3] powerpc/86xx: Introduce and use common dtsi

Signed-off-by: Alessio Igor Bogani --- arch/powerpc/boot/dts/fsl/gef_ppc9a.dts| 258 +++-- arch/powerpc/boot/dts/fsl/gef_sbc310.dts | 246 +++- arch/powerpc/boot/dts/fsl/gef_sbc610.dts | 258 +++--

[RFC PATCH v3 2/3] powerpc/86xx: Update device tree

Avoid duplication of the interrupt-parent, migrate to 4 interrupt-cells and set the right clock-frequency for pcie (100 Mhz). Signed-off-by: Alessio Igor Bogani --- arch/powerpc/boot/dts/fsl/gef_ppc9a.dts| 73

[RFC PATCH v3 1/3] powerpc/86xx: Move dts files to fsl directory

Signed-off-by: Alessio Igor Bogani --- v2 -> v3 Use appropriate git format-patch flag "-M" to detect renames v1 -> v2 Address suggestion made by Scott Wood Split the second patch in two Don't remove "fsl,mpic" which it is required for 4-cell

Re: [RFC] powerpc/mm: Add validation for platform reserved memory ranges

On Wed, 2016-02-03 at 08:46:12 UTC, Anshuman Khandual wrote: > For partition running on PHYP, there can be a adjunct partition > which shares the virtual address range with the operating system. > Virtual address ranges which can be used by the adjunct partition > are communicated with virtual

Re: hw_breakpoint: Fix Oops at destroying hw_breakpoint event on powerpc

On Wed, Mar 02, 2016 at 10:53:24PM +1100, Michael Ellerman wrote: > Peterz, acme, do you guys want to take this? Or should I? I'm not too happy its touching event->ctx at all. It really should not be doing that. ___ Linuxppc-dev mailing list

Re: hw_breakpoint: Fix Oops at destroying hw_breakpoint event on powerpc

Hi Ravi, On Wed, 2016-02-03 at 09:55:17 UTC, Ravi Bangoria wrote: > At a time of destroying hw_breakpoint event, kernel ends up with Oops. > Here is the sample output from 4.5.0-rc6 kernel. It's nice to trim the oops a bit, the time stamps aren't useful. And the full GPRs is probably not useful

Re: [PATCH] hw_breakpoint: Fix Oops at destroying hw_breakpoint event on powerpc

On Wed, Mar 02, 2016 at 03:25:17PM +0530, Ravi Bangoria wrote: > At a time of destroying hw_breakpoint event, kernel ends up with Oops. > Here is the sample output from 4.5.0-rc6 kernel. > Call chain: > > hw_breakpoint_event_init() > bp->destroy = bp_perf_event_destroy; > > do_exit() >

[RFC PATCH v2 3/3] powerpc/86xx: Introduce and use common dtsi

Signed-off-by: Alessio Igor Bogani --- arch/powerpc/boot/dts/fsl/gef_ppc9a.dts| 258 +++-- arch/powerpc/boot/dts/fsl/gef_sbc310.dts | 246 +++- arch/powerpc/boot/dts/fsl/gef_sbc610.dts | 258 +++--

[RFC PATCH v2 2/3] powerpc/86xx: Update device tree

Avoid duplication of the interrupt-parent, migrate to 4 interrupt-cells and set the right clock-frequency for pcie (100 Mhz). Signed-off-by: Alessio Igor Bogani --- arch/powerpc/boot/dts/fsl/gef_ppc9a.dts| 73

[PATCH] hw_breakpoint: Fix Oops at destroying hw_breakpoint event on powerpc

At a time of destroying hw_breakpoint event, kernel ends up with Oops. Here is the sample output from 4.5.0-rc6 kernel. [ 450.708568] Unable to handle kernel paging request for data at address 0x0c07 [ 450.708684] Faulting instruction address: 0xc00291d0 [ 450.708750] Oops:

Re: [PATCH 1/6] rtc: generic: allow building on all architectures

On Wed, Mar 2, 2016 at 10:28 AM, Andreas Schwab wrote: > Geert Uytterhoeven writes: > >>> +#else >>> +#define generic_rtc_ops *(struct rtc_class_ops*)NULL >>> +#endif >>> >>> static int __init generic_rtc_probe(struct platform_device *dev) >>> { >>>

Re: [PATCH 1/6] rtc: generic: allow building on all architectures

Geert Uytterhoeven writes: >> +#else >> +#define generic_rtc_ops *(struct rtc_class_ops*)NULL >> +#endif >> >> static int __init generic_rtc_probe(struct platform_device *dev) >> { >> struct rtc_device *rtc; >> + const struct rtc_class_ops *ops; >> + >> +

Re: [PATCH 1/6] rtc: generic: allow building on all architectures

On Wednesday 02 March 2016 09:57:27 Geert Uytterhoeven wrote: > > @@ -33,13 +35,21 @@ static const struct rtc_class_ops generic_rtc_ops = { > > .read_time = generic_get_time, > > .set_time = generic_set_time, > > }; > > +#else > > +#define generic_rtc_ops *(struct

Re: [PATCH V10 18/28] selftests, powerpc: Add ptrace tests for GPR/FPR registers

On 03/02/2016 06:10 AM, Cyril Bur wrote: > On Tue, 16 Feb 2016 14:29:48 +0530 > Anshuman Khandual wrote: > >> > This patch adds ptrace interface test for GPR/FPR registers. >> > This adds ptrace interface based helper functions related to >> > GPR/FPR access and some

Re: [PATCH V10 17/28] selftests, powerpc: Add ptrace tests for EBB

On 03/02/2016 06:02 AM, Cyril Bur wrote: > On Tue, 16 Feb 2016 14:29:47 +0530 > Anshuman Khandual wrote: > >> This patch adds ptrace interface test for EBB specific >> registers. This also adds some generic ptrace interface >> based helper functions to be used by

Re: [PATCH 1/6] rtc: generic: allow building on all architectures

Hi Arnd, On Tue, Mar 1, 2016 at 5:59 PM, Arnd Bergmann wrote: > There are four architectures using this driver, but since we can > build it with COMPILE_TEST, we should try dealing with the absence > of the asm/rtc.h header file, to avoid getting a build error: > >

[RFC] powerpc/mm: Add validation for platform reserved memory ranges

For partition running on PHYP, there can be a adjunct partition which shares the virtual address range with the operating system. Virtual address ranges which can be used by the adjunct partition are communicated with virtual device node of the device tree with a property known as