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

[Michael Brown]

On 14/07/17 03:39, Heinrich Schuchardt wrote:
>> 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)?

We don't care about the console input interrupt, since console input is 
not latency sensitive.

We already start a 32Hz timer via CreateEvent() and SetTimer().  The 
timer interrupt must therefore be running, or the platform will not be 
able to trigger our timer event.  (In turn, this will prevent various 
timeout mechanisms from working, such as TCP retransmission.)

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

You can already do that if you want.  In config/nap.h, use e.g.

  #undef NAP_EFIX86
  #undef NAP_EFIARM
  #define NAP_NULL

Needless to say, this is an incredibly ugly 'solution'.  Users are 
entitled to reasonably expect that they do not need to learn about this 
kind of hackery; an ARM64 iPXE UEFI binary should ideally Just Work if 
run on U-Boot without any compilation quirks.

U-Boot needs to provide a working timer via the SetTimer() API, since 
this is required in order for TCP and other retransmission mechanisms. 
This implies that U-Boot is already using a timer interrupt, in which 
case your entire point is moot.

If you somehow have SetTimer() working without being interrupt driven, 
then I am prepared to commit a patch to iPXE which avoids halting the 
CPU if interrupts are disabled (at the CPU level).  You then just need 
to ensure that U-Boot explicitly disables interrupts at the CPU level 
(rather than leaving them enabled but with no active interrupt sources).

Michael