From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 4F44AAC1214 for ; Thu, 4 Jan 2024 14:38:24 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=5+0hPASbUA5vUotRXfbmHL2pmo1KnO1WbZgoRIckezs=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1704379102; v=1; b=wD4Vh5UCiTVAFHIGGTyZNdfB9jQpZe/2nS0ebtfLux4D6MOWZ3Eb/dZRRVsvt0J1vxVmkuIT PNaagXthqrwMwsWOem/bMzEo3AHzlsY+pk1hIuMSiBdjHbRRRAFYcpr4lnN9XtjLJjgJHzBBNY0 cYh6zg2KvOyRyAVeGVoXtbRk= X-Received: by 127.0.0.2 with SMTP id tJmYYY7687511xEF3j1sHu2h; Thu, 04 Jan 2024 06:38:22 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.55435.1704379102275678826 for ; Thu, 04 Jan 2024 06:38:22 -0800 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-60-9hWJnLdjMuaoc5RGLloSsw-1; Thu, 04 Jan 2024 09:38:20 -0500 X-MC-Unique: 9hWJnLdjMuaoc5RGLloSsw-1 X-Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A0ED33C025CD; Thu, 4 Jan 2024 14:38:19 +0000 (UTC) X-Received: from [10.39.194.24] (unknown [10.39.194.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 79D4E492BF0; Thu, 4 Jan 2024 14:38:18 +0000 (UTC) Message-ID: Date: Thu, 4 Jan 2024 15:38:17 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH 3/4] UefiCpuPkg/CpuTimerDxeRiscV64: Add support for Sstc To: devel@edk2.groups.io, sunilvl@ventanamicro.com Cc: Gerd Hoffmann , Rahul Kumar , Ray Ni , Andrei Warkentin References: <20240103135849.127251-1-sunilvl@ventanamicro.com> <20240103135849.127251-4-sunilvl@ventanamicro.com> From: "Laszlo Ersek" In-Reply-To: <20240103135849.127251-4-sunilvl@ventanamicro.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 0JuE3Yj4MpZ2k5Mb1yfDDfJDx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=wD4Vh5UC; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 1/3/24 14:58, Sunil V L wrote: > Sstc extension allows to program the timer and receive the interrupt > without using an SBI call. This reduces the latency to generate the timer > interrupt. So, detect whether Sstc extension is supported and use the > stimecmp register directly to program the timer interrupt. >=20 > Cc: Gerd Hoffmann > Cc: Rahul Kumar > Cc: Laszlo Ersek > Cc: Ray Ni > Cc: Andrei Warkentin > Signed-off-by: Sunil V L > --- > .../CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf | 1 + > UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h | 2 ++ > UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 30 +++++++++++++++++-- > 3 files changed, 31 insertions(+), 2 deletions(-) >=20 > diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf b/UefiC= puPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf > index aba660186dc0..f2a2cf12caef 100644 > --- a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf > +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf > @@ -41,6 +41,7 @@ [Sources.RISCV64] > Timer.c > =20 > [Pcd] > + gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride ## CONSUMES > gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency ## CONSUMES > =20 > [Protocols] > diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h b/UefiCpuPkg/CpuTimerD= xeRiscV64/Timer.h > index 9b3542230cb5..5e5071b3f0b2 100644 > --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h > +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h > @@ -26,6 +26,8 @@ > // > #define DEFAULT_TIMER_TICK_DURATION 100000 > =20 > +#define RISCV_CPU_FEATURE_SSTC_BITMASK 0x2 (1) Not a bug by any means, but BIT1 might read more idiomatic. > + > extern VOID > RiscvSetTimerPeriod ( > UINT32 TimerPeriod > diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c b/UefiCpuPkg/CpuTimerD= xeRiscV64/Timer.c > index 30e48061cd06..4babfb4bfc60 100644 > --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c > +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c > @@ -44,6 +44,19 @@ STATIC EFI_TIMER_NOTIFY mTimerNotifyFunction; > STATIC UINT64 mTimerPeriod =3D 0; > STATIC UINT64 mLastPeriodStart =3D 0; > =20 > +/** > + Check whether Sstc is enabled in PCD. > + > +**/ > +STATIC > +BOOLEAN > +RiscVIsSstcEnabled ( > + VOID > + ) > +{ > + return ((PcdGet64 (PcdRiscVFeatureOverride) & RISCV_CPU_FEATURE_SSTC_B= ITMASK) !=3D 0); > +} > + > /** > Timer Interrupt Handler. > =20 > @@ -94,7 +107,12 @@ TimerInterruptHandler ( > ), > 1000000u > ); // convert to tick > - SbiSetTimer (PeriodStart); > + if (RiscVIsSstcEnabled ()) { (2) Even though the PCD is currently declared as fixed or patchable-in-module, seeing a PcdGet64() call on the call stack of the timer interrupt handler (and at a high TPL) makes me uncomfortable. It carries a risk that later on we relax the PCD decl to dynamic, and then this code would become brittle. I propose: either replace the PcdGet64 call above with FixedPcdGet64 (so it can never land in the runtime / dynamic PCD protocol), or perform the PCD check in the entry point function of the driver, and store the result in a STATIC BOOLEAN variable. Then further PCD accesses (dynamic or otherwise) will not be needed. > + RiscVSetSupervisorTimeCompareRegister (PeriodStart); > + } else { > + SbiSetTimer (PeriodStart); > + } > + > RiscVEnableTimerInterrupt (); // enable SMode timer int > gBS->RestoreTPL (OriginalTPL); > } > @@ -197,7 +215,11 @@ TimerDriverSetTimerPeriod ( > ), > 1000000u > ); // convert to tick > - SbiSetTimer (PeriodStart); > + if (RiscVIsSstcEnabled ()) { > + RiscVSetSupervisorTimeCompareRegister (PeriodStart); > + } else { > + SbiSetTimer (PeriodStart); > + } > =20 > mCpu->EnableInterrupt (mCpu); > RiscVEnableTimerInterrupt (); // enable SMode timer int (3) This seems like duplicated code. How about replacing the RiscVIsSstcEnabled() function with a more substantive function that incorporates both the feature check *and* the "PeriodStart" setting? Then you can easily call that function from both TimerInterruptHandler() and TimerDriverSetTimerPeriod(). > @@ -282,6 +304,10 @@ TimerDriverInitialize ( > // > mTimerNotifyFunction =3D NULL; > =20 > + if (RiscVIsSstcEnabled ()) { > + DEBUG ((DEBUG_INFO, "%a: Timer interrupt is via Sstc extension\n", _= _func__)); > + } > + Right, this would be the place to fetch the PCD explicitly and to store the result (based on bit-masking) into the global boolean. > // > // Make sure the Timer Architectural Protocol is not already installed= in the system > // Thanks Laszlo -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113176): https://edk2.groups.io/g/devel/message/113176 Mute This Topic: https://groups.io/mt/103501843/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-