Andrew,
Thanks, that helps. Threads are concurrent.
I suppose if we used MpServices to handle more than one task in the TPL
queue at once, at that point we would be thread-like.
Thanks for the help,
-chip
On Thu, May 16, 2013 at 6:53 PM, Andrew Fish <af...@apple.com> wrote:
>
> 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
>
>
------------------------------------------------------------------------------
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
