public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Andrei Warkentin" <andrei.warkentin@intel.com>
To: devel@edk2.groups.io
Cc: Andrei Warkentin <andrei.warkentin@intel.com>,
	Sunil V L <sunilvl@ventanamicro.com>,
	Daniel Schaefer <git@danielschaefer.me>
Subject: [edk2 1/1] RiscV64 Timer: fix tick duration accounting
Date: Fri, 17 Feb 2023 22:31:49 -0600	[thread overview]
Message-ID: <20230218043149.1058-1-andrei.warkentin@intel.com> (raw)

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: Sunil V L <sunilvl@ventanamicro.com>
Cc: Daniel Schaefer <git@danielschaefer.me>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
---
 UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 31 ++++++++++++--------
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
index 0ecefddf1f18..f65c64c296cd 100644
--- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
+++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
@@ -41,6 +41,7 @@ STATIC EFI_TIMER_NOTIFY  mTimerNotifyFunction;
 // The current period of the timer interrupt
 //
 STATIC UINT64  mTimerPeriod = 0;
+STATIC UINT64  mLastPeriodStart = 0;
 
 /**
   Timer Interrupt Handler.
@@ -55,26 +56,32 @@ TimerInterruptHandler (
   IN EFI_SYSTEM_CONTEXT  SystemContext
   )
 {
-  EFI_TPL  OriginalTPL;
-  UINT64   RiscvTimer;
+  EFI_TPL OriginalTPL;
+  UINT64  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);
+  mLastPeriodStart = PeriodStart;
+  SbiSetTimer (PeriodStart += mTimerPeriod);
+  RiscVEnableTimerInterrupt (); // enable SMode timer int
   gBS->RestoreTPL (OriginalTPL);
-  RiscVEnableTimerInterrupt (); // enable SMode timer int
 }
 
 /**
@@ -154,8 +161,6 @@ TimerDriverSetTimerPeriod (
   IN UINT64                   TimerPeriod
   )
 {
-  UINT64  RiscvTimer;
-
   DEBUG ((DEBUG_INFO, "TimerDriverSetTimerPeriod(0x%lx)\n", TimerPeriod));
 
   if (TimerPeriod == 0) {
@@ -165,8 +170,8 @@ TimerDriverSetTimerPeriod (
   }
 
   mTimerPeriod = TimerPeriod / 10; // convert unit from 100ns to 1us
-  RiscvTimer   = RiscVReadTimer ();
-  SbiSetTimer (RiscvTimer + mTimerPeriod);
+  mLastPeriodStart = RiscVReadTimer ();
+  SbiSetTimer (mLastPeriodStart + mTimerPeriod);
 
   mCpu->EnableInterrupt (mCpu);
   RiscVEnableTimerInterrupt (); // enable SMode timer int
-- 
2.25.1


             reply	other threads:[~2023-02-18  4:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-18  4:31 Andrei Warkentin [this message]
2023-02-21  5:07 ` [edk2 1/1] RiscV64 Timer: fix tick duration accounting Sunil V L
     [not found] ` <1745BEA47127C0BE.676@groups.io>
2023-02-22  9:57   ` [edk2-devel] " Sunil V L

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230218043149.1058-1-andrei.warkentin@intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox