Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1226211

Re: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early in boot process

Show all headers | View raw

On 16/09/15 14:05, Will Deacon wrote:
> On Mon, Sep 14, 2015 at 02:26:17PM +0100, Daniel Thompson wrote:
>> Currently alternatives are applied very late in the boot process (and
>> a long time after we enable scheduling). Some alternative sequences,
>> such as those that alter the way CPU context is stored, must be applied
>> much earlier in the boot sequence.
>>
>> Introduce apply_alternatives_early() to allow some alternatives to be
>> applied immediately after we detect the CPU features of the boot CPU.
>>
>> Currently apply_alternatives_all() is not optimized and will re-patch
>> code that has already been updated. This is harmless but could be
>> removed by adding extra flags to the alternatives store.
>>
>> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
>> ---
> [snip]
>>   /*
>> + * This is called very early in the boot process (directly after we run
>> + * a feature detect on the boot CPU). No need to worry about other CPUs
>> + * here.
>> + */
>> +void apply_alternatives_early(void)
>> +{
>> +	struct alt_region region = {
>> +		.begin	= __alt_instructions,
>> +		.end	= __alt_instructions_end,
>> +	};
>> +
>> +	__apply_alternatives(&region);
>> +}
>
> How do you choose which alternatives are applied early and which are
> applied later? AFAICT, this just applies everything before we've
> established the capabilities of the CPUs in the system, which could cause
> problems for big/little SoCs.

They are applied twice. This relies for correctness on the fact that 
cpufeatures can be set but not unset.

In other words the boot CPU does a feature detect and, as a result, a 
subset of the required alternatives will be applied. However after this 
the other CPUs will boot and the the remaining alternatives applied as 
before.

The current implementation is inefficient (because it will redundantly 
patch the same code twice) but I don't think it is broken.


> Also, why do we need this for the NMI?

I was/am concerned that a context saved before the alternatives are 
applied might be restored afterwards. If that happens the bit that 
indicates what value to put into the PMR would read during the restore 
without having been saved first. Applying early ensures that the context 
save/restore code is updated before it is ever used.


Daniel.

--
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/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early in boot process Daniel Thompson <daniel.thompson@linaro.org> - 2015-09-14 15:30 +0200
  Re: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early  in boot process Will Deacon <will.deacon@arm.com> - 2015-09-16 15:10 +0200
    Re: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early  in boot process Daniel Thompson <daniel.thompson@linaro.org> - 2015-09-16 18:00 +0200
      Re: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early  in boot process Will Deacon <will.deacon@arm.com> - 2015-09-16 18:30 +0200
        Re: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early  in boot process Daniel Thompson <daniel.thompson@linaro.org> - 2015-09-17 15:30 +0200
          Re: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early  in boot process Will Deacon <will.deacon@arm.com> - 2015-09-17 16:10 +0200
            Re: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early  in boot process Daniel Thompson <daniel.thompson@linaro.org> - 2015-09-17 17:30 +0200
              Re: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early  in boot process Will Deacon <will.deacon@arm.com> - 2015-09-17 17:50 +0200

csiph-web