On 25/01/2024 15:06, Ni, Ray wrote:
I agree with you about the above PI spec clarifications. Would you like to write a PI spec ECR?
I am not a UEFI Forum member, so I don't think I have standing to do this. (I also don't have the spare time to do this for free, sorry.)
But I do not think the PI spec version stored in the PI system table needs to reflect whether a DxeCore implementation follows the clarification. Since the DxeCore::CoreTimerTick() implementation raises TPL to HIGH in the very first version created in more than 10 years ago, I think it's safe for TimerInterruptHandler() assumes CoreTimerTick() will raise TPL to HIGH so that TimerInterruptHandler() does not need to raise TPL to HIGH. (I agree changing the spec version is the most correct way if we review the problem in a very theorical way.)
I don't see any call to RaiseTPL() in the current version of CoreTimerTick(), unless this is implicit in the use of CoreAcquireLock()?
I really want to keep the UEFI world simple with the bug fixed.
I definitely agree with this aim! :)
(The cost is assumption on existing DxeCore::CoreTimerTick().)
For me, the problem is that we can't assume that it's the EDK2 implementation of CoreTimerTick() that is being used. It's perfectly legitimate for an implementation to not use EDK2's DxeCore, and to provide a NotifyFunction that *requires* being called with the TPL already raised to TPL_HIGH_LEVEL.
If we're not worried about maintaining conformance to the published specifications, then there are several very breaking changes I'd like to make, starting with the USB I/O protocols. :)
Thanks, Michael -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114427): https://edk2.groups.io/g/devel/message/114427 Mute This Topic: https://groups.io/mt/103950154/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
