cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

cpu_features.rst (2730B)


      1============
      2CPU Features
      3============
      4
      5Hollis Blanchard <hollis@austin.ibm.com>
      65 Jun 2002
      7
      8This document describes the system (including self-modifying code) used in the
      9PPC Linux kernel to support a variety of PowerPC CPUs without requiring
     10compile-time selection.
     11
     12Early in the boot process the ppc32 kernel detects the current CPU type and
     13chooses a set of features accordingly. Some examples include Altivec support,
     14split instruction and data caches, and if the CPU supports the DOZE and NAP
     15sleep modes.
     16
     17Detection of the feature set is simple. A list of processors can be found in
     18arch/powerpc/kernel/cputable.c. The PVR register is masked and compared with
     19each value in the list. If a match is found, the cpu_features of cur_cpu_spec
     20is assigned to the feature bitmask for this processor and a __setup_cpu
     21function is called.
     22
     23C code may test 'cur_cpu_spec[smp_processor_id()]->cpu_features' for a
     24particular feature bit. This is done in quite a few places, for example
     25in ppc_setup_l2cr().
     26
     27Implementing cpufeatures in assembly is a little more involved. There are
     28several paths that are performance-critical and would suffer if an array
     29index, structure dereference, and conditional branch were added. To avoid the
     30performance penalty but still allow for runtime (rather than compile-time) CPU
     31selection, unused code is replaced by 'nop' instructions. This nop'ing is
     32based on CPU 0's capabilities, so a multi-processor system with non-identical
     33processors will not work (but such a system would likely have other problems
     34anyways).
     35
     36After detecting the processor type, the kernel patches out sections of code
     37that shouldn't be used by writing nop's over it. Using cpufeatures requires
     38just 2 macros (found in arch/powerpc/include/asm/cputable.h), as seen in head.S
     39transfer_to_handler::
     40
     41	#ifdef CONFIG_ALTIVEC
     42	BEGIN_FTR_SECTION
     43		mfspr	r22,SPRN_VRSAVE		/* if G4, save vrsave register value */
     44		stw	r22,THREAD_VRSAVE(r23)
     45	END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
     46	#endif /* CONFIG_ALTIVEC */
     47
     48If CPU 0 supports Altivec, the code is left untouched. If it doesn't, both
     49instructions are replaced with nop's.
     50
     51The END_FTR_SECTION macro has two simpler variations: END_FTR_SECTION_IFSET
     52and END_FTR_SECTION_IFCLR. These simply test if a flag is set (in
     53cur_cpu_spec[0]->cpu_features) or is cleared, respectively. These two macros
     54should be used in the majority of cases.
     55
     56The END_FTR_SECTION macros are implemented by storing information about this
     57code in the '__ftr_fixup' ELF section. When do_cpu_ftr_fixups
     58(arch/powerpc/kernel/misc.S) is invoked, it will iterate over the records in
     59__ftr_fixup, and if the required feature is not present it will loop writing
     60nop's from each BEGIN_FTR_SECTION to END_FTR_SECTION.