On May 16, 2013, at 11:36 AM, "Zimmer, Vincent" <vincent.zim...@intel.com>
wrote:
> See Ousterhout’s distinction on threaded versus event-based programming
>
> http://www.cc.gatech.edu/classes/AY2009/cs4210_fall/papers/ousterhout-threads.pdf
>
>
Vincent, thanks for the link. It reiterates a lot of the though processes we
went through when we decided to stick with a signal/event model and to not
enable threads in EFI. Our other big reason for not enabling threads was
determinism from boot to boot as it makes debugging and powering on early
silicon a lot easier.
For some of the same reasons we also decided to not generically enable
interrupts, but to have a timer based event. We did not want to have to
architect a software abstraction for interrupts that would last 30 years. So we
figured it was better to defer it until it was absolutely necessary (we made
this choice last Millennium, so far so good).
In general we took the philosophy with EFI that "simplicity was the ultimate
sophistication" and that good computer architecture is figuring what to leave
out. We also wanted to make a 100% hardware agnostic spec that would scale from
iPods to supercomputers. I'l admit that generalized abstractions do tend to
raise complexity, but they also tend to scale and last a long time.
For those that think that the edk2 is too complex I'd say it is driven by a few
things. The 1st is the EFI Driver Model was a retro fit in EFI 1.10, but the
biggest thing driving up complexity is the complexity in the PI specs. The
dispatching, dependency expressions, PEI, DXE, etc. were all driven by a lot of
complex marketing requirements that made them some what complex.
I'd point out that conceptually in the edk2 you could take the current DXE
Core, add your own DXE Core entry point lib that replaces PEI, and add a series
of NULL library classes that implement the architectural protocols and have the
core of EFI implemented in a single linked binary.
Thanks,
Andrew Fish
>
> 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
>
> ------------------------------------------------------------------------------
> 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
