Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 02/20] MdePkg/BaseLib: RISC-V: Add few more helper functions

[Sunil V L]

Hi Mike,

On Thu, Feb 09, 2023 at 01:43:57AM +, Kinney, Michael D wrote:
> Hi Sunil,
> 
> Just a formatting comment below.
> 
> Mike
> 
> > -Original Message-
> > From: Sunil V L 
> > Sent: Saturday, January 28, 2023 11:18 AM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Gao, Liming 
> > ; Liu, Zhiguang ;
> > Daniel Schaefer ; Abner Chang 
> > Subject: [edk2-staging/RiscV64QemuVirt PATCH V7 02/20] MdePkg/BaseLib: 
> > RISC-V: Add few more helper functions
> > 
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> > 
> > Few of the basic helper functions required for any
> > RISC-V CPU were added in edk2-platforms. To support
> > qemu virt, they need to be added in BaseLib.
> > 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Daniel Schaefer 
> > Signed-off-by: Sunil V L 
> > Acked-by: Abner Chang 
> > ---
> >  MdePkg/Library/BaseLib/BaseLib.inf  |  3 ++
> >  MdePkg/Include/Library/BaseLib.h| 50 ++
> >  MdePkg/Library/BaseLib/RiscV64/CpuScratch.S | 31 
> >  MdePkg/Library/BaseLib/RiscV64/ReadTimer.S  | 23 +
> >  MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S | 53 ++--
> >  MdePkg/Library/BaseLib/RiscV64/RiscVMmu.S   | 23 +
> >  6 files changed, 179 insertions(+), 4 deletions(-)
> > 
> > diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
> > b/MdePkg/Library/BaseLib/BaseLib.inf
> > index 9ed46a584a14..3a48492b1a01 100644
> > --- a/MdePkg/Library/BaseLib/BaseLib.inf
> > +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> > @@ -401,6 +401,9 @@ [Sources.RISCV64]
> >RiscV64/RiscVCpuPause.S   | GCC
> >RiscV64/RiscVInterrupt.S  | GCC
> >RiscV64/FlushCache.S  | GCC
> > +  RiscV64/CpuScratch.S  | GCC
> > +  RiscV64/ReadTimer.S   | GCC
> > +  RiscV64/RiscVMmu.S| GCC
> > 
> >  [Sources.LOONGARCH64]
> >Math64.c
> > diff --git a/MdePkg/Include/Library/BaseLib.h 
> > b/MdePkg/Include/Library/BaseLib.h
> > index f3f59f21c2ea..b4f4e45a1486 100644
> > --- a/MdePkg/Include/Library/BaseLib.h
> > +++ b/MdePkg/Include/Library/BaseLib.h
> > @@ -151,6 +151,56 @@ typedef struct {
> > 
> >  #define BASE_LIBRARY_JUMP_BUFFER_ALIGNMENT  8
> > 
> > +VOID
> > +  RiscVSetSupervisorScratch (
> > + UINT64
> > + );
> > +
> > +UINT64
> > +RiscVGetSupervisorScratch (
> > +  VOID
> > +  );
> > +
> > +VOID
> > +  RiscVSetSupervisorStvec (
> > +   UINT64
> > +   );
> > +
> > +UINT64
> > +RiscVGetSupervisorStvec (
> > +  VOID
> > +  );
> > +
> > +UINT64
> > +RiscVGetSupervisorTrapCause (
> > +  VOID
> > +  );
> > +
> > +VOID
> > +  RiscVSetSupervisorAddressTranslationRegister (
> > +UINT64
> > +);
> 
> Formatting does not look right.
> 
> Have you run EDK II uncrustify on this patch series.
> 
Interesting. I ran both offline CI and CI through PR for these changes.
Anyway, thanks for catching this. Let me fix it in the next revision.

Thanks!
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99867): https://edk2.groups.io/g/devel/message/99867
Mute This Topic: https://groups.io/mt/96593493/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 03/20] MdePkg: Add BaseRiscVSbiLib Library for RISC-V

[Sunil V L]

Hi Mike,

On Thu, Feb 09, 2023 at 01:45:48AM +, Michael D Kinney wrote:
> One comment below.
> 
> Mike
> 
> > -Original Message-
> > From: Sunil V L 
> > Sent: Saturday, January 28, 2023 11:18 AM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Gao, Liming 
> > ; Liu, Zhiguang ;
> > Abner Chang 
> > Subject: [edk2-staging/RiscV64QemuVirt PATCH V7 03/20] MdePkg: Add 
> > BaseRiscVSbiLib Library for RISC-V
> > 
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> > 
> > This library is required to make SBI ecalls from the S-mode EDK2.
> > This is mostly copied from
> > edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib
> > 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Signed-off-by: Sunil V L 
> > Acked-by: Abner Chang 
> > ---
> >  MdePkg/MdePkg.dec  |   4 +
> >  MdePkg/MdePkg.dsc  |   3 +
> >  MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf |  25 +++
> >  MdePkg/Include/Library/BaseRiscVSbiLib.h   | 127 +++
> >  MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.c   | 227 
> > 
> >  5 files changed, 386 insertions(+)
> > 
> > diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> > index 3d08f20d15b0..ca2e4dcf815c 100644
> > --- a/MdePkg/MdePkg.dec
> > +++ b/MdePkg/MdePkg.dec
> > @@ -316,6 +316,10 @@ [LibraryClasses.IA32, LibraryClasses.X64]
> >##  @libraryclass  Provides function to support TDX processing.
> >TdxLib|Include/Library/TdxLib.h
> > 
> > +[LibraryClasses.RISCV64]
> > +  ##  @libraryclass  Provides function to make ecalls to SBI
> > +  BaseRiscVSbiLib|Include/Library/BaseRiscVSbiLib.h
> > +
> >  [Guids]
> >#
> ># GUID defined in UEFI2.1/UEFI2.0/EFI1.1
> > diff --git a/MdePkg/MdePkg.dsc b/MdePkg/MdePkg.dsc
> > index 32a852dc466e..0ac7618b4623 100644
> > --- a/MdePkg/MdePkg.dsc
> > +++ b/MdePkg/MdePkg.dsc
> > @@ -190,4 +190,7 @@ [Components.ARM, Components.AARCH64]
> >MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.inf
> >MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
> > 
> > +[Components.RISCV64]
> > +  MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
> > +
> >  [BuildOptions]
> > diff --git a/MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf 
> > b/MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
> > new file mode 100644
> > index ..d03132bf01c1
> > --- /dev/null
> > +++ b/MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
> > @@ -0,0 +1,25 @@
> > +## @file
> > +# RISC-V Library to call SBI ecalls
> > +#
> > +#  Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All 
> > rights reserved.
> > +#
> > +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +#
> > +##
> > +
> > +[Defines]
> > +  INF_VERSION = 0x0001001b
> > +  BASE_NAME   = BaseRiscVSbiLib
> > +  FILE_GUID   = D742CF3D-E600-4009-8FB5-318073008508
> > +  MODULE_TYPE = BASE
> > +  VERSION_STRING  = 1.0
> > +  LIBRARY_CLASS   = RiscVSbiLib
> > +
> > +[Sources]
> > +  BaseRiscVSbiLib.c
> > +
> > +[Packages]
> > +  MdePkg/MdePkg.dec
> > +
> > +[LibraryClasses]
> > +  BaseLib
> > diff --git a/MdePkg/Include/Library/BaseRiscVSbiLib.h 
> > b/MdePkg/Include/Library/BaseRiscVSbiLib.h
> > new file mode 100644
> > index ..3a3cbfb879f1
> > --- /dev/null
> > +++ b/MdePkg/Include/Library/BaseRiscVSbiLib.h
> > @@ -0,0 +1,127 @@
> > +/** @file
> > +  Library to call the RISC-V SBI ecalls
> > +
> > +  Copyright (c) 2021-2022, Hewlett Packard Development LP. All rights 
> > reserved.
> > +
> > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +
> > +  @par Glossary:
> > +- Hart - Hardware Thread, similar to a CPU core
> > +
> > +  Currently, EDK2 needs to call SBI only to set the time and to do system 
> > reset.
> > +
> > +**/
> > +
> > +#ifndef RISCV_SBI_LIB_H_
> > +#define RISCV_SBI_LIB_H_
> > +
> > +#include 
> > +
> > +/* SBI Extension IDs */
> > +#define SBI_EXT_TIME  0x54494D45
> > +#define SBI_EXT_SRST  0x53525354
> > +
> > +/* SBI function IDs for TIME extension*/
> > +#define SBI_EXT_TIME_SET_TIMER  0x0
> > +
> > +/* SBI function IDs for SRST extension */
> > +#define SBI_EXT_SRST_RESET  0x0
> > +
> > +#define SBI_SRST_RESET_TYPE_SHUTDOWN 0x0
> > +#define SBI_SRST_RESET_TYPE_COLD_REBOOT  0x1
> > +#define SBI_SRST_RESET_TYPE_WARM_REBOOT  0x2
> > +
> > +#define SBI_SRST_RESET_REASON_NONE 0x0
> > +#define SBI_SRST_RESET_REASON_SYSFAIL  0x1
> > +
> > +/* SBI return error codes */
> > +#define SBI_SUCCESS0
> > +#define SBI_ERR_FAILED -1
> > +#define SBI_ERR_NOT_SUPPORTED  -2
> > +#define SBI_ERR_INVALID_PARAM  -3
> > +#define SBI_ERR_DENIED -4
> > +#define SBI_ERR_INVALID_ADDRESS-5
> > +#define SBI_ERR_ALREADY_AVAILABLE  -6
> > +#define SBI_ERR_ALREADY_STARTED-7
> > +#define SBI_ERR_ALREADY_STOPPED-8
> > +
> > +#define SBI_LAST_ERR  SBI_ERR_ALREADY_STOPPED
> > +
> > +typedef struct {

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 07/20] UefiCpuPkg/CpuDxe: Add RISC-V instance

[Sunil V L]

On Wed, Feb 08, 2023 at 09:43:39PM -0800, Ni, Ray wrote:
> Since there is nothing shared between RiscV and X86, can you put the driver 
> in a different folder such as RiscVCpuDxe?

Thank you very much Ray. Mike had given similar feedback. I am fine with
your suggestion. Let me update the series with your suggestion for other
patches also.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99865): https://edk2.groups.io/g/devel/message/99865
Mute This Topic: https://groups.io/mt/96593503/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 07/20] UefiCpuPkg/CpuDxe: Add RISC-V instance

[Ni, Ray]

Since there is nothing shared between RiscV and X86, can you put the driver in 
a different folder such as RiscVCpuDxe?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99864): https://edk2.groups.io/g/devel/message/99864
Mute This Topic: https://groups.io/mt/96593503/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 09/20] UefiCpuPkg/UefiCpuPkg.ci.yaml: Ignore RISC-V file

[Ni, Ray]

Acked-by: Ray Ni 

> -Original Message-
> From: Sunil V L 
> Sent: Sunday, January 29, 2023 3:18 AM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R ; Gerd Hoffmann ;
> Abner Chang 
> Subject: [edk2-staging/RiscV64QemuVirt PATCH V7 09/20]
> UefiCpuPkg/UefiCpuPkg.ci.yaml: Ignore RISC-V file
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> 
> RISC-V register names do not follow the EDK2 formatting.
> So, add it to ignore list for now.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Signed-off-by: Sunil V L 
> Acked-by: Abner Chang 
> ---
>  UefiCpuPkg/UefiCpuPkg.ci.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.ci.yaml
> b/UefiCpuPkg/UefiCpuPkg.ci.yaml
> index a377366798b0..953361ba0479 100644
> --- a/UefiCpuPkg/UefiCpuPkg.ci.yaml
> +++ b/UefiCpuPkg/UefiCpuPkg.ci.yaml
> @@ -27,6 +27,7 @@
>  ],
>  ## Both file path and directory path are accepted.
>  "IgnoreFiles": [
> +  "Library/CpuExceptionHandlerLib/RiscV64/CpuExceptionHandlerLib.h"
>  ]
>  },
>  "CompilerPlugin": {
> --
> 2.38.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99863): https://edk2.groups.io/g/devel/message/99863
Mute This Topic: https://groups.io/mt/96593505/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 08/20] UefiCpuPkg/CpuTimerLib: Add RISC-V instance

[Ni, Ray]

Can you rename CpuTimerLib to RiscVTimerLib or something else that's more 
specific?
RiscV64 sub-directory might not be necessary.

> -Original Message-
> From: Sunil V L 
> Sent: Sunday, January 29, 2023 3:18 AM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R ; Daniel Schaefer
> ; Abner Chang ; Gerd
> Hoffmann 
> Subject: [edk2-staging/RiscV64QemuVirt PATCH V7 08/20]
> UefiCpuPkg/CpuTimerLib: Add RISC-V instance
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> 
> This is mostly copied from
> edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVTimerLib
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Daniel Schaefer 
> Cc: Abner Chang 
> Cc: Gerd Hoffmann 
> Signed-off-by: Sunil V L 
> Acked-by: Abner Chang 
> ---
>  UefiCpuPkg/UefiCpuPkg.dsc |   1 +
>  UefiCpuPkg/Library/CpuTimerLib/BaseRiscV64CpuTimerLib.inf |  32 
>  UefiCpuPkg/Library/CpuTimerLib/RiscV64/CpuTimerLib.c  | 199
> 
>  3 files changed, 232 insertions(+)
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
> index 8f2be6cd1b05..2df02bf75a35 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dsc
> +++ b/UefiCpuPkg/UefiCpuPkg.dsc
> @@ -199,6 +199,7 @@ [Components.RISCV64]
>UefiCpuPkg/CpuTimerDxe/CpuTimerDxe.inf
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHan
> dlerLib.inf
>UefiCpuPkg/CpuDxe/CpuDxeRiscV64.inf
> +  UefiCpuPkg/Library/CpuTimerLib/BaseRiscV64CpuTimerLib.inf
> 
>  [BuildOptions]
>*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
> diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseRiscV64CpuTimerLib.inf
> b/UefiCpuPkg/Library/CpuTimerLib/BaseRiscV64CpuTimerLib.inf
> new file mode 100644
> index ..c920e8e098b5
> --- /dev/null
> +++ b/UefiCpuPkg/Library/CpuTimerLib/BaseRiscV64CpuTimerLib.inf
> @@ -0,0 +1,32 @@
> +## @file
> +# RISC-V Base CPU Timer Library Instance
> +#
> +#  Copyright (c) 2016 - 2019, Hewlett Packard Enterprise Development LP. All
> rights reserved.
> +#  Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x0001001B
> +  BASE_NAME  = BaseRisV64CpuTimerLib
> +  FILE_GUID  = B635A600-EA24-4199-88E8-5761EEA96A51
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = TimerLib
> +
> +[Sources]
> +  RiscV64/CpuTimerLib.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  UefiCpuPkg/UefiCpuPkg.dec
> +
> +[LibraryClasses]
> +  BaseLib
> +  PcdLib
> +  DebugLib
> +
> +[Pcd]
> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency  ##
> CONSUMES
> diff --git a/UefiCpuPkg/Library/CpuTimerLib/RiscV64/CpuTimerLib.c
> b/UefiCpuPkg/Library/CpuTimerLib/RiscV64/CpuTimerLib.c
> new file mode 100644
> index ..9c8efc0f3530
> --- /dev/null
> +++ b/UefiCpuPkg/Library/CpuTimerLib/RiscV64/CpuTimerLib.c
> @@ -0,0 +1,199 @@
> +/** @file
> +  RISC-V instance of Timer Library.
> +
> +  Copyright (c) 2016 - 2022, Hewlett Packard Enterprise Development LP. All
> rights reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> +  Stalls the CPU for at least the given number of ticks.
> +
> +  Stalls the CPU for at least the given number of ticks. It's invoked by
> +  MicroSecondDelay() and NanoSecondDelay().
> +
> +  @param  Delay A period of time to delay in ticks.
> +
> +**/
> +VOID
> +InternalRiscVTimerDelay (
> +  IN UINT32  Delay
> +  )
> +{
> +  UINT32  Ticks;
> +  UINT32  Times;
> +
> +  Times  = Delay >> (RISCV_TIMER_COMPARE_BITS - 2);
> +  Delay &= ((1 << (RISCV_TIMER_COMPARE_BITS - 2)) - 1);
> +  do {
> +//
> +// The target timer count is calculated here
> +//
> +Ticks = RiscVReadTimer () + Delay;
> +Delay = 1 << (RISCV_TIMER_COMPARE_BITS - 2);
> +while (((Ticks - RiscVReadTimer ()) & (1 << (RISCV_TIMER_COMPARE_BITS
> - 1))) == 0) {
> +  CpuPause ();
> +}
> +  } while (Times-- > 0);
> +}
> +
> +/**
> +  Stalls the CPU for at least the given number of microseconds.
> +
> +  Stalls the CPU for the number of microseconds specified by MicroSeconds.
> +
> +  @param  MicroSeconds  The minimum number of microseconds to delay.
> +
> +  @return MicroSeconds
> +
> +**/
> +UINTN
> +EFIAPI
> +MicroSecondDelay (
> +  IN UINTN  MicroSeconds
> +  )
> +{
> +  InternalRiscVTimerDelay (
> +(UINT32)DivU64x32 (
> +  MultU64x32 (
> +MicroSeconds,
> +PcdGet64 (PcdCpuCoreCrystalClockFrequency)
> +),
> +  100u
> +  )
> +);
> +  return MicroSeconds;
> +}
> +
> +/**
> +  Stalls the CPU for at least the given number of nanoseconds.
> +
> +  Stalls the CPU for the number of nanoseconds specified by 

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 06/20] UefiCpuPkg/CpuExceptionHandlerLib: Add RISC-V instance

[Ni, Ray]

I don't prefer to mix the RiscV64 CpuExceptionHandlerLib instance code with x86 
one in
the same directory because they share nothing.
Can you use name such as "RiscVCpuExceptionHandlerLib" as the directory name?

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Sunil V L
> Sent: Sunday, January 29, 2023 3:18 AM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R ; Daniel Schaefer
> ; Abner Chang ; Gerd
> Hoffmann 
> Subject: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 06/20]
> UefiCpuPkg/CpuExceptionHandlerLib: Add RISC-V instance
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> 
> Add Cpu Exception Handler library for RISC-V. This is copied
> from edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVExceptionLib
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Daniel Schaefer 
> Cc: Abner Chang 
> Cc: Gerd Hoffmann 
> Signed-off-by: Sunil V L 
> Acked-by: Abner Chang 
> ---
>  UefiCpuPkg/UefiCpuPkg.dsc
>|   1 +
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHan
> dlerLib.inf |  42 +++
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/RiscV64/CpuExceptionHandlerL
> ib.h  | 116 +
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/RiscV64/CpuExceptionHandlerL
> ib.c  | 133 
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/RiscV64/SupervisorTrapHandle
> r.S   | 105 
>  5 files changed, 397 insertions(+)
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
> index 96f6770281fe..251a8213f022 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dsc
> +++ b/UefiCpuPkg/UefiCpuPkg.dsc
> @@ -197,6 +197,7 @@ [Components.X64]
> 
>  [Components.RISCV64]
>UefiCpuPkg/CpuTimerDxe/CpuTimerDxe.inf
> +
> UefiCpuPkg/Library/CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHan
> dlerLib.inf
> 
>  [BuildOptions]
>*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHa
> ndlerLib.inf
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHa
> ndlerLib.inf
> new file mode 100644
> index ..82ca22c4bfec
> --- /dev/null
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHa
> ndlerLib.inf
> @@ -0,0 +1,42 @@
> +## @file
> +# RISC-V CPU Exception Handler Library
> +#
> +# Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved.
> +#
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x0001001B
> +  BASE_NAME  = BaseRiscV64CpuExceptionHandlerLib
> +  MODULE_UNI_FILE= BaseRiscV64CpuExceptionHandlerLib.uni
> +  FILE_GUID  = 6AB0D5FD-E615-45A3-9374-E284FB061FC9
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = CpuExceptionHandlerLib
> +
> +#
> +# The following information is for reference only and not required by the
> build tools.
> +#
> +#  VALID_ARCHITECTURES   = RISCV64
> +#
> +
> +[Sources]
> +  RiscV64/SupervisorTrapHandler.S
> +  RiscV64/CpuExceptionHandlerLib.c
> +  RiscV64/CpuExceptionHandlerLib.h
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
> +  UefiCpuPkg/UefiCpuPkg.dec
> +
> +[LibraryClasses]
> +  BaseLib
> +  SerialPortLib
> +  PrintLib
> +  SynchronizationLib
> +  PeCoffGetEntryPointLib
> +  MemoryAllocationLib
> +  DebugLib
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/RiscV64/CpuExceptionHandl
> erLib.h
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/RiscV64/CpuExceptionHandl
> erLib.h
> new file mode 100644
> index ..30f47e87552b
> --- /dev/null
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/RiscV64/CpuExceptionHandl
> erLib.h
> @@ -0,0 +1,116 @@
> +/** @file
> +
> +  RISC-V Exception Handler library definition file.
> +
> +  Copyright (c) 2019-2022, Hewlett Packard Enterprise Development LP. All
> rights reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef RISCV_CPU_EXECPTION_HANDLER_LIB_H_
> +#define RISCV_CPU_EXECPTION_HANDLER_LIB_H_
> +
> +#include 
> +
> +/**
> +  Trap Handler for S-mode
> +
> +**/
> +VOID
> +SupervisorModeTrap (
> +  VOID
> +  );
> +
> +//
> +// Index of SMode trap register
> +//
> +#define SMODE_TRAP_REGS_zero 0
> +#define SMODE_TRAP_REGS_ra   1
> +#define SMODE_TRAP_REGS_sp   2
> +#define SMODE_TRAP_REGS_gp   3
> +#define SMODE_TRAP_REGS_tp   4
> +#define SMODE_TRAP_REGS_t0   5
> +#define SMODE_TRAP_REGS_t1   6
> +#define SMODE_TRAP_REGS_t2   7
> +#define SMODE_TRAP_REGS_s0   8
> +#define SMODE_TRAP_REGS_s1   9
> +#define SMODE_TRAP_REGS_a0   10
> +#define SMODE_TRAP_REGS_a1   11
> +#define SMODE_TRAP_REGS_a2   12
> +#define SMODE_TRAP_REGS_a3   13
> +#define SMODE_TRAP_REGS_a4   14

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 05/20] UefiCpuPkg: Add CpuTimerDxe module

[Ni, Ray]

I am curious if this module will support other arch as well? If it's RiscV 
specific, there is no need for creating the RiscV64 folder.

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Sunil V L
> Sent: Sunday, January 29, 2023 3:18 AM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R ; Daniel Schaefer
> ; Gerd Hoffmann ; Abner
> Chang 
> Subject: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 05/20]
> UefiCpuPkg: Add CpuTimerDxe module
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> 
> This DXE module initializes the timer interrupt handler
> and installs the Arch Timer protocol.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Daniel Schaefer 
> Cc: Gerd Hoffmann 
> Signed-off-by: Sunil V L 
> Acked-by: Abner Chang 
> ---
>  UefiCpuPkg/UefiCpuPkg.dsc|   3 +
>  UefiCpuPkg/CpuTimerDxe/CpuTimerDxe.inf   |  51 
>  UefiCpuPkg/CpuTimerDxe/RiscV64/Timer.h   | 177 
>  UefiCpuPkg/CpuTimerDxe/RiscV64/Timer.c   | 294 
>  UefiCpuPkg/CpuTimerDxe/CpuTimer.uni  |  14 +
>  UefiCpuPkg/CpuTimerDxe/CpuTimerExtra.uni |  12 +
>  6 files changed, 551 insertions(+)
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
> index f9a46089d2c7..96f6770281fe 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dsc
> +++ b/UefiCpuPkg/UefiCpuPkg.dsc
> @@ -195,5 +195,8 @@ [Components.IA32, Components.X64]
>  [Components.X64]
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/UnitTest/DxeCpuExceptionHan
> dlerLibUnitTest.inf
> 
> +[Components.RISCV64]
> +  UefiCpuPkg/CpuTimerDxe/CpuTimerDxe.inf
> +
>  [BuildOptions]
>*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
> diff --git a/UefiCpuPkg/CpuTimerDxe/CpuTimerDxe.inf
> b/UefiCpuPkg/CpuTimerDxe/CpuTimerDxe.inf
> new file mode 100644
> index ..d7706328b591
> --- /dev/null
> +++ b/UefiCpuPkg/CpuTimerDxe/CpuTimerDxe.inf
> @@ -0,0 +1,51 @@
> +## @file
> +# Timer Arch protocol module
> +#
> +# Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All rights
> reserved.
> +#
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x0001001b
> +  BASE_NAME  = CpuTimerDxe
> +  MODULE_UNI_FILE= CpuTimer.uni
> +  FILE_GUID  = 055DDAC6-9142-4013-BF20-FC2E5BC325C9
> +  MODULE_TYPE= DXE_DRIVER
> +  VERSION_STRING = 1.0
> +  ENTRY_POINT= TimerDriverInitialize
> +#
> +# The following information is for reference only and not required by the
> build
> +# tools.
> +#
> +#  VALID_ARCHITECTURES   = RISCV64
> +#
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  UefiCpuPkg/UefiCpuPkg.dec
> +
> +[LibraryClasses]
> +  BaseLib
> +  DebugLib
> +  IoLib
> +  CpuLib
> +  UefiBootServicesTableLib
> +  UefiDriverEntryPoint
> +
> +[LibraryClasses.RISCV64]
> +  RiscVSbiLib
> +
> +[Sources.RISCV64]
> +  RiscV64/Timer.h
> +  RiscV64/Timer.c
> +
> +[Protocols]
> +  gEfiCpuArchProtocolGuid   ## CONSUMES
> +  gEfiTimerArchProtocolGuid ## PRODUCES
> +
> +[Depex]
> +  gEfiCpuArchProtocolGuid
> +
> +[UserExtensions.TianoCore."ExtraFiles"]
> +  CpuTimerExtra.uni
> diff --git a/UefiCpuPkg/CpuTimerDxe/RiscV64/Timer.h
> b/UefiCpuPkg/CpuTimerDxe/RiscV64/Timer.h
> new file mode 100644
> index ..586eb0cfadb4
> --- /dev/null
> +++ b/UefiCpuPkg/CpuTimerDxe/RiscV64/Timer.h
> @@ -0,0 +1,177 @@
> +/** @file
> +  RISC-V Timer Architectural Protocol definitions
> +
> +  Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All rights
> reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef TIMER_H_
> +#define TIMER_H_
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +//
> +// RISC-V use 100us timer.
> +// The default timer tick duration is set to 10 ms = 10 * 1000 * 10 100 ns 
> units
> +//
> +#define DEFAULT_TIMER_TICK_DURATION  10
> +
> +extern VOID
> +RiscvSetTimerPeriod (
> +  UINT32  TimerPeriod
> +  );
> +
> +//
> +// Function Prototypes
> +//
> +
> +/**
> +  Initialize the Timer Architectural Protocol driver
> +
> +  @param ImageHandle ImageHandle of the loaded driver
> +  @param SystemTable Pointer to the System Table
> +
> +  @retval EFI_SUCCESSTimer Architectural Protocol created
> +  @retval EFI_OUT_OF_RESOURCES   Not enough resources available to
> initialize driver.
> +  @retval EFI_DEVICE_ERROR   A device error occured attempting to
> initialize the driver.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +TimerDriverInitialize (
> +  IN EFI_HANDLEImageHandle,
> +  IN EFI_SYSTEM_TABLE  *SystemTable
> +  )
> +;
> +
> +/**
> +
> +  This function adjusts the period of timer interrupts to the value specified
> +  by TimerPeriod.  If the timer period is updated, then the selected timer
> +  period is stored in EFI_TIMER.TimerPeriod, and EFI_SUCCESS is 

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 04/20] UefiCpuPkg: Add RISCV_EFI_BOOT_PROTOCOL related definitions

[Ni, Ray]

Acked-by: Ray Ni 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Sunil V L
> Sent: Sunday, January 29, 2023 3:18 AM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R ; Daniel Schaefer
> ; Gerd Hoffmann ; Abner
> Chang ; Heinrich Schuchardt
> 
> Subject: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 04/20]
> UefiCpuPkg: Add RISCV_EFI_BOOT_PROTOCOL related definitions
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> 
> RISC-V UEFI based platforms need to support RISCV_EFI_BOOT_PROTOCOL.
> Add this protocol GUID definition and the header file required.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Daniel Schaefer 
> Cc: Gerd Hoffmann 
> Signed-off-by: Sunil V L 
> Acked-by: Abner Chang 
> Reviewed-by: Heinrich Schuchardt 
> ---
>  UefiCpuPkg/UefiCpuPkg.dec   |  7 
>  UefiCpuPkg/Include/Protocol/RiscVBootProtocol.h | 34
> 
>  2 files changed, 41 insertions(+)
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
> index cff239d5283e..903ad52da91b 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -86,6 +86,13 @@ [Protocols]
>## Include/Protocol/SmMonitorInit.h
>gEfiSmMonitorInitProtocolGuid  = { 0x228f344d, 0xb3de, 0x43bb, { 0xa4,
> 0xd7, 0xea, 0x20, 0xb, 0x1b, 0x14, 0x82 }}
> 
> +[Protocols.RISCV64]
> +  #
> +  # Protocols defined for RISC-V systems
> +  #
> +  ## Include/Protocol/RiscVBootProtocol.h
> +  gRiscVEfiBootProtocolGuid  = { 0xccd15fec, 0x6f73, 0x4eec, { 0x83, 0x95,
> 0x3e, 0x69, 0xe4, 0xb9, 0x40, 0xbf }}
> +
>  #
>  # [Error.gUefiCpuPkgTokenSpaceGuid]
>  #   0x8001 | Invalid value provided.
> diff --git a/UefiCpuPkg/Include/Protocol/RiscVBootProtocol.h
> b/UefiCpuPkg/Include/Protocol/RiscVBootProtocol.h
> new file mode 100644
> index ..ed223b852d34
> --- /dev/null
> +++ b/UefiCpuPkg/Include/Protocol/RiscVBootProtocol.h
> @@ -0,0 +1,34 @@
> +/** @file
> +  RISC-V Boot Protocol mandatory for RISC-V UEFI platforms.
> +
> +  @par Revision Reference:
> +  The protocol specification can be found at
> +  https://github.com/riscv-non-isa/riscv-uefi
> +
> +  Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef RISCV_BOOT_PROTOCOL_H_
> +#define RISCV_BOOT_PROTOCOL_H_
> +
> +typedef struct _RISCV_EFI_BOOT_PROTOCOL RISCV_EFI_BOOT_PROTOCOL;
> +
> +#define RISCV_EFI_BOOT_PROTOCOL_REVISION  0x0001
> +#define RISCV_EFI_BOOT_PROTOCOL_LATEST_VERSION \
> +RISCV_EFI_BOOT_PROTOCOL_REVISION
> +
> +typedef
> +EFI_STATUS
> +(EFIAPI *EFI_GET_BOOT_HARTID)(
> +  IN RISCV_EFI_BOOT_PROTOCOL   *This,
> +  OUT UINTN*BootHartId
> +  );
> +
> +typedef struct _RISCV_EFI_BOOT_PROTOCOL {
> +  UINT64 Revision;
> +  EFI_GET_BOOT_HARTIDGetBootHartId;
> +} RISCV_EFI_BOOT_PROTOCOL;
> +
> +#endif
> --
> 2.38.0
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99859): https://edk2.groups.io/g/devel/message/99859
Mute This Topic: https://groups.io/mt/96593496/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 20/20] Maintainers.txt: Add entry for OvmfPkg/RiscVVirt

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Hi Jiewen and Sunil,
Sorry, I am not allowed to keep working on RISC-V stuff, at least at the 
moment. Maybe later in the future.  
Abner
> -Original Message-
> From: Yao, Jiewen 
> Sent: Thursday, February 9, 2023 1:07 PM
> To: Sunil V L ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Chang, Abner
> ; Andrew Fish ; Leif Lindholm
> 
> Subject: RE: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 20/20]
> Maintainers.txt: Add entry for OvmfPkg/RiscVVirt
> 
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
> 
> 
> Thanks.
> 
> I agree to add Sunil V L  to be a reviewer.
> Reviewed-by: Jiewen Yao 
> 
> > -Original Message-
> > From: Sunil V L 
> > Sent: Thursday, February 9, 2023 12:34 PM
> > To: devel@edk2.groups.io; Yao, Jiewen 
> > Cc: Kinney, Michael D ;
> > abner.ch...@amd.com; Andrew Fish ; Leif Lindholm
> > 
> > Subject: Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7
> > 20/20]
> > Maintainers.txt: Add entry for OvmfPkg/RiscVVirt
> >
> > Hi Jiewen,
> >
> > On Thu, Feb 09, 2023 at 03:32:20AM +, Yao, Jiewen wrote:
> > > Hello
> > > I have not tracked all discussion. Sorry for that.
> > > May I know if we have discussed the option to create RiscVVirtPkg ?
> > > similar to
> > https://github.com/tianocore/edk2/tree/master/ArmVirtPkg . To me, that
> > is more natural place.
> > >
> >
> > Thanks for the feedback. Yes, this was discussed and recommendation
> > was to add in OvmfPkg instead of creating RiscVVirtPkg..
> > https://edk2.groups.io/g/devel/message/85932
> >
> > >
> > > For the new content on RiscVVirt, I recommend to add one more
> > reviewer/maintainer.
> > > I notice the patches are Acked-by: Abner Chang. Can we get his help on 
> > > that?
> > >
> >
> > Agree, that was in my plan to find out some one. Abner had given up
> > RISC-V mandatory roles. He was helping me here since he was the
> > original to start this. So, I didn't add him but I will be happy if Abner 
> > agrees.
> >
> > Will find out and add one more reviewer when I revise the series.
> >
> > Thanks!
> > Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99858): https://edk2.groups.io/g/devel/message/99858
Mute This Topic: https://groups.io/mt/96593524/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH] IntelSiliconPkg/SpiFvbServiceSmm: Support Other NVS variable region.

[Chiu, Chasel]

Platform may implement Other NVS variable region following Regular
variable region and in this case SpiFvbService should include both
region size when calculating the total NVS region size.

One usage model is EventLog NVS region and there could be others.

Cc: Ashraf Ali S 
Cc: Isaac Oram 
Cc: Rangasai V Chaganty 
Cc: Ray Ni 
Cc: Michael Kubacki 
Signed-off-by: Chasel Chiu 
---
 
Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceCommon.c 
| 7 +++
 Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceSmm.inf 
 | 7 ---
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec  
 | 8 
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceCommon.c
 
b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceCommon.c
index 942abf95a6..bcde98131d 100644
--- 
a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceCommon.c
+++ 
b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceCommon.c
@@ -568,6 +568,13 @@ GetVariableFvInfo (
 return;
   }
 
+  //
+  // GetVariableFlashNvStorageInfo () only reports regular variable region 
information,
+  // if platform implemented a separate Other variable region following the 
regular variable region,
+  // the size should be included as overall NVS variable region size.
+  //
+  NvStoreLength += PcdGet32 (PcdFlashNvStorageOtherVariableSize);
+
   Status = GetVariableFlashFtwSpareInfo (, );
   if (!EFI_ERROR (Status)) {
 // Stay within the current UINT32 size assumptions in the variable stack.
diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceSmm.inf
 
b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceSmm.inf
index 73049eceb2..f40067418a 100644
--- 
a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceSmm.inf
+++ 
b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceSmm.inf
@@ -43,9 +43,10 @@
   IntelSiliconPkg/IntelSiliconPkg.dec
 
 [Pcd]
-  gIntelSiliconPkgTokenSpaceGuid.PcdFlashMicrocodeFvBase ## CONSUMES
-  gIntelSiliconPkgTokenSpaceGuid.PcdFlashMicrocodeFvSize ## CONSUMES
-  gIntelSiliconPkgTokenSpaceGuid.PcdFlashVariableStoreType   ## 
SOMETIMES_CONSUMES
+  gIntelSiliconPkgTokenSpaceGuid.PcdFlashMicrocodeFvBase## CONSUMES
+  gIntelSiliconPkgTokenSpaceGuid.PcdFlashMicrocodeFvSize## CONSUMES
+  gIntelSiliconPkgTokenSpaceGuid.PcdFlashVariableStoreType  ## 
SOMETIMES_CONSUMES
+  gIntelSiliconPkgTokenSpaceGuid.PcdFlashNvStorageOtherVariableSize ## CONSUMES
 
 [Sources]
   FvbInfo.c
diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec 
b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
index 63dae756ad..7034ab93b0 100644
--- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
+++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
@@ -194,3 +194,11 @@
   #  Other value: reserved for future use.
   # @Prompt Flash Variable Store type.
   
gIntelSiliconPkgTokenSpaceGuid.PcdFlashVariableStoreType|0x00|UINT8|0x000E
+
+  ## Declares Separate NVS Variable Region Size.
+  #  Platform may implement a Regular variable region and an Other variable 
region, which will require this PCD
+  #  to tell SpiFvbService to include both regions.
+  #  0: No separate Other variable region.
+  #  non-zero: The size of a separate Other variable region following the 
Regular variable region.
+  # @Prompt Separate NVS Variable Region Size.
+  
gIntelSiliconPkgTokenSpaceGuid.PcdFlashNvStorageOtherVariableSize|0x|UINT32|0x000F
-- 
2.35.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99857): https://edk2.groups.io/g/devel/message/99857
Mute This Topic: https://groups.io/mt/96847771/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [IMPORTANT] February Release Reviews and Merges

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Hi Miki,
Here is a submission waiting for maintainer/reviewer's review.
https://edk2.groups.io/g/devel/message/98927 (Adds AmdSmmCpuFeaturesLib for AMD 
Family)

Thanks
Abner


> -Original Message-
> From: disc...@edk2.groups.io  On Behalf Of Demeter,
> Miki via groups.io
> Sent: Thursday, February 9, 2023 8:20 AM
> To: devel@edk2.groups.io; annou...@edk2.groups.io; disc...@edk2.groups.io
> Subject: [edk2-discuss] [IMPORTANT] February Release Reviews and Merges
> 
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
> 
> 
> Important Information About the February Release
> 
> The Stewards are aware there has been an issue with getting patches reviewed
> and/or merged in a timely manner. The stewards are considering a delay to the
> February release to allow for these issues to be addressed.
> 
> Please take the time to validate that your submissions to the email list fall 
> into
> one of the two categories please contact me directly immediately and CC the
> mailing list
> 
> [1] You have patches submitted to the mailing list requesting review with no
> response
> 
> [2] You have patches submitted to the mailing list that have been reviewed but
> not merged for the February release
> 
> 
> Thank you
> 
> --
> Miki Demeter (she/her/Miki)
> Security Researcher / FW Developer
> FST
> Intel Corporation
> 
> Co-Chair, Network of Intel African-Ancestry(NIA) - Oregon NIA-
> Oregon
> 
> Portland Women in Tech Best Speaker
> miki.deme...@intel.com
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99856): https://edk2.groups.io/g/devel/message/99856
Mute This Topic: https://groups.io/mt/96843583/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 20/20] Maintainers.txt: Add entry for OvmfPkg/RiscVVirt

[Yao, Jiewen]

Thanks.

I agree to add Sunil V L  to be a reviewer.
Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Sunil V L 
> Sent: Thursday, February 9, 2023 12:34 PM
> To: devel@edk2.groups.io; Yao, Jiewen 
> Cc: Kinney, Michael D ; abner.ch...@amd.com;
> Andrew Fish ; Leif Lindholm 
> Subject: Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 20/20]
> Maintainers.txt: Add entry for OvmfPkg/RiscVVirt
> 
> Hi Jiewen,
> 
> On Thu, Feb 09, 2023 at 03:32:20AM +, Yao, Jiewen wrote:
> > Hello
> > I have not tracked all discussion. Sorry for that.
> > May I know if we have discussed the option to create RiscVVirtPkg ? similar 
> > to
> https://github.com/tianocore/edk2/tree/master/ArmVirtPkg . To me, that is
> more natural place.
> >
> 
> Thanks for the feedback. Yes, this was discussed and recommendation was
> to add in OvmfPkg instead of creating RiscVVirtPkg..
> https://edk2.groups.io/g/devel/message/85932
> 
> >
> > For the new content on RiscVVirt, I recommend to add one more
> reviewer/maintainer.
> > I notice the patches are Acked-by: Abner Chang. Can we get his help on that?
> >
> 
> Agree, that was in my plan to find out some one. Abner had given up
> RISC-V mandatory roles. He was helping me here since he was the original
> to start this. So, I didn't add him but I will be happy if Abner agrees.
> 
> Will find out and add one more reviewer when I revise the series.
> 
> Thanks!
> Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99855): https://edk2.groups.io/g/devel/message/99855
Mute This Topic: https://groups.io/mt/96593524/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 20/20] Maintainers.txt: Add entry for OvmfPkg/RiscVVirt

[Sunil V L]

Hi Jiewen,

On Thu, Feb 09, 2023 at 03:32:20AM +, Yao, Jiewen wrote:
> Hello
> I have not tracked all discussion. Sorry for that.
> May I know if we have discussed the option to create RiscVVirtPkg ? similar 
> to https://github.com/tianocore/edk2/tree/master/ArmVirtPkg . To me, that is 
> more natural place.
> 

Thanks for the feedback. Yes, this was discussed and recommendation was
to add in OvmfPkg instead of creating RiscVVirtPkg..
https://edk2.groups.io/g/devel/message/85932

> 
> For the new content on RiscVVirt, I recommend to add one more 
> reviewer/maintainer.
> I notice the patches are Acked-by: Abner Chang. Can we get his help on that?
> 

Agree, that was in my plan to find out some one. Abner had given up
RISC-V mandatory roles. He was helping me here since he was the original
to start this. So, I didn't add him but I will be happy if Abner agrees.

Will find out and add one more reviewer when I revise the series.

Thanks!
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99854): https://edk2.groups.io/g/devel/message/99854
Mute This Topic: https://groups.io/mt/96593524/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 20/20] Maintainers.txt: Add entry for OvmfPkg/RiscVVirt

[Yao, Jiewen]

Hello
I have not tracked all discussion. Sorry for that.
May I know if we have discussed the option to create RiscVVirtPkg ? similar to 
https://github.com/tianocore/edk2/tree/master/ArmVirtPkg . To me, that is more 
natural place.


For the new content on RiscVVirt, I recommend to add one more 
reviewer/maintainer.
I notice the patches are Acked-by: Abner Chang. Can we get his help on that?

Thank you
Yao, Jiewen


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael D
> Kinney
> Sent: Thursday, February 9, 2023 9:52 AM
> To: Sunil V L ; devel@edk2.groups.io
> Cc: Andrew Fish ; Leif Lindholm
> ; Kinney, Michael D 
> Subject: Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 20/20]
> Maintainers.txt: Add entry for OvmfPkg/RiscVVirt
> 
> Reviewed-by: Michael D Kinney 
> 
> > -Original Message-
> > From: Sunil V L 
> > Sent: Saturday, January 28, 2023 11:18 AM
> > To: devel@edk2.groups.io
> > Cc: Andrew Fish ; Leif Lindholm
> ; Kinney, Michael D 
> > Subject: [edk2-staging/RiscV64QemuVirt PATCH V7 20/20] Maintainers.txt:
> Add entry for OvmfPkg/RiscVVirt
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> >
> > RiscVVirt is created to support EDK2 for RISC-V qemu
> > virt machine platform. Add maintainer entries.
> >
> > Cc: Andrew Fish 
> > Cc: Leif Lindholm 
> > Cc: Michael D Kinney 
> > Signed-off-by: Sunil V L 
> > ---
> >  Maintainers.txt | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index 68f603b48398..fdb27c39b152 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -539,6 +539,10 @@ F: OvmfPkg/XenResetVector/
> >  R: Anthony Perard  [tperard]
> >  R: Julien Grall  [jgrall]
> >
> > +OvmfPkg: RISC-V Qemu Virt Platform
> > +F: OvmfPkg/RiscVVirt
> > +R: Sunil V L  [vlsunil]
> > +
> >  PcAtChipsetPkg
> >  F: PcAtChipsetPkg/
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg
> > --
> > 2.38.0
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99853): https://edk2.groups.io/g/devel/message/99853
Mute This Topic: https://groups.io/mt/96593524/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC] [staging/CryptoLibrary] Openssl1.1 replacement proposal

[Yao, Jiewen]

If you are asking how to do that best *at this moment*, I suggest we create a 
branch in https://github.com/tianocore/edk2-staging and continue the research 
work. Before September 2023, we need community's help to resolve openssl-3 size 
issue, before check in.

If you are asking how to do that best after September 2023, we have no choice 
but put to edk2 main branch. We have to remove openssl-11.

If we have either openssl-30 and mbedtls work (size/feature), we can replace 
openssl-11 with either openssl-30 or mbedtls.

Worst case, if we have to support dual-crypto module, I think to:
1) replace openssl-11 with openssl-30 directly.
2) add mbedtls as another cryptolib instance.

Thank you
Yao, Jiewen

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Gerd
> Hoffmann
> Sent: Wednesday, February 8, 2023 7:45 PM
> To: devel@edk2.groups.io; Yao, Jiewen 
> Subject: Re: [edk2-devel] [RFC] [staging/CryptoLibrary] Openssl1.1 replacement
> proposal
> 
>   Hi,
> 
> > 3. If 1 or 2 can success, we can replace openssl 1.1 with one crypto lib.
> > If both 1 and 2 fail, we may use *dual-crypto module*. For example: mbedtls
> for PEI and openssl3.0 for DXE.
> > The source code size will become larger, more time to download the tree.
> 
> Suggestions how to do that best, ideally without duplicating CryptoPkg
> for that?
> 
> A while back I've tried to add openssl-3 in parallel to openssl-11,
> with the idea to allow projects picking the one or the other, and quicky
> ran into problems because apparently libraries can't add include
> directories.  Only packages can do that (see Includes.Common.Private in
> CryptoPkg/CryptoPkg.dec which adds Library/OpensslLib/openssl/include).
> 
> take care,
>   Gerd
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99852): https://edk2.groups.io/g/devel/message/99852
Mute This Topic: https://groups.io/mt/96741156/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V3] RedfishPkg: RedfishRestExDxe: Two PCDs for controlling the requests

[Igor Kulchytskyy via groups.io]

Since BIOS should work with different BMC implementation
chunked requests as well as Expect header should be optional.
One PCD is used to enable/disable Expect header.
Another PCD is used to enable/disable chunked requests.

Reviewed-by: Abner Chang 
Cc: Abner Chang 
Cc: Nickle Wang 
Signed-off-by: Igor Kulchytskyy 
---
 RedfishPkg/RedfishPkg.dec   |  10 ++
 RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf|   2 +
 RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c |  23 ++--
 RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c | 137 
 4 files changed, 111 insertions(+), 61 deletions(-)

diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
index d2b189b..bf48fdd 100644
--- a/RedfishPkg/RedfishPkg.dec
+++ b/RedfishPkg/RedfishPkg.dec
@@ -97,3 +97,13 @@
   # protocol instance.
   #
   
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDiscoverAccessModeInBand|FALSE|BOOLEAN|0x1002
+  #
+  # This PCD indicates if the EFI REST EX sends chunk request to Redfish 
service.
+  # Default is set to non chunk mode.
+  #
+  
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExChunkRequestMode|FALSE|BOOLEAN|0x1003
+  #
+  # This PCD indicates if the EFI REST EX adds Expect header to the POST, 
PATCH, PUT requests to Redfish service.
+  # Default is set to not add.
+  #
+  
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExAddingExpect|FALSE|BOOLEAN|0x1004
diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf 
b/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
index 75437b0..29003ae 100644
--- a/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
+++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
@@ -57,6 +57,8 @@

 [Pcd]
   gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExServiceAccessModeInBand   ## 
CONSUMES
+  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExChunkRequestMode   ## CONSUMES
+  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExAddingExpect   ## CONSUMES

 [UserExtensions.TianoCore."ExtraFiles"]
   RedfishRestExDxeExtra.uni
diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c 
b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
index 952e9d1..0da0d10 100644
--- a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
+++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
@@ -140,9 +140,6 @@ RedfishHttpAddExpectation (
   }

   *ItsWrite = FALSE;
-  if (PreservedRequestHeaders != NULL) {
-*PreservedRequestHeaders = RequestMessage->Headers;
-  }

   if ((RequestMessage->Data.Request->Method != HttpMethodPut) && 
(RequestMessage->Data.Request->Method != HttpMethodPost) &&
   (RequestMessage->Data.Request->Method != HttpMethodPatch))
@@ -152,10 +149,20 @@ RedfishHttpAddExpectation (

   *ItsWrite = TRUE;

-  NewHeaders = AllocateZeroPool ((RequestMessage->HeaderCount + 1) * sizeof 
(EFI_HTTP_HEADER));
-  CopyMem ((VOID *)NewHeaders, (VOID *)RequestMessage->Headers, 
RequestMessage->HeaderCount * sizeof (EFI_HTTP_HEADER));
-  HttpSetFieldNameAndValue (NewHeaders + RequestMessage->HeaderCount, 
HTTP_HEADER_EXPECT, HTTP_EXPECT_100_CONTINUE);
-  RequestMessage->HeaderCount++;
-  RequestMessage->Headers = NewHeaders;
+  //
+  // Check PCD before adding Expect header
+  //
+  if(FixedPcdGetBool(PcdRedfishRestExAddingExpect)) {
+if (PreservedRequestHeaders != NULL) {
+  *PreservedRequestHeaders = RequestMessage->Headers;
+}
+
+NewHeaders = AllocateZeroPool ((RequestMessage->HeaderCount + 1) * sizeof 
(EFI_HTTP_HEADER));
+CopyMem ((VOID *)NewHeaders, (VOID *)RequestMessage->Headers, 
RequestMessage->HeaderCount * sizeof (EFI_HTTP_HEADER));
+HttpSetFieldNameAndValue (NewHeaders + RequestMessage->HeaderCount, 
HTTP_HEADER_EXPECT, HTTP_EXPECT_100_CONTINUE);
+RequestMessage->HeaderCount++;
+RequestMessage->Headers = NewHeaders;
+  }
+
   return EFI_SUCCESS;
 }
diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c 
b/RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c
index 4b61fc0..21d5f47 100644
--- a/RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c
+++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c
@@ -66,11 +66,13 @@ RedfishRestExSendReceive (
   HTTP_IO_SEND_NON_CHUNK_PROCESS  SendNonChunkProcess;
   EFI_HTTP_MESSAGEChunkTransferRequestMessage;

-  Status   = EFI_SUCCESS;
-  ResponseData = NULL;
-  IsGetChunkedTransfer = FALSE;
-  SendChunkProcess = HttpIoSendChunkNone;
-  SendNonChunkProcess  = HttpIoSendNonChunkNone;
+  Status= EFI_SUCCESS;
+  ResponseData  = NULL;
+  IsGetChunkedTransfer  = FALSE;
+  SendChunkProcess  = HttpIoSendChunkNone;
+  SendNonChunkProcess   = HttpIoSendNonChunkNone;
+  ItsWrite  = FALSE;
+  PreservedRequestHeaders   = NULL;

   //
   // Validate the parameters
@@ -94,67 +96,84 @@ RedfishRestExSendReceive (
   DEBUG ((DEBUG_INFO, "\nRedfishRestExSendReceive():\n"));
   DEBUG ((DEBUG_INFO, "*** Perform HTTP Request Method - %d, URL: %s\n", 
RequestMessage->Data.Request->Method, 

Re: [edk2-devel] [edk2-non-osi][PATCH V1] ASpeed/ASpeedGopBinPkg: Correct all INF_VERSION value

[Isaac Oram]

Pushed as bc0b6bf..bd07ad3

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Isaac Oram
Sent: Wednesday, February 8, 2023 5:59 PM
To: devel@edk2.groups.io; tommy_hu...@aspeedtech.com
Cc: a...@kernel.org; Desimone, Nathaniel L ; 
quic_llind...@quicinc.com; Kinney, Michael D ; 
Chen, Ryan ; bmc...@aspeedtech.com
Subject: Re: [edk2-devel] [edk2-non-osi][PATCH V1] ASpeed/ASpeedGopBinPkg: 
Correct all INF_VERSION value

Reviewed-by: Isaac Oram 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Tommy Huang
Sent: Wednesday, February 1, 2023 3:14 AM
To: devel@edk2.groups.io
Cc: a...@kernel.org; Desimone, Nathaniel L ; 
Oram, Isaac W ; quic_llind...@quicinc.com; Kinney, 
Michael D ; Chen, Ryan ; 
bmc...@aspeedtech.com
Subject: [edk2-devel] [edk2-non-osi][PATCH V1] ASpeed/ASpeedGopBinPkg: Correct 
all INF_VERSION value

1. Correct all INF_VERSION value.

Cc: Ard Biesheuvel 
Cc: Isaac Oram 
Cc: Nate DeSimone 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Ryan Chen 
Cc: BMC-SW 

Signed-off-by: Tommy Huang 
---
 Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf | 4 ++--  
Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf 
b/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
index d6a674c..6bda488 100644
--- a/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
+++ b/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
@@ -10,11 +10,11 @@
 ##

 

 [Defines]

-  INF_VERSION= 0x00011302
+  INF_VERSION= 1.29
   BASE_NAME  = ASpeedAst2500GopDxe

   FILE_GUID  = 7F81D838-F91D-4C44-8552-8FB912122FDD

   MODULE_TYPE= UEFI_DRIVER

-  VERSION_STRING = 1.29
+  VERSION_STRING = 1.13.02
 

 [Binaries.AArch64]

   PE32|AArch64/ASpeedAst2500Gop.efi|*

diff --git a/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf 
b/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf
index a652ced..3375407 100644
--- a/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf
+++ b/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf
@@ -9,11 +9,11 @@
 ##
 
 [Defines]
-  INF_VERSION= 0x00011302
+  INF_VERSION= 1.29
   BASE_NAME  = ASpeedAst2600GopDxe
   FILE_GUID  = 36f08597-2a8d-4824-9416-59c810b0d9f3
   MODULE_TYPE= UEFI_DRIVER
-  VERSION_STRING = 1.29
+  VERSION_STRING = 1.13.02
 
 [Binaries.AArch64]
   PE32|AArch64/ASpeedAst2600Gop.efi|*
--
2.25.1













-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99850): https://edk2.groups.io/g/devel/message/99850
Mute This Topic: https://groups.io/mt/96619610/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/3] UsbNetworkPkg/UsbRndis: Add USB RNDIS devices support

[RichardHo [何明忠] via groups . io]

Hi Rebecca,

We will modify it in next patch.

Thanks,
Richard

-Original Message-
From: Rebecca Cran 
Sent: 2023年2月8日 12:14 AM
To: devel@edk2.groups.io; Richard Ho (何明忠) 
Cc: Andrew Fish ; Leif Lindholm ; 
Michael D Kinney ; Michael Kubacki 
; Zhiguang Liu ; Liming 
Gao ; Tony Lo (羅金松) 
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v2 1/3] UsbNetworkPkg/UsbRndis: Add 
USB RNDIS devices support

[rebe...@bsdio.com appears similar to someone who previously sent you email, 
but may not be that person. Learn why this could be a risk at 
https://aka.ms/LearnAboutSenderIdentification ]

**CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.**

On 2/4/23 01:54, RichardHo [何明忠] via groups.io wrote:

> diff --git a/UsbNetworkPkg/Include/Protocol/EdkIIUsbEthernetProtocol.h
> b/UsbNetworkPkg/Include/Protocol/EdkIIUsbEthernetProtocol.h
> new file mode 100644
> index 00..629c83e24e
> --- /dev/null
> +++ b/UsbNetworkPkg/Include/Protocol/EdkIIUsbEthernetProtocol.h
> @@ -0,0 +1,873 @@
> +/** @file
> +  Header file contains code for USB Ethernet Protocol
> +  definitions
> +
> +  Copyright (c) 2023, American Megatrends International LLC. All
> +rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent **/
> +
> +#ifndef _EDKII_USB_ETHERNET_PROTOCOL_H #define
> +_EDKII_USB_ETHERNET_PROTOCOL_H

The header guards shouldn't have a leading underscore, since such names are 
reserved for compiler use.

--
Rebecca Cran

-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99849): https://edk2.groups.io/g/devel/message/99849
Mute This Topic: https://groups.io/mt/96740897/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/3] UsbNetworkPkg/UsbRndis: Add USB RNDIS devices support

[RichardHo [何明忠] via groups . io]

Hi Tinh,

Thanks for your response. We will do more test in this patch.

Thanks,
Richard

-Original Message-
From: Tinh Nguyen OS 
Sent: 2023年2月8日 10:46 AM
To: Michael Brown ; devel@edk2.groups.io; Tinh Nguyen OS 
; Richard Ho (何明忠) 
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v2 1/3] UsbNetworkPkg/UsbRndis: Add 
USB RNDIS devices support


**CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.**

On 2/7/2023 3:20 PM, Michael Brown wrote:
> On 07/02/2023 06:21, Tinh Nguyen via groups.io wrote:
>> From: Tinh Nguyen 
>> Date: Tue, 7 Feb 2023 12:43:17 +0700
>> Subject: [PATCH] UsbNetworkPkg: Support rate limitting
>>
>> Signed-off-by: Tinh Nguyen 
>
> Thank you for extending my patch to add the PCD support.  The overall
> patch appears still to be substantially my code: could you please
> credit it as such?
>
Oops, sorry, my alias command generates a patch with my signature which I don't 
review on a regular


See my update below in attached file

Anyway, it is a proposal for Richard to use for his patch. And need his 
approval to pick-up

- Tinh

-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99848): https://edk2.groups.io/g/devel/message/99848
Mute This Topic: https://groups.io/mt/96740897/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Enum size checks in Base.h (UINT32 not ISO C compatible)

[Rebecca Cran]

Given the comment above it, I was looking in the 2.3 specification: 
mention of UINT32 was only introduced in UEFI 2.3.1 Errata C.


The revision history states:

913 Enum definition does not match what our current compilers implement.


I'll send a patch to fix it.


--
Rebecca Cran


On 2/8/23 19:28, Kinney, Michael D wrote:

Hi Rebecca,

Great catch!!!  I think the static assert verifier is incorrect.

The UEFI Spec does clearly state in Section 2.3.1 that enum values
can be type INT32 or UINT32.  The use of 0x assumes use of
only UINT32.  I agree that the correct value to assign to the 32-bit
enum value for this size check should be 0x7.

Mike


-Original Message-
From: Rebecca Cran 
Sent: Wednesday, February 8, 2023 6:20 PM
To: devel@edk2.groups.io; Kinney, Michael D ; Gao, Liming 

Subject: Enum size checks in Base.h (UINT32 not ISO C compatible)

In commit 6440385b17def888544c2454ffba58384b929a22
(https://github.com/tianocore/edk2/commit/6440385b17def888544c2454ffba58384b929a22)
enum size checks were added.

However, according to gcc, ISO C restricts the size of enum values to
int; building with -std=c11 -pedantic results in the error:

MdePkg/Include/Base.h:812:28: error: ISO C restricts enumerator values
to range of ‘int’ [-Werror=pedantic]
812 |   __VerifyInt32EnumValue = 0x

Replacing 0x with 0x7fff fixes the problem.

It looks like this might change in C23, but since the use of
_Static_assert in Base.h we require at least C11 (and I suspect most
compilers aren't C23 compliant) which states:

"The expression that defines the value of an enumeration constant shall
be an integer constant expression that has a value representable as an int.
[Section 6.7.2.2]"

The UEFI Specification appears to say we require an INT32 (i.e. a signed
int) so is the existing code wrong?

--
Rebecca Cran



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99847): https://edk2.groups.io/g/devel/message/99847
Mute This Topic: https://groups.io/mt/96845703/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Enum size checks in Base.h (UINT32 not ISO C compatible)

[Michael D Kinney]

Hi Rebecca,

Great catch!!!  I think the static assert verifier is incorrect.

The UEFI Spec does clearly state in Section 2.3.1 that enum values
can be type INT32 or UINT32.  The use of 0x assumes use of
only UINT32.  I agree that the correct value to assign to the 32-bit
enum value for this size check should be 0x7.

Mike

> -Original Message-
> From: Rebecca Cran 
> Sent: Wednesday, February 8, 2023 6:20 PM
> To: devel@edk2.groups.io; Kinney, Michael D ; 
> Gao, Liming 
> Subject: Enum size checks in Base.h (UINT32 not ISO C compatible)
> 
> In commit 6440385b17def888544c2454ffba58384b929a22
> (https://github.com/tianocore/edk2/commit/6440385b17def888544c2454ffba58384b929a22)
> enum size checks were added.
> 
> However, according to gcc, ISO C restricts the size of enum values to
> int; building with -std=c11 -pedantic results in the error:
> 
> MdePkg/Include/Base.h:812:28: error: ISO C restricts enumerator values
> to range of ‘int’ [-Werror=pedantic]
>812 |   __VerifyInt32EnumValue = 0x
> 
> Replacing 0x with 0x7fff fixes the problem.
> 
> It looks like this might change in C23, but since the use of
> _Static_assert in Base.h we require at least C11 (and I suspect most
> compilers aren't C23 compliant) which states:
> 
> "The expression that defines the value of an enumeration constant shall
> be an integer constant expression that has a value representable as an int.
> [Section 6.7.2.2]"
> 
> The UEFI Specification appears to say we require an INT32 (i.e. a signed
> int) so is the existing code wrong?
> 
> --
> Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99846): https://edk2.groups.io/g/devel/message/99846
Mute This Topic: https://groups.io/mt/96845703/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Enum size checks in Base.h (UINT32 not ISO C compatible)

[Rebecca Cran]

In commit 6440385b17def888544c2454ffba58384b929a22 
(https://github.com/tianocore/edk2/commit/6440385b17def888544c2454ffba58384b929a22) 
enum size checks were added.


However, according to gcc, ISO C restricts the size of enum values to 
int; building with -std=c11 -pedantic results in the error:


MdePkg/Include/Base.h:812:28: error: ISO C restricts enumerator values 
to range of ‘int’ [-Werror=pedantic]

  812 |   __VerifyInt32EnumValue = 0x

Replacing 0x with 0x7fff fixes the problem.

It looks like this might change in C23, but since the use of 
_Static_assert in Base.h we require at least C11 (and I suspect most 
compilers aren't C23 compliant) which states:


"The expression that defines the value of an enumeration constant shall 
be an integer constant expression that has a value representable as an int.

[Section 6.7.2.2]"

The UEFI Specification appears to say we require an INT32 (i.e. a signed 
int) so is the existing code wrong?


--
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99845): https://edk2.groups.io/g/devel/message/99845
Mute This Topic: https://groups.io/mt/96845703/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 RESEND] RedfishPkg: RedfishRestExDxe: Two PCDs for controlling the requests

[Chang, Abner via groups.io]

[AMD Official Use Only - General]



> -Original Message-
> From: Igor Kulchytskyy 
> Sent: Thursday, February 9, 2023 7:57 AM
> To: Chang, Abner ; devel@edk2.groups.io
> Cc: Nickle Wang 
> Subject: RE: [EXTERNAL] RE: [PATCH V2 RESEND] RedfishPkg: RedfishRestExDxe:
> Two PCDs for controlling the requests
> 
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
> 
> 
> Hi Abner,
> Thank you for your comments.
> See my comments on your comments below.
> Igor
> 
> -Original Message-
> From: Chang, Abner 
> Sent: Wednesday, February 8, 2023 4:13 PM
> To: Igor Kulchytskyy ; devel@edk2.groups.io
> Cc: Nickle Wang 
> Subject: [EXTERNAL] RE: [PATCH V2 RESEND] RedfishPkg: RedfishRestExDxe:
> Two PCDs for controlling the requests
> 
> 
> **CAUTION: The e-mail below is from an external source. Please exercise
> caution before opening attachments, clicking links, or following guidance.**
> 
> [AMD Official Use Only - General]
> 
> Hi Igor,
> Few comments in below.
> 
> > -Original Message-
> > From: Igor Kulchytskyy 
> > Sent: Thursday, February 9, 2023 1:23 AM
> > To: devel@edk2.groups.io
> > Cc: Igor Kulchytskyy ; Chang, Abner
> > ; Nickle Wang 
> > Subject: [PATCH V2 RESEND] RedfishPkg: RedfishRestExDxe: Two PCDs for
> > controlling the requests
> >
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > Since BIOS should work with different BMC implementation chunked
> > requests as well as Expect header should be optional.
> > One PCD is used to enable/disable Expect header.
> > Another PCD is used to enable/disable chunked requests.
> >
> > Cc: Abner Chang 
> > Cc: Nickle Wang 
> > Signed-off-by: Igor Kulchytskyy 
> > ---
> >  RedfishPkg/RedfishPkg.dec   |  10 ++
> >  RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf|   2 +
> >  RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c |  23 ++--
> >  RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c | 140
> > 
> > 
> >  4 files changed, 113 insertions(+), 62 deletions(-)
> >
> > diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
> > index d2b189b..89ef32a 100644
> > --- a/RedfishPkg/RedfishPkg.dec
> > +++ b/RedfishPkg/RedfishPkg.dec
> > @@ -97,3 +97,13 @@
> ># protocol instance.
> >#
> >
> >
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDiscoverAccessModeInBand|FALSE|
> > BOOLEAN|0x1002
> > +  #
> > +  # This PCD indicates if the EFI REST EX sends chunk request to Redfish
> service.
> > +  # Default is set to non chunk mode.
> > +  #
> > +
> > +
> >
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExChunkRequestMode|TRUE|BO
> > O
> > + LEAN|0x1003
> We can default set PcdRedfishRestExChunkRequestMode to FALSE.
> Igor: Agree. Just forgot to make it FALSE after I tested BIOS with Expect PCD
> disabled and Chunked PCD enabled.
> 
> > +  #
> > +  # This PCD indicates if the EFI REST EX adds Expect header to the
> > + POST, PATCH,
> > PUT requests to Redfish service.
> > +  # Default is set to not add.
> > +  #
> > +
> > +
> >
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExAddingExpect|FALSE|BOOLEA
> > + N|0x1004
> > diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
> > b/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
> > index 75437b0..29003ae 100644
> > --- a/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
> > +++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
> > @@ -57,6 +57,8 @@
> >
> >  [Pcd]
> >
> > gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExServiceAccessModeInBand
> > ## CONSUMES
> > +  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExChunkRequestMode   ##
> > CONSUMES
> > +  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExAddingExpect   ##
> > CONSUMES
> >
> >  [UserExtensions.TianoCore."ExtraFiles"]
> >RedfishRestExDxeExtra.uni
> > diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
> > b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
> > index 952e9d1..0da0d10 100644
> > --- a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
> > +++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
> > @@ -140,9 +140,6 @@ RedfishHttpAddExpectation (
> >}
> >
> >*ItsWrite = FALSE;
> > -  if (PreservedRequestHeaders != NULL) {
> > -*PreservedRequestHeaders = RequestMessage->Headers;
> > -  }
> >
> >if ((RequestMessage->Data.Request->Method != HttpMethodPut) &&
> > (RequestMessage->Data.Request->Method != HttpMethodPost) &&
> >(RequestMessage->Data.Request->Method != HttpMethodPatch)) @@ -
> > 152,10 +149,20 @@ RedfishHttpAddExpectation (
> >
> >*ItsWrite = TRUE;
> >
> > -  NewHeaders = AllocateZeroPool ((RequestMessage->HeaderCount + 1) *
> > sizeof (EFI_HTTP_HEADER));
> > -  CopyMem ((VOID *)NewHeaders, (VOID *)RequestMessage->Headers,
> > RequestMessage->HeaderCount * sizeof (EFI_HTTP_HEADER));
> > -  HttpSetFieldNameAndValue (NewHeaders + 

Re: [edk2-devel] [edk2-non-osi][PATCH V1] ASpeed/ASpeedGopBinPkg: Correct all INF_VERSION value

[Isaac Oram]

Reviewed-by: Isaac Oram 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Tommy Huang
Sent: Wednesday, February 1, 2023 3:14 AM
To: devel@edk2.groups.io
Cc: a...@kernel.org; Desimone, Nathaniel L ; 
Oram, Isaac W ; quic_llind...@quicinc.com; Kinney, 
Michael D ; Chen, Ryan ; 
bmc...@aspeedtech.com
Subject: [edk2-devel] [edk2-non-osi][PATCH V1] ASpeed/ASpeedGopBinPkg: Correct 
all INF_VERSION value

1. Correct all INF_VERSION value.

Cc: Ard Biesheuvel 
Cc: Isaac Oram 
Cc: Nate DeSimone 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Ryan Chen 
Cc: BMC-SW 

Signed-off-by: Tommy Huang 
---
 Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf | 4 ++--  
Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf 
b/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
index d6a674c..6bda488 100644
--- a/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
+++ b/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
@@ -10,11 +10,11 @@
 ##

 

 [Defines]

-  INF_VERSION= 0x00011302
+  INF_VERSION= 1.29
   BASE_NAME  = ASpeedAst2500GopDxe

   FILE_GUID  = 7F81D838-F91D-4C44-8552-8FB912122FDD

   MODULE_TYPE= UEFI_DRIVER

-  VERSION_STRING = 1.29
+  VERSION_STRING = 1.13.02
 

 [Binaries.AArch64]

   PE32|AArch64/ASpeedAst2500Gop.efi|*

diff --git a/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf 
b/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf
index a652ced..3375407 100644
--- a/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf
+++ b/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf
@@ -9,11 +9,11 @@
 ##
 
 [Defines]
-  INF_VERSION= 0x00011302
+  INF_VERSION= 1.29
   BASE_NAME  = ASpeedAst2600GopDxe
   FILE_GUID  = 36f08597-2a8d-4824-9416-59c810b0d9f3
   MODULE_TYPE= UEFI_DRIVER
-  VERSION_STRING = 1.29
+  VERSION_STRING = 1.13.02
 
 [Binaries.AArch64]
   PE32|AArch64/ASpeedAst2600Gop.efi|*
--
2.25.1








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99843): https://edk2.groups.io/g/devel/message/99843
Mute This Topic: https://groups.io/mt/96619610/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 20/20] Maintainers.txt: Add entry for OvmfPkg/RiscVVirt

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Sunil V L 
> Sent: Saturday, January 28, 2023 11:18 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Leif Lindholm ; 
> Kinney, Michael D 
> Subject: [edk2-staging/RiscV64QemuVirt PATCH V7 20/20] Maintainers.txt: Add 
> entry for OvmfPkg/RiscVVirt
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> 
> RiscVVirt is created to support EDK2 for RISC-V qemu
> virt machine platform. Add maintainer entries.
> 
> Cc: Andrew Fish 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Signed-off-by: Sunil V L 
> ---
>  Maintainers.txt | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 68f603b48398..fdb27c39b152 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -539,6 +539,10 @@ F: OvmfPkg/XenResetVector/
>  R: Anthony Perard  [tperard]
>  R: Julien Grall  [jgrall]
> 
> +OvmfPkg: RISC-V Qemu Virt Platform
> +F: OvmfPkg/RiscVVirt
> +R: Sunil V L  [vlsunil]
> +
>  PcAtChipsetPkg
>  F: PcAtChipsetPkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg
> --
> 2.38.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99842): https://edk2.groups.io/g/devel/message/99842
Mute This Topic: https://groups.io/mt/96593524/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 10/20] EmbeddedPkg: Enable PcdPrePiCpuIoSize for RISC-V

[Michael D Kinney]

Reviewed-by: Michael D Kinney 


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Sunil V L
> Sent: Saturday, January 28, 2023 11:18 AM
> To: devel@edk2.groups.io
> Cc: Leif Lindholm ; Ard Biesheuvel 
> ; Abner Chang ; Daniel
> Schaefer 
> Subject: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 10/20] 
> EmbeddedPkg: Enable PcdPrePiCpuIoSize for RISC-V
> 
> This PCD is required to be enabled so that PrePiLib
> can be used in RISC-V.
> 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Abner Chang 
> Cc: Daniel Schaefer 
> Signed-off-by: Sunil V L 
> ---
>  EmbeddedPkg/EmbeddedPkg.dec | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
> index 341ef5e6a679..2965f01444e9 100644
> --- a/EmbeddedPkg/EmbeddedPkg.dec
> +++ b/EmbeddedPkg/EmbeddedPkg.dec
> @@ -165,6 +165,9 @@ [PcdsFixedAtBuild.IA32]
>  [PcdsFixedAtBuild.X64]
>gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16|UINT8|0x0011
> 
> +[PcdsFixedAtBuild.RISCV64]
> +  gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|0|UINT8|0x0011
> +
>  [PcdsFixedAtBuild.common, PcdsDynamic.common]
>#
># Value to add to a host address to obtain a device address, using
> --
> 2.38.0
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99841): https://edk2.groups.io/g/devel/message/99841
Mute This Topic: https://groups.io/mt/96593506/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 09/20] UefiCpuPkg/UefiCpuPkg.ci.yaml: Ignore RISC-V file

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Sunil V L
> Sent: Saturday, January 28, 2023 11:18 AM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar, 
> Rahul R ; Gerd Hoffmann
> ; Abner Chang 
> Subject: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 09/20] 
> UefiCpuPkg/UefiCpuPkg.ci.yaml: Ignore RISC-V file
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> 
> RISC-V register names do not follow the EDK2 formatting.
> So, add it to ignore list for now.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Signed-off-by: Sunil V L 
> Acked-by: Abner Chang 
> ---
>  UefiCpuPkg/UefiCpuPkg.ci.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.ci.yaml b/UefiCpuPkg/UefiCpuPkg.ci.yaml
> index a377366798b0..953361ba0479 100644
> --- a/UefiCpuPkg/UefiCpuPkg.ci.yaml
> +++ b/UefiCpuPkg/UefiCpuPkg.ci.yaml
> @@ -27,6 +27,7 @@
>  ],
>  ## Both file path and directory path are accepted.
>  "IgnoreFiles": [
> +  "Library/CpuExceptionHandlerLib/RiscV64/CpuExceptionHandlerLib.h"
>  ]
>  },
>  "CompilerPlugin": {
> --
> 2.38.0
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99840): https://edk2.groups.io/g/devel/message/99840
Mute This Topic: https://groups.io/mt/96593505/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v4] IntelSiliconPkg/SpiFvbServiceSmm: Rewrite VariableStore header.

[Chiu, Chasel]

Bug fix patch has been merged: 
https://github.com/tianocore/edk2-platforms/commit/e95c7988994c73918ffa282e2d2f5af11f8addc4

Thanks,
Chasel


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Chiu, Chasel
> Sent: Wednesday, February 8, 2023 2:17 PM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; S, Ashraf Ali 
> ;
> Oram, Isaac W ; Chaganty, Rangasai V
> ; Ni, Ray ; Kubacki,
> Michael 
> Subject: [edk2-devel] [edk2-platforms: PATCH v4]
> IntelSiliconPkg/SpiFvbServiceSmm: Rewrite VariableStore header.
> 
> When invalid VariableStore FV header detected, current SpiFvbService will 
> erase
> both FV and VariableStore headers from flash, however, it will only rewrite FV
> header back and cause invalid VariableStore header.
> 
> This patch adding the support for rewriting both FV header and VariableStore
> header when VariableStore corruption happened.
> The Corrupted variable content should be taken care by FaultTolerantWrite
> driver later.
> 
> Platform has to set PcdFlashVariableStoreType to inform SpiFvbService which
> VariableStoreType should be rewritten.
> 
> Cc: Ashraf Ali S 
> Cc: Isaac Oram 
> Cc: Rangasai V Chaganty 
> Cc: Ray Ni 
> Cc: Michael Kubacki 
> Signed-off-by: Chasel Chiu 
> ---
>  Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c  
>   |
> 69
> --
> ---
>  
> Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceSmm.inf
> |  3 +++
>  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
>   |  8 
>  3 files changed, 75 insertions(+), 5 deletions(-)
> 
> diff --git
> a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c
> b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c
> index 6b4bcdcfe3..052be97872 100644
> ---
> a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c
> +++ b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbSe
> +++ rviceMm.c
> @@ -12,6 +12,7 @@
>  #include  #include
>  #include
> +#include 
> /**   The function installs EFI_FIRMWARE_VOLUME_BLOCK protocol@@ -113,7
> +114,12 @@ FvbInitialize (
>UINT32MaxLbaSize;   UINT32 
>BytesWritten;
> UINTN BytesErased;+  EFI_PHYSICAL_ADDRESS
> NvStorageBaseAddress;   UINT64
> NvStorageFvSize;+  UINT32
> ExpectedBytesWritten;+  VARIABLE_STORE_HEADER
> *VariableStoreHeader;+  UINT8 
> VariableStoreType;+  UINT8
> *NvStoreBuffer;Status = GetVariableFlashNvStorageInfo (,
> );   if (EFI_ERROR (Status)) {@@ -124,12 +130,14 @@
> FvbInitialize (
> // Stay within the current UINT32 size assumptions in the variable stack.
> Status = SafeUint64ToUint32 (BaseAddress,
> [0].FvBase);+  NvStorageBaseAddress =
> mPlatformFvBaseAddress[0].FvBase;   if (EFI_ERROR (Status))
> { ASSERT_EFI_ERROR (Status); DEBUG ((DEBUG_ERROR, "[%a] - 64-bit
> variable storage base address not supported.\n", __FUNCTION__)); return;  
>  }
> Status = SafeUint64ToUint32 (NvStorageFvSize,
> [0].FvSize);+  NvStorageFvSize =
> mPlatformFvBaseAddress[0].FvSize;   if (EFI_ERROR (Status))
> { ASSERT_EFI_ERROR (Status); DEBUG ((DEBUG_ERROR, "[%a] - 64-bit
> variable storage size not supported.\n", __FUNCTION__));@@ -186,8 +194,59
> @@ FvbInitialize (
>}   continue; }-BytesWritten = 
> FvHeader->HeaderLength;-
> Status = SpiFlashWrite ((UINTN)BaseAddress, ,
> (UINT8*)FvHeader);++BytesWritten = FvHeader->HeaderLength;+
> ExpectedBytesWritten = BytesWritten;+if (BaseAddress !=
> NvStorageBaseAddress) {+  Status = SpiFlashWrite ((UINTN)BaseAddress,
> , (UINT8 *)FvHeader);+} else {+  //+  // 
> This is
> Variable Store, rewrite both EFI_FIRMWARE_VOLUME_HEADER and
> VARIABLE_STORE_HEADER.+  // The corrupted Variable content should be
> taken care by FaultTolerantWrite driver later.+  //+  
> NvStoreBuffer =
> NULL;+  NvStoreBuffer = AllocateZeroPool (sizeof
> (VARIABLE_STORE_HEADER) + FvHeader->HeaderLength);+  if
> (NvStoreBuffer != NULL) {+//+// Combine FV header and
> VariableStore header into the buffer.+//+CopyMem 
> (NvStoreBuffer,
> FvHeader, FvHeader->HeaderLength);+VariableStoreHeader =
> (VARIABLE_STORE_HEADER *)(NvStoreBuffer + FvHeader->HeaderLength);+
> VariableStoreType   = PcdGet8 (PcdFlashVariableStoreType);+switch
> (VariableStoreType) {+  case 0:+DEBUG 
> ((DEBUG_ERROR, "Type:
> gEfiVariableGuid\n"));+CopyGuid 
> (>Signature,
> );+break;+  case 1:+ 
>DEBUG
> ((DEBUG_ERROR, "Type: gEfiAuthenticatedVariableGuid\n"));+
> CopyGuid
> 

Re: [edk2-devel] [edk2-platforms: PATCH v4] IntelSiliconPkg/SpiFvbServiceSmm: Rewrite VariableStore header.

[Chiu, Chasel]

Thanks Isaac!

> -Original Message-
> From: Oram, Isaac W 
> Sent: Wednesday, February 8, 2023 5:39 PM
> To: devel@edk2.groups.io; mikub...@linux.microsoft.com; Chiu, Chasel
> 
> Cc: S, Ashraf Ali ; Chaganty, Rangasai V
> ; Ni, Ray ; Kubacki,
> Michael 
> Subject: RE: [edk2-devel] [edk2-platforms: PATCH v4]
> IntelSiliconPkg/SpiFvbServiceSmm: Rewrite VariableStore header.
> 
> Reviewed-by: Isaac Oram 
> 
> At some point, we should work to comment the related flows better so that
> code is clear on the different responsibilities for the different paths 
> through first
> boots, normal scenarios, reclaims, and error remediation.  For now though, 
> this
> is fine.
> 
> Regards,
> Isaac
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael
> Kubacki
> Sent: Wednesday, February 8, 2023 4:41 PM
> To: devel@edk2.groups.io; Chiu, Chasel 
> Cc: S, Ashraf Ali ; Oram, Isaac W
> ; Chaganty, Rangasai V
> ; Ni, Ray ; Kubacki,
> Michael 
> Subject: Re: [edk2-devel] [edk2-platforms: PATCH v4]
> IntelSiliconPkg/SpiFvbServiceSmm: Rewrite VariableStore header.
> 
> Reviewed-by: Michael Kubacki 
> 
> On the following lines, I recommend moving the assignment until after the if
> block. It seems unnecessary to assign a potentially invalid value to a local
> variable before checking the validation result.
> 
>Status = SafeUint64ToUint32 (BaseAddress,
> [0].FvBase);
>NvStorageBaseAddress = mPlatformFvBaseAddress[0].FvBase;
>if (EFI_ERROR (Status)) {
>  ASSERT_EFI_ERROR (Status);
>  DEBUG ((DEBUG_ERROR, "[%a] - 64-bit variable storage base address not
> supported.\n", __FUNCTION__));
>  return;
>}
> 
> ---
> 
> (similar for NvStorageFvSize)
> 
> Thanks,
> Michael
> 
> On 2/8/2023 5:17 PM, Chiu, Chasel wrote:
> > When invalid VariableStore FV header detected, current SpiFvbService
> > will erase both FV and VariableStore headers from flash, however, it
> > will only rewrite FV header back and cause invalid VariableStore
> > header.
> >
> > This patch adding the support for rewriting both FV header and
> > VariableStore header when VariableStore corruption happened.
> > The Corrupted variable content should be taken care by
> > FaultTolerantWrite driver later.
> >
> > Platform has to set PcdFlashVariableStoreType to inform SpiFvbService
> > which VariableStoreType should be rewritten.
> >
> > Cc: Ashraf Ali S 
> > Cc: Isaac Oram 
> > Cc: Rangasai V Chaganty 
> > Cc: Ray Ni 
> > Cc: Michael Kubacki 
> > Signed-off-by: Chasel Chiu 
> > ---
> >   
> > Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c
> | 69
> --
> ---
> >
> Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceSmm.inf
> |  3 +++
> >   Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec 
> >  |  8 
> >   3 files changed, 75 insertions(+), 5 deletions(-)
> >
> > diff --git
> > a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServ
> > iceMm.c
> > b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServ
> > iceMm.c
> > index 6b4bcdcfe3..052be97872 100644
> > ---
> > a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServ
> > iceMm.c
> > +++ b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvb
> > +++ ServiceMm.c
> > @@ -12,6 +12,7 @@
> >   #include 
> >
> >   #include 
> >
> >   #include 
> >
> > +#include 
> >
> >
> >
> >   /**
> >
> > The function installs EFI_FIRMWARE_VOLUME_BLOCK protocol
> >
> > @@ -113,7 +114,12 @@ FvbInitialize (
> > UINT32MaxLbaSize;
> >
> > UINT32BytesWritten;
> >
> > UINTN BytesErased;
> >
> > +  EFI_PHYSICAL_ADDRESS  NvStorageBaseAddress;
> >
> > UINT64NvStorageFvSize;
> >
> > +  UINT32ExpectedBytesWritten;
> >
> > +  VARIABLE_STORE_HEADER *VariableStoreHeader;
> >
> > +  UINT8 VariableStoreType;
> >
> > +  UINT8 *NvStoreBuffer;
> >
> >
> >
> > Status = GetVariableFlashNvStorageInfo (,
> > );
> >
> > if (EFI_ERROR (Status)) {
> >
> > @@ -124,12 +130,14 @@ FvbInitialize (
> >
> >
> > // Stay within the current UINT32 size assumptions in the variable 
> > stack.
> >
> > Status = SafeUint64ToUint32 (BaseAddress,
> > [0].FvBase);
> >
> > +  NvStorageBaseAddress = mPlatformFvBaseAddress[0].FvBase;
> >
> > if (EFI_ERROR (Status)) {
> >
> >   ASSERT_EFI_ERROR (Status);
> >
> >   DEBUG ((DEBUG_ERROR, "[%a] - 64-bit variable storage base
> > address not supported.\n", __FUNCTION__));
> >
> >   return;
> >
> > }
> >
> > Status = SafeUint64ToUint32 (NvStorageFvSize,
> > [0].FvSize);
> >
> > +  NvStorageFvSize = mPlatformFvBaseAddress[0].FvSize;
> >
> > if (EFI_ERROR (Status)) {

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 03/20] MdePkg: Add BaseRiscVSbiLib Library for RISC-V

[Michael D Kinney]

One comment below.

Mike

> -Original Message-
> From: Sunil V L 
> Sent: Saturday, January 28, 2023 11:18 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming 
> ; Liu, Zhiguang ;
> Abner Chang 
> Subject: [edk2-staging/RiscV64QemuVirt PATCH V7 03/20] MdePkg: Add 
> BaseRiscVSbiLib Library for RISC-V
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> 
> This library is required to make SBI ecalls from the S-mode EDK2.
> This is mostly copied from
> edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Signed-off-by: Sunil V L 
> Acked-by: Abner Chang 
> ---
>  MdePkg/MdePkg.dec  |   4 +
>  MdePkg/MdePkg.dsc  |   3 +
>  MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf |  25 +++
>  MdePkg/Include/Library/BaseRiscVSbiLib.h   | 127 +++
>  MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.c   | 227 
>  5 files changed, 386 insertions(+)
> 
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> index 3d08f20d15b0..ca2e4dcf815c 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -316,6 +316,10 @@ [LibraryClasses.IA32, LibraryClasses.X64]
>##  @libraryclass  Provides function to support TDX processing.
>TdxLib|Include/Library/TdxLib.h
> 
> +[LibraryClasses.RISCV64]
> +  ##  @libraryclass  Provides function to make ecalls to SBI
> +  BaseRiscVSbiLib|Include/Library/BaseRiscVSbiLib.h
> +
>  [Guids]
>#
># GUID defined in UEFI2.1/UEFI2.0/EFI1.1
> diff --git a/MdePkg/MdePkg.dsc b/MdePkg/MdePkg.dsc
> index 32a852dc466e..0ac7618b4623 100644
> --- a/MdePkg/MdePkg.dsc
> +++ b/MdePkg/MdePkg.dsc
> @@ -190,4 +190,7 @@ [Components.ARM, Components.AARCH64]
>MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.inf
>MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
> 
> +[Components.RISCV64]
> +  MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
> +
>  [BuildOptions]
> diff --git a/MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf 
> b/MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
> new file mode 100644
> index ..d03132bf01c1
> --- /dev/null
> +++ b/MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
> @@ -0,0 +1,25 @@
> +## @file
> +# RISC-V Library to call SBI ecalls
> +#
> +#  Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION = 0x0001001b
> +  BASE_NAME   = BaseRiscVSbiLib
> +  FILE_GUID   = D742CF3D-E600-4009-8FB5-318073008508
> +  MODULE_TYPE = BASE
> +  VERSION_STRING  = 1.0
> +  LIBRARY_CLASS   = RiscVSbiLib
> +
> +[Sources]
> +  BaseRiscVSbiLib.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +
> +[LibraryClasses]
> +  BaseLib
> diff --git a/MdePkg/Include/Library/BaseRiscVSbiLib.h 
> b/MdePkg/Include/Library/BaseRiscVSbiLib.h
> new file mode 100644
> index ..3a3cbfb879f1
> --- /dev/null
> +++ b/MdePkg/Include/Library/BaseRiscVSbiLib.h
> @@ -0,0 +1,127 @@
> +/** @file
> +  Library to call the RISC-V SBI ecalls
> +
> +  Copyright (c) 2021-2022, Hewlett Packard Development LP. All rights 
> reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +  @par Glossary:
> +- Hart - Hardware Thread, similar to a CPU core
> +
> +  Currently, EDK2 needs to call SBI only to set the time and to do system 
> reset.
> +
> +**/
> +
> +#ifndef RISCV_SBI_LIB_H_
> +#define RISCV_SBI_LIB_H_
> +
> +#include 
> +
> +/* SBI Extension IDs */
> +#define SBI_EXT_TIME  0x54494D45
> +#define SBI_EXT_SRST  0x53525354
> +
> +/* SBI function IDs for TIME extension*/
> +#define SBI_EXT_TIME_SET_TIMER  0x0
> +
> +/* SBI function IDs for SRST extension */
> +#define SBI_EXT_SRST_RESET  0x0
> +
> +#define SBI_SRST_RESET_TYPE_SHUTDOWN 0x0
> +#define SBI_SRST_RESET_TYPE_COLD_REBOOT  0x1
> +#define SBI_SRST_RESET_TYPE_WARM_REBOOT  0x2
> +
> +#define SBI_SRST_RESET_REASON_NONE 0x0
> +#define SBI_SRST_RESET_REASON_SYSFAIL  0x1
> +
> +/* SBI return error codes */
> +#define SBI_SUCCESS0
> +#define SBI_ERR_FAILED -1
> +#define SBI_ERR_NOT_SUPPORTED  -2
> +#define SBI_ERR_INVALID_PARAM  -3
> +#define SBI_ERR_DENIED -4
> +#define SBI_ERR_INVALID_ADDRESS-5
> +#define SBI_ERR_ALREADY_AVAILABLE  -6
> +#define SBI_ERR_ALREADY_STARTED-7
> +#define SBI_ERR_ALREADY_STOPPED-8
> +
> +#define SBI_LAST_ERR  SBI_ERR_ALREADY_STOPPED
> +
> +typedef struct {
> +  UINT64BootHartId;
> +  VOID  *PeiServiceTable;// PEI Service table
> +  VOID  *PrePiHobList;   // Pre PI Hob List
> +  UINT64FlattenedDeviceTree; // Pointer to Flattened Device tree
> +} EFI_RISCV_FIRMWARE_CONTEXT;
> +
> +//
> +// EDK2 OpenSBI firmware extension return status.
> +//
> +typedef struct {
> +  UINTNError; ///< SBI status code
> +  UINTN 

Re: [edk2-devel][edk2-platforms][PATCH V2 1/1] AdvancedFeaturePkg: Improve sample build instructions

[Isaac Oram]

Pushed as 615afc82db..ab4ddecb12

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Rebecca Cran
Sent: Thursday, January 19, 2023 7:56 AM
To: Oram, Isaac W ; devel@edk2.groups.io
Cc: Chaganty, Rangasai V ; Desimone, Nathaniel L 
; Gao, Liming ; 
Rebecca Cran 
Subject: Re: [edk2-devel][edk2-platforms][PATCH V2 1/1] AdvancedFeaturePkg: 
Improve sample build instructions

Reviewed-by: Rebecca Cran 

On 1/18/23 18:20, Isaac Oram wrote:
> V1: Make the Windows build example current working directory based 
> instead of arbitrary.
> V2: Fix case mismatch in edk2 repo local name.
> 
> Cc: Sai Chaganty 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Cc: Rebecca Cran 
> Signed-off-by: Isaac Oram 
> ---
>   Features/Intel/AdvancedFeaturePkg/Readme.md | 14 --
>   1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/Features/Intel/AdvancedFeaturePkg/Readme.md 
> b/Features/Intel/AdvancedFeaturePkg/Readme.md
> index ba50560328..20f456bebe 100644
> --- a/Features/Intel/AdvancedFeaturePkg/Readme.md
> +++ b/Features/Intel/AdvancedFeaturePkg/Readme.md
> @@ -19,19 +19,21 @@ Supported build targets
>   * GCC5
>   
>   ## Windows Example:
> -With current working directory at O:\
> -
>   git clone https://github.com/tianocore/edk2.git
>   
> +git clone https://github.com/tianocore/edk2-non-osi.git
> +
>   git clone https://github.com/tianocore/edk2-platforms.git
>   
> -set workspace=O:\
> +set workspace=%cd%
>   
> -set EDK_TOOLS_PATH=O:\Edk2\BaseTools
> +set EDK_TOOLS_PATH=%workspace%\edk2\BaseTools
>   
> -set 
> packages_path=O:\edk2;O:\edk2-non-osi;O:\edk2-platforms\Platform\Intel
> ;O:\edk2-platforms\Silicon\Intel;O:\edk2-platforms\Platform\Qemu;O:\ed
> k2-platforms\Silicon\Qemu;O:\edk2-platforms\Features\Intel;O:\edk2-pla
> tforms\Features\Intel\Debugging;O:\edk2-platforms\Features\Intel\Netwo
> rk;O:\edk2-platforms\Features\Intel\OutOfBandManagement;O:\edk2-platfo
> rms\Features\Intel\PowerManagement;O:\edk2-platforms\Features\Intel\Sy
> stemInformation;O:\edk2-platforms\Features\Intel\UserInterface
> +set 
> +packages_path=%workspace%\edk2;%workspace%\edk2-non-osi;%workspace%\e
> +dk2-platforms\Platform\Intel;%workspace%\edk2-platforms\Silicon\Intel
> +;%workspace%\edk2-platforms\Platform\Qemu;%workspace%\edk2-platforms\
> +Silicon\Qemu;%workspace%\edk2-platforms\Features\Intel;%workspace%\ed
> +k2-platforms\Features\Intel\Debugging;%workspace%\edk2-platforms\Feat
> +ures\Intel\Network;%workspace%\edk2-platforms\Features\Intel\OutOfBan
> +dManagement;%workspace%\edk2-platforms\Features\Intel\PowerManagement
> +;%workspace%\edk2-platforms\Features\Intel\SystemInformation;%workspa
> +ce%\edk2-platforms\Features\Intel\UserInterface
>   
> -cd \edk2
> +cd %workspace%\edk2
> +
> +git submodule update --init
>   
>   edksetup.bat Rebuild
>   







-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99836): https://edk2.groups.io/g/devel/message/99836
Mute This Topic: https://groups.io/mt/96368993/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 01/20] MdePkg/Register: Add register definition header files for RISC-V

[Michael D Kinney]

Reviewed-by: Michael D Kinney 


> -Original Message-
> From: Sunil V L 
> Sent: Saturday, January 28, 2023 11:18 AM
> To: devel@edk2.groups.io
> Cc: Daniel Schaefer ; Kinney, Michael D 
> ; Gao, Liming ;
> Liu, Zhiguang ; Abner Chang 
> Subject: [edk2-staging/RiscV64QemuVirt PATCH V7 01/20] MdePkg/Register: Add 
> register definition header files for RISC-V
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> 
> Add register definitions and access routines for RISC-V. These
> headers are leveraged from opensbi repo.
> 
> Cc: Daniel Schaefer 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Signed-off-by: Sunil V L 
> Acked-by: Abner Chang 
> ---
>  MdePkg/Include/Register/RiscV64/RiscVEncoding.h | 119 
>  MdePkg/Include/Register/RiscV64/RiscVImpl.h |  25 
>  2 files changed, 144 insertions(+)
> 
> diff --git a/MdePkg/Include/Register/RiscV64/RiscVEncoding.h 
> b/MdePkg/Include/Register/RiscV64/RiscVEncoding.h
> new file mode 100644
> index ..5c2989b797bf
> --- /dev/null
> +++ b/MdePkg/Include/Register/RiscV64/RiscVEncoding.h
> @@ -0,0 +1,119 @@
> +/** @file
> +  RISC-V CSR encodings
> +
> +  Copyright (c) 2019, Western Digital Corporation or its affiliates. All 
> rights reserved.
> +  Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef RISCV_ENCODING_H_
> +#define RISCV_ENCODING_H_
> +
> +#define MSTATUS_SIE 0x0002UL
> +#define MSTATUS_MIE 0x0008UL
> +#define MSTATUS_SPIE_SHIFT  5
> +#define MSTATUS_SPIE(1UL << MSTATUS_SPIE_SHIFT)
> +#define MSTATUS_UBE 0x0040UL
> +#define MSTATUS_MPIE0x0080UL
> +#define MSTATUS_SPP_SHIFT   8
> +#define MSTATUS_SPP (1UL << MSTATUS_SPP_SHIFT)
> +#define MSTATUS_MPP_SHIFT   11
> +#define MSTATUS_MPP (3UL << MSTATUS_MPP_SHIFT)
> +
> +#define SSTATUS_SIE MSTATUS_SIE
> +#define SSTATUS_SPIE_SHIFT  MSTATUS_SPIE_SHIFT
> +#define SSTATUS_SPIEMSTATUS_SPIE
> +#define SSTATUS_SPP_SHIFT   MSTATUS_SPP_SHIFT
> +#define SSTATUS_SPP MSTATUS_SPP
> +
> +#define IRQ_S_SOFT1
> +#define IRQ_VS_SOFT   2
> +#define IRQ_M_SOFT3
> +#define IRQ_S_TIMER   5
> +#define IRQ_VS_TIMER  6
> +#define IRQ_M_TIMER   7
> +#define IRQ_S_EXT 9
> +#define IRQ_VS_EXT10
> +#define IRQ_M_EXT 11
> +#define IRQ_S_GEXT12
> +#define IRQ_PMU_OVF   13
> +
> +#define MIP_SSIP(1UL << IRQ_S_SOFT)
> +#define MIP_VSSIP   (1UL << IRQ_VS_SOFT)
> +#define MIP_MSIP(1UL << IRQ_M_SOFT)
> +#define MIP_STIP(1UL << IRQ_S_TIMER)
> +#define MIP_VSTIP   (1UL << IRQ_VS_TIMER)
> +#define MIP_MTIP(1UL << IRQ_M_TIMER)
> +#define MIP_SEIP(1UL << IRQ_S_EXT)
> +#define MIP_VSEIP   (1UL << IRQ_VS_EXT)
> +#define MIP_MEIP(1UL << IRQ_M_EXT)
> +#define MIP_SGEIP   (1UL << IRQ_S_GEXT)
> +#define MIP_LCOFIP  (1UL << IRQ_PMU_OVF)
> +
> +#define SIP_SSIP  MIP_SSIP
> +#define SIP_STIP  MIP_STIP
> +
> +#define PRV_U  0UL
> +#define PRV_S  1UL
> +#define PRV_M  3UL
> +
> +#define SATP64_MODE  0xF000ULL
> +#define SATP64_ASID  0x0000ULL
> +#define SATP64_PPN   0x0FFFULL
> +
> +#define SATP_MODE_OFF   0UL
> +#define SATP_MODE_SV32  1UL
> +#define SATP_MODE_SV39  8UL
> +#define SATP_MODE_SV48  9UL
> +#define SATP_MODE_SV57  10UL
> +#define SATP_MODE_SV64  11UL
> +
> +#define SATP_MODE  SATP64_MODE
> +
> +/* User Counters/Timers */
> +#define CSR_CYCLE  0xc00
> +#define CSR_TIME   0xc01
> +
> +/* Supervisor Trap Setup */
> +#define CSR_SSTATUS  0x100
> +#define CSR_SEDELEG  0x102
> +#define CSR_SIDELEG  0x103
> +#define CSR_SIE  0x104
> +#define CSR_STVEC0x105
> +
> +/* Supervisor Configuration */
> +#define CSR_SENVCFG  0x10a
> +
> +/* Supervisor Trap Handling */
> +#define CSR_SSCRATCH  0x140
> +#define CSR_SEPC  0x141
> +#define CSR_SCAUSE0x142
> +#define CSR_STVAL 0x143
> +#define CSR_SIP   0x144
> +
> +/* Supervisor Protection and Translation */
> +#define CSR_SATP  0x180
> +
> +/* Trap/Exception Causes */
> +#define CAUSE_MISALIGNED_FETCH  0x0
> +#define CAUSE_FETCH_ACCESS  0x1
> +#define CAUSE_ILLEGAL_INSTRUCTION   0x2
> +#define CAUSE_BREAKPOINT0x3
> +#define CAUSE_MISALIGNED_LOAD   0x4
> +#define CAUSE_LOAD_ACCESS   0x5
> +#define CAUSE_MISALIGNED_STORE  0x6
> +#define CAUSE_STORE_ACCESS  0x7
> +#define CAUSE_USER_ECALL0x8
> +#define CAUSE_SUPERVISOR_ECALL  0x9
> +#define CAUSE_VIRTUAL_SUPERVISOR_ECALL  0xa
> +#define CAUSE_MACHINE_ECALL 0xb
> +#define CAUSE_FETCH_PAGE_FAULT  0xc
> +#define CAUSE_LOAD_PAGE_FAULT   0xd
> +#define CAUSE_STORE_PAGE_FAULT  0xf
> +#define CAUSE_FETCH_GUEST_PAGE_FAULT0x14
> +#define CAUSE_LOAD_GUEST_PAGE_FAULT 0x15
> +#define CAUSE_VIRTUAL_INST_FAULT0x16
> +#define CAUSE_STORE_GUEST_PAGE_FAULT0x17
> 

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 02/20] MdePkg/BaseLib: RISC-V: Add few more helper functions

[Michael D Kinney]

Hi Sunil,

Just a formatting comment below.

Mike

> -Original Message-
> From: Sunil V L 
> Sent: Saturday, January 28, 2023 11:18 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming 
> ; Liu, Zhiguang ;
> Daniel Schaefer ; Abner Chang 
> Subject: [edk2-staging/RiscV64QemuVirt PATCH V7 02/20] MdePkg/BaseLib: 
> RISC-V: Add few more helper functions
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> 
> Few of the basic helper functions required for any
> RISC-V CPU were added in edk2-platforms. To support
> qemu virt, they need to be added in BaseLib.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Daniel Schaefer 
> Signed-off-by: Sunil V L 
> Acked-by: Abner Chang 
> ---
>  MdePkg/Library/BaseLib/BaseLib.inf  |  3 ++
>  MdePkg/Include/Library/BaseLib.h| 50 ++
>  MdePkg/Library/BaseLib/RiscV64/CpuScratch.S | 31 
>  MdePkg/Library/BaseLib/RiscV64/ReadTimer.S  | 23 +
>  MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S | 53 ++--
>  MdePkg/Library/BaseLib/RiscV64/RiscVMmu.S   | 23 +
>  6 files changed, 179 insertions(+), 4 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
> b/MdePkg/Library/BaseLib/BaseLib.inf
> index 9ed46a584a14..3a48492b1a01 100644
> --- a/MdePkg/Library/BaseLib/BaseLib.inf
> +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> @@ -401,6 +401,9 @@ [Sources.RISCV64]
>RiscV64/RiscVCpuPause.S   | GCC
>RiscV64/RiscVInterrupt.S  | GCC
>RiscV64/FlushCache.S  | GCC
> +  RiscV64/CpuScratch.S  | GCC
> +  RiscV64/ReadTimer.S   | GCC
> +  RiscV64/RiscVMmu.S| GCC
> 
>  [Sources.LOONGARCH64]
>Math64.c
> diff --git a/MdePkg/Include/Library/BaseLib.h 
> b/MdePkg/Include/Library/BaseLib.h
> index f3f59f21c2ea..b4f4e45a1486 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -151,6 +151,56 @@ typedef struct {
> 
>  #define BASE_LIBRARY_JUMP_BUFFER_ALIGNMENT  8
> 
> +VOID
> +  RiscVSetSupervisorScratch (
> + UINT64
> + );
> +
> +UINT64
> +RiscVGetSupervisorScratch (
> +  VOID
> +  );
> +
> +VOID
> +  RiscVSetSupervisorStvec (
> +   UINT64
> +   );
> +
> +UINT64
> +RiscVGetSupervisorStvec (
> +  VOID
> +  );
> +
> +UINT64
> +RiscVGetSupervisorTrapCause (
> +  VOID
> +  );
> +
> +VOID
> +  RiscVSetSupervisorAddressTranslationRegister (
> +UINT64
> +);

Formatting does not look right.

Have you run EDK II uncrustify on this patch series.

> +
> +UINT64
> +RiscVReadTimer (
> +  VOID
> +  );
> +
> +VOID
> +RiscVEnableTimerInterrupt (
> +  VOID
> +  );
> +
> +VOID
> +RiscVDisableTimerInterrupt (
> +  VOID
> +  );
> +
> +VOID
> +RiscVClearPendingTimerInterrupt (
> +  VOID
> +  );
> +
>  #endif // defined (MDE_CPU_RISCV64)
> 
>  #if defined (MDE_CPU_LOONGARCH64)
> diff --git a/MdePkg/Library/BaseLib/RiscV64/CpuScratch.S 
> b/MdePkg/Library/BaseLib/RiscV64/CpuScratch.S
> new file mode 100644
> index ..5492a500eb5e
> --- /dev/null
> +++ b/MdePkg/Library/BaseLib/RiscV64/CpuScratch.S
> @@ -0,0 +1,31 @@
> +//--
> +//
> +// CPU scratch register related functions for RISC-V
> +//
> +// Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +//
> +// SPDX-License-Identifier: BSD-2-Clause-Patent
> +//
> +//--
> +
> +#include 
> +
> +.data
> +.align 3
> +.section .text
> +
> +//
> +// Set Supervisor mode scratch.
> +// @param a0 : Value set to Supervisor mode scratch
> +//
> +ASM_FUNC (RiscVSetSupervisorScratch)
> +csrw CSR_SSCRATCH, a0
> +ret
> +
> +//
> +// Get Supervisor mode scratch.
> +// @retval a0 : Value in Supervisor mode scratch
> +//
> +ASM_FUNC (RiscVGetSupervisorScratch)
> +csrr a0, CSR_SSCRATCH
> +ret
> diff --git a/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S 
> b/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
> new file mode 100644
> index ..39a06efa51ef
> --- /dev/null
> +++ b/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
> @@ -0,0 +1,23 @@
> +//--
> +//
> +// Read CPU timer
> +//
> +// Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +//
> +// SPDX-License-Identifier: BSD-2-Clause-Patent
> +//
> +//--
> +
> +#include 
> +
> +.data
> +.align 3
> +.section .text
> +
> +//
> +// Read TIME CSR.
> +// @retval a0 : 64-bit timer.
> +//
> +ASM_FUNC (RiscVReadTimer)
> +csrr a0, CSR_TIME
> +ret
> diff --git 

Re: [edk2-devel] [edk2-platforms: PATCH v4] IntelSiliconPkg/SpiFvbServiceSmm: Rewrite VariableStore header.

[Isaac Oram]

Reviewed-by: Isaac Oram 

At some point, we should work to comment the related flows better so that code 
is clear on the different responsibilities for the different paths through 
first boots, normal scenarios, reclaims, and error remediation.  For now 
though, this is fine.

Regards,
Isaac

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Wednesday, February 8, 2023 4:41 PM
To: devel@edk2.groups.io; Chiu, Chasel 
Cc: S, Ashraf Ali ; Oram, Isaac W 
; Chaganty, Rangasai V ; 
Ni, Ray ; Kubacki, Michael 
Subject: Re: [edk2-devel] [edk2-platforms: PATCH v4] 
IntelSiliconPkg/SpiFvbServiceSmm: Rewrite VariableStore header.

Reviewed-by: Michael Kubacki 

On the following lines, I recommend moving the assignment until after the if 
block. It seems unnecessary to assign a potentially invalid value to a local 
variable before checking the validation result.

   Status = SafeUint64ToUint32 (BaseAddress, [0].FvBase);
   NvStorageBaseAddress = mPlatformFvBaseAddress[0].FvBase;
   if (EFI_ERROR (Status)) {
 ASSERT_EFI_ERROR (Status);
 DEBUG ((DEBUG_ERROR, "[%a] - 64-bit variable storage base address not 
supported.\n", __FUNCTION__));
 return;
   }

---

(similar for NvStorageFvSize)

Thanks,
Michael

On 2/8/2023 5:17 PM, Chiu, Chasel wrote:
> When invalid VariableStore FV header detected, current SpiFvbService 
> will erase both FV and VariableStore headers from flash, however, it 
> will only rewrite FV header back and cause invalid VariableStore 
> header.
> 
> This patch adding the support for rewriting both FV header and 
> VariableStore header when VariableStore corruption happened.
> The Corrupted variable content should be taken care by 
> FaultTolerantWrite driver later.
> 
> Platform has to set PcdFlashVariableStoreType to inform SpiFvbService 
> which VariableStoreType should be rewritten.
> 
> Cc: Ashraf Ali S 
> Cc: Isaac Oram 
> Cc: Rangasai V Chaganty 
> Cc: Ray Ni 
> Cc: Michael Kubacki 
> Signed-off-by: Chasel Chiu 
> ---
>   Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c 
>| 69 -
>   
> Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceSmm.inf
>  |  3 +++
>   Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec   
>|  8 
>   3 files changed, 75 insertions(+), 5 deletions(-)
> 
> diff --git 
> a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServ
> iceMm.c 
> b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServ
> iceMm.c
> index 6b4bcdcfe3..052be97872 100644
> --- 
> a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServ
> iceMm.c
> +++ b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvb
> +++ ServiceMm.c
> @@ -12,6 +12,7 @@
>   #include 
> 
>   #include 
> 
>   #include 
> 
> +#include 
> 
>   
> 
>   /**
> 
> The function installs EFI_FIRMWARE_VOLUME_BLOCK protocol
> 
> @@ -113,7 +114,12 @@ FvbInitialize (
> UINT32MaxLbaSize;
> 
> UINT32BytesWritten;
> 
> UINTN BytesErased;
> 
> +  EFI_PHYSICAL_ADDRESS  NvStorageBaseAddress;
> 
> UINT64NvStorageFvSize;
> 
> +  UINT32ExpectedBytesWritten;
> 
> +  VARIABLE_STORE_HEADER *VariableStoreHeader;
> 
> +  UINT8 VariableStoreType;
> 
> +  UINT8 *NvStoreBuffer;
> 
>   
> 
> Status = GetVariableFlashNvStorageInfo (, 
> );
> 
> if (EFI_ERROR (Status)) {
> 
> @@ -124,12 +130,14 @@ FvbInitialize (
>   
> 
> // Stay within the current UINT32 size assumptions in the variable stack.
> 
> Status = SafeUint64ToUint32 (BaseAddress, 
> [0].FvBase);
> 
> +  NvStorageBaseAddress = mPlatformFvBaseAddress[0].FvBase;
> 
> if (EFI_ERROR (Status)) {
> 
>   ASSERT_EFI_ERROR (Status);
> 
>   DEBUG ((DEBUG_ERROR, "[%a] - 64-bit variable storage base 
> address not supported.\n", __FUNCTION__));
> 
>   return;
> 
> }
> 
> Status = SafeUint64ToUint32 (NvStorageFvSize, 
> [0].FvSize);
> 
> +  NvStorageFvSize = mPlatformFvBaseAddress[0].FvSize;
> 
> if (EFI_ERROR (Status)) {
> 
>   ASSERT_EFI_ERROR (Status);
> 
>   DEBUG ((DEBUG_ERROR, "[%a] - 64-bit variable storage size not 
> supported.\n", __FUNCTION__));
> 
> @@ -186,8 +194,59 @@ FvbInitialize (
> }
> 
> continue;
> 
>   }
> 
> -BytesWritten = FvHeader->HeaderLength;
> 
> -Status = SpiFlashWrite ((UINTN)BaseAddress, , 
> (UINT8*)FvHeader);
> 
> +
> 
> +BytesWritten = FvHeader->HeaderLength;
> 
> +ExpectedBytesWritten = BytesWritten;
> 
> +if (BaseAddress != NvStorageBaseAddress) {
> 
> +  Status = SpiFlashWrite ((UINTN)BaseAddress, , 
> + (UINT8 

Re: [edk2-devel] [edk2-platforms: PATCH v4] IntelSiliconPkg/SpiFvbServiceSmm: Rewrite VariableStore header.

[Chiu, Chasel]

Thanks Michael! I will apply the change during merging!


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael
> Kubacki
> Sent: Wednesday, February 8, 2023 4:41 PM
> To: devel@edk2.groups.io; Chiu, Chasel 
> Cc: S, Ashraf Ali ; Oram, Isaac W
> ; Chaganty, Rangasai V
> ; Ni, Ray ; Kubacki,
> Michael 
> Subject: Re: [edk2-devel] [edk2-platforms: PATCH v4]
> IntelSiliconPkg/SpiFvbServiceSmm: Rewrite VariableStore header.
> 
> Reviewed-by: Michael Kubacki 
> 
> On the following lines, I recommend moving the assignment until after the if
> block. It seems unnecessary to assign a potentially invalid value to a local
> variable before checking the validation result.
> 
>Status = SafeUint64ToUint32 (BaseAddress,
> [0].FvBase);
>NvStorageBaseAddress = mPlatformFvBaseAddress[0].FvBase;
>if (EFI_ERROR (Status)) {
>  ASSERT_EFI_ERROR (Status);
>  DEBUG ((DEBUG_ERROR, "[%a] - 64-bit variable storage base address not
> supported.\n", __FUNCTION__));
>  return;
>}
> 
> ---
> 
> (similar for NvStorageFvSize)
> 
> Thanks,
> Michael
> 
> On 2/8/2023 5:17 PM, Chiu, Chasel wrote:
> > When invalid VariableStore FV header detected, current SpiFvbService
> > will erase both FV and VariableStore headers from flash, however, it
> > will only rewrite FV header back and cause invalid VariableStore
> > header.
> >
> > This patch adding the support for rewriting both FV header and
> > VariableStore header when VariableStore corruption happened.
> > The Corrupted variable content should be taken care by
> > FaultTolerantWrite driver later.
> >
> > Platform has to set PcdFlashVariableStoreType to inform SpiFvbService
> > which VariableStoreType should be rewritten.
> >
> > Cc: Ashraf Ali S 
> > Cc: Isaac Oram 
> > Cc: Rangasai V Chaganty 
> > Cc: Ray Ni 
> > Cc: Michael Kubacki 
> > Signed-off-by: Chasel Chiu 
> > ---
> >   
> > Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c
> | 69
> --
> ---
> >
> Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceSmm.inf
> |  3 +++
> >   Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec 
> >  |  8 
> >   3 files changed, 75 insertions(+), 5 deletions(-)
> >
> > diff --git
> > a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServ
> > iceMm.c
> > b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServ
> > iceMm.c
> > index 6b4bcdcfe3..052be97872 100644
> > ---
> > a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServ
> > iceMm.c
> > +++ b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvb
> > +++ ServiceMm.c
> > @@ -12,6 +12,7 @@
> >   #include 
> >
> >   #include 
> >
> >   #include 
> >
> > +#include 
> >
> >
> >
> >   /**
> >
> > The function installs EFI_FIRMWARE_VOLUME_BLOCK protocol
> >
> > @@ -113,7 +114,12 @@ FvbInitialize (
> > UINT32MaxLbaSize;
> >
> > UINT32BytesWritten;
> >
> > UINTN BytesErased;
> >
> > +  EFI_PHYSICAL_ADDRESS  NvStorageBaseAddress;
> >
> > UINT64NvStorageFvSize;
> >
> > +  UINT32ExpectedBytesWritten;
> >
> > +  VARIABLE_STORE_HEADER *VariableStoreHeader;
> >
> > +  UINT8 VariableStoreType;
> >
> > +  UINT8 *NvStoreBuffer;
> >
> >
> >
> > Status = GetVariableFlashNvStorageInfo (,
> > );
> >
> > if (EFI_ERROR (Status)) {
> >
> > @@ -124,12 +130,14 @@ FvbInitialize (
> >
> >
> > // Stay within the current UINT32 size assumptions in the variable 
> > stack.
> >
> > Status = SafeUint64ToUint32 (BaseAddress,
> > [0].FvBase);
> >
> > +  NvStorageBaseAddress = mPlatformFvBaseAddress[0].FvBase;
> >
> > if (EFI_ERROR (Status)) {
> >
> >   ASSERT_EFI_ERROR (Status);
> >
> >   DEBUG ((DEBUG_ERROR, "[%a] - 64-bit variable storage base
> > address not supported.\n", __FUNCTION__));
> >
> >   return;
> >
> > }
> >
> > Status = SafeUint64ToUint32 (NvStorageFvSize,
> > [0].FvSize);
> >
> > +  NvStorageFvSize = mPlatformFvBaseAddress[0].FvSize;
> >
> > if (EFI_ERROR (Status)) {
> >
> >   ASSERT_EFI_ERROR (Status);
> >
> >   DEBUG ((DEBUG_ERROR, "[%a] - 64-bit variable storage size not
> > supported.\n", __FUNCTION__));
> >
> > @@ -186,8 +194,59 @@ FvbInitialize (
> > }
> >
> > continue;
> >
> >   }
> >
> > -BytesWritten = FvHeader->HeaderLength;
> >
> > -Status = SpiFlashWrite ((UINTN)BaseAddress, ,
> (UINT8*)FvHeader);
> >
> > +
> >
> > +BytesWritten = FvHeader->HeaderLength;
> >
> > +ExpectedBytesWritten = BytesWritten;
> >
> > +if (BaseAddress != NvStorageBaseAddress) {
> >
> > +  Status = SpiFlashWrite 

Re: [edk2-devel] [Patch 1/1] EmulatorPkg/PeiTimerLib: Bug fix in NanoSecondDelay

[Michael D Kinney]

Thank you Liming.  Ray has completed the review and I have pushed the PR branch
with the Rb.  I will add push label after CI passes.

Mike





> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of gaoliming via 
> groups.io
> Sent: Wednesday, February 8, 2023 5:07 PM
> To: Kinney, Michael D ; devel@edk2.groups.io
> Cc: Cole, Deric ; 'Andrew Fish' ; Ni, 
> Ray 
> Subject: 回复: [edk2-devel] [Patch 1/1] EmulatorPkg/PeiTimerLib: Bug fix in 
> NanoSecondDelay
> 
> Mike:
>   This fix is OK to me. I am OK to merge it for this stable tag.
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: Kinney, Michael D 
> > 发送时间: 2023年2月9日 7:17
> > 收件人: devel@edk2.groups.io; Kinney, Michael D
> > ; Gao, Liming 
> > 抄送: Cole, Deric ; Andrew Fish ;
> > Ni, Ray ; Kinney, Michael D 
> > 主题: RE: [edk2-devel] [Patch 1/1] EmulatorPkg/PeiTimerLib: Bug fix in
> > NanoSecondDelay
> >
> > Hi Liming,
> >
> > This is a significant behavior bug in EmulatorPkg PeiTimerLib that was
> > discovered during the soft freeze evaluation period.
> >
> > I would like to request this patch be included in the edk2-stable202302
> > release.
> >
> > Thanks,
> >
> > Mike
> >
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of Michael
> > D Kinney
> > > Sent: Wednesday, February 8, 2023 3:10 PM
> > > To: devel@edk2.groups.io
> > > Cc: Cole, Deric ; Andrew Fish ;
> > Ni, Ray 
> > > Subject: [edk2-devel] [Patch 1/1] EmulatorPkg/PeiTimerLib: Bug fix in
> > NanoSecondDelay
> > >
> > > From: Deric Cole 
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4339
> > >
> > > Thunk->Sleep is expecting nanoseconds, no need to multiply by 100.
> > >
> > > Cc: Andrew Fish 
> > > Cc: Ray Ni 
> > > Signed-off-by: Deric Cole 
> > > Reviewed-by: Michael D Kinney 
> > > ---
> > >  EmulatorPkg/Include/Protocol/EmuThunk.h   | 2 +-
> > >  EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c | 4 ++--
> > >  2 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/EmulatorPkg/Include/Protocol/EmuThunk.h
> > b/EmulatorPkg/Include/Protocol/EmuThunk.h
> > > index b720023ac9c7..c419d0a67790 100644
> > > --- a/EmulatorPkg/Include/Protocol/EmuThunk.h
> > > +++ b/EmulatorPkg/Include/Protocol/EmuThunk.h
> > > @@ -130,7 +130,7 @@ UINT64
> > >  typedef
> > >  VOID
> > >  (EFIAPI *EMU_SLEEP)(
> > > -  IN  UINT64Milliseconds
> > > +  IN  UINT64Nanoseconds
> > >);
> > >
> > >  typedef
> > > diff --git a/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> > b/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> > > index 8c4f20f42b47..5344719f98d8 100644
> > > --- a/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> > > +++ b/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> > > @@ -1,7 +1,7 @@
> > >  /** @file
> > >A non-functional instance of the Timer Library.
> > >
> > > -  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
> > > +  Copyright (c) 2007 - 2023, Intel Corporation. All rights reserved.
> > >SPDX-License-Identifier: BSD-2-Clause-Patent
> > >
> > >  **/
> > > @@ -65,7 +65,7 @@ NanoSecondDelay (
> > >   );
> > >if (!EFI_ERROR (Status)) {
> > >  Thunk = (EMU_THUNK_PROTOCOL *)ThunkPpi->Thunk ();
> > > -Thunk->Sleep (NanoSeconds * 100);
> > > +Thunk->Sleep (NanoSeconds);
> > >  return NanoSeconds;
> > >}
> > >
> > > --
> > > 2.37.1.windows.1
> > >
> > >
> > >
> > >
> > >
> 
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99831): https://edk2.groups.io/g/devel/message/99831
Mute This Topic: https://groups.io/mt/96844651/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

回复: [edk2-devel] [Patch 1/1] EmulatorPkg/PeiTimerLib: Bug fix in NanoSecondDelay

[gaoliming via groups.io]

Mike:
  This fix is OK to me. I am OK to merge it for this stable tag. 

Thanks
Liming
> -邮件原件-
> 发件人: Kinney, Michael D 
> 发送时间: 2023年2月9日 7:17
> 收件人: devel@edk2.groups.io; Kinney, Michael D
> ; Gao, Liming 
> 抄送: Cole, Deric ; Andrew Fish ;
> Ni, Ray ; Kinney, Michael D 
> 主题: RE: [edk2-devel] [Patch 1/1] EmulatorPkg/PeiTimerLib: Bug fix in
> NanoSecondDelay
> 
> Hi Liming,
> 
> This is a significant behavior bug in EmulatorPkg PeiTimerLib that was
> discovered during the soft freeze evaluation period.
> 
> I would like to request this patch be included in the edk2-stable202302
> release.
> 
> Thanks,
> 
> Mike
> 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Michael
> D Kinney
> > Sent: Wednesday, February 8, 2023 3:10 PM
> > To: devel@edk2.groups.io
> > Cc: Cole, Deric ; Andrew Fish ;
> Ni, Ray 
> > Subject: [edk2-devel] [Patch 1/1] EmulatorPkg/PeiTimerLib: Bug fix in
> NanoSecondDelay
> >
> > From: Deric Cole 
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4339
> >
> > Thunk->Sleep is expecting nanoseconds, no need to multiply by 100.
> >
> > Cc: Andrew Fish 
> > Cc: Ray Ni 
> > Signed-off-by: Deric Cole 
> > Reviewed-by: Michael D Kinney 
> > ---
> >  EmulatorPkg/Include/Protocol/EmuThunk.h   | 2 +-
> >  EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c | 4 ++--
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/EmulatorPkg/Include/Protocol/EmuThunk.h
> b/EmulatorPkg/Include/Protocol/EmuThunk.h
> > index b720023ac9c7..c419d0a67790 100644
> > --- a/EmulatorPkg/Include/Protocol/EmuThunk.h
> > +++ b/EmulatorPkg/Include/Protocol/EmuThunk.h
> > @@ -130,7 +130,7 @@ UINT64
> >  typedef
> >  VOID
> >  (EFIAPI *EMU_SLEEP)(
> > -  IN  UINT64Milliseconds
> > +  IN  UINT64Nanoseconds
> >);
> >
> >  typedef
> > diff --git a/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> b/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> > index 8c4f20f42b47..5344719f98d8 100644
> > --- a/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> > +++ b/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> > @@ -1,7 +1,7 @@
> >  /** @file
> >A non-functional instance of the Timer Library.
> >
> > -  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
> > +  Copyright (c) 2007 - 2023, Intel Corporation. All rights reserved.
> >SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> > @@ -65,7 +65,7 @@ NanoSecondDelay (
> >   );
> >if (!EFI_ERROR (Status)) {
> >  Thunk = (EMU_THUNK_PROTOCOL *)ThunkPpi->Thunk ();
> > -Thunk->Sleep (NanoSeconds * 100);
> > +Thunk->Sleep (NanoSeconds);
> >  return NanoSeconds;
> >}
> >
> > --
> > 2.37.1.windows.1
> >
> >
> >
> > 
> >





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99830): https://edk2.groups.io/g/devel/message/99830
Mute This Topic: https://groups.io/mt/96844383/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch 1/1] EmulatorPkg/PeiTimerLib: Bug fix in NanoSecondDelay

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: Kinney, Michael D 
> Sent: Thursday, February 9, 2023 7:17 AM
> To: devel@edk2.groups.io; Kinney, Michael D ;
> Gao, Liming 
> Cc: Cole, Deric ; Andrew Fish ; Ni,
> Ray ; Kinney, Michael D 
> Subject: RE: [edk2-devel] [Patch 1/1] EmulatorPkg/PeiTimerLib: Bug fix in
> NanoSecondDelay
> 
> Hi Liming,
> 
> This is a significant behavior bug in EmulatorPkg PeiTimerLib that was
> discovered during the soft freeze evaluation period.
> 
> I would like to request this patch be included in the edk2-stable202302 
> release.
> 
> Thanks,
> 
> Mike
> 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Michael D
> Kinney
> > Sent: Wednesday, February 8, 2023 3:10 PM
> > To: devel@edk2.groups.io
> > Cc: Cole, Deric ; Andrew Fish ; Ni,
> Ray 
> > Subject: [edk2-devel] [Patch 1/1] EmulatorPkg/PeiTimerLib: Bug fix in
> NanoSecondDelay
> >
> > From: Deric Cole 
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4339
> >
> > Thunk->Sleep is expecting nanoseconds, no need to multiply by 100.
> >
> > Cc: Andrew Fish 
> > Cc: Ray Ni 
> > Signed-off-by: Deric Cole 
> > Reviewed-by: Michael D Kinney 
> > ---
> >  EmulatorPkg/Include/Protocol/EmuThunk.h   | 2 +-
> >  EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c | 4 ++--
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/EmulatorPkg/Include/Protocol/EmuThunk.h
> b/EmulatorPkg/Include/Protocol/EmuThunk.h
> > index b720023ac9c7..c419d0a67790 100644
> > --- a/EmulatorPkg/Include/Protocol/EmuThunk.h
> > +++ b/EmulatorPkg/Include/Protocol/EmuThunk.h
> > @@ -130,7 +130,7 @@ UINT64
> >  typedef
> >  VOID
> >  (EFIAPI *EMU_SLEEP)(
> > -  IN  UINT64Milliseconds
> > +  IN  UINT64Nanoseconds
> >);
> >
> >  typedef
> > diff --git a/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> b/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> > index 8c4f20f42b47..5344719f98d8 100644
> > --- a/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> > +++ b/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> > @@ -1,7 +1,7 @@
> >  /** @file
> >A non-functional instance of the Timer Library.
> >
> > -  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
> > +  Copyright (c) 2007 - 2023, Intel Corporation. All rights reserved.
> >SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> > @@ -65,7 +65,7 @@ NanoSecondDelay (
> >   );
> >if (!EFI_ERROR (Status)) {
> >  Thunk = (EMU_THUNK_PROTOCOL *)ThunkPpi->Thunk ();
> > -Thunk->Sleep (NanoSeconds * 100);
> > +Thunk->Sleep (NanoSeconds);
> >  return NanoSeconds;
> >}
> >
> > --
> > 2.37.1.windows.1
> >
> >
> >
> > 
> >



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99829): https://edk2.groups.io/g/devel/message/99829
Mute This Topic: https://groups.io/mt/96842440/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v4] IntelSiliconPkg/SpiFvbServiceSmm: Rewrite VariableStore header.

[Michael Kubacki]

Reviewed-by: Michael Kubacki 

On the following lines, I recommend moving the assignment until after 
the if block. It seems unnecessary to assign a potentially invalid value 
to a local variable before checking the validation result.


  Status = SafeUint64ToUint32 (BaseAddress, 
[0].FvBase);

  NvStorageBaseAddress = mPlatformFvBaseAddress[0].FvBase;
  if (EFI_ERROR (Status)) {
ASSERT_EFI_ERROR (Status);
DEBUG ((DEBUG_ERROR, "[%a] - 64-bit variable storage base address 
not supported.\n", __FUNCTION__));

return;
  }

---

(similar for NvStorageFvSize)

Thanks,
Michael

On 2/8/2023 5:17 PM, Chiu, Chasel wrote:

When invalid VariableStore FV header detected, current SpiFvbService
will erase both FV and VariableStore headers from flash, however,
it will only rewrite FV header back and cause invalid VariableStore
header.

This patch adding the support for rewriting both FV header and
VariableStore header when VariableStore corruption happened.
The Corrupted variable content should be taken care by
FaultTolerantWrite driver later.

Platform has to set PcdFlashVariableStoreType to inform SpiFvbService
which VariableStoreType should be rewritten.

Cc: Ashraf Ali S 
Cc: Isaac Oram 
Cc: Rangasai V Chaganty 
Cc: Ray Ni 
Cc: Michael Kubacki 
Signed-off-by: Chasel Chiu 
---
  Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c   
 | 69 -
  
Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceSmm.inf 
|  3 +++
  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec 
 |  8 
  3 files changed, 75 insertions(+), 5 deletions(-)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c 
b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c
index 6b4bcdcfe3..052be97872 100644
--- 
a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c
+++ 
b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c
@@ -12,6 +12,7 @@
  #include 

  #include 

  #include 

+#include 

  


  /**

The function installs EFI_FIRMWARE_VOLUME_BLOCK protocol

@@ -113,7 +114,12 @@ FvbInitialize (
UINT32MaxLbaSize;

UINT32BytesWritten;

UINTN BytesErased;

+  EFI_PHYSICAL_ADDRESS  NvStorageBaseAddress;

UINT64NvStorageFvSize;

+  UINT32ExpectedBytesWritten;

+  VARIABLE_STORE_HEADER *VariableStoreHeader;

+  UINT8 VariableStoreType;

+  UINT8 *NvStoreBuffer;

  


Status = GetVariableFlashNvStorageInfo (, );

if (EFI_ERROR (Status)) {

@@ -124,12 +130,14 @@ FvbInitialize (
  


// Stay within the current UINT32 size assumptions in the variable stack.

Status = SafeUint64ToUint32 (BaseAddress, 
[0].FvBase);

+  NvStorageBaseAddress = mPlatformFvBaseAddress[0].FvBase;

if (EFI_ERROR (Status)) {

  ASSERT_EFI_ERROR (Status);

  DEBUG ((DEBUG_ERROR, "[%a] - 64-bit variable storage base address not 
supported.\n", __FUNCTION__));

  return;

}

Status = SafeUint64ToUint32 (NvStorageFvSize, 
[0].FvSize);

+  NvStorageFvSize = mPlatformFvBaseAddress[0].FvSize;

if (EFI_ERROR (Status)) {

  ASSERT_EFI_ERROR (Status);

  DEBUG ((DEBUG_ERROR, "[%a] - 64-bit variable storage size not 
supported.\n", __FUNCTION__));

@@ -186,8 +194,59 @@ FvbInitialize (
}

continue;

  }

-BytesWritten = FvHeader->HeaderLength;

-Status = SpiFlashWrite ((UINTN)BaseAddress, , 
(UINT8*)FvHeader);

+

+BytesWritten = FvHeader->HeaderLength;

+ExpectedBytesWritten = BytesWritten;

+if (BaseAddress != NvStorageBaseAddress) {

+  Status = SpiFlashWrite ((UINTN)BaseAddress, , (UINT8 
*)FvHeader);

+} else {

+  //

+  // This is Variable Store, rewrite both EFI_FIRMWARE_VOLUME_HEADER 
and VARIABLE_STORE_HEADER.

+  // The corrupted Variable content should be taken care by 
FaultTolerantWrite driver later.

+  //

+  NvStoreBuffer = NULL;

+  NvStoreBuffer = AllocateZeroPool (sizeof (VARIABLE_STORE_HEADER) + 
FvHeader->HeaderLength);

+  if (NvStoreBuffer != NULL) {

+//

+// Combine FV header and VariableStore header into the buffer.

+//

+CopyMem (NvStoreBuffer, FvHeader, FvHeader->HeaderLength);

+VariableStoreHeader = (VARIABLE_STORE_HEADER *)(NvStoreBuffer + 
FvHeader->HeaderLength);

+VariableStoreType   = PcdGet8 (PcdFlashVariableStoreType);

+switch (VariableStoreType) {

+  case 0:

+DEBUG ((DEBUG_ERROR, "Type: gEfiVariableGuid\n"));

+ 

Re: [edk2-devel] [PATCH V2 RESEND] RedfishPkg: RedfishRestExDxe: Two PCDs for controlling the requests

[Igor Kulchytskyy via groups.io]

Hi Abner,
Thank you for your comments.
See my comments on your comments below.
Igor

-Original Message-
From: Chang, Abner 
Sent: Wednesday, February 8, 2023 4:13 PM
To: Igor Kulchytskyy ; devel@edk2.groups.io
Cc: Nickle Wang 
Subject: [EXTERNAL] RE: [PATCH V2 RESEND] RedfishPkg: RedfishRestExDxe: Two 
PCDs for controlling the requests


**CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.**

[AMD Official Use Only - General]

Hi Igor,
Few comments in below.

> -Original Message-
> From: Igor Kulchytskyy 
> Sent: Thursday, February 9, 2023 1:23 AM
> To: devel@edk2.groups.io
> Cc: Igor Kulchytskyy ; Chang, Abner
> ; Nickle Wang 
> Subject: [PATCH V2 RESEND] RedfishPkg: RedfishRestExDxe: Two PCDs for
> controlling the requests
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> Since BIOS should work with different BMC implementation chunked
> requests as well as Expect header should be optional.
> One PCD is used to enable/disable Expect header.
> Another PCD is used to enable/disable chunked requests.
>
> Cc: Abner Chang 
> Cc: Nickle Wang 
> Signed-off-by: Igor Kulchytskyy 
> ---
>  RedfishPkg/RedfishPkg.dec   |  10 ++
>  RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf|   2 +
>  RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c |  23 ++--
>  RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c | 140
> 
> 
>  4 files changed, 113 insertions(+), 62 deletions(-)
>
> diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
> index d2b189b..89ef32a 100644
> --- a/RedfishPkg/RedfishPkg.dec
> +++ b/RedfishPkg/RedfishPkg.dec
> @@ -97,3 +97,13 @@
># protocol instance.
>#
>
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDiscoverAccessModeInBand|FALSE|
> BOOLEAN|0x1002
> +  #
> +  # This PCD indicates if the EFI REST EX sends chunk request to Redfish 
> service.
> +  # Default is set to non chunk mode.
> +  #
> +
> +
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExChunkRequestMode|TRUE|BO
> O
> + LEAN|0x1003
We can default set PcdRedfishRestExChunkRequestMode to FALSE.
Igor: Agree. Just forgot to make it FALSE after I tested BIOS with Expect PCD 
disabled and Chunked PCD enabled.

> +  #
> +  # This PCD indicates if the EFI REST EX adds Expect header to the
> + POST, PATCH,
> PUT requests to Redfish service.
> +  # Default is set to not add.
> +  #
> +
> +
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExAddingExpect|FALSE|BOOLEA
> + N|0x1004
> diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
> b/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
> index 75437b0..29003ae 100644
> --- a/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
> +++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
> @@ -57,6 +57,8 @@
>
>  [Pcd]
>
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExServiceAccessModeInBand
> ## CONSUMES
> +  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExChunkRequestMode   ##
> CONSUMES
> +  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExAddingExpect   ##
> CONSUMES
>
>  [UserExtensions.TianoCore."ExtraFiles"]
>RedfishRestExDxeExtra.uni
> diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
> b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
> index 952e9d1..0da0d10 100644
> --- a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
> +++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
> @@ -140,9 +140,6 @@ RedfishHttpAddExpectation (
>}
>
>*ItsWrite = FALSE;
> -  if (PreservedRequestHeaders != NULL) {
> -*PreservedRequestHeaders = RequestMessage->Headers;
> -  }
>
>if ((RequestMessage->Data.Request->Method != HttpMethodPut) &&
> (RequestMessage->Data.Request->Method != HttpMethodPost) &&
>(RequestMessage->Data.Request->Method != HttpMethodPatch)) @@ -
> 152,10 +149,20 @@ RedfishHttpAddExpectation (
>
>*ItsWrite = TRUE;
>
> -  NewHeaders = AllocateZeroPool ((RequestMessage->HeaderCount + 1) *
> sizeof (EFI_HTTP_HEADER));
> -  CopyMem ((VOID *)NewHeaders, (VOID *)RequestMessage->Headers,
> RequestMessage->HeaderCount * sizeof (EFI_HTTP_HEADER));
> -  HttpSetFieldNameAndValue (NewHeaders + RequestMessage->HeaderCount,
> HTTP_HEADER_EXPECT, HTTP_EXPECT_100_CONTINUE);
> -  RequestMessage->HeaderCount++;
> -  RequestMessage->Headers = NewHeaders;
> +  //
> +  // Check PCD before adding Expect header  //
> +  if(FixedPcdGetBool(PcdRedfishRestExAddingExpect)) {
> +if (PreservedRequestHeaders != NULL) {
> +  *PreservedRequestHeaders = RequestMessage->Headers;
> +}
> +
> +NewHeaders = AllocateZeroPool ((RequestMessage->HeaderCount + 1)
> + *
> sizeof (EFI_HTTP_HEADER));
> +CopyMem ((VOID *)NewHeaders, (VOID *)RequestMessage->Headers,
> RequestMessage->HeaderCount * sizeof (EFI_HTTP_HEADER));
> +HttpSetFieldNameAndValue (NewHeaders +
> + RequestMessage->HeaderCount,
> 

Re: [edk2-devel] [Patch 1/1] EmulatorPkg/PeiTimerLib: Bug fix in NanoSecondDelay

[Michael D Kinney]

Hi Liming,

This is a significant behavior bug in EmulatorPkg PeiTimerLib that was
discovered during the soft freeze evaluation period.

I would like to request this patch be included in the edk2-stable202302 release.

Thanks,

Mike


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael D 
> Kinney
> Sent: Wednesday, February 8, 2023 3:10 PM
> To: devel@edk2.groups.io
> Cc: Cole, Deric ; Andrew Fish ; Ni, 
> Ray 
> Subject: [edk2-devel] [Patch 1/1] EmulatorPkg/PeiTimerLib: Bug fix in 
> NanoSecondDelay
> 
> From: Deric Cole 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4339
> 
> Thunk->Sleep is expecting nanoseconds, no need to multiply by 100.
> 
> Cc: Andrew Fish 
> Cc: Ray Ni 
> Signed-off-by: Deric Cole 
> Reviewed-by: Michael D Kinney 
> ---
>  EmulatorPkg/Include/Protocol/EmuThunk.h   | 2 +-
>  EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/EmulatorPkg/Include/Protocol/EmuThunk.h 
> b/EmulatorPkg/Include/Protocol/EmuThunk.h
> index b720023ac9c7..c419d0a67790 100644
> --- a/EmulatorPkg/Include/Protocol/EmuThunk.h
> +++ b/EmulatorPkg/Include/Protocol/EmuThunk.h
> @@ -130,7 +130,7 @@ UINT64
>  typedef
>  VOID
>  (EFIAPI *EMU_SLEEP)(
> -  IN  UINT64Milliseconds
> +  IN  UINT64Nanoseconds
>);
> 
>  typedef
> diff --git a/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c 
> b/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> index 8c4f20f42b47..5344719f98d8 100644
> --- a/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> +++ b/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
> @@ -1,7 +1,7 @@
>  /** @file
>A non-functional instance of the Timer Library.
> 
> -  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
> +  Copyright (c) 2007 - 2023, Intel Corporation. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -65,7 +65,7 @@ NanoSecondDelay (
>   );
>if (!EFI_ERROR (Status)) {
>  Thunk = (EMU_THUNK_PROTOCOL *)ThunkPpi->Thunk ();
> -Thunk->Sleep (NanoSeconds * 100);
> +Thunk->Sleep (NanoSeconds);
>  return NanoSeconds;
>}
> 
> --
> 2.37.1.windows.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99825): https://edk2.groups.io/g/devel/message/99825
Mute This Topic: https://groups.io/mt/96842440/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] Platform/Qemu/Sbsa: Update TF-A binaries to enable SVE/SME

[Marcin Juszkiewicz via groups.io]

From: Marcin Juszkiewicz 

Update the TF-A binaries with SVE/SME enablement.

This support was merged into TF-A:

https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17825

This allows to test SBSA Reference Platform to boot Linux 6.x kernels
with "max" cpu.

Signed-off-by: Marcin Juszkiewicz 
---
 Platform/Qemu/Sbsa/Readme.md |  85 +++
 Platform/Qemu/Sbsa/bl1.bin   | Bin 19301 -> 19493 bytes
 Platform/Qemu/Sbsa/fip.bin   | Bin 54002 -> 58098 bytes
 3 files changed, 56 insertions(+), 29 deletions(-)

diff --git a/Platform/Qemu/Sbsa/Readme.md b/Platform/Qemu/Sbsa/Readme.md
index 3b36cfb..c7ced43 100644
--- a/Platform/Qemu/Sbsa/Readme.md
+++ b/Platform/Qemu/Sbsa/Readme.md
@@ -1,29 +1,56 @@
-Qemu SBSA TF-A binaries



-

-These binaries have been created from the mainline TF-A

-code checked out at the following commit ID:

-

-commit 99c447f4406c8ae66b6cab2341ef0c8e8d9751d2

-Merge: 331723509 8e570b71d

-Author: André Przywara 

-Date:   Tue Jul 7 22:06:31 2020 +

-

-Merge "drivers: arm: gicv3: auto-detect presence of GIC600-AE" into 
integration

-

-

-This ensures that the following fix for qemu_sbsa platform is

-merged upstream and is included in the build:

-

-commit d7f5be8ec2fc5254fc581af52156b5fde5deb822

-Author: Masahisa Kojima 

-Date:   Tue May 19 19:49:36 2020 +0900

-

-qemu/qemu_sbsa: increase size to handle fdt

-

-

-NOTE: No modifications to the source code have been done.

-  The binaries have been generated for the AARCH64 platform

-  with the following command:

-

-   make PLAT=qemu_sbsa all fip

+Qemu SBSA TF-A binaries
+---
+
+These binaries have been created from the mainline TF-A
+code checked out at the following commit ID:
+
+commit 6264643a0711faef346cbbb6e3d928a198aeaf31
+Merge: d9248e851 cb3e9650f
+Author: Manish V Badarkhe 
+Date:   Fri Feb 3 17:04:42 2023 +0100
+
+Merge "refactor(tc): update total compute gpu device node" into integration
+
+
+This ensures that the following fix for qemu_sbsa platform is
+merged upstream and is included in the build:
+
+commit 9bff7ce37545162d417953ac36c6878216815b94
+Author: Marcin Juszkiewicz 
+Date:   Wed Nov 16 14:47:51 2022 +0100
+
+fix(qemu-sbsa): enable SVE and SME
+
+Commit 337ff4f1dd6604738d79fd3fa275ae74d74256b2 enabled SVE/SME for
+qemu platform. Let do the same for qemu-sbsa one too.
+
+With this change I can boot Debian 'bookworm' installed using Max cpu.
+
+Info from referenced commit:
+
+Starting with QEMU v3.1.0 (Dec 2018), QEMU's TCG emulation engine supports
+the SVE architecture extension. In QEMU v7.1.0 (Aug 2022) it also gained
+SME support.
+
+As it stands today, running TF-A under QEMU with "-cpu max" makes Linux
+hang, because SME and SVE accesses trap to EL3, but are never handled
+there. This is because the Linux kernel sees the SVE or SME feature bits,
+and assumes firmware has enabled the feature for lower exception levels.
+This requirement is described in the Linux kernel booting protocol.
+
+Enable those features in the TF-A build, so that BL31 does the proper
+EL3 setup to make the feature usable in non-secure world.
+We check the actual feature bits before accessing SVE or SME registers,
+so this is safe even for older QEMU version or when not running with
+-cpu max. As SVE and SME are AArch64 features only, do not enable them
+when building for AArch32.
+
+Signed-off-by: Marcin Juszkiewicz 
+Change-Id: I9ea1f91e6b801218d944e8a7d798d5ae568ed59a
+
+
+NOTE: No modifications to the source code have been done.
+  The binaries have been generated for the AARCH64 platform
+  with the following command:
+
+   make PLAT=qemu_sbsa all fip
diff --git a/Platform/Qemu/Sbsa/bl1.bin b/Platform/Qemu/Sbsa/bl1.bin
index 
314bd4cc28c5c14e3d6d02849666a66f94347f5c..716607806966d418b9eb6988262edef2fd86988c
 100755
GIT binary patch
delta 7536
zcmZ`-3tUv!ng8y+GcbTr9s`3wm^*;4@ev;&)OFFZLMkQ06yZQCS-^)L7fYd
z#+D|V>m}9IR7P97~aiOTGL$}g-y5Jc0lvkkYp7!Fe=XezdJL8WOwKH
zo8LL-JKyPQU
z6URTB*J1lrBC}SF(Lob62hq7|?Uy#sqmj+?M8v?C9qKf#CTu@nZZK>9oEpHQgl
zBMY_ON7VWd{+BFdrIZB_U`soJVW+gJJ3`o|$tzq#ydG}@bPY?O3jqg~3%(nV
zioQ}4T{}rsC4(1b-tEzPP1L%=Osy>S7ZN!?mZ$ltQl6FHPKNFTsYNdm0TCGTl
z1Cr#Ix7H4I5*>%2SIeOlEm1377Vmy}YyQwhkqQZn?PIp~_r|wnm76F<-l|siNLIgS
z5uHt`)De_2oaewNDBWZAPc$ZJ%QY*c2)N$j{a$gV!29}rkh8s>F`IU*RdD#10
z7slp$`k?=C!wDbj_6M9AZa8_QTVmL6e1={tay8y#o##ML_t{+SMjC~@P}`3*Z~
z=4h{uUVC%2y;%P&9Nq(3t^4pFfH~|Ys_QXP)qbqg71D6td0dzeeJll`W4fxWXjZp
zF-oW!ZY{*Affw}&=9!P4vT4=5Hp5KmCM6V$xbgeZUSK@+0t
zvYHRGc4jIHPE|r|8wZ$p03(Tt>T#|Z!nNjQYJ-dNG{(7HE5MG38nYUB9(e4IolvYt
z%7k|T4jKoM78veD)b+sMX#Yy^kHMJL8mh%b-{ZUd3g<{Yf8fHv$OXAQGn6xGxr
zXv_FtU@Vp5I=bR0bPaP(0|dt?y)A}#UOE^I%nhl+Y>?`Whz)RKjut?Md-H+9;1^q)|wzy8vv&6gjj;Xf9sq
ze{nI=p)y_*NDWkMtsb(I)aOO6b(lyiO{Qzr;cyj8vucH7$VjV`qb8Z0(7|42zzUXj
z*ez5C@2rBkQsjb!4)#WUjPza4aKl?ZcJWwp!_E7>Ai{1rm`x%37^<_Fsft~nJ+K+V

Re: [edk2-devel] regarding uefipayload build warning for pcd

[ritul guru]

Any idea why the below error comes?

Loading driver 378D7B65-8DA9-4773-B6E4-A47826A833E1
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 51A3E1C0
Loading driver at 0x00051DD1000 EntryPoint=0x00051DD5670 PcRtc.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 51A3ED98
ProtectUefiImageCommon - 0x51A3E1C0
  - 0x51DD1000 - 0x8000
SetUefiImageMemoryAttributes - 0x51DD1000 - 0x1000
(0x4008)
SetUefiImageMemoryAttributes - 0x51DD2000 - 0x6000
(0x00020008)
SetUefiImageMemoryAttributes - 0x51DD8000 - 0x1000
(0x4008)
PROGRESS CODE: V03040002 I0

ASSERT_EFI_ERROR (Status = Device Error)
*ASSERT [PcRtc]
/home//src/p/coreboot/payloads/external/edk2/workspace/tianocore/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c(1)*


*anything to do with warning:*

build time warning:
Active Platform  =
/home//src///coreboot/payloads/external/edk2/workspace/tianocore/UefiPayloadPkg/UefiPayloadPkg.dsc
.build: : warning: The PCD was not specified by any INF module in the
platform for the given architecture.
PCD: [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister]
Platform: [UefiPayloadPkg.dsc]
Arch: ['IA32']
build: : warning: The PCD was not specified by any INF module in the
platform for the given architecture.
PCD: [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcTargetRegister]
Platform: [UefiPayloadPkg.dsc]
Arch: ['IA32']
. done!





*Thanks & RegardsRitul Guru+91-9916513186*


On Wed, Feb 8, 2023 at 3:40 AM Sean Rhodes  wrote:

> L36 is help text that says what you are trying to do, wont work
>
> On Tue, 7 Feb 2023 at 20:51, ritul guru  wrote:
>
>> fatal: repository 'payloads/external/edk2/workspace/tianocore' does not
>> exist
>> make[1]: *** [Makefile:123:
>> /home/amd/src/phx2/coreboot_phx2/coreboot/payloads/external/edk2/workspace/edk2]
>> Error 128
>> make: *** [payloads/external/Makefile.inc:158: build/UEFIPAYLOAD.fd]
>> Error 2
>>
>>
>>
>>
>>
>> *Thanks & RegardsRitul Guru+91-9916513186*
>>
>>
>> On Wed, Feb 8, 2023 at 2:19 AM ritul guru  wrote:
>>
>>> I do not get debug logs from edk2 payload even though debug payload is
>>> selected in menuconfig of coreboot.
>>> and also updated FD_BASE, if not then getting GCD assert while adding
>>> regions in phit table.
>>>
>>> below path should be give at L36 for custom edk2 repo?
>>> payloads/external/edk2/workspace/tianocore/
>>>
>>>
>>>
>>> *Thanks & RegardsRitul Guru+91-9916513186*
>>>
>>>
>>> On Wed, Feb 8, 2023 at 2:06 AM Sean Rhodes 
>>> wrote:
>>>
 Why the edk2 changes? Just to fix this issue?

 Have you seen L36 of payloads/external/edk2/Kconfig

 On Tue, 7 Feb 2023 at 20:30, ritul guru  wrote:

>
>
> Loading driver 378D7B65-8DA9-4773-B6E4-A47826A833E1
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 51A3E1C0
> Loading driver at 0x00051DD1000 EntryPoint=0x00051DD5670 PcRtc.efi
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 51A3ED98
> ProtectUefiImageCommon - 0x51A3E1C0
>   - 0x51DD1000 - 0x8000
> SetUefiImageMemoryAttributes - 0x51DD1000 - 0x1000
> (0x4008)
> SetUefiImageMemoryAttributes - 0x51DD2000 - 0x6000
> (0x00020008)
> SetUefiImageMemoryAttributes - 0x51DD8000 - 0x1000
> (0x4008)
> PROGRESS CODE: V03040002 I0
>
> ASSERT_EFI_ERROR (Status = Device Error)
>
> *ASSERT [PcRtc]
> /home//src/p/coreboot/payloads/external/edk2/workspace/tianocore/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c(1)*
> getting above assert after changed to FD_BASE to below value,
> This error is coming while booting to coreboot with edk2 payload:
>
> UefiPayloadPkg/UefiPayloadPkg.fdf
> DEFINE FD_BASE   = 0x02182000
>
> need to change FD_BASE, as it was going outside Available memory.
> any hint would be appreciated.
>
>
>
>
> *Thanks & RegardsRitul Guru+91-9916513186*
>
>
> On Tue, Feb 7, 2023 at 10:09 PM ritul guru 
> wrote:
>
>> UefiPayloadPkg/UefiPayloadPkg.fdf
>> DEFINE FD_BASE   = 0x0080
>>
>> Is the above address correct in uefipaylaod?
>> As observing some regions are getting out of limit of FD limit,
>>
>> and when setting DEFINE FD_BASE   = 0x0220, then seeing
>> assert in
>> [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister].
>>
>>
>>
>>
>>
>>
>> *Thanks & RegardsRitul Guru+91-9916513186*
>>
>>
>> On Tue, Feb 7, 2023 at 8:29 PM ritul guru 
>> wrote:
>>
>>> Hi,
>>> I am building edk2 payload and getting below warning for
>>> PcdRtcIndexRegister,
>>> and if try to boot to then observing that there is assert at:
>>>
>>> ASSERT_EFI_ERROR 

[edk2-devel] [Patch 1/1] EmulatorPkg/PeiTimerLib: Bug fix in NanoSecondDelay

[Michael D Kinney]

From: Deric Cole 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4339

Thunk->Sleep is expecting nanoseconds, no need to multiply by 100.

Cc: Andrew Fish 
Cc: Ray Ni 
Signed-off-by: Deric Cole 
Reviewed-by: Michael D Kinney 
---
 EmulatorPkg/Include/Protocol/EmuThunk.h   | 2 +-
 EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/EmulatorPkg/Include/Protocol/EmuThunk.h 
b/EmulatorPkg/Include/Protocol/EmuThunk.h
index b720023ac9c7..c419d0a67790 100644
--- a/EmulatorPkg/Include/Protocol/EmuThunk.h
+++ b/EmulatorPkg/Include/Protocol/EmuThunk.h
@@ -130,7 +130,7 @@ UINT64
 typedef
 VOID
 (EFIAPI *EMU_SLEEP)(
-  IN  UINT64Milliseconds
+  IN  UINT64Nanoseconds
   );
 
 typedef
diff --git a/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c 
b/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
index 8c4f20f42b47..5344719f98d8 100644
--- a/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
+++ b/EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.c
@@ -1,7 +1,7 @@
 /** @file
   A non-functional instance of the Timer Library.
 
-  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
+  Copyright (c) 2007 - 2023, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -65,7 +65,7 @@ NanoSecondDelay (
  );
   if (!EFI_ERROR (Status)) {
 Thunk = (EMU_THUNK_PROTOCOL *)ThunkPpi->Thunk ();
-Thunk->Sleep (NanoSeconds * 100);
+Thunk->Sleep (NanoSeconds);
 return NanoSeconds;
   }
 
-- 
2.37.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99822): https://edk2.groups.io/g/devel/message/99822
Mute This Topic: https://groups.io/mt/96842440/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 2/3] ArmPkg/CpuDxe: Perform preliminary NX remap of free memory

[Ard Biesheuvel]

On Wed, 8 Feb 2023 at 19:57, Taylor Beebe  wrote:
>
>
>
> On 2/8/2023 10:49 AM, Ard Biesheuvel wrote:
> > On Wed, 8 Feb 2023 at 19:32, Marvin Häuser  wrote:
> >>
> >> Thanks!! :) Comments inline.
> >>
> >>> On 8. Feb 2023, at 18:58, Ard Biesheuvel  wrote:
> >>>
> >>> The DXE core implementation of PcdDxeNxMemoryProtectionPolicy already
> >>> contains an assertion that EfiConventionalMemory and EfiBootServicesData
> >>> are subjected to the same policy when it comes to the use of NX
> >>> permissions. The reason for this is that we may otherwise end up with
> >>> unbounded recursion in the page table code, given that allocating a page
> >>> table would then involve a permission attribute change, and this could
> >>> result in the need for a block entry to be split, which would trigger
> >>> the allocation of a page table recursively.
> >>>
> >>> For the same reason, a shortcut exists in ApplyMemoryProtectionPolicy()
> >>> where, instead of setting the memory attributes unconditionally, we
> >>> compare the NX policies and avoid touching the page tables if they are
> >>> the same for the old and the new memory types. Without this shortcut, we
> >>> may end up in a situation where, as the CPU arch protocol DXE driver is
> >>> ramping up, the same unbounded recursion is triggered, due to the fact
> >>> that the NX policy for EfiConventionalMemory has not been applied yet.
> >>>
> >>> To break this cycle, let's remap all EfiConventionalMemory regions
> >>> according to the NX policy for EfiBootServicesData before exposing the
> >>> CPU arch protocol to the DXE core and other drivers. This ensures that
> >>> creating EfiBootServicesData allocations does not result in memory
> >>> attribute changes, and therefore no recursion.
> >>>
> >>> Signed-off-by: Ard Biesheuvel 
> >>> ---
> >>> ArmPkg/Drivers/CpuDxe/CpuDxe.c   | 77 
> >>> ArmPkg/Drivers/CpuDxe/CpuDxe.inf |  2 +
> >>> 2 files changed, 79 insertions(+)
> >>>
> >>> diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.c 
> >>> b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> >>> index d04958e79e52..83fd6fd4e476 100644
> >>> --- a/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> >>> +++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> >>> @@ -11,6 +11,8 @@
> >>>
> >>> #include 
> >>>
> >>> +#include 
> >>> +
> >>> BOOLEAN  mIsFlushingGCD;
> >>>
> >>> /**
> >>> @@ -227,6 +229,69 @@ InitializeDma (
> >>>CpuArchProtocol->DmaBufferAlignment = ArmCacheWritebackGranule ();
> >>> }
> >>>
> >>> +STATIC
> >>> +VOID
> >>> +RemapUnusedMemoryNx (
> >>> +  VOID
> >>> +  )
> >>> +{
>
> This feels somewhat hacky but it's strictly better than what we have
> right now and a value add so I'm all for this change.
>
> >>> +  UINT64 TestBit;
> >>> +  UINTN  MemoryMapSize;
> >>> +  UINTN  MapKey;
> >>> +  UINTN  DescriptorSize;
> >>> +  UINT32 DescriptorVersion;
> >>> +  EFI_MEMORY_DESCRIPTOR  *MemoryMap;
> >>> +  EFI_MEMORY_DESCRIPTOR  *MemoryMapEntry;
> >>> +  EFI_MEMORY_DESCRIPTOR  *MemoryMapEnd;
> >>> +  EFI_STATUS Status;
> >>> +
> >>> +  TestBit = LShiftU64 (1, EfiBootServicesData);
> >>> +  if ((PcdGet64 (PcdDxeNxMemoryProtectionPolicy) & TestBit) == 0) {
> >>> +return;
> >>> +  }
> >>> +
> >>> +  MemoryMapSize = 0;
> >>> +  MemoryMap = NULL;
> >>> +
> >>> +  Status = gBS->GetMemoryMap (
> >>> +  ,
> >>> +  MemoryMap,
> >>> +  ,
> >>> +  ,
> >>> +  
> >>> +  );
> >>> +  ASSERT (Status == EFI_BUFFER_TOO_SMALL);
> >>> +  do {
> >>> +MemoryMap = (EFI_MEMORY_DESCRIPTOR *)AllocatePool (MemoryMapSize);
> >>
> >> nitpick: *If* there is a V2, maybe drop the cast?
> >>
> >>> +ASSERT (MemoryMap != NULL);
> >>
> >> I know ASSERTing for NULL is a common pattern for some reason, but I'd 
> >> rather not have more code with this added.
> >>
> >>> +Status = gBS->GetMemoryMap (
> >>> +,
> >>> +MemoryMap,
> >>> +,
> >>> +,
> >>> +
> >>> +);
> >>
> >> Another nitpick, isn't it common practice to call the Core* functions 
> >> directly within *Core? I know there is code that doesn't, but the former 
> >> should be more efficient.
> >>
> >>> +if (EFI_ERROR (Status)) {
> >>> +  FreePool (MemoryMap);
> >>> +}
> >>> +  } while (Status == EFI_BUFFER_TOO_SMALL);
> >>
> >> Is this guaranteed to terminate? I mean, I get the idea - try again with 
> >> the larger size and when allocating the bigger buffer, its potential new 
> >> entry will already be accounted for. However, I saw downstream code that 
> >> tried something like this (they actually added a constant overhead ahead 
> >> of time) bounded by something like 5 iterations. Might just have been 
> >> defensive programming - probably was -, but it's not trivial to verify, I 
> >> think, is it?
> >>
> >> 

Re: [edk2-devel] [edk2-platforms: PATCH v3] IntelSiliconPkg/SpiFvbServiceSmm: Rewrite VariableStore header.

[Chiu, Chasel]

Thanks for reviewing Michael.
Please see my reply below inline and help to review V4 patch again.

Thanks,
Chasel



> -Original Message-
> From: Michael Kubacki 
> Sent: Tuesday, February 7, 2023 12:22 PM
> To: devel@edk2.groups.io; Chiu, Chasel 
> Cc: S, Ashraf Ali ; Oram, Isaac W
> ; Chaganty, Rangasai V
> ; Ni, Ray ; Kubacki,
> Michael 
> Subject: Re: [edk2-devel] [edk2-platforms: PATCH v3]
> IntelSiliconPkg/SpiFvbServiceSmm: Rewrite VariableStore header.
> 
> Hi Chasel,
> 
> I agree with the high-level problem. Here's some observations.
> 
> 1. I'm not a big fan of implicitly associating index zero of the
> mPlatformFvBaseAddress array as the variable FV entry. It could be easy for 
> that
> to silently get out of sync in the future.
> 
> Perhaps you could check if the base address at a given index equals the 
> variable
> store address since it is retrieved via
> GetVariableFlashNvStorageInfo() at the beginning of FvbInitialize().
> 


Done in V4


> 2. VariableFlashInfoLib is meant to abstract var store info with
> GetVariableFlashNvStorageInfo().
> 
> Please use that instead of directly getting it with PcdGet32
> (PcdFlashNvStorageVariableSize).
> 


Done in V4

> 3. Suggest a blank link before the following text for readability.
> 
>  //
>  // Write buffer to flash
>  //
> 


Done in V4

> 4. Usually there's a few default variables in the var store FV that form a
> foundation that the variable HOB gets written upon when the HOB gets flushed.
> Does the original var store FV still contain some of those entries? If so, 
> this just
> restores an empty store, so those are known to be lost, right?
> 
> If that's true, please call it out in the patch description.
> 

Since SpiFvbService driver only needs VariableStore information, it should only 
rewrite FV and VariableStore headers.
I added comments in code and commit message to mention about "the corrupted 
variable content should be taken care by FaultTolerantWrite driver later".
Please see if this I good enough.



> Thanks,
> Michael
> 
> On 2/7/2023 2:42 PM, Chiu, Chasel wrote:
> > When invalid VariableStore FV header detected, current SpiFvbService
> > will erase both FV and VariableStore headers from flash, however, it
> > will only rewrite FV header back and cause invalid VariableStore
> > header.
> >
> > This patch adding the support for rewriting both FV header and
> > VariableStore header when VariableStore corruption happened.
> >
> > Platform has to set PcdFlashVariableStoreType to inform SpiFvbService
> > which VariableStoreType should be rewritten.
> >
> > Cc: Ashraf Ali S 
> > Cc: Isaac Oram 
> > Cc: Rangasai V Chaganty 
> > Cc: Ray Ni 
> > Cc: Michael Kubacki 
> > Signed-off-by: Chasel Chiu 
> > ---
> >   
> > Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c
> | 64 +++---
> --
> >
> Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceSmm.inf
> |  4 
> >   Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec 
> >  |  8 
> >   3 files changed, 71 insertions(+), 5 deletions(-)
> >
> > diff --git
> > a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServ
> > iceMm.c
> > b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServ
> > iceMm.c
> > index 6b4bcdcfe3..6338442e1a 100644
> > ---
> > a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServ
> > iceMm.c
> > +++ b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvb
> > +++ ServiceMm.c
> > @@ -12,6 +12,7 @@
> >   #include 
> >
> >   #include 
> >
> >   #include 
> >
> > +#include 
> >
> >
> >
> >   /**
> >
> > The function installs EFI_FIRMWARE_VOLUME_BLOCK protocol
> >
> > @@ -114,6 +115,10 @@ FvbInitialize (
> > UINT32BytesWritten;
> >
> > UINTN BytesErased;
> >
> > UINT64NvStorageFvSize;
> >
> > +  UINT32ExpectedBytesWritten;
> >
> > +  VARIABLE_STORE_HEADER *VariableStoreHeader;
> >
> > +  UINT8 VariableStoreType;
> >
> > +  UINT8 *NvStoreBuffer;
> >
> >
> >
> > Status = GetVariableFlashNvStorageInfo (,
> > );
> >
> > if (EFI_ERROR (Status)) {
> >
> > @@ -186,8 +191,57 @@ FvbInitialize (
> > }
> >
> > continue;
> >
> >   }
> >
> > -BytesWritten = FvHeader->HeaderLength;
> >
> > -Status = SpiFlashWrite ((UINTN)BaseAddress, ,
> (UINT8*)FvHeader);
> >
> > +
> >
> > +BytesWritten = FvHeader->HeaderLength;
> >
> > +ExpectedBytesWritten = BytesWritten;
> >
> > +if (Idx != 0) {
> >
> > +  Status = SpiFlashWrite ((UINTN)BaseAddress, ,
> > + (UINT8 *)FvHeader);
> >
> > +} else {
> >
> > +  //
> >
> > +  // This is 

Re: [edk2-devel] [PATCH 3/3] MdeModulePkg/DxeCore: Unconditionally set memory protections

[Taylor Beebe]

On 2/8/2023 2:08 PM, Ard Biesheuvel wrote:

On Wed, 8 Feb 2023 at 20:12, Taylor Beebe  wrote:


I ran some tests and did some quick napkin math. Based on the time it
takes to perform the SetMemoryAttributes() routine on QEMU, as long as
<79% of the calls to ApplyMemoryProtectionPolicy() actually require a
subsequent call to SetMemoryAttributes(), it is more efficient to walk
the page/translation table to check if the attributes actually need to
be updated. Even on a platform with varied NX policy settings, the
number of times the attributes need to be updated is less than 0.0005%
of all calls to ApplyMemoryProtectionPolicy() (likely due to most
allocations being BootServicesData).

Once the ARM and X64 implementations of the Memory Attribute Protocol
are in, would you be open to updating this block to utilize the protocol
to check the attributes of the region being updated?



Yes, that was what I had in my initial prototype.

However, I'm not sure how walking the page tables to retrieve all
existing attributes is fundamentally different from walking the page
tables to set them, given that everything is cached and we are running
uniprocessor at this point.



I was also skeptical, but running the experiment revealed that checking 
the page table is the clear winner. My guess is that branch prediction 
expects the table walk to reveal that the SetAttributes() call is 
unnecessary, and the cost of doing an instruction pipeline flush due to 
improper branch prediction is similar to the cost of doing a TLB 
flush/invalidation after the call to SetAttributes() making the upside 
outweigh the downside in almost all cases.





On 2/8/2023 10:25 AM, Ard Biesheuvel wrote:

On Wed, 8 Feb 2023 at 18:58, Ard Biesheuvel  wrote:


Instead of relying on a questionable heuristic that avoids calling into
the SetMemoryAttributes () DXE service when the old memory type and the
new one are subjected to the same NX memory protection policy, make this
call unconditionally. This avoids corner cases where memory region
attributes are out of sync with the policy, either due to the fact that
we are in the middle of ramping up the protections, or due to explicit
invocations of SetMemoryAttributes() by drivers.

This requires the architecture page table code to be able to deal with
this, in particular, it needs to be robust against potential recursion
due to NX policies being applied to newly allocated page tables.

Signed-off-by: Ard Biesheuvel 
---
   MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 29 
   1 file changed, 29 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
index 36987843f142..503feb72b5d0 100644
--- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
+++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
@@ -1263,9 +1263,7 @@ ApplyMemoryProtectionPolicy (
 IN  UINT64Length
 )
   {
-  UINT64  OldAttributes;
 UINT64  NewAttributes;
-  EFI_STATUS  Status;

 //
 // The policy configured in PcdDxeNxMemoryProtectionPolicy
@@ -1320,32 +1318,5 @@ ApplyMemoryProtectionPolicy (
 //
 NewAttributes = GetPermissionAttributeForMemoryType (NewType);

-  if (OldType != EfiMaxMemoryType) {
-OldAttributes = GetPermissionAttributeForMemoryType (OldType);
-if (!mAfterDxeNxMemoryProtectionInit &&
-(OldAttributes == NewAttributes)) {
-  return EFI_SUCCESS;
-}
-


This removes some code that does not actually exist - apologies.

It comes down to just removing the conditional checks here, though,
and perform the tail call below unconditionally.


-//
-// If available, use the EFI memory attribute protocol to obtain
-// the current attributes of the region. If the entire region is
-// covered and the attributes match, we don't have to do anything.
-//
-if (mMemoryAttribute != NULL) {
-  Status = mMemoryAttribute->GetMemoryAttributes (mMemoryAttribute,
-  Memory,
-  Length,
-  
-  );
-  if (!EFI_ERROR (Status) && (OldAttributes == NewAttributes)) {
-return EFI_SUCCESS;
-  }
-}
-  } else if (NewAttributes == 0) {
-// newly added region of a type that does not require protection
-return EFI_SUCCESS;
-  }
-
 return gCpu->SetMemoryAttributes (gCpu, Memory, Length, NewAttributes);
   }
--
2.39.1



--
Taylor Beebe
Software Engineer @ Microsoft


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99819): https://edk2.groups.io/g/devel/message/99819
Mute This Topic: https://groups.io/mt/96835917/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v4] IntelSiliconPkg/SpiFvbServiceSmm: Rewrite VariableStore header.

[Chiu, Chasel]

When invalid VariableStore FV header detected, current SpiFvbService
will erase both FV and VariableStore headers from flash, however,
it will only rewrite FV header back and cause invalid VariableStore
header.

This patch adding the support for rewriting both FV header and
VariableStore header when VariableStore corruption happened.
The Corrupted variable content should be taken care by
FaultTolerantWrite driver later.

Platform has to set PcdFlashVariableStoreType to inform SpiFvbService
which VariableStoreType should be rewritten.

Cc: Ashraf Ali S 
Cc: Isaac Oram 
Cc: Rangasai V Chaganty 
Cc: Ray Ni 
Cc: Michael Kubacki 
Signed-off-by: Chasel Chiu 
---
 Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c
| 69 -
 Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceSmm.inf 
|  3 +++
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec  
|  8 
 3 files changed, 75 insertions(+), 5 deletions(-)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c 
b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c
index 6b4bcdcfe3..052be97872 100644
--- 
a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c
+++ 
b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceMm.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
   The function installs EFI_FIRMWARE_VOLUME_BLOCK protocol
@@ -113,7 +114,12 @@ FvbInitialize (
   UINT32MaxLbaSize;
   UINT32BytesWritten;
   UINTN BytesErased;
+  EFI_PHYSICAL_ADDRESS  NvStorageBaseAddress;
   UINT64NvStorageFvSize;
+  UINT32ExpectedBytesWritten;
+  VARIABLE_STORE_HEADER *VariableStoreHeader;
+  UINT8 VariableStoreType;
+  UINT8 *NvStoreBuffer;
 
   Status = GetVariableFlashNvStorageInfo (, );
   if (EFI_ERROR (Status)) {
@@ -124,12 +130,14 @@ FvbInitialize (
 
   // Stay within the current UINT32 size assumptions in the variable stack.
   Status = SafeUint64ToUint32 (BaseAddress, [0].FvBase);
+  NvStorageBaseAddress = mPlatformFvBaseAddress[0].FvBase;
   if (EFI_ERROR (Status)) {
 ASSERT_EFI_ERROR (Status);
 DEBUG ((DEBUG_ERROR, "[%a] - 64-bit variable storage base address not 
supported.\n", __FUNCTION__));
 return;
   }
   Status = SafeUint64ToUint32 (NvStorageFvSize, 
[0].FvSize);
+  NvStorageFvSize = mPlatformFvBaseAddress[0].FvSize;
   if (EFI_ERROR (Status)) {
 ASSERT_EFI_ERROR (Status);
 DEBUG ((DEBUG_ERROR, "[%a] - 64-bit variable storage size not 
supported.\n", __FUNCTION__));
@@ -186,8 +194,59 @@ FvbInitialize (
   }
   continue;
 }
-BytesWritten = FvHeader->HeaderLength;
-Status = SpiFlashWrite ((UINTN)BaseAddress, , 
(UINT8*)FvHeader);
+
+BytesWritten = FvHeader->HeaderLength;
+ExpectedBytesWritten = BytesWritten;
+if (BaseAddress != NvStorageBaseAddress) {
+  Status = SpiFlashWrite ((UINTN)BaseAddress, , (UINT8 
*)FvHeader);
+} else {
+  //
+  // This is Variable Store, rewrite both EFI_FIRMWARE_VOLUME_HEADER 
and VARIABLE_STORE_HEADER.
+  // The corrupted Variable content should be taken care by 
FaultTolerantWrite driver later.
+  //
+  NvStoreBuffer = NULL;
+  NvStoreBuffer = AllocateZeroPool (sizeof (VARIABLE_STORE_HEADER) + 
FvHeader->HeaderLength);
+  if (NvStoreBuffer != NULL) {
+//
+// Combine FV header and VariableStore header into the buffer.
+//
+CopyMem (NvStoreBuffer, FvHeader, FvHeader->HeaderLength);
+VariableStoreHeader = (VARIABLE_STORE_HEADER *)(NvStoreBuffer + 
FvHeader->HeaderLength);
+VariableStoreType   = PcdGet8 (PcdFlashVariableStoreType);
+switch (VariableStoreType) {
+  case 0:
+DEBUG ((DEBUG_ERROR, "Type: gEfiVariableGuid\n"));
+CopyGuid (>Signature, );
+break;
+  case 1:
+DEBUG ((DEBUG_ERROR, "Type: gEfiAuthenticatedVariableGuid\n"));
+CopyGuid (>Signature, 
);
+break;
+  default:
+break;
+}
+
+//
+// Initialize common VariableStore header fields
+//
+VariableStoreHeader->Size  = (UINT32) (NvStorageFvSize - 
FvHeader->HeaderLength);
+VariableStoreHeader->Format= VARIABLE_STORE_FORMATTED;
+VariableStoreHeader->State = VARIABLE_STORE_HEALTHY;
+VariableStoreHeader->Reserved  = 0;
+VariableStoreHeader->Reserved1 = 0;
+
+  

Re: [edk2-devel] [PATCH 3/3] MdeModulePkg/DxeCore: Unconditionally set memory protections

[Ard Biesheuvel]

On Wed, 8 Feb 2023 at 20:12, Taylor Beebe  wrote:
>
> I ran some tests and did some quick napkin math. Based on the time it
> takes to perform the SetMemoryAttributes() routine on QEMU, as long as
> <79% of the calls to ApplyMemoryProtectionPolicy() actually require a
> subsequent call to SetMemoryAttributes(), it is more efficient to walk
> the page/translation table to check if the attributes actually need to
> be updated. Even on a platform with varied NX policy settings, the
> number of times the attributes need to be updated is less than 0.0005%
> of all calls to ApplyMemoryProtectionPolicy() (likely due to most
> allocations being BootServicesData).
>
> Once the ARM and X64 implementations of the Memory Attribute Protocol
> are in, would you be open to updating this block to utilize the protocol
> to check the attributes of the region being updated?
>

Yes, that was what I had in my initial prototype.

However, I'm not sure how walking the page tables to retrieve all
existing attributes is fundamentally different from walking the page
tables to set them, given that everything is cached and we are running
uniprocessor at this point.


> On 2/8/2023 10:25 AM, Ard Biesheuvel wrote:
> > On Wed, 8 Feb 2023 at 18:58, Ard Biesheuvel  wrote:
> >>
> >> Instead of relying on a questionable heuristic that avoids calling into
> >> the SetMemoryAttributes () DXE service when the old memory type and the
> >> new one are subjected to the same NX memory protection policy, make this
> >> call unconditionally. This avoids corner cases where memory region
> >> attributes are out of sync with the policy, either due to the fact that
> >> we are in the middle of ramping up the protections, or due to explicit
> >> invocations of SetMemoryAttributes() by drivers.
> >>
> >> This requires the architecture page table code to be able to deal with
> >> this, in particular, it needs to be robust against potential recursion
> >> due to NX policies being applied to newly allocated page tables.
> >>
> >> Signed-off-by: Ard Biesheuvel 
> >> ---
> >>   MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 29 
> >>   1 file changed, 29 deletions(-)
> >>
> >> diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
> >> b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> >> index 36987843f142..503feb72b5d0 100644
> >> --- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> >> +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> >> @@ -1263,9 +1263,7 @@ ApplyMemoryProtectionPolicy (
> >> IN  UINT64Length
> >> )
> >>   {
> >> -  UINT64  OldAttributes;
> >> UINT64  NewAttributes;
> >> -  EFI_STATUS  Status;
> >>
> >> //
> >> // The policy configured in PcdDxeNxMemoryProtectionPolicy
> >> @@ -1320,32 +1318,5 @@ ApplyMemoryProtectionPolicy (
> >> //
> >> NewAttributes = GetPermissionAttributeForMemoryType (NewType);
> >>
> >> -  if (OldType != EfiMaxMemoryType) {
> >> -OldAttributes = GetPermissionAttributeForMemoryType (OldType);
> >> -if (!mAfterDxeNxMemoryProtectionInit &&
> >> -(OldAttributes == NewAttributes)) {
> >> -  return EFI_SUCCESS;
> >> -}
> >> -
> >
> > This removes some code that does not actually exist - apologies.
> >
> > It comes down to just removing the conditional checks here, though,
> > and perform the tail call below unconditionally.
> >
> >> -//
> >> -// If available, use the EFI memory attribute protocol to obtain
> >> -// the current attributes of the region. If the entire region is
> >> -// covered and the attributes match, we don't have to do anything.
> >> -//
> >> -if (mMemoryAttribute != NULL) {
> >> -  Status = mMemoryAttribute->GetMemoryAttributes (mMemoryAttribute,
> >> -  Memory,
> >> -  Length,
> >> -  
> >> -  );
> >> -  if (!EFI_ERROR (Status) && (OldAttributes == NewAttributes)) {
> >> -return EFI_SUCCESS;
> >> -  }
> >> -}
> >> -  } else if (NewAttributes == 0) {
> >> -// newly added region of a type that does not require protection
> >> -return EFI_SUCCESS;
> >> -  }
> >> -
> >> return gCpu->SetMemoryAttributes (gCpu, Memory, Length, NewAttributes);
> >>   }
> >> --
> >> 2.39.1
> >>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99817): https://edk2.groups.io/g/devel/message/99817
Mute This Topic: https://groups.io/mt/96835917/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 RESEND] RedfishPkg: RedfishRestExDxe: Two PCDs for controlling the requests

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Hi Igor,
Few comments in below.

> -Original Message-
> From: Igor Kulchytskyy 
> Sent: Thursday, February 9, 2023 1:23 AM
> To: devel@edk2.groups.io
> Cc: Igor Kulchytskyy ; Chang, Abner
> ; Nickle Wang 
> Subject: [PATCH V2 RESEND] RedfishPkg: RedfishRestExDxe: Two PCDs for
> controlling the requests
> 
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
> 
> 
> Since BIOS should work with different BMC implementation chunked requests as
> well as Expect header should be optional.
> One PCD is used to enable/disable Expect header.
> Another PCD is used to enable/disable chunked requests.
> 
> Cc: Abner Chang 
> Cc: Nickle Wang 
> Signed-off-by: Igor Kulchytskyy 
> ---
>  RedfishPkg/RedfishPkg.dec   |  10 ++
>  RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf|   2 +
>  RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c |  23 ++--
>  RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c | 140 
> 
>  4 files changed, 113 insertions(+), 62 deletions(-)
> 
> diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec index
> d2b189b..89ef32a 100644
> --- a/RedfishPkg/RedfishPkg.dec
> +++ b/RedfishPkg/RedfishPkg.dec
> @@ -97,3 +97,13 @@
># protocol instance.
>#
> 
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDiscoverAccessModeInBand|FALSE|
> BOOLEAN|0x1002
> +  #
> +  # This PCD indicates if the EFI REST EX sends chunk request to Redfish 
> service.
> +  # Default is set to non chunk mode.
> +  #
> +
> +
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExChunkRequestMode|TRUE|BO
> O
> + LEAN|0x1003
We can default set PcdRedfishRestExChunkRequestMode to FALSE.


> +  #
> +  # This PCD indicates if the EFI REST EX adds Expect header to the POST, 
> PATCH,
> PUT requests to Redfish service.
> +  # Default is set to not add.
> +  #
> +
> +
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExAddingExpect|FALSE|BOOLEA
> + N|0x1004
> diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
> b/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
> index 75437b0..29003ae 100644
> --- a/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
> +++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
> @@ -57,6 +57,8 @@
> 
>  [Pcd]
>gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExServiceAccessModeInBand
> ## CONSUMES
> +  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExChunkRequestMode   ##
> CONSUMES
> +  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExAddingExpect   ##
> CONSUMES
> 
>  [UserExtensions.TianoCore."ExtraFiles"]
>RedfishRestExDxeExtra.uni
> diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
> b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
> index 952e9d1..0da0d10 100644
> --- a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
> +++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
> @@ -140,9 +140,6 @@ RedfishHttpAddExpectation (
>}
> 
>*ItsWrite = FALSE;
> -  if (PreservedRequestHeaders != NULL) {
> -*PreservedRequestHeaders = RequestMessage->Headers;
> -  }
> 
>if ((RequestMessage->Data.Request->Method != HttpMethodPut) &&
> (RequestMessage->Data.Request->Method != HttpMethodPost) &&
>(RequestMessage->Data.Request->Method != HttpMethodPatch)) @@ -
> 152,10 +149,20 @@ RedfishHttpAddExpectation (
> 
>*ItsWrite = TRUE;
> 
> -  NewHeaders = AllocateZeroPool ((RequestMessage->HeaderCount + 1) *
> sizeof (EFI_HTTP_HEADER));
> -  CopyMem ((VOID *)NewHeaders, (VOID *)RequestMessage->Headers,
> RequestMessage->HeaderCount * sizeof (EFI_HTTP_HEADER));
> -  HttpSetFieldNameAndValue (NewHeaders + RequestMessage->HeaderCount,
> HTTP_HEADER_EXPECT, HTTP_EXPECT_100_CONTINUE);
> -  RequestMessage->HeaderCount++;
> -  RequestMessage->Headers = NewHeaders;
> +  //
> +  // Check PCD before adding Expect header  //
> +  if(FixedPcdGetBool(PcdRedfishRestExAddingExpect)) {
> +if (PreservedRequestHeaders != NULL) {
> +  *PreservedRequestHeaders = RequestMessage->Headers;
> +}
> +
> +NewHeaders = AllocateZeroPool ((RequestMessage->HeaderCount + 1) *
> sizeof (EFI_HTTP_HEADER));
> +CopyMem ((VOID *)NewHeaders, (VOID *)RequestMessage->Headers,
> RequestMessage->HeaderCount * sizeof (EFI_HTTP_HEADER));
> +HttpSetFieldNameAndValue (NewHeaders + RequestMessage->HeaderCount,
> HTTP_HEADER_EXPECT, HTTP_EXPECT_100_CONTINUE);
> +RequestMessage->HeaderCount++;
> +RequestMessage->Headers = NewHeaders;  }
> +
>return EFI_SUCCESS;
>  }
> diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c
> b/RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c
> index 4b61fc0..fbd5e46 100644
> --- a/RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c
> +++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c
> @@ -66,11 +66,13 @@ RedfishRestExSendReceive (
>HTTP_IO_SEND_NON_CHUNK_PROCESS  SendNonChunkProcess;
>EFI_HTTP_MESSAGEChunkTransferRequestMessage;
> 
> -  

Re: [edk2-devel] [PATCH 1/1] .pytool/Plugin/EccCheck: Add PACKAGES_PATH support

[Michael D Kinney]

Merged 

https://github.com/tianocore/edk2/pull/4018

Commit: 
https://github.com/tianocore/edk2/commit/b59e6fdae2545b45c36c8c5373f4b858fb83c8cd

Mike


> -Original Message-
> From: Kinney, Michael D 
> Sent: Tuesday, February 7, 2023 11:33 PM
> To: devel@edk2.groups.io; mhaeu...@posteo.de
> Cc: Feng, Bob C ; Chen, Christine 
> ; Sean Brogan ; Michael
> Kubacki ; Gao, Liming 
> ; Pedro Falcato ; Kinney,
> Michael D 
> Subject: RE: [edk2-devel] [PATCH 1/1] .pytool/Plugin/EccCheck: Add 
> PACKAGES_PATH support
> 
> I will merge tomorrow.
> 
> Mike
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Marvin Häuser
> > Sent: Tuesday, February 7, 2023 4:49 AM
> > To: Kinney, Michael D 
> > Cc: devel@edk2.groups.io; Feng, Bob C ; Chen, 
> > Christine ; Sean Brogan
> > ; Michael Kubacki 
> > ; Gao, Liming ; 
> > Pedro Falcato
> > 
> > Subject: Re: [edk2-devel] [PATCH 1/1] .pytool/Plugin/EccCheck: Add 
> > PACKAGES_PATH support
> >
> > Hi Mike,
> >
> > This patch was reviewed by Michael Kubacki. It is required to enable 
> > edk2-platforms CI for Ext4Pkg, upstream workarounds on the
> > edk2-platforms side would be *very* ugly. Also, the change is trivial and 
> > basically just a copy-and-paste from other pytools. Can
> we
> > please merge this into the next stable tag?
> >
> > Best regards,
> > Marvin
> >
> > > On 1. Feb 2023, at 20:56, Kinney, Michael D  
> > > wrote:
> > >
> > > +Bob
> > > +Christine
> > >
> > >
> > >> -Original Message-
> > >> From: Marvin Häuser 
> > >> Sent: Wednesday, February 1, 2023 6:48 AM
> > >> To: devel@edk2.groups.io
> > >> Cc: Marvin Häuser ; Sean Brogan 
> > >> ; Michael Kubacki
> > >> ; Kinney, Michael D 
> > >> ; Gao, Liming
> > >> ; Pedro Falcato 
> > >> Subject: [PATCH 1/1] .pytool/Plugin/EccCheck: Add PACKAGES_PATH support
> > >>
> > >> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4326
> > >>
> > >> EccBuild currently assumes all packages reside in WORKSPACE. However,
> > >> this is obviously not the case for many setups. Most notably, Ext4Pkg
> > >> is located in edk2-platforms/Features and thus cannot be in WORKSPACE
> > >> in any reasonable setup.
> > >>
> > >> Use Edk2Path to locate the package in WORKSPACE and PACKAGES_PATH.
> > >>
> > >> Cc: Sean Brogan 
> > >> Cc: Michael Kubacki 
> > >> Cc: Michael D Kinney 
> > >> Cc: Liming Gao 
> > >> Cc: Pedro Falcato 
> > >> Signed-off-by: Marvin Häuser 
> > >> ---
> > >> .pytool/Plugin/EccCheck/EccCheck.py | 9 -
> > >> 1 file changed, 8 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/.pytool/Plugin/EccCheck/EccCheck.py 
> > >> b/.pytool/Plugin/EccCheck/EccCheck.py
> > >> index 4fbc67765fdf..7235fcb55cea 100644
> > >> --- a/.pytool/Plugin/EccCheck/EccCheck.py
> > >> +++ b/.pytool/Plugin/EccCheck/EccCheck.py
> > >> @@ -69,6 +69,13 @@ class EccCheck(ICiBuildPlugin):
> > >> env.set_shell_var('PACKAGES_PATH', 
> > >> os.pathsep.join(Edk2pathObj.PackagePathList))
> > >> self.ECC_PASS = True
> > >>
> > >> +abs_pkg_path = 
> > >> Edk2pathObj.GetAbsolutePathOnThisSystemFromEdk2RelativePath(packagename)
> > >> +
> > >> +if abs_pkg_path is None:
> > >> +tc.SetSkipped()
> > >> +tc.LogStdError("No Package folder {0}".format(abs_pkg_path))
> > >> +return 0
> > >> +
> > >> # Create temp directory
> > >> temp_path = os.path.join(workspace_path, 'Build', '.pytool', 
> > >> 'Plugin', 'EccCheck')
> > >> try:
> > >> @@ -77,7 +84,7 @@ class EccCheck(ICiBuildPlugin):
> > >> shutil.rmtree(temp_path)
> > >> # Copy package being scanned to temp_path
> > >> shutil.copytree (
> > >> -  os.path.join(workspace_path, packagename),
> > >> +  abs_pkg_path,
> > >>   os.path.join(temp_path, packagename),
> > >>   symlinks=True
> > >>   )
> > >> --
> > >> 2.39.1
> > >
> >
> >
> >
> > 
> >



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99815): https://edk2.groups.io/g/devel/message/99815
Mute This Topic: https://groups.io/mt/96677674/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 3/3] MdeModulePkg/DxeCore: Unconditionally set memory protections

[Taylor Beebe]

I ran some tests and did some quick napkin math. Based on the time it 
takes to perform the SetMemoryAttributes() routine on QEMU, as long as 
<79% of the calls to ApplyMemoryProtectionPolicy() actually require a 
subsequent call to SetMemoryAttributes(), it is more efficient to walk 
the page/translation table to check if the attributes actually need to 
be updated. Even on a platform with varied NX policy settings, the 
number of times the attributes need to be updated is less than 0.0005% 
of all calls to ApplyMemoryProtectionPolicy() (likely due to most 
allocations being BootServicesData).


Once the ARM and X64 implementations of the Memory Attribute Protocol 
are in, would you be open to updating this block to utilize the protocol 
to check the attributes of the region being updated?


On 2/8/2023 10:25 AM, Ard Biesheuvel wrote:

On Wed, 8 Feb 2023 at 18:58, Ard Biesheuvel  wrote:


Instead of relying on a questionable heuristic that avoids calling into
the SetMemoryAttributes () DXE service when the old memory type and the
new one are subjected to the same NX memory protection policy, make this
call unconditionally. This avoids corner cases where memory region
attributes are out of sync with the policy, either due to the fact that
we are in the middle of ramping up the protections, or due to explicit
invocations of SetMemoryAttributes() by drivers.

This requires the architecture page table code to be able to deal with
this, in particular, it needs to be robust against potential recursion
due to NX policies being applied to newly allocated page tables.

Signed-off-by: Ard Biesheuvel 
---
  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 29 
  1 file changed, 29 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
index 36987843f142..503feb72b5d0 100644
--- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
+++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
@@ -1263,9 +1263,7 @@ ApplyMemoryProtectionPolicy (
IN  UINT64Length
)
  {
-  UINT64  OldAttributes;
UINT64  NewAttributes;
-  EFI_STATUS  Status;

//
// The policy configured in PcdDxeNxMemoryProtectionPolicy
@@ -1320,32 +1318,5 @@ ApplyMemoryProtectionPolicy (
//
NewAttributes = GetPermissionAttributeForMemoryType (NewType);

-  if (OldType != EfiMaxMemoryType) {
-OldAttributes = GetPermissionAttributeForMemoryType (OldType);
-if (!mAfterDxeNxMemoryProtectionInit &&
-(OldAttributes == NewAttributes)) {
-  return EFI_SUCCESS;
-}
-


This removes some code that does not actually exist - apologies.

It comes down to just removing the conditional checks here, though,
and perform the tail call below unconditionally.


-//
-// If available, use the EFI memory attribute protocol to obtain
-// the current attributes of the region. If the entire region is
-// covered and the attributes match, we don't have to do anything.
-//
-if (mMemoryAttribute != NULL) {
-  Status = mMemoryAttribute->GetMemoryAttributes (mMemoryAttribute,
-  Memory,
-  Length,
-  
-  );
-  if (!EFI_ERROR (Status) && (OldAttributes == NewAttributes)) {
-return EFI_SUCCESS;
-  }
-}
-  } else if (NewAttributes == 0) {
-// newly added region of a type that does not require protection
-return EFI_SUCCESS;
-  }
-
return gCpu->SetMemoryAttributes (gCpu, Memory, Length, NewAttributes);
  }
--
2.39.1




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99814): https://edk2.groups.io/g/devel/message/99814
Mute This Topic: https://groups.io/mt/96835917/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 2/3] ArmPkg/CpuDxe: Perform preliminary NX remap of free memory

[Taylor Beebe]

On 2/8/2023 10:49 AM, Ard Biesheuvel wrote:

On Wed, 8 Feb 2023 at 19:32, Marvin Häuser  wrote:


Thanks!! :) Comments inline.


On 8. Feb 2023, at 18:58, Ard Biesheuvel  wrote:

The DXE core implementation of PcdDxeNxMemoryProtectionPolicy already
contains an assertion that EfiConventionalMemory and EfiBootServicesData
are subjected to the same policy when it comes to the use of NX
permissions. The reason for this is that we may otherwise end up with
unbounded recursion in the page table code, given that allocating a page
table would then involve a permission attribute change, and this could
result in the need for a block entry to be split, which would trigger
the allocation of a page table recursively.

For the same reason, a shortcut exists in ApplyMemoryProtectionPolicy()
where, instead of setting the memory attributes unconditionally, we
compare the NX policies and avoid touching the page tables if they are
the same for the old and the new memory types. Without this shortcut, we
may end up in a situation where, as the CPU arch protocol DXE driver is
ramping up, the same unbounded recursion is triggered, due to the fact
that the NX policy for EfiConventionalMemory has not been applied yet.

To break this cycle, let's remap all EfiConventionalMemory regions
according to the NX policy for EfiBootServicesData before exposing the
CPU arch protocol to the DXE core and other drivers. This ensures that
creating EfiBootServicesData allocations does not result in memory
attribute changes, and therefore no recursion.

Signed-off-by: Ard Biesheuvel 
---
ArmPkg/Drivers/CpuDxe/CpuDxe.c   | 77 
ArmPkg/Drivers/CpuDxe/CpuDxe.inf |  2 +
2 files changed, 79 insertions(+)

diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.c b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
index d04958e79e52..83fd6fd4e476 100644
--- a/ArmPkg/Drivers/CpuDxe/CpuDxe.c
+++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
@@ -11,6 +11,8 @@

#include 

+#include 
+
BOOLEAN  mIsFlushingGCD;

/**
@@ -227,6 +229,69 @@ InitializeDma (
   CpuArchProtocol->DmaBufferAlignment = ArmCacheWritebackGranule ();
}

+STATIC
+VOID
+RemapUnusedMemoryNx (
+  VOID
+  )
+{


This feels somewhat hacky but it's strictly better than what we have 
right now and a value add so I'm all for this change.



+  UINT64 TestBit;
+  UINTN  MemoryMapSize;
+  UINTN  MapKey;
+  UINTN  DescriptorSize;
+  UINT32 DescriptorVersion;
+  EFI_MEMORY_DESCRIPTOR  *MemoryMap;
+  EFI_MEMORY_DESCRIPTOR  *MemoryMapEntry;
+  EFI_MEMORY_DESCRIPTOR  *MemoryMapEnd;
+  EFI_STATUS Status;
+
+  TestBit = LShiftU64 (1, EfiBootServicesData);
+  if ((PcdGet64 (PcdDxeNxMemoryProtectionPolicy) & TestBit) == 0) {
+return;
+  }
+
+  MemoryMapSize = 0;
+  MemoryMap = NULL;
+
+  Status = gBS->GetMemoryMap (
+  ,
+  MemoryMap,
+  ,
+  ,
+  
+  );
+  ASSERT (Status == EFI_BUFFER_TOO_SMALL);
+  do {
+MemoryMap = (EFI_MEMORY_DESCRIPTOR *)AllocatePool (MemoryMapSize);


nitpick: *If* there is a V2, maybe drop the cast?


+ASSERT (MemoryMap != NULL);


I know ASSERTing for NULL is a common pattern for some reason, but I'd rather 
not have more code with this added.


+Status = gBS->GetMemoryMap (
+,
+MemoryMap,
+,
+,
+
+);


Another nitpick, isn't it common practice to call the Core* functions directly 
within *Core? I know there is code that doesn't, but the former should be more 
efficient.


+if (EFI_ERROR (Status)) {
+  FreePool (MemoryMap);
+}
+  } while (Status == EFI_BUFFER_TOO_SMALL);


Is this guaranteed to terminate? I mean, I get the idea - try again with the 
larger size and when allocating the bigger buffer, its potential new entry will 
already be accounted for. However, I saw downstream code that tried something 
like this (they actually added a constant overhead ahead of time) bounded by 
something like 5 iterations. Might just have been defensive programming - 
probably was -, but it's not trivial to verify, I think, is it?

Regarding the added constant, the spec actually says the following, which 
obviously is just to shortcut a second round of GetMemoryMap(), but still:
"The actual size of the buffer allocated for the consequent call to GetMemoryMap() 
should be bigger then the value returned in MemoryMapSize"

It appears the spec did not define a canonical way to call GetMemoryMap(), did 
it? :(



This is all copy-pasted from MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c


+
+  ASSERT_EFI_ERROR (Status);
+
+  MemoryMapEntry = MemoryMap;
+  MemoryMapEnd   = (EFI_MEMORY_DESCRIPTOR *)((UINT8 *)MemoryMap + 
MemoryMapSize);
+  while ((UINTN)MemoryMapEntry < (UINTN)MemoryMapEnd) {
+if (MemoryMapEntry->Type == EfiConventionalMemory) {
+ 

Re: [edk2-devel] [PATCH 3/3] MdeModulePkg/DxeCore: Unconditionally set memory protections

[Marvin Häuser]

> On 8. Feb 2023, at 19:49, Ard Biesheuvel  wrote:
> 
> This is all copy-pasted from MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c

:(

> 
> The ordering here is a bit tricky. As soon as the CPU arch protocol is
> exposed, every allocation will be remapped individually, resulting in
> page table splits and therefore recursion.

So the issue is the order of event handlers or allocations within the event 
dispatcher? :( Oh lord...

Can we maybe clarify the comment with something like "While 
DxeCore/InitializeDxeNxMemoryProtectionPolicy() would in theory perform this 
task, allocations between the protocol installation and the invocation of its 
event handler may trigger the issue."?

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99812): https://edk2.groups.io/g/devel/message/99812
Mute This Topic: https://groups.io/mt/96835917/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 2/3] ArmPkg/CpuDxe: Perform preliminary NX remap of free memory

[Ard Biesheuvel]

On Wed, 8 Feb 2023 at 19:32, Marvin Häuser  wrote:
>
> Thanks!! :) Comments inline.
>
> > On 8. Feb 2023, at 18:58, Ard Biesheuvel  wrote:
> >
> > The DXE core implementation of PcdDxeNxMemoryProtectionPolicy already
> > contains an assertion that EfiConventionalMemory and EfiBootServicesData
> > are subjected to the same policy when it comes to the use of NX
> > permissions. The reason for this is that we may otherwise end up with
> > unbounded recursion in the page table code, given that allocating a page
> > table would then involve a permission attribute change, and this could
> > result in the need for a block entry to be split, which would trigger
> > the allocation of a page table recursively.
> >
> > For the same reason, a shortcut exists in ApplyMemoryProtectionPolicy()
> > where, instead of setting the memory attributes unconditionally, we
> > compare the NX policies and avoid touching the page tables if they are
> > the same for the old and the new memory types. Without this shortcut, we
> > may end up in a situation where, as the CPU arch protocol DXE driver is
> > ramping up, the same unbounded recursion is triggered, due to the fact
> > that the NX policy for EfiConventionalMemory has not been applied yet.
> >
> > To break this cycle, let's remap all EfiConventionalMemory regions
> > according to the NX policy for EfiBootServicesData before exposing the
> > CPU arch protocol to the DXE core and other drivers. This ensures that
> > creating EfiBootServicesData allocations does not result in memory
> > attribute changes, and therefore no recursion.
> >
> > Signed-off-by: Ard Biesheuvel 
> > ---
> > ArmPkg/Drivers/CpuDxe/CpuDxe.c   | 77 
> > ArmPkg/Drivers/CpuDxe/CpuDxe.inf |  2 +
> > 2 files changed, 79 insertions(+)
> >
> > diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.c b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> > index d04958e79e52..83fd6fd4e476 100644
> > --- a/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> > +++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> > @@ -11,6 +11,8 @@
> >
> > #include 
> >
> > +#include 
> > +
> > BOOLEAN  mIsFlushingGCD;
> >
> > /**
> > @@ -227,6 +229,69 @@ InitializeDma (
> >   CpuArchProtocol->DmaBufferAlignment = ArmCacheWritebackGranule ();
> > }
> >
> > +STATIC
> > +VOID
> > +RemapUnusedMemoryNx (
> > +  VOID
> > +  )
> > +{
> > +  UINT64 TestBit;
> > +  UINTN  MemoryMapSize;
> > +  UINTN  MapKey;
> > +  UINTN  DescriptorSize;
> > +  UINT32 DescriptorVersion;
> > +  EFI_MEMORY_DESCRIPTOR  *MemoryMap;
> > +  EFI_MEMORY_DESCRIPTOR  *MemoryMapEntry;
> > +  EFI_MEMORY_DESCRIPTOR  *MemoryMapEnd;
> > +  EFI_STATUS Status;
> > +
> > +  TestBit = LShiftU64 (1, EfiBootServicesData);
> > +  if ((PcdGet64 (PcdDxeNxMemoryProtectionPolicy) & TestBit) == 0) {
> > +return;
> > +  }
> > +
> > +  MemoryMapSize = 0;
> > +  MemoryMap = NULL;
> > +
> > +  Status = gBS->GetMemoryMap (
> > +  ,
> > +  MemoryMap,
> > +  ,
> > +  ,
> > +  
> > +  );
> > +  ASSERT (Status == EFI_BUFFER_TOO_SMALL);
> > +  do {
> > +MemoryMap = (EFI_MEMORY_DESCRIPTOR *)AllocatePool (MemoryMapSize);
>
> nitpick: *If* there is a V2, maybe drop the cast?
>
> > +ASSERT (MemoryMap != NULL);
>
> I know ASSERTing for NULL is a common pattern for some reason, but I'd rather 
> not have more code with this added.
>
> > +Status = gBS->GetMemoryMap (
> > +,
> > +MemoryMap,
> > +,
> > +,
> > +
> > +);
>
> Another nitpick, isn't it common practice to call the Core* functions 
> directly within *Core? I know there is code that doesn't, but the former 
> should be more efficient.
>
> > +if (EFI_ERROR (Status)) {
> > +  FreePool (MemoryMap);
> > +}
> > +  } while (Status == EFI_BUFFER_TOO_SMALL);
>
> Is this guaranteed to terminate? I mean, I get the idea - try again with the 
> larger size and when allocating the bigger buffer, its potential new entry 
> will already be accounted for. However, I saw downstream code that tried 
> something like this (they actually added a constant overhead ahead of time) 
> bounded by something like 5 iterations. Might just have been defensive 
> programming - probably was -, but it's not trivial to verify, I think, is it?
>
> Regarding the added constant, the spec actually says the following, which 
> obviously is just to shortcut a second round of GetMemoryMap(), but still:
> "The actual size of the buffer allocated for the consequent call to 
> GetMemoryMap() should be bigger then the value returned in MemoryMapSize"
>
> It appears the spec did not define a canonical way to call GetMemoryMap(), 
> did it? :(
>

This is all copy-pasted from MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c

> > +
> > +  ASSERT_EFI_ERROR (Status);
> 

Re: [edk2-devel] [PATCH 2/3] ArmPkg/CpuDxe: Perform preliminary NX remap of free memory

[Marvin Häuser]

Thanks!! :) Comments inline.

> On 8. Feb 2023, at 18:58, Ard Biesheuvel  wrote:
> 
> The DXE core implementation of PcdDxeNxMemoryProtectionPolicy already
> contains an assertion that EfiConventionalMemory and EfiBootServicesData
> are subjected to the same policy when it comes to the use of NX
> permissions. The reason for this is that we may otherwise end up with
> unbounded recursion in the page table code, given that allocating a page
> table would then involve a permission attribute change, and this could
> result in the need for a block entry to be split, which would trigger
> the allocation of a page table recursively.
> 
> For the same reason, a shortcut exists in ApplyMemoryProtectionPolicy()
> where, instead of setting the memory attributes unconditionally, we
> compare the NX policies and avoid touching the page tables if they are
> the same for the old and the new memory types. Without this shortcut, we
> may end up in a situation where, as the CPU arch protocol DXE driver is
> ramping up, the same unbounded recursion is triggered, due to the fact
> that the NX policy for EfiConventionalMemory has not been applied yet.
> 
> To break this cycle, let's remap all EfiConventionalMemory regions
> according to the NX policy for EfiBootServicesData before exposing the
> CPU arch protocol to the DXE core and other drivers. This ensures that
> creating EfiBootServicesData allocations does not result in memory
> attribute changes, and therefore no recursion.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
> ArmPkg/Drivers/CpuDxe/CpuDxe.c   | 77 
> ArmPkg/Drivers/CpuDxe/CpuDxe.inf |  2 +
> 2 files changed, 79 insertions(+)
> 
> diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.c b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> index d04958e79e52..83fd6fd4e476 100644
> --- a/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> +++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> @@ -11,6 +11,8 @@
> 
> #include 
> 
> +#include 
> +
> BOOLEAN  mIsFlushingGCD;
> 
> /**
> @@ -227,6 +229,69 @@ InitializeDma (
>   CpuArchProtocol->DmaBufferAlignment = ArmCacheWritebackGranule ();
> }
> 
> +STATIC
> +VOID
> +RemapUnusedMemoryNx (
> +  VOID
> +  )
> +{
> +  UINT64 TestBit;
> +  UINTN  MemoryMapSize;
> +  UINTN  MapKey;
> +  UINTN  DescriptorSize;
> +  UINT32 DescriptorVersion;
> +  EFI_MEMORY_DESCRIPTOR  *MemoryMap;
> +  EFI_MEMORY_DESCRIPTOR  *MemoryMapEntry;
> +  EFI_MEMORY_DESCRIPTOR  *MemoryMapEnd;
> +  EFI_STATUS Status;
> +
> +  TestBit = LShiftU64 (1, EfiBootServicesData);
> +  if ((PcdGet64 (PcdDxeNxMemoryProtectionPolicy) & TestBit) == 0) {
> +return;
> +  }
> +
> +  MemoryMapSize = 0;
> +  MemoryMap = NULL;
> +
> +  Status = gBS->GetMemoryMap (
> +  ,
> +  MemoryMap,
> +  ,
> +  ,
> +  
> +  );
> +  ASSERT (Status == EFI_BUFFER_TOO_SMALL);
> +  do {
> +MemoryMap = (EFI_MEMORY_DESCRIPTOR *)AllocatePool (MemoryMapSize);

nitpick: *If* there is a V2, maybe drop the cast?

> +ASSERT (MemoryMap != NULL);

I know ASSERTing for NULL is a common pattern for some reason, but I'd rather 
not have more code with this added.

> +Status = gBS->GetMemoryMap (
> +,
> +MemoryMap,
> +,
> +,
> +
> +);

Another nitpick, isn't it common practice to call the Core* functions directly 
within *Core? I know there is code that doesn't, but the former should be more 
efficient.

> +if (EFI_ERROR (Status)) {
> +  FreePool (MemoryMap);
> +}
> +  } while (Status == EFI_BUFFER_TOO_SMALL);

Is this guaranteed to terminate? I mean, I get the idea - try again with the 
larger size and when allocating the bigger buffer, its potential new entry will 
already be accounted for. However, I saw downstream code that tried something 
like this (they actually added a constant overhead ahead of time) bounded by 
something like 5 iterations. Might just have been defensive programming - 
probably was -, but it's not trivial to verify, I think, is it?

Regarding the added constant, the spec actually says the following, which 
obviously is just to shortcut a second round of GetMemoryMap(), but still:
"The actual size of the buffer allocated for the consequent call to 
GetMemoryMap() should be bigger then the value returned in MemoryMapSize"

It appears the spec did not define a canonical way to call GetMemoryMap(), did 
it? :(

> +
> +  ASSERT_EFI_ERROR (Status);
> +
> +  MemoryMapEntry = MemoryMap;
> +  MemoryMapEnd   = (EFI_MEMORY_DESCRIPTOR *)((UINT8 *)MemoryMap + 
> MemoryMapSize);
> +  while ((UINTN)MemoryMapEntry < (UINTN)MemoryMapEnd) {
> +if (MemoryMapEntry->Type == EfiConventionalMemory) {
> +  ArmSetMemoryRegionNoExec (
> +MemoryMapEntry->PhysicalStart,
> +EFI_PAGES_TO_SIZE 

Re: [edk2-devel] [PATCH 3/3] MdeModulePkg/DxeCore: Unconditionally set memory protections

[Ard Biesheuvel]

On Wed, 8 Feb 2023 at 18:58, Ard Biesheuvel  wrote:
>
> Instead of relying on a questionable heuristic that avoids calling into
> the SetMemoryAttributes () DXE service when the old memory type and the
> new one are subjected to the same NX memory protection policy, make this
> call unconditionally. This avoids corner cases where memory region
> attributes are out of sync with the policy, either due to the fact that
> we are in the middle of ramping up the protections, or due to explicit
> invocations of SetMemoryAttributes() by drivers.
>
> This requires the architecture page table code to be able to deal with
> this, in particular, it needs to be robust against potential recursion
> due to NX policies being applied to newly allocated page tables.
>
> Signed-off-by: Ard Biesheuvel 
> ---
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 29 
>  1 file changed, 29 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
> b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> index 36987843f142..503feb72b5d0 100644
> --- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> @@ -1263,9 +1263,7 @@ ApplyMemoryProtectionPolicy (
>IN  UINT64Length
>)
>  {
> -  UINT64  OldAttributes;
>UINT64  NewAttributes;
> -  EFI_STATUS  Status;
>
>//
>// The policy configured in PcdDxeNxMemoryProtectionPolicy
> @@ -1320,32 +1318,5 @@ ApplyMemoryProtectionPolicy (
>//
>NewAttributes = GetPermissionAttributeForMemoryType (NewType);
>
> -  if (OldType != EfiMaxMemoryType) {
> -OldAttributes = GetPermissionAttributeForMemoryType (OldType);
> -if (!mAfterDxeNxMemoryProtectionInit &&
> -(OldAttributes == NewAttributes)) {
> -  return EFI_SUCCESS;
> -}
> -

This removes some code that does not actually exist - apologies.

It comes down to just removing the conditional checks here, though,
and perform the tail call below unconditionally.

> -//
> -// If available, use the EFI memory attribute protocol to obtain
> -// the current attributes of the region. If the entire region is
> -// covered and the attributes match, we don't have to do anything.
> -//
> -if (mMemoryAttribute != NULL) {
> -  Status = mMemoryAttribute->GetMemoryAttributes (mMemoryAttribute,
> -  Memory,
> -  Length,
> -  
> -  );
> -  if (!EFI_ERROR (Status) && (OldAttributes == NewAttributes)) {
> -return EFI_SUCCESS;
> -  }
> -}
> -  } else if (NewAttributes == 0) {
> -// newly added region of a type that does not require protection
> -return EFI_SUCCESS;
> -  }
> -
>return gCpu->SetMemoryAttributes (gCpu, Memory, Length, NewAttributes);
>  }
> --
> 2.39.1
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99809): https://edk2.groups.io/g/devel/message/99809
Mute This Topic: https://groups.io/mt/96835917/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 05/20] UefiCpuPkg: Add CpuTimerDxe module

[Sunil V L]

On Wed, Feb 08, 2023 at 06:02:44PM +, Kinney, Michael D wrote:
> Hi Sunil,
> 
> One comment on the name of this module.  CpuTimerDxe is a very generic name, 
> but the
> Implementation is for RISCV only and depends on SBL services.  Correct?
> 
> If I look at other TimerDxe modules, they have in their name some indication 
> of 
> the timer hardware/software dependencies in their name,
> 
> * LocalApicTimerDxe.inf
> * HpetTimerDxe.inf
> 
> How about RiscVTimerDxe or RiscVSbiTimerLib?
> 
> Mike
> 
Thanks!, Mike. Your suggestion makes sense. Since most of the drivers in
UefiCpuPkg were named as Cpu*, I named it like this. Let me change it to
RiscVTimerDxe.

Thanks!
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99808): https://edk2.groups.io/g/devel/message/99808
Mute This Topic: https://groups.io/mt/96593498/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 05/20] UefiCpuPkg: Add CpuTimerDxe module

[Michael D Kinney]

Hi Sunil,

One comment on the name of this module.  CpuTimerDxe is a very generic name, 
but the
Implementation is for RISCV only and depends on SBL services.  Correct?

If I look at other TimerDxe modules, they have in their name some indication of 
the timer hardware/software dependencies in their name,

* LocalApicTimerDxe.inf
* HpetTimerDxe.inf

How about RiscVTimerDxe or RiscVSbiTimerLib?

Mike


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Sunil V L
> Sent: Saturday, January 28, 2023 11:18 AM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar, 
> Rahul R ; Daniel Schaefer
> ; Gerd Hoffmann ; Abner Chang 
> 
> Subject: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 05/20] 
> UefiCpuPkg: Add CpuTimerDxe module
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> 
> This DXE module initializes the timer interrupt handler
> and installs the Arch Timer protocol.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Daniel Schaefer 
> Cc: Gerd Hoffmann 
> Signed-off-by: Sunil V L 
> Acked-by: Abner Chang 
> ---
>  UefiCpuPkg/UefiCpuPkg.dsc|   3 +
>  UefiCpuPkg/CpuTimerDxe/CpuTimerDxe.inf   |  51 
>  UefiCpuPkg/CpuTimerDxe/RiscV64/Timer.h   | 177 
>  UefiCpuPkg/CpuTimerDxe/RiscV64/Timer.c   | 294 
>  UefiCpuPkg/CpuTimerDxe/CpuTimer.uni  |  14 +
>  UefiCpuPkg/CpuTimerDxe/CpuTimerExtra.uni |  12 +
>  6 files changed, 551 insertions(+)
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
> index f9a46089d2c7..96f6770281fe 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dsc
> +++ b/UefiCpuPkg/UefiCpuPkg.dsc
> @@ -195,5 +195,8 @@ [Components.IA32, Components.X64]
>  [Components.X64]
>
> UefiCpuPkg/Library/CpuExceptionHandlerLib/UnitTest/DxeCpuExceptionHandlerLibUnitTest.inf
> 
> +[Components.RISCV64]
> +  UefiCpuPkg/CpuTimerDxe/CpuTimerDxe.inf
> +
>  [BuildOptions]
>*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
> diff --git a/UefiCpuPkg/CpuTimerDxe/CpuTimerDxe.inf 
> b/UefiCpuPkg/CpuTimerDxe/CpuTimerDxe.inf
> new file mode 100644
> index ..d7706328b591
> --- /dev/null
> +++ b/UefiCpuPkg/CpuTimerDxe/CpuTimerDxe.inf
> @@ -0,0 +1,51 @@
> +## @file
> +# Timer Arch protocol module
> +#
> +# Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +#
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x0001001b
> +  BASE_NAME  = CpuTimerDxe
> +  MODULE_UNI_FILE= CpuTimer.uni
> +  FILE_GUID  = 055DDAC6-9142-4013-BF20-FC2E5BC325C9
> +  MODULE_TYPE= DXE_DRIVER
> +  VERSION_STRING = 1.0
> +  ENTRY_POINT= TimerDriverInitialize
> +#
> +# The following information is for reference only and not required by the 
> build
> +# tools.
> +#
> +#  VALID_ARCHITECTURES   = RISCV64
> +#
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  UefiCpuPkg/UefiCpuPkg.dec
> +
> +[LibraryClasses]
> +  BaseLib
> +  DebugLib
> +  IoLib
> +  CpuLib
> +  UefiBootServicesTableLib
> +  UefiDriverEntryPoint
> +
> +[LibraryClasses.RISCV64]
> +  RiscVSbiLib
> +
> +[Sources.RISCV64]
> +  RiscV64/Timer.h
> +  RiscV64/Timer.c
> +
> +[Protocols]
> +  gEfiCpuArchProtocolGuid   ## CONSUMES
> +  gEfiTimerArchProtocolGuid ## PRODUCES
> +
> +[Depex]
> +  gEfiCpuArchProtocolGuid
> +
> +[UserExtensions.TianoCore."ExtraFiles"]
> +  CpuTimerExtra.uni
> diff --git a/UefiCpuPkg/CpuTimerDxe/RiscV64/Timer.h 
> b/UefiCpuPkg/CpuTimerDxe/RiscV64/Timer.h
> new file mode 100644
> index ..586eb0cfadb4
> --- /dev/null
> +++ b/UefiCpuPkg/CpuTimerDxe/RiscV64/Timer.h
> @@ -0,0 +1,177 @@
> +/** @file
> +  RISC-V Timer Architectural Protocol definitions
> +
> +  Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef TIMER_H_
> +#define TIMER_H_
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +//
> +// RISC-V use 100us timer.
> +// The default timer tick duration is set to 10 ms = 10 * 1000 * 10 100 ns 
> units
> +//
> +#define DEFAULT_TIMER_TICK_DURATION  10
> +
> +extern VOID
> +RiscvSetTimerPeriod (
> +  UINT32  TimerPeriod
> +  );
> +
> +//
> +// Function Prototypes
> +//
> +
> +/**
> +  Initialize the Timer Architectural Protocol driver
> +
> +  @param ImageHandle ImageHandle of the loaded driver
> +  @param SystemTable Pointer to the System Table
> +
> +  @retval EFI_SUCCESSTimer Architectural Protocol created
> +  @retval EFI_OUT_OF_RESOURCES   Not enough resources available to 
> initialize driver.
> +  @retval EFI_DEVICE_ERROR   A device error occured attempting to 
> initialize the driver.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +TimerDriverInitialize (
> +  IN EFI_HANDLEImageHandle,
> +  IN 

Re: [edk2-devel] [PATCH 1/1] MdePkg: Add DDR5 SPD defs to IndustryStandard per JESD400-5A.01

[Rebecca Cran]

+Liming at his correct email address.

Sorry, I used the email address from the DDR4 commit back in 2016.

On 2/8/23 10:47, Rebecca Cran wrote:

Copying the style of SdramSpdDdr4.h, add DDR5 SPD definitions to
SpdDdr5.h per JEDEC JESD400-5A.01 specification
(https://www.jedec.org/standards-documents/docs/jesd400-5a01).

Signed-off-by: Rebecca Cran 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Zhiguang Liu 
---
  MdePkg/Include/IndustryStandard/SpdDdr5.h | 541 
  1 file changed, 541 insertions(+)

diff --git a/MdePkg/Include/IndustryStandard/SpdDdr5.h 
b/MdePkg/Include/IndustryStandard/SpdDdr5.h
new file mode 100644
index ..305ab69af852
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/SpdDdr5.h
@@ -0,0 +1,541 @@
+/** @file
+  This file contains definitions for DDR5 SPD.
+
+  Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
+  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Revision Reference:
+- DDR5 Serial Presence Detect (SPD), Document Release 1.1 (Jan 2023)
+  https://www.jedec.org/standards-documents/docs/jesd400-5a01
+**/
+
+#ifndef SPD_DDR5_H_
+#define SPD_DDR5_H_
+
+#include 
+
+#pragma pack (push, 1)
+
+typedef union {
+  struct {
+UINT8BetaLevel3_0 :  4;///< Bits 3:0
+UINT8BytesTotal   :  3;///< Bits 6:4
+UINT8BetaLevel4   :  1;///< Bits 7:7
+  } Bits;
+  UINT8Data;
+} SPD5_DEVICE_DESCRIPTION_STRUCT;
+
+typedef union {
+  struct {
+UINT8Minor :  4;   ///< Bits 3:0
+UINT8Major :  4;   ///< Bits 7:4
+  } Bits;
+  UINT8Data;
+} SPD5_REVISION_STRUCT;
+
+typedef union {
+  struct {
+UINT8Type :  8;///< Bits 7:0
+  } Bits;
+  UINT8Data;
+} SPD5_DEVICE_TYPE_STRUCT;
+
+typedef union {
+  struct {
+UINT8ModuleType  :  4; ///< Bits 3:0
+UINT8HybridMedia :  3; ///< Bits 6:4
+UINT8Hybrid  :  1; ///< Bits 7:7
+  } Bits;
+  UINT8Data;
+} SPD5_MODULE_TYPE_STRUCT;
+
+typedef union {
+  struct {
+UINT8Density :  5; ///< Bits 4:0
+UINT8Die :  3; ///< Bits 7:5
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_DENSITY_PACKAGE_STRUCT;
+
+typedef union {
+  struct {
+UINT8RowAddress:  5;   ///< Bits 4:0
+UINT8ColumnAddress :  3;   ///< Bits 7:5
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_ADDRESSING_STRUCT;
+
+typedef union {
+  struct {
+UINT8Reserved : 5; ///< Bits 4:0
+UINT8IoWidth  : 3; ///< Bits 7:5
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_IO_WIDTH_STRUCT;
+
+typedef union {
+  struct {
+UINT8BanksPerBankGroup : 3;///< Bits 2:0
+UINT8Reserved  : 2;///< Bits 4:3
+UINT8BankGroups: 3;///< Bits 7:5
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_BANKS_STRUCT;
+
+typedef union {
+  struct {
+UINT8Reserved0   : 1;  ///< Bits 0:0
+UINT8Mbist_mPpr  : 1;  ///< Bits 1:1
+UINT8Reserved1   : 2;  ///< Bits 3:2
+UINT8BL32: 1;  ///< Bits 4:4
+UINT8SPprUndo_Lock   : 1;  ///< Bits 5:5
+UINT8Reserved2   : 1;  ///< Bits 6:6
+UINT8SPprGranularity : 1;  ///< Bits 7:7
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_BL32_POST_PACKAGE_REPAIR_STRUCT;
+
+typedef union {
+  struct {
+UINT8DcaTypesSupported : 2;///< Bits 1:0
+UINT8Reserved0 : 2;///< Bits 3:2
+UINT8Pasr  : 1;///< Bits 4:4
+UINT8Reserved1 : 3;///< Bits 7:5
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_DCA_AND_PASR_STRUCT;
+
+typedef union {
+  struct {
+UINT8BoundedFault: 1;  ///< Bits 0:0
+UINT8x4RmwEcsWbSuppressionMrSelector : 1;  ///< Bits 1:1
+UINT8x4RmwEcsWriteBackSuppresion : 1;  ///< Bits 2:2
+UINT8WideTemperatureSense: 1;  ///< Bits 3:3
+UINT8Reserved: 4;  ///< Bits 7:4
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_FAULT_HANDLING_TEMP_SENSE_STRUCT;
+
+typedef union {
+  struct {
+UINT8Endurant:  2; ///< Bits 1:0
+UINT8Operational :  2; ///< Bits 3:2
+UINT8Nominal :  4; ///< Bits 7:4
+  } Bits;
+  UINT8Data;
+} SPD5_MODULE_NOMINAL_VOLTAGE_STRUCT;
+
+typedef 

[edk2-devel] [PATCH 1/1] OvmfPkg: Update build.sh to allow building OVMF then running QEMU

[Rebecca Cran]

Allow users to build OVMF then run QEMU by moving the build block above
the run block and removing the exit line.

Signed-off-by: Rebecca Cran 
Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
---
 OvmfPkg/build.sh | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
index 91b1442ade6b..b0334fb76e74 100755
--- a/OvmfPkg/build.sh
+++ b/OvmfPkg/build.sh
@@ -245,6 +245,11 @@ else
   echo using prebuilt tools
 fi
 
+#
+# Build the edk2 OvmfPkg
+#
+echo Running edk2 build for OvmfPkg$Processor
+build -p $PLATFORMFILE $BUILD_OPTIONS -b $BUILDTARGET -t $TARGET_TOOLS -n 
$THREADNUMBER -DDEBUG_ON_SERIAL_PORT=TRUE
 
 if [[ "$RUN_QEMU" == "yes" ]]; then
   if [[ ! -d $QEMU_FIRMWARE_DIR ]]; then
@@ -260,11 +265,3 @@ if [[ "$RUN_QEMU" == "yes" ]]; then
   $QEMU_COMMAND "$@"
   exit $?
 fi
-
-#
-# Build the edk2 OvmfPkg
-#
-echo Running edk2 build for OvmfPkg$Processor
-build -p $PLATFORMFILE $BUILD_OPTIONS -b $BUILDTARGET -t $TARGET_TOOLS -n 
$THREADNUMBER
-exit $?
-
-- 
2.30.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99805): https://edk2.groups.io/g/devel/message/99805
Mute This Topic: https://groups.io/mt/96836052/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 3/3] MdeModulePkg/DxeCore: Unconditionally set memory protections

[Ard Biesheuvel]

Instead of relying on a questionable heuristic that avoids calling into
the SetMemoryAttributes () DXE service when the old memory type and the
new one are subjected to the same NX memory protection policy, make this
call unconditionally. This avoids corner cases where memory region
attributes are out of sync with the policy, either due to the fact that
we are in the middle of ramping up the protections, or due to explicit
invocations of SetMemoryAttributes() by drivers.

This requires the architecture page table code to be able to deal with
this, in particular, it needs to be robust against potential recursion
due to NX policies being applied to newly allocated page tables.

Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 29 
 1 file changed, 29 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
index 36987843f142..503feb72b5d0 100644
--- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
+++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
@@ -1263,9 +1263,7 @@ ApplyMemoryProtectionPolicy (
   IN  UINT64Length
   )
 {
-  UINT64  OldAttributes;
   UINT64  NewAttributes;
-  EFI_STATUS  Status;
 
   //
   // The policy configured in PcdDxeNxMemoryProtectionPolicy
@@ -1320,32 +1318,5 @@ ApplyMemoryProtectionPolicy (
   //
   NewAttributes = GetPermissionAttributeForMemoryType (NewType);
 
-  if (OldType != EfiMaxMemoryType) {
-OldAttributes = GetPermissionAttributeForMemoryType (OldType);
-if (!mAfterDxeNxMemoryProtectionInit &&
-(OldAttributes == NewAttributes)) {
-  return EFI_SUCCESS;
-}
-
-//
-// If available, use the EFI memory attribute protocol to obtain
-// the current attributes of the region. If the entire region is
-// covered and the attributes match, we don't have to do anything.
-//
-if (mMemoryAttribute != NULL) {
-  Status = mMemoryAttribute->GetMemoryAttributes (mMemoryAttribute,
-  Memory,
-  Length,
-  
-  );
-  if (!EFI_ERROR (Status) && (OldAttributes == NewAttributes)) {
-return EFI_SUCCESS;
-  }
-}
-  } else if (NewAttributes == 0) {
-// newly added region of a type that does not require protection
-return EFI_SUCCESS;
-  }
-
   return gCpu->SetMemoryAttributes (gCpu, Memory, Length, NewAttributes);
 }
-- 
2.39.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99804): https://edk2.groups.io/g/devel/message/99804
Mute This Topic: https://groups.io/mt/96835917/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 2/3] ArmPkg/CpuDxe: Perform preliminary NX remap of free memory

[Ard Biesheuvel]

The DXE core implementation of PcdDxeNxMemoryProtectionPolicy already
contains an assertion that EfiConventionalMemory and EfiBootServicesData
are subjected to the same policy when it comes to the use of NX
permissions. The reason for this is that we may otherwise end up with
unbounded recursion in the page table code, given that allocating a page
table would then involve a permission attribute change, and this could
result in the need for a block entry to be split, which would trigger
the allocation of a page table recursively.

For the same reason, a shortcut exists in ApplyMemoryProtectionPolicy()
where, instead of setting the memory attributes unconditionally, we
compare the NX policies and avoid touching the page tables if they are
the same for the old and the new memory types. Without this shortcut, we
may end up in a situation where, as the CPU arch protocol DXE driver is
ramping up, the same unbounded recursion is triggered, due to the fact
that the NX policy for EfiConventionalMemory has not been applied yet.

To break this cycle, let's remap all EfiConventionalMemory regions
according to the NX policy for EfiBootServicesData before exposing the
CPU arch protocol to the DXE core and other drivers. This ensures that
creating EfiBootServicesData allocations does not result in memory
attribute changes, and therefore no recursion.

Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Drivers/CpuDxe/CpuDxe.c   | 77 
 ArmPkg/Drivers/CpuDxe/CpuDxe.inf |  2 +
 2 files changed, 79 insertions(+)

diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.c b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
index d04958e79e52..83fd6fd4e476 100644
--- a/ArmPkg/Drivers/CpuDxe/CpuDxe.c
+++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
@@ -11,6 +11,8 @@
 
 #include 
 
+#include 
+
 BOOLEAN  mIsFlushingGCD;
 
 /**
@@ -227,6 +229,69 @@ InitializeDma (
   CpuArchProtocol->DmaBufferAlignment = ArmCacheWritebackGranule ();
 }
 
+STATIC
+VOID
+RemapUnusedMemoryNx (
+  VOID
+  )
+{
+  UINT64 TestBit;
+  UINTN  MemoryMapSize;
+  UINTN  MapKey;
+  UINTN  DescriptorSize;
+  UINT32 DescriptorVersion;
+  EFI_MEMORY_DESCRIPTOR  *MemoryMap;
+  EFI_MEMORY_DESCRIPTOR  *MemoryMapEntry;
+  EFI_MEMORY_DESCRIPTOR  *MemoryMapEnd;
+  EFI_STATUS Status;
+
+  TestBit = LShiftU64 (1, EfiBootServicesData);
+  if ((PcdGet64 (PcdDxeNxMemoryProtectionPolicy) & TestBit) == 0) {
+return;
+  }
+
+  MemoryMapSize = 0;
+  MemoryMap = NULL;
+
+  Status = gBS->GetMemoryMap (
+  ,
+  MemoryMap,
+  ,
+  ,
+  
+  );
+  ASSERT (Status == EFI_BUFFER_TOO_SMALL);
+  do {
+MemoryMap = (EFI_MEMORY_DESCRIPTOR *)AllocatePool (MemoryMapSize);
+ASSERT (MemoryMap != NULL);
+Status = gBS->GetMemoryMap (
+,
+MemoryMap,
+,
+,
+
+);
+if (EFI_ERROR (Status)) {
+  FreePool (MemoryMap);
+}
+  } while (Status == EFI_BUFFER_TOO_SMALL);
+
+  ASSERT_EFI_ERROR (Status);
+
+  MemoryMapEntry = MemoryMap;
+  MemoryMapEnd   = (EFI_MEMORY_DESCRIPTOR *)((UINT8 *)MemoryMap + 
MemoryMapSize);
+  while ((UINTN)MemoryMapEntry < (UINTN)MemoryMapEnd) {
+if (MemoryMapEntry->Type == EfiConventionalMemory) {
+  ArmSetMemoryRegionNoExec (
+MemoryMapEntry->PhysicalStart,
+EFI_PAGES_TO_SIZE (MemoryMapEntry->NumberOfPages)
+);
+}
+
+MemoryMapEntry = NEXT_MEMORY_DESCRIPTOR (MemoryMapEntry, DescriptorSize);
+  }
+}
+
 EFI_STATUS
 CpuDxeInitialize (
   IN EFI_HANDLEImageHandle,
@@ -240,6 +305,18 @@ CpuDxeInitialize (
 
   InitializeDma ();
 
+  //
+  // Once we install the CPU arch protocol, the DXE core's memory
+  // protection routines will invoke them to manage the permissions of page
+  // allocations as they are created. Given that this includes pages
+  // allocated for page tables by this driver, we must ensure that unused
+  // memory is mapped with the same permissions as boot services data
+  // regions. Otherwise, we may end up with unbounded recursion, due to the
+  // fact that updating permissions on a newly allocated page table may trigger
+  // a block entry split, which triggers a page table allocation, etc etc
+  //
+  RemapUnusedMemoryNx ();
+
   Status = gBS->InstallMultipleProtocolInterfaces (
   ,
   ,
diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.inf b/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
index e732e21cb94a..8fd0f4133088 100644
--- a/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
+++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
@@ -48,6 +48,7 @@ [LibraryClasses]
   DefaultExceptionHandlerLib
   DxeServicesTableLib
   HobLib
+  MemoryAllocationLib
   PeCoffGetEntryPointLib
   UefiDriverEntryPoint
   UefiLib
@@ -64,6 +65,7 @@ [Guids]
 
 [Pcd.common]
   gArmTokenSpaceGuid.PcdVFPEnabled
+  

[edk2-devel] [PATCH 0/3] Apply NX protections more strictly

[Ard Biesheuvel]

This fixes an issue reported by Marvin, where NX memory protections are
applied in a rather unreliable manner, resulting in the possibility that
memory mappings may exist that are using different attributes than
intended.

The reason for this approach was that applying memory protections
eagerly (i.e., after every alloc/free even if the memory attributes are
not expected to change as a result) may result in unbounded recursion in
the page table code, due to the fact that the page tables it allocates
need to be remapped with the correct attributes as well.

This has not been reported as being an issue on x86, but on ARM, this
needs a couple of fixes so that converting between EfiConventionalMemory
and EfiBootServicesData will never trigger a block entry split. With
that fixed, we can just remove the shortcut from DXE core and always
call SetMemoryAttributes.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3316

Cc: Michael Kinney 
Cc: Liming Gao 
Cc: Jiewen Yao 
Cc: Michael Kubacki 
Cc: Sean Brogan 
Cc: Rebecca Cran 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Taylor Beebe 
Cc: Marvin Häuser 

Ard Biesheuvel (3):
  ArmPkg/ArmMmuLib: Avoid splitting block entries if possible
  ArmPkg/CpuDxe: Perform preliminary NX remap of free memory
  MdeModulePkg/DxeCore: Unconditionally set memory protections

 ArmPkg/Drivers/CpuDxe/CpuDxe.c   | 77 
 ArmPkg/Drivers/CpuDxe/CpuDxe.inf |  2 +
 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c |  9 +++
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c| 29 
 4 files changed, 88 insertions(+), 29 deletions(-)

-- 
2.39.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99801): https://edk2.groups.io/g/devel/message/99801
Mute This Topic: https://groups.io/mt/96835912/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/3] ArmPkg/ArmMmuLib: Avoid splitting block entries if possible

[Ard Biesheuvel]

Currently, the AArch64 MMU page table logic will break down any block
entry that overlaps with the region being mapped, even if the block
entry in question is using the same attributes as the new region.

This means that creating a non-executable mapping inside a region that
is already mapped non-executable at a coarser granularity may trigger a
call to AllocatePages (), which may recurse back into the page table
code to update the attributes on the newly allocated page tables.

Let's avoid this, by preserving the block entry if it already covers the
region being mapped with the correct attributes.

Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c 
b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
index 1cf8dc090012..28191938aeb1 100644
--- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
+++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
@@ -251,6 +251,15 @@ UpdateRegionMappingRecursive (
   ASSERT (Level < 3);
 
   if (!IsTableEntry (*Entry, Level)) {
+//
+// If the region we are trying to map is already covered by a block
+// entry with the right attributes, don't bother splitting it up.
+//
+if (IsBlockEntry (*Entry, Level) &&
+((*Entry & TT_ATTRIBUTES_MASK & ~AttributeClearMask) == 
AttributeSetMask)) {
+  continue;
+}
+
 //
 // No table entry exists yet, so we need to allocate a page table
 // for the next level.
-- 
2.39.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99802): https://edk2.groups.io/g/devel/message/99802
Mute This Topic: https://groups.io/mt/96835913/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/1] MdePkg: Add DDR5 SPD defs to IndustryStandard per JESD400-5A.01

[Rebecca Cran]

Copying the style of SdramSpdDdr4.h, add DDR5 SPD definitions to
SpdDdr5.h per JEDEC JESD400-5A.01 specification
(https://www.jedec.org/standards-documents/docs/jesd400-5a01).

Signed-off-by: Rebecca Cran 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Zhiguang Liu 
---
 MdePkg/Include/IndustryStandard/SpdDdr5.h | 541 
 1 file changed, 541 insertions(+)

diff --git a/MdePkg/Include/IndustryStandard/SpdDdr5.h 
b/MdePkg/Include/IndustryStandard/SpdDdr5.h
new file mode 100644
index ..305ab69af852
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/SpdDdr5.h
@@ -0,0 +1,541 @@
+/** @file
+  This file contains definitions for DDR5 SPD.
+
+  Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
+  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Revision Reference:
+- DDR5 Serial Presence Detect (SPD), Document Release 1.1 (Jan 2023)
+  https://www.jedec.org/standards-documents/docs/jesd400-5a01
+**/
+
+#ifndef SPD_DDR5_H_
+#define SPD_DDR5_H_
+
+#include 
+
+#pragma pack (push, 1)
+
+typedef union {
+  struct {
+UINT8BetaLevel3_0 :  4;///< Bits 3:0
+UINT8BytesTotal   :  3;///< Bits 6:4
+UINT8BetaLevel4   :  1;///< Bits 7:7
+  } Bits;
+  UINT8Data;
+} SPD5_DEVICE_DESCRIPTION_STRUCT;
+
+typedef union {
+  struct {
+UINT8Minor :  4;   ///< Bits 3:0
+UINT8Major :  4;   ///< Bits 7:4
+  } Bits;
+  UINT8Data;
+} SPD5_REVISION_STRUCT;
+
+typedef union {
+  struct {
+UINT8Type :  8;///< Bits 7:0
+  } Bits;
+  UINT8Data;
+} SPD5_DEVICE_TYPE_STRUCT;
+
+typedef union {
+  struct {
+UINT8ModuleType  :  4; ///< Bits 3:0
+UINT8HybridMedia :  3; ///< Bits 6:4
+UINT8Hybrid  :  1; ///< Bits 7:7
+  } Bits;
+  UINT8Data;
+} SPD5_MODULE_TYPE_STRUCT;
+
+typedef union {
+  struct {
+UINT8Density :  5; ///< Bits 4:0
+UINT8Die :  3; ///< Bits 7:5
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_DENSITY_PACKAGE_STRUCT;
+
+typedef union {
+  struct {
+UINT8RowAddress:  5;   ///< Bits 4:0
+UINT8ColumnAddress :  3;   ///< Bits 7:5
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_ADDRESSING_STRUCT;
+
+typedef union {
+  struct {
+UINT8Reserved : 5; ///< Bits 4:0
+UINT8IoWidth  : 3; ///< Bits 7:5
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_IO_WIDTH_STRUCT;
+
+typedef union {
+  struct {
+UINT8BanksPerBankGroup : 3;///< Bits 2:0
+UINT8Reserved  : 2;///< Bits 4:3
+UINT8BankGroups: 3;///< Bits 7:5
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_BANKS_STRUCT;
+
+typedef union {
+  struct {
+UINT8Reserved0   : 1;  ///< Bits 0:0
+UINT8Mbist_mPpr  : 1;  ///< Bits 1:1
+UINT8Reserved1   : 2;  ///< Bits 3:2
+UINT8BL32: 1;  ///< Bits 4:4
+UINT8SPprUndo_Lock   : 1;  ///< Bits 5:5
+UINT8Reserved2   : 1;  ///< Bits 6:6
+UINT8SPprGranularity : 1;  ///< Bits 7:7
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_BL32_POST_PACKAGE_REPAIR_STRUCT;
+
+typedef union {
+  struct {
+UINT8DcaTypesSupported : 2;///< Bits 1:0
+UINT8Reserved0 : 2;///< Bits 3:2
+UINT8Pasr  : 1;///< Bits 4:4
+UINT8Reserved1 : 3;///< Bits 7:5
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_DCA_AND_PASR_STRUCT;
+
+typedef union {
+  struct {
+UINT8BoundedFault: 1;  ///< Bits 0:0
+UINT8x4RmwEcsWbSuppressionMrSelector : 1;  ///< Bits 1:1
+UINT8x4RmwEcsWriteBackSuppresion : 1;  ///< Bits 2:2
+UINT8WideTemperatureSense: 1;  ///< Bits 3:3
+UINT8Reserved: 4;  ///< Bits 7:4
+  } Bits;
+  UINT8Data;
+} SPD5_SDRAM_FAULT_HANDLING_TEMP_SENSE_STRUCT;
+
+typedef union {
+  struct {
+UINT8Endurant:  2; ///< Bits 1:0
+UINT8Operational :  2; ///< Bits 3:2
+UINT8Nominal :  4; ///< Bits 7:4
+  } Bits;
+  UINT8Data;
+} SPD5_MODULE_NOMINAL_VOLTAGE_STRUCT;
+
+typedef union {
+  struct {
+UINT8NonStandardCoreTimings :  1;  ///< Bits 0:0
+UINT8Reserved   :  7;  

[edk2-devel] [PATCH V2 RESEND] RedfishPkg: RedfishRestExDxe: Two PCDs for controlling the requests

[Igor Kulchytskyy via groups.io]

Since BIOS should work with different BMC implementation
chunked requests as well as Expect header should be optional.
One PCD is used to enable/disable Expect header.
Another PCD is used to enable/disable chunked requests.

Cc: Abner Chang 
Cc: Nickle Wang 
Signed-off-by: Igor Kulchytskyy 
---
 RedfishPkg/RedfishPkg.dec   |  10 ++
 RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf|   2 +
 RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c |  23 ++--
 RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c | 140 
 4 files changed, 113 insertions(+), 62 deletions(-)

diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
index d2b189b..89ef32a 100644
--- a/RedfishPkg/RedfishPkg.dec
+++ b/RedfishPkg/RedfishPkg.dec
@@ -97,3 +97,13 @@
   # protocol instance.
   #
   
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDiscoverAccessModeInBand|FALSE|BOOLEAN|0x1002
+  #
+  # This PCD indicates if the EFI REST EX sends chunk request to Redfish 
service.
+  # Default is set to non chunk mode.
+  #
+  
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExChunkRequestMode|TRUE|BOOLEAN|0x1003
+  #
+  # This PCD indicates if the EFI REST EX adds Expect header to the POST, 
PATCH, PUT requests to Redfish service.
+  # Default is set to not add.
+  #
+  
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExAddingExpect|FALSE|BOOLEAN|0x1004
diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf 
b/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
index 75437b0..29003ae 100644
--- a/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
+++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
@@ -57,6 +57,8 @@

 [Pcd]
   gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExServiceAccessModeInBand   ## 
CONSUMES
+  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExChunkRequestMode   ## CONSUMES
+  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishRestExAddingExpect   ## CONSUMES

 [UserExtensions.TianoCore."ExtraFiles"]
   RedfishRestExDxeExtra.uni
diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c 
b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
index 952e9d1..0da0d10 100644
--- a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
+++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
@@ -140,9 +140,6 @@ RedfishHttpAddExpectation (
   }

   *ItsWrite = FALSE;
-  if (PreservedRequestHeaders != NULL) {
-*PreservedRequestHeaders = RequestMessage->Headers;
-  }

   if ((RequestMessage->Data.Request->Method != HttpMethodPut) && 
(RequestMessage->Data.Request->Method != HttpMethodPost) &&
   (RequestMessage->Data.Request->Method != HttpMethodPatch))
@@ -152,10 +149,20 @@ RedfishHttpAddExpectation (

   *ItsWrite = TRUE;

-  NewHeaders = AllocateZeroPool ((RequestMessage->HeaderCount + 1) * sizeof 
(EFI_HTTP_HEADER));
-  CopyMem ((VOID *)NewHeaders, (VOID *)RequestMessage->Headers, 
RequestMessage->HeaderCount * sizeof (EFI_HTTP_HEADER));
-  HttpSetFieldNameAndValue (NewHeaders + RequestMessage->HeaderCount, 
HTTP_HEADER_EXPECT, HTTP_EXPECT_100_CONTINUE);
-  RequestMessage->HeaderCount++;
-  RequestMessage->Headers = NewHeaders;
+  //
+  // Check PCD before adding Expect header
+  //
+  if(FixedPcdGetBool(PcdRedfishRestExAddingExpect)) {
+if (PreservedRequestHeaders != NULL) {
+  *PreservedRequestHeaders = RequestMessage->Headers;
+}
+
+NewHeaders = AllocateZeroPool ((RequestMessage->HeaderCount + 1) * sizeof 
(EFI_HTTP_HEADER));
+CopyMem ((VOID *)NewHeaders, (VOID *)RequestMessage->Headers, 
RequestMessage->HeaderCount * sizeof (EFI_HTTP_HEADER));
+HttpSetFieldNameAndValue (NewHeaders + RequestMessage->HeaderCount, 
HTTP_HEADER_EXPECT, HTTP_EXPECT_100_CONTINUE);
+RequestMessage->HeaderCount++;
+RequestMessage->Headers = NewHeaders;
+  }
+
   return EFI_SUCCESS;
 }
diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c 
b/RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c
index 4b61fc0..fbd5e46 100644
--- a/RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c
+++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExProtocol.c
@@ -66,11 +66,13 @@ RedfishRestExSendReceive (
   HTTP_IO_SEND_NON_CHUNK_PROCESS  SendNonChunkProcess;
   EFI_HTTP_MESSAGEChunkTransferRequestMessage;

-  Status   = EFI_SUCCESS;
-  ResponseData = NULL;
-  IsGetChunkedTransfer = FALSE;
-  SendChunkProcess = HttpIoSendChunkNone;
-  SendNonChunkProcess  = HttpIoSendNonChunkNone;
+  Status= EFI_SUCCESS;
+  ResponseData  = NULL;
+  IsGetChunkedTransfer  = FALSE;
+  SendChunkProcess  = HttpIoSendChunkNone;
+  SendNonChunkProcess   = HttpIoSendNonChunkNone;
+  ItsWrite  = FALSE;
+  PreservedRequestHeaders   = NULL;

   //
   // Validate the parameters
@@ -94,67 +96,85 @@ RedfishRestExSendReceive (
   DEBUG ((DEBUG_INFO, "\nRedfishRestExSendReceive():\n"));
   DEBUG ((DEBUG_INFO, "*** Perform HTTP Request Method - %d, URL: %s\n", 
RequestMessage->Data.Request->Method, 

Re: [edk2-devel] [PATCH 4/5] UefiPayloadPkg: Add CpuPageTableLib required by MpInitLib

[Guo Dong]

Reviewed-by: Guo Dong 

-Original Message-
From: Xie, Yuanhao  
Sent: Tuesday, February 7, 2023 6:50 AM
To: devel@edk2.groups.io
Cc: Dong, Guo ; Ni, Ray ; Rhodes, Sean 
; Lu, James ; Guo, Gua 

Subject: [PATCH 4/5] UefiPayloadPkg: Add CpuPageTableLib required by MpInitLib

Add CpuPageTableLib required by MpInitLib in UefiPayloadPkg.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: Yuanhao Xie 
---
 UefiPayloadPkg/UefiPayloadPkg.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc 
b/UefiPayloadPkg/UefiPayloadPkg.dsc
index 2dbd875f37..a1a3c74290 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -340,6 +340,7 @@
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+  CpuPageTableLib|UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableLib.inf
   MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
 !if $(PERFORMANCE_MEASUREMENT_ENABLE)
   PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
-- 
2.36.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99798): https://edk2.groups.io/g/devel/message/99798
Mute This Topic: https://groups.io/mt/96807125/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH v4 00/12] Ext4Pkg: Code correctness and security improvements

[Pedro Falcato]

With some minor fixups[1], for the series:

Reviewed-by: Pedro Falcato 

and pushed to edk2-platforms HEAD.

Thanks,

Pedro

[1] Fixed up some commit messages to be imperative, added my Rb, fixed
a status return in Extents.c for ("Ext4Pkg: Correct integer overflow
check logic in DiskUtil"), and removed a comment wrt ("Ext4Pkg: Add
inode number validity check"); you misinterpreted what I told you
off-list, I meant that we shouldn't judge what operating systems put
as inodes as long as it doesn't jeopardize the driver and it's
correctness - so doing > 0 is good, banning 1 for no reason is not -
this doesn't mean we're going to start using inode 1 any time soon.

On Thu, Feb 2, 2023 at 10:21 AM Savva Mitrofanov  wrote:
>
> Hi all,
>
> In v4 I rebased patches according upstream. Also in this revision I corrected
> all remarks and comments from v3.
>
> This patchset fixes several code problems found by fuzzing Ext4Dxe like
> buffer and integer overflows, memory leaks, logic bugs and so on.
>
> REF: https://github.com/savvamitrofanov/edk2-platforms/tree/master
>
> Cc: Marvin Häuser 
> Cc: Pedro Falcato 
> Cc: Vitaly Cheptsov 
>
> Savva Mitrofanov (12):
>   Ext4Pkg: Fix memory leak in Ext4RetrieveDirent
>   Ext4Pkg: Fix incorrect checksum metadata feature check
>   Ext4Pkg: Fix division by zero by adding check for s_inodes_per_group
>   Ext4Pkg: Add inode number validity check
>   Ext4Pkg: Fix shift out of bounds in Ext4OpenSuperblock
>   Ext4Pkg: Corrects integer overflow check logic in DiskUtil
>   Ext4Pkg: Check that source file is directory in Ext4OpenInternal
>   Ext4Pkg: Check VolumeName allocation correctness in Ext4GetVolumeName
>   Ext4Pkg: Add missing exit Status in Ext4OpenDirent
>   Ext4Pkg: Fixes build on MSVC
>   Ext4Pkg: Filter out directory entry names containing \0 as invalid
>   Ext4Pkg: Corrects memory leak in Ext4ReadSlowSymlink
>
>  Features/Ext4Pkg/Ext4Pkg.dsc  |  2 +-
>  Features/Ext4Pkg/Ext4Dxe/Ext4Disk.h   | 13 +-
>  Features/Ext4Pkg/Ext4Dxe/Ext4Dxe.h| 26 
>  Features/Ext4Pkg/Ext4Dxe/BlockGroup.c |  5 +++
>  Features/Ext4Pkg/Ext4Dxe/Directory.c  | 42 
>  Features/Ext4Pkg/Ext4Dxe/DiskUtil.c   | 18 +++--
>  Features/Ext4Pkg/Ext4Dxe/Extents.c| 15 +--
>  Features/Ext4Pkg/Ext4Dxe/File.c   | 23 ---
>  Features/Ext4Pkg/Ext4Dxe/Inode.c  |  6 +--
>  Features/Ext4Pkg/Ext4Dxe/Superblock.c | 16 ++--
>  Features/Ext4Pkg/Ext4Dxe/Symlink.c| 13 +++---
>  11 files changed, 134 insertions(+), 45 deletions(-)
>
> --
> 2.39.1
>


-- 
Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99797): https://edk2.groups.io/g/devel/message/99797
Mute This Topic: https://groups.io/mt/96697364/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC] [staging/CryptoLibrary] Openssl1.1 replacement proposal

[Gerd Hoffmann]

  Hi,

> 3. If 1 or 2 can success, we can replace openssl 1.1 with one crypto lib.
> If both 1 and 2 fail, we may use *dual-crypto module*. For example: mbedtls 
> for PEI and openssl3.0 for DXE.
> The source code size will become larger, more time to download the tree.

Suggestions how to do that best, ideally without duplicating CryptoPkg
for that?

A while back I've tried to add openssl-3 in parallel to openssl-11,
with the idea to allow projects picking the one or the other, and quicky
ran into problems because apparently libraries can't add include
directories.  Only packages can do that (see Includes.Common.Private in
CryptoPkg/CryptoPkg.dec which adds Library/OpensslLib/openssl/include).

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99796): https://edk2.groups.io/g/devel/message/99796
Mute This Topic: https://groups.io/mt/96741156/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 2/5] UefiCpuPkg: Contiguous memory allocation and code clean-up.

[Gerd Hoffmann]

> +  AllocSize = EFI_PAGES_TO_SIZE (
> +EFI_SIZE_TO_PAGES (
> +  CpuMpData->CpuCount * AP_SAFE_STACK_SIZE + ApLoopFuncSize
> +  )
> +);
> +  Status = gBS->AllocatePages (
> +  AllocateMaxAddress,
> +  EfiReservedMemoryType,
> +  EFI_SIZE_TO_PAGES (AllocSize),
> +  
> +  );

Hmm?  You convert size to pages, pages to size, size to pages again.

Also you don't want stack and code being on the same page, so I guess
the logic you actually need is this:

StackPages = EFI_SIZE_TO_PAGES(CpuMpData->CpuCount * AP_SAFE_STACK_SIZE);
FuncPages  = EFI_SIZE_TO_PAGES(ApLoopFuncSize)
gBS->AllocatePages(..., StackPages + FuncPages, ...);

> +//
> +// Union holds the relocate APs loop entries for different cases
> +//
> +typedef union {
> +  VOID  *Data;
> +  ASM_RELOCATE_AP_LOOP_AMD64Amd64Entry;   // 64-bit AMD Processor
> +  ASM_RELOCATE_AP_LOOP  GenericEntry; // Intel Processor (32-bit or 
> 64-bit), or 32-bit AMD Processor
> +} RELOCATE_AP_LOOP_ENTRY;

I'm sure I've mentioned this before.  The special case you have to
handle is not running on a AMD Processor, but AmdSev being active
(i.e. UseSevEsAPMethod == True).  Otherwise it should be just standard
Ia32 and X64, there should be no need to check whenever you are running
on a AMD processor.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99795): https://edk2.groups.io/g/devel/message/99795
Mute This Topic: https://groups.io/mt/96807120/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 3/5] OvmfPkg: Add CpuPageTableLib required by MpInitLib.

[Gerd Hoffmann]

On Tue, Feb 07, 2023 at 09:49:37PM +0800, Yuanhao Xie wrote:
> Add CpuPageTableLib required by MpInitLib in OvmfPkg.
> 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Gerd Hoffmann 
> Signed-off-by: Yuanhao Xie 

Acked-by: Gerd Hoffmann 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99794): https://edk2.groups.io/g/devel/message/99794
Mute This Topic: https://groups.io/mt/96807123/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 2/5] UefiCpuPkg: Contiguous memory allocation and code clean-up.

[Yuanhao Xie]

Hi Marvin,

Thanks for the feedbacks.
The corrected implementation is in patch 5.
The stacks are located high and the function is located low. With padding, it 
ensures page alignment.
I'll resend the patch to make sure the changes are included in patch 2.

Best Regards,
Yuanhao


From: Marvin Häuser 
Sent: Wednesday, February 8, 2023 12:41 AM
To: Xie, Yuanhao ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH 2/5] UefiCpuPkg: Contiguous memory allocation 
and code clean-up.

Hi Yuanhao,

1) The code comments and copy code suggest that the stacks are located low and 
the function is located high (good). However, the SetMemorySpaceAttributes() 
call un-XP's Address, which is the low address. So, do I misunderstand the 
changes, or are you un-XP'ing the first stack (and keep the function XP'd)?

2) The same SetMemorySpaceAttributes() call, you now pass ApLoopFuncSize over 
ApSafeBufferSize. The latter was explicitly page-aligned, while the former is 
not. How is it guaranteed it is indeed aligned? If it is not, I don't think 
this is supported, at least universally.

3) Similar to 2), the stack size is much smaller than the page size, no? How do 
you guarantee the function is on a page boundary for memory protection?

4) A proper W^X flow should be to wait with un-XP till the CopyMem() for the 
function code has returned. Right before that, the copied code should be marked 
read-only.

Best regards,
Marvin


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99793): https://edk2.groups.io/g/devel/message/99793
Mute This Topic: https://groups.io/mt/96807120/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Graphic Output on qemu

[Michael Brown]

On 08/02/2023 09:55, Alireza Banejad wrote:
As my previous email, I mentioned that I am able to find the protocol 
since the LocateProtocol returns 0 (EFI_SUCCESS) (using the exact code 
you wrote) . But when I want to open it either with OpenProtocol or 
HandleProtocol I get a RETURN_UNSUPPORTED. Are you implying that by 
calling LocateProtocol() the protocol would also be opened?


LocateProtocol() gives you back a pointer to the protocol instance. 
There is no need for a separate "open" action: you can just immediately 
use the protocol instance that LocateProtocol() returns to you.


Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99792): https://edk2.groups.io/g/devel/message/99792
Mute This Topic: https://groups.io/mt/96810830/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Graphic Output on qemu

[Alireza Banejad]

As my previous email, I mentioned that I am able to find the protocol since
the LocateProtocol returns 0 (EFI_SUCCESS) (using the exact code you wrote)
. But when I want to open it either with OpenProtocol or HandleProtocol I
get a RETURN_UNSUPPORTED. Are you implying that by calling LocateProtocol()
the protocol would also be opened? or do I still need to open it? if I
still need to open then I am still getting the UNSUPPORTED Status.
But if I don't need to open it I still don't know why I am not able to use
the GOP methods.
one example of the many examples which I get this error is as below:


Status = gBS->HandleProtocol (SystemTable->ConsoleOutHandle,
, (VOID **));
  if (EFI_ERROR (Status)) {
Status = gBS->LocateProtocol (, NULL,
(VOID **));
if (EFI_ERROR (Status)) {
  Print (L"Error: Could not find a GOP instance!\n");
  Status = EFI_NOT_FOUND;
  goto Done;
}
  }
Blt = NULL;
  ImageWidth  = 0;
  ImageHeight = 0;
  Status  =  TranslateBmpToGopBlt (
   BmpFileData,
   BmpFileSize,
   ,
   ,
   ,
   
   );
It is worth mentioning that the BmpFIleData and BmpFileSize are valid
variables with the proper data stored. Anyways, the status code for the
TranslateBmpToGopBlt returns a RETURN_UNSUPPORTED. This is the same with
other GOP methods

On Wed, Feb 8, 2023 at 12:36 PM Michael Brown  wrote:

> On 08/02/2023 08:03, Alireza Banejad wrote:
> > Below is how I use the HandleProtocol function:
> >
> >Status = gBS->HandleProtocol (
> >gST->ConsoleOutHandle,
> >,
> >(VOID **)
> >);
>
> You are querying only the ConsoleOutHandle, which is not necessarily
> where the GOP will be installed.
>
> Use LocateProtocol() to find the protocol instance instead:
>
>
>Status = gBS->LocateProtocol(, NULL,
> (VOID **));
>
> HTH,
>
> Michael
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99791): https://edk2.groups.io/g/devel/message/99791
Mute This Topic: https://groups.io/mt/96810830/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Graphic Output on qemu

[Michael Brown]

On 08/02/2023 08:03, Alireza Banejad wrote:

Below is how I use the HandleProtocol function:

   Status = gBS->HandleProtocol (
                   gST->ConsoleOutHandle,
                   ,
                   (VOID **)
                   );


You are querying only the ConsoleOutHandle, which is not necessarily 
where the GOP will be installed.


Use LocateProtocol() to find the protocol instance instead:


  Status = gBS->LocateProtocol(, NULL,
   (VOID **));

HTH,

Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99790): https://edk2.groups.io/g/devel/message/99790
Mute This Topic: https://groups.io/mt/96810830/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Graphic Output on qemu

[Alireza Banejad]

Hi Bill,

Yes, I have the graphics window with the logo showing and I see the setup
menu.
In fact, I have designed a HII form with my specific applications. The
problem is that it just uses the SimpleTextOutput. It doesn't use the GOP
or UgaDraw libraries.
Plus, I am able to locate the protocol and it returns the status code of 0.
the actual issue happens with the HandleProtocol Function.
After I compile my code with the debug macros enabled, the status code for
HandleProtocol() function is RETURN_UNSUPPORTED (Both for UgaDraw and GOP)
and if I were to use the GOP or UgaDraw methods, my application would
simply crash.
Below is how I use the HandleProtocol function:

  Status = gBS->HandleProtocol (
  gST->ConsoleOutHandle,
  ,
  (VOID **)
  );

Last but not least, whether using the virtio-gpu I get the same result.
Based on what I mentioned above, since I find the protocol but I'm not able
to open it, I concluded there might be something wrong with my qemu
settings.

On Tue, Feb 7, 2023, 23:25 Paul, Bill  wrote:

> Of all the gin joints in all the towns in all the world, Alireza Banejad
> had
> to walk into mine at 02:22:32 on Tuesday, 7 February 2023 and say:
>
> > Do not click links or open attachments unless you recognize the sender
> and
> > know the content is safe. Hello everyone,
> > I am trying to use the GOP library for my uefi development. But no matter
> > what code whenever i want to open the GOP handle RETURN_UNSUPPORTED is
> > returned. I think this may be a qemu problem as if it doesn't support the
> > GOP at all. This is how I run my qemu
> >
> > qemu-system-x86_64 -bios $FIRMWARE -hda fat:rw:$DRIVE -global
> > isa-debugcon.iobase=0x402  -net none -debugcon file:debug2.log  -machine
> > pc-q35-6.2 -device virtio-gpu
> >
> > Should I add any specific options for the qemu command or should I just
> use
> > another lib for GOP on qemu?
>
> One question: when you launch QEMU, do you actually see a graphics window
> pop
> up with the Tianocore logo? If you press F2 as it launches, are you able
> to
> enter the setup menu?
>
> I'm trying to understand if QEMU/OVMF's graphics display is working all
> all.
> If it is, then in theory the GOP support should work.
>
> If I may suggest, omit the -device virtio-gpu option. In my experience,
> the
> OVMF firmware for Intel works with the QEMU built-in emulated VGA display
> device. With the code I've written in the past, calling
> BS->LocateProtocol()
> with the GOP GUID returns a valid handle. Once you have that, you should
> be
> able to use the GOP methods, e.g. GOP->Blt().
>
> -Bill
>
> --
>
> =
> -Bill Paul(510) 749-2329 | VxWorks Software Architect,
>  wp...@windriver.com | Master of Unix-Fu - Wind River
> Systems
>
> =
>"I put a dollar in a change machine. Nothing changed." - George Carlin
>
> =
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99789): https://edk2.groups.io/g/devel/message/99789
Mute This Topic: https://groups.io/mt/96810830/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-