Problem:
	There exists a case where we stop monitoring, i.e. clear
	psr.pp/dcr.pp, via IPI. This is when the stop is triggered
	by a close(), either explicit in the application or implicit
	via exit_files(). The IPI is necessary because at the time the
	thread (controlling the context) issues a close() it may not run
	on the CPU the context is bound to. Yet the call must succeed,
	hence we need to propagate the call to the right CPU.
	But what is the problem then?
	Under IPI, we invoke a perfmon routine which clear the kernel
	(live) kernel psr.pp bit and also dcr.pp. Then we return from
	the function and execute the kernel exit path which restores
	the interrupted state. Unfortunately, this restores the kernel
	psr from ipsr which now contains a stale value. Therefore
	monitoring in the kernel will be active even though we stopped it.
	You cannot modify the "global" psr in an interrupt routine because
	it will be systematically restored on the way back.
	
Solution:
	We need to patch ipsr.pp in the kernel exit path to reflect the
	kernel value of the kernel psr.pp bit. This must be done only when
	returning to kernel. 

	The proposed patch does patch ipsr.pp such that it is identical
	to psr.pp. The patch is subtle because the exit path does not have
	a lot of free registers and also because we need to schedule for
	a psr read. I had to shuffle  things around a little bit.

	The patch is important because there will be another situation where
	this problem can occur once we incorporate the support for event set
	and multiplexing. In this configuration, you may be in the middle of
	the idle loop and on a timer interrupt, you may stop monitoring.
	Slightly different condition, yet same problem with ipsr.pp vs. psr.pp.


Changelog:
	- update kernel exit path when returning to kernel to copy
	psr.pp to ipsr.pp. This is necesary to ensure that if psr.pp
	was modified during the kernel entry, the change is propagated
	the the psr.pp of the of the interrupted thread. Psr.pp can
	be modified as a consequence of an IPI under certain conditions,
	such as when a system-wide context is closed from a remote CPU.

Special thanks to David for reworking the patch to fit
into the enhanced exit path.
signed-off-by: stephane eranian <eranian@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>