date:20200824

Re: [edk2-devel] [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix buffer overrun in FileHandleReadLine()

2020-08-24 Thread Vladimir Olovyannikov via groups.io

> -Original Message-
> From: Laszlo Ersek 
> Sent: Monday, August 24, 2020 9:52 AM
> To: devel@edk2.groups.io; zhiguang@intel.com;
> vladimir.olovyanni...@broadcom.com
> Cc: Kinney, Michael D ; Gao, Liming
> 
> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix
> buffer overrun in FileHandleReadLine()
>
> On 08/24/20 18:18, Laszlo Ersek wrote:
> > On 07/03/20 04:30, Zhiguang Liu wrote:
> >> Reviewed-by: Zhiguang Liu 
> >
> > Merged as commit 4535fc312b76, via
> > .
>
> The commit message does not mention a TianoCore BZ. If there *is* an
> associated TianoCore BZ, please set it to RESOLVED|FIXED now, and also
> mark the above commit hash in a comment on it.
>
> Thanks
> Laszlo
Thank you Laszlo.
I modified the BZ https://bugzilla.tianocore.org/show_bug.cgi?id=2783 as you
suggested.

Thank you,
Vladimir
>
> >
> > Thanks,
> > Laszlo
> >
> >>
> >>> -Original Message-
> >>> From: devel@edk2.groups.io  On Behalf Of
> >>> Vladimir Olovyannikov via groups.io
> >>> Sent: Thursday, July 2, 2020 10:31 AM
> >>> To: devel@edk2.groups.io
> >>> Cc: Vladimir Olovyannikov ;
> >>> Kinney, Michael D ; Gao, Liming
> >>> ; Liu, Zhiguang 
> >>> Subject: [edk2-devel] [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix
> >>> buffer overrun in FileHandleReadLine()
> >>>
> >>> If the size of the supplied buffer in FileHandleReadLine(), module
> >>> UefiFileHandleLib.c, was not 0, but was not enough to fit in the
> >>> line, the size is increased, and then the Buffer of the new size is
> >>> zeroed. This size is always larger than the supplied buffer size,
> >>> causing supplied buffer overrun. Fix the issue by using the supplied
> >>> buffer size in ZeroMem().
> >>>
> >>> Signed-off-by: Vladimir Olovyannikov
> >>> 
> >>> Cc: Michael D Kinney 
> >>> Cc: Liming Gao 
> >>> Cc: Zhiguang Liu 
> >>> ---
> >>>  MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 6 --
> >>>  1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> >>> b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> >>> index 28e28e5f67d5..ab34e6ccd5f4 100644
> >>> --- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> >>> +++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> >>> @@ -969,6 +969,7 @@ FileHandleReadLine(
> >>>UINTN   CharSize;
> >>>
> >>>UINTN   CountSoFar;
> >>>
> >>>UINTN   CrCount;
> >>>
> >>> +  UINTN   OldSize;
> >>>
> >>>UINT64  OriginalFilePosition;
> >>>
> >>>
> >>>
> >>>if (Handle == NULL
> >>>
> >>> @@ -1039,10 +1040,11 @@ FileHandleReadLine(
> >>>// if we ran out of space tell when...
> >>>
> >>>//
> >>>
> >>>if ((CountSoFar+1-CrCount)*sizeof(CHAR16) > *Size){
> >>>
> >>> +OldSize = *Size;
> >>>
> >>>  *Size = (CountSoFar+1-CrCount)*sizeof(CHAR16);
> >>>
> >>>  if (!Truncate) {
> >>>
> >>> -  if (Buffer != NULL && *Size != 0) {
> >>>
> >>> -ZeroMem(Buffer, *Size);
> >>>
> >>> +  if (Buffer != NULL && OldSize != 0) {
> >>>
> >>> +ZeroMem(Buffer, OldSize);
> >>>
> >>>}
> >>>
> >>>FileHandleSetPosition(Handle, OriginalFilePosition);
> >>>
> >>>return (EFI_BUFFER_TOO_SMALL);
> >>>
> >>> --
> >>> 2.26.2.266.ge870325ee8
> >

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64593): https://edk2.groups.io/g/devel/message/64593
Mute This Topic: https://groups.io/mt/75251007/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 1/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

2020-08-24 Thread Vladimir Olovyannikov via groups.io

Hi Laszlo,

Sorry, I should've checked. No, there was no intention at all to even touch
an OpenSSL lib.
I will re-send tomorrow morning.

Thank you,
Vladimir

> -Original Message-
> From: Laszlo Ersek 
> Sent: Monday, August 24, 2020 12:43 PM
> To: devel@edk2.groups.io; vladimir.olovyanni...@broadcom.com
> Cc: Samer El-Haj-Mahmoud ; Zhichao
> Gao ; Maciej Rabeda
> ; Jiaxin Wu ; Siyuan
> Fu ; Ray Ni ; Liming Gao
> ; Nd 
> Subject: Re: [edk2-devel] [PATCH v6 1/1] ShellPkg/DynamicCommand: add
> HttpDynamicCommand
>
> Hi Vladimir,
>
> On 08/21/20 18:05, Vladimir Olovyannikov via groups.io wrote:
> > Introduce an http client utilizing EDK2 HTTP protocol, to allow fast
> > image downloading from http/https servers.
> > HTTP download speed is usually faster than tftp.
> > The client is based on the same approach as tftp dynamic command, and
> > uses the same UEFI Shell command line parameters. This makes it easy
> > integrating http into existing UEFI Shell scripts.
> > Note that to enable HTTP download, feature Pcd
> > gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must be set to
> > TRUE.
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860
> >
> > Signed-off-by: Vladimir Olovyannikov
> > 
> > Cc: Samer El-Haj-Mahmoud 
> > Cc: Laszlo Ersek 
> > Cc: Zhichao Gao 
> > Cc: Maciej Rabeda 
> > Cc: Jiaxin Wu 
> > Cc: Siyuan Fu 
> > Cc: Ray Ni 
> > Cc: Liming Gao 
> > Cc: Nd 
> > ---
> >  ShellPkg/ShellPkg.dec |1 +
> >  ShellPkg/ShellPkg.dsc |5 +
> >  .../HttpDynamicCommand/HttpApp.inf|   58 +
> >  .../HttpDynamicCommand/HttpDynamicCommand.inf |   63 +
> >  .../DynamicCommand/HttpDynamicCommand/Http.h  |   88 +
> >  ShellPkg/Include/Guid/ShellLibHiiGuid.h   |5 +
> >  .../DynamicCommand/HttpDynamicCommand/Http.c  | 1693
> +
> >  .../HttpDynamicCommand/HttpApp.c  |   61 +
> >  .../HttpDynamicCommand/HttpDynamicCommand.c   |  137 ++
> >  CryptoPkg/Library/OpensslLib/openssl  |2 +-
> >  .../HttpDynamicCommand/Http.uni   |  116 ++
> >  11 files changed, 2228 insertions(+), 1 deletion(-)  create mode
> > 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
> >  create mode 100644
> >
> ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand
> .inf
> >  create mode 100644
> ShellPkg/DynamicCommand/HttpDynamicCommand/Http.h
> >  create mode 100644
> ShellPkg/DynamicCommand/HttpDynamicCommand/Http.c
> >  create mode 100644
> > ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.c
> >  create mode 100644
> >
> ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand
> .c
> >  create mode 100644
> > ShellPkg/DynamicCommand/HttpDynamicCommand/Http.uni
>
> [...]
>
> > diff --git a/CryptoPkg/Library/OpensslLib/openssl
> > b/CryptoPkg/Library/OpensslLib/openssl
> > index e2e09d9fba11..c3656cc594da 16
> > --- a/CryptoPkg/Library/OpensslLib/openssl
> > +++ b/CryptoPkg/Library/OpensslLib/openssl
> > @@ -1 +1 @@
> > -Subproject commit e2e09d9fba1187f8d6aafaa34d4172f56f1ffb72
> > +Subproject commit c3656cc594daac8167721dde7220f0e59ae146fc
>
> your patch includes a hunk that moves our openssl submodule from 1.1.1g
> back to ~1.1.1d.
>
> I think that must be unintentional; can you please drop this hunk and post
> v7?
>
> Thanks
> Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64592): https://edk2.groups.io/g/devel/message/64592
Mute This Topic: https://groups.io/mt/76332046/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

2020-08-24 Thread Abner Chang

Liming and Laszlo, many thanks to your helps on this! 

> -Original Message-
> From: gaoliming [mailto:gaolim...@byosoft.com.cn]
> Sent: Tuesday, August 25, 2020 9:20 AM
> To: devel@edk2.groups.io; ler...@redhat.com; 'Leif Lindholm'
> ; af...@apple.com; 'Kinney, Michael D'
> ; 'Guptha, Soumya K'
> 
> Cc: annou...@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> ; qi1.zh...@intel.com;
> marcello.ba...@9elements.com
> Subject: 回复: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-
> 24 for edk2-stable202008
> 
> Laszlo:
>   Thanks for your great support.
> 
>   I merge SmBios type 42 patch @
> 78ab44cb96808bd3ff0edf312599f94a6a92172a.
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: bounce+27952+64572+4905953+8761...@groups.io
> >  代表 Laszlo Ersek
> > 发送时间: 2020年8月24日 21:38
> > 收件人: gaoliming ; 'Leif Lindholm'
> > ; af...@apple.com; 'Kinney, Michael D'
> > ; 'Guptha, Soumya K'
> > 
> > 抄送: devel@edk2.groups.io; annou...@edk2.groups.io; 'Chang, Abner
> (HPS
> > SW/FW Technologist)' ; qi1.zh...@intel.com;
> > marcello.ba...@9elements.com
> > 主题: Re: [edk2-devel] Soft Feature Freeze start date delays to
> > 2020-08-24
> for
> > edk2-stable202008
> >
> > Hi Liming,
> >
> > On 08/24/20 03:49, gaoliming wrote:
> > > Hi, all
> > >
> > > Based on the discussion
> > > INVALID URI REMOVED
> > >
> g_devel_message_64493=DwIFbw=C5b8zRQO1miGmBeVZ2LFWg=_
> SN6FZBN4V
> > > gi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E=Ezm_GF-
> Nrwz68WJSOEmoaYue4UtvI3Ay
> > > cFv1I6pPqN8=EWWY74jVVLuAgol6-VxRBNCxlmUOyawSRBZc5PFPP-
> U= , we
> > > make the conclusion to defer one week for edk2-stable202008 to
> > > include the important patch for RiscV. Soft Feature Freeze (SFF)
> > > will start from today (2020-08-24). Below is new edk2-stable202008
> > > tag planning proposed schedule
> > >
> >
>  Plann
> > ing>.
> > > If you have any comments, please raise it.
> > >
> > >
> > > Date (00:00:00 UTC-8) Description
> > > 2020-06-03Beginning of development
> > > 2020-08-07Feature Planning Freeze
> > > 2020-08-24Soft Feature Freeze
> > > 2020-08-28Hard Feature Freeze
> > > 2020-09-04Release
> > >
> > > Because SFF date is changed, if the patches passed code review
> > > before SFF date (2020-08-24), the patches can still be merged for
> > > this stable tag. Here is the patch list those passed code review
> > > before new SFF date. For below features, I will let the feature
> > > owner decides whether to merge it for this stable tag.
> >
> > As of this writing:
> >
> > - Mon Aug 24 12:59:59 UTC 2020
> >
> > we've entered the (new) Soft Feature Freeze. (The SFF date is
> > 2020-08-24
> > 00:00:00 UTC-8; in UTC, that's Mon Aug 24 08:00:00 UTC 2020 -- about
> > five hours ago.)
> >
> > So:
> >
> > > Feature List:
> > >
> > > INVALID URI REMOVED
> > >
> g_devel_message_63767=DwIFbw=C5b8zRQO1miGmBeVZ2LFWg=_
> SN6FZBN4V
> > > gi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E=Ezm_GF-
> Nrwz68WJSOEmoaYue4UtvI3Ay
> > >
> cFv1I6pPqN8=DZ4LNCQI974irYanMafqUNTinVCebHjYzyjmNrzw44A=
> > > [PATCH] EmbeddedPkg/libfdt: Add strncmp macro to use AsciiStrnCmp
> >
> > I'm going to merge this soon (with Leif's review).
> >
> > > INVALID URI REMOVED
> > >
> g_devel_message_64363=DwIFbw=C5b8zRQO1miGmBeVZ2LFWg=_
> SN6FZBN4V
> > > gi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E=Ezm_GF-
> Nrwz68WJSOEmoaYue4UtvI3Ay
> > >
> cFv1I6pPqN8=ticdzJnT3RUAQhR6PWJGg89mpw89bXziNJvmmBxDkAI=
> > > [PATCH v5 0/3] UefiPayloadPkg: Runtime MMCONF
> >
> > The UefiPayloadPkg patches in the series (#1, #3) have not received
> reviews.
> > We have to delay this until after the stable tag.
> >
> > > INVALID URI REMOVED
> > >
> g_devel_message_64354=DwIFbw=C5b8zRQO1miGmBeVZ2LFWg=_
> SN6FZBN4V
> > > gi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E=Ezm_GF-
> Nrwz68WJSOEmoaYue4UtvI3Ay
> > > cFv1I6pPqN8=p-jAd4Mr-
> vHN_CpVOx3c7yEd2oGKeNZjGYgc461S5vk=
> > > [PATCH v4 0/8] Need add a FSP binary measurement
> >
> > The SecurityPkg patches have not been approved yet, and Bret and
> > Jiewen are still testing / discussing (as far as I understand):
> >  3A__edk2.groups.io_g_devel_message_64526=DwIFbw=C5b8zRQO1m
> iGmBeVZ2LFWg=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E
> =Ezm_GF-
> Nrwz68WJSOEmoaYue4UtvI3AycFv1I6pPqN8=gFa0PtigKqGf1y8gQHp87UI_
> aO_4-U6WDGQjzKR6HdY= >. Material for the next tag.
> >
> >
> > On the other hand, I'm going to push two patches that had been
> > reviewed
> just
> > before we entered the *delayed* SFF:
> >
> >   INVALID URI REMOVED
> 3A__edk2.groups.io_g_devel_message_64345=DwIFbw=C5b8zRQO1m
> iGmBeVZ2LFWg=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E
> =Ezm_GF-
> Nrwz68WJSOEmoaYue4UtvI3AycFv1I6pPqN8=O19EomxNTCrUwxTvj-
> ptq6b9rN99JlWABtfXdpRzP-s=
> >   [PATCH 1/1] OvmfPkg/Bhyve: rename files to remove 'Pkg' infix
> >
> >   INVALID URI REMOVED
> 3A__edk2.groups.io_g_devel_message_62561=DwIFbw=C5b8zRQO1m
> iGmBeVZ2LFWg=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E
> =Ezm_GF-
>

回复: [edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 08/25/2020 6:30pm-7:30pm #cal-reminder

2020-08-24 Thread gaoliming

Hi, all

 The following issues will be reviewed this week. Most from abner.ch...@hpe.com 
  are about REST and Redfish. 

 


  2925

EDK2

Code

unassig...@tianocore.org

UNCO

CryptoPkg/Library/OpensslLib/process_files.pl missing copyright 
 

20:50:55

af...@apple.com


  2924

EDK2

Code

sean.bro...@microsoft.com

UNCO

HostUnitTestDscCompleteCheck: return value typo under DscPath file check 
 

08:40:38

ler...@redhat.com


  2909

EDK2

Code

abner.ch...@hpe.com

UNCO

TlsChildHandle is not cleared to NULL when HTTP EFI instance is reset 
 

Fri 03:04

abner.ch...@hpe.com


  2919

EDK2 Cod

Referenc

abner.ch...@hpe.com

UNCO

EFI Redfish BIOS resource provisioning transport protocol 
 

Fri 02:58

abner.ch...@hpe.com


  2918

EDK2 Cod

Referenc

abner.ch...@hpe.com

UNCO

Reference implement of EFI Redfish BIOS resource provisioning payload generator 
protocol  

Fri 02:35

abner.ch...@hpe.com


  2916

EDK2

Tools

abner.ch...@hpe.com

UNCO

Support Rest style in HII options in VFR compiler 
 

Fri 01:15

abner.ch...@hpe.com


  2915

EDK2

Code

abner.ch...@hpe.com

UNCO

Add definitions for HTTP Chunked Transfer 
 

Fri 01:04

abner.ch...@hpe.com


  2914

EDK2 Cod

Referenc

abner.ch...@hpe.com

UNCO

Reference implementation of EFI SOURCE CODING PROTOCOL 
 

Thu 12:05

abner.ch...@hpe.com


  2913

EDK2 Cod

Referenc

abner.ch...@hpe.com

UNCO

Implement the reference platform driver to provide 
EFI_REDFISH_PLATFORM_BIOS_RESOURCE_PROTOCOL 
 

Thu 11:53

abner.ch...@hpe.com


  2907

EDK2

Code

abner.ch...@hpe.com

UNCO

Implementation of UEFI spec 29.7.3 EFI_REST_JSON_STRUCTURE_PROTOCOL 
 

Thu 11:45

abner.ch...@hpe.com


  2906

EDK2

Code

abner.ch...@hpe.com

UNCO

Implementation of UEFI spec 31.1 Redfish Discover Protocol 
 

Thu 11:44

abner.ch...@hpe.com


  2908

EDK2

Code

abner.ch...@hpe.com

UNCO

Implementation of UEFI spec 29.7.2 EFI_REST_EX_PROTOCOL 
 

Thu 11:44

abner.ch...@hpe.com


  2910

EDK2 Cod

Referenc

abner.ch...@hpe.com

UNCO

EFI Redfish Credential Protocol 
 

Thu 11:44

abner.ch...@hpe.com


  2911

EDK2 Cod

Referenc

abner.ch...@hpe.com

UNCO

Reference Implementation of EFI Redfish Config Handler Protocol 
 

Thu 11:43

abner.ch...@hpe.com


  2912

EDK2 Cod

Referenc

abner.ch...@hpe.com

UNCO

Implementation of UEFI Redfish Host Interface Dxe 
 

Thu 11:43

abner.ch...@hpe.com

 

Thanks

Liming

发件人: bounce+27952+64589+4905953+8761...@groups.io 
 代表 devel@edk2.groups.io Calendar
发送时间: 2020年8月25日 9:30
收件人: devel@edk2.groups.io
主题: [edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 08/25/2020 
6:30pm-7:30pm #cal-reminder

 

Reminder: TianoCore Bug Triage - APAC / NAMO

When: Tuesday, 25 August 2020, 6:30pm to 7:30pm, (GMT-07:00) America/Los 
Angeles 

Where:https://bluejeans.com/889357567?src=join_info

View Event  

Organizer: Brian Richardson brian.richard...@intel.com 


Description: 

https://www.tianocore.org/bug-triage

 

Meeting URL

https://bluejeans.com/889357567?src=join_info

 

Meeting ID

889 357 567

 

Want to dial in from a phone?

Dial one of the following numbers:

+1.408.740.7256 (US (San Jose))

+1.408.317.9253 (US (Primary, San Jose))

 

(see all numbers -

[edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 08/25/2020 6:30pm-7:30pm #cal-reminder

2020-08-24 Thread devel@edk2.groups.io Calendar

*Reminder:* TianoCore Bug Triage - APAC / NAMO

*When:* Tuesday, 25 August 2020, 6:30pm to 7:30pm, (GMT-07:00) America/Los 
Angeles

*Where:* https://bluejeans.com/889357567?src=join_info

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

*Organizer:* Brian Richardson brian.richard...@intel.com ( 
brian.richard...@intel.com?subject=Re:%20Event:%20TianoCore%20Bug%20Triage%20-%20APAC%20%2F%20NAMO
 )

*Description:*

https://www.tianocore.org/bug-triage

Meeting URL

https://bluejeans.com/889357567?src=join_info

Meeting ID

889 357 567

Want to dial in from a phone?

Dial one of the following numbers:

+1.408.740.7256 (US (San Jose))

+1.408.317.9253 (US (Primary, San Jose))

(see all numbers - https://www.bluejeans.com/numbers)

Enter the meeting ID and passcode followed by #

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64589): https://edk2.groups.io/g/devel/message/64589
Mute This Topic: https://groups.io/mt/76398801/21656
Mute #cal-reminder: https://groups.io/g/edk2/mutehashtag/cal-reminder
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

回复: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

2020-08-24 Thread gaoliming

Laszlo:
  Thanks for your great support. 

  I merge SmBios type 42 patch @ 78ab44cb96808bd3ff0edf312599f94a6a92172a.

Thanks
Liming
> -邮件原件-
> 发件人: bounce+27952+64572+4905953+8761...@groups.io
>  代表 Laszlo Ersek
> 发送时间: 2020年8月24日 21:38
> 收件人: gaoliming ; 'Leif Lindholm'
> ; af...@apple.com; 'Kinney, Michael D'
> ; 'Guptha, Soumya K'
> 
> 抄送: devel@edk2.groups.io; annou...@edk2.groups.io; 'Chang, Abner (HPS
> SW/FW Technologist)' ; qi1.zh...@intel.com;
> marcello.ba...@9elements.com
> 主题: Re: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-24
for
> edk2-stable202008
> 
> Hi Liming,
> 
> On 08/24/20 03:49, gaoliming wrote:
> > Hi, all
> >
> > Based on the discussion https://edk2.groups.io/g/devel/message/64493,
> > we make the conclusion to defer one week for edk2-stable202008 to
> > include the important patch for RiscV. Soft Feature Freeze (SFF) will
> > start from today (2020-08-24). Below is new edk2-stable202008 tag
> > planning proposed schedule
> >
>
 ing>.
> > If you have any comments, please raise it.
> >
> >
> > Date (00:00:00 UTC-8) Description
> > 2020-06-03Beginning of development
> > 2020-08-07Feature Planning Freeze
> > 2020-08-24Soft Feature Freeze
> > 2020-08-28Hard Feature Freeze
> > 2020-09-04Release
> >
> > Because SFF date is changed, if the patches passed code review before
> > SFF date (2020-08-24), the patches can still be merged for this stable
> > tag. Here is the patch list those passed code review before new SFF
> > date. For below features, I will let the feature owner decides whether
> > to merge it for this stable tag.
> 
> As of this writing:
> 
> - Mon Aug 24 12:59:59 UTC 2020
> 
> we've entered the (new) Soft Feature Freeze. (The SFF date is 2020-08-24
> 00:00:00 UTC-8; in UTC, that's Mon Aug 24 08:00:00 UTC 2020 -- about five
> hours ago.)
> 
> So:
> 
> > Feature List:
> >
> > https://edk2.groups.io/g/devel/message/63767
> > [PATCH] EmbeddedPkg/libfdt: Add strncmp macro to use AsciiStrnCmp
> 
> I'm going to merge this soon (with Leif's review).
> 
> > https://edk2.groups.io/g/devel/message/64363
> > [PATCH v5 0/3] UefiPayloadPkg: Runtime MMCONF
> 
> The UefiPayloadPkg patches in the series (#1, #3) have not received
reviews.
> We have to delay this until after the stable tag.
> 
> > https://edk2.groups.io/g/devel/message/64354
> > [PATCH v4 0/8] Need add a FSP binary measurement
> 
> The SecurityPkg patches have not been approved yet, and Bret and Jiewen
> are still testing / discussing (as far as I understand):
> . Material for the next tag.
> 
> 
> On the other hand, I'm going to push two patches that had been reviewed
just
> before we entered the *delayed* SFF:
> 
>   https://edk2.groups.io/g/devel/message/64345
>   [PATCH 1/1] OvmfPkg/Bhyve: rename files to remove 'Pkg' infix
> 
>   https://edk2.groups.io/g/devel/message/62561
>   [PATCH] OvmfPkg/SmmControl2Dxe: negotiate
> ICH9_LPC_SMI_F_CPU_HOTPLUG
> 
> > Bug List:
> >
> > https://edk2.groups.io/g/devel/message/50406
> > [PATCH 1/1] MdePkg/Include: Add missing definitions of SMBIOS type 42h
> > in SmBios.h
> 
> Liming, can you please merge this patch? For some reason I can't see it in
my
> local archives! (Only responses to it.)
> 
> > https://edk2.groups.io/g/devel/message/64507
> > [PATCH v2 1/1] UefiCpuPkg/MpInitLib: Always initialize the DoDecrement
> > variable
> 
> I'm going to merge this soon.
> 
> > https://edk2.groups.io/g/devel/message/64539
> > [PATCH] Maintainers.txt: Update Liming mail address
> 
> I'll merge this one as well.
> 
> > https://edk2.groups.io/g/devel/message/64529
> > [PATCH] .pytool/EccCheck: Disable Ecc error code 10014 for open CI
> 
> Already merged as commit d4e0b9607c9a.
> 
> >
> > https://edk2.groups.io/g/devel/message/61938
> > [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix buffer overrun in
> > FileHandleReadLine()
> 
> I'll merge it.
> 
> Thanks!
> Laszlo
> 
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64588): https://edk2.groups.io/g/devel/message/64588
Mute This Topic: https://groups.io/mt/76398678/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 2/2] CryptoPkg/OpensslLib: Commit the auto-generated assembly files for X64

2020-08-24 Thread Andrew Fish via groups.io




> On Aug 19, 2020, at 11:06 AM, Laszlo Ersek  wrote:
> 
> On 08/19/20 17:37, Andrew Fish via groups.io wrote:
>> 
>> 
>>> On Aug 18, 2020, at 2:22 PM, Zurcher, Christopher J 
>>>  wrote:
>>> 
>>> Per the added header comment in process_files.pl:
>>> 
>>> # Due to the script wrapping required to process the OpenSSL
>>> # configuration data, each native architecture must be processed
>>> # individually by the maintainer (in addition to the standard version):
>>> #   ./process_files.pl
>> 
>> Side note: process_file.pl is missing a copyright statement. 
> 
> True :(
> 
> Andrew, could you please report a BZ about it?
> 

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

> Thanks!
> Laszlo
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64587): https://edk2.groups.io/g/devel/message/64587
Mute This Topic: https://groups.io/mt/75978613/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 2/6] FmpDevicePkg: Add LastAttemptStatus.h

2020-08-24 Thread Michael Kubacki

Can you provide an example of how you expect the namespace 
identifier/error code token to be used?


Thanks,
Michael

On 8/24/2020 10:22 AM, Desimone, Nathaniel L wrote:

Ah interesting. So you are more concerned about the namespace that the error 
code comes from as opposed to the actual meaning of the error code itself.

That brings another piece of feedback to mind, generally in UEFI namespaces are 
established using GUIDs... would it be more appropriate to decompose this into a GUID 
namespace identifier plus an error code integer token? That would eliminate the need for 
any knowledge of the integer values of the error codes outside of the producing module 
and seems to follow the "Single Responsibility Principle" 
(https://en.wikipedia.org/wiki/Single-responsibility_principle) more closely.

Thanks,
Nate

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Friday, August 21, 2020 2:24 PM
To: Desimone, Nathaniel L ; devel@edk2.groups.io
Cc: Gao, Liming ; Kinney, Michael D ; 
Jiang, Guomin ; Xu, Wei6 
Subject: Re: [edk2-devel] [PATCH v2 2/6] FmpDevicePkg: Add LastAttemptStatus.h

Hi Nate,

Yes, these are individual codes used within FmpDevicePkg. The specific error 
codes in the enum in v2 are not intended to be used outside FmpDevicePkg. I 
refactored this in v3.

What is desired is a way to consistently map error codes to specific error 
sources during the update flow. The codes might come from common FmpDevicePkg 
source code (like FmpDxe) or platform authored source code (like FmpDeviceLib). 
The exact codes used in FmpDevicePkg implementation do not necessarily need to 
be known to the library (it doesn't receive those as input) and the library is 
free to define codes for its own library instance implementation to use as 
output. For example, there might be cases where the FmpDxe driver and a 
FmpDeviceLib instance both define a similar error code (e.g. memory allocation 
failed) but the specific value leads to a particular error condition in either 
component.

At the moment, FmpDevicePkg implementation and FmpDeviceLib instances are the 
two high-level pieces involved in producing error codes so within the overall 
0x1000 - 0x3FFF range available, they're each be assigned an overall range in 
the public header of length 0x800 (in v4) leaving 0x2000 for future expansion. 
In V3, this led to the ranges being defined in a public header but the specific 
error codes in the enum being defined in a private header.

Thanks,
Michael

On 8/20/2020 10:33 PM, Desimone, Nathaniel L wrote:

Hi Michael,

I guess I might not understand the exact use cases for the enum. It seems like 
the meaning of the error codes you only want to be known within FmpDevicePkg, 
but it appears to me that the error code values could traverse to drivers 
outside this package, is that correct?

Thanks,
Nate

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael
Kubacki
Sent: Tuesday, August 11, 2020 11:58 AM
To: Desimone, Nathaniel L ;
devel@edk2.groups.io
Cc: Gao, Liming ; Kinney, Michael D
; Jiang, Guomin ;
Xu, Wei6 
Subject: Re: [edk2-devel] [PATCH v2 2/6] FmpDevicePkg: Add
LastAttemptStatus.h

I realized there is room for misinterpretation of the macros 
LAST_ATTEMPT_STATUS_DRIVER_ERROR_COUNT and 
LAST_ATTEMPT_STATUS_DEPENDENCY_ERROR_COUNT based on name.

If there's no further feedback on the topic, I'll change them to 
LAST_ATTEMPT_STATUS_DRIVER_ERROR_RANGE_LENGTH and 
LAST_ATTEMPT_STATUS_DEPENDENCY_ERROR_RANGE_LENGTH.

Thanks,
Michael

On 8/11/2020 10:46 AM, Michael Kubacki wrote:

#1: In v3, I'm going to split it such that the defines are in the
public header and the enum specifying the internal driver and
dependency ranges are in a private header to FmpDevicePkg.

Here's the current set of v3 changes to agree upon before sending a series:
1. Move the defines for the ranges to a public header 2. Move the
enum to a private instance file 3. Rename
LAST_ATTEMPT_STATUS_LIBRARY_ERROR_MIN_ERROR_CODE to
LAST_ATTEMPT_STATUS_DEVICE_LIBRARY_ERROR_MIN_ERROR_CODE
4. Include a comment to explicitly state new codes within a given
range must be added at the end of the range

Please let me know if there's any further feedback.

Thanks,
Michael

On 8/10/2020 5:31 PM, Desimone, Nathaniel L wrote:

My feedback:

#1: Why is LastAttemptStatus.h in PrivateInclude? Seems like
something you would want to have as a public header.

#2: If someone inserts a new enum value in the middle of
LAST_ATTEMPT_STATUS_EXPANDED_ERROR_LIST it will make it difficult to
decode error codes in the future. Either put a comment that new
error code should go on the bottom. Or add some space between each
entry using something like this:

enum LAST_ATTEMPT_STATUS_EXPANDED_ERROR_LIST
{
     LAST_ATTEMPT_STATUS_DRIVER_ERROR_GET_FMP_HEADER =
LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MIN,
     LAST_ATTEMPT_STATUS_DRIVER_ERROR_PROGRESS_CALLBACK_ERROR =

Re: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native instruction support for X64

2020-08-24 Thread Yao, Jiewen

Below:

> -Original Message-
> From: Zurcher, Christopher J 
> Sent: Tuesday, August 25, 2020 5:26 AM
> To: devel@edk2.groups.io; Zurcher, Christopher J
> ; Yao, Jiewen 
> Cc: Wang, Jian J ; Lu, XiaoyuX ;
> Ard Biesheuvel 
> Subject: RE: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native
> instruction support for X64
> 
> 1) I have confirmed that the ApiHooks.c file is still required even without 
> the AVX
> instructions included. The x86_64 assembly files in OpenSSL set a flag called
> $win64 and automatically include calls to the RtlVirtualUnwind function if 
> NASM
> is selected as the assembler scheme.
> 
> https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-
> rtlvirtualunwind
> 
> I have submitted an issue against OpenSSL since I don't think using the NASM
> assembler should force the inclusion of Windows-specific API hooks, but that
> change cannot be made in OpenSSL 1.1.1 and we will have to wait for OpenSSL 3
> or later to remove the stub function.
> 
> https://github.com/openssl/openssl/issues/12712
> 

[Jiewen] Thanks.

> 2) So far I have only built with VS.
> 

[Jiewen] I think we need support build with GCC and LLVM, and with X64.


> 3) The X64 SHA256 implementation was successfully exercised across a large
> number of devices in a production environment as a verification step in a 
> multi-
> GB data transfer scenario.
> 

[Jiewen] Since you also add other sha (sha1, sha512) and aesni, I think those 
need unit test for them too.


> Thanks,
> Christopher Zurcher
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Zurcher,
> > Christopher J
> > Sent: Tuesday, August 18, 2020 15:50
> > To: Yao, Jiewen ; devel@edk2.groups.io
> > Cc: Wang, Jian J ; Lu, XiaoyuX
> ;
> > Ard Biesheuvel 
> > Subject: Re: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native
> > instruction support for X64
> >
> > After further review, the ApiHooks.c file may no longer be needed since we
> > are no longer including the AVX instructions. I will look over the
> > dependencies and send a new patch set if I can eliminate the API hooks file.
> >
> > Thanks,
> > Christopher Zurcher
> >
> > > -Original Message-
> > > From: Yao, Jiewen 
> > > Sent: Thursday, August 13, 2020 08:04
> > > To: Zurcher, Christopher J ;
> > > devel@edk2.groups.io
> > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > ;
> > > Ard Biesheuvel 
> > > Subject: RE: [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native instruction
> > > support for X64
> > >
> > > Hi Christopher
> > > Thanks.
> > >
> > > 1) Would you please help me understand more on "ApiHooks.c contains a
> stub
> > > function for a Windows API call" ?
> > > Why we need this?
> > > If it is compiler specific in openssl, should we submit patch to openssl 
> > > to
> > > exclude this with OPENSSL_SYS_UEFI? That should be a cleaner solution for
> > > UEFI.
> > >
> > > 2) Would you please describe what compiler you have tried? VS? GCC? LLVM?
> > >
> > > 3) Would you please describe what unit test you have done?
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > >
> > > > -Original Message-
> > > > From: Zurcher, Christopher J 
> > > > Sent: Tuesday, August 4, 2020 8:24 AM
> > > > To: devel@edk2.groups.io
> > > > Cc: Yao, Jiewen ; Wang, Jian J
> > > ;
> > > > Lu, XiaoyuX ; Ard Biesheuvel
> > > 
> > > > Subject: [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native instruction
> > > support
> > > > for X64
> > > >
> > > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2507
> > > >
> > > > Adding OpensslLibX64.inf and modifying process_files.pl to process this
> > > > file and generate the necessary assembly files.
> > > > ApiHooks.c contains a stub function for a Windows API call.
> > > > uefi-asm.conf contains the limited assembly configurations for OpenSSL.
> > > >
> > > > Cc: Jiewen Yao 
> > > > Cc: Jian J Wang 
> > > > Cc: Xiaoyu Lu 
> > > > Cc: Ard Biesheuvel 
> > > > Signed-off-by: Christopher J Zurcher 
> > > > ---
> > > >  CryptoPkg/Library/OpensslLib/OpensslLib.inf  |   2 +-
> > > >  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf|   2 +-
> > > >  CryptoPkg/Library/OpensslLib/OpensslLibX64.inf   | 656
> > > > 
> > > >  CryptoPkg/Library/Include/openssl/opensslconf.h  |   3 -
> > > >  CryptoPkg/Library/OpensslLib/ApiHooks.c  |  18 +
> > > >  CryptoPkg/Library/OpensslLib/OpensslLibConstructor.c |  34 +
> > > >  CryptoPkg/Library/OpensslLib/process_files.pl| 223 +--
> > > >  CryptoPkg/Library/OpensslLib/uefi-asm.conf   |  15 +
> > > >  8 files changed, 903 insertions(+), 50 deletions(-)
> > > >
> > > > diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > > > b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > > > index dbbe5386a1..bd62d86936 100644
> > > > --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > > > +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > > > @@ -16,7 +16,7 @@
> > > >VERSION_STRING = 1.0
> > > >
> > >

Re: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native instruction support for X64

2020-08-24 Thread Zurcher, Christopher J

1) I have confirmed that the ApiHooks.c file is still required even without the 
AVX instructions included. The x86_64 assembly files in OpenSSL set a flag 
called $win64 and automatically include calls to the RtlVirtualUnwind function 
if NASM is selected as the assembler scheme.

https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlvirtualunwind

I have submitted an issue against OpenSSL since I don't think using the NASM 
assembler should force the inclusion of Windows-specific API hooks, but that 
change cannot be made in OpenSSL 1.1.1 and we will have to wait for OpenSSL 3 
or later to remove the stub function.

https://github.com/openssl/openssl/issues/12712

2) So far I have only built with VS.

3) The X64 SHA256 implementation was successfully exercised across a large 
number of devices in a production environment as a verification step in a 
multi-GB data transfer scenario.

Thanks,
Christopher Zurcher

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Zurcher,
> Christopher J
> Sent: Tuesday, August 18, 2020 15:50
> To: Yao, Jiewen ; devel@edk2.groups.io
> Cc: Wang, Jian J ; Lu, XiaoyuX ;
> Ard Biesheuvel 
> Subject: Re: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native
> instruction support for X64
> 
> After further review, the ApiHooks.c file may no longer be needed since we
> are no longer including the AVX instructions. I will look over the
> dependencies and send a new patch set if I can eliminate the API hooks file.
> 
> Thanks,
> Christopher Zurcher
> 
> > -Original Message-
> > From: Yao, Jiewen 
> > Sent: Thursday, August 13, 2020 08:04
> > To: Zurcher, Christopher J ;
> > devel@edk2.groups.io
> > Cc: Wang, Jian J ; Lu, XiaoyuX
> ;
> > Ard Biesheuvel 
> > Subject: RE: [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native instruction
> > support for X64
> >
> > Hi Christopher
> > Thanks.
> >
> > 1) Would you please help me understand more on "ApiHooks.c contains a stub
> > function for a Windows API call" ?
> > Why we need this?
> > If it is compiler specific in openssl, should we submit patch to openssl to
> > exclude this with OPENSSL_SYS_UEFI? That should be a cleaner solution for
> > UEFI.
> >
> > 2) Would you please describe what compiler you have tried? VS? GCC? LLVM?
> >
> > 3) Would you please describe what unit test you have done?
> >
> > Thank you
> > Yao Jiewen
> >
> >
> > > -Original Message-
> > > From: Zurcher, Christopher J 
> > > Sent: Tuesday, August 4, 2020 8:24 AM
> > > To: devel@edk2.groups.io
> > > Cc: Yao, Jiewen ; Wang, Jian J
> > ;
> > > Lu, XiaoyuX ; Ard Biesheuvel
> > 
> > > Subject: [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native instruction
> > support
> > > for X64
> > >
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2507
> > >
> > > Adding OpensslLibX64.inf and modifying process_files.pl to process this
> > > file and generate the necessary assembly files.
> > > ApiHooks.c contains a stub function for a Windows API call.
> > > uefi-asm.conf contains the limited assembly configurations for OpenSSL.
> > >
> > > Cc: Jiewen Yao 
> > > Cc: Jian J Wang 
> > > Cc: Xiaoyu Lu 
> > > Cc: Ard Biesheuvel 
> > > Signed-off-by: Christopher J Zurcher 
> > > ---
> > >  CryptoPkg/Library/OpensslLib/OpensslLib.inf  |   2 +-
> > >  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf|   2 +-
> > >  CryptoPkg/Library/OpensslLib/OpensslLibX64.inf   | 656
> > > 
> > >  CryptoPkg/Library/Include/openssl/opensslconf.h  |   3 -
> > >  CryptoPkg/Library/OpensslLib/ApiHooks.c  |  18 +
> > >  CryptoPkg/Library/OpensslLib/OpensslLibConstructor.c |  34 +
> > >  CryptoPkg/Library/OpensslLib/process_files.pl| 223 +--
> > >  CryptoPkg/Library/OpensslLib/uefi-asm.conf   |  15 +
> > >  8 files changed, 903 insertions(+), 50 deletions(-)
> > >
> > > diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > > b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > > index dbbe5386a1..bd62d86936 100644
> > > --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > > +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > > @@ -16,7 +16,7 @@
> > >VERSION_STRING = 1.0
> > >
> > >LIBRARY_CLASS  = OpensslLib
> > >
> > >DEFINE OPENSSL_PATH= openssl
> > >
> > > -  DEFINE OPENSSL_FLAGS   = -DL_ENDIAN -DOPENSSL_SMALL_FOOTPRINT
> > > -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE
> > >
> > > +  DEFINE OPENSSL_FLAGS   = -DL_ENDIAN -DOPENSSL_SMALL_FOOTPRINT
> > > -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -
> > > DOPENSSL_NO_ASM
> > >
> > >
> > >
> > >  #
> > >
> > >  #  VALID_ARCHITECTURES   = IA32 X64 ARM AARCH64
> > >
> > > diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> > > b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> > > index 616ccd9f62..2b7324a990 100644
> > > --- a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> > > +++

Re: [edk2-devel] [PATCH v6 1/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

2020-08-24 Thread Laszlo Ersek

Hi Vladimir,

On 08/21/20 18:05, Vladimir Olovyannikov via groups.io wrote:
> Introduce an http client utilizing EDK2 HTTP protocol, to
> allow fast image downloading from http/https servers.
> HTTP download speed is usually faster than tftp.
> The client is based on the same approach as tftp dynamic command, and
> uses the same UEFI Shell command line parameters. This makes it easy
> integrating http into existing UEFI Shell scripts.
> Note that to enable HTTP download, feature Pcd
> gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must
> be set to TRUE.
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860
> 
> Signed-off-by: Vladimir Olovyannikov 
> Cc: Samer El-Haj-Mahmoud 
> Cc: Laszlo Ersek 
> Cc: Zhichao Gao 
> Cc: Maciej Rabeda 
> Cc: Jiaxin Wu 
> Cc: Siyuan Fu 
> Cc: Ray Ni 
> Cc: Liming Gao 
> Cc: Nd 
> ---
>  ShellPkg/ShellPkg.dec |1 +
>  ShellPkg/ShellPkg.dsc |5 +
>  .../HttpDynamicCommand/HttpApp.inf|   58 +
>  .../HttpDynamicCommand/HttpDynamicCommand.inf |   63 +
>  .../DynamicCommand/HttpDynamicCommand/Http.h  |   88 +
>  ShellPkg/Include/Guid/ShellLibHiiGuid.h   |5 +
>  .../DynamicCommand/HttpDynamicCommand/Http.c  | 1693 +
>  .../HttpDynamicCommand/HttpApp.c  |   61 +
>  .../HttpDynamicCommand/HttpDynamicCommand.c   |  137 ++
>  CryptoPkg/Library/OpensslLib/openssl  |2 +-
>  .../HttpDynamicCommand/Http.uni   |  116 ++
>  11 files changed, 2228 insertions(+), 1 deletion(-)
>  create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
>  create mode 100644 
> ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf
>  create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.h
>  create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.c
>  create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.c
>  create mode 100644 
> ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.c
>  create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.uni

[...]

> diff --git a/CryptoPkg/Library/OpensslLib/openssl 
> b/CryptoPkg/Library/OpensslLib/openssl
> index e2e09d9fba11..c3656cc594da 16
> --- a/CryptoPkg/Library/OpensslLib/openssl
> +++ b/CryptoPkg/Library/OpensslLib/openssl
> @@ -1 +1 @@
> -Subproject commit e2e09d9fba1187f8d6aafaa34d4172f56f1ffb72
> +Subproject commit c3656cc594daac8167721dde7220f0e59ae146fc

your patch includes a hunk that moves our openssl submodule from 1.1.1g
back to ~1.1.1d.

I think that must be unintentional; can you please drop this hunk and
post v7?

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64583): https://edk2.groups.io/g/devel/message/64583
Mute This Topic: https://groups.io/mt/76332046/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Maintainers.txt: Update Liming mail address

2020-08-24 Thread Laszlo Ersek

On 08/21/20 16:49, gaoliming wrote:
> Signed-off-by: Liming Gao 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> ---
>  Maintainers.txt | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)

Merged as commit aad9cba85fb7, via
.

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64582): https://edk2.groups.io/g/devel/message/64582
Mute This Topic: https://groups.io/mt/76332353/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] UefiCpuPkg/MpInitLib: Always initialize the DoDecrement variable

2020-08-24 Thread Laszlo Ersek

On 08/20/20 16:53, Lendacky, Thomas wrote:
> From: Tom Lendacky 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2901
> 
> The DoDecrement variable in ApWakeupFunction () wasn't always being
> initialized. Update the code to always fully initialize it.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Signed-off-by: Tom Lendacky 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index 90416c81b616..07426274f639 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -885,9 +885,7 @@ ApWakeupFunction (
>UINT64Status;
>BOOLEAN   DoDecrement;
>  
> -  if (CpuMpData->InitFlag == ApInitConfig) {
> -DoDecrement = TRUE;
> -  }
> +  DoDecrement = (BOOLEAN) (CpuMpData->InitFlag == ApInitConfig);
>  
>while (TRUE) {
>  Msr.GhcbPhysicalAddress = AsmReadMsr64 (MSR_SEV_ES_GHCB);
> 

Merged as commit 48a83481d2a2, via
.

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64581): https://edk2.groups.io/g/devel/message/64581
Mute This Topic: https://groups.io/mt/76309738/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] OvmfPkg/Bhyve: rename files to remove 'Pkg' infix

2020-08-24 Thread Laszlo Ersek

On 08/18/20 10:56, Laszlo Ersek wrote:
> On 08/18/20 04:21, Peter Grehan wrote:
>> Reviewed-by: Peter Grehan 
> 
> Reviewed-by: Laszlo Ersek 
> 
> I'll merge this after the stable tag (it's neither a feature nor a
> bugfix -- I'd say it is a cleanup, and so I'd not like it to add any
> noise to the feature freezes).

Because review completed before the (extended) SFF deadline, I've now
merged this patch. Commit hash ad40eb4e6c9d, github PR
.

Thanks,
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64580): https://edk2.groups.io/g/devel/message/64580
Mute This Topic: https://groups.io/mt/76257809/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] EmbeddedPkg/libfdt: Add strncmp macro to use AsciiStrnCmp

2020-08-24 Thread Laszlo Ersek

On 08/18/20 20:04, Leif Lindholm wrote:
> On Thu, Aug 06, 2020 at 10:34:21 +0800, Abner Chang wrote:
>> For the implementation which utilizes libfdt provided in EmbeddedPkg
>> however it uses strncmp function in the libfdt helper library,
>> libfdt_env.h should provide the macro implied with edk2 strncmp
>> implementation.
>>
>> The example is RISC-V OpenSBI library. edk2 RISC-V port uses OpenSBI
>> library and incorporate with edk2 libfdt. edk2 libfdt_env.h provides
>> the necessary macros to build OpenSBI which uses fdt functions in edk2
>> environment. However, OpenSBI also has libfdt helper library that uses
>> strncmp function which is not defined in edk2 libfdt_env.h. This commit
>> addresses the build issue caused by missing strncmp macro in
>> libfdt_env.h.
>>
>> Check below three commits for the corresponding changes on OpenSBI,
>> https://github.com/riscv/opensbi/commit/8e47649eff96c303e02fbd58cdc6c4ed341066ec
>> https://github.com/riscv/opensbi/commit/2845d2d2cf4fb74a89452ba223995aa4a118c07e
>> https://github.com/riscv/opensbi/commit/2cfd2fc9048806353298a1b967abf985901e36e8
>>
>> Signed-off-by: Abner Chang 
>>
>> Cc: Leif Lindholm 
>> Cc: Ard Biesheuvel 
>> Cc: Daniel Schaefer 
> 
> Whoops, I failed to file this away in my queue - apologies.
> Many thanks for fixing this in opensbi.
> Reviewed-by: Leif Lindholm 

Merged as commit 019f513a19f8, via
.

If there is an associated TianoCore BZ (the commit message does not
mention one), please flip it to RESOLVED|FIXED, and mark the commit hash
on it.

Thanks,
Laszlo

> 
> 
>> ---
>>  EmbeddedPkg/Include/libfdt_env.h | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/EmbeddedPkg/Include/libfdt_env.h 
>> b/EmbeddedPkg/Include/libfdt_env.h
>> index 11a9764733..7feff52bc0 100644
>> --- a/EmbeddedPkg/Include/libfdt_env.h
>> +++ b/EmbeddedPkg/Include/libfdt_env.h
>> @@ -76,4 +76,8 @@ static inline size_t strnlen (const char* str, size_t 
>> strsz ) {
>>return AsciiStrnLenS (str, strsz);
>>  }
>>  
>> +static inline size_t strncmp (const char* str1, const char* str2, size_t 
>> strsz ) {
>> +  return AsciiStrnCmp (str1, str2, strsz);
>> +}
>> +
>>  #endif /* _LIBFDT_ENV_H */
>> -- 
>> 2.25.0
>>
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64579): https://edk2.groups.io/g/devel/message/64579
Mute This Topic: https://groups.io/mt/76021725/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 2/6] FmpDevicePkg: Add LastAttemptStatus.h

2020-08-24 Thread Nate DeSimone

Ah interesting. So you are more concerned about the namespace that the error 
code comes from as opposed to the actual meaning of the error code itself.

That brings another piece of feedback to mind, generally in UEFI namespaces are 
established using GUIDs... would it be more appropriate to decompose this into 
a GUID namespace identifier plus an error code integer token? That would 
eliminate the need for any knowledge of the integer values of the error codes 
outside of the producing module and seems to follow the "Single Responsibility 
Principle" (https://en.wikipedia.org/wiki/Single-responsibility_principle) more 
closely.

Thanks,
Nate

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Friday, August 21, 2020 2:24 PM
To: Desimone, Nathaniel L ; devel@edk2.groups.io
Cc: Gao, Liming ; Kinney, Michael D 
; Jiang, Guomin ; Xu, Wei6 

Subject: Re: [edk2-devel] [PATCH v2 2/6] FmpDevicePkg: Add LastAttemptStatus.h

Hi Nate,

Yes, these are individual codes used within FmpDevicePkg. The specific error 
codes in the enum in v2 are not intended to be used outside FmpDevicePkg. I 
refactored this in v3.

What is desired is a way to consistently map error codes to specific error 
sources during the update flow. The codes might come from common FmpDevicePkg 
source code (like FmpDxe) or platform authored source code (like FmpDeviceLib). 
The exact codes used in FmpDevicePkg implementation do not necessarily need to 
be known to the library (it doesn't receive those as input) and the library is 
free to define codes for its own library instance implementation to use as 
output. For example, there might be cases where the FmpDxe driver and a 
FmpDeviceLib instance both define a similar error code (e.g. memory allocation 
failed) but the specific value leads to a particular error condition in either 
component.

At the moment, FmpDevicePkg implementation and FmpDeviceLib instances are the 
two high-level pieces involved in producing error codes so within the overall 
0x1000 - 0x3FFF range available, they're each be assigned an overall range in 
the public header of length 0x800 (in v4) leaving 0x2000 for future expansion. 
In V3, this led to the ranges being defined in a public header but the specific 
error codes in the enum being defined in a private header.

Thanks,
Michael

On 8/20/2020 10:33 PM, Desimone, Nathaniel L wrote:
> Hi Michael,
> 
> I guess I might not understand the exact use cases for the enum. It seems 
> like the meaning of the error codes you only want to be known within 
> FmpDevicePkg, but it appears to me that the error code values could traverse 
> to drivers outside this package, is that correct?
> 
> Thanks,
> Nate
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael 
> Kubacki
> Sent: Tuesday, August 11, 2020 11:58 AM
> To: Desimone, Nathaniel L ; 
> devel@edk2.groups.io
> Cc: Gao, Liming ; Kinney, Michael D 
> ; Jiang, Guomin ; 
> Xu, Wei6 
> Subject: Re: [edk2-devel] [PATCH v2 2/6] FmpDevicePkg: Add 
> LastAttemptStatus.h
> 
> I realized there is room for misinterpretation of the macros 
> LAST_ATTEMPT_STATUS_DRIVER_ERROR_COUNT and 
> LAST_ATTEMPT_STATUS_DEPENDENCY_ERROR_COUNT based on name.
> 
> If there's no further feedback on the topic, I'll change them to 
> LAST_ATTEMPT_STATUS_DRIVER_ERROR_RANGE_LENGTH and 
> LAST_ATTEMPT_STATUS_DEPENDENCY_ERROR_RANGE_LENGTH.
> 
> Thanks,
> Michael
> 
> On 8/11/2020 10:46 AM, Michael Kubacki wrote:
>> #1: In v3, I'm going to split it such that the defines are in the 
>> public header and the enum specifying the internal driver and 
>> dependency ranges are in a private header to FmpDevicePkg.
>>
>> Here's the current set of v3 changes to agree upon before sending a series:
>> 1. Move the defines for the ranges to a public header 2. Move the 
>> enum to a private instance file 3. Rename 
>> LAST_ATTEMPT_STATUS_LIBRARY_ERROR_MIN_ERROR_CODE to 
>> LAST_ATTEMPT_STATUS_DEVICE_LIBRARY_ERROR_MIN_ERROR_CODE
>> 4. Include a comment to explicitly state new codes within a given 
>> range must be added at the end of the range
>>
>> Please let me know if there's any further feedback.
>>
>> Thanks,
>> Michael
>>
>> On 8/10/2020 5:31 PM, Desimone, Nathaniel L wrote:
>>> My feedback:
>>>
>>> #1: Why is LastAttemptStatus.h in PrivateInclude? Seems like 
>>> something you would want to have as a public header.
>>>
>>> #2: If someone inserts a new enum value in the middle of 
>>> LAST_ATTEMPT_STATUS_EXPANDED_ERROR_LIST it will make it difficult to 
>>> decode error codes in the future. Either put a comment that new 
>>> error code should go on the bottom. Or add some space between each 
>>> entry using something like this:
>>>
>>> enum LAST_ATTEMPT_STATUS_EXPANDED_ERROR_LIST
>>> {
>>>     LAST_ATTEMPT_STATUS_DRIVER_ERROR_GET_FMP_HEADER = 
>>> LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MIN,
>>>     LAST_ATTEMPT_STATUS_DRIVER_ERROR_PROGRESS_CALLBACK_ERROR = 
>>>

Re: [edk2-devel] [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix buffer overrun in FileHandleReadLine()

2020-08-24 Thread Laszlo Ersek

On 08/24/20 18:18, Laszlo Ersek wrote:
> On 07/03/20 04:30, Zhiguang Liu wrote:
>> Reviewed-by: Zhiguang Liu 
> 
> Merged as commit 4535fc312b76, via
> .

The commit message does not mention a TianoCore BZ. If there *is* an
associated TianoCore BZ, please set it to RESOLVED|FIXED now, and also
mark the above commit hash in a comment on it.

Thanks
Laszlo

> 
> Thanks,
> Laszlo
> 
>>
>>> -Original Message-
>>> From: devel@edk2.groups.io  On Behalf Of Vladimir
>>> Olovyannikov via groups.io
>>> Sent: Thursday, July 2, 2020 10:31 AM
>>> To: devel@edk2.groups.io
>>> Cc: Vladimir Olovyannikov ; Kinney,
>>> Michael D ; Gao, Liming
>>> ; Liu, Zhiguang 
>>> Subject: [edk2-devel] [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix buffer
>>> overrun in FileHandleReadLine()
>>>
>>> If the size of the supplied buffer in FileHandleReadLine(), module
>>> UefiFileHandleLib.c, was not 0, but was not enough to fit in
>>> the line, the size is increased, and then the Buffer of the new
>>> size is zeroed. This size is always larger than the supplied buffer size,
>>> causing supplied buffer overrun. Fix the issue by using the
>>> supplied buffer size in ZeroMem().
>>>
>>> Signed-off-by: Vladimir Olovyannikov
>>> 
>>> Cc: Michael D Kinney 
>>> Cc: Liming Gao 
>>> Cc: Zhiguang Liu 
>>> ---
>>>  MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 6 --
>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
>>> b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
>>> index 28e28e5f67d5..ab34e6ccd5f4 100644
>>> --- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
>>> +++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
>>> @@ -969,6 +969,7 @@ FileHandleReadLine(
>>>UINTN   CharSize;
>>>
>>>UINTN   CountSoFar;
>>>
>>>UINTN   CrCount;
>>>
>>> +  UINTN   OldSize;
>>>
>>>UINT64  OriginalFilePosition;
>>>
>>>
>>>
>>>if (Handle == NULL
>>>
>>> @@ -1039,10 +1040,11 @@ FileHandleReadLine(
>>>// if we ran out of space tell when...
>>>
>>>//
>>>
>>>if ((CountSoFar+1-CrCount)*sizeof(CHAR16) > *Size){
>>>
>>> +OldSize = *Size;
>>>
>>>  *Size = (CountSoFar+1-CrCount)*sizeof(CHAR16);
>>>
>>>  if (!Truncate) {
>>>
>>> -  if (Buffer != NULL && *Size != 0) {
>>>
>>> -ZeroMem(Buffer, *Size);
>>>
>>> +  if (Buffer != NULL && OldSize != 0) {
>>>
>>> +ZeroMem(Buffer, OldSize);
>>>
>>>}
>>>
>>>FileHandleSetPosition(Handle, OriginalFilePosition);
>>>
>>>return (EFI_BUFFER_TOO_SMALL);
>>>
>>> --
>>> 2.26.2.266.ge870325ee8
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64577): https://edk2.groups.io/g/devel/message/64577
Mute This Topic: https://groups.io/mt/75251007/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg/SmmControl2Dxe: negotiate ICH9_LPC_SMI_F_CPU_HOTPLUG

2020-08-24 Thread Laszlo Ersek

On 08/21/20 15:53, Laszlo Ersek wrote:
> Hi Ard,
> 
> can you please ACK this patch?
> 
> I'm not (necessarily) aiming at the upcoming stable tag, but Igor has
> resumed work on the QEMU-side patches [*], so this is again relevant for
> edk2.
> 
> [*] http://mid.mail-archive.com/20200818122208.1243901-1-imammedo@redhat.com
> https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg03892.html
> 
> (Top-posting because I want to keep the full context intact for you.)
> 
> Thanks!
> Laszlo

Thank you Phil and Ard for the reviews -- because those fit in the
(delayed) SFF deadline, I've gone ahead and merged this patch. Commit
5ba203b54e59, merged via .

Thanks!
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64576): https://edk2.groups.io/g/devel/message/64576
Mute This Topic: https://groups.io/mt/75505395/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix buffer overrun in FileHandleReadLine()

2020-08-24 Thread Laszlo Ersek

On 07/03/20 04:30, Zhiguang Liu wrote:
> Reviewed-by: Zhiguang Liu 

Merged as commit 4535fc312b76, via
.

Thanks,
Laszlo

> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Vladimir
>> Olovyannikov via groups.io
>> Sent: Thursday, July 2, 2020 10:31 AM
>> To: devel@edk2.groups.io
>> Cc: Vladimir Olovyannikov ; Kinney,
>> Michael D ; Gao, Liming
>> ; Liu, Zhiguang 
>> Subject: [edk2-devel] [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix buffer
>> overrun in FileHandleReadLine()
>>
>> If the size of the supplied buffer in FileHandleReadLine(), module
>> UefiFileHandleLib.c, was not 0, but was not enough to fit in
>> the line, the size is increased, and then the Buffer of the new
>> size is zeroed. This size is always larger than the supplied buffer size,
>> causing supplied buffer overrun. Fix the issue by using the
>> supplied buffer size in ZeroMem().
>>
>> Signed-off-by: Vladimir Olovyannikov
>> 
>> Cc: Michael D Kinney 
>> Cc: Liming Gao 
>> Cc: Zhiguang Liu 
>> ---
>>  MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
>> b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
>> index 28e28e5f67d5..ab34e6ccd5f4 100644
>> --- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
>> +++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
>> @@ -969,6 +969,7 @@ FileHandleReadLine(
>>UINTN   CharSize;
>>
>>UINTN   CountSoFar;
>>
>>UINTN   CrCount;
>>
>> +  UINTN   OldSize;
>>
>>UINT64  OriginalFilePosition;
>>
>>
>>
>>if (Handle == NULL
>>
>> @@ -1039,10 +1040,11 @@ FileHandleReadLine(
>>// if we ran out of space tell when...
>>
>>//
>>
>>if ((CountSoFar+1-CrCount)*sizeof(CHAR16) > *Size){
>>
>> +OldSize = *Size;
>>
>>  *Size = (CountSoFar+1-CrCount)*sizeof(CHAR16);
>>
>>  if (!Truncate) {
>>
>> -  if (Buffer != NULL && *Size != 0) {
>>
>> -ZeroMem(Buffer, *Size);
>>
>> +  if (Buffer != NULL && OldSize != 0) {
>>
>> +ZeroMem(Buffer, OldSize);
>>
>>}
>>
>>FileHandleSetPosition(Handle, OriginalFilePosition);
>>
>>return (EFI_BUFFER_TOO_SMALL);
>>
>> --
>> 2.26.2.266.ge870325ee8


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64575): https://edk2.groups.io/g/devel/message/64575
Mute This Topic: https://groups.io/mt/75251007/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] arm64: AMD Overdrive MNP Bug

2020-08-24 Thread Laszlo Ersek

On 08/22/20 21:43, Sahaj Sarup wrote:
> Hi all,
> 
> I just flashed edk2 to my AMD Overdrive 3000 for the first time, it is
> a fresh edk2 build as well.
> 
> When it boot i'm bombarded with this error:
> MnpReceivePacket: Snp->Receive() = Device Error.
> 
> This continues till the OS takes over UART, it makes the edk2 TUI
> completely unusable.
> Please let me know if you require any other logs and for the time
> being is there a way to suppress this message or disable the component
> completely?

It seems like MnpReceivePacket() [NetworkPkg/MnpDxe/MnpIo.c] reports
that Snp->Receive() failed. Unless we can prove that the SNP failure is
justified/expected due to invalid SNP use in the MNP driver, you really
have to look into your SNP driver. (It most probably comes flashed onto
your NIC; not sure where you can get access to the source code.)

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64574): https://edk2.groups.io/g/devel/message/64574
Mute This Topic: https://groups.io/mt/76369858/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 1/1] ShellPkg/AcpiView: HMAT Parser

2020-08-24 Thread Sami Mujawar

From: Marc Moisson-Franckhauser 

Add a new parser for the Heterogeneous Memory Attribute Table. The
parser also validates some fields for this table.

The HMAT table is used to describe the memory attributes such as memory
side cache attributes and bandwidth and latency details related to
memory proximity domains. The info in the HMAT table can be used by an
operating system for optimisation.

Signed-off-by: Marc Moisson-Franckhauser 
Signed-off-by: Sami Mujawar 
---

The changes can be seen at:
https://github.com/samimujawar/edk2/tree/833_hmat_parser_v1

 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h| 
 28 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h   | 
  4 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Hmat/HmatParser.c   | 
640 
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.c   | 
  3 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.inf | 
  3 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni | 
  3 +-
 6 files changed, 675 insertions(+), 6 deletions(-)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
index 
f81ccac7e118378aa185db4b625e5bcd75f78347..969cc0b371852f01f30c88dc506374a459c9c19e
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
@@ -1,7 +1,7 @@
 /** @file
   Header file for ACPI parser
 
-  Copyright (c) 2016 - 2020, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2020, Arm Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
 
@@ -592,6 +592,32 @@ ParseAcpiGtdt (
   );
 
 /**
+  This function parses the ACPI HMAT table.
+  When trace is enabled this function parses the HMAT table and
+  traces the ACPI table fields.
+
+  This function parses the following HMAT structures:
+- Memory Proximity Domain Attributes Structure (Type 0)
+- System Locality Latency and Bandwidth Info Structure (Type 1)
+- Memory Side Cache Info structure (Type 2)
+
+  This function also performs validation of the ACPI table fields.
+
+  @param [in] Trace  If TRUE, trace the ACPI fields.
+  @param [in] PtrPointer to the start of the buffer.
+  @param [in] AcpiTableLengthLength of the ACPI table.
+  @param [in] AcpiTableRevision  Revision of the ACPI table.
+**/
+VOID
+EFIAPI
+ParseAcpiHmat (
+  IN BOOLEAN Trace,
+  IN UINT8*  Ptr,
+  IN UINT32  AcpiTableLength,
+  IN UINT8   AcpiTableRevision
+  );
+
+/**
   This function parses the ACPI IORT table.
   When trace is enabled this function parses the IORT table and
   traces the ACPI fields.
diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h
index 
4f92596b90a6ee422d8d0959881015ffd3de4da0..f8e8b5979f3be041bbc8d17042b2db8e0b73f205
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h
@@ -1,7 +1,7 @@
 /** @file
   Header file for ACPI table parser
 
-  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2018, Arm Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
 
@@ -11,7 +11,7 @@
 /**
   The maximum number of ACPI table parsers.
 */
-#define MAX_ACPI_TABLE_PARSERS  16
+#define MAX_ACPI_TABLE_PARSERS  32
 
 /** An invalid/NULL signature value.
 */
diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Hmat/HmatParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Hmat/HmatParser.c
new file mode 100644
index 
..6494eaf9da0eb585c14f13c34c48b669b21854f9
--- /dev/null
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Hmat/HmatParser.c
@@ -0,0 +1,640 @@
+/** @file
+  HMAT table parser
+
+  Copyright (c) 2020, Arm Limited.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+- ACPI 6.3 Specification - January 2019
+
+  @par Glossary:
+- MPDA  - Memory Proximity Domain Attributes
+- SLLBI - System Locality Latency and Bandwidth Information
+- MSCI  - Memory Side Cache Information
+- Dom   - Domain
+**/
+
+#include 
+#include 
+#include 
+#include "AcpiParser.h"
+#include "AcpiView.h"
+
+// Maximum Memory Domain matrix print size.
+#define MAX_MEMORY_DOMAIN_TARGET_PRINT_MATRIX12
+
+// Local variables
+STATIC CONST UINT16*  HmatStructureType;
+STATIC CONST UINT32*  HmatStructureLength;
+
+STATIC CONST UINT32*  NumberInitiatorProximityDomain;
+STATIC CONST UINT32*  NumberTargetProximityDomain;
+STATIC CONST
+EFI_ACPI_6_3_HMAT_STRUCTURE_SYSTEM_LOCALITY_LATENCY_AND_BANDWIDTH_INFO_FLAGS*
+SllbiFlags;
+
+STATIC CONST UINT8*   SllbiDataType;
+STATIC CONST UINT32*

Re: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

2020-08-24 Thread Laszlo Ersek

Hi Liming,

On 08/24/20 03:49, gaoliming wrote:
> Hi, all
>
> Based on the discussion https://edk2.groups.io/g/devel/message/64493,
> we make the conclusion to defer one week for edk2-stable202008 to
> include the important patch for RiscV. Soft Feature Freeze (SFF) will
> start from today (2020-08-24). Below is new edk2-stable202008 tag
> planning proposed schedule
> .
> If you have any comments, please raise it.
>
>
> Date (00:00:00 UTC-8) Description
> 2020-06-03Beginning of development
> 2020-08-07Feature Planning Freeze
> 2020-08-24Soft Feature Freeze
> 2020-08-28Hard Feature Freeze
> 2020-09-04Release
>
> Because SFF date is changed, if the patches passed code review before
> SFF date (2020-08-24), the patches can still be merged for this stable
> tag. Here is the patch list those passed code review before new SFF
> date. For below features, I will let the feature owner decides whether
> to merge it for this stable tag.

As of this writing:

- Mon Aug 24 12:59:59 UTC 2020

we've entered the (new) Soft Feature Freeze. (The SFF date is 2020-08-24
00:00:00 UTC-8; in UTC, that's Mon Aug 24 08:00:00 UTC 2020 -- about
five hours ago.)

So:

> Feature List:
>
> https://edk2.groups.io/g/devel/message/63767
> [PATCH] EmbeddedPkg/libfdt: Add strncmp macro to use AsciiStrnCmp

I'm going to merge this soon (with Leif's review).

> https://edk2.groups.io/g/devel/message/64363
> [PATCH v5 0/3] UefiPayloadPkg: Runtime MMCONF

The UefiPayloadPkg patches in the series (#1, #3) have not received
reviews. We have to delay this until after the stable tag.

> https://edk2.groups.io/g/devel/message/64354
> [PATCH v4 0/8] Need add a FSP binary measurement

The SecurityPkg patches have not been approved yet, and Bret and Jiewen
are still testing / discussing (as far as I understand):
. Material for the next
tag.


On the other hand, I'm going to push two patches that had been reviewed
just before we entered the *delayed* SFF:

  https://edk2.groups.io/g/devel/message/64345
  [PATCH 1/1] OvmfPkg/Bhyve: rename files to remove 'Pkg' infix

  https://edk2.groups.io/g/devel/message/62561
  [PATCH] OvmfPkg/SmmControl2Dxe: negotiate ICH9_LPC_SMI_F_CPU_HOTPLUG

> Bug List:
>
> https://edk2.groups.io/g/devel/message/50406
> [PATCH 1/1] MdePkg/Include: Add missing definitions of SMBIOS type 42h in 
> SmBios.h

Liming, can you please merge this patch? For some reason I can't see it
in my local archives! (Only responses to it.)

> https://edk2.groups.io/g/devel/message/64507
> [PATCH v2 1/1] UefiCpuPkg/MpInitLib: Always initialize the DoDecrement 
> variable

I'm going to merge this soon.

> https://edk2.groups.io/g/devel/message/64539
> [PATCH] Maintainers.txt: Update Liming mail address

I'll merge this one as well.

> https://edk2.groups.io/g/devel/message/64529
> [PATCH] .pytool/EccCheck: Disable Ecc error code 10014 for open CI

Already merged as commit d4e0b9607c9a.

>
> https://edk2.groups.io/g/devel/message/61938
> [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix buffer overrun in 
> FileHandleReadLine()

I'll merge it.

Thanks!
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64572): https://edk2.groups.io/g/devel/message/64572
Mute This Topic: https://groups.io/mt/76377867/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Maintainers.txt: Update Liming mail address

2020-08-24 Thread Laszlo Ersek

On 08/21/20 16:49, gaoliming wrote:
> Signed-off-by: Liming Gao 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> ---
>  Maintainers.txt | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index f673ddd2b3..57cd2fc662 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -80,7 +80,7 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/Security
>  EDK II Releases:
>  
>  W: 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
> -M: Liming Gao 
> +M: Liming Gao 
>  
>  UEFI Shell Binaries (ShellBinPkg.zip) from EDK II Releases:
>  ---
> @@ -105,12 +105,12 @@ F: .azurepipelines/
>  M: Sean Brogan 
>  M: Bret Barkelew 
>  R: Michael D Kinney 
> -R: Liming Gao 
> +R: Liming Gao 
>  
>  .mergify/
>  F: .mergify/
>  M: Michael D Kinney 
> -M: Liming Gao 
> +M: Liming Gao 
>  R: Sean Brogan 
>  R: Bret Barkelew 
>  
> @@ -119,7 +119,7 @@ F: .pytool/
>  M: Sean Brogan 
>  M: Bret Barkelew 
>  R: Michael D Kinney 
> -R: Liming Gao 
> +R: Liming Gao 
>  
>  EDK II Packages:
>  
> @@ -156,7 +156,7 @@ BaseTools
>  F: BaseTools/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
>  M: Bob Feng 
> -M: Liming Gao 
> +M: Liming Gao 
>  R: Yuwei Chen 
>  
>  CryptoPkg
> @@ -197,7 +197,7 @@ T: git - https://github.com/tianocore/edk2-FatPkg.git
>  FmpDevicePkg
>  F: FmpDevicePkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> -M: Liming Gao 
> +M: Liming Gao 
>  M: Michael D Kinney 
>  R: Guomin Jiang 
>  R: Wei6 Xu 
> @@ -226,7 +226,7 @@ MdeModulePkg: ACPI modules
>  F: MdeModulePkg/Include/*Acpi*.h
>  F: MdeModulePkg/Universal/Acpi/
>  R: Dandan Bi 
> -R: Liming Gao 
> +R: Liming Gao 
>  
>  MdeModulePkg: ACPI modules related to S3
>  F: MdeModulePkg/*LockBox*/
> @@ -288,7 +288,7 @@ F: MdeModulePkg/Universal/PCD/
>  F: MdeModulePkg/Universal/PlatformDriOverrideDxe/
>  F: MdeModulePkg/Universal/SecurityStubDxe/SecurityStub.c
>  R: Dandan Bi 
> -R: Liming Gao 
> +R: Liming Gao 
>  
>  MdeModulePkg: Device and Peripheral modules
>  F: MdeModulePkg/*PciHostBridge*/
> @@ -327,7 +327,7 @@ F: MdeModulePkg/Library/DisplayUpdateProgressLib*/
>  F: MdeModulePkg/Library/FmpAuthenticationLibNull/
>  F: MdeModulePkg/Universal/Esrt*/
>  R: Hao A Wu 
> -R: Liming Gao 
> +R: Liming Gao 
>  R: Guomin Jiang 
>  
>  MdeModulePkg: HII and UI modules
> @@ -358,7 +358,7 @@ R: Ray Ni 
>  MdeModulePkg: Pei Core
>  F: MdeModulePkg/Core/Pei/
>  R: Dandan Bi 
> -R: Liming Gao 
> +R: Liming Gao 
>  R: Debkumar De 
>  R: Harry Han 
>  R: Catharine West 
> @@ -390,13 +390,13 @@ F: MdeModulePkg/Include/Guid/SystemNvDataGuid.h
>  F: MdeModulePkg/Include/Protocol/SwapAddressRange.h
>  F: MdeModulePkg/Universal/FaultTolerantWrite*/
>  R: Hao A Wu 
> -R: Liming Gao 
> +R: Liming Gao 
>  
>  MdePkg
>  F: MdePkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/MdePkg
>  M: Michael D Kinney 
> -M: Liming Gao 
> +M: Liming Gao 
>  R: Zhiguang Liu 
>  
>  NetworkPkg
> 

Reviewed-by: Laszlo Ersek 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64571): https://edk2.groups.io/g/devel/message/64571
Mute This Topic: https://groups.io/mt/76332353/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] running CI locally

2020-08-24 Thread Laszlo Ersek

On 08/21/20 23:36, Sean Brogan wrote:
> On 8/21/2020 12:23 AM, Laszlo Ersek wrote:

>>- ArmVirtPkg, DynamicTablesPkg, CryptoPkg, EmulatorPkg, FatPkg,
>>  NetworkPkg, OvmfPkg, PcAtChipsetPkg, SecurityPkg and ShellPkg
>>  are not covered by host-based unit tests -- I think also
>>  expected:
>>
>>> [...]
>>
>>- I'm not really sure about the following warnings. They were
>>  emitted for a subset of the above packages. I read the docs at
>>
>> 
>>
>>  but I still don't understand :)
>
> Each plugin/test has a readme as well.  Not sure if this helps explain
> the HostUnitTestDscCompleteCheck more.
>
> https://github.com/tianocore/edk2/tree/master/.pytool/Plugin/HostUnitTestDscCompleteCheck

I've carefully re-read the explanation now, and (apparently) I do
understand it now :/

Before, I didn't realize that the expression

  "those related to host based unit tests"

stood for the set of INF files where each INF was
MODULE_TYPE=HOST_APPLICATION or
LIBRARY_CLASS=FoobarLib|HOST_APPLICATION.

> As to why you don't see it skipped for ArmVirtPkg or a few others: I
> think this is a bug.
>
> In Azure CI i see it as test passed.
>
> PROGRESS - --Running ArmVirtPkg: Host Unit Test Dsc Complete Check
> Test NO-TARGET --
> PROGRESS - --->Test Success: Host Unit Test Dsc Complete Check Test
> NO-TARGET
>
> When i look at the code
> https://github.com/tianocore/edk2/blob/master/.pytool/Plugin/HostUnitTestDscCompleteCheck/HostUnitTestDscCompleteCheck.py#L59
>
>
> I see that how those packages *.ci.yaml have it configured is
> different than those that show skipped below.  It avoids the skip
> conditions but since those packages don't have any host unit test
> libraries or modules there is no failure.

"OvmfPkg/OvmfPkg.ci.yaml" (as an example) sets both
"HostUnitTestCompilerPlugin.DscPath" and
"HostUnitTestDscCompleteCheck.DscPath" to the empty string.

"ShellPkg/ShellPkg.ci.yaml" (an an example) sets neither attribute at
all.

Both HostUnitTestCompilerPlugin and HostUnitTestDscCompleteCheck check
for the existence of the DscPath attribute, as first step, so both
plugins warn about, and skip, ShellPkg.

OvmfPkg passes the same, first -- i.e., DscPath attribute existence --
check in both plugins. This suggests OvmfPkg is ruled out by *further*
checks in one plugin, and not ruled out by any further checks in the
other plugin.

The next (2nd) check in both plugins seems to be, whether we can
actually find the DSC file pointed-to by the DscPath attribute.
Furthermore, in HostUnitTestDscCompleteCheck, this check is the last one
(no other checks).

I think that this 2nd check *too* should fail for OvmfPkg in *both*
plugins. Because the DscPath attribute, while it exists, is empty.

I don't see why the "DSC path lookup" would fail in
HostUnitTestCompilerPlugin (and so we'd get a warning about OvmfPkg),
but not in HostUnitTestDscCompleteCheck (and so we'd get no warning
about OvmfPkg).

... Is it possible that the 2nd check actually fires in
HostUnitTestDscCompleteCheck too, but we suppress the warning by
returning 0, and not -1?

Compare the return values after the tc.SetSkipped() calls:

[https://github.com/tianocore/edk2/blob/master/.pytool/Plugin/HostUnitTestCompilerPlugin/HostUnitTestCompilerPlugin.py#L103]

100 if AP is None or AP_Path is None or not os.path.isfile(APDSC):
101 tc.SetSkipped()
102 tc.LogStdError("Package HostBasedUnitTest Dsc not found.")
103 return -1
   ^^

versus

[https://github.com/tianocore/edk2/blob/master/.pytool/Plugin/HostUnitTestDscCompleteCheck/HostUnitTestDscCompleteCheck.py#L73]

70 if abs_dsc_path is None or wsr_dsc_path == "" or not 
os.path.isfile(abs_dsc_path):
71 tc.SetSkipped()
72 tc.LogStdError("Package Host Unit Test Dsc not found")
73 return 0
  ^

I guess I could verify if the branch was taken at all, from the standard
error...

Ah, "Build/TestSuites.xml" seems relevant.

... Yes, I'm fairly sure the zero value after the "return" statement, on
line 73, is a typo. Because this is what I have in
"Build/TestSuites.xml" (excerpt re-wrapped here for readability):

> 
>   id="14"
>  name="OvmfPkg"
>  package="Edk2CiBuild.Edk2.OvmfPkg"
>  errors="0"
>  tests="12"
>  failures="0"
>  skipped="6">
>
>   classname="Edk2CiBuild.Edk2.OvmfPkg.HostUnitTestCompiler.X64"
>  name="Compile and Run Host-Based UnitTests for 
> Edk2CiBuild.Edk2.OvmfPkg on arch X64"
>  time="0.0002715587615966797">
> 
> 
> Package HostBasedUnitTest Dsc not found.
> 
>
>   classname="Edk2CiBuild.Edk2.OvmfPkg.HostUnitTestDscCompleteCheck"
>  name="Check the Edk2CiBuild.Edk2.OvmfPkg Host Unit Test DSC for a 
> being complete"
>

Re: [edk2-devel] [edk2-platforms] [PATCH v2] SgiPkg/RdN1EdgeX2: Add missing reference to PcdChipCount

2020-08-24 Thread Sami Mujawar

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

-Original Message-
From: Vijayenthiran Subramaniam 
Sent: 21 August 2020 06:17 PM
To: devel@edk2.groups.io; l...@nuviainc.com; Ard Biesheuvel 
; Sami Mujawar 
Cc: Thomas Abraham ; Aditya Angadi 

Subject: [edk2-platforms] [PATCH v2] SgiPkg/RdN1EdgeX2: Add missing reference 
to PcdChipCount

Commit e8fe2026dd79 (“Platform/ARM/SgiPkg: Use chip count constant on
rdn1edgex2 platform”) used the PcdChipCount constant but did not declare
its use in the ACPI table module. Fix this by listing it in the list of
PCDs to be looked up.

Signed-off-by: Vijayenthiran Subramaniam 
---

Changes since v1:
  - Add commit id in commit message for which this patch fixes the build
failure.

 Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
index 974d9db543..d44f02ab0c 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
@@ -45,6 +45,8 @@
   gArmSgiTokenSpaceGuid.PcdDramBlock2Base
   gArmSgiTokenSpaceGuid.PcdDramBlock2Size

+  gArmSgiTokenSpaceGuid.PcdChipCount
+
   gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum
   gArmTokenSpaceGuid.PcdArmArchTimerIntrNum
   gArmTokenSpaceGuid.PcdArmArchTimerHypIntrNum
--
2.17.1

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64569): https://edk2.groups.io/g/devel/message/64569
Mute This Topic: https://groups.io/mt/76333625/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [patch][edk2-platforms] Maintainers.txt: Update Liming mail address

2020-08-24 Thread Leif Lindholm

Hi Liming,

Based on Mike's R-b for the edk2 one:
Reviewed-by: Leif Lindholm 

/
Leif

On Mon, Aug 24, 2020 at 08:56:57 +0800, gaoliming wrote:
> Signed-off-by: Liming Gao 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> ---
>  Maintainers.txt | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 6ed57dd73b..5132a2483a 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -129,17 +129,17 @@ R: Ard Biesheuvel 
>  Features/Intel
>  F: Features/Intel/
>  M: Sai Chaganty 
> -R: Liming Gao 
> +R: Liming Gao 
>  
>  Features/Intel/Debugging
>  F: Features/Intel/Debugging/
>  M: Eric Dong 
> -R: Liming Gao 
> +R: Liming Gao 
>  
>  Features/Intel/UserInterface
>  F: Features/Intel/UserInterface/
>  M: Dandan Bi 
> -R: Liming Gao 
> +R: Liming Gao 
>  
>  Platform/Intel/QuarkPlatformPkg
>  F: Platform/Intel/QuarkPlatformPkg/
> @@ -154,7 +154,7 @@ M: Yi Qian 
>  Platform/Intel/BoardModulePkg
>  F: Platform/Intel/BoardModulePkg/
>  M: Eric Dong 
> -R: Liming Gao 
> +R: Liming Gao 
>  
>  Platform/Intel/KabylakeOpenBoardPkg
>  F: Platform/Intel/KabylakeOpenBoardPkg/
> @@ -169,7 +169,7 @@ Platform/Intel/MinPlatformPkg
>  F: Platform/Intel/MinPlatformPkg/
>  M: Chasel Chiu 
>  M: Nate DeSimone 
> -R: Liming Gao 
> +R: Liming Gao 
>  R: Eric Dong 
>  
>  Platform/Intel/WhiskeylakeOpenBoardPkg
> @@ -192,7 +192,7 @@ M: Agyeman Prince 
>  Platform/Intel/Tools
>  F: Platform/Intel/Tools/
>  M: Bob Feng 
> -M: Liming Gao 
> +M: Liming Gao 
>  R: Yuwei Chen 
>  
>  Silicon/Intel/IntelSiliconPkg
> @@ -231,7 +231,7 @@ M: Agyeman Prince 
>  Silicon/Intel/Tools
>  F: Silicon/Intel/Tools/
>  M: Bob Feng 
> -M: Liming Gao 
> +M: Liming Gao 
>  R: Yuwei Chen 
>  
>  Marvell platforms and silicon
> -- 
> 2.27.0.windows.1
> 
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64568): https://edk2.groups.io/g/devel/message/64568
Mute This Topic: https://groups.io/mt/76377156/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 1/1] ShellPkg/AcpiView: PCCT Parser

2020-08-24 Thread Sami Mujawar

From: Marc Moisson-Franckhauser 

Create a new parser for the PCCT Table.

The PCCT Table is used to describe how the OSPM can
communicate with entities outside the platform. It
describes which memory spaces correspond to which
entity as well as a few of the needed information
to handle the communications.

This new PCCT parser dumps the values and names of
the table fields. It also performs some validation
on the table's fields.

Signed-off-by: Marc Moisson-Franckhauser 
Signed-off-by: Sami Mujawar 
---

The changes can be seen at:
https://github.com/samimujawar/edk2/tree/840_pcct_parser_v1

 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h| 
 24 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h   | 
  4 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.c   | 
494 
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.h   | 
 33 ++
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.c   | 
  4 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.inf | 
  4 +-
 6 files changed, 558 insertions(+), 5 deletions(-)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
index 
f81ccac7e118378aa185db4b625e5bcd75f78347..051fdf807abb1067a264c136364bb6d145b38dab
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
@@ -1,7 +1,7 @@
 /** @file
   Header file for ACPI parser
 
-  Copyright (c) 2016 - 2020, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2020, Arm Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
 
@@ -671,6 +671,28 @@ ParseAcpiMcfg (
   );
 
 /**
+  This function parses the ACPI PCCT table including its sub-structures
+  of type 0 through 4.
+  When trace is enabled this function parses the PCCT table and
+  traces the ACPI table fields.
+
+  This function also performs validation of the ACPI table fields.
+
+  @param [in] Trace  If TRUE, trace the ACPI fields.
+  @param [in] PtrPointer to the start of the buffer.
+  @param [in] AcpiTableLengthLength of the ACPI table.
+  @param [in] AcpiTableRevision  Revision of the ACPI table.
+**/
+VOID
+EFIAPI
+ParseAcpiPcct (
+  IN BOOLEAN Trace,
+  IN UINT8*  Ptr,
+  IN UINT32  AcpiTableLength,
+  IN UINT8   AcpiTableRevision
+  );
+
+/**
   This function parses the ACPI PPTT table.
   When trace is enabled this function parses the PPTT table and
   traces the ACPI table fields.
diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h
index 
4f92596b90a6ee422d8d0959881015ffd3de4da0..19265d0b763f8a810759a2cef09ce2cc2d7bec03
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h
@@ -1,7 +1,7 @@
 /** @file
   Header file for ACPI table parser
 
-  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2020, Arm Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
 
@@ -11,7 +11,7 @@
 /**
   The maximum number of ACPI table parsers.
 */
-#define MAX_ACPI_TABLE_PARSERS  16
+#define MAX_ACPI_TABLE_PARSERS  17
 
 /** An invalid/NULL signature value.
 */
diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.c
new file mode 100644
index 
..526cb7b79aa7aa6eee09824600b6c7eac0ab67e2
--- /dev/null
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.c
@@ -0,0 +1,494 @@
+/** @file
+  PCCT table parser
+
+  Copyright (c) 2020, Arm Limited.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+- ACPI 6.3 Specification - January 2019
+**/
+
+#include 
+#include 
+#include "AcpiParser.h"
+#include "AcpiView.h"
+#include "AcpiViewConfig.h"
+#include "PcctParser.h"
+
+// Local variables
+STATIC ACPI_DESCRIPTION_HEADER_INFO AcpiHdrInfo;
+
+STATIC UINT8* PccSubspaceLength;
+STATIC UINT8* PccSubspaceType;
+
+/**
+  This function validates the length coded on 4 bytes of a shared memory range
+
+  @param [in] Ptr Pointer to the start of the field data.
+  @param [in] Context Pointer to context specific information e.g. this
+  could be a pointer to the ACPI table header.
+**/
+STATIC
+VOID
+EFIAPI
+ValidateRangeLength4 (
+  IN UINT8* Ptr,
+  IN VOID*  Context
+  )
+{
+  if (*(UINT32*)Ptr < MIN_EXT_PCC_SUBSPACE_MEM_RANGE_LEN) {
+IncrementErrorCount ();
+Print (
+  L"\nError: Shared memory range length is too short.\n"
+  L"Length is %u when it should be greater than or equal to %u",
+  *(UINT32*)Ptr,
+

Re: [edk2-devel] [edk2-platforms] [PATCH v2] SgiPkg/RdN1EdgeX2: Add missing reference to PcdChipCount

2020-08-24 Thread Thomas Abraham

On Fri, Aug 21, 2020 at 10:47 PM Vijayenthiran Subramaniam
 wrote:
>
> Commit e8fe2026dd79 (“Platform/ARM/SgiPkg: Use chip count constant on
> rdn1edgex2 platform”) used the PcdChipCount constant but did not declare
> its use in the ACPI table module. Fix this by listing it in the list of
> PCDs to be looked up.
>
> Signed-off-by: Vijayenthiran Subramaniam 

Reviewed-by: Thomas Abraham 

> ---
>
> Changes since v1:
>   - Add commit id in commit message for which this patch fixes the build
> failure.
>
>  Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf 
> b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
> index 974d9db543..d44f02ab0c 100644
> --- a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
> +++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
> @@ -45,6 +45,8 @@
>gArmSgiTokenSpaceGuid.PcdDramBlock2Base
>gArmSgiTokenSpaceGuid.PcdDramBlock2Size
>
> +  gArmSgiTokenSpaceGuid.PcdChipCount
> +
>gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum
>gArmTokenSpaceGuid.PcdArmArchTimerIntrNum
>gArmTokenSpaceGuid.PcdArmArchTimerHypIntrNum
> --
> 2.17.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64566): https://edk2.groups.io/g/devel/message/64566
Mute This Topic: https://groups.io/mt/76333625/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix buffer overrun in FileHandleReadLine()

Re: [edk2-devel] [PATCH v6 1/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

Re: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

回复: [edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 08/25/2020 6:30pm-7:30pm #cal-reminder

[edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 08/25/2020 6:30pm-7:30pm #cal-reminder

回复: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

Re: [edk2-devel] [PATCH v2 2/2] CryptoPkg/OpensslLib: Commit the auto-generated assembly files for X64

Re: [edk2-devel] [PATCH v2 2/6] FmpDevicePkg: Add LastAttemptStatus.h

Re: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native instruction support for X64

Re: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native instruction support for X64

Re: [edk2-devel] [PATCH v6 1/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

Re: [edk2-devel] [PATCH] Maintainers.txt: Update Liming mail address

Re: [edk2-devel] [PATCH v2 1/1] UefiCpuPkg/MpInitLib: Always initialize the DoDecrement variable

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/Bhyve: rename files to remove 'Pkg' infix

Re: [edk2-devel] [PATCH] EmbeddedPkg/libfdt: Add strncmp macro to use AsciiStrnCmp

Re: [edk2-devel] [PATCH v2 2/6] FmpDevicePkg: Add LastAttemptStatus.h

Re: [edk2-devel] [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix buffer overrun in FileHandleReadLine()

Re: [edk2-devel] [PATCH] OvmfPkg/SmmControl2Dxe: negotiate ICH9_LPC_SMI_F_CPU_HOTPLUG

Re: [edk2-devel] [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix buffer overrun in FileHandleReadLine()

Re: [edk2-devel] arm64: AMD Overdrive MNP Bug

[edk2-devel] [PATCH v1 1/1] ShellPkg/AcpiView: HMAT Parser

Re: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

Re: [edk2-devel] [PATCH] Maintainers.txt: Update Liming mail address

Re: [edk2-devel] running CI locally

Re: [edk2-devel] [edk2-platforms] [PATCH v2] SgiPkg/RdN1EdgeX2: Add missing reference to PcdChipCount

Re: [edk2-devel] [patch][edk2-platforms] Maintainers.txt: Update Liming mail address

[edk2-devel] [PATCH v1 1/1] ShellPkg/AcpiView: PCCT Parser

Re: [edk2-devel] [edk2-platforms] [PATCH v2] SgiPkg/RdN1EdgeX2: Add missing reference to PcdChipCount

28 matches

Site Navigation

Mail list logo

Footer information