diff options
author | Andrei Warkentin <andrei.warkentin@intel.com> | 2023-02-17 18:44:51 -0600 |
---|---|---|
committer | mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> | 2023-03-08 18:10:34 +0000 |
commit | 5ad2592ab370b6c9030d1239940046bdeec9c2c6 (patch) | |
tree | 295a62746bf284070455f9bf6d1a998b5cea0ef9 /UefiCpuPkg | |
parent | db0a3087a535f54f3697e0d658a53bb78d57ce70 (diff) | |
download | edk2-5ad2592ab370b6c9030d1239940046bdeec9c2c6.tar.gz edk2-5ad2592ab370b6c9030d1239940046bdeec9c2c6.tar.bz2 edk2-5ad2592ab370b6c9030d1239940046bdeec9c2c6.zip |
UefiCpuPkg: CpuTimerDxeRiscV64: fix tick duration accounting
The TimerDxe implementation doesn't account for the physical
time passed due to timer handler execution or (perhaps even
more importantly) time spent with interrupts masked.
Other implementations (e.g. like the Arm one) do. If the
timer tick is always incremented at a fixed rate, then
you can slow down UEFI's perception of time by running
long sections of code in a critical section.
Cc: Daniel Schaefer <git@danielschaefer.me>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
Diffstat (limited to 'UefiCpuPkg')
-rw-r--r-- | UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 35 |
1 files changed, 21 insertions, 14 deletions
diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c index db153f715e..287e7e1330 100644 --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c @@ -40,7 +40,8 @@ STATIC EFI_TIMER_NOTIFY mTimerNotifyFunction; //
// The current period of the timer interrupt
//
-STATIC UINT64 mTimerPeriod = 0;
+STATIC UINT64 mTimerPeriod = 0;
+STATIC UINT64 mLastPeriodStart = 0;
/**
Timer Interrupt Handler.
@@ -56,25 +57,33 @@ TimerInterruptHandler ( )
{
EFI_TPL OriginalTPL;
- UINT64 RiscvTimer;
+ UINT64 PeriodStart;
+
+ PeriodStart = RiscVReadTimer ();
OriginalTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL);
if (mTimerNotifyFunction != NULL) {
- mTimerNotifyFunction (mTimerPeriod);
+ //
+ // For any number of reasons, the ticks could be coming
+ // in slower than mTimerPeriod. For example, some code
+ // is doing a *lot* of stuff inside an EFI_TPL_HIGH
+ // critical section, and this should not cause the EFI
+ // time to increment slower. So when we take an interrupt,
+ // account for the actual time passed.
+ //
+ mTimerNotifyFunction (PeriodStart - mLastPeriodStart);
}
- RiscVDisableTimerInterrupt (); // Disable SMode timer int
- RiscVClearPendingTimerInterrupt ();
if (mTimerPeriod == 0) {
+ RiscVDisableTimerInterrupt ();
gBS->RestoreTPL (OriginalTPL);
- RiscVDisableTimerInterrupt (); // Disable SMode timer int
return;
}
- RiscvTimer = RiscVReadTimer ();
- SbiSetTimer (RiscvTimer += mTimerPeriod);
- gBS->RestoreTPL (OriginalTPL);
+ mLastPeriodStart = PeriodStart;
+ SbiSetTimer (PeriodStart += mTimerPeriod);
RiscVEnableTimerInterrupt (); // enable SMode timer int
+ gBS->RestoreTPL (OriginalTPL);
}
/**
@@ -154,8 +163,6 @@ TimerDriverSetTimerPeriod ( IN UINT64 TimerPeriod
)
{
- UINT64 RiscvTimer;
-
DEBUG ((DEBUG_INFO, "TimerDriverSetTimerPeriod(0x%lx)\n", TimerPeriod));
if (TimerPeriod == 0) {
@@ -164,9 +171,9 @@ TimerDriverSetTimerPeriod ( return EFI_SUCCESS;
}
- mTimerPeriod = TimerPeriod / 10; // convert unit from 100ns to 1us
- RiscvTimer = RiscVReadTimer ();
- SbiSetTimer (RiscvTimer + mTimerPeriod);
+ mTimerPeriod = TimerPeriod / 10; // convert unit from 100ns to 1us
+ mLastPeriodStart = RiscVReadTimer ();
+ SbiSetTimer (mLastPeriodStart + mTimerPeriod);
mCpu->EnableInterrupt (mCpu);
RiscVEnableTimerInterrupt (); // enable SMode timer int
|