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 "ibm,reserved-vir
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:
>
> drivers/rtc/rtc-generic.c:12:21
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 other patches later
>> on in the
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 assembly helper functions rel
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 rtc_class_ops*)NU
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;
>> +
>> + ops = dev_get_platd
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)
>>> {
>>> struct rtc_device *rtc;
>>> + c
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: K
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
arch/powerpc/boot/dts/fsl/gef_sbc310.dts | 79 +
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 +++--
arch/powerpc/boot/dts/fsl/mpc86
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()
>
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 i
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
Linuxppc-dev
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 devi
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
interrupt speci
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
arch/powerpc/boot/dts/fsl/gef_sbc310.dts | 79 +
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 +++--
arch/powerpc/boot/dts/fsl/mpc86
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
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 v
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 a/drivers/macintosh/rack-mete
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.
Signed-off-b
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 powerpc
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
> > > > w
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
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
implementatio
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.
Signed-off-b
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, a
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 i
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 the
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 w
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 k
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
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 tab
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 reasonable
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 b
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 therea
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
---
arch/powerpc/kvm/powerpc.c | 5 -
1 file
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 kvmppc_allocate_hp
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.
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: David
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
---
arc
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 an
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 Kumar
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
> +#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 :)
>
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)
>
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
---
arch/powerpc/include/asm/sections.h | 12
arch/pow
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 corr
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 to
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 (ie
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 function_trace_op
handlin
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
Signed-off-by: Michael Ellerma
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
GCC 4.9, 5 and
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.
Arguably it w
(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 sin
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
_
> +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 mailing list
Linuxppc-dev@
Acked-by: Ian Munsie
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
> +/*
> + * 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.
> +
> +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
Linuxppc-dev@lists.ozlabs.org
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 merg
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 introduced in v4.5-rc1.
* 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 Duwe
> Signed-off-by: Michael Ellerman
For the pat
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
https://patchwork.ozlabs.org/patch/58
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:
with patch vs without patch: 10
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
with 24TB memory which allocat
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
Signed-off-by: Li Zhang
---
67 matches
Mail list logo
