Right, this also depends on
69b907297f4e list: Add lockless list traversal primitives
On 01/21/2016 06:56 PM, kbuild test robot wrote:
Hi Alexey,
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.4 next-20160121]
[if your patch is applied to the wrong git tree, please
This adds a capability number for 64-bit TCE tables support.
Signed-off-by: Alexey Kardashevskiy
---
include/uapi/linux/kvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 9da9051..8ce5f64 100644
--- a/include/uapi/linux/kvm.h
+++ b
The existing KVM_CREATE_SPAPR_TCE only supports 32bit windows which is not
enough for directly mapped windows as the guest can get more than 4GB.
This adds KVM_CREATE_SPAPR_TCE_64 ioctl and advertises it
via KVM_CAP_SPAPR_TCE_64 capability.
Since 64bit windows are to support Dynamic DMA windows (
This enables userspace view of TCE tables to start from non-zero offset
on a bus. This will be used for huge DMA windows.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/kvm_host.h | 1 +
arch/powerpc/kvm/book3s_64_vio_hv.c | 6 --
2 files changed, 5 insertions(+), 2 deletio
At the moment the kvmppc_spapr_tce_table struct can only describe
4GB windows and handle fixed size (4K) pages. Dynamic DMA windows
support more so these limits need to be extended.
This replaces window_size (in bytes, 4GB max) with page_shift (32bit)
and size (64bit, in pages).
This should cause
This extends the existing H_PUT_TCE/etc in-kernel acceleration to 64bit
DMA windows mapped at addresses other than zero. This accelerates huge
DMA windows which pseries guests create using Dynamic DMA window (DDW) API.
This does not affect VFIO yet.
This depends on:
69b907297f4e list: Add lockle
On 21 January 2016 at 07:45, Ard Biesheuvel wrote:
> On 21 January 2016 at 06:10, Rusty Russell wrote:
>> Ard Biesheuvel writes:
>>> This implements text-relative kallsyms address tables. This was developed
>>> as part of my series to implement KASLR/CONFIG_RELOCATABLE for arm64, but
>>> I think
On Wednesday 20 January 2016 04:08 PM, Michael Ellerman wrote:
Hi Anju,
On Mon, 2016-01-11 at 15:58 +0530, Anju T wrote:
The enum definition assigns an 'id' to each register in "struct pt_regs"
of arch/powerpc. The order of these values in the enum definition are
based on the corresponding mac
On Wed, 20 Jan 2016, Michael Ellerman wrote:
> For me the series doesn't even boot, even with livepatching disabled.
Could you please post config and dmesg from that non-booting kernel?
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
In POWER8, OCC(On-Chip-Controller) can throttle the frequency of the
CPU when the chip crosses its thermal and power limits. Currently,
powernv-cpufreq driver detects and reports this event as a console
message. Some machines may not sustain the max turbo frequency in all
conditions and can be thro
In the kworker_thread powernv_cpufreq_work_fn(), we can end up
sending an IPI to a cpu going offline. This is a rare corner case
which is fixed using {get/put}_online_cpus(). Along with this fix,
this patch adds changes to do oneshot cpumask_{clear/and} operation.
Suggested-by: Shreyas B Prabhu
S
cpu_to_chip_id() does a DT walk through to find out the chip id by
taking a contended device tree lock. This adds an unnecessary overhead
in a hot path. So instead of calling cpu_to_chip_id() everytime cache
the chip ids for all cores in the array 'core_to_chip_map' and use it
in the hotpath.
Repo
This patch adds the powernv_throttle tracepoint to trace the CPU
frequency throttling event, which is used by the powernv-cpufreq
driver in POWER8.
Signed-off-by: Shilpasri G Bhat
Reviewed-by: Gautham R. Shenoy
CC: Ingo Molnar
CC: Steven Rostedt
---
No changes since v2.
include/trace/events/
Currently we use printk message to notify the throttle event. But this
can flood the console if the cpu is throttled frequently. So replace the
printk with the tracepoint to notify the throttle event. And also events
like throttle below nominal frequency and OCC_RESET are reduced to
pr_warn/pr_warn
Create sysfs attributes to export throttle information in
/sys/devices/system/cpu/cpufreq/chipN. The newly added sysfs files are as
follows:
1)/sys/devices/system/cpu/cpufreq/chip0/throttle_frequencies
This gives the throttle stats for each of the available frequencies.
The throttle stat of a
Am Donnerstag, 21. Januar 2016, 11:25:27 schrieb Michael Ellerman:
> There's no reason I'm aware of that the VMX copy loop shouldn't work on
> PPC970. And in fact it seems to boot and generally be happy.
does the same also hold for Cell? Maybe there are even more optimizations
which can be copied
Hi mpe,
On Wednesday 20 January 2016 04:16 PM, Michael Ellerman wrote:
On Mon, 2016-01-11 at 15:58 +0530, Anju T wrote:
diff --git a/tools/perf/arch/powerpc/include/perf_regs.h
b/tools/perf/arch/powerpc/include/perf_regs.h
new file mode 100644
index 000..93080f5
--- /dev/null
+++ b/tools/pe
Hi mpe,
On Wednesday 20 January 2016 04:10 PM, Michael Ellerman wrote:
On Mon, 2016-01-11 at 15:58 +0530, Anju T wrote:
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9a7057e..c4ce60d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -119,6 +119,7 @@ config PPC
Hi Shilpasri,
[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.4 next-20160121]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Shilpasri-G-Bhat/cpufreq-powernv-Redesign
On Thu, 2016-01-21 at 10:51 +0100, Marc Dietrich wrote:
> Am Donnerstag, 21. Januar 2016, 11:25:27 schrieb Michael Ellerman:
> > There's no reason I'm aware of that the VMX copy loop shouldn't work on
> > PPC970. And in fact it seems to boot and generally be happy.
>
> does the same also hold fo
Similar to how relative extables are implemented, it is possible to emit
the kallsyms table in such a way that it contains offsets relative to some
anchor point in the kernel image rather than absolute addresses. The benefit
is that such table entries are no longer subject to dynamic relocation whe
On 21 January 2016 at 11:48, Ard Biesheuvel wrote:
> Similar to how relative extables are implemented, it is possible to emit
> the kallsyms table in such a way that it contains offsets relative to some
> anchor point in the kernel image rather than absolute addresses. The benefit
> is that such t
On Wed 2016-01-20 10:48:30, Petr Mladek wrote:
> I did the testing on PPC64LE with a kernel based on 4.4.0-rc8
> using the attached config. I used the following stuff:
Ah, I forgot to attach it. Also it is rahter big. Please,
find it at http://pastebin.com/tzJ3mdUd
Best Regards,
Petr
On Thu, 2016-01-21 at 10:33 +0100, Jiri Kosina wrote:
> On Wed, 20 Jan 2016, Michael Ellerman wrote:
>
> > For me the series doesn't even boot, even with livepatching disabled.
>
> Could you please post config and dmesg from that non-booting kernel?
Sorry been busy.
There is no dmesg :)
It get
On Thu, Jan 21, 2016 at 11:54:51PM +1100, Michael Ellerman wrote:
> There is no dmesg :)
>
> It gets stuck in early_setup() before the console is even found.
Confirmed.
| Device tree struct 0x014b -> 0x014c
| Quiescing Open Firmware ...
| Booting Linux via __start() ...
a
On Thu, Jan 21, 2016 at 04:06:33PM +0100, Torsten Duwe wrote:
> mcount call sites looks normal on first sight...
Not quite.
LR is not saved on the stack before the call.
Argh!
Petr, this looks like 12 bytes offset for gcc-6.
I think I can work around the rest.
Torsten
__
With commit 90a545e9 (restrict /dev/mem to idle io memory ranges) mapping
rtas_rmo_buf from user space is failing. Hence we are not able to make
RTAS syscall.
This patch calls page_is_rtas_user_buf before calling iomem_is_exclusive
in devmem_is_allowed(). This will allow user space to map rtas_rm
On Thu, Jan 21, 2016 at 8:15 AM, Vasant Hegde
wrote:
> With commit 90a545e9 (restrict /dev/mem to idle io memory ranges) mapping
> rtas_rmo_buf from user space is failing. Hence we are not able to make
> RTAS syscall.
>
> This patch calls page_is_rtas_user_buf before calling iomem_is_exclusive
> i
Similar to how relative extables are implemented, it is possible to emit
the kallsyms table in such a way that it contains offsets relative to some
anchor point in the kernel image rather than absolute addresses. The benefit
is that such table entries are no longer subject to dynamic relocation whe
Le 20/01/2016 03:20, Michael Neuling a écrit :
The only thing I'm a bit concerned about is are we going to end up
duplicating a lot of the linux PCI API, but I guess we are only going
to do this for things the papr HCALL interface mimics.
There are actually very few operations we can do on th
On Tue, Jan 19, 2016 at 05:00:35AM +, Shaohui Xie wrote:
> > -Original Message-
> > From: Andrew Lunn [mailto:and...@lunn.ch]
> > Sent: Monday, January 18, 2016 11:15 PM
> > To: Shaohui Xie
> > Cc: Sebastian Hesselbarth; Florian Fainelli; shh@gmail.com;
> > devicet...@vger.kernel.or
On Thu, 21 Jan 2016, Torsten Duwe wrote:
> > mcount call sites looks normal on first sight...
>
> Not quite.
> LR is not saved on the stack before the call.
> Argh!
>
> Petr, this looks like 12 bytes offset for gcc-6.
> I think I can work around the rest.
Are we sure that gcc is doing the right
On Thu, Jan 21, 2016 at 10:29:13PM +0100, Jiri Kosina wrote:
> On Thu, 21 Jan 2016, Torsten Duwe wrote:
>
> > > mcount call sites looks normal on first sight...
> >
> > Not quite.
> > LR is not saved on the stack before the call.
> > Argh!
> >
> > Petr, this looks like 12 bytes offset for gcc-6.
On Thu, 21 Jan 2016 18:19:43 +0100 Ard Biesheuvel
wrote:
> Similar to how relative extables are implemented, it is possible to emit
> the kallsyms table in such a way that it contains offsets relative to some
> anchor point in the kernel image rather than absolute addresses. The benefit
> is tha
On Thu, Jan 21, 2016 at 2:50 PM, Andrew Morton
wrote:
> On Thu, 21 Jan 2016 18:19:43 +0100 Ard Biesheuvel
> wrote:
>
>> Similar to how relative extables are implemented, it is possible to emit
>> the kallsyms table in such a way that it contains offsets relative to some
>> anchor point in the ke
On Thu, 21 Jan 2016 14:55:00 -0800 Kees Cook wrote:
> IIUC, this means that the relocation work done after decompression now
> doesn't have to do relocation updates for all these values, which
> means a smaller relocation table as well.
Makes sense, thanks. I altered the changelog
: Similar to
On Thu, 2016-01-21 at 19:48 +0100, Frederic Barrat wrote:
>
> Le 20/01/2016 03:20, Michael Neuling a écrit :
> > The only thing I'm a bit concerned about is are we going to end up
> > duplicating a lot of the linux PCI API, but I guess we are only going
> > to do this for things the papr HCALL int
On Thu, Jan 21, 2016 at 06:39:32PM +1100, Alexey Kardashevskiy wrote:
> This reworks the existing H_PUT_TCE/H_GET_TCE handlers to have following
> patches applied nicer.
>
> This moves the ioba boundaries check to a helper and adds a check for
> least bits which have to be zeros.
>
> The patch is
On 01/22/2016 11:42 AM, David Gibson wrote:
On Thu, Jan 21, 2016 at 06:39:32PM +1100, Alexey Kardashevskiy wrote:
This reworks the existing H_PUT_TCE/H_GET_TCE handlers to have following
patches applied nicer.
This moves the ioba boundaries check to a helper and adds a check for
least bits whic
On Thu, 2016-01-21 at 14:55 -0800, Kees Cook wrote:
> On Thu, Jan 21, 2016 at 2:50 PM, Andrew Morton
> wrote:
> > On Thu, 21 Jan 2016 18:19:43 +0100 Ard Biesheuvel
> > wrote:
> >
> > > Similar to how relative extables are implemented, it is possible to emit
> > > the kallsyms table in such a wa
On Thu, 2016-01-21 at 21:45 +0530, Vasant Hegde wrote:
> With commit 90a545e9 (restrict /dev/mem to idle io memory ranges) mapping
> rtas_rmo_buf from user space is failing. Hence we are not able to make
> RTAS syscall.
>
> This patch calls page_is_rtas_user_buf before calling iomem_is_exclusive
On Thu, Jan 21, 2016 at 03:08:59PM +0530, Shilpasri G Bhat wrote:
> Signed-off-by: Shilpasri G Bhat
Reviewed-by: Gautham R. Shenoy
--
Thanks and Regards
gautham.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/list
On 01/22/2016 10:59 AM, Michael Ellerman wrote:
> On Thu, 2016-01-21 at 21:45 +0530, Vasant Hegde wrote:
>
>> With commit 90a545e9 (restrict /dev/mem to idle io memory ranges) mapping
>> rtas_rmo_buf from user space is failing. Hence we are not able to make
>> RTAS syscall.
>>
>> This patch calls
Recent change 03a76b60 "vfio: Include No-IOMMU mode" disabled VFIO
on systems which do not implement iommu_ops for the PCI bus even though
there is an VFIO IOMMU driver for it such as SPAPR TCE driver for
PPC64/powernv platform.
This moves iommu_present() call under #ifdef CONFIG_VFIO_NOIOMMU as
i
On 22 January 2016 at 04:44, Michael Ellerman wrote:
> On Thu, 2016-01-21 at 14:55 -0800, Kees Cook wrote:
>> On Thu, Jan 21, 2016 at 2:50 PM, Andrew Morton
>> wrote:
>> > On Thu, 21 Jan 2016 18:19:43 +0100 Ard Biesheuvel
>> > wrote:
>> >
>> > > Similar to how relative extables are implemented,
On 01/22/2016 05:34 PM, Alexey Kardashevskiy wrote:
Recent change 03a76b60 "vfio: Include No-IOMMU mode" disabled VFIO
on systems which do not implement iommu_ops for the PCI bus even though
there is an VFIO IOMMU driver for it such as SPAPR TCE driver for
PPC64/powernv platform.
This moves iomm
In POWER8, OCC(On-Chip-Controller) can throttle the frequency of the
CPU when the chip crosses its thermal and power limits. Currently,
powernv-cpufreq driver detects and reports this event as a console
message. Some machines may not sustain the max turbo frequency in all
conditions and can be thro
In the kworker_thread powernv_cpufreq_work_fn(), we can end up
sending an IPI to a cpu going offline. This is a rare corner case
which is fixed using {get/put}_online_cpus(). Along with this fix,
this patch adds changes to do oneshot cpumask_{clear/and} operation.
Suggested-by: Shreyas B Prabhu
S
cpu_to_chip_id() does a DT walk through to find out the chip id by
taking a contended device tree lock. This adds an unnecessary overhead
in a hot path. So instead of calling cpu_to_chip_id() everytime cache
the chip ids for all cores in the array 'core_to_chip_map' and use it
in the hotpath.
Repo
Currently we use printk message to notify the throttle event. But this
can flood the console if the cpu is throttled frequently. So replace the
printk with the tracepoint to notify the throttle event. And also events
like throttle below nominal frequency and OCC_RESET are reduced to
pr_warn/pr_warn
This patch adds the powernv_throttle tracepoint to trace the CPU
frequency throttling event, which is used by the powernv-cpufreq
driver in POWER8.
Signed-off-by: Shilpasri G Bhat
Reviewed-by: Gautham R. Shenoy
CC: Ingo Molnar
CC: Steven Rostedt
---
No changes since v2.
include/trace/events/
Create sysfs attributes to export throttle information in
/sys/devices/system/cpu/cpufreq/chipN. The newly added sysfs files are as
follows:
1)/sys/devices/system/cpu/cpufreq/chip0/throttle_frequencies
This gives the throttle stats for each of the available frequencies.
The throttle stat of a
52 matches
Mail list logo
