On May 16, 2013, at 5:36 PM, Chip Ueltschey <chipj...@gmail.com> wrote:
> Andrew,
>
> Yes, and there is an interaction between signals and threads. When we create
> and event and provide the callback, I am suggesting that this is like a
> thread.
Preemption does not a thread make. Threads execute independently of each other
and provide an abstraction of concurrent execution. Signals provide an
abstraction of preemption, or actions based on events.
> When the event is signaled for whatever reason, this is like a signal for
> that thread.
No when an event is singled it is put into the signal queue. Events are
dispatched off the signal queue only when gBS->RestoreTPL() is called.
The confusing bit is the EFI Timer handler in the Timer AP driver will
gBS->RaiseTPL to TPL_HIGH_LEVEL and call the DXE Core where the Tick handler
will queue up and pending timer events. The 1st chance for these events to get
dispatched is back in the Timer AP when it does the gBS->RestoreTPL().
I think I mentioned in the previous mail that POSIX signals include a timer
event. It is also possible in POSIX, using sigmask, to mask any signal, so this
is similar to RaiseTPL in EFI.
> But I asked the question because I realize I could be confused here, so maybe
> you can help me see how UEFI Events are not fundamentally threadlike.
I think this is an interesting and useful discussion to have on the mailing
list for folks.
I think there is some confusion between signals and threads. So for example if
you are using pthreads you get your signals sent to all your threads, but if
you use pthreads you can't use sigmask, as you have to use pthread_sigmask. I
think this points out that signaling another thread is really part of the
thread model and not the signal model, given the POSIX sigmask is not thread
safe.
The EmulatorPkg actually uses pthreads to emulate the APs, and a POSIX SIGALRM
to emulate the timer.
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EmulatorPkg/Unix/Host/Pthreads.c
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EmulatorPkg/Unix/Host/EmuThunk.c
OK back out of the weeds. I think the key point about threads is they provide
an abstraction of concurrent execution, and that is also what makes them so
complex. So a simple timer tick is still a signal and not a thread. Also in a
signal model it is key to yield control back, in a thread model the code would
just poll in an infinite loop taking action when needed.
Thanks,
Andrew Fish
>
> I noticed also that some of our software is making this more explicit.
> gEfiDpcProtocolGuid is used heavily in the network code.
> But I don't understand why they needed to create this? Why not just use
> events directly? Is it the FIFO enforcement, and if so why wouldn't a normal
> TPL queue provide that.
> Seems like the whole thing is just a wrapper for the TPL queues...so why did
> we need that wrapper.
> And from this point is where I have my question.
> Why are our Events looked at so differently from threads.
> I know it would be possible to make a library to provide thread services on
> top of Events.
> But maybe that is the answer to my question...but I would like to hear what
> you think.
>
> -chip
>
>
>
> On Thu, May 16, 2013 at 11:39 AM, Andrew Fish <af...@apple.com> wrote:
>
> On May 16, 2013, at 11:29 AM, Chip Ueltschey <chipj...@gmail.com> wrote:
>
>> 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,
>
> I came to the realization as some point that EFI Events are conceptually like
> Unix signals in our single threaded world.
> http://en.wikipedia.org/wiki/Unix_signal
>
> If you look at something like POSIX threads and signals are separate
> concepts. So EFI events implement a single threaded preemptive signal model.
> Basically signals can preempt, but there is only a single main thread. In EFI
> you can only have the main thread or a signaled event running.
>
> Thanks,
>
> Andrew Fish.
>
>> -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
>>
>> ------------------------------------------------------------------------------
>> 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
