Discussion:
[edk2] Few doubts on code execution
D chinni babu
2015-06-30 05:05:20 UTC
Permalink
Hi All,
I have few questions on UEFI Code execution.Please help me to understand
UEFI in a better way.

1) What is the need of locking mechanism and Task Priority Levels in UEFI
when there is no multi process execution in boot time?
More insight ,As Per my understanding we have only one interrupt which is
Timer interrupt which can halt the normal execution to check for Timer
events.If any Timer event needs to signal it will can and exit.
TPL is Raising to TPL_HIGH_LEVEL -1 when we look for timer events in the
Queue.
My doubt is when exactly Locking mechanism becomes handy?
TPL_APPLICATION is the normal default level execution and when we create a
event type other than EVT_TIMER , it will be executed only when we signal
the event (directly by us or indirectly by core code) when means core code
will look into the link-list and call the notification function.Everything
looks like Linear execution.


2) In locking mechanism and Task Priority Levels Core code we are using
ASSERT messages to detect the errors that means these wont be
detected/reported in Release build.correct ? if it is so ,in release build
when we have error in TPL_LEVEL change or in Locking mechanism and there is
no hardware or software issue found in Firmware execution in real time ,we
wont be able to detect .correct ?

3) In UEFI Spec Table 22 .we have a description for the TPLS Levels.

Interrupts code executing below TPL_CALLBACK level.Long term operations
(such as file system operations and disk I/O) can occur at this level.

Interrupts code executing below TPL_NOTIFY level. Blocking is not allowed
at this level. Code executes to completion and returns. If code requires
more processing, it needs to signal an event to wait to obtain control
again at whatever level it requires. This level is typically used to
process low level IO to or from a device.

I didn't seen any core code to achieve both the statements.Is there any
core code to differentiate the TPL Levels and to stop one code execution
and call the other one at different level ?

Please help to clarify these things for better understanding of UEFI.

Thanks,
Chinni.
Andrew Fish
2015-06-30 05:25:15 UTC
Permalink
Post by D chinni babu
Hi All,
I have few questions on UEFI Code execution.Please help me to understand UEFI in a better way.
1) What is the need of locking mechanism and Task Priority Levels in UEFI when there is no multi process execution in boot time?
UEFI is an event model. While this presentation is not related to UEFI in any way it is useful in explaining why we picked a simplistic event model for EFI.
https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf
Post by D chinni babu
More insight ,As Per my understanding we have only one interrupt which is Timer interrupt which can halt the normal execution to check for Timer events.If any Timer event needs to signal it will can and exit.
TPL is Raising to TPL_HIGH_LEVEL -1 when we look for timer events in the Queue.
My doubt is when exactly Locking mechanism becomes handy?
TPL_APPLICATION is the normal default level execution and when we create a event type other than EVT_TIMER , it will be executed only when we signal the event (directly by us or indirectly by core code) when means core code will look into the link-list and call the notification function.Everything looks like Linear execution.
You are thinking about a thread model, UEFI is an event module. There is just the main program (what ever driver, app, is running) and events. There is no scheduler, the main flow owns the system, and events can fire. Thus blocking events prevents reentrancy, and is used for Locks. If you look at Table 23, you will see that most interfaces, and services have TPL restrictions. Thus you only have to raise hight enough to block being called.
Post by D chinni babu
2) In locking mechanism and Task Priority Levels Core code we are using ASSERT messages to detect the errors that means these wont be detected/reported in Release build.correct ? if it is so ,in release build when we have error in TPL_LEVEL change or in Locking mechanism and there is no hardware or software issue found in Firmware execution in real time ,we wont be able to detect .correct ?
Don’t bad TPL operation is “undefined behavior” per the EFI spec and the system may crash. It is a bug in your code, so the DEBUG builds ASSERT to let you know. The release builds try to keep running. There is not much more they could do, well I guess they could log an error.
Post by D chinni babu
3) In UEFI Spec Table 22 .we have a description for the TPLS Levels.
Interrupts code executing below TPL_CALLBACK level.Long term operations (such as file system operations and disk I/O) can occur at this level.
Interrupts code executing below TPL_NOTIFY level. Blocking is not allowed at this level. Code executes to completion and returns. If code requires more processing, it needs to signal an event to wait to obtain control again at whatever level it requires. This level is typically used to process low level IO to or from a device.
I didn't seen any core code to achieve both the statements.Is there any core code to differentiate the TPL Levels and to stop one code execution and call the other one at different level ?
It is an event model, so the person writing the event has to yield the system back. If you put a CpuDeadLoop() in an event handler you will crash the system.

Thanks,

Andrew Fish
Post by D chinni babu
Please help to clarify these things for better understanding of UEFI.
Thanks,
Chinni.
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Loading...