Re: [edk2-devel] [edk2 1/1] RISCV: clean up exception handling

[Sunil V L]

Hi Andrei,

Happy to see this patch!

On Fri, Feb 17, 2023 at 10:28:09PM -0600, Andrei Warkentin wrote:
> RegisterCpuInterruptHandler did not allow setting
> exception handlers for anything beyond the timer IRQ.
> Beyond that, it didn't meet the spec around handling
> of inputs.
> 
> RiscVSupervisorModeTrapHandler now will invoke
> set handlers for both exceptions and interrupts.
> Two arrays of handlers are maintained - one for exceptions
> and one for interrupts.
> 
> For unhandled traps, RiscVSupervisorModeTrapHandler dumps
> state using the now implemented DumpCpuContext.
> 
> For EFI_SYSTEM_CONTEXT_RISCV64, extend this with the trapped
> PC address (SEPC), just like on AArch64 (ELR). This is
> necessary for X86EmulatorPkg to work as it allows a trap
> handler to return execution to a different place. Add
> SSTATUS/STVAL as well, at least for debugging purposes. There
> is no value in hiding this.
> 
> Fix nested exception handling. Handler code should not
> be saving SIE (the value is saved in SSTATUS.SPIE) or
> directly restored (that's done by SRET). Save and
> restore the entire SSTATUS and STVAL, too.
> 
> Cc: Sunil V L 
> Cc: Daniel Schaefer 
> Signed-off-by: Andrei Warkentin 
> ---
>  MdePkg/Include/Protocol/DebugSupport.h   
>  |  23 ++-
>  
> UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandlerLib.h 
> |  11 +-
>  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
>  |   3 +-
>  
> UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandlerLib.c 
> | 215 +---
>  UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/SupervisorTrapHandler.S 
>  |  17 +-
>  5 files changed, 225 insertions(+), 44 deletions(-)
> 
> diff --git a/MdePkg/Include/Protocol/DebugSupport.h 
> b/MdePkg/Include/Protocol/DebugSupport.h
> index 2b0ae2d1577b..0d94c409448c 100644
> --- a/MdePkg/Include/Protocol/DebugSupport.h
> +++ b/MdePkg/Include/Protocol/DebugSupport.h
> @@ -613,11 +613,25 @@ typedef struct {
>  #define EXCEPT_RISCV_STORE_AMO_ACCESS_FAULT7
>  #define EXCEPT_RISCV_ENV_CALL_FROM_UMODE   8
>  #define EXCEPT_RISCV_ENV_CALL_FROM_SMODE   9
> -#define EXCEPT_RISCV_ENV_CALL_FROM_HMODE   10
> +#define EXCEPT_RISCV_1010

Why do we need this change? mExceptionNameStr has a string. Also, should
we name these with exact words from the spec like VSMODE?

>  #define EXCEPT_RISCV_ENV_CALL_FROM_MMODE   11
> +#define EXCEPT_RISCV_INST_ACCESS_PAGE_FAULT12
> +#define EXCEPT_RISCV_LOAD_ACCESS_PAGE_FAULT13
> +#define EXCEPT_RISCV_STORE_ACCESS_PAGE_FAULT   14

Shouldn't this be 15?

> +#define EXCEPT_RISCV_MAX_EXCEPTIONS
> (EXCEPT_RISCV_STORE_ACCESS_PAGE_FAULT)
>  
> -#define EXCEPT_RISCV_SOFTWARE_INT  0x0
> -#define EXCEPT_RISCV_TIMER_INT 0x1
> +///
> +/// RISC-V processor exception types for interrupts.
> +///
> +#define EXCEPT_RISCV_IS_IRQ(x) ((x & 
> 0x8000UL) != 0)
> +#define EXCEPT_RISCV_IRQ_INDEX(x)  (x & 0x7FFFUL)

Please run uncrustify.

> +#define EXCEPT_RISCV_IRQ_0 0x8000UL
> +#define EXCEPT_RISCV_IRQ_SOFT_FROM_SMODE   0x8001UL
> +#define EXCEPT_RISCV_IRQ_2 0x8002UL
> +#define EXCEPT_RISCV_IRQ_SOFT_FROM_MMODE   0x8003UL
> +#define EXCEPT_RISCV_IRQ_4 0x8004UL
> +#define EXCEPT_RISCV_IRQ_TIMER_FROM_SMODE  0x8005UL
> +#define EXCEPT_RISCV_MAX_IRQS  
> (EXCEPT_RISCV_IRQ_INDEX(EXCEPT_RISCV_IRQ_TIMER_FROM_SMODE))
>  
>  typedef struct {
>UINT64X0;
> @@ -652,6 +666,9 @@ typedef struct {
>UINT64X29;
>UINT64X30;
>UINT64X31;
> +  UINT64SEPC;
> +  UINT32SSTATUS;
> +  UINT32STVAL;
>  } EFI_SYSTEM_CONTEXT_RISCV64;
>  
>  //
> diff --git 
> a/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandlerLib.h
>  
> b/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandlerLib.h
> index 30f47e87552b..9b7e1304dd3b 100644
> --- 
> a/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandlerLib.h
> +++ 
> b/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandlerLib.h
> @@ -59,7 +59,7 @@ SupervisorModeTrap (
>  #define SMODE_TRAP_REGS_t6   31
>  #define SMODE_TRAP_REGS_sepc 32
>  #define SMODE_TRAP_REGS_sstatus  33
> -#define SMODE_TRAP_REGS_sie  34
> +#define SMODE_TRAP_REGS_stval34
>  #define SMODE_TRAP_REGS_last 35
>  
>  #define SMODE_TRAP_REGS_OFFSET(x)  ((SMODE_TRAP_REGS_##x) * 
> __SIZEOF_POINTER__)
> @@ -68,7 +68,7 @@ SupervisorModeTrap (
>  #pragma pack(1)
>  typedef struct {
>//
> -  // Below are follow the format of EFI_SYSTEM_CONTEXT
> +  // Below follow the format of EFI_SYSTEM_CONTEXT.
>//
>UINT64zero;
>UINT64ra;
> @@ -102,1

Re: [edk2-devel] [edk2 1/1] RiscV64 Timer: fix tick duration accounting

[Sunil V L]

Hi Andrei,

Thank you very much for fixing this!

On Fri, Feb 17, 2023 at 10:31:49PM -0600, Andrei Warkentin wrote:
> The TimerDxe implementation doesn't account for the physical
> time passed due to timer handler execution or (perhaps even
> more importantly) time spent with interrupts masked.
> 
> Other implementations (e.g. like the Arm one) do. If the
> timer tick is always incremented at a fixed rate, then
> you can slow down UEFI's perception of time by running
> long sections of code in a critical section.
> 
> Cc: Sunil V L 
> Cc: Daniel Schaefer 
> Signed-off-by: Andrei Warkentin 
> ---
>  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 31 
>  1 file changed, 18 insertions(+), 13 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c 
> b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
> index 0ecefddf1f18..f65c64c296cd 100644
> --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
> +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
> @@ -41,6 +41,7 @@ STATIC EFI_TIMER_NOTIFY  mTimerNotifyFunction;
>  // The current period of the timer interrupt
>  //
>  STATIC UINT64  mTimerPeriod = 0;
> +STATIC UINT64  mLastPeriodStart = 0;
>  
>  /**
>Timer Interrupt Handler.
> @@ -55,26 +56,32 @@ TimerInterruptHandler (
>IN EFI_SYSTEM_CONTEXT  SystemContext
>)
>  {
> -  EFI_TPL  OriginalTPL;
> -  UINT64   RiscvTimer;
> +  EFI_TPL OriginalTPL;
> +  UINT64  PeriodStart = RiscVReadTimer ();
>  
>OriginalTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL);
>if (mTimerNotifyFunction != NULL) {
> -mTimerNotifyFunction (mTimerPeriod);
> +//
> +// For any number of reasons, the ticks could be coming
> +// in slower than mTimerPeriod. For example, some code
> +// is doing a *lot* of stuff inside an EFI_TPL_HIGH
> +// critical section, and this should not cause the EFI
> +// time to increment slower. So when we take an interrupt,
> +// account for the actual time passed.
> +//
> +mTimerNotifyFunction (PeriodStart - mLastPeriodStart);

Shouldn't we consider debug case like ARM does?

Also, looks like there are some uncrustify errors. Please run manually
and fix them.

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-Formatting#manual-usage---generate-file-list-via-stdin

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100401): https://edk2.groups.io/g/devel/message/100401
Mute This Topic: https://groups.io/mt/97044196/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 V8 00/19] Add support for RISC-V virt machine

[Heinrich Schuchardt]

On 2/17/23 10:16, Michael Brown wrote:

On 17/02/2023 04:27, Sunil V L wrote:

On Thu, Feb 16, 2023 at 03:45:49PM -0700, dann frazier wrote:

   Thanks for your work getting this merged! In the above wiki, it
notes that GCC 12+ is not supported. Is that still accurate? If so,
can you clarify what is blocking that?


Please see https://bugzilla.tianocore.org/show_bug.cgi?id=4061.

My attempt to fix this issue
(https://edk2.groups.io/g/devel/message/93831) was not accepted due to
the concerns that it can cause weird issues in CI.

So, we are left with either support gcc <12 or gcc >=12. We can mandate
gcc 12 itself for RISC-V, but that change need to be done hand in hand
with CI tests moving to use gcc 12. Otherwise, it will break CI.


Is there an alternative (and presumably less ideal) way to force an 
instruction cache invalidation?  For example, does a global TSO "fence" 
instruction as used in RiscVInvalidateDataCacheAsm() also invalidate the 
instruction cache?


If so, then a viable solution would be:

--- a/MdePkg/Library/BaseLib/RiscV64/FlushCache.S
+++ b/MdePkg/Library/BaseLib/RiscV64/FlushCache.S
@@ -15,3 +15,7 @@ ASM_GLOBAL ASM_PFX(RiscVInvalidateDataCacheAsm)
  ASM_PFX(RiscVInvalidateInstCacheAsm):
-    fence.i
+#ifdef __riscv_zifencei
+   fence.i
+#else
+   fence
+#endif
  ret


This would also permit EDK2 to be used on implementations that genuinely 
do not provide the fence.i instruction.


Michael



fence.i is the right instruction to use. The problem are not platforms 
that do not provide the fence.i instruction but that the fence.i 
instruction was removed from RVGC64 in the specification.


Now all programs like OpenSBI, U-Boot, Linux have to be compiled with 
different -march parameters for GCC11 and GCC12.


Sunil suggested dropping support for GCC < 12. This seems to be the 
easiest approach. An alternative would be adding a GCC12 profile to 
BaseTools/Conf/tools_def.template but that would create a high effort.


Best regards

Heinrich


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

[edk2-devel] PciBus scan: Does it support scan from EndBusNum to StartBusNum?

[Yoshinoya]

Hi
Usually PciBus scan is from low bus num to high bus num.


So, does it support scan from end bus num to start bus num?


Thanks

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

回复: [edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, February 21, 2023 #cal-reminder

[gaoliming via groups.io]

There is no new issue. The meeting will be cancelled. 

 

Thanks

Liming

发件人: devel@edk2.groups.io  代表 Group Notification
发送时间: 2023年2月21日 10:30
收件人: devel@edk2.groups.io
主题: [edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, February 
21, 2023 #cal-reminder

 

Reminder: TianoCore Bug Triage - APAC / NAMO 

When:
Tuesday, February 21, 2023
6:30pm to 7:30pm
(UTC-08:00) America/Los Angeles 

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d
 

Organizer: Liming Gao gaolim...@byosoft.com.cn 

  

View Event  

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 


 

Microsoft Teams meeting 

Join on your computer or mobile app 

 

 Click here to join the meeting 

Join with a video conferencing device 

te...@conf.intel.com   

Video Conference ID: 116 062 094 0 

 

 Alternate VTC dialing instructions 

Or call in (audio only) 

  +1 916-245-6934,,77463821#   United States, 
Sacramento 

Phone Conference ID: 774 638 21# 

 

 Find a local number |   Reset 
PIN 

  Learn More |  

 Meeting options 





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

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

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

Hi Tinh,

Our last RNDIS driver’s code has add that.
To see 
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/control-channel-characteristics,
It need to read the Interrupt IN endpoint before response the RNDIS message.

The host does not continuously poll the USB Control endpoint for input control 
messages. Upon placing a control message
on its Control endpoint, the device must return a notification on the 
Communication Class interface's Interrupt IN endpoint,
which is polled by the host whenever the device can return control messages. 
The transfer from the device's interrupt IN endpoint
to the host is a standard USB Interrupt IN transfer. The only defined device 
notification is the RESPONSE_AVAILABLE notification,
defined in the following table.



Thanks,
Richard

From: Tinh Nguyen OS 
Sent: 2023年2月21日 10:24 AM
To: devel@edk2.groups.io; Richard Ho (何明忠) 
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v4 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 18/02/2023 16:47, RichardHo [何明忠] via groups.io wrote:



+  PrintRndisMsg (RndisMsg);

+

+  Status = UsbIo->UsbControlTransfer (

+UsbIo,

+&DevReq,

+EfiUsbDataOut,

+USB_ETHERNET_TRANSFER_TIMEOUT,

+RndisMsg,

+RndisMsg->MessageLength,

+&UsbStatus

+);

+

+  DEBUG ((DEBUG_INFO, "RndisControlMsg: UsbStatus : %x Status : %r 
RndisMsgResponse : %lx\n", UsbStatus, Status, RndisMsgResponse));

+

+  // Error or no response expected

+  if ((EFI_ERROR (Status)) || (RndisMsgResponse == NULL)) {

+DEBUG ((DEBUG_INFO, "RndisControlMsg: UsbStatus : %x Status : %r\n", 
UsbStatus, Status));

+return Status;

+  }

+

+  for (Index = 0; Index < (RNDIS_CONTROL_TIMEOUT/100); Index++) {

+ReadRndisResponseInterrupt (UsbRndisDevice);

Could you help review the ReadRndisResponseInterrupt function? (). While using 
USB Rndis, the Jade platform crashes.

I found that AMI had published the same driver here 
OSF-Aptio-OpenEdition/UsbRndisFunction.c at main · 
opencomputeproject/OSF-Aptio-OpenEdition 
(github.com),

however the RndisControlMsg function does not call ReadRndisResponseInterrupt.

Jade platform (aarch64) works well with this 
(OSF-Aptio-OpenEdition/UsbRndisFunction.c at main · 
opencomputeproject/OSF-Aptio-OpenEdition 
(github.com)).
 Does your x86 system work without this line ?

+ZeroMem (&DevReq, sizeof (EFI_USB_DEVICE_REQUEST));

+

+DevReq.RequestType = USB_ENDPOINT_DIR_IN | USB_REQ_TYPE_CLASS | 
USB_TARGET_INTERFACE;

+DevReq.Request = GET_ENCAPSULATED_RESPONSE;

-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 (#100397): https://edk2.groups.io/g/devel/message/100397
Mute This Top

[edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, February 21, 2023 #cal-reminder

[Group Notification]

*Reminder: TianoCore Bug Triage - APAC / NAMO*

*When:*
Tuesday, February 21, 2023
6:30pm to 7:30pm
(UTC-08:00) America/Los Angeles

*Where:*
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d

*Organizer:* Liming Gao gaolim...@byosoft.com.cn ( 
gaolim...@byosoft.com.cn?subject=Re:%20Event:%20TianoCore%20Bug%20Triage%20-%20APAC%20%2F%20NAMO
 )

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=1753754 )

*Description:*

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao



Microsoft Teams meeting

*Join on your computer or mobile app*

Click here to join the meeting ( 
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d
 )

*Join with a video conferencing device*

te...@conf.intel.com

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions ( 
https://conf.intel.com/teams/?conf=1160620940&ivr=teams&d=conf.intel.com&test=test_call
 )

*Or call in (audio only)*

+1 916-245-6934,,77463821# ( tel:+19162456934,,77463821# ) United States, 
Sacramento

Phone Conference ID: 774 638 21#

Find a local number ( 
https://dialin.teams.microsoft.com/d195d438-2daa-420e-b9ea-da26f9d1d6d5?id=77463821
 ) | Reset PIN ( https://mysettings.lync.com/pstnconferencing )

Learn More ( https://aka.ms/JoinTeamsMeeting ) | Meeting options ( 
https://teams.microsoft.com/meetingOptions/?organizerId=b286b53a-1218-4db3-bfc9-3d4c5aa7669e&tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh@thread.v2&messageId=0&language=en-US
 )


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

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

[Tinh Nguyen via groups.io]

On 18/02/2023 16:47, RichardHo [何明忠] via groups.io wrote:


+  PrintRndisMsg (RndisMsg);
+
+  Status = UsbIo->UsbControlTransfer (
+UsbIo,
+&DevReq,
+EfiUsbDataOut,
+USB_ETHERNET_TRANSFER_TIMEOUT,
+RndisMsg,
+RndisMsg->MessageLength,
+&UsbStatus
+);
+
+  DEBUG ((DEBUG_INFO, "RndisControlMsg: UsbStatus : %x Status : %r 
RndisMsgResponse : %lx\n", UsbStatus, Status, RndisMsgResponse));
+
+  // Error or no response expected
+  if ((EFI_ERROR (Status)) || (RndisMsgResponse == NULL)) {
+DEBUG ((DEBUG_INFO, "RndisControlMsg: UsbStatus : %x Status : %r\n", 
UsbStatus, Status));
+return Status;
+  }
+
+  for (Index = 0; Index < (RNDIS_CONTROL_TIMEOUT/100); Index++) {
+ReadRndisResponseInterrupt (UsbRndisDevice);

Could you help review the ReadRndisResponseInterrupt function? (). While using 
USB Rndis, the Jade platform crashes.

I found that AMI had published the same driver here 
OSF-Aptio-OpenEdition/UsbRndisFunction.c at main · 
opencomputeproject/OSF-Aptio-OpenEdition 
(github.com),

however the RndisControlMsg function does not call ReadRndisResponseInterrupt.

Jade platform (aarch64) works well with this 
(OSF-Aptio-OpenEdition/UsbRndisFunction.c at main · 
opencomputeproject/OSF-Aptio-OpenEdition 
(github.com)).
 Does your x86 system work without this line ?

+ZeroMem (&DevReq, sizeof (EFI_USB_DEVICE_REQUEST));
+
+DevReq.RequestType = USB_ENDPOINT_DIR_IN | USB_REQ_TYPE_CLASS | 
USB_TARGET_INTERFACE;
+DevReq.Request = GET_ENCAPSULATED_RESPONSE;



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100395): https://edk2.groups.io/g/devel/message/100395
Mute This Topic: https://groups.io/mt/97046156/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] MdePkg: Remove whitespace in doxygen param passing direction [in,out]

[Rebecca Cran]

On 2/20/23 18:58, Tinh Nguyen OS wrote:

On 2/21/2023 1:45 AM, Rebecca Cran via groups.io wrote:

There isn't supposed to be whitespace for "@param [in,out]" between "in"
and "out". clang generates the following warning:

test.c:8:9: warning: whitespace is not allowed in parameter passing direction 
[-Wdocumentation-pedantic]
   @param [in, out] argv Array of arguments.
  ^
  [in,out]

Update the documentation blocks in MdePkg.

Signed-off-by: Rebecca Cran 
---


Hi Rebecca,

It is just a personal question, not relevant to patch review, which tool
do you use?

I used Visual Studio Code to do the search/replace.

--
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100394): https://edk2.groups.io/g/devel/message/100394
Mute This Topic: https://groups.io/mt/97092666/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] MdePkg: Remove whitespace in doxygen param passing direction [in,out]

[Tinh Nguyen via groups.io]

On 2/21/2023 1:45 AM, Rebecca Cran via groups.io wrote:
> There isn't supposed to be whitespace for "@param [in,out]" between "in"
> and "out". clang generates the following warning:
>
> test.c:8:9: warning: whitespace is not allowed in parameter passing direction 
> [-Wdocumentation-pedantic]
>   @param [in, out] argv Array of arguments.
>  ^
>  [in,out]
>
> Update the documentation blocks in MdePkg.
>
> Signed-off-by: Rebecca Cran 
> ---
>
Hi Rebecca,

It is just a personal question, not relevant to patch review, which tool 
do you use?

Thanks,

Tinh



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

[edk2-devel] [PATCH EDK2 v1 0/1] MdeModulePkg/VariablePolicyLib: Remove status checking

[wenyi,xie via groups.io]

Main Changes :
1.Removing status checking as the status is always EFI_SUCCESS.

Wenyi Xie (1):
  MdeModulePkg/VariablePolicyLib: Remove status checking

 MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

-- 
2.20.1.windows.1



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

[edk2-devel] [PATCH EDK2 v1 1/1] MdeModulePkg/VariablePolicyLib: Remove status checking

[wenyi,xie via groups.io]

Removing status checking as the status is always EFI_SUCCESS.
No functional change.

Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Hao A Wu 
Signed-off-by: Wenyi Xie 
---
 MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.c 
b/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.c
index 82dae67ef50f..fbc192c6ab26 100644
--- a/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.c
+++ b/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.c
@@ -782,9 +782,7 @@ InitVariablePolicyLib (
 return EFI_ALREADY_STARTED;
   }
 
-  if (!EFI_ERROR (Status)) {
-Status = VariablePolicyExtraInit ();
-  }
+  Status = VariablePolicyExtraInit ();
 
   if (!EFI_ERROR (Status)) {
 // Save an internal pointer to the GetVariableHelper.
@@ -841,9 +839,7 @@ DeinitVariablePolicyLib (
 return EFI_NOT_READY;
   }
 
-  if (!EFI_ERROR (Status)) {
-Status = VariablePolicyExtraDeinit ();
-  }
+  Status = VariablePolicyExtraDeinit ();
 
   if (!EFI_ERROR (Status)) {
 mGetVariableHelper  = NULL;
-- 
2.20.1.windows.1



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

[edk2-devel] [PATCH edk2-platforms 2/2] Silicon/Qemu: Use the symbolic value for the SPCR table revision.

[Rebecca Cran]

From: Rebecca Cran 

The current SPCR table revision is 2. Instead of using a hard-coded
value, use the symbolic constant
EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_REVISION.

Signed-off-by: Rebecca Cran 
---
 Silicon/Qemu/SbsaQemu/AcpiTables/Spcr.aslc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Spcr.aslc 
b/Silicon/Qemu/SbsaQemu/AcpiTables/Spcr.aslc
index 432097307f8a..435b7fe66778 100644
--- a/Silicon/Qemu/SbsaQemu/AcpiTables/Spcr.aslc
+++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Spcr.aslc
@@ -17,7 +17,8 @@ STATIC EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE Spcr = {
   SBSAQEMU_ACPI_HEADER (
 EFI_ACPI_6_0_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_SIGNATURE,
 EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE,
-2), /* New MS definition for PL011 support */
+/* New MS definition for PL011 support */
+EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_REVISION),
   EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_ARM_PL011_UART,
   { EFI_ACPI_RESERVED_BYTE, EFI_ACPI_RESERVED_BYTE, EFI_ACPI_RESERVED_BYTE },
   {
-- 
2.30.2



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

[edk2-devel] [PATCH edk2-platforms 1/2] Silicon/Qemu: Convert DSDT ASL from legacy to ASL 2.0 syntax

[Rebecca Cran]

From: Rebecca Cran 

ACPI 6.0 introduced support for ASL 2.0 includes standard operators.
Convert the DSDT from legacy to ASL 2.0 syntax.

Signed-off-by: Rebecca Cran 
---
 Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl 
b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
index 3357916571fe..e50772fcf76d 100644
--- a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
+++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
@@ -449,7 +449,7 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
*/
   Method (_OSC,4) {
 // Check for proper UUID
-If (LEqual(Arg0,ToUUID("33DB4D5B-1FF7-401C-9657-7441C03DD766"))) {
+If (Arg0 == ToUUID("33DB4D5B-1FF7-401C-9657-7441C03DD766")) {
   // Create DWord-adressable fields from the Capabilities Buffer
   CreateDWordField (Arg3,0,CDW1)
   CreateDWordField (Arg3,4,CDW2)
@@ -463,28 +463,28 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
   // * ASPM
   // * Clock PM
   // * MSI/MSI-X
-  If (LNotEqual(And(SUPP, 0x16), 0x16)) {
-And (CTRL,0x1E,CTRL) // Mask bit 0 (and undefined bits)
+  If ((SUPP & 0x16) != 0x16) {
+CTRL &= 0x1E // Mask bit 0 (and undefined bits)
   }
 
   // Always allow native PME, AER (no dependencies)
 
   // Never allow SHPC (no SHPC controller in this system)
-  And (CTRL,0x1D,CTRL)
+  CTRL &= 0x1D
 
-  If (LNotEqual(Arg1,One)) {// Unknown revision
-Or (CDW1,0x08,CDW1)
+  If (Arg1 != One) { // Unknown revision
+CDW1 |= 0x08
   }
 
-  If (LNotEqual(CDW3,CTRL)) {// Capabilities bits were masked
-Or (CDW1,0x10,CDW1)
+  If (CDW3 != CTRL) {// Capabilities bits were masked
+CDW1 |= 0x10
   }
 
   // Update DWORD3 in the buffer
   Store (CTRL,CDW3)
   Return (Arg3)
 } Else {
-  Or (CDW1,4,CDW1) // Unrecognized UUID
+  CDW1 |= 4 // Unrecognized UUID
   Return (Arg3)
 }
   } // End _OSC
-- 
2.30.2



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

[edk2-devel] [PATCH edk2-platforms 0/2] Silicon/Qemu: SbsaQemu ACPI formatting improvements

[Rebecca Cran]

Improve the readability of the SbsaQemu SPCR and DSDT.

Rebecca Cran (2):
  Silicon/Qemu: Convert DSDT ASL from legacy to ASL 2.0 syntax
  Silicon/Qemu: Use the symbolic value for the SPCR table revision.

 Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl  | 18 +-
 Silicon/Qemu/SbsaQemu/AcpiTables/Spcr.aslc |  3 ++-
 2 files changed, 11 insertions(+), 10 deletions(-)

-- 
2.30.2



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

[edk2-devel] [PATCH edk2-platforms v2 2/2] Platform/ARM/JunoPkg: Set PcdArmArchTimerFreqInHz to 0 to read from CNTFRQ_EL0

[Rebecca Cran]

If PcdArmArchTimerFreqInHz is zero, the value of the timer frequency
will be read from CNTFRQ_EL0. Avoid hard-coding the value in ArmJuno.dsc
and instead let the ArmArchTimerLib driver read it from the SoC.

Signed-off-by: Rebecca Cran 
---
 Platform/ARM/JunoPkg/ArmJuno.dsc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc b/Platform/ARM/JunoPkg/ArmJuno.dsc
index 9cde4c862651..d3bb205aa6f2 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.dsc
+++ b/Platform/ARM/JunoPkg/ArmJuno.dsc
@@ -188,7 +188,8 @@
   #
   # ARM Architectural Timer Frequency
   #
-  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|5000
+  # Set to 0 so ArmArchTimerLib will read its value from CNTFRQ_EL0
+  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|0
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
 
-- 
2.30.2



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

[edk2-devel] [PATCH edk2-platforms v2 1/2] Platform/ARM/JunoPkg: Switch to MdeModulePkg/Universal/Metronome driver

[Rebecca Cran]

The MetronomeDxe driver uses the PCD PcdMetronomeTickPeriod to calculate
how many ticks to wait in MicroSecondDelay. Given that the timer clock
on Juno runs at 50 MHz, it ticks every 20 ns; therefore, a setting of
1000 is wrong: for example it causes a call to gBS->Stall (1) to take
10 us.

The driver in MdeModulePkg/Universal/Metronome assumes the clock ticks
at least every 100 ns, which is the minimum allowed by the Metronome
protocol. Since that's the case on Juno, switch from
EmbeddedPkg/MetronomeDxe to MdeModulePkg/Universal/Metronome.

Signed-off-by: Rebecca Cran 
---
 Platform/ARM/JunoPkg/ArmJuno.dsc | 3 +--
 Platform/ARM/JunoPkg/ArmJuno.fdf | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc b/Platform/ARM/JunoPkg/ArmJuno.dsc
index a00b866c5e9a..9cde4c862651 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.dsc
+++ b/Platform/ARM/JunoPkg/ArmJuno.dsc
@@ -189,7 +189,6 @@
   # ARM Architectural Timer Frequency
   #
   gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|5000
-  gEmbeddedTokenSpaceGuid.PcdMetronomeTickPeriod|1000
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
 
@@ -248,10 +247,10 @@
   MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
   MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
+  MdeModulePkg/Universal/Metronome/Metronome.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
   EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
-  EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
 
   MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
   MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
diff --git a/Platform/ARM/JunoPkg/ArmJuno.fdf b/Platform/ARM/JunoPkg/ArmJuno.fdf
index fca5a78cee6c..836d3cde8781 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.fdf
+++ b/Platform/ARM/JunoPkg/ArmJuno.fdf
@@ -96,10 +96,10 @@ FvNameGuid = B73FE497-B92E-416e-8326-45AD0D270092
   INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
   INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
   INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
+  INF MdeModulePkg/Universal/Metronome/Metronome.inf
   INF 
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
   INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
-  INF EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
 
   INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
   INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
-- 
2.30.2



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

[edk2-devel] [PATCH edk2-platforms v2 0/2] Platform/ARM/JunoPkg: Timer fixes

[Rebecca Cran]

The use of the EmbeddedPkg/MetronomeDxe driver on Juno can cause problems
with drivers that use gBS->Stall, since it takes 10x longer than
requested. For example requesting a timeout of 1 ms when doing a USB 
bulk transfer results in it taking 100 ms. Switching to the
MdeModulePkg/Universal/Metronome driver fixes this since it assumes the
timer clock ticks at least every 100 ns.

While here, set the PCD value of the timer frequency to 0 so it gets
read from the SoC instead of hard-coding it.

Changes in v2:

Dropped the patch to set PcdTimerPeriod.

Rebecca Cran (2):
  Platform/ARM/JunoPkg: Switch to MdeModulePkg/Universal/Metronome
driver
  Platform/ARM/JunoPkg: Set PcdArmArchTimerFreqInHz to 0 to read from
CNTFRQ_EL0

 Platform/ARM/JunoPkg/ArmJuno.dsc | 6 +++---
 Platform/ARM/JunoPkg/ArmJuno.fdf | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.30.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100385): https://edk2.groups.io/g/devel/message/100385
Mute This Topic: https://groups.io/mt/97099986/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] MdeModulePkg: Improve formatting of warning DEBUG in UsbSelectConfig

[Rebecca Cran]

Improve the formatting of a warning in UsbSelectConfig by adding
parentheses around the EFI_STATUS value.

Signed-off-by: Rebecca Cran 
---
 MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c 
b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
index aed34596f469..29a6419c3c86 100644
--- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
+++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
@@ -440,7 +440,7 @@ UsbSelectConfig (
 if (EFI_ERROR (Status)) {
   DEBUG ((
 DEBUG_WARN,
-"UsbSelectConfig: failed to connect driver %r, ignored\n",
+"UsbSelectConfig: failed to connect driver (%r), ignored\n",
 Status
 ));
 }
-- 
2.30.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100384): https://edk2.groups.io/g/devel/message/100384
Mute This Topic: https://groups.io/mt/97099772/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] ShellPkg: Improve "ping" output by adding equals sign after time

[Rebecca Cran]

Could someone commit this please?

On 12/5/22 19:17, Gao, Zhichao wrote:

Reviewed-by: Zhichao Gao 

Thanks,
Zhichao


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Rebecca
Cran
Sent: Friday, December 2, 2022 5:50 AM
To: devel@edk2.groups.io; Ni, Ray ; Gao, Zhichao

Cc: Rebecca Cran 
Subject: [edk2-devel] [PATCH 1/1] ShellPkg: Improve "ping" output by adding
equals sign after time

The output of the "ping" command shows the time without a space between
the label and the value. e.g.:

20 bytes from 192.168.0.1 : icmp_seq=1 ttl=1 time1~2ms

Improve the readability and consistency by adding an equals sign for the time
value:

20 bytes from 192.168.0.1 : icmp_seq=1 ttl=1 time=1~2ms

Signed-off-by: Rebecca Cran 
---

ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Comm
andsLib.uni | 2 +-
ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Comm
andsLib.uni | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git
a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
mandsLib.uni
b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
mandsLib.uni
index 73cf96d9e614..37fd4a11929c 100644
---
a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
mandsLib.uni
+++
b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Com
+++ mandsLib.uni
@@ -52,7 +52,7 @@
  #string STR_PING_NOROUTE_FOUND   #language en-US "There is no
route to the destination '%B%s%N' from the source '%B%s%N' was
found.\r\n"
  #string STR_PING_START   #language en-US "Ping %s %d data
bytes.\r\n"
  #string STR_PING_TIMEOUT #language en-US "Echo request
sequence %d timeout.\r\n"
-#string STR_PING_REPLY_INFO  #language en-US "%d bytes from %s :
icmp_seq=%d ttl=%d time%d~%dms\r\n"
+#string STR_PING_REPLY_INFO  #language en-US "%d bytes from %s :
icmp_seq=%d ttl=%d time=%d~%dms\r\n"
  #string STR_PING_STAT#language en-US "\n%d packets
transmitted, %d received, %d%% packet loss, time %dms\r\n"
  #string STR_PING_RTT #language en-US "\nRtt(round trip time)
min=%d~%dms max=%d~%dms avg=%d~%dms\r\n"

diff --git
a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
mandsLib.uni
b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
mandsLib.uni
index 30913ae5b583..cb9d39a33fbe 100644
---
a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
mandsLib.uni
+++
b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
+++ mandsLib.uni
@@ -33,7 +33,7 @@
  #string STR_PING6_NOSOURCE_INDOMAIN#language en-US  "No
sources in %s's multicast domain.\r\n"
  #string STR_PING6_START#language en-US  "Ping %s %d data
bytes\r\n"
  #string STR_PING6_TIMEOUT  #language en-US  "Echo request
sequence %d timeout.\r\n"
-#string STR_PING6_REPLY_INFO   #language en-US  "%d bytes
from %s : icmp_seq=%d ttl=%d time%d~%dms\r\n"
+#string STR_PING6_REPLY_INFO   #language en-US  "%d bytes
from %s : icmp_seq=%d ttl=%d time=%d~%dms\r\n"
  #string STR_PING6_STAT #language en-US  "\n%d packets
transmitted, %d received, %d%% packet loss, time %dms\r\n"
  #string STR_PING6_RTT  #language en-US  "\nRtt(round trip 
time)
min=%d~%dms max=%d~%dms avg=%d~%dms\r\n"

--
2.30.2










-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100383): https://edk2.groups.io/g/devel/message/100383
Mute This Topic: https://groups.io/mt/95394121/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 for this stable tag 202302

[Sunil V L]

On Mon, Feb 20, 2023 at 10:28:58PM +0800, gaoliming via groups.io wrote:
> Hi, all
> 
>  There are the request to include several security fixes in this stable tag
> 202302. So, Hard feature freeze will be defer to the early of March. Now, we
> are still in soft feature freeze phase. If you have the patch set for this
> stable tag, please raise your request in this mail thread.
> 
>  
Hi Liming,

If possible, I request to consider below two patches. They help in
running SCT and enable building risc-v with gcc 12.

https://edk2.groups.io/g/devel/message/100379
https://edk2.groups.io/g/devel/message/100381

Thanks
Sunil



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100382): https://edk2.groups.io/g/devel/message/100382
Mute This Topic: https://groups.io/mt/97086575/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] OvmfPkg/RiscVVirt: Fix for SCT memory allocation test case failure.

[Sunil V L]

The stack doesn't grow downwards but upwards for RISC-V.
Hence, fix the UEFI memory range calculation by including the correct
stack memory range. Without this fix, SCT hangs in MemoryAllocation
test cases which call AllocateAddress().

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Andrei Warkentin 
Reported-by: Heinrich Schuchardt 
Signed-off-by: Sunil V L 
---
 OvmfPkg/RiscVVirt/Sec/SecMain.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/RiscVVirt/Sec/SecMain.c b/OvmfPkg/RiscVVirt/Sec/SecMain.c
index 054e49ef0c1e..0e1f9b891af9 100644
--- a/OvmfPkg/RiscVVirt/Sec/SecMain.c
+++ b/OvmfPkg/RiscVVirt/Sec/SecMain.c
@@ -54,7 +54,7 @@ SecStartup (
   EFI_RISCV_FIRMWARE_CONTEXT  FirmwareContext;
   EFI_STATUS  Status;
   UINT64  UefiMemoryBase;
-  UINT64  StackBase;
+  UINT64  StackEnd;
 
   //
   // Report Status Code to indicate entering SEC core
@@ -71,15 +71,16 @@ SecStartup (
   FirmwareContext.FlattenedDeviceTree = (UINT64)DeviceTreeAddress;
   SetFirmwareContextPointer (&FirmwareContext);
 
-  StackBase  = (UINT64)FixedPcdGet32 (PcdOvmfSecPeiTempRamBase);
-  UefiMemoryBase = StackBase +  FixedPcdGet32 (PcdOvmfSecPeiTempRamSize) - 
SIZE_32MB;
+  StackEnd = (UINT64)FixedPcdGet32 (PcdOvmfSecPeiTempRamBase) +
+ FixedPcdGet32 (PcdOvmfSecPeiTempRamSize);
+  UefiMemoryBase = StackEnd - SIZE_32MB;
 
   // Declare the PI/UEFI memory region
   HobList = HobConstructor (
   (VOID *)UefiMemoryBase,
   SIZE_32MB,
   (VOID *)UefiMemoryBase,
-  (VOID *)StackBase // The top of the UEFI Memory is reserved for 
the stacks
+  (VOID *)StackEnd // The top of the UEFI Memory is reserved for 
the stacks
   );
   PrePeiSetHobList (HobList);
 
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100381): https://edk2.groups.io/g/devel/message/100381
Mute This Topic: https://groups.io/mt/97094512/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 V8 00/19] Add support for RISC-V virt machine

[Sunil V L]

On Mon, Feb 20, 2023 at 09:44:22AM -0800, Oliver Steffen wrote:
> Quoting Sunil V L (2023-02-17 05:27:15)
> > On Thu, Feb 16, 2023 at 03:45:49PM -0700, dann frazier wrote:
> > > On Fri, Feb 10, 2023 at 5:30 AM Sunil V L  
> > > wrote:
> > > >
> > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> > > >
> > > > Add support for RISC-V qemu virt machine. Most of the changes are 
> > > > migrated from
> > > > edk2-platforms repo and added qemu specific libraries under OvmfPkg.
> > > >
> > > > The series has passed CI tests 
> > > > (https://github.com/tianocore/edk2/pull/4023)
> > > >
> > > > These changes are available at: 
> > > > https://github.com/vlsunil/edk2/tree/RiscV64QemuVirt_V8
> > > >
> > > > The series can be tested as per instructions @
> > > > https://github.com/vlsunil/riscv-uefi-edk2-docs/wiki/RISC-V-Qemu-Virt-support
> > >
> > > Hi Sunil,
> > >
> > >   Thanks for your work getting this merged! In the above wiki, it
> > > notes that GCC 12+ is not supported. Is that still accurate? If so,
> > > can you clarify what is blocking that?
> > >
> > Hi Dan,
> >
> > Please see https://bugzilla.tianocore.org/show_bug.cgi?id=4061.
> >
> > My attempt to fix this issue
> > (https://edk2.groups.io/g/devel/message/93831) was not accepted due to
> > the concerns that it can cause weird issues in CI.
> >
> > So, we are left with either support gcc <12 or gcc >=12. We can mandate
> > gcc 12 itself for RISC-V, but that change need to be done hand in hand
> > with CI tests moving to use gcc 12. Otherwise, it will break CI.
> >
> > Let me check with CI owners on their roadmap to move to gcc 12.
> >
> > Thanks,
> > Sunil
> >
> 
> Adding Chris.
> 
> Pull request for a new contaimer image for Linux CI jobs with gcc12 is
> open:
> https://github.com/tianocore/containers/pull/60
> 
> Meanwhile you could try this image (temporary test build) in the CI:
> 
>   docker pull ghcr.io/osteffenrh/edk2-containers/fedora-37-test:latest
> 
> - Oliver
> 
Hey Oliver!,

Thank you very much!. However, I found a way to break this dependency.
So, you can move the CI image anytime you want once this patch gets
merged. 

https://edk2.groups.io/g/devel/message/100379

Thanks!
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100380): https://edk2.groups.io/g/devel/message/100380
Mute This Topic: https://groups.io/mt/96874977/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] BaseTools/tools_def.template: Update -march parameter for RISC-V

[Sunil V L]

Replace rv64imafdc with rv64gc so that it works for gcc 12.

"g" means imafd in gcc < 12 and imafd_zifencei_zicsr. So,
replacing rv64imafdc with rv64gc will work for both gcc <12
and gcc >=12.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yuwei Chen 
Cc: Andrei Warkentin 
Cc: Heinrich Schuchardt 
Signed-off-by: Sunil V L 
---
 BaseTools/Conf/tools_def.template | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index f77e936c0453..471eb67c0c83 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -1965,7 +1965,7 @@ DEFINE GCC5_RISCV_ALL_CC_FLAGS_WARNING_DISABLE= 
-Wno-tautological-compare -W
 
 DEFINE GCC5_RISCV_OPENSBI_TYPES   = 
-DOPENSBI_EXTERNAL_SBI_TYPES=OpensbiTypes.h
 
-DEFINE GCC5_RISCV64_ARCH   = rv64imafdc
+DEFINE GCC5_RISCV64_ARCH   = rv64gc
 DEFINE GCC5_RISCV32_RISCV64_ASLDLINK_FLAGS = DEF(GCC5_RISCV_ALL_DLINK_COMMON) 
-Wl,--entry,ReferenceAcpiTable -u ReferenceAcpiTable
 DEFINE GCC5_RISCV64_CC_FLAGS   = DEF(GCC5_RISCV_ALL_CC_FLAGS) 
DEF(GCC5_RISCV_ALL_CC_FLAGS_WARNING_DISABLE) DEF(GCC5_RISCV_OPENSBI_TYPES) 
-march=DEF(GCC5_RISCV64_ARCH) -fno-builtin -fno-builtin-memcpy 
-fno-stack-protector -Wno-address -fno-asynchronous-unwind-tables 
-Wno-unused-but-set-variable -fpack-struct=8 -mcmodel=medany -mabi=lp64 
-mno-relax
 DEFINE GCC5_RISCV64_DLINK_FLAGS= DEF(GCC5_RISCV_ALL_DLINK_FLAGS) 
-Wl,-melf64lriscv,--oformat=elf64-littleriscv,--no-relax
-- 
2.34.1



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

Re: [edk2-devel] [PATCH v4 1/1] MdePkg: Use ANSI colors to indicate debug message severity

[Rebecca Cran]

Hi Mike,

Sorry, I only just saw this message.
Your implementation looks better since as you say it doesn't require 
updates to the DebugLib instances.


Since you're more familiar with the gotchas around adding this, I'll 
leave it to you to decide if this can be committed or not.


--
Rebecca Cran

On 11/10/22 16:14, Michael D Kinney wrote:

Hi Rebecca,

Here is an alternate way to implement this feature.  Just an
experiment because it does not follow the recommended methods
to add a feature that can be enabled/disabled.  I have tested
this on EmulatorPkg and OvmfPkg and it works as expected.
Does not require any updates to any DebugLib instances.

https://github.com/mdkinney/edk2/tree/POC_DebugLibAnsi
https://github.com/mdkinney/edk2/commit/8961ee82e95495651eca53145ae76c4f0097c637

In general we do not like using #if to enable/disable features.
However, this feature does increase the size of modules to enable
ANSI color sequences.  This approach has zero size impact
if MDEPKG_DEBUGANSI is not defined.

There are also challenges with this feature for platform FW
builds that may integrate binaries from other sources if there
is a mix of modules that enable or disable the feature.

Only the platform developer knows if the device that all
DEBUG()/ASSERT() messages are routed supports ANSI color
sequences or not.  This means adding the sequences needs
to be in a platform component.  Or we need a mode where all
generated messages are more like trace messages that include
the message type and error level, and let the receiver of
the trace messages reformat as needed.

Best regards,

Mike


-Original Message-
From: Kinney, Michael D 
Sent: Thursday, November 10, 2022 11:12 AM
To: Rebecca Cran ; devel@edk2.groups.io; Gao, Liming 
; Liu, Zhiguang
; Andrew Fish ; Kinney, Michael D 

Subject: RE: [PATCH v4 1/1] MdePkg: Use ANSI colors to indicate debug message 
severity

Hi Rebecca,

In the edk2 repo, I see the following instances of the DebugPrintMarker() API
where you are currently adding he ANSI color sequences.  Should all of these
be updated?  I did not review the edk2-platforms repo.  And there may be
downstream custom DebugLib instances.  It would better if this feature could
be enabled for all existing DebugLib instances, but the only common location
is the DEBUG() macro definition in MdePkg/Include/Library/DebugLib.h and
adding code to that macro adds statements to the module calling the DebugLib
services, which can increase code size.

ArmPkg\Library\SemiHostingDebugLib\DebugLib.c:
75  VOID
76: DebugPrintMarker (
77IN  UINTNErrorLevel,

IntelFsp2Pkg\Library\BaseFspDebugLibSerialPort\DebugLib.c:
89  VOID
90: DebugPrintMarker (
91IN  UINTNErrorLevel,

MdeModulePkg\Library\PeiDxeDebugLibReportStatusCode\DebugLib.c:
85  VOID
86: DebugPrintMarker (
87IN  UINTNErrorLevel,

MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c:
97  VOID
98: DebugPrintMarker (
99IN  UINTNErrorLevel,

MdePkg\Library\DxeRuntimeDebugLibSerialPort\DebugLib.c:
   156  VOID
   157: DebugPrintMarker (
   158IN  UINTNErrorLevel,

MdePkg\Library\UefiDebugLibConOut\DebugLib.c:
79  VOID
80: DebugPrintMarker (
81IN  UINTNErrorLevel,

MdePkg\Library\UefiDebugLibDebugPortProtocol\DebugLib.c:
   137  VOID
   138: DebugPrintMarker (
   139IN  UINTNErrorLevel,

MdePkg\Library\UefiDebugLibStdErr\DebugLib.c:
79  VOID
80: DebugPrintMarker (
81IN  UINTNErrorLevel,

OvmfPkg\Library\PlatformDebugLibIoPort\DebugLib.c:
79  VOID
80: DebugPrintMarker (
81IN  UINTNErrorLevel,

Also, the ErrorLevel parameter is a bitmask.  It cannot be used in
a switch/case statement for only 1 bit being set.  To test for a
debug message of type ERROR or WARN, a check must be done for that
one bit being set in ErrorLevel.

The DebugLib also provides support for ASSERT() macros.  Should
ASSERT() messages have the same color as an ERROR message?  Or
its own color?

The logic below changes the color for the message based on message
type.  But is does not save/restore the current ANSI color setting.
It see it using the END_ESC_SEQ.  Does that put the color settings
back to the previous setting?

Thanks,

Mike


-Original Message-
From: Rebecca Cran 
Sent: Thursday, October 27, 2022 11:51 AM
To: devel@edk2.groups.io; Kinney, Michael D ; Gao, Liming 
; Liu,

Zhiguang

; Andrew Fish 
Cc: Rebecca Cran 
Subject: [PATCH v4 1/1] MdePkg: Use ANSI colors to indicate debug message 
severity

There currently isn't a way to differentiate the different
levels of DEBUG output: DEBUG_ERROR, DEBUG_WARN, DEBUG_INFO
etc.

To improve this, wrap DEBUG_ERROR and DEBUG_WARN level
messages in ANSI color code escape sequences. DEBUG_ERROR
messages will be displayed in red text, and DEBUG_WARN
in yellow.

Only enable this new functionality if the FeatureFlag
gEfiMdePkgTokenSpaceGuid.PcdDebugAnsiSeqSuppo

Re: [edk2-devel] [PATCH v4 1/1] MdePkg: Use ANSI colors to indicate debug message severity

[Rebecca Cran]

On 11/10/22 12:11, Kinney, Michael D wrote:


In the edk2 repo, I see the following instances of the DebugPrintMarker() API
where you are currently adding he ANSI color sequences.  Should all of these
be updated?  I did not review the edk2-platforms repo.  And there may be
downstream custom DebugLib instances.  It would better if this feature could
be enabled for all existing DebugLib instances, but the only common location
is the DEBUG() macro definition in MdePkg/Include/Library/DebugLib.h and
adding code to that macro adds statements to the module calling the DebugLib
services, which can increase code size.


I'll update the other instances. Given it's purely an aesthetic change, 
I'm not sure we need to worry about custom instances?

Also, the ErrorLevel parameter is a bitmask.  It cannot be used in
a switch/case statement for only 1 bit being set.  To test for a
debug message of type ERROR or WARN, a check must be done for that
one bit being set in ErrorLevel.


Thanks, I'll fix that.



The DebugLib also provides support for ASSERT() macros.  Should
ASSERT() messages have the same color as an ERROR message?  Or
its own color?


I wasn't thinking about ASSERT messages because those are super clear 
being one of the last messages printed.



The logic below changes the color for the message based on message
type.  But is does not save/restore the current ANSI color setting.
It see it using the END_ESC_SEQ.  Does that put the color settings
back to the previous setting?


No, it resets it to the terminal's default color scheme. I'm not aware 
of a way to save/restore the color.


--
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100377): https://edk2.groups.io/g/devel/message/100377
Mute This Topic: https://groups.io/mt/94611226/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 5/5] UefiCpuPkg: Put APs in 64 bit mode before handoff to OS.

[Lendacky, Thomas via groups.io]

On 2/20/23 11:43, Xie, Yuanhao wrote:

Hi Tom,

This series is the same on the link that I sent to you last Wednesday with the 
latest update 5 days ago: https://github.com/tianocore/edk2/pull/4012.
Last request email is on 17th, and a quick response on 18th, so I expect the 
testing is on the update version.


That was strange, when I pulled the tree, there was only one other commit 
above the first patch in the pull request. Not sure what happened there...


I pulled the tree again and now see all the commits.




Let's test it again. Please wait me one more day for the update, since I would 
like to have a bit more change based on Marvin Häuser's feedback.


Ok, I'll wait another day and re-test everything.

Thanks,
Tom



Thanks in advanced.
Yuanhao
-Original Message-
From: devel@edk2.groups.io  On Behalf Of Lendacky, Thomas 
via groups.io
Sent: Monday, February 20, 2023 10:11 PM
To: Xie, Yuanhao ; devel@edk2.groups.io
Cc: Dong, Guo ; Ni, Ray ; Rhodes, Sean ; 
Lu, James ; Guo, Gua ; Gerd Hoffmann ; Laszlo 
Ersek 
Subject: Re: [edk2-devel] [Patch V2 5/5] UefiCpuPkg: Put APs in 64 bit mode 
before handoff to OS.

On 2/19/23 23:20, Yuanhao Xie wrote:

Update the address of the allocated memory, only keep 4GB limitation for
   the case that APs still need to be transferred to 32-bit mode before
   OS.

Remove the unused arguments of AsmRelocateApLoopStart, update the
stack offset. For the processors other than with SEV-ES enabled, keep
APs in 64 bit mode before handoff to OS.

Create PageTable for the allocated reserved memory.

Tested on the OVMF package use of the support on AMD processors.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Tested-by: Tom Lendacky 


I only tested the pull request that you pointed me at which didn't have all 
these patches (basically it was only patch #1), so you can't really put my 
Tested-by: on this.

You didn't send an updated link, so I didn't test the full series. But I will 
test this full series. Do you have a link to a tree?

Thanks,
Tom


Tested-by: Yuanhao Xie 
Signed-off-by: Yuanhao Xie 
---
   UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf   |   6 +-
   UefiCpuPkg/Library/MpInitLib/DxeMpLib.c |  28 
++--
   UefiCpuPkg/Library/MpInitLib/Ia32/CreatePageTable.c |  23 
+++
   UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm  |  11 ---
   UefiCpuPkg/Library/MpInitLib/MpEqu.inc  |  22 
+++---
   UefiCpuPkg/Library/MpInitLib/MpLib.h|  17 +
   UefiCpuPkg/Library/MpInitLib/X64/CreatePageTable.c  |  82 
++
   UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm   | 173 
-
   UefiCpuPkg/UefiCpuPkg.dsc   |   3 ++-
   9 files changed, 186 insertions(+), 179 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
index cd07de3a3c..4285dd06b4 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
@@ -1,7 +1,7 @@
   ## @file
   #  MP Initialize Library instance for DXE driver.
   #
-#  Copyright (c) 2016 - 2021, Intel Corporation. All rights
reserved.
+#  Copyright (c) 2016 - 2023, Intel Corporation. All rights
+reserved.
   #  SPDX-License-Identifier: BSD-2-Clause-Patent
   #
   ##
@@ -24,10 +24,12 @@
   [Sources.IA32]
 Ia32/AmdSev.c
 Ia32/MpFuncs.nasm
+  Ia32/CreatePageTable.c
   
   [Sources.X64]

 X64/AmdSev.c
 X64/MpFuncs.nasm
+  X64/CreatePageTable.c
   
   [Sources.common]

 AmdSev.c
@@ -56,6 +58,8 @@
 PcdLib
 CcExitLib
 MicrocodeLib
+[LibraryClasses.X64]
+  CpuPageTableLib
   
   [Protocols]

 gEfiTimerArchProtocolGuid ## SOMETIMES_CONSUMES
diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
index 75743faf5f..76953206ca 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
@@ -28,7 +28,7 @@ volatile BOOLEANmStopCheckAllApsStatus   = TRUE;
   UINTN   mReservedTopOfApStack;
   volatile UINT32 mNumberToFinish = 0;
   RELOCATE_AP_LOOP_ENTRY  mReservedApLoop;
-
+UINTN   mApPageTable;
   
   //

   // Begin wakeup buffer allocation below 0x88000 @@ -379,10 +379,10
@@ RelocateApLoop (
 IN OUT VOID  *Buffer
 )
   {
-  CPU_MP_DATA  *CpuMpData;
-  BOOLEAN  MwaitSupport;
-  UINTNProcessorNumber;
-  UINTNStackStart;
+  CPU_MP_DATA  *CpuMpData;
+  BOOLEAN  MwaitSupport;
+  UINTNProcess

[edk2-devel] Event: Tools, CI, Code base construction meeting series - Tuesday, February 21, 2023 #cal-reminder

[Group Notification]

*Reminder: Tools, CI, Code base construction meeting series*

*When:*
Tuesday, February 21, 2023
10:00am to 11:00am
(UTC-08:00) America/Los Angeles

*Where:*
https://github.com/tianocore/edk2/discussions/2614

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=1753759 )

*Description:*

TianoCore community,

Microsoft and Intel will be hosting a series of open meetings to discuss build, 
CI, tools, and other related topics. If you are interested, have ideas/opinions 
please join us. These meetings will be Monday 4:30pm Pacific Time on Microsoft 
Teams.

MS Teams Link in following discussion: * 
https://github.com/tianocore/edk2/discussions/2614

Anyone is welcome to join.

* tianocore/edk2: EDK II (github.com)
* tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP module 
(github.com) https://github.com/tianocore/edk2-basetools
* tianocore/edk2-pytool-extensions: Extensions to the edk2 build system 
allowing for a more robust and plugin based build system and tool execution 
environment (github.com) https://github.com/tianocore/edk2-pytool-extensions
* tianocore/edk2-pytool-library: Python library package that supports UEFI 
development (github.com) https://github.com/tianocore/edk2-pytool-library

MS Teams Browser Clients * 
https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100374): https://edk2.groups.io/g/devel/message/100374
Mute This Topic: https://groups.io/mt/97091631/21656
Mute #cal-reminder:https://edk2.groups.io/g/devel/mutehashtag/cal-reminder
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 V8 00/19] Add support for RISC-V virt machine

[Oliver Steffen]

Quoting Sunil V L (2023-02-17 05:27:15)
> On Thu, Feb 16, 2023 at 03:45:49PM -0700, dann frazier wrote:
> > On Fri, Feb 10, 2023 at 5:30 AM Sunil V L  wrote:
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
> > >
> > > Add support for RISC-V qemu virt machine. Most of the changes are 
> > > migrated from
> > > edk2-platforms repo and added qemu specific libraries under OvmfPkg.
> > >
> > > The series has passed CI tests 
> > > (https://github.com/tianocore/edk2/pull/4023)
> > >
> > > These changes are available at: 
> > > https://github.com/vlsunil/edk2/tree/RiscV64QemuVirt_V8
> > >
> > > The series can be tested as per instructions @
> > > https://github.com/vlsunil/riscv-uefi-edk2-docs/wiki/RISC-V-Qemu-Virt-support
> >
> > Hi Sunil,
> >
> >   Thanks for your work getting this merged! In the above wiki, it
> > notes that GCC 12+ is not supported. Is that still accurate? If so,
> > can you clarify what is blocking that?
> >
> Hi Dan,
>
> Please see https://bugzilla.tianocore.org/show_bug.cgi?id=4061.
>
> My attempt to fix this issue
> (https://edk2.groups.io/g/devel/message/93831) was not accepted due to
> the concerns that it can cause weird issues in CI.
>
> So, we are left with either support gcc <12 or gcc >=12. We can mandate
> gcc 12 itself for RISC-V, but that change need to be done hand in hand
> with CI tests moving to use gcc 12. Otherwise, it will break CI.
>
> Let me check with CI owners on their roadmap to move to gcc 12.
>
> Thanks,
> Sunil
>

Adding Chris.

Pull request for a new contaimer image for Linux CI jobs with gcc12 is
open:
https://github.com/tianocore/containers/pull/60

Meanwhile you could try this image (temporary test build) in the CI:

  docker pull ghcr.io/osteffenrh/edk2-containers/fedora-37-test:latest

- Oliver



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100373): https://edk2.groups.io/g/devel/message/100373
Mute This Topic: https://groups.io/mt/96874977/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 5/5] UefiCpuPkg: Put APs in 64 bit mode before handoff to OS.

[Yuanhao Xie]

Hi Tom,

This series is the same on the link that I sent to you last Wednesday with the 
latest update 5 days ago: https://github.com/tianocore/edk2/pull/4012. 
Last request email is on 17th, and a quick response on 18th, so I expect the 
testing is on the update version.


Let's test it again. Please wait me one more day for the update, since I would 
like to have a bit more change based on Marvin Häuser's feedback.

Thanks in advanced.
Yuanhao
-Original Message-
From: devel@edk2.groups.io  On Behalf Of Lendacky, Thomas 
via groups.io
Sent: Monday, February 20, 2023 10:11 PM
To: Xie, Yuanhao ; devel@edk2.groups.io
Cc: Dong, Guo ; Ni, Ray ; Rhodes, Sean 
; Lu, James ; Guo, Gua 
; Gerd Hoffmann ; Laszlo Ersek 

Subject: Re: [edk2-devel] [Patch V2 5/5] UefiCpuPkg: Put APs in 64 bit mode 
before handoff to OS.

On 2/19/23 23:20, Yuanhao Xie wrote:
> Update the address of the allocated memory, only keep 4GB limitation for
>   the case that APs still need to be transferred to 32-bit mode before
>   OS.
> 
> Remove the unused arguments of AsmRelocateApLoopStart, update the 
> stack offset. For the processors other than with SEV-ES enabled, keep 
> APs in 64 bit mode before handoff to OS.
> 
> Create PageTable for the allocated reserved memory.
> 
> Tested on the OVMF package use of the support on AMD processors.
> 
> Cc: Guo Dong 
> Cc: Ray Ni 
> Cc: Sean Rhodes 
> Cc: James Lu 
> Cc: Gua Guo 
> Cc: Gerd Hoffmann 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Tested-by: Tom Lendacky 

I only tested the pull request that you pointed me at which didn't have all 
these patches (basically it was only patch #1), so you can't really put my 
Tested-by: on this.

You didn't send an updated link, so I didn't test the full series. But I will 
test this full series. Do you have a link to a tree?

Thanks,
Tom

> Tested-by: Yuanhao Xie 
> Signed-off-by: Yuanhao Xie 
> ---
>   UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf   |   6 +-
>   UefiCpuPkg/Library/MpInitLib/DxeMpLib.c |  28 
> ++--
>   UefiCpuPkg/Library/MpInitLib/Ia32/CreatePageTable.c |  23 
> +++
>   UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm  |  11 ---
>   UefiCpuPkg/Library/MpInitLib/MpEqu.inc  |  22 
> +++---
>   UefiCpuPkg/Library/MpInitLib/MpLib.h|  17 +
>   UefiCpuPkg/Library/MpInitLib/X64/CreatePageTable.c  |  82 
> ++
>   UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm   | 173 
> -
>   UefiCpuPkg/UefiCpuPkg.dsc   |   3 ++-
>   9 files changed, 186 insertions(+), 179 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf 
> b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> index cd07de3a3c..4285dd06b4 100644
> --- a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> @@ -1,7 +1,7 @@
>   ## @file
>   #  MP Initialize Library instance for DXE driver.
>   #
> -#  Copyright (c) 2016 - 2021, Intel Corporation. All rights 
> reserved.
> +#  Copyright (c) 2016 - 2023, Intel Corporation. All rights 
> +reserved.
>   #  SPDX-License-Identifier: BSD-2-Clause-Patent
>   #
>   ##
> @@ -24,10 +24,12 @@
>   [Sources.IA32]
> Ia32/AmdSev.c
> Ia32/MpFuncs.nasm
> +  Ia32/CreatePageTable.c
>   
>   [Sources.X64]
> X64/AmdSev.c
> X64/MpFuncs.nasm
> +  X64/CreatePageTable.c
>   
>   [Sources.common]
> AmdSev.c
> @@ -56,6 +58,8 @@
> PcdLib
> CcExitLib
> MicrocodeLib
> +[LibraryClasses.X64]
> +  CpuPageTableLib
>   
>   [Protocols]
> gEfiTimerArchProtocolGuid ## SOMETIMES_CONSUMES
> diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> index 75743faf5f..76953206ca 100644
> --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> @@ -28,7 +28,7 @@ volatile BOOLEANmStopCheckAllApsStatus   = TRUE;
>   UINTN   mReservedTopOfApStack;
>   volatile UINT32 mNumberToFinish = 0;
>   RELOCATE_AP_LOOP_ENTRY  mReservedApLoop;
> -
> +UINTN   mApPageTable;
>   
>   //
>   // Begin wakeup buffer allocation below 0x88000 @@ -379,10 +379,10 
> @@ RelocateApLoop (
> IN OUT VOID  *Buffer
> )
>   {
> -  CPU_MP_DATA  *CpuMpData;
> -  BOOLEAN  MwaitSupport;
> -  UINTNProcessorNumber;
> -  UINTNStackStart;
> +  CPU_MP_DATA  *CpuMpData;
> +  BOOLEAN  MwaitSupport;
> +  UINTNProcessorNumber;
> +  UINTNStackStart;
>   
> MpInitLibWhoAmI (&ProcessorNumber);
> CpuMpData= GetCpuMpData ();
> @@ -404,12 +404,9 @@ Rel

Re: [edk2-devel] BUG: tianocore does not honor the bootorder

[Gregory Lee Bartholomew]

On Mon, 2023-02-20 at 08:10 +0100, Gerd Hoffmann wrote:
> On Fri, Feb 17, 2023 at 10:23:22AM -0600, Gregory Lee Bartholomew wrote:
> > On Fri, 2023-02-17 at 14:08 +0100, Gerd Hoffmann wrote:
> > > On Wed, Feb 15, 2023 at 02:20:23PM -0600, Gregory Lee Bartholomew wrote:
> > > > I have a script that uses Qemu to install a Linux OS to the supplied 
> > > > device. At
> > > > the end of the install script, efibootmgr is called to create UEFI boot 
> > > > entries
> > > > and set the boot order. However, every time I boot the VM, it boots to 
> > > > entry
> > > > 0004 "UEFI Misc Device" instead of the proper entry specified in the 
> > > > bootorder.
> > > > This is confusing a script that I have for managing multiple ESPs (the 
> > > > script
> > > > needs to detect the current ESP and sync its contents to 
> > > > secondary/backup ESPs).
> > >  
> > > > Please fix tianocore to honor the bootorder instead of creating its own 
> > > > entries.
> > > 
> > > ovmf orders the boot entries according to the qemu configuration
> > > (bootindex property for devices).  If you don't want that just remove
> > > all bootindex properties from your qemu command line.
> > > 
> > > take care,
> > >   Gerd
> > > 
> > 
> > I don't believe I've set a bootindex. Below is the script that I'm using to
> > start the qemu instances.
> 
> OVMF shouldn't touch the order then.  It will still create entries for
> the devices it finds (on first boot).  If you add more entries and put
> them first (by setting BootOrder accordingly) OVMF should try booting
> these first.
> 
> take care,
>   Gerd
> 

It was my mistake. My qemu instance was referencing the wrong OVMF_VARS.fd.
Tiano was automatically booting the system from that "Misc Device" entry because
the installer-created entries were from an old run and were pointing to invalid
partition UUIDs. I personally think it would be less confusing if that sort of
automation were not done and instead a proper error were reported to the admin.
But I guess I understand why that is being done.

Sorry for the bogus bug report.

gb


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

Re: [edk2-devel] [RESEND] [PATCH v2 2/2] OvmfPkg/ResetVector: Exclude SEV launch secrets page from pre-validation

[Lendacky, Thomas via groups.io]

On 2/20/23 02:49, Dov Murik wrote:

In order to allow the VMM (such as QEMU) to add a page with hashes of
kernel/initrd/cmdline for measured direct boot on SNP, this page must
not be part of the SNP metadata list reported to the VMM.

Check if that page is defined; if it is, skip it in the metadata list.
In such case, VMM should fill the page with the hashes content, or
explicitly update it as a zero page (if kernel hashes are not used).


Would it be better to define a new section type (similar to what I did in 
the SVSM PoC)? This way, it remains listed in the metadata and allows the 
VMM to detect it and decide how to handle it.


Thanks,
Tom



Note that for SNP, the launch secret part of the page (lower 3KB) are
not relevant and will stay zero.  The last 1KB is used for the hashes.

This should have no effect on OvmfPkgX64 targets (which don't define
PcdSevLaunchSecretBase).

Signed-off-by: Dov Murik 
---
  OvmfPkg/ResetVector/ResetVector.nasmb | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb
index 94fbb0a87b37..16f3daf49d82 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -75,7 +75,19 @@
  ;
  %define SNP_SEC_MEM_BASE_DESC_2   (GHCB_BASE + 0x1000)
  %define SNP_SEC_MEM_SIZE_DESC_2   (SEV_SNP_SECRETS_BASE - 
SNP_SEC_MEM_BASE_DESC_2)
-%define SNP_SEC_MEM_BASE_DESC_3   (CPUID_BASE + CPUID_SIZE)
+%if (FixedPcdGet32 (PcdSevLaunchSecretBase) > 0)
+  ; There's a reserved page for SEV secrets and hashes; the VMM will fill and
+  ; validate the page, or mark it as a zero page.
+  %define EXPECTED_END_OF_LAUNCH_SECRET_PAGE (FixedPcdGet32 
(PcdSevLaunchSecretBase) + \
+  FixedPcdGet32 
(PcdSevLaunchSecretSize) + \
+  FixedPcdGet32 
(PcdQemuHashTableSize))
+  %if (FixedPcdGet32 (PcdOvmfSecPeiTempRamBase) != 
EXPECTED_END_OF_LAUNCH_SECRET_PAGE)
+%error "PcdOvmfSecPeiTempRamBase must start directly after the SEV Launch 
Secret page"
+  %endif
+  %define SNP_SEC_MEM_BASE_DESC_3 (FixedPcdGet32 
(PcdOvmfSecPeiTempRamBase))
+%else
+  %define SNP_SEC_MEM_BASE_DESC_3 (CPUID_BASE + CPUID_SIZE)
+%endif
  %define SNP_SEC_MEM_SIZE_DESC_3   (FixedPcdGet32 (PcdOvmfPeiMemFvBase) - 
SNP_SEC_MEM_BASE_DESC_3)
  
  %ifdef ARCH_X64



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

回复: [edk2-devel] [IMPORTANT] February Release Reviews and Merges for this stable tag 202302

[gaoliming via groups.io]

Hi, all

 There are the request to include several security fixes in this stable tag
202302. So, Hard feature freeze will be defer to the early of March. Now, we
are still in soft feature freeze phase. If you have the patch set for this
stable tag, please raise your request in this mail thread.

 

Thanks

Liming

发件人: devel@edk2.groups.io  代表 gaoliming via
groups.io
发送时间: 2023年2月15日 23:59
收件人: devel@edk2.groups.io; miki.deme...@intel.com;
annou...@edk2.groups.io; disc...@edk2.groups.io
抄送: 'Andrew Fish' ; 'Michael D Kinney'
; 'Leif Lindholm' ;
suni...@ventanamicro.com; 'Joey Vagedes' ; 'Chang,
Abner' ; abdat...@amd.com; 'Ni, Ray'
; jesh...@nvidia.com
主题: 回复: [edk2-devel] [IMPORTANT] February Release Reviews and Merges for
this stable tag 202302

 

Hi, all

 So far, below four patches are requested to catch this stable tag 202302.
If any one is missed, please reply the mail to mention it. I summary their
current status. Only two patches are required to be resolved for new stable
tag 202302. So, I would propose Hard Feature Freeze from Feb 20th (next
Monday) to Mar 3th (202302 stable tag will be created). If these two patches
pass code review before Hard Feature Freeze, they will be merged for this
stable tag. Otherwise, they will be for next stable tag. 


 


1.BaseTools: Update WindowsVsToolChain plugin
(https://edk2.groups.io/g/devel/message/100215)


[Liming] This patch passed reviewed before the soft feature freeze. It can
be merged. 


2.Add support for RISC-V virt machine
(https://edk2.groups.io/g/devel/message/99981)


[Liming] This patch got all review in the soft feature freeze on Feb 10th.
If no objection, this patch set can be merged. 


3.Adds AmdSmmCpuFeaturesLib for AMD Family
(https://edk2.groups.io/g/devel/message/100222)

[Liming] This patch is under code review now. 


4.MdeModulePkg: allow PlatformBootManagerLib to use BootNext
(https://edk2.groups.io/g/devel/message/100186)


[Liming] This patch is under the discussion now. 


5.   Update OpenSSL version to version 1.1.1t to include CVE fix
(https://bugzilla.tianocore.org/show_bug.cgi?id=4342)


[Liming] This is a new request. Edk2 patch is not ready, because new openssl
version 1.1.1t is just released on Feb 7th. I would like to collect the
comments for this new request to catch stable tag 202302. 


 

Thanks

Liming

发件人: devel@edk2.groups.io 
mailto:devel@edk2.groups.io> > 代表 Demeter, Miki
发送时间: 2023年2月10日 1:01
收件人: devel@edk2.groups.io  ;
annou...@edk2.groups.io  ;
disc...@edk2.groups.io  
主题: [edk2-devel] [IMPORTANT] February Release Reviews and Merges

 

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  

503.712.8030 (office)

971.248.0123 (cell)

 





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100369): https://edk2.groups.io/g/devel/message/100369
Mute This Topic: https://groups.io/mt/97086575/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 5/5] UefiCpuPkg: Put APs in 64 bit mode before handoff to OS.

[Lendacky, Thomas via groups.io]

On 2/19/23 23:20, Yuanhao Xie wrote:

Update the address of the allocated memory, only keep 4GB limitation for
  the case that APs still need to be transferred to 32-bit mode before
  OS.

Remove the unused arguments of AsmRelocateApLoopStart, update the
stack offset. For the processors other than with SEV-ES enabled, keep
APs in 64 bit mode before handoff to OS.

Create PageTable for the allocated reserved memory.

Tested on the OVMF package use of the support on AMD processors.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Tested-by: Tom Lendacky 


I only tested the pull request that you pointed me at which didn't have 
all these patches (basically it was only patch #1), so you can't really 
put my Tested-by: on this.


You didn't send an updated link, so I didn't test the full series. But I 
will test this full series. Do you have a link to a tree?


Thanks,
Tom


Tested-by: Yuanhao Xie 
Signed-off-by: Yuanhao Xie 
---
  UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf   |   6 +-
  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c |  28 
++--
  UefiCpuPkg/Library/MpInitLib/Ia32/CreatePageTable.c |  23 
+++
  UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm  |  11 ---
  UefiCpuPkg/Library/MpInitLib/MpEqu.inc  |  22 
+++---
  UefiCpuPkg/Library/MpInitLib/MpLib.h|  17 +
  UefiCpuPkg/Library/MpInitLib/X64/CreatePageTable.c  |  82 
++
  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm   | 173 
-
  UefiCpuPkg/UefiCpuPkg.dsc   |   3 ++-
  9 files changed, 186 insertions(+), 179 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf 
b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
index cd07de3a3c..4285dd06b4 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
@@ -1,7 +1,7 @@
  ## @file
  #  MP Initialize Library instance for DXE driver.
  #
-#  Copyright (c) 2016 - 2021, Intel Corporation. All rights reserved.
+#  Copyright (c) 2016 - 2023, Intel Corporation. All rights reserved.
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
  ##
@@ -24,10 +24,12 @@
  [Sources.IA32]
Ia32/AmdSev.c
Ia32/MpFuncs.nasm
+  Ia32/CreatePageTable.c
  
  [Sources.X64]

X64/AmdSev.c
X64/MpFuncs.nasm
+  X64/CreatePageTable.c
  
  [Sources.common]

AmdSev.c
@@ -56,6 +58,8 @@
PcdLib
CcExitLib
MicrocodeLib
+[LibraryClasses.X64]
+  CpuPageTableLib
  
  [Protocols]

gEfiTimerArchProtocolGuid ## SOMETIMES_CONSUMES
diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c 
b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
index 75743faf5f..76953206ca 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
@@ -28,7 +28,7 @@ volatile BOOLEANmStopCheckAllApsStatus   = TRUE;
  UINTN   mReservedTopOfApStack;
  volatile UINT32 mNumberToFinish = 0;
  RELOCATE_AP_LOOP_ENTRY  mReservedApLoop;
-
+UINTN   mApPageTable;
  
  //

  // Begin wakeup buffer allocation below 0x88000
@@ -379,10 +379,10 @@ RelocateApLoop (
IN OUT VOID  *Buffer
)
  {
-  CPU_MP_DATA  *CpuMpData;
-  BOOLEAN  MwaitSupport;
-  UINTNProcessorNumber;
-  UINTNStackStart;
+  CPU_MP_DATA  *CpuMpData;
+  BOOLEAN  MwaitSupport;
+  UINTNProcessorNumber;
+  UINTNStackStart;
  
MpInitLibWhoAmI (&ProcessorNumber);

CpuMpData= GetCpuMpData ();
@@ -404,12 +404,9 @@ RelocateApLoop (
  mReservedApLoop.GenericEntry (
MwaitSupport,
CpuMpData->ApTargetCState,
-  CpuMpData->PmCodeSegment,
StackStart - ProcessorNumber * AP_SAFE_STACK_SIZE,
(UINTN)&mNumberToFinish,
-  CpuMpData->Pm16CodeSegment,
-  CpuMpData->SevEsAPBuffer,
-  CpuMpData->WakeupBuffer
+  mApPageTable
);
}
  
@@ -540,9 +537,11 @@ InitMpGlobalData (
  
AddressMap = &CpuMpData->AddressMap;

if (CpuMpData->UseSevEsAPMethod) {
+Address= BASE_4GB - 1;
  ApLoopFunc = AddressMap->RelocateApLoopFuncAddressAmdSev;
  ApLoopFuncSize = AddressMap->RelocateApLoopFuncSizeAmdSev;
} else {
+Address= MAX_ADDRESS;
  ApLoopFunc = AddressMap->RelocateApLoopFuncAddress;
  ApLoopFuncSize = AddressMap->RelocateApLoopFuncSize;
}
@@ -564,7 +563,6 @@ InitMpGlobalData (

Re: [edk2-devel] [edk2 1/1] Dxe: add RISCV64 to mMachineTypeInfo

[Sunil V L]

Please update the subject.

Otherwise,
Reviewed-by: Sunil V L 

Thanks!
Sunil
On Fri, Feb 17, 2023 at 10:36:26PM -0600, Andrei Warkentin wrote:
> This fixes messages like:
> "Image type AARCH64 can't be loaded on  UEFI system"
> 
> Cc: Sunil V L 
> Cc: Daniel Schaefer 
> Cc: Liming Gao 
> Cc: Jian J Wang 
> Signed-off-by: Andrei Warkentin 
> ---
>  MdeModulePkg/Core/Dxe/Image/Image.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Image/Image.c 
> b/MdeModulePkg/Core/Dxe/Image/Image.c
> index 06cc6744b8c6..8704ebea9a7c 100644
> --- a/MdeModulePkg/Core/Dxe/Image/Image.c
> +++ b/MdeModulePkg/Core/Dxe/Image/Image.c
> @@ -81,7 +81,8 @@ GLOBAL_REMOVE_IF_UNREFERENCED MACHINE_TYPE_INFO  
> mMachineTypeInfo[] = {
>{ EFI_IMAGE_MACHINE_IA64,   L"IA64"},
>{ EFI_IMAGE_MACHINE_X64,L"X64" },
>{ EFI_IMAGE_MACHINE_ARMTHUMB_MIXED, L"ARM" },
> -  { EFI_IMAGE_MACHINE_AARCH64,L"AARCH64" }
> +  { EFI_IMAGE_MACHINE_AARCH64,L"AARCH64" },
> +  { EFI_IMAGE_MACHINE_RISCV64,L"RISCV64" },
>  };
>  
>  UINT16  mDxeCoreImageMachineType = 0;
> -- 
> 2.25.1
> 
> 
> 
> 
> 
> 


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

Re: [edk2-devel] [edk2 1/1] RISCV: Fix CpuSleep symbol name.

[Sunil V L]

Same feedback regarding the subject.

Otherwise,
Reviewed-by: Sunil V L 

On Fri, Feb 17, 2023 at 10:30:36PM -0600, Andrei Warkentin wrote:
> CpuSleep, not _CpuSleep.
> 
> Cc: Sunil V L 
> Cc: Daniel Schaefer 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Signed-off-by: Andrei Warkentin 
> ---
>  MdePkg/Library/BaseCpuLib/RiscV/Cpu.S | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseCpuLib/RiscV/Cpu.S 
> b/MdePkg/Library/BaseCpuLib/RiscV/Cpu.S
> index 375b91d31427..d6560087e080 100644
> --- a/MdePkg/Library/BaseCpuLib/RiscV/Cpu.S
> +++ b/MdePkg/Library/BaseCpuLib/RiscV/Cpu.S
> @@ -10,9 +10,9 @@
>  .align 3
>  .section .text
>  
> -.global ASM_PFX(_CpuSleep)
> +.global ASM_PFX(CpuSleep)
>  
> -ASM_PFX(_CpuSleep):
> +ASM_PFX(CpuSleep):
>  wfi
>  ret
>  
> -- 
> 2.25.1
> 


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

Re: [edk2-devel] [edk2 1/1] BaseLib: don't log in InternalSwitchStack

[Sunil V L]

Thanks for these fixes!, Andrei.

Could you please use below format for the subject?
PackageName: ModuleName: summary of changes

Also, could you create single patch series with these patches?

Otherwise,
Reviewed-by: Sunil V L 


On Fri, Feb 17, 2023 at 10:29:21PM -0600, Andrei Warkentin wrote:
> InternalSwitchStack may be called with a TPL high
> enough for a DebugLib implementation to assert.
> 
> Other arch implementations don't log either.
> 
> Cc: Sunil V L 
> Cc: Daniel Schaefer 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Signed-off-by: Andrei Warkentin 
> ---
>  MdePkg/Library/BaseLib/RiscV64/InternalSwitchStack.c | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseLib/RiscV64/InternalSwitchStack.c 
> b/MdePkg/Library/BaseLib/RiscV64/InternalSwitchStack.c
> index cf646e498aba..b78424c16383 100644
> --- a/MdePkg/Library/BaseLib/RiscV64/InternalSwitchStack.c
> +++ b/MdePkg/Library/BaseLib/RiscV64/InternalSwitchStack.c
> @@ -44,14 +44,6 @@ InternalSwitchStack (
>  {
>BASE_LIBRARY_JUMP_BUFFER  JumpBuffer;
>  
> -  DEBUG ((
> -DEBUG_INFO,
> -"RISC-V InternalSwitchStack Entry:%x Context1:%x Context2:%x 
> NewStack%x\n", \
> -EntryPoint,
> -Context1,
> -Context2,
> -NewStack
> -));
>JumpBuffer.RA = (UINTN)EntryPoint;
>JumpBuffer.SP = (UINTN)NewStack - sizeof (VOID *);
>JumpBuffer.S0 = (UINT64)(UINTN)Context1;
> -- 
> 2.25.1
> 


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

[edk2-devel] [RESEND] [PATCH v2 2/2] OvmfPkg/ResetVector: Exclude SEV launch secrets page from pre-validation

[Dov Murik]

In order to allow the VMM (such as QEMU) to add a page with hashes of
kernel/initrd/cmdline for measured direct boot on SNP, this page must
not be part of the SNP metadata list reported to the VMM.

Check if that page is defined; if it is, skip it in the metadata list.
In such case, VMM should fill the page with the hashes content, or
explicitly update it as a zero page (if kernel hashes are not used).

Note that for SNP, the launch secret part of the page (lower 3KB) are
not relevant and will stay zero.  The last 1KB is used for the hashes.

This should have no effect on OvmfPkgX64 targets (which don't define
PcdSevLaunchSecretBase).

Signed-off-by: Dov Murik 
---
 OvmfPkg/ResetVector/ResetVector.nasmb | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb
index 94fbb0a87b37..16f3daf49d82 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -75,7 +75,19 @@
 ;
 %define SNP_SEC_MEM_BASE_DESC_2   (GHCB_BASE + 0x1000)
 %define SNP_SEC_MEM_SIZE_DESC_2   (SEV_SNP_SECRETS_BASE - 
SNP_SEC_MEM_BASE_DESC_2)
-%define SNP_SEC_MEM_BASE_DESC_3   (CPUID_BASE + CPUID_SIZE)
+%if (FixedPcdGet32 (PcdSevLaunchSecretBase) > 0)
+  ; There's a reserved page for SEV secrets and hashes; the VMM will fill and
+  ; validate the page, or mark it as a zero page.
+  %define EXPECTED_END_OF_LAUNCH_SECRET_PAGE (FixedPcdGet32 
(PcdSevLaunchSecretBase) + \
+  FixedPcdGet32 
(PcdSevLaunchSecretSize) + \
+  FixedPcdGet32 
(PcdQemuHashTableSize))
+  %if (FixedPcdGet32 (PcdOvmfSecPeiTempRamBase) != 
EXPECTED_END_OF_LAUNCH_SECRET_PAGE)
+%error "PcdOvmfSecPeiTempRamBase must start directly after the SEV Launch 
Secret page"
+  %endif
+  %define SNP_SEC_MEM_BASE_DESC_3 (FixedPcdGet32 
(PcdOvmfSecPeiTempRamBase))
+%else
+  %define SNP_SEC_MEM_BASE_DESC_3 (CPUID_BASE + CPUID_SIZE)
+%endif
 %define SNP_SEC_MEM_SIZE_DESC_3   (FixedPcdGet32 (PcdOvmfPeiMemFvBase) - 
SNP_SEC_MEM_BASE_DESC_3)
 
 %ifdef ARCH_X64
-- 
2.25.1



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

[edk2-devel] [RESEND] [PATCH v2 1/2] OvmfPkg/AmdSev: Reorder MEMFD pages to match the order in OvmfPkgX64.fdf

[Dov Murik]

Resize the MEMFD section of AmdSevX64.fdf and reorder its pages so that
it matches the same size and order used in OvmfPkgX64.fdf.

After this change, this is the difference in the MEMFD of the two
targets:

$ diff -u \
   <(sed -ne '/FD.MEMFD/,/FV.SECFV/p' OvmfPkg/OvmfPkgX64.fdf) \
   <(sed -ne '/FD.MEMFD/,/FV.SECFV/p' OvmfPkg/AmdSev/AmdSevX64.fdf)
--- /dev/fd/63  2023-02-16 07:06:15.365308683 +
+++ /dev/fd/62  2023-02-16 07:06:15.365308683 +
@@ -32,6 +32,12 @@
 0x00E000|0x001000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize

+0x00F000|0x000C00
+gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize
+
+0x00FC00|0x000400
+gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
+
 0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize

Signed-off-by: Dov Murik 
---
 OvmfPkg/AmdSev/AmdSevX64.fdf | 27 ++--
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf
index 5fb3b5d27632..54ba9ecf5149 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.fdf
+++ b/OvmfPkg/AmdSev/AmdSevX64.fdf
@@ -36,10 +36,10 @@ FV = SECFV
 
 [FD.MEMFD]
 BaseAddress   = $(MEMFD_BASE_ADDRESS)
-Size  = 0xD0
+Size  = 0xE0
 ErasePolarity = 1
 BlockSize = 0x1
-NumBlocks = 0xD0
+NumBlocks = 0xE0
 
 0x00|0x006000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
@@ -59,21 +59,21 @@ 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmf
 0x00B000|0x001000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize
 
-0x00C000|0x000C00
-gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize
-
-0x00CC00|0x000400
-gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
-
-0x00D000|0x001000
+0x00C000|0x001000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupSize
 
-0x00E000|0x001000
+0x00D000|0x001000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize
 
-0x00F000|0x001000
+0x00E000|0x001000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize
 
+0x00F000|0x000C00
+gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize
+
+0x00FC00|0x000400
+gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
+
 0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
@@ -81,12 +81,13 @@ 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.P
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
 FV = PEIFV
 
-0x10|0xC0
+0x10|0xD0
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
 FV = DXEFV
 
 
##
-# Set the SEV-ES specific work area PCDs
+# Set the SEV-ES specific work area PCDs (used for all forms of SEV since the
+# the SEV STATUS MSR is now saved in the work area)
 #
 SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase = $(MEMFD_BASE_ADDRESS) +  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase + 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
 SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize = 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize - 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
-- 
2.25.1



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

[edk2-devel] [RESEND] [PATCH v2 0/2] OvmfPkg: Enable measured direct boot on AMD SEV-SNP

[Dov Murik]

[Resending due to missing Cc in actual patches emails.]

(Note: This is a new version of this one-year-old patch series; the v1
series [1] got a few Acked-by but it's been so long that I don't
consider them relevant anymore.)

AMD SEV and SEV-ES support measured direct boot with
kernel/initrd/cmdline hashes injected by QEMU and verified by OVMF
during boot.

To enable the same approach for AMD SEV-SNP we make sure the page in
which QEMU inserts the hashes of kernel/initrd/cmdline is not already
pre-validated, as SNP doesn't allow validating a page twice.

The first patch rearranges the pages in AmdSevX64's MEMFD so they are in
the same order both as in the main target (OvmfPkgX64), with the
exception of the SEV Launch Secret page which isn't defined in
OvmfPkgX64.

The second patch modifies the SNP metadata structure such that on
AmdSev target the SEV Launch Secret page is not included in the ranges
that are pre-validated (zero pages) by the VMM; instead the VMM will
insert content into this page (the hashes table), or mark it explicitly
as a zero page if no hashes are added.

This series is available at:
https://github.com/confidential-containers-demo/edk2/tree/snp-kernel-hashes-v2

The corresponding RFC patch series for QEMU is in:
https://lore.kernel.org/qemu-devel/20230216084913.2148508-1-dovmu...@linux.ibm.com/
or use this tree:
https://github.com/confidential-containers-demo/qemu/tree/snp-kernel-hashes-v2

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Min Xu 
Cc: Tom Lendacky 
Cc: Michael Roth 
Cc: Ashish Kalra 
Cc: Mario Smarduch 
Cc: Tobin Feldman-Fitzthum 

---

v2 changes:
* Rebased on master
* Updated AmdSev MEMFD size to match OvmfX64

v1:
[1] https://edk2.groups.io/g/devel/message/88137


Dov Murik (2):
  OvmfPkg/AmdSev: Reorder MEMFD pages to match the order in
OvmfPkgX64.fdf
  OvmfPkg/ResetVector: Exclude SEV launch secrets page from
pre-validation

 OvmfPkg/AmdSev/AmdSevX64.fdf  | 27 ++--
 OvmfPkg/ResetVector/ResetVector.nasmb | 14 +-
 2 files changed, 27 insertions(+), 14 deletions(-)

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100362): https://edk2.groups.io/g/devel/message/100362
Mute This Topic: https://groups.io/mt/97082681/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] Ext4Pkg: Move unicode collation initialization to Start()

[Marvin Häuser]

> On 20. Feb 2023, at 08:52, Ard Biesheuvel  wrote:
> 
> On Fri, 17 Feb 2023 at 21:14, Pedro Falcato  wrote:
>> 
>> There have been reports[1] of failures to boot due to unicode collation
>> protocols not being available at Ext4Dxe load time. Therefore, attempt
>> to initialize unicode collation at Start() time, like done previously in
>> FatPkg/EnhancedFatDxe. By doing so, we move collation initialization
>> to BDS, where the module responsible for protocol installation should
>> have already been loaded and ran.
>> 
>> [1]: https://edk2.groups.io/g/devel/message/100312
>> 
>> Cc: Ard Biesheuvel 
>> Cc: Marvin Häuser 
>> Fixes: d9ceedca6c8f ("Ext4Pkg: Add Ext4Dxe driver.")
>> Signed-off-by: Pedro Falcato 
>> ---
>> RFC-ish patch that implements one of the possibilities discussed in [1].
>> Please test and give feedback.
>> 
>> Odd that this issue was never caught in any other platform. Do the RPi 
>> platforms have
>> something funky going on?
>> 
> 
> It could be something as simple as the order the drivers appear in the
> .FDF file.
> 
>> Features/Ext4Pkg/Ext4Dxe/Collation.c | 18 +-
>> Features/Ext4Pkg/Ext4Dxe/Ext4Dxe.c   | 51 +++-
>> Features/Ext4Pkg/Ext4Dxe/Ext4Dxe.h   | 11 ++
>> 3 files changed, 56 insertions(+), 24 deletions(-)
>> 
>> diff --git a/Features/Ext4Pkg/Ext4Dxe/Collation.c 
>> b/Features/Ext4Pkg/Ext4Dxe/Collation.c
>> index 91d172b1cb89..65c34c33ea93 100644
>> --- a/Features/Ext4Pkg/Ext4Dxe/Collation.c
>> +++ b/Features/Ext4Pkg/Ext4Dxe/Collation.c
>> @@ -1,7 +1,7 @@
>> /** @file
>>   Unicode collation routines
>> 
>> -  Copyright (c) 2021 Pedro Falcato All rights reserved.
>> +  Copyright (c) 2021 - 2023 Pedro Falcato All rights reserved.
>>   Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
>> 
>>   SPDX-License-Identifier: BSD-2-Clause-Patent
>> @@ -9,6 +9,7 @@
>> 
>> #include 
>> 
>> +#include 
>> #include 
>> #include 
>> #include 
>> @@ -169,5 +170,20 @@ Ext4StrCmpInsensitive (
>>   IN CHAR16  *Str2
>>   )
>> {
>> +  ASSERT (gUnicodeCollationInterface != NULL);
>>   return gUnicodeCollationInterface->StriColl (gUnicodeCollationInterface, 
>> Str1, Str2);
>> }
>> +
>> +/**
>> +   Check if unicode collation is initialized
>> +
>> +   @retval TRUE if Ext4InitialiseUnicodeCollation() was already called 
>> successfully
>> +   @retval FALSE if Ext4InitialiseUnicodeCollation() was not yet called 
>> successfully
>> +**/
>> +BOOLEAN
>> +Ext4IsCollationInitialized (
>> +  VOID
>> +  )
>> +{
>> +  return gUnicodeCollationInterface != NULL;
>> +}
>> diff --git a/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe.c 
>> b/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe.c
>> index 2a4f5a7bd0ef..de0d633febfb 100644
>> --- a/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe.c
>> +++ b/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe.c
>> @@ -1,7 +1,7 @@
>> /** @file
>>   Driver entry point
>> 
>> -  Copyright (c) 2021 Pedro Falcato All rights reserved.
>> +  Copyright (c) 2021 - 2023 Pedro Falcato All rights reserved.
>>   SPDX-License-Identifier: BSD-2-Clause-Patent
>> **/
>> 
>> @@ -513,26 +513,18 @@ Ext4EntryPoint (
>>   IN EFI_SYSTEM_TABLE  *SystemTable
>>   )
>> {
>> -  EFI_STATUS  Status;
>> -
>> -  Status = EfiLibInstallAllDriverProtocols2 (
>> - ImageHandle,
>> - SystemTable,
>> - &gExt4BindingProtocol,
>> - ImageHandle,
>> - &gExt4ComponentName,
>> - &gExt4ComponentName2,
>> - NULL,
>> - NULL,
>> - NULL,
>> - NULL
>> - );
>> -
>> -  if (EFI_ERROR (Status)) {
>> -return Status;
>> -  }
>> -
>> -  return Ext4InitialiseUnicodeCollation (ImageHandle);
>> +  return EfiLibInstallAllDriverProtocols2 (
>> +   ImageHandle,
>> +   SystemTable,
>> +   &gExt4BindingProtocol,
>> +   ImageHandle,
>> +   &gExt4ComponentName,
>> +   &gExt4ComponentName2,
>> +   NULL,
>> +   NULL,
>> +   NULL,
>> +   NULL
>> +   );
>> }
>> 
>> /**
>> @@ -761,6 +753,19 @@ Ext4Bind (
>>   BlockIo = NULL;
>>   DiskIo  = NULL;
>> 
>> +  // Note: We initialize collation here since this is called in BDS, when 
>> we are likely
>> +  // to have the Unicode Collation protocols available.
>> +  if (!Ext4IsCollationInitialized ()) {
>> +Status = Ext4InitialiseUnicodeCollation (BindingProtocol->ImageHandle);
>> +if (EFI_ERROR (Status)) {
>> +  // Lets throw a loud error into the log
>> +  // It is very unlikely something like this may fire out of the blue. 
>> Chances are either
>> +  // the platform configuration is wrong, or we are.
>> +  DEBUG ((DEBUG_ERROR, "[ext4] Error: Unicode Collation not available - 
>> failure to Start() - error %r\n", Status));
>> +  goto Error;
>> +}
>> +  }
>> +
> 
> This should work, although I'm not sure I see the point of the extra check.

Thanks for checking! Which extra check, IsInit? It’s just a weirdly abstract 
shortcut to not go through protocol lookup