[ipxe-devel] [PATCH 1/1] efi: provide possibility to disable cpu_nap

Heinrich Schuchardt xypron.glpk at gmx.de
Fri Jul 14 02:39:45 UTC 2017


On 07/14/2017 12:08 AM, Michael Brown wrote:
> On 13/07/17 06:50, Heinrich Schuchardt wrote:
>>> You could add code in efiarm_nap.c and/or efix86_nap.c to detect whether
>>> or not it is safe to sleep the CPU.  The attached (completely untested)
>>> patch demonstrates this idea: modify the cpu_nap() implementation in
>>> efix86_nap.c to execute "hlt" only if the platform firmware has enabled
>>> interrupts.
>>
>> By analyzing CPU registers it is not possible to find out if the
>> external hardware is set up to trigger interrupts.
> 
> It allows the platform firmware (such as U-Boot) to deliberately signal
> to other programs (such as UEFI iPXE) that interrupts are unexpectedly
> disabled.  You would have to ensure that U-Boot actually does this.
> 
> Disabling interrupts via "cli" will not prevent CPU exceptions such as
> page faults on x86.  The Intel SDM states:
> 
>   "Clearing the IF flag causes the processor to ignore maskable
>    external interrupts.  The IF flag and the CLI and STI instruction
>    have no affect on the generation of exceptions and NMI interrupts."
> 
> I assume that the equivalent is true on ARM, but you should check the
> documentation to be sure.

And what do we do if some interrupts are implemented by a platform but
not the ones you are waiting for (console input and timer)?

> 
>> What is wrong about deciding at compile time if we enable cpu_nap()?
> 
> The "#ifdef MY_PET_FEATURE" anti-pattern has been banned to the maximum
> extent possible from new iPXE code since around 2005 (before the name
> change from Etherboot to gPXE, let alone iPXE).  See
> 
>   http://dox.ipxe.org/ifdef_harmful.html
> 
> for a rationale.
> 

According to

http://dox.ipxe.org/tables_8h_source.html

a solution matching your programming guidelines would be creating a
module for cpu_nap and deciding at link time if we want to use it.

Best regards

Heinrich



More information about the ipxe-devel mailing list