Revision 595d153dd1022392083ac93a1550382cbee127e0 authored by Michael Ellerman on 26 May 2020, 06:18:08 UTC, committed by Michael Ellerman on 26 May 2020, 07:32:37 UTC
Commit 702f09805222 ("powerpc/64s/exception: Remove lite interrupt
return") changed the interrupt return path to not restore non-volatile
registers by default, and explicitly restore them in paths where it is
required.

But it missed that the facility unavailable exception can sometimes
modify user registers, ie. when it does emulation of move from DSCR.

This is seen as a failure of the dscr_sysfs_thread_test:
  test: dscr_sysfs_thread_test
  [cpu 0] User DSCR should be 1 but is 0
  failure: dscr_sysfs_thread_test

So restore non-volatile GPRs after facility unavailable exceptions.

Currently the hypervisor facility unavailable exception is also wired
up to call facility_unavailable_exception().

In practice we should never take a hypervisor facility unavailable
exception for the DSCR. On older bare metal systems we set HFSCR_DSCR
unconditionally in __init_HFSCR, or on newer systems it should be
enabled via the "data-stream-control-register" device tree CPU
feature.

Even if it's not, since commit f3c99f97a3cd ("KVM: PPC: Book3S HV:
Don't access HFSCR, LPIDR or LPCR when running nested"), the KVM code
has unconditionally set HFSCR_DSCR when running guests.

So we should only get a hypervisor facility unavailable for the DSCR
if skiboot has disabled the "data-stream-control-register" feature,
and we are somehow in guest context but not via KVM.

Given all that, it should be unnecessary to add a restore of
non-volatile GPRs after the hypervisor facility exception, because we
never expect to hit that path. But equally we may as well add the
restore, because we never expect to hit that path, and if we ever did,
at least we would correctly restore the registers to their post
emulation state.

In future we can split the non-HV and HV facility unavailable handling
so that there is no emulation in the HV handler, and then remove the
restore for the HV case.

Fixes: 702f09805222 ("powerpc/64s/exception: Remove lite interrupt return")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200526061808.2472279-1-mpe@ellerman.id.au
1 parent 8659a0e
Raw File
Kconfig.hz
# SPDX-License-Identifier: GPL-2.0-only
#
# Timer Interrupt Frequency Configuration
#

choice
	prompt "Timer frequency"
	default HZ_250
	help
	 Allows the configuration of the timer frequency. It is customary
	 to have the timer interrupt run at 1000 Hz but 100 Hz may be more
	 beneficial for servers and NUMA systems that do not need to have
	 a fast response for user interaction and that may experience bus
	 contention and cacheline bounces as a result of timer interrupts.
	 Note that the timer interrupt occurs on each processor in an SMP
	 environment leading to NR_CPUS * HZ number of timer interrupts
	 per second.


	config HZ_100
		bool "100 HZ"
	help
	  100 Hz is a typical choice for servers, SMP and NUMA systems
	  with lots of processors that may show reduced performance if
	  too many timer interrupts are occurring.

	config HZ_250
		bool "250 HZ"
	help
	 250 Hz is a good compromise choice allowing server performance
	 while also showing good interactive responsiveness even
	 on SMP and NUMA systems. If you are going to be using NTSC video
	 or multimedia, selected 300Hz instead.

	config HZ_300
		bool "300 HZ"
	help
	 300 Hz is a good compromise choice allowing server performance
	 while also showing good interactive responsiveness even
	 on SMP and NUMA systems and exactly dividing by both PAL and
	 NTSC frame rates for video and multimedia work.

	config HZ_1000
		bool "1000 HZ"
	help
	 1000 Hz is the preferred choice for desktop systems and other
	 systems requiring fast interactive responses to events.

endchoice

config HZ
	int
	default 100 if HZ_100
	default 250 if HZ_250
	default 300 if HZ_300
	default 1000 if HZ_1000

config SCHED_HRTICK
	def_bool HIGH_RES_TIMERS
back to top