From: "Sunil V L" <sunilvl@ventanamicro.com>
To: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: devel@edk2.groups.io, Daniel Schaefer <git@danielschaefer.me>
Subject: Re: [edk2 1/1] RiscV64 Timer: fix tick duration accounting
Date: Tue, 21 Feb 2023 10:37:23 +0530 [thread overview]
Message-ID: <Y/RRi3KdUimUq9iQ@sunil-laptop> (raw)
In-Reply-To: <20230218043149.1058-1-andrei.warkentin@intel.com>
Hi Andrei,
Thank you very much for fixing this!
On Fri, Feb 17, 2023 at 10:31:49PM -0600, Andrei Warkentin wrote:
> 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);
Shouldn't we consider debug case like ARM does?
Also, looks like there are some uncrustify errors. Please run manually
and fix them.
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-Formatting#manual-usage---generate-file-list-via-stdin
Thanks,
Sunil
next prev parent reply other threads:[~2023-02-21 5:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-18 4:31 [edk2 1/1] RiscV64 Timer: fix tick duration accounting Andrei Warkentin
2023-02-21 5:07 ` Sunil V L [this message]
[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=Y/RRi3KdUimUq9iQ@sunil-laptop \
--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