public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
* [PATCH] MdePkg/SecPeiDxeTimerLibCpu: Better support for dynamic PcdFSBClock
@ 2022-11-08 14:31 Anthony PERARD
  2023-02-10  1:27 ` [edk2-devel] " joeyli
  0 siblings, 1 reply; 3+ messages in thread
From: Anthony PERARD @ 2022-11-08 14:31 UTC (permalink / raw)
  To: devel; +Cc: Liming Gao, Zhiguang Liu, Michael D Kinney, Anthony PERARD

From: Anthony PERARD <anthony.perard@citrix.com>

The PcdFSBClock can be a dynamic PCD. This can be an issue when
InternalX86GetTimerFrequency() tries to get the value while been
called with TPL been set to TPL_HIGH_LEVEL.

When the PCD is dynamic, PcdGet*() calls a function that try to grab a
lock which set TPL to TPL_NOTIFY. If TPL is already at TPL_HIGH_LEVEL,
then an assert() in RaiseTPL() fails (in debug build).

To try to avoid the issue, we'll store the current PcdFSBClock value
in a local variable the first time we need it.

The issue was discovered while attempting to boot a Windows guest with
OvmfXen platform. The issue appear while executing the Windows's boot
loader EFI application.

The down side of this change is that when the PCD is FixedAtBuild, the
value is loaded from a variable rather than been a constant.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---

InternalX86GetTimerFrequency() is called by
- MicroSecondDelay()
- NanoSecondDelay()
- GetPerformanceCounterProperties()

If one of those functions is called for the first time with a TPL too
high, the work around in this patch would not work. But it seems to
workaround the issue in my test case. So maybe that's enough, unless
someone have a better idea?
---
 MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c b/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
index c60589607fde..28ff77ad0c1f 100644
--- a/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
+++ b/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
@@ -90,8 +90,16 @@ InternalX86GetTimerFrequency (
   IN      UINTN  ApicBase
   )
 {
+  STATIC UINT32 mFSBClock;
+
+  if (mFSBClock == 0) {
+      //
+      // Cache current value of PcdFSBClock in case it's a dynamic PCD.
+      //
+      mFSBClock = PcdGet32 (PcdFSBClock);
+  }
   return
-    PcdGet32 (PcdFSBClock) /
+    mFSBClock /
     mTimerLibLocalApicDivisor[MmioBitFieldRead32 (ApicBase + APIC_TDCR, 0, 3)];
 }
 
-- 
Anthony PERARD


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [edk2-devel] [PATCH] MdePkg/SecPeiDxeTimerLibCpu: Better support for dynamic PcdFSBClock
  2022-11-08 14:31 [PATCH] MdePkg/SecPeiDxeTimerLibCpu: Better support for dynamic PcdFSBClock Anthony PERARD
@ 2023-02-10  1:27 ` joeyli
  2023-02-10  2:23   ` Michael D Kinney
  0 siblings, 1 reply; 3+ messages in thread
From: joeyli @ 2023-02-10  1:27 UTC (permalink / raw)
  To: devel, anthony.perard; +Cc: Liming Gao, Zhiguang Liu, Michael D Kinney

On Tue, Nov 08, 2022 at 02:31:48PM +0000, Anthony PERARD via groups.io wrote:
> From: Anthony PERARD <anthony.perard@citrix.com>
> 
> The PcdFSBClock can be a dynamic PCD. This can be an issue when
> InternalX86GetTimerFrequency() tries to get the value while been
> called with TPL been set to TPL_HIGH_LEVEL.
> 
> When the PCD is dynamic, PcdGet*() calls a function that try to grab a
> lock which set TPL to TPL_NOTIFY. If TPL is already at TPL_HIGH_LEVEL,
> then an assert() in RaiseTPL() fails (in debug build).
> 
> To try to avoid the issue, we'll store the current PcdFSBClock value
> in a local variable the first time we need it.
> 
> The issue was discovered while attempting to boot a Windows guest with
> OvmfXen platform. The issue appear while executing the Windows's boot
> loader EFI application.
> 
> The down side of this change is that when the PCD is FixedAtBuild, the
> value is loaded from a variable rather than been a constant.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

I have tested this patch with edk2-stable202202 and edk2-stable202211. It
works to me to fix problem on bto#4340:

Bug 4340 - Running windows 2k22 on OvmfXen got ASSERT /root/source-git/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c(66): ((BOOLEAN)(0==1))
https://bugzilla.tianocore.org/show_bug.cgi?id=4340

Thanks a lot!
Joey Lee

> ---
> 
> InternalX86GetTimerFrequency() is called by
> - MicroSecondDelay()
> - NanoSecondDelay()
> - GetPerformanceCounterProperties()
> 
> If one of those functions is called for the first time with a TPL too
> high, the work around in this patch would not work. But it seems to
> workaround the issue in my test case. So maybe that's enough, unless
> someone have a better idea?
> ---
>  MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c b/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
> index c60589607fde..28ff77ad0c1f 100644
> --- a/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
> +++ b/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
> @@ -90,8 +90,16 @@ InternalX86GetTimerFrequency (
>    IN      UINTN  ApicBase
>    )
>  {
> +  STATIC UINT32 mFSBClock;
> +
> +  if (mFSBClock == 0) {
> +      //
> +      // Cache current value of PcdFSBClock in case it's a dynamic PCD.
> +      //
> +      mFSBClock = PcdGet32 (PcdFSBClock);
> +  }
>    return
> -    PcdGet32 (PcdFSBClock) /
> +    mFSBClock /
>      mTimerLibLocalApicDivisor[MmioBitFieldRead32 (ApicBase + APIC_TDCR, 0, 3)];
>  }
>  
> -- 
> Anthony PERARD
> 
> 
> 
> 
> 
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [edk2-devel] [PATCH] MdePkg/SecPeiDxeTimerLibCpu: Better support for dynamic PcdFSBClock
  2023-02-10  1:27 ` [edk2-devel] " joeyli
@ 2023-02-10  2:23   ` Michael D Kinney
  0 siblings, 0 replies; 3+ messages in thread
From: Michael D Kinney @ 2023-02-10  2:23 UTC (permalink / raw)
  To: devel@edk2.groups.io, jlee@suse.com, anthony.perard@citrix.com
  Cc: Gao, Liming, Liu, Zhiguang, Kinney, Michael D

This library is intended to be compatible with XIP SEC and XIP PEIMs that are not
allowed to use writable global C variables.

I think storage for STATIC UINT32 mFSBClock is from the .data section and not
the stack, so this will break XIP use cases.

Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of joeyli via groups.io
> Sent: Thursday, February 9, 2023 5:27 PM
> To: devel@edk2.groups.io; anthony.perard@citrix.com
> Cc: Gao, Liming <gaoliming@byosoft.com.cn>; Liu, Zhiguang <zhiguang.liu@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: Re: [edk2-devel] [PATCH] MdePkg/SecPeiDxeTimerLibCpu: Better support for dynamic PcdFSBClock
> 
> On Tue, Nov 08, 2022 at 02:31:48PM +0000, Anthony PERARD via groups.io wrote:
> > From: Anthony PERARD <anthony.perard@citrix.com>
> >
> > The PcdFSBClock can be a dynamic PCD. This can be an issue when
> > InternalX86GetTimerFrequency() tries to get the value while been
> > called with TPL been set to TPL_HIGH_LEVEL.
> >
> > When the PCD is dynamic, PcdGet*() calls a function that try to grab a
> > lock which set TPL to TPL_NOTIFY. If TPL is already at TPL_HIGH_LEVEL,
> > then an assert() in RaiseTPL() fails (in debug build).
> >
> > To try to avoid the issue, we'll store the current PcdFSBClock value
> > in a local variable the first time we need it.
> >
> > The issue was discovered while attempting to boot a Windows guest with
> > OvmfXen platform. The issue appear while executing the Windows's boot
> > loader EFI application.
> >
> > The down side of this change is that when the PCD is FixedAtBuild, the
> > value is loaded from a variable rather than been a constant.
> >
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> I have tested this patch with edk2-stable202202 and edk2-stable202211. It
> works to me to fix problem on bto#4340:
> 
> Bug 4340 - Running windows 2k22 on OvmfXen got ASSERT /root/source-git/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c(66): ((BOOLEAN)(0==1))
> https://bugzilla.tianocore.org/show_bug.cgi?id=4340
> 
> Thanks a lot!
> Joey Lee
> 
> > ---
> >
> > InternalX86GetTimerFrequency() is called by
> > - MicroSecondDelay()
> > - NanoSecondDelay()
> > - GetPerformanceCounterProperties()
> >
> > If one of those functions is called for the first time with a TPL too
> > high, the work around in this patch would not work. But it seems to
> > workaround the issue in my test case. So maybe that's enough, unless
> > someone have a better idea?
> > ---
> >  MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c | 10 +++++++++-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c b/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
> > index c60589607fde..28ff77ad0c1f 100644
> > --- a/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
> > +++ b/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
> > @@ -90,8 +90,16 @@ InternalX86GetTimerFrequency (
> >    IN      UINTN  ApicBase
> >    )
> >  {
> > +  STATIC UINT32 mFSBClock;
> > +
> > +  if (mFSBClock == 0) {
> > +      //
> > +      // Cache current value of PcdFSBClock in case it's a dynamic PCD.
> > +      //
> > +      mFSBClock = PcdGet32 (PcdFSBClock);
> > +  }
> >    return
> > -    PcdGet32 (PcdFSBClock) /
> > +    mFSBClock /
> >      mTimerLibLocalApicDivisor[MmioBitFieldRead32 (ApicBase + APIC_TDCR, 0, 3)];
> >  }
> >
> > --
> > Anthony PERARD
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-02-10  2:23 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-11-08 14:31 [PATCH] MdePkg/SecPeiDxeTimerLibCpu: Better support for dynamic PcdFSBClock Anthony PERARD
2023-02-10  1:27 ` [edk2-devel] " joeyli
2023-02-10  2:23   ` Michael D Kinney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox