• Suzuki K Poulose's avatar
    arm64: capabilities: Prepare for fine grained capabilities · 143ba05d
    Suzuki K Poulose authored
    We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
    to the userspace and the CPU hwcaps used by the kernel, which
    include cpu features and CPU errata work arounds. Capabilities
    have some properties that decide how they should be treated :
    
     1) Detection, i.e scope : A cap could be "detected" either :
        - if it is present on at least one CPU (SCOPE_LOCAL_CPU)
    	Or
        - if it is present on all the CPUs (SCOPE_SYSTEM)
    
     2) When is it enabled ? - A cap is treated as "enabled" when the
      system takes some action based on whether the capability is detected or
      not. e.g, setting some control register, patching the kernel code.
      Right now, we treat all caps are enabled at boot-time, after all
      the CPUs are brought up by the kernel. But there are certain caps,
      which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
      and kernel starts using them, even before the secondary CPUs are brought
      up. We would need a way to describe this for each capability.
    
     3) Conflict on a late CPU - When a CPU is brought up, it is checked
      against the caps that are known to be enabled on the system (via
      verify_local_cpu_capabilities()). Based on the state of the capability
      on the CPU vs. that of System we could have the following combinations
      of conflict.
    
    	x-----------------------------x
    	| Type	| System   | Late CPU |
    	------------------------------|
    	|  a    |   y      |    n     |
    	------------------------------|
    	|  b    |   n      |    y     |
    	x-----------------------------x
    
      Case (a) is not permitted for caps which are system features, which the
      system expects all the CPUs to have (e.g VHE). While (a) is ignored for
      all errata work arounds. However, there could be exceptions to the plain
      filtering approach. e.g, KPTI is an optional feature for a late CPU as
      long as the system already enables it.
    
      Case (b) is not permitted for errata work arounds which requires some
      work around, which cannot be delayed. And we ignore (b) for features.
      Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
      are too late to enable it (because we change the allocation of ASIDs
      etc).
    
    So this calls for a lot more fine grained behavior for each capability.
    And if we define all the attributes to control their behavior properly,
    we may be able to use a single table for the CPU hwcaps (which cover
    errata and features, not the ELF HWCAPs). This is a prepartory step
    to get there. More bits would be added for the properties listed above.
    
    We are going to use a bit-mask to encode all the properties of a
    capabilities. This patch encodes the "SCOPE" of the capability.
    
    As such there is no change in how the capabilities are treated.
    
    Cc: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
    Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    143ba05d
cpufeature.h 12.9 KB