See Ousterhout’s distinction on threaded versus event-based programming

 

http://www.cc.gatech.edu/classes/AY2009/cs4210_fall/papers/ousterhout-threads.pdf

 

 

 

From: Chip Ueltschey [mailto:chipj...@gmail.com] 
Sent: Thursday, May 16, 2013 11:29 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] how timer and interrupt works in UEFI?

 

Andrew,

 

Can't we think of UEFI as being preemptive and threaded; the event handlers are 
like threads. Certainly we are missing some infrastructure for thread-like 
constructs, but I am just curious about what you mean when you say "signal 
based and not threaded."

 

-chip

 

On Thu, May 16, 2013 at 11:08 AM, Andrew Fish <af...@apple.com> wrote:



On May 16, 2013, at 10:50 AM, Tim Lewis <tim.le...@insyde.com> wrote:

> Stephen --
>
> No, on most UEFI implementations timer is running and, in the shell, 
> polling-related events are happening all the time (to check for input-related 
> device status change)
>
> Could the DXE core do on-demand only? Probably, but that is not the current 
> EDK2 implementation, as far as I understand it.
>

Tim you are correct. The CoreTimerTick() function in the DXE gets called at the 
default period set by the Timer Architectural Protocol. The CoreTimerTick() 
checks the internal queues and decides if an EFI based timer event needs to be 
signaled. The timer tick starts when the Timer Architectural protocol driver is 
loaded, and the code I pointed to was an event handler for the installation of 
architectural protocols by a driver in the DXE Core. By definition all the PI 
architectural protocol drivers must be loaded prior to running any EFI 
driver/application since they are needed to make all the EFI services work. 
This is why no dependency expression in a drivers INF file means depend on all 
architectural protocols and does not imply a depex of TRUE.

Given drivers like USB and networking always use the timer tick, even if an 
optimization was made to "adjust the period" based on need ticks would still be 
happening.

Since EFI is signal based and not threaded, you are either in the main thread 
(running a driver or applications entry point) or a signaled event. Thus if you 
are in the CoreTimerTick() and no event is called that time conceptually is 
waisted (you could have been doing work on the main thread). I guess some one 
could profile how much time in the boot is spent in a CoreTimerTick() where no 
work is done and that is the best case how much boot time your could get back 
from reprogramming the timer tick to the next needed value. There will be some 
amount of book keeping required to calculate these values to program into the 
timer.

Thanks,

Andrew Fish


> Tim
>
> -----Original Message-----
> From: Stephen Polkowski [mailto:step...@centtech.com]
> Sent: Thursday, May 16, 2013 10:31 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] how timer and interrupt works in UEFI?
>
>
> Hi Andrew,
>
>       Thanks for answering this question.  I was curious about interrupts as 
> well.  If I understand you correctly, a timer exists and it is only used when 
> a driver or a program requests it.
>
>       So, when we come up in a basic UEFI Shell the system is essentially 
> tickless?
>
> Thanks,
>
> Stephen
>
>
> Andrew Fish wrote:
>>
>> On May 16, 2013, at 7:16 AM, "zzhh.happy" <zzhh.ha...@163.com
>> <mailto:zzhh.ha...@163.com>> wrote:
>>
>>> Hi all,
>>>
>>> I'm fresh man for studying UEFI,and there are some questions ,is
>>> there anyone can help,thanks!
>>> as we know there is only on interrupt that is the timer,it works as
>>> the  heartbeat timer.but in X86 platform i can't find the timer
>>> interrupt handle function. except bellow service *CoreTimerTick,*but
>>> there is a input parameter *Duration,*never heard that interrupt
>>> service have input parameter,if yes, who pass it in?
>>> and there are my question:
>>>
>> UEFI does not define how the timer works, just that it exists. The
>> UEFI Platform Initialization Specification 1.2.1
>> <http://www.uefi.org/specs/platform_agreement>  (also called PI spec)
>> defines how the timer works in the edk2 http://www.uefi.org/specs/.
>>
>> The PI defines a set of Architectural Protocol that produce the
>> hardware services needed to produce the EFI services. If you look in
>> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/
>> Core/Dxe/DxeMain/DxeProtocolNotify.c
>> you will see the mArchProtocols array that contains a list of these
>> architectural protocols, and some globals that filled in when the
>> protocols are registered.
>>
>> So basically the CPU AP, gEfiCpuArchProtocolGuid, abstracts interrupt
>> handling in a processor agnostic way (Same DXE Core source works for
>> Itainum, IA32, X64, and ARM). The Timer AP, gEfiTimerArchProtocolGuid,
>> depends on the CPU AP and produces the timer tick for the platform.
>>> 1.in x86 platform what is the heartbeat,is it the leagcy 8254?
>> It can be any timer. It is what ever Timer AP driver gets included in
>> the firmware. Search for drivers installing gEfiTimerArchProtocolGuid.
>>> 2.what is the interrupt vector number?
>> There is not a standard. It is platform specific and set by the driver.
>> Some drivers may offer a PCD config setting to change the vector.
>>> 3.where is the IDT table exist in memery after the timer start
>>> ticking
>> The CPU AP driver sets up the IDT. For X64/IA32 the IDT is not at a
>> fixed address. Search for a driver installing gEfiCpuArchProtocolGuid.
>> Note: There is an assemble instruction that lets you know the address,
>> but it is probably a very bad idea to patch anything into the table
>> directly as debuggers need to cooperate with the CPU AP to hook
>> vectors, so you may break the debugger or the CPU AP. You can use
>> gEfiCpuArchProtocolGuid services to hook an interrupt vector if that
>> is what you need to do.
>> There are C functions that implement common assembly instruction in
>> the BaseLib. So AsmReadIdtr().
>>> 4.what is the heartbeat service handle,and how it registered to the
>>> cpu's interrupt verctor table.
>> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/
>> Core/Dxe/DxeMain/DxeProtocolNotify.c
>>
>> When the Timer AP service is registered the DXE Core does:
>>
>> gTimer->RegisterHandler (gTimer, CoreTimerTick);
>>
>> Which registers the DXE Cores timer callback.
>>
>> This is an example gEfiCpuArchProtocolGuid driver:
>> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/UefiCpuPkg/Cp
>> uDxe/ This is not the driver you would find on a real platform as
>> there is a large amount of processor specific initialization that is
>> required, but it shows the general concepts.
>>
>> Thanks,
>>
>> Andrew Fish
>>>
>>> thanks very much.
>>>
>>>
>>> VOID
>>> EFIAPI
>>> *CoreTimerTick* (
>>>  IN UINT64   Duration
>>>  )
>>> /*++
>>> Routine Description:
>>>  Called by the platform code to process a tick.
>>> Arguments:  Duration    - The number of 100ns elasped since the last
>>> call to TimerTick
>>> Returns:  None
>>> --*/
>>> {
>>>  IEVENT          *Event;
>>>   // Check runtiem flag in case there are ticks while exiting boot
>>> services
>>>  CoreAcquireLock (&mEfiSystemTimeLock);
>>>  // Update the system time
>>>  mEfiSystemTime += Duration;
>>>  // If the head of the list is expired, fire the timer event
>>>  // to process it
>>>  if (!IsListEmpty (&mEfiTimerList)) {
>>>    Event = CR (mEfiTimerList.ForwardLink, IEVENT, u.Timer.Link,
>>> EVENT_SIGNATURE);
>>>    if (Event->u.Timer.TriggerTime <= mEfiSystemTime) {
>>>      CoreSignalEvent (mEfiCheckTimerEvent);
>>>    }
>>>  }
>>>  CoreReleaseLock (&mEfiSystemTimeLock); }
>>> 2013-05-16
>>> ---------------------------------------------------------------------
>>> ---
>>> zzhh.happy
>>> ---------------------------------------------------------------------
>>> --------- AlienVault Unified Security Management (USM) platform
>>> delivers complete security visibility with the essential security
>>> capabilities. Easily and efficiently configure, manage, and operate
>>> all of your security controls from a single console and one unified
>>> framework. Download a free trial.
>>> http://p.sf.net/sfu/alienvault_d2d___________________________________
>>> ____________
>>> edk2-devel mailing list
>>> edk2-devel@lists.sourceforge.net
>>> <mailto:edk2-devel@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> ----------------------------------------------------------------------
>> -------- AlienVault Unified Security Management (USM) platform
>> delivers complete security visibility with the essential security
>> capabilities. Easily and efficiently configure, manage, and operate
>> all of your security controls from a single console and one unified
>> framework. Download a free trial.
>> http://p.sf.net/sfu/alienvault_d2d
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete 
> security visibility with the essential security capabilities. Easily and 
> efficiently configure, manage, and operate all of your security controls from 
> a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to