* Poll: Rebasing of powerpc-next
From: Benjamin Herrenschmidt @ 2009-08-15 22:20 UTC (permalink / raw)
To: linuxppc-dev list
Hi !
I'd like to rebase powerpc-next ... a few bugs have been found that it
would be nice to fix in the original patch rather than introducing a
bisection breakage, and Kumar also just noticed a potentially misleading
error in a commit message from his tree.
So who is not ok with me doing that tomorrow or tuesday ?
Cheers,
Ben.
^ permalink raw reply
* Re: ARM clock API to PowerPC
From: Grant Likely @ 2009-08-16 5:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree-discuss, John Jacques, linuxppc-dev list, Torez Smith,
Guennadi Liakhovetski, Russell King
In-Reply-To: <1250374683.24143.69.camel@pasglop>
On Sat, Aug 15, 2009 at 4:18 PM, Benjamin
Herrenschmidt<benh@kernel.crashing.org> wrote:
> For ppc we really don't have much of a choice here anyway because we
> support multiple platforms compiled in the same kernel as long as they
> have a CPU core that's the same overall family, and that can be very
> wide. For example, 440-type cores can exist in all sort of IBM/AMCC
> cores, but also Xilinx FPGAs, and when you start saying FPGA the
> possibilities go wild :-)
Yes, exactly! In fact, FPGAs are somewhat nicer in that only the
hardware actually needed is present on the running system (fewer data
instances), but the flip side is that the set of instances changes at
the whim of the FPGA engineer. Static definition isn't an option
unless you want to change the platform source code for each new FPGA
bistream revision.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Dipankar Sarma @ 2009-08-16 18:26 UTC (permalink / raw)
To: Pavel Machek
Cc: Brown, Len, Darrick J. Wong, Peter Zijlstra, Gautham R Shenoy,
linux-kernel@vger.kernel.org, Rafael J. Wysocki,
Pallipadi, Venkatesh, Li, Shaohua, Ingo Molnar,
linuxppc-dev@lists.ozlabs.org, Len Brown
In-Reply-To: <20090814113021.GL32418@elf.ucw.cz>
On Fri, Aug 14, 2009 at 01:30:21PM +0200, Pavel Machek wrote:
> >
> > It depends on the hypervisor implementation. On pseries (powerpc)
> > hypervisor, for example, they are different. By offlining a vcpu
> > (and in turn shutting a cpu), you will actually create a configuration
> > change in the VM that is visible to other systems management tools
> > which may not be what the system administrator wanted. Ideally,
> > we would like to distinguish between these two states.
> >
> > Hope that suffices as an example.
>
> So... you have something like "physically pulling out hotplug cpu" on
> powerpc.
If any system can do physical unplug, then it should do "offline"
with configuration changes reflected in the hypervisor and
other system configuration software.
> But maybe it is useful to take already offline cpus (from linux side),
> and make that visible to hypervisor, too.
>
> So maybe something like "echo 1 > /sys/devices/system/cpu/cpu1/unplug"
> would be more useful for hypervisor case?
On pseries, we do an RTAS call ("stop-cpu") which effectively permantently
de-allocates it from the VM hands over the control to hypervisor. The
hypervisors may do whatever it wants including allocating it to
another VM. Once gone, the original VM may not get it back depending
on the situation.
The point I am making is that we may not always want to *release*
the CPU to hypervisor and induce a configuration change. That needs
to be reflected by extending the existing user interface - hence
the proposal for - /sys/devices/system/cpu/cpu<#>/state and
/sys/devices/system/cpu/cpu<#>/available_states. It allows
ceding to hypervisor without de-allocating. It is a minor
extension of the existing interface keeping backwards compatibility
and platforms can allow what make sense.
Thanks
Dipankar
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Balbir Singh @ 2009-08-16 19:44 UTC (permalink / raw)
To: Dipankar Sarma
Cc: Brown, Len, Darrick J. Wong, Peter Zijlstra, Gautham R Shenoy,
linux-kernel@vger.kernel.org, Rafael J. Wysocki, Pavel Machek,
Pallipadi, Venkatesh, Li, Shaohua, Ingo Molnar,
linuxppc-dev@lists.ozlabs.org, Len Brown
In-Reply-To: <20090816182629.GA31027@in.ibm.com>
* Dipankar Sarma <dipankar@in.ibm.com> [2009-08-16 23:56:29]:
> On Fri, Aug 14, 2009 at 01:30:21PM +0200, Pavel Machek wrote:
> > >
> > > It depends on the hypervisor implementation. On pseries (powerpc)
> > > hypervisor, for example, they are different. By offlining a vcpu
> > > (and in turn shutting a cpu), you will actually create a configuration
> > > change in the VM that is visible to other systems management tools
> > > which may not be what the system administrator wanted. Ideally,
> > > we would like to distinguish between these two states.
> > >
> > > Hope that suffices as an example.
> >
> > So... you have something like "physically pulling out hotplug cpu" on
> > powerpc.
>
> If any system can do physical unplug, then it should do "offline"
> with configuration changes reflected in the hypervisor and
> other system configuration software.
>
> > But maybe it is useful to take already offline cpus (from linux side),
> > and make that visible to hypervisor, too.
> >
> > So maybe something like "echo 1 > /sys/devices/system/cpu/cpu1/unplug"
> > would be more useful for hypervisor case?
>
> On pseries, we do an RTAS call ("stop-cpu") which effectively permantently
> de-allocates it from the VM hands over the control to hypervisor. The
> hypervisors may do whatever it wants including allocating it to
> another VM. Once gone, the original VM may not get it back depending
> on the situation.
>
> The point I am making is that we may not always want to *release*
> the CPU to hypervisor and induce a configuration change. That needs
> to be reflected by extending the existing user interface - hence
> the proposal for - /sys/devices/system/cpu/cpu<#>/state and
> /sys/devices/system/cpu/cpu<#>/available_states. It allows
> ceding to hypervisor without de-allocating. It is a minor
> extension of the existing interface keeping backwards compatibility
> and platforms can allow what make sense.
>
Agreed, I've tried to come with a little ASCII art to depict your
scenairos graphically
+--------+ don't need (offline)
| OS +----------->+------------+
+--+-----+ | hypervisor +-----> Reuse CPU
| | | for something
| | | else
| | | (visible to users)
| | | as resource changed
| +----------- +
V (needed, but can cede)
+------------+
| hypervisor | Don't reuse CPU
| | (CPU ceded)
| | give back to OS
+------------+ when needed.
(Not visible to
users as so resource
binding changed)
--
Balbir
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Peter Zijlstra @ 2009-08-16 21:53 UTC (permalink / raw)
To: balbir
Cc: Brown, Len, Darrick J. Wong, Gautham R Shenoy,
linux-kernel@vger.kernel.org, Rafael J. Wysocki, Pavel Machek,
Pallipadi, Venkatesh, Li, Shaohua, Ingo Molnar,
linuxppc-dev@lists.ozlabs.org, Len Brown
In-Reply-To: <20090816194441.GA22626@balbir.in.ibm.com>
On Mon, 2009-08-17 at 01:14 +0530, Balbir Singh wrote:
> * Dipankar Sarma <dipankar@in.ibm.com> [2009-08-16 23:56:29]:
>
> > On Fri, Aug 14, 2009 at 01:30:21PM +0200, Pavel Machek wrote:
> > > >
> > > > It depends on the hypervisor implementation. On pseries (powerpc)
> > > > hypervisor, for example, they are different. By offlining a vcpu
> > > > (and in turn shutting a cpu), you will actually create a configuration
> > > > change in the VM that is visible to other systems management tools
> > > > which may not be what the system administrator wanted. Ideally,
> > > > we would like to distinguish between these two states.
> > > >
> > > > Hope that suffices as an example.
> > >
> > > So... you have something like "physically pulling out hotplug cpu" on
> > > powerpc.
> >
> > If any system can do physical unplug, then it should do "offline"
> > with configuration changes reflected in the hypervisor and
> > other system configuration software.
> >
> > > But maybe it is useful to take already offline cpus (from linux side),
> > > and make that visible to hypervisor, too.
> > >
> > > So maybe something like "echo 1 > /sys/devices/system/cpu/cpu1/unplug"
> > > would be more useful for hypervisor case?
> >
> > On pseries, we do an RTAS call ("stop-cpu") which effectively permantently
> > de-allocates it from the VM hands over the control to hypervisor. The
> > hypervisors may do whatever it wants including allocating it to
> > another VM. Once gone, the original VM may not get it back depending
> > on the situation.
> >
> > The point I am making is that we may not always want to *release*
> > the CPU to hypervisor and induce a configuration change. That needs
> > to be reflected by extending the existing user interface - hence
> > the proposal for - /sys/devices/system/cpu/cpu<#>/state and
> > /sys/devices/system/cpu/cpu<#>/available_states. It allows
> > ceding to hypervisor without de-allocating. It is a minor
> > extension of the existing interface keeping backwards compatibility
> > and platforms can allow what make sense.
> >
>
>
> Agreed, I've tried to come with a little ASCII art to depict your
> scenairos graphically
>
>
> +--------+ don't need (offline)
> | OS +----------->+------------+
> +--+-----+ | hypervisor +-----> Reuse CPU
> | | | for something
> | | | else
> | | | (visible to users)
> | | | as resource changed
> | +----------- +
> V (needed, but can cede)
> +------------+
> | hypervisor | Don't reuse CPU
> | | (CPU ceded)
> | | give back to OS
> +------------+ when needed.
> (Not visible to
> users as so resource
> binding changed)
I still don't get it... _why_ should this be exposed in the guest
kernel? Why not let the hypervisor manage a guest's offline cpus in a
way it sees fit?
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Dipankar Sarma @ 2009-08-17 6:24 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Brown, Len, Gautham R Shenoy, Darrick J. Wong,
linux-kernel@vger.kernel.org, Rafael J. Wysocki, Pavel Machek,
Pallipadi, Venkatesh, Li, Shaohua, Ingo Molnar, balbir,
linuxppc-dev@lists.ozlabs.org, Len Brown
In-Reply-To: <1250459602.8648.35.camel@laptop>
On Sun, Aug 16, 2009 at 11:53:22PM +0200, Peter Zijlstra wrote:
> On Mon, 2009-08-17 at 01:14 +0530, Balbir Singh wrote:
> > Agreed, I've tried to come with a little ASCII art to depict your
> > scenairos graphically
> >
> >
> > +--------+ don't need (offline)
> > | OS +----------->+------------+
> > +--+-----+ | hypervisor +-----> Reuse CPU
> > | | | for something
> > | | | else
> > | | | (visible to users)
> > | | | as resource changed
> > | +----------- +
> > V (needed, but can cede)
> > +------------+
> > | hypervisor | Don't reuse CPU
> > | | (CPU ceded)
> > | | give back to OS
> > +------------+ when needed.
> > (Not visible to
> > users as so resource
> > binding changed)
>
> I still don't get it... _why_ should this be exposed in the guest
> kernel? Why not let the hypervisor manage a guest's offline cpus in a
> way it sees fit?
For most parts, we do. The guest kernel doesn't manage the offline
CPU state. That is typically done by the hypervisor. However, offline
operation as defined now always result in a VM resize in some hypervisor
systems (like pseries) - it would be convenient to have a non-resize
offline operation which lets the guest cede the cpu to hypervisor
with the hint that the VM shouldn't be resized and the guest needs the guarantee
to get the cpu back any time. The hypervisor can do whatever it wants
with the ceded CPU including putting it in a low power state, but
not change the physical cpu shares of the VM. The pseries hypervisor,
for example, clearly distinguishes between the two - "rtas-stop-self" call
to resize VM vs. H_CEDE hypercall with a hint. What I am suggesting
is that we allow this with an extension to existing interfaces because it
makes sense to allow sort of "hibernation" of the cpus without changing any
configuration of the VMs.
Thanks
Dipankar
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Peter Zijlstra @ 2009-08-17 7:15 UTC (permalink / raw)
To: dipankar
Cc: Brown, Len, Gautham R Shenoy, Darrick J. Wong,
linux-kernel@vger.kernel.org, Rafael J. Wysocki, Pavel Machek,
Pallipadi, Venkatesh, Li, Shaohua, Ingo Molnar, balbir,
linuxppc-dev@lists.ozlabs.org, Len Brown
In-Reply-To: <20090817062418.GB31027@in.ibm.com>
On Mon, 2009-08-17 at 11:54 +0530, Dipankar Sarma wrote:
> On Sun, Aug 16, 2009 at 11:53:22PM +0200, Peter Zijlstra wrote:
> > On Mon, 2009-08-17 at 01:14 +0530, Balbir Singh wrote:
> > > Agreed, I've tried to come with a little ASCII art to depict your
> > > scenairos graphically
> > >
> > >
> > > +--------+ don't need (offline)
> > > | OS +----------->+------------+
> > > +--+-----+ | hypervisor +-----> Reuse CPU
> > > | | | for something
> > > | | | else
> > > | | | (visible to users)
> > > | | | as resource changed
> > > | +----------- +
> > > V (needed, but can cede)
> > > +------------+
> > > | hypervisor | Don't reuse CPU
> > > | | (CPU ceded)
> > > | | give back to OS
> > > +------------+ when needed.
> > > (Not visible to
> > > users as so resource
> > > binding changed)
> >
> > I still don't get it... _why_ should this be exposed in the guest
> > kernel? Why not let the hypervisor manage a guest's offline cpus in a
> > way it sees fit?
>
> For most parts, we do. The guest kernel doesn't manage the offline
> CPU state. That is typically done by the hypervisor. However, offline
> operation as defined now always result in a VM resize in some hypervisor
> systems (like pseries) - it would be convenient to have a non-resize
> offline operation which lets the guest cede the cpu to hypervisor
> with the hint that the VM shouldn't be resized and the guest needs the guarantee
> to get the cpu back any time. The hypervisor can do whatever it wants
> with the ceded CPU including putting it in a low power state, but
> not change the physical cpu shares of the VM. The pseries hypervisor,
> for example, clearly distinguishes between the two - "rtas-stop-self" call
> to resize VM vs. H_CEDE hypercall with a hint. What I am suggesting
> is that we allow this with an extension to existing interfaces because it
> makes sense to allow sort of "hibernation" of the cpus without changing any
> configuration of the VMs.
>From my POV the thing you call cede is the only sane thing to do for a
guest. Let the hypervisor management interface deal with resizing guests
if and when that's needed.
Thing is, you don't want a guest to be able to influence the amount of
cpu shares attributed to it. You want that in explicit control of
whomever manages the hypervisor.
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Dipankar Sarma @ 2009-08-17 7:58 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Brown, Len, Gautham R Shenoy, Darrick J. Wong,
linux-kernel@vger.kernel.org, Rafael J. Wysocki, Pavel Machek,
Pallipadi, Venkatesh, Li, Shaohua, Ingo Molnar, balbir,
linuxppc-dev@lists.ozlabs.org, Len Brown
In-Reply-To: <1250493357.5241.1656.camel@twins>
On Mon, Aug 17, 2009 at 09:15:57AM +0200, Peter Zijlstra wrote:
> On Mon, 2009-08-17 at 11:54 +0530, Dipankar Sarma wrote:
> > For most parts, we do. The guest kernel doesn't manage the offline
> > CPU state. That is typically done by the hypervisor. However, offline
> > operation as defined now always result in a VM resize in some hypervisor
> > systems (like pseries) - it would be convenient to have a non-resize
> > offline operation which lets the guest cede the cpu to hypervisor
> > with the hint that the VM shouldn't be resized and the guest needs the guarantee
> > to get the cpu back any time. The hypervisor can do whatever it wants
> > with the ceded CPU including putting it in a low power state, but
> > not change the physical cpu shares of the VM. The pseries hypervisor,
> > for example, clearly distinguishes between the two - "rtas-stop-self" call
> > to resize VM vs. H_CEDE hypercall with a hint. What I am suggesting
> > is that we allow this with an extension to existing interfaces because it
> > makes sense to allow sort of "hibernation" of the cpus without changing any
> > configuration of the VMs.
>
> >From my POV the thing you call cede is the only sane thing to do for a
> guest. Let the hypervisor management interface deal with resizing guests
> if and when that's needed.
That is more or less how it currently works - atleast for pseries hypervisor.
The current "offline" operation with "rtas-stop-self" call I mentioned
earlier is initiated by the hypervisor management interfaces/tool in
pseries system. This wakes up a guest system tool that echoes "1"
to the offline file resulting in the configuration change.
The OS involvement is necessary to evacuate tasks/interrupts
from the released CPU. We don't really want to initiate this from guests.
> Thing is, you don't want a guest to be able to influence the amount of
> cpu shares attributed to it. You want that in explicit control of
> whomever manages the hypervisor.
Agreed. But given a fixed cpu share by the hypervisor management tools,
we would like to be able to cede cpus to hypervisor leaving the hypervisor
configuration intact. This, we don't have at the moment and want to just
extend the current interface for this.
Thanks
Dipankar
^ permalink raw reply
* Re: Poll: Rebasing of powerpc-next
From: Josh Boyer @ 2009-08-17 12:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1250374817.24143.71.camel@pasglop>
On Sun, Aug 16, 2009 at 08:20:17AM +1000, Benjamin Herrenschmidt wrote:
>Hi !
>
>I'd like to rebase powerpc-next ... a few bugs have been found that it
>would be nice to fix in the original patch rather than introducing a
>bisection breakage, and Kumar also just noticed a potentially misleading
>error in a commit message from his tree.
>
>So who is not ok with me doing that tomorrow or tuesday ?
That's fine with me. I have a few pending patches to pull in, and another
to send out myself. I'll do that after the rebase.
josh
^ permalink raw reply
* [PATCH] powerpc: Fix __flush_icache_range on 44x
From: Josh Boyer @ 2009-08-17 13:41 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
The ptrace POKETEXT interface allows a process to modify the text pages of
a child process being ptraced, usually to insert breakpoints via trap
instructions. The kernel eventually calls copy_to_user_page, which in turn
calls __flush_icache_range to invalidate the icache lines for the child
process.
However, this function does not work on 44x due to the icache being virtually
indexed. This was noticed by a breakpoint being triggered after it had been
cleared by ltrace on a 440EPx board. The convenient solution is to do a
flash invalidate of the icache in the __flush_icache_range function.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 15f28e0..c9805a4 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -346,6 +346,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
2: icbi 0,r6
addi r6,r6,L1_CACHE_BYTES
bdnz 2b
+#ifdef CONFIG_44x
+ iccci r0, r0
+#endif
sync /* additional sync needed on g4 */
isync
blr
^ permalink raw reply related
* Re: [PATCH 4/8] powerpc/qe&cpm: Implement static inline stubs for non-QE/CPM builds
From: Anton Vorontsov @ 2009-08-17 13:53 UTC (permalink / raw)
To: David Brownell
Cc: spi-devel-general, Andrew Morton, linux-kernel, linuxppc-dev
In-Reply-To: <20090814222549.GD14458@oksana.dev.rtsoft.ru>
On Sat, Aug 15, 2009 at 02:25:49AM +0400, Anton Vorontsov wrote:
[....]
> +#ifdef CONFIG_CPM
> int cpm_command(u32 command, u8 opcode);
> +#else
> +static inline int cpm_command(u32 command, u8 opcode)
> +{
> + return -ENOSYS;
> +}
> +#endif /* CONFIG_CPM */
It appers that fsl_qe_udc.h defines its own inlined version, and so
fsl_qe_udc.c's build breaks:
In file included from drivers/usb/gadget/fsl_qe_udc.c:44:
fsl_qe_udc.h:432: error: redefinition of ‘qe_issue_cmd’
arch/powerpc/include/asm/qe.h:153: error: previous definition of ‘qe_issue_cmd’ was here
I didn't notice that earlier because USB_GADGET_FSL_QE isn't enabled
in any defconfig.
I'll send v2 soon.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Dipankar Sarma @ 2009-08-17 14:40 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Brown, Len, Gautham R Shenoy, Darrick J. Wong,
linux-kernel@vger.kernel.org, Rafael J. Wysocki, Pavel Machek,
Pallipadi, Venkatesh, Li, Shaohua, Ingo Molnar, balbir,
linuxppc-dev@lists.ozlabs.org, Len Brown
In-Reply-To: <20090817075815.GB11049@in.ibm.com>
On Mon, Aug 17, 2009 at 01:28:15PM +0530, Dipankar Sarma wrote:
> On Mon, Aug 17, 2009 at 09:15:57AM +0200, Peter Zijlstra wrote:
> > On Mon, 2009-08-17 at 11:54 +0530, Dipankar Sarma wrote:
> > > For most parts, we do. The guest kernel doesn't manage the offline
> > > CPU state. That is typically done by the hypervisor. However, offline
> > > operation as defined now always result in a VM resize in some hypervisor
> > > systems (like pseries) - it would be convenient to have a non-resize
> > > offline operation which lets the guest cede the cpu to hypervisor
> > > with the hint that the VM shouldn't be resized and the guest needs the guarantee
> > > to get the cpu back any time. The hypervisor can do whatever it wants
> > > with the ceded CPU including putting it in a low power state, but
> > > not change the physical cpu shares of the VM. The pseries hypervisor,
> > > for example, clearly distinguishes between the two - "rtas-stop-self" call
> > > to resize VM vs. H_CEDE hypercall with a hint. What I am suggesting
> > > is that we allow this with an extension to existing interfaces because it
> > > makes sense to allow sort of "hibernation" of the cpus without changing any
> > > configuration of the VMs.
> >
> > >From my POV the thing you call cede is the only sane thing to do for a
> > guest. Let the hypervisor management interface deal with resizing guests
> > if and when that's needed.
>
> That is more or less how it currently works - atleast for pseries hypervisor.
> The current "offline" operation with "rtas-stop-self" call I mentioned
> earlier is initiated by the hypervisor management interfaces/tool in
> pseries system. This wakes up a guest system tool that echoes "1"
> to the offline file resulting in the configuration change.
Should have said - echoes "0" to the online file.
You don't necessarily need this in the guest Linux as long as there is
a way for hypervisor tools to internally move Linux tasks/interrupts
from a vcpu - async event handled by the kernel, for example.
But I think it is too late for that - the interface has long been
exported.
> The OS involvement is necessary to evacuate tasks/interrupts
> from the released CPU. We don't really want to initiate this from guests.
>
> > Thing is, you don't want a guest to be able to influence the amount of
> > cpu shares attributed to it. You want that in explicit control of
> > whomever manages the hypervisor.
>
> Agreed. But given a fixed cpu share by the hypervisor management tools,
> we would like to be able to cede cpus to hypervisor leaving the hypervisor
> configuration intact. This, we don't have at the moment and want to just
> extend the current interface for this.
>
> Thanks
> Dipankar
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: Poll: Rebasing of powerpc-next
From: Becky Bruce @ 2009-08-17 15:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1250374817.24143.71.camel@pasglop>
On Aug 15, 2009, at 5:20 PM, Benjamin Herrenschmidt wrote:
> Hi !
>
> I'd like to rebase powerpc-next ... a few bugs have been found that it
> would be nice to fix in the original patch rather than introducing a
> bisection breakage, and Kumar also just noticed a potentially
> misleading
> error in a commit message from his tree.
>
> So who is not ok with me doing that tomorrow or tuesday ?
Sounds like a swell idea to me.... I hate bisection breakage.
-Becky
^ permalink raw reply
* Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC
From: Josh Boyer @ 2009-08-17 15:13 UTC (permalink / raw)
To: Solomon Peachy; +Cc: linuxppc-dev
In-Reply-To: <20090730200848.GF10244@zod.rchland.ibm.com>
On Thu, Jul 30, 2009 at 04:08:49PM -0400, Josh Boyer wrote:
>>> Ok. So I'm not really all that thrilled with changes to ppcboot.h.
>>> We try to keep this file as much in-sync with U-Boot as we can. Did
>>> your HOTFOOT changes get pulled into upstream U-Boot?
>>
>>Yeah, I thought this may be a problem, but I didn't know a better way to
>>go about this and still maintain compatibility with the many thousands
>>of boards already in the field. I mean, I could strip out the ppcboot.h
>>changes and maintain that as an out-of-tree patch, but without that
>>patch, the kernel won't boot on in-the-field boards, rendering the
>>upstreaming of support for this board kinda pointless.
>>
>>I haven't tried to push anything to upstream u-boot, given how ancient
>>the in-production bootloader is. The guy who originally mangled u-boot
>>for this board did so before the "standard" 405EP dual ethernet layout
>>was added, and never tried to push it upstream. Any upstream uboot work
>>will take the form of a native dts/fdt port that probably won't use
>>ppcboot.h anyway, which brings us full circle...
>
>There is another way. Perhaps you could just copy ppcboot.h to a new file
>called "hotfoot.h" and just use that. It's a duplication of ppcboot.h to
>some degree, but it seems to make sense for your board and it helps preserve
>the "stock" ppcboot.h for other boards.
Solomon, any update on this? As far as I'm concerned, the ppcboot.h issue is
the only thing that really needs to be reworked before we bring this patch
in.
josh
^ permalink raw reply
* Re: [PATCH 1/1 v1] powerpc44x: Add Eiger AMCC (AppliedMicro) PPC460SX evaluation board support.
From: Josh Boyer @ 2009-08-17 15:34 UTC (permalink / raw)
To: Feng Kan; +Cc: linuxppc-dev, Tai Tri Nguyen
In-Reply-To: <1250123927-29167-1-git-send-email-fkan@amcc.com>
On Wed, Aug 12, 2009 at 05:38:47PM -0700, Feng Kan wrote:
>This patch adds support for the AMCC (AppliedMicro) PPC460SX Eiger evaluation board.
>
>Signed-off-by: Tai Tri Nguyen <ttnguyen@amcc.com>
>Acked-by: Feng Kan <fkan@amcc.com>
>Acked-by: Tirumala Marri <tmarri@amcc.com>
>---
> arch/powerpc/boot/dts/eiger.dts | 421 ++++++++++
> arch/powerpc/configs/44x/eiger_defconfig | 1200 ++++++++++++++++++++++++++++
> arch/powerpc/platforms/44x/Kconfig | 12 +
> arch/powerpc/platforms/44x/ppc44x_simple.c | 1 +
> 4 files changed, 1634 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/eiger.dts
> create mode 100644 arch/powerpc/configs/44x/eiger_defconfig
Thanks, this looks great.
If you have no objections, I will commit an updated defconfig against the
current kernel sources instead of the one attached. Some of the options
will move around a bit, but there should be no overall changes.
josh
^ permalink raw reply
* Re: [PATCH] powerpc: Fix __flush_icache_range on 44x
From: Josh Boyer @ 2009-08-17 16:07 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20090817134136.GB8710@zod.rchland.ibm.com>
On Mon, Aug 17, 2009 at 09:41:36AM -0400, Josh Boyer wrote:
>The ptrace POKETEXT interface allows a process to modify the text pages of
>a child process being ptraced, usually to insert breakpoints via trap
>instructions. The kernel eventually calls copy_to_user_page, which in turn
>calls __flush_icache_range to invalidate the icache lines for the child
>process.
>
>However, this function does not work on 44x due to the icache being virtually
>indexed. This was noticed by a breakpoint being triggered after it had been
>cleared by ltrace on a 440EPx board. The convenient solution is to do a
>flash invalidate of the icache in the __flush_icache_range function.
>
>Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
>---
>
>diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
>index 15f28e0..c9805a4 100644
>--- a/arch/powerpc/kernel/misc_32.S
>+++ b/arch/powerpc/kernel/misc_32.S
>@@ -346,6 +346,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
> 2: icbi 0,r6
> addi r6,r6,L1_CACHE_BYTES
> bdnz 2b
>+#ifdef CONFIG_44x
>+ iccci r0, r0
>+#endif
Olof pointed out that we could probably do the iccci before the icbi loop and
just skip that loop entirely on 44x. This is most certainly valid, but at
this particular moment I don't have time to try and reproduce the issue with
an alternative fix and I wanted to get _something_ out there to fix the issue.
I suck for that, I know.
josh
^ permalink raw reply
* Re: [PATCH 1/1 v1] powerpc44x: Add Eiger AMCC (AppliedMicro) PPC460SX evaluation board support.
From: Feng Kan @ 2009-08-17 16:35 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Tai Tri Nguyen
In-Reply-To: <20090817153456.GD8710@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]
Please do, much appreciated.
Thanks
Feng Kan
AMCC Software
On 08/17/2009 08:34 AM, Josh Boyer wrote:
> On Wed, Aug 12, 2009 at 05:38:47PM -0700, Feng Kan wrote:
>
>> This patch adds support for the AMCC (AppliedMicro) PPC460SX Eiger evaluation board.
>>
>> Signed-off-by: Tai Tri Nguyen<ttnguyen@amcc.com>
>> Acked-by: Feng Kan<fkan@amcc.com>
>> Acked-by: Tirumala Marri<tmarri@amcc.com>
>> ---
>> arch/powerpc/boot/dts/eiger.dts | 421 ++++++++++
>> arch/powerpc/configs/44x/eiger_defconfig | 1200 ++++++++++++++++++++++++++++
>> arch/powerpc/platforms/44x/Kconfig | 12 +
>> arch/powerpc/platforms/44x/ppc44x_simple.c | 1 +
>> 4 files changed, 1634 insertions(+), 0 deletions(-)
>> create mode 100644 arch/powerpc/boot/dts/eiger.dts
>> create mode 100644 arch/powerpc/configs/44x/eiger_defconfig
>>
>
> Thanks, this looks great.
>
> If you have no objections, I will commit an updated defconfig against the
> current kernel sources instead of the one attached. Some of the options
> will move around a bit, but there should be no overall changes.
>
> josh
>
[-- Attachment #2: Type: text/html, Size: 1734 bytes --]
^ permalink raw reply
* FW: need help getting SPI controller working on 405EX [PPM2009081200000033]
From: Tirumala Reddy Marri @ 2009-08-17 18:07 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 5118 bytes --]
1) It looks like the correct entry in kilauea.dts file should be:
208 IIC1: i2c@ef600500 {
209 compatible = "ibm,iic-405ex", "ibm,iic";
210 reg = <ef600500 14>;
211 interrupt-parent = <&UIC0>;
212 interrupts = <7 4>;
213 #address-cells = <1>;
214 #size-cells = <0>;
215 };
216
217 SPI0: spi@ef600600 {
218 /* compatible = "ibm,iic-405ex", "ibm,iic"; */
219 compatible = "amcc,scp-405ex";
220 reg = <ef600600 6>;
221 interrupts = <8 4>;
222 interrupt-parent = <&UIC0>;
223 };
224
225 RGMII0: emac-rgmii@ef600b00 {
226 compatible = "ibm,rgmii-405ex", "ibm,rgmii";
227 reg = <ef600b00 104>;
228 has-mdio;
229 };
230
231 EMAC0: ethernet@ef600900 {
2) Right now the e.g. scp-dev.c is in drivers/scp directory in one of
the internal release I have found, NOT in the e.g. 2.6.29.
Additional comments:
- Ideally the file should be moved to drivers/spi, like all other spi
drivers.
- Even in the internal release, the files do NOT compile properly,
because of missing file, need CONFIG_PINE, etc
[support@localhost linux]$ make uImage
scripts/kconfig/conf -s arch/powerpc/Kconfig
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
CALL arch/powerpc/kernel/systbl_chk.sh
CC drivers/scp/scp-dev.o
drivers/scp/scp-dev.c:84:24: error: asm/ibm4xx.h: No such file or
directory
drivers/scp/scp-dev.c:705: error: 'scpdev_init' undeclared here (not in
a function)
make[2]: *** [drivers/scp/scp-dev.o] Error 1
make[1]: *** [drivers/scp] Error 2
make: *** [drivers] Error 2
[support@localhost linux]
Q: Marri, what do we need to provide to Nathan French ?
Q: Fan, per Jinag-An's request, what is the procedure for cleaning this
up before releasing to Linux community ?
Regards, Samuel
-----Original Message-----
From: support_reply@amcc.com [mailto:support_reply@amcc.com]
Sent: Fri 8/7/2009 9:24 AM
To: Samuel Wang
Subject: FW: need help getting SPI controller working on 405EX
[PPM2009081200000033311192]
Sender : tmarri@amcc.com
Tracking Number : PPM2009081200000033311192
Pool : PPC_MID
Sent to : "AMCC Product Support" <supportimc@amcc.com>
Date : 8/7/09 9:24 AM
---
Forwarded by: Alan Millard
(no comments entered)
---
-----Original Message-----
From: linuxppc-dev-bounces+tmarri=amcc.com@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc.com@lists.ozlabs.org] On Behalf
Of Nathan French
Sent: Thursday, August 06, 2009 9:08 AM
To: linuxppc-dev@lists.ozlabs.org
Subject: need help getting SPI controller working on 405EX
Hi, I am trying to add support for the 405EX's SPI controller on a
Kilauea board. I've added the below to the device tree (under
plb/opb/):
[nfrench@nfrench-laptop linux-2.6-denx]$ diff -C2
arch/powerpc/boot/dts/kilauea.dts spi.dts
*** arch/powerpc/boot/dts/kilauea.dts 2009-05-05 15:56:16.000000000
-0700
--- spi.dts 2009-08-06 08:42:19.000000000 -0700
***************
*** 207,210 ****
--- 207,221 ----
#size-cells = <0>;
};
+
+ SPI0: spi@ef600600 {
+ cell-index = <0>;
+ compatible = "ibm,spi-405ex", "ibm,spi";
+ reg = <ef600600 6>;
+ interrupts = <8 4>;
+ interrupt-parent = <&UIC0>;
+ mode = "cpu";
+ };
RGMII0: emac-rgmii@ef600b00 {
I've also compiled my kernel with the following enabled:
CONFIG_SPI=y
CONFIG_SPI_MASTER=y
CONFIG_SPI_SPIDEV=y
I see this make it into the device tree after boot:
[root@10.2.3.28 /]$ find /proc/device-tree/ | grep spi
/proc/device-tree/plb/opb/spi@ef600600
/proc/device-tree/plb/opb/spi@ef600600/name
/proc/device-tree/plb/opb/spi@ef600600/mode
/proc/device-tree/plb/opb/spi@ef600600/interrupt-parent
/proc/device-tree/plb/opb/spi@ef600600/interrupts
/proc/device-tree/plb/opb/spi@ef600600/reg
/proc/device-tree/plb/opb/spi@ef600600/compatible
/proc/device-tree/plb/opb/spi@ef600600/cell-index
But I don't see any /dev/spidev* devices created or any mention of SPI
at boot time. I'm starting to suspect that I don't have the kernel
configured right, otherwise I would see at least the SPI driver
complaining about something, right?
Thanks,
Nathan French
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 18745 bytes --]
^ permalink raw reply
* Re: simple gpio driver
From: Grant Likely @ 2009-08-17 21:18 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <4A83A976.60608@denx.de>
On Wed, Aug 12, 2009 at 11:49 PM, Heiko Schocher<hs@denx.de> wrote:
> Hello Anton,
>
> i am trying to use the arch/powerpc/sysdev/simple_gpio.c driver,
> for accessing some gpios, and found, that u8_gpio_get()
> returns not only a 1 or a 0, instead it returns the real bit
> position from the gpio:
>
> gpio =A0 =A0return
> base =A0 =A0value
> 0 =A0 =A0 =A0 0/0x01
> 1 =A0 =A0 =A0 0/0x02
> 2 =A0 =A0 =A0 0/0x04
> 3 =A0 =A0 =A0 0/0x08
> 4 =A0 =A0 =A0 0/0x10
> 5 =A0 =A0 =A0 0/0x20
> 6 =A0 =A0 =A0 0/0x40
> 7 =A0 =A0 =A0 0/0x80
>
> I also use the arch/powerpc/platforms/52xx/mpc52xx_gpio.c and
> mpc52xx_gpt.c drivers, they all return for a gpio just a 1 or 0,
> which seems correct to me, because a gpio can have only 1 or 0
> as state ... what do you think?
I think returning '1' is perhaps slightly 'better' (however you define
that), but I don't think the caller should make any assumptions beyond
zero/non-zero.
>
> I solved this issue (if it is) with the following patch:
>
> diff --git a/arch/powerpc/sysdev/simple_gpio.c b/arch/powerpc/sysdev/simp=
le_gpio.c
> index 43c4569..bb0d79c 100644
> --- a/arch/powerpc/sysdev/simple_gpio.c
> +++ b/arch/powerpc/sysdev/simple_gpio.c
> @@ -46,7 +46,7 @@ static int u8_gpio_get(struct gpio_chip *gc, unsigned i=
nt gpio)
> =A0{
> =A0 =A0 =A0 =A0struct of_mm_gpio_chip *mm_gc =3D to_of_mm_gpio_chip(gc);
>
> - =A0 =A0 =A0 return in_8(mm_gc->regs) & u8_pin2mask(gpio);
> + =A0 =A0 =A0 return (in_8(mm_gc->regs) & u8_pin2mask(gpio) ? 1 : 0);
For clarity, the brackets should be just around the & operands, and
"!=3D 0" instead of "? 1 : 0" might result in slightly smaller code.
return (in_8(mm_gc->regs) & u8_pin2mask(gpio)) !=3D 0;
^ permalink raw reply
* Re: [PATCH] powerpc: Fix __flush_icache_range on 44x
From: Benjamin Herrenschmidt @ 2009-08-17 21:46 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20090817160713.GE8710@zod.rchland.ibm.com>
On Mon, 2009-08-17 at 12:07 -0400, Josh Boyer wrote:
>
> Olof pointed out that we could probably do the iccci before the icbi loop and
> just skip that loop entirely on 44x. This is most certainly valid, but at
> this particular moment I don't have time to try and reproduce the issue with
> an alternative fix and I wanted to get _something_ out there to fix the issue.
>
> I suck for that, I know.
Well, I can massage your patch if you want. The fact is, the icbi loop
and iccci are definitely redundant :-)
Cheers,
Ben.
^ permalink raw reply
* [PATCH 2/3 v3] powerpc: Allow perf_counters to access user memory at interrupt time
From: Paul Mackerras @ 2009-08-17 23:00 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <19081.57584.173693.798535@cargo.ozlabs.ibm.com>
This provides a mechanism to allow the perf_counters code to access
user memory in a PMU interrupt routine. Such an access can cause
various kinds of interrupt: SLB miss, MMU hash table miss, segment
table miss, or TLB miss, depending on the processor. This commit
only deals with 64-bit classic/server processors, which use an MMU
hash table. 32-bit processors are already able to access user memory
at interrupt time. Since we don't soft-disable on 32-bit, we avoid
the possibility of reentering hash_page or the TLB miss handlers,
since they run with interrupts disabled.
On 64-bit processors, an SLB miss interrupt on a user address will
update the slb_cache and slb_cache_ptr fields in the paca. This is
OK except in the case where a PMU interrupt occurs in switch_slb,
which also accesses those fields. To prevent this, we hard-disable
interrupts in switch_slb. Interrupts are already soft-disabled at
this point, and will get hard-enabled when they get soft-enabled
later.
This also reworks slb_flush_and_rebolt: to avoid hard-disabling twice,
and to make sure that it clears the slb_cache_ptr when called from
other callers than switch_slb, the existing routine is renamed to
__slb_flush_and_rebolt, which is called by switch_slb and the new
version of slb_flush_and_rebolt.
Similarly, switch_stab (used on POWER3 and RS64 processors) gets a
hard_irq_disable() to protect the per-cpu variables used there and
in ste_allocate.
If a MMU hashtable miss interrupt occurs, normally we would call
hash_page to look up the Linux PTE for the address and create a HPTE.
However, hash_page is fairly complex and takes some locks, so to
avoid the possibility of deadlock, we check the preemption count
to see if we are in a (pseudo-)NMI handler, and if so, we don't call
hash_page but instead treat it like a bad access that will get
reported up through the exception table mechanism. An interrupt
whose handler runs even though the interrupt occurred when
soft-disabled (such as the PMU interrupt) is considered a pseudo-NMI
handler, which should use nmi_enter()/nmi_exit() rather than
irq_enter()/irq_exit().
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/kernel/asm-offsets.c | 2 +
arch/powerpc/kernel/exceptions-64s.S | 19 +++++++++++++++++
arch/powerpc/mm/slb.c | 37 +++++++++++++++++++++++----------
arch/powerpc/mm/stab.c | 11 +++++++++-
4 files changed, 57 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 561b646..197b156 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -67,6 +67,8 @@ int main(void)
DEFINE(MMCONTEXTID, offsetof(struct mm_struct, context.id));
#ifdef CONFIG_PPC64
DEFINE(AUDITCONTEXT, offsetof(struct task_struct, audit_context));
+ DEFINE(SIGSEGV, SIGSEGV);
+ DEFINE(NMI_MASK, NMI_MASK);
#else
DEFINE(THREAD_INFO, offsetof(struct task_struct, stack));
#endif /* CONFIG_PPC64 */
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index eb89811..8ac85e0 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -729,6 +729,11 @@ BEGIN_FTR_SECTION
bne- do_ste_alloc /* If so handle it */
END_FTR_SECTION_IFCLR(CPU_FTR_SLB)
+ clrrdi r11,r1,THREAD_SHIFT
+ lwz r0,TI_PREEMPT(r11) /* If we're in an "NMI" */
+ andis. r0,r0,NMI_MASK@h /* (i.e. an irq when soft-disabled) */
+ bne 77f /* then don't call hash_page now */
+
/*
* On iSeries, we soft-disable interrupts here, then
* hard-enable interrupts so that the hash_page code can spin on
@@ -833,6 +838,20 @@ handle_page_fault:
bl .low_hash_fault
b .ret_from_except
+/*
+ * We come here as a result of a DSI at a point where we don't want
+ * to call hash_page, such as when we are accessing memory (possibly
+ * user memory) inside a PMU interrupt that occurred while interrupts
+ * were soft-disabled. We want to invoke the exception handler for
+ * the access, or panic if there isn't a handler.
+ */
+77: bl .save_nvgprs
+ mr r4,r3
+ addi r3,r1,STACK_FRAME_OVERHEAD
+ li r5,SIGSEGV
+ bl .bad_page_fault
+ b .ret_from_except
+
/* here we have a segment miss */
do_ste_alloc:
bl .ste_allocate /* try to insert stab entry */
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index 5b7038f..a685652 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -92,15 +92,13 @@ static inline void create_shadowed_slbe(unsigned long ea, int ssize,
: "memory" );
}
-void slb_flush_and_rebolt(void)
+static void __slb_flush_and_rebolt(void)
{
/* If you change this make sure you change SLB_NUM_BOLTED
* appropriately too. */
unsigned long linear_llp, vmalloc_llp, lflags, vflags;
unsigned long ksp_esid_data, ksp_vsid_data;
- WARN_ON(!irqs_disabled());
-
linear_llp = mmu_psize_defs[mmu_linear_psize].sllp;
vmalloc_llp = mmu_psize_defs[mmu_vmalloc_psize].sllp;
lflags = SLB_VSID_KERNEL | linear_llp;
@@ -117,12 +115,6 @@ void slb_flush_and_rebolt(void)
ksp_vsid_data = get_slb_shadow()->save_area[2].vsid;
}
- /*
- * We can't take a PMU exception in the following code, so hard
- * disable interrupts.
- */
- hard_irq_disable();
-
/* We need to do this all in asm, so we're sure we don't touch
* the stack between the slbia and rebolting it. */
asm volatile("isync\n"
@@ -139,6 +131,21 @@ void slb_flush_and_rebolt(void)
: "memory");
}
+void slb_flush_and_rebolt(void)
+{
+
+ WARN_ON(!irqs_disabled());
+
+ /*
+ * We can't take a PMU exception in the following code, so hard
+ * disable interrupts.
+ */
+ hard_irq_disable();
+
+ __slb_flush_and_rebolt();
+ get_paca()->slb_cache_ptr = 0;
+}
+
void slb_vmalloc_update(void)
{
unsigned long vflags;
@@ -180,12 +187,20 @@ static inline int esids_match(unsigned long addr1, unsigned long addr2)
/* Flush all user entries from the segment table of the current processor. */
void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
{
- unsigned long offset = get_paca()->slb_cache_ptr;
+ unsigned long offset;
unsigned long slbie_data = 0;
unsigned long pc = KSTK_EIP(tsk);
unsigned long stack = KSTK_ESP(tsk);
unsigned long unmapped_base;
+ /*
+ * We need interrupts hard-disabled here, not just soft-disabled,
+ * so that a PMU interrupt can't occur, which might try to access
+ * user memory (to get a stack trace) and possible cause an SLB miss
+ * which would update the slb_cache/slb_cache_ptr fields in the PACA.
+ */
+ hard_irq_disable();
+ offset = get_paca()->slb_cache_ptr;
if (!cpu_has_feature(CPU_FTR_NO_SLBIE_B) &&
offset <= SLB_CACHE_ENTRIES) {
int i;
@@ -200,7 +215,7 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
}
asm volatile("isync" : : : "memory");
} else {
- slb_flush_and_rebolt();
+ __slb_flush_and_rebolt();
}
/* Workaround POWER5 < DD2.1 issue */
diff --git a/arch/powerpc/mm/stab.c b/arch/powerpc/mm/stab.c
index 98cd1dc..ab5fb48 100644
--- a/arch/powerpc/mm/stab.c
+++ b/arch/powerpc/mm/stab.c
@@ -164,7 +164,7 @@ void switch_stab(struct task_struct *tsk, struct mm_struct *mm)
{
struct stab_entry *stab = (struct stab_entry *) get_paca()->stab_addr;
struct stab_entry *ste;
- unsigned long offset = __get_cpu_var(stab_cache_ptr);
+ unsigned long offset;
unsigned long pc = KSTK_EIP(tsk);
unsigned long stack = KSTK_ESP(tsk);
unsigned long unmapped_base;
@@ -172,6 +172,15 @@ void switch_stab(struct task_struct *tsk, struct mm_struct *mm)
/* Force previous translations to complete. DRENG */
asm volatile("isync" : : : "memory");
+ /*
+ * We need interrupts hard-disabled here, not just soft-disabled,
+ * so that a PMU interrupt can't occur, which might try to access
+ * user memory (to get a stack trace) and possible cause an STAB miss
+ * which would update the stab_cache/stab_cache_ptr per-cpu variables.
+ */
+ hard_irq_disable();
+
+ offset = __get_cpu_var(stab_cache_ptr);
if (offset <= NR_STAB_CACHE_ENTRIES) {
int i;
--
1.6.0.4
^ permalink raw reply related
* [PATCH 3/3 v3] perf_counter: powerpc: Add callchain support
From: Paul Mackerras @ 2009-08-17 23:01 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <19081.57584.173693.798535@cargo.ozlabs.ibm.com>
This adds support for tracing callchains for powerpc, both 32-bit
and 64-bit, and both in the kernel and userspace, from PMU interrupt
context.
The first three entries stored for each callchain are the NIP (next
instruction pointer), LR (link register), and the contents of the LR
save area in the second stack frame (the first is ignored because the
ABI convention on powerpc is that functions save their return address
in their caller's stack frame). Because leaf functions don't have to
save their return address (LR value) and don't have to establish a
stack frame, it's possible for either or both of LR and the second
stack frame's LR save area to have valid return addresses in them.
This is basically impossible to disambiguate without either reading
the code or looking at auxiliary information such as CFI tables.
Since we don't want to do either of those things at interrupt time,
we store both LR and the second stack frame's LR save area.
Once we get past the second stack frame, there is no ambiguity; all
return addresses we get are reliable.
For kernel traces, we check whether they are valid kernel instruction
addresses and store zero instead if they are not (rather than
omitting them, which would make it impossible for userspace to know
which was which). We also store zero instead of the second stack
frame's LR save area value if it is the same as LR.
For kernel traces, we check for interrupt frames, and for user traces,
we check for signal frames. In each case, since we're starting a new
trace, we store a PERF_CONTEXT_KERNEL/USER marker so that userspace
knows that the next three entries are NIP, LR and the second stack fram=
e
for the interrupted context.
We read user memory with __get_user_inatomic. On 64-bit, if this
PMU interrupt occurred while interrupts are soft-disabled, and
there is no MMU hash table entry for the page, we will get an
-EFAULT return from __get_user_inatomic even if there is a valid
Linux PTE for the page, since hash_page isn't reentrant. Thus we
have code here to read the Linux PTE and access the page via the
kernel linear mapping. Since 64-bit doesn't use (or need) highmem
there is no need to do kmap_atomic. On 32-bit, we don't do soft
interrupt disabling, so this complication doesn't occur and there
is no need to fall back to reading the Linux PTE, since hash_page
(or the TLB miss handler) will get called automatically if necessary.
Note that we cannot get PMU interrupts in the interval during
context switch between switch_mm (which switches the user address
space) and switch_to (which actually changes current to the new
process). On 64-bit this is because interrupts are hard-disabled
in switch_mm and stay hard-disabled until they are soft-enabled
later, after switch_to has returned. So there is no possibility
of trying to do a user stack trace when the user address space is
not current's address space.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/perf_callchain.c | 527 ++++++++++++++++++++++++++=
++++++++
2 files changed, 528 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/kernel/perf_callchain.c
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefil=
e
index b73396b..9619285 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -97,7 +97,7 @@ obj64-$(CONFIG_AUDIT)=09=09+=3D compat_audit.o
=20
obj-$(CONFIG_DYNAMIC_FTRACE)=09+=3D ftrace.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER)=09+=3D ftrace.o
-obj-$(CONFIG_PPC_PERF_CTRS)=09+=3D perf_counter.o
+obj-$(CONFIG_PPC_PERF_CTRS)=09+=3D perf_counter.o perf_callchain.o
obj64-$(CONFIG_PPC_PERF_CTRS)=09+=3D power4-pmu.o ppc970-pmu.o power5-=
pmu.o \
=09=09=09=09 power5+-pmu.o power6-pmu.o power7-pmu.o
obj32-$(CONFIG_PPC_PERF_CTRS)=09+=3D mpc7450-pmu.o
diff --git a/arch/powerpc/kernel/perf_callchain.c b/arch/powerpc/kernel=
/perf_callchain.c
new file mode 100644
index 0000000..f74b62c
--- /dev/null
+++ b/arch/powerpc/kernel/perf_callchain.c
@@ -0,0 +1,527 @@
+/*
+ * Performance counter callchain support - powerpc architecture code
+ *
+ * Copyright =A9 2009 Paul Mackerras, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/perf_counter.h>
+#include <linux/percpu.h>
+#include <linux/uaccess.h>
+#include <linux/mm.h>
+#include <asm/ptrace.h>
+#include <asm/pgtable.h>
+#include <asm/sigcontext.h>
+#include <asm/ucontext.h>
+#include <asm/vdso.h>
+#ifdef CONFIG_PPC64
+#include "ppc32.h"
+#endif
+
+/*
+ * Store another value in a callchain_entry.
+ */
+static inline void callchain_store(struct perf_callchain_entry *entry,=
u64 ip)
+{
+=09unsigned int nr =3D entry->nr;
+
+=09if (nr < PERF_MAX_STACK_DEPTH) {
+=09=09entry->ip[nr] =3D ip;
+=09=09entry->nr =3D nr + 1;
+=09}
+}
+
+/*
+ * Is sp valid as the address of the next kernel stack frame after pre=
v_sp?
+ * The next frame may be in a different stack area but should not go
+ * back down in the same stack area.
+ */
+static int valid_next_sp(unsigned long sp, unsigned long prev_sp)
+{
+=09if (sp & 0xf)
+=09=09return 0;=09=09/* must be 16-byte aligned */
+=09if (!validate_sp(sp, current, STACK_FRAME_OVERHEAD))
+=09=09return 0;
+=09if (sp >=3D prev_sp + STACK_FRAME_OVERHEAD)
+=09=09return 1;
+=09/*
+=09 * sp could decrease when we jump off an interrupt stack
+=09 * back to the regular process stack.
+=09 */
+=09if ((sp & ~(THREAD_SIZE - 1)) !=3D (prev_sp & ~(THREAD_SIZE - 1)))
+=09=09return 1;
+=09return 0;
+}
+
+static void perf_callchain_kernel(struct pt_regs *regs,
+=09=09=09=09 struct perf_callchain_entry *entry)
+{
+=09unsigned long sp, next_sp;
+=09unsigned long next_ip;
+=09unsigned long lr;
+=09long level =3D 0;
+=09unsigned long *fp;
+
+=09lr =3D regs->link;
+=09sp =3D regs->gpr[1];
+=09callchain_store(entry, PERF_CONTEXT_KERNEL);
+=09callchain_store(entry, regs->nip);
+
+=09if (!validate_sp(sp, current, STACK_FRAME_OVERHEAD))
+=09=09return;
+
+=09for (;;) {
+=09=09fp =3D (unsigned long *) sp;
+=09=09next_sp =3D fp[0];
+
+=09=09if (next_sp =3D=3D sp + STACK_INT_FRAME_SIZE &&
+=09=09 fp[STACK_FRAME_MARKER] =3D=3D STACK_FRAME_REGS_MARKER) {
+=09=09=09/*
+=09=09=09 * This looks like an interrupt frame for an
+=09=09=09 * interrupt that occurred in the kernel
+=09=09=09 */
+=09=09=09regs =3D (struct pt_regs *)(sp + STACK_FRAME_OVERHEAD);
+=09=09=09next_ip =3D regs->nip;
+=09=09=09lr =3D regs->link;
+=09=09=09level =3D 0;
+=09=09=09callchain_store(entry, PERF_CONTEXT_KERNEL);
+
+=09=09} else {
+=09=09=09if (level =3D=3D 0)
+=09=09=09=09next_ip =3D lr;
+=09=09=09else
+=09=09=09=09next_ip =3D fp[STACK_FRAME_LR_SAVE];
+
+=09=09=09/*
+=09=09=09 * We can't tell which of the first two addresses
+=09=09=09 * we get are valid, but we can filter out the
+=09=09=09 * obviously bogus ones here. We replace them
+=09=09=09 * with 0 rather than removing them entirely so
+=09=09=09 * that userspace can tell which is which.
+=09=09=09 */
+=09=09=09if ((level =3D=3D 1 && next_ip =3D=3D lr) ||
+=09=09=09 (level <=3D 1 && !kernel_text_address(next_ip)))
+=09=09=09=09next_ip =3D 0;
+
+=09=09=09++level;
+=09=09}
+
+=09=09callchain_store(entry, next_ip);
+=09=09if (!valid_next_sp(next_sp, sp))
+=09=09=09return;
+=09=09sp =3D next_sp;
+=09}
+}
+
+#ifdef CONFIG_PPC64
+
+#ifdef CONFIG_HUGETLB_PAGE
+#define is_huge_psize(pagesize)=09(HPAGE_SHIFT && mmu_huge_psizes[page=
size])
+#else
+#define is_huge_psize(pagesize)=090
+#endif
+
+/*
+ * On 64-bit we don't want to invoke hash_page on user addresses from
+ * interrupt context, so if the access faults, we read the page tables=
+ * to find which page (if any) is mapped and access it directly.
+ */
+static int read_user_stack_slow(void __user *ptr, void *ret, int nb)
+{
+=09pgd_t *pgdir;
+=09pte_t *ptep, pte;
+=09int pagesize;
+=09unsigned long addr =3D (unsigned long) ptr;
+=09unsigned long offset;
+=09unsigned long pfn;
+=09void *kaddr;
+
+=09pgdir =3D current->mm->pgd;
+=09if (!pgdir)
+=09=09return -EFAULT;
+
+=09pagesize =3D get_slice_psize(current->mm, addr);
+
+=09/* align address to page boundary */
+=09offset =3D addr & ((1ul << mmu_psize_defs[pagesize].shift) - 1);
+=09addr -=3D offset;
+
+=09if (is_huge_psize(pagesize))
+=09=09ptep =3D huge_pte_offset(current->mm, addr);
+=09else
+=09=09ptep =3D find_linux_pte(pgdir, addr);
+
+=09if (ptep =3D=3D NULL)
+=09=09return -EFAULT;
+=09pte =3D *ptep;
+=09if (!pte_present(pte) || !(pte_val(pte) & _PAGE_USER))
+=09=09return -EFAULT;
+=09pfn =3D pte_pfn(pte);
+=09if (!page_is_ram(pfn))
+=09=09return -EFAULT;
+
+=09/* no highmem to worry about here */
+=09kaddr =3D pfn_to_kaddr(pfn);
+=09memcpy(ret, kaddr + offset, nb);
+=09return 0;
+}
+
+static int read_user_stack_64(unsigned long __user *ptr, unsigned long=
*ret)
+{
+=09if ((unsigned long)ptr > TASK_SIZE - sizeof(unsigned long) ||
+=09 ((unsigned long)ptr & 7))
+=09=09return -EFAULT;
+
+=09if (!__get_user_inatomic(*ret, ptr))
+=09=09return 0;
+
+=09return read_user_stack_slow(ptr, ret, 8);
+}
+
+static int read_user_stack_32(unsigned int __user *ptr, unsigned int *=
ret)
+{
+=09if ((unsigned long)ptr > TASK_SIZE - sizeof(unsigned int) ||
+=09 ((unsigned long)ptr & 3))
+=09=09return -EFAULT;
+
+=09if (!__get_user_inatomic(*ret, ptr))
+=09=09return 0;
+
+=09return read_user_stack_slow(ptr, ret, 4);
+}
+
+static inline int valid_user_sp(unsigned long sp, int is_64)
+{
+=09if (!sp || (sp & 7) || sp > (is_64 ? TASK_SIZE : 0x100000000UL) - 3=
2)
+=09=09return 0;
+=09return 1;
+}
+
+/*
+ * 64-bit user processes use the same stack frame for RT and non-RT si=
gnals.
+ */
+struct signal_frame_64 {
+=09char=09=09dummy[__SIGNAL_FRAMESIZE];
+=09struct ucontext=09uc;
+=09unsigned long=09unused[2];
+=09unsigned int=09tramp[6];
+=09struct siginfo=09*pinfo;
+=09void=09=09*puc;
+=09struct siginfo=09info;
+=09char=09=09abigap[288];
+};
+
+static int is_sigreturn_64_address(unsigned long nip, unsigned long fp=
)
+{
+=09if (nip =3D=3D fp + offsetof(struct signal_frame_64, tramp))
+=09=09return 1;
+=09if (vdso64_rt_sigtramp && current->mm->context.vdso_base &&
+=09 nip =3D=3D current->mm->context.vdso_base + vdso64_rt_sigtramp)=
+=09=09return 1;
+=09return 0;
+}
+
+/*
+ * Do some sanity checking on the signal frame pointed to by sp.
+ * We check the pinfo and puc pointers in the frame.
+ */
+static int sane_signal_64_frame(unsigned long sp)
+{
+=09struct signal_frame_64 __user *sf;
+=09unsigned long pinfo, puc;
+
+=09sf =3D (struct signal_frame_64 __user *) sp;
+=09if (read_user_stack_64((unsigned long __user *) &sf->pinfo, &pinfo)=
||
+=09 read_user_stack_64((unsigned long __user *) &sf->puc, &puc))
+=09=09return 0;
+=09return pinfo =3D=3D (unsigned long) &sf->info &&
+=09=09puc =3D=3D (unsigned long) &sf->uc;
+}
+
+static void perf_callchain_user_64(struct pt_regs *regs,
+=09=09=09=09 struct perf_callchain_entry *entry)
+{
+=09unsigned long sp, next_sp;
+=09unsigned long next_ip;
+=09unsigned long lr;
+=09long level =3D 0;
+=09struct signal_frame_64 __user *sigframe;
+=09unsigned long __user *fp, *uregs;
+
+=09next_ip =3D regs->nip;
+=09lr =3D regs->link;
+=09sp =3D regs->gpr[1];
+=09callchain_store(entry, PERF_CONTEXT_USER);
+=09callchain_store(entry, next_ip);
+
+=09for (;;) {
+=09=09fp =3D (unsigned long __user *) sp;
+=09=09if (!valid_user_sp(sp, 1) || read_user_stack_64(fp, &next_sp))
+=09=09=09return;
+=09=09if (level > 0 && read_user_stack_64(&fp[2], &next_ip))
+=09=09=09return;
+
+=09=09/*
+=09=09 * Note: the next_sp - sp >=3D signal frame size check
+=09=09 * is true when next_sp < sp, which can happen when
+=09=09 * transitioning from an alternate signal stack to the
+=09=09 * normal stack.
+=09=09 */
+=09=09if (next_sp - sp >=3D sizeof(struct signal_frame_64) &&
+=09=09 (is_sigreturn_64_address(next_ip, sp) ||
+=09=09 (level <=3D 1 && is_sigreturn_64_address(lr, sp))) &&
+=09=09 sane_signal_64_frame(sp)) {
+=09=09=09/*
+=09=09=09 * This looks like an signal frame
+=09=09=09 */
+=09=09=09sigframe =3D (struct signal_frame_64 __user *) sp;
+=09=09=09uregs =3D sigframe->uc.uc_mcontext.gp_regs;
+=09=09=09if (read_user_stack_64(&uregs[PT_NIP], &next_ip) ||
+=09=09=09 read_user_stack_64(&uregs[PT_LNK], &lr) ||
+=09=09=09 read_user_stack_64(&uregs[PT_R1], &sp))
+=09=09=09=09return;
+=09=09=09level =3D 0;
+=09=09=09callchain_store(entry, PERF_CONTEXT_USER);
+=09=09=09callchain_store(entry, next_ip);
+=09=09=09continue;
+=09=09}
+
+=09=09if (level =3D=3D 0)
+=09=09=09next_ip =3D lr;
+=09=09callchain_store(entry, next_ip);
+=09=09++level;
+=09=09sp =3D next_sp;
+=09}
+}
+
+static inline int current_is_64bit(void)
+{
+=09/*
+=09 * We can't use test_thread_flag() here because we may be on an
+=09 * interrupt stack, and the thread flags don't get copied over
+=09 * from the thread_info on the main stack to the interrupt stack.
+=09 */
+=09return !test_ti_thread_flag(task_thread_info(current), TIF_32BIT);
+}
+
+#else /* CONFIG_PPC64 */
+/*
+ * On 32-bit we just access the address and let hash_page create a
+ * HPTE if necessary, so there is no need to fall back to reading
+ * the page tables. Since this is called at interrupt level,
+ * do_page_fault() won't treat a DSI as a page fault.
+ */
+static int read_user_stack_32(unsigned int __user *ptr, unsigned int *=
ret)
+{
+=09if ((unsigned long)ptr > TASK_SIZE - sizeof(unsigned int) ||
+=09 ((unsigned long)ptr & 3))
+=09=09return -EFAULT;
+
+=09return __get_user_inatomic(*ret, ptr);
+}
+
+static inline void perf_callchain_user_64(struct pt_regs *regs,
+=09=09=09=09=09 struct perf_callchain_entry *entry)
+{
+}
+
+static inline int current_is_64bit(void)
+{
+=09return 0;
+}
+
+static inline int valid_user_sp(unsigned long sp, int is_64)
+{
+=09if (!sp || (sp & 7) || sp > TASK_SIZE - 32)
+=09=09return 0;
+=09return 1;
+}
+
+#define __SIGNAL_FRAMESIZE32=09__SIGNAL_FRAMESIZE
+#define sigcontext32=09=09sigcontext
+#define mcontext32=09=09mcontext
+#define ucontext32=09=09ucontext
+#define compat_siginfo_t=09struct siginfo
+
+#endif /* CONFIG_PPC64 */
+
+/*
+ * Layout for non-RT signal frames
+ */
+struct signal_frame_32 {
+=09char=09=09=09dummy[__SIGNAL_FRAMESIZE32];
+=09struct sigcontext32=09sctx;
+=09struct mcontext32=09mctx;
+=09int=09=09=09abigap[56];
+};
+
+/*
+ * Layout for RT signal frames
+ */
+struct rt_signal_frame_32 {
+=09char=09=09=09dummy[__SIGNAL_FRAMESIZE32 + 16];
+=09compat_siginfo_t=09info;
+=09struct ucontext32=09uc;
+=09int=09=09=09abigap[56];
+};
+
+static int is_sigreturn_32_address(unsigned int nip, unsigned int fp)
+{
+=09if (nip =3D=3D fp + offsetof(struct signal_frame_32, mctx.mc_pad))
+=09=09return 1;
+=09if (vdso32_sigtramp && current->mm->context.vdso_base &&
+=09 nip =3D=3D current->mm->context.vdso_base + vdso32_sigtramp)
+=09=09return 1;
+=09return 0;
+}
+
+static int is_rt_sigreturn_32_address(unsigned int nip, unsigned int f=
p)
+{
+=09if (nip =3D=3D fp + offsetof(struct rt_signal_frame_32,
+=09=09=09=09 uc.uc_mcontext.mc_pad))
+=09=09return 1;
+=09if (vdso32_rt_sigtramp && current->mm->context.vdso_base &&
+=09 nip =3D=3D current->mm->context.vdso_base + vdso32_rt_sigtramp)=
+=09=09return 1;
+=09return 0;
+}
+
+static int sane_signal_32_frame(unsigned int sp)
+{
+=09struct signal_frame_32 __user *sf;
+=09unsigned int regs;
+
+=09sf =3D (struct signal_frame_32 __user *) (unsigned long) sp;
+=09if (read_user_stack_32((unsigned int __user *) &sf->sctx.regs, ®=
s))
+=09=09return 0;
+=09return regs =3D=3D (unsigned long) &sf->mctx;
+}
+
+static int sane_rt_signal_32_frame(unsigned int sp)
+{
+=09struct rt_signal_frame_32 __user *sf;
+=09unsigned int regs;
+
+=09sf =3D (struct rt_signal_frame_32 __user *) (unsigned long) sp;
+=09if (read_user_stack_32((unsigned int __user *) &sf->uc.uc_regs, &re=
gs))
+=09=09return 0;
+=09return regs =3D=3D (unsigned long) &sf->uc.uc_mcontext;
+}
+
+static unsigned int __user *signal_frame_32_regs(unsigned int sp,
+=09=09=09=09unsigned int next_sp, unsigned int next_ip)
+{
+=09struct mcontext32 __user *mctx =3D NULL;
+=09struct signal_frame_32 __user *sf;
+=09struct rt_signal_frame_32 __user *rt_sf;
+
+=09/*
+=09 * Note: the next_sp - sp >=3D signal frame size check
+=09 * is true when next_sp < sp, for example, when
+=09 * transitioning from an alternate signal stack to the
+=09 * normal stack.
+=09 */
+=09if (next_sp - sp >=3D sizeof(struct signal_frame_32) &&
+=09 is_sigreturn_32_address(next_ip, sp) &&
+=09 sane_signal_32_frame(sp)) {
+=09=09sf =3D (struct signal_frame_32 __user *) (unsigned long) sp;
+=09=09mctx =3D &sf->mctx;
+=09}
+
+=09if (!mctx && next_sp - sp >=3D sizeof(struct rt_signal_frame_32) &&=
+=09 is_rt_sigreturn_32_address(next_ip, sp) &&
+=09 sane_rt_signal_32_frame(sp)) {
+=09=09rt_sf =3D (struct rt_signal_frame_32 __user *) (unsigned long) s=
p;
+=09=09mctx =3D &rt_sf->uc.uc_mcontext;
+=09}
+
+=09if (!mctx)
+=09=09return NULL;
+=09return mctx->mc_gregs;
+}
+
+static void perf_callchain_user_32(struct pt_regs *regs,
+=09=09=09=09 struct perf_callchain_entry *entry)
+{
+=09unsigned int sp, next_sp;
+=09unsigned int next_ip;
+=09unsigned int lr;
+=09long level =3D 0;
+=09unsigned int __user *fp, *uregs;
+
+=09next_ip =3D regs->nip;
+=09lr =3D regs->link;
+=09sp =3D regs->gpr[1];
+=09callchain_store(entry, PERF_CONTEXT_USER);
+=09callchain_store(entry, next_ip);
+
+=09while (entry->nr < PERF_MAX_STACK_DEPTH) {
+=09=09fp =3D (unsigned int __user *) (unsigned long) sp;
+=09=09if (!valid_user_sp(sp, 0) || read_user_stack_32(fp, &next_sp))
+=09=09=09return;
+=09=09if (level > 0 && read_user_stack_32(&fp[1], &next_ip))
+=09=09=09return;
+
+=09=09uregs =3D signal_frame_32_regs(sp, next_sp, next_ip);
+=09=09if (!uregs && level <=3D 1)
+=09=09=09uregs =3D signal_frame_32_regs(sp, next_sp, lr);
+=09=09if (uregs) {
+=09=09=09/*
+=09=09=09 * This looks like an signal frame, so restart
+=09=09=09 * the stack trace with the values in it.
+=09=09=09 */
+=09=09=09if (read_user_stack_32(&uregs[PT_NIP], &next_ip) ||
+=09=09=09 read_user_stack_32(&uregs[PT_LNK], &lr) ||
+=09=09=09 read_user_stack_32(&uregs[PT_R1], &sp))
+=09=09=09=09return;
+=09=09=09level =3D 0;
+=09=09=09callchain_store(entry, PERF_CONTEXT_USER);
+=09=09=09callchain_store(entry, next_ip);
+=09=09=09continue;
+=09=09}
+
+=09=09if (level =3D=3D 0)
+=09=09=09next_ip =3D lr;
+=09=09callchain_store(entry, next_ip);
+=09=09++level;
+=09=09sp =3D next_sp;
+=09}
+}
+
+/*
+ * Since we can't get PMU interrupts inside a PMU interrupt handler,
+ * we don't need separate irq and nmi entries here.
+ */
+static DEFINE_PER_CPU(struct perf_callchain_entry, callchain);
+
+struct perf_callchain_entry *perf_callchain(struct pt_regs *regs)
+{
+=09struct perf_callchain_entry *entry =3D &__get_cpu_var(callchain);
+
+=09entry->nr =3D 0;
+
+=09if (current->pid =3D=3D 0)=09=09/* idle task? */
+=09=09return entry;
+
+=09if (!user_mode(regs)) {
+=09=09perf_callchain_kernel(regs, entry);
+=09=09if (current->mm)
+=09=09=09regs =3D task_pt_regs(current);
+=09=09else
+=09=09=09regs =3D NULL;
+=09}
+
+=09if (regs) {
+=09=09if (current_is_64bit())
+=09=09=09perf_callchain_user_64(regs, entry);
+=09=09else
+=09=09=09perf_callchain_user_32(regs, entry);
+=09}
+
+=09return entry;
+}
--=20
1.6.0.4
^ permalink raw reply related
* [PATCH 1/3 v3] powerpc/32: Always order writes to halves of 64-bit PTEs
From: Paul Mackerras @ 2009-08-17 23:00 UTC (permalink / raw)
To: linuxppc-dev
On 32-bit systems with 64-bit PTEs, the PTEs have to be written in two
32-bit halves. On SMP we write the higher-order half and then the
lower-order half, with a write barrier between the two halves, but on
UP there was no particular ordering of the writes to the two halves.
This extends the ordering that we already do on SMP to the UP case as
well. The reason is that with the perf_counter subsystem potentially
accessing user memory at interrupt time to get stack traces, we have
to be careful not to create an incorrect but apparently valid PTE even
on UP.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/pgtable.h | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
index eb17da7..2a5da06 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -104,8 +104,8 @@ static inline void __set_pte_at(struct mm_struct *mm, unsigned long addr,
else
pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte));
-#elif defined(CONFIG_PPC32) && defined(CONFIG_PTE_64BIT) && defined(CONFIG_SMP)
- /* Second case is 32-bit with 64-bit PTE in SMP mode. In this case, we
+#elif defined(CONFIG_PPC32) && defined(CONFIG_PTE_64BIT)
+ /* Second case is 32-bit with 64-bit PTE. In this case, we
* can just store as long as we do the two halves in the right order
* with a barrier in between. This is possible because we take care,
* in the hash code, to pre-invalidate if the PTE was already hashed,
@@ -140,7 +140,7 @@ static inline void __set_pte_at(struct mm_struct *mm, unsigned long addr,
#else
/* Anything else just stores the PTE normally. That covers all 64-bit
- * cases, and 32-bit non-hash with 64-bit PTEs in UP mode
+ * cases, and 32-bit non-hash with 32-bit PTEs.
*/
*ptep = pte;
#endif
--
1.6.0.4
^ permalink raw reply related
* Re: simple gpio driver
From: Anton Vorontsov @ 2009-08-17 23:38 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, hs
In-Reply-To: <fa686aa40908171418k57ce5ff6iac44a72171bcf14a@mail.gmail.com>
Oops, I missed that patch, sorry.
On Mon, Aug 17, 2009 at 03:18:37PM -0600, Grant Likely wrote:
> On Wed, Aug 12, 2009 at 11:49 PM, Heiko Schocher<hs@denx.de> wrote:
> > Hello Anton,
> >
> > i am trying to use the arch/powerpc/sysdev/simple_gpio.c driver,
> > for accessing some gpios, and found, that u8_gpio_get()
> > returns not only a 1 or a 0, instead it returns the real bit
> > position from the gpio:
> >
> > gpio return
> > base value
> > 0 0/0x01
> > 1 0/0x02
> > 2 0/0x04
> > 3 0/0x08
> > 4 0/0x10
> > 5 0/0x20
> > 6 0/0x40
> > 7 0/0x80
> >
> > I also use the arch/powerpc/platforms/52xx/mpc52xx_gpio.c and
> > mpc52xx_gpt.c drivers, they all return for a gpio just a 1 or 0,
There is also arch/powerpc/sysdev/qe_lib/gpio.c and
arch/powerpc/sysdev/mpc8xxx_gpio.c that don't do that.
> > which seems correct to me, because a gpio can have only 1 or 0
> > as state ... what do you think?
>
> I think returning '1' is perhaps slightly 'better' (however you define
> that), but I don't think the caller should make any assumptions beyond
> zero/non-zero.
Yep. So I don't think that the patch is needed.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 1/3 v3] powerpc/32: Always order writes to halves of 64-bit PTEs
From: Kumar Gala @ 2009-08-18 0:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <19081.57584.173693.798535@cargo.ozlabs.ibm.com>
On Aug 17, 2009, at 6:00 PM, Paul Mackerras wrote:
> On 32-bit systems with 64-bit PTEs, the PTEs have to be written in two
> 32-bit halves. On SMP we write the higher-order half and then the
> lower-order half, with a write barrier between the two halves, but on
> UP there was no particular ordering of the writes to the two halves.
>
> This extends the ordering that we already do on SMP to the UP case as
> well. The reason is that with the perf_counter subsystem potentially
> accessing user memory at interrupt time to get stack traces, we have
> to be careful not to create an incorrect but apparently valid PTE even
> on UP.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> arch/powerpc/include/asm/pgtable.h | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
Just out of interest did you end up hitting this in testing?
- k
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox