date:20210927

[edk2-devel] Cancelled Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, September 28, 2021 #cal-cancelled

2021-09-27 Thread devel@edk2.groups.io Calendar

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:CANCELLED
REFRESH-INTERVAL;VALUE=DURATION:PT1H
X-PUBLISHED-TTL:PT1H
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
LAST-MODIFIED:20201011T015911Z
TZURL:http://tzurl.org/zoneinfo-outlook/America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZNAME:PDT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:PST
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
X-GIOIDS:Event:1083760 
UID:mlda.1580078539586725120.r...@groups.io
DTSTAMP:20210928T053344Z
ORGANIZER;CN=Liming Gao:mailto:gaolim...@byosoft.com.cn
DTSTART:20210929T013000Z
DTEND:20210929T023000Z
SUMMARY:TianoCore Bug Triage - APAC / NAMO
DESCRIPTION:TianoCore Bug Triage - APAC / NAMO\n\nHosted by Liming Gao\n\
 n
 \n\nMicrosoft Teams meeting\n\n*Join on your computer or mobile a
 pp*\n\nClick here to join the meeting ( https://teams.microsoft.com/l/mee
 tup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40
 thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255
 d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d )\n\n*Jo
 in with a video conferencing device*\n\nte...@conf.intel.com\n\nVideo Con
 ference ID: 116 062 094 0\n\nAlternate VTC dialing instructions ( https:/
 /conf.intel.com/teams/?conf=1160620940&ivr=teams&d=conf.intel.com&test=te
 st_call )\n\n*Or call in (audio only)*\n\n+1 916-245-6934\,\,77463821# ( 
 tel:+19162456934\,\,77463821# ) United States\, Sacramento\n\nPhone Confe
 rence ID: 774 638 21#\n\nFind a local number ( https://dialin.teams.micro
 soft.com/d195d438-2daa-420e-b9ea-da26f9d1d6d5?id=77463821 ) | Reset PIN (
  https://mysettings.lync.com/pstnconferencing )\n\nLearn More ( https://a
 ka.ms/JoinTeamsMeeting ) | Meeting options ( https://teams.microsoft.com/
 meetingOptions/?organizerId=b286b53a-1218-4db3-bfc9-3d4c5aa7669e&tenantId
 =46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_OTUyZTg2NjgtNDh
 lNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh@thread.v2&messageId=0&language=en-US )
LOCATION:https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2N
 jgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%2
 2%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-
 1218-4db3-bfc9-3d4c5aa7669e%22%7d
SEQUENCE:3
STATUS:CANCELLED
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

回复: [edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - 09/28/2021 #cal-reminder

2021-09-27 Thread gaoliming

Few new issues are submitted this week. I will cancel the meeting. 

 


  3654

EDK2

Code

unassig...@tianocore.org

UNCO

Openssl native instructions for 32-bit 
 

Fri 17:32

klaut...@microsoft.com


  3652

EDK2

Code

unassig...@tianocore.org

UNCO

Move StandaloneMmPkg/Drivers/StandaloneMmCpu driver and EntryPointLib to ArmPkg 
 

Thu 04:00

sean.bro...@microsoft.com


  3651

EDK2

Code

unassig...@tianocore.org

UNCO

Remove DxeIpl dependency on ArmPkg 
 

Thu 03:55

sean.bro...@microsoft.com


  3650

EDK2

Code

unassig...@tianocore.org

UNCO

Move GccLto binaries from ArmPkg to Basetools to better align with usage 
 

Thu 03:41

sean.bro...@microsoft.com


  3649

EDK2

Code

unassig...@tianocore.org

UNCO

ArmPkg CompilerIntrinsicsLib should be moved to MdePkg as it is part of build 
tools and baseline architectural support 
 

Thu 03:32

sean.bro...@microsoft.com


  3647

EDK2

Code

thomas.abra...@arm.com

UNCO

Align the *MmuLib definitions in ArmPkg to allow common layers to exist 
 

Thu 03:25

sean.bro...@microsoft.com

 

Thanks

Liming

发件人: devel@edk2.groups.io  代表 devel@edk2.groups.io 
Calendar
发送时间: 2021年9月28日 9:30
收件人: devel@edk2.groups.io
主题: [edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - 09/28/2021 
#cal-reminder

 

Reminder: TianoCore Bug Triage - APAC / NAMO 

When:
09/28/2021
6:30pm to 7:30pm
(UTC-07:00) America/Los Angeles 

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%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 (#81204): https://edk2.groups.io/g/devel/message/81204
Mute This Topic: https://groups.io/mt/85918732/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]
-=-=-=-=-=-=-=-=-=-=-=-

回复: [edk2-devel] [PATCH V2 0/2] Add ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0

2021-09-27 Thread gaoliming

Reviewed-by: Liming Gao 

> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Zeng, Star
> 发送时间: 2021年9月28日 10:36
> 收件人: devel@edk2.groups.io
> 抄送: Star Zeng 
> 主题: [edk2-devel] [PATCH V2 0/2] Add ProcessorUpgradeSocketLGA4677
> from SMBIOS 3.5.0
> 
> V2: Split patches for packages.
> 
> Star Zeng (2):
>   MdePkg: Add ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0
>   ShellPkg: Support ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0
> 
>  MdePkg/Include/IndustryStandard/SmBios.h   |  7 +--
>  .../SmbiosView/QueryTable.c| 14
> +-
>  2 files changed, 18 insertions(+), 3 deletions(-)
> 
> --
> 2.27.0.windows.1
> 
> 
> 
> 
> 





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

回复: [edk2-devel] [PATCH V3] MdeModulePkg/BootManagerMenuApp: Limit string drawing within one line

2021-09-27 Thread gaoliming

I am ok for this change. Reviewed-by: Liming Gao 

> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Gao, Zhichao
> 发送时间: 2021年9月28日 13:18
> 收件人: devel@edk2.groups.io; Gao, Zhichao 
> 抄送: Wang, Jian J ; Liming Gao
> ; Ni, Ray 
> 主题: Re: [edk2-devel] [PATCH V3] MdeModulePkg/BootManagerMenuApp:
> Limit string drawing within one line
> 
> Hi Liming/Ray,
> 
> I have updated the commit message and the BZ comments. Do you agree to
> merge the code?
> 
> Thanks,
> Zhichao
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Gao,
> > Zhichao
> > Sent: Monday, September 27, 2021 3:10 PM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J ; Liming Gao
> > ; Ni, Ray 
> > Subject: [edk2-devel] [PATCH V3] MdeModulePkg/BootManagerMenuApp:
> > Limit string drawing within one line
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3590
> >
> > Limit the draw box always within the screen's column and row.
> > Limit the string drawing within one line.For the incompleted string the
last 3
> > characters in one line wouldbe replaced with "...".
> >
> > Cc: Jian J Wang 
> > Cc: Liming Gao 
> > Cc: Ray Ni 
> > Signed-off-by: Zhichao Gao Reviewed-by: Ray Ni
> >  ---V2:Drop the change in UefiBootManagerLib in
> V1.Add
> > the limitation in BootManagerMenuApp instead.V3:Update the commit
> > message only.
> >  .../BootManagerMenuApp/BootManagerMenu.c  | 72
> > ++-
> >  1 file changed, 69 insertions(+), 3 deletions(-)
> >
> > diff --git
> > a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
> > c
> > b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
> > c
> > index 9e729074ec..d4bdeba073 100644
> > ---
> > a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
> > c
> > +++
> > b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
> > c
> > @@ -1,7 +1,7 @@
> >  /** @file   The application to show the Boot Manager Menu. -Copyright
> (c)
> > 2011 - 2018, Intel Corporation. All rights reserved.+Copyright (c)
2011 -
> > 2021, Intel Corporation. All rights reserved.
SPDX-License-Identifier:
> > BSD-2-Clause-Patent  **/@@ -45,9 +45,56 @@ PrintStringAt (
> >IN CHAR16*String   ) {+  UINTN ScreenWidth;+
> UINTN
> > ScreenRows;+  CHAR16*TurncateString;+  EFI_STATUS
> Status;+  UINTN
> > ShowingLength;gST->ConOut->SetCursorPosition (gST->ConOut,
> Column,
> > Row);-  return Print (L"%s", String);++  gST->ConOut->QueryMode (+
> > gST->ConOut,+ gST->ConOut->Mode->Mode,+
> > &ScreenWidth,+
> &ScreenRows+ );++  if (Column >
> > (ScreenWidth - 1) || Row > (ScreenRows - 1)) {+return 0;+  }++  if
> ((StrLen
> > (String) + Column) > (ScreenWidth - 1)) {+//+// |  -
> ScreenWidth -   |+
> > // ...Column.+// TurncateString length should
leave one
> > character for draw box and+// require one character for string end.+
> //+
> > ShowingLength = ScreenWidth - Column - 1;+TurncateString =
> AllocatePool
> > ((ShowingLength + 1) * sizeof (CHAR16));++if (TurncateString ==
NULL)
> {+
> > return 0;+}++Status = StrnCpyS (TurncateString, ShowingLength +
> 1,
> > String, ShowingLength - 3);++if (EFI_ERROR (Status)) {+
FreePool
> > (TurncateString);+  return 0;+}++*(TurncateString +
> ShowingLength - 3)
> > = L'.';+*(TurncateString + ShowingLength - 2) = L'.';+
> *(TurncateString +
> > ShowingLength - 1) = L'.';+*(TurncateString + ShowingLength) =
> L'\0';+
> > ShowingLength = Print (L"%s", TurncateString);+FreePool
> > (TurncateString);+return ShowingLength;+  } else {+return Print
> (L"%s",
> > String);+  } }  /**@@ -68,7 +115,22 @@ PrintCharAt (
> >CHAR16   Character   ) {+  UINTN ScreenWidth;+
> UINTN
> > ScreenRows;+   gST->ConOut->SetCursorPosition (gST->ConOut, Column,
> > Row);++  gST->ConOut->QueryMode (+
> gST->ConOut,+ gST-
> > >ConOut->Mode->Mode,+ &ScreenWidth,+
> > &ScreenRows+ );++  if (Column > (ScreenWidth - 1) ||
> Row >
> > (ScreenRows - 1)) {+return 0;+  }+   return Print (L"%c",
Character); }
> @@ -
> > 193,7 +255,11 @@ InitializeBootMenuScreen (
> > MaxPrintRows = Row - 6;   UnSelectableItmes =
> TITLE_TOKEN_COUNT + 2 +
> > HELP_TOKEN_COUNT + 2;-  BootMenuData->MenuScreen.Width =
> > MaxStrWidth + 8;+  if (MaxStrWidth + 8 > Column) {+BootMenuData-
> > >MenuScreen.Width = Column;+  } else {+BootMenuData-
> > >MenuScreen.Width = MaxStrWidth + 8;+  }   if
> (BootMenuData->ItemCount
> > + UnSelectableItmes > MaxPrintRows) { BootMenuData-
> > >MenuScreen.Height = MaxPrintRows; BootMenuData-
> > >ScrollBarControl.HasScrollBar = TRUE;--
> > 2.31.1.windows.1
> >
> >
> >
> > -=-=-=-=-=-=
> > Groups.io Links: You receive all messages sent to this group.
> > View/Reply Online (#81153):
> https://edk2.groups.io/g/devel/message/81153
> > Mute This Topic: https://groups.io/mt/85895022/1768756
> > Group Owner: devel+o

Re: [edk2-devel] [PATCH V3] MdeModulePkg/BootManagerMenuApp: Limit string drawing within one line

2021-09-27 Thread Gao, Zhichao

Hi Liming/Ray,

I have updated the commit message and the BZ comments. Do you agree to merge 
the code?

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Gao,
> Zhichao
> Sent: Monday, September 27, 2021 3:10 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Liming Gao
> ; Ni, Ray 
> Subject: [edk2-devel] [PATCH V3] MdeModulePkg/BootManagerMenuApp:
> Limit string drawing within one line
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3590
> 
> Limit the draw box always within the screen's column and row.
> Limit the string drawing within one line.For the incompleted string the last 3
> characters in one line wouldbe replaced with "...".
> 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> Cc: Ray Ni 
> Signed-off-by: Zhichao Gao Reviewed-by: Ray Ni
>  ---V2:Drop the change in UefiBootManagerLib in V1.Add
> the limitation in BootManagerMenuApp instead.V3:Update the commit
> message only.
>  .../BootManagerMenuApp/BootManagerMenu.c  | 72
> ++-
>  1 file changed, 69 insertions(+), 3 deletions(-)
> 
> diff --git
> a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
> c
> b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
> c
> index 9e729074ec..d4bdeba073 100644
> ---
> a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
> c
> +++
> b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
> c
> @@ -1,7 +1,7 @@
>  /** @file   The application to show the Boot Manager Menu. -Copyright (c)
> 2011 - 2018, Intel Corporation. All rights reserved.+Copyright (c) 2011 -
> 2021, Intel Corporation. All rights reserved. SPDX-License-Identifier:
> BSD-2-Clause-Patent  **/@@ -45,9 +45,56 @@ PrintStringAt (
>IN CHAR16*String   ) {+  UINTN ScreenWidth;+  UINTN
> ScreenRows;+  CHAR16*TurncateString;+  EFI_STATUSStatus;+  UINTN
> ShowingLength;gST->ConOut->SetCursorPosition (gST->ConOut, Column,
> Row);-  return Print (L"%s", String);++  gST->ConOut->QueryMode (+
> gST->ConOut,+ gST->ConOut->Mode->Mode,+
> &ScreenWidth,+ &ScreenRows+ );++  if (Column >
> (ScreenWidth - 1) || Row > (ScreenRows - 1)) {+return 0;+  }++  if 
> ((StrLen
> (String) + Column) > (ScreenWidth - 1)) {+//+// |  - ScreenWidth 
> -   |+
> // ...Column.+// TurncateString length should leave 
> one
> character for draw box and+// require one character for string end.+
> //+
> ShowingLength = ScreenWidth - Column - 1;+TurncateString = AllocatePool
> ((ShowingLength + 1) * sizeof (CHAR16));++if (TurncateString == NULL) {+
> return 0;+}++Status = StrnCpyS (TurncateString, ShowingLength + 1,
> String, ShowingLength - 3);++if (EFI_ERROR (Status)) {+  FreePool
> (TurncateString);+  return 0;+}++*(TurncateString + ShowingLength 
> - 3)
> = L'.';+*(TurncateString + ShowingLength - 2) = L'.';+
> *(TurncateString +
> ShowingLength - 1) = L'.';+*(TurncateString + ShowingLength) = L'\0';+
> ShowingLength = Print (L"%s", TurncateString);+FreePool
> (TurncateString);+return ShowingLength;+  } else {+return Print 
> (L"%s",
> String);+  } }  /**@@ -68,7 +115,22 @@ PrintCharAt (
>CHAR16   Character   ) {+  UINTN ScreenWidth;+  UINTN
> ScreenRows;+   gST->ConOut->SetCursorPosition (gST->ConOut, Column,
> Row);++  gST->ConOut->QueryMode (+ gST->ConOut,+  
>gST-
> >ConOut->Mode->Mode,+ &ScreenWidth,+
> &ScreenRows+ );++  if (Column > (ScreenWidth - 1) || Row >
> (ScreenRows - 1)) {+return 0;+  }+   return Print (L"%c", Character); } 
> @@ -
> 193,7 +255,11 @@ InitializeBootMenuScreen (
> MaxPrintRows = Row - 6;   UnSelectableItmes = TITLE_TOKEN_COUNT + 2 +
> HELP_TOKEN_COUNT + 2;-  BootMenuData->MenuScreen.Width =
> MaxStrWidth + 8;+  if (MaxStrWidth + 8 > Column) {+BootMenuData-
> >MenuScreen.Width = Column;+  } else {+BootMenuData-
> >MenuScreen.Width = MaxStrWidth + 8;+  }   if (BootMenuData->ItemCount
> + UnSelectableItmes > MaxPrintRows) { BootMenuData-
> >MenuScreen.Height = MaxPrintRows; BootMenuData-
> >ScrollBarControl.HasScrollBar = TRUE;--
> 2.31.1.windows.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#81153): https://edk2.groups.io/g/devel/message/81153
> Mute This Topic: https://groups.io/mt/85895022/1768756
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [zhichao@intel.com]
> -=-=-=-=-=-=
> 



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

Re: [edk2-devel] [PATCH V8 3/3] OvmfPkg: Enable TDX in ResetVector

2021-09-27 Thread Gerd Hoffmann

  Hi,

> > Can you move the metadata changes to a separate patch please?
> Yes, the metadata changes will be in a separate patch in the next version.

Can you also add a comment block documenting the format?  Not only those
parts which are used for TDVF, but everything?  The description in
tdx-virtual-firmware-design-guide-rev-1.pdf seems to be incomplete,
specifically the option to use the table for TD memory allocation
(as mentioned by Jiewen) is not covered.  And possibly there is more
which is missing ...

thanks,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81200): https://edk2.groups.io/g/devel/message/81200
Mute This Topic: https://groups.io/mt/85891884/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/9] ArmVirtPkg/FdtClintDxe: Move FdtClientDxe to EmbeddedPkg

2021-09-27 Thread Abner Chang



> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Ard Biesheuvel
> Sent: Tuesday, September 28, 2021 4:27 AM
> To: Chang, Abner (HPS SW/FW Technologist) 
> Cc: edk2-devel-groups-io ; Ard Biesheuvel
> ; Leif Lindholm ; Sami
> Mujawar ; Gerd Hoffmann ;
> Schaefer, Daniel ; Sunil V L
> 
> Subject: Re: [edk2-devel] [PATCH 1/9] ArmVirtPkg/FdtClintDxe: Move
> FdtClientDxe to EmbeddedPkg
> 
> On Mon, 27 Sept 2021 at 17:01, Abner Chang 
> wrote:
> >
> > This is one of the series patches to restructure the location of modules
> under
> > ArmVirtPkg for RiscVVirtPkg. RiscVVirtPkg leverage FDT Client protocol to
> > parse FDT nodes.
> >
> > Signed-off-by: Abner Chang 
> > Cc: Ard Biesheuvel 
> > Cc: Leif Lindholm 
> > Cc: Sami Mujawar 
> > Cc: Gerd Hoffmann 
> > Cc: Daniel Schaefer 
> > Cc: Sunil V L 
> > ---
> >  ArmVirtPkg/ArmVirtPkg.dec | 4 +---
> >  EmbeddedPkg/EmbeddedPkg.dec   | 2 ++
> >  ArmVirtPkg/ArmVirtCloudHv.dsc | 3 ++-
> >  ArmVirtPkg/ArmVirtKvmTool.dsc | 3 ++-
> >  ArmVirtPkg/ArmVirtQemu.dsc| 3 ++-
> >  ArmVirtPkg/ArmVirtQemuKernel.dsc  | 3 ++-
> >  ArmVirtPkg/ArmVirtXen.dsc | 3 ++-
> >  EmbeddedPkg/EmbeddedPkg.dsc   | 2 ++
> >  ArmVirtPkg/ArmVirtCloudHv.fdf | 3 ++-
> >  ArmVirtPkg/ArmVirtKvmTool.fdf | 3 ++-
> >  ArmVirtPkg/ArmVirtXen.fdf | 3 ++-
> >  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc  | 3 ++-
> >  ArmVirtPkg/HighMemDxe/HighMemDxe.inf  | 2 ++
> >  ArmVirtPkg/Library/ArmVirtGicArchLib/ArmVirtGicArchLib.inf| 2 ++
> >  .../ArmVirtPL031FdtClientLib/ArmVirtPL031FdtClientLib.inf | 2 ++
> >  .../ArmVirtPsciResetSystemLib/ArmVirtPsciResetSystemLib.inf   | 2 ++
> >  .../ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf | 2 ++
> >  .../Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf   | 2 ++
> >  .../Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf | 2 ++
> >  .../Library/KvmtoolRtcFdtClientLib/KvmtoolRtcFdtClientLib.inf | 2 ++
> >  ArmVirtPkg/Library/NorFlashKvmtoolLib/NorFlashKvmtoolLib.inf  | 3 +++
> >  ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf| 2 ++
> >  ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf  | 2 ++
> >  ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf  | 2 ++
> >  ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf  | 2 ++
> >  ArmVirtPkg/XenioFdtDxe/XenioFdtDxe.inf| 2 ++
> >  .../Drivers}/FdtClientDxe/FdtClientDxe.inf| 2 +-
> >  {ArmVirtPkg => EmbeddedPkg}/Include/Protocol/FdtClient.h  | 0
> >  .../Drivers}/FdtClientDxe/FdtClientDxe.c  | 0
> >  29 files changed, 53 insertions(+), 13 deletions(-)
> >  rename {ArmVirtPkg =>
> EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.inf (88%)
> >  rename {ArmVirtPkg => EmbeddedPkg}/Include/Protocol/FdtClient.h
> (100%)
> >  rename {ArmVirtPkg =>
> EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.c (100%)
> >
> > diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
> > index 4e4d758015..f5d34283b9 100644
> > --- a/ArmVirtPkg/ArmVirtPkg.dec
> > +++ b/ArmVirtPkg/ArmVirtPkg.dec
> > @@ -2,6 +2,7 @@
> >  #
> >  #  Copyright (c) 2014, Linaro Limited. All rights reserved.
> >  #  Copyright (c) 2020, ARM Limited. All rights reserved.
> > +#  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
> >  #
> 
> Please remove these bogus copyright statements. This hunk takes the
> cake because it claims copyright for the lines it removes (??), but in
> general, a series that claims to only move code around should not be
> adding these.
That's fine to remove those license. I thought we have to add copyright when 
touch the files.
Will resend the series.
Thanks
Abner
> 
> 
> >  #  SPDX-License-Identifier: BSD-2-Clause-Patent
> >  #
> > @@ -35,9 +36,6 @@
> >
> >gArmVirtVariableGuid   = { 0x50bea1e5, 0xa2c5, 0x46e9, { 0x9b, 0x3a, 
> > 0x59,
> 0x59, 0x65, 0x16, 0xb0, 0x0a } }
> >
> > -[Protocols]
> > -  gFdtClientProtocolGuid = { 0xE11FACA0, 0x4710, 0x4C8E, { 0xA7, 0xA2,
> 0x01, 0xBA, 0xA2, 0x59, 0x1B, 0x4C } }
> > -
> >  [PcdsFeatureFlag]
> >#
> ># Feature Flag PCD that defines whether TPM2 support is enabled
> > diff --git a/EmbeddedPkg/EmbeddedPkg.dec
> b/EmbeddedPkg/EmbeddedPkg.dec
> > index 7638de..932d1b6077 100644
> > --- a/EmbeddedPkg/EmbeddedPkg.dec
> > +++ b/EmbeddedPkg/EmbeddedPkg.dec
> > @@ -5,6 +5,7 @@
> >  # Copyright (c) 2007, Intel Corporation. All rights reserved.
> >  # Copyright (c) 2012-2015, ARM Ltd. All rights reserved.
> >  # Copyright (c) 2017, Linaro Ltd. All rights reserved.
> > +# (C) Copyright 2021 Hewle

Re: [edk2-devel] [PATCH] MdePkg,ShellPkg: Add ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0

2021-09-27 Thread Zeng, Star

Good comment.
Saw 0db89a661f38b10012ff4f62e1853bfc48efd462 does so for both MdePkg and 
ShellPkg, but that is different for fixing typo which must change both MdePkg 
and ShellPkg in same patch.

Please check V2.


Thanks,
Star
-Original Message-
From: Ni, Ray  
Sent: 2021年9月28日 10:12
To: Zeng, Star ; devel@edk2.groups.io
Cc: gaolim...@byosoft.com.cn; Kinney, Michael D ; 
Liu, Zhiguang ; Gao, Zhichao 
Subject: RE: [edk2-devel] [PATCH] MdePkg,ShellPkg: Add 
ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0

Star,
It might be better to split the patch to two patches.
one is to change MdePkg adding the definitions.
The other is to change ShellPkg consuming the definitions.

> -Original Message-
> From: Zeng, Star 
> Sent: Tuesday, September 28, 2021 10:11 AM
> To: devel@edk2.groups.io; Zeng, Star 
> Cc: gaolim...@byosoft.com.cn; Kinney, Michael D 
> ; Liu, Zhiguang ; 
> Ni, Ray ; Gao, Zhichao 
> Subject: RE: [edk2-devel] [PATCH] MdePkg,ShellPkg: Add 
> ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0
> 
> + Maintainers and Reviewers
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Zeng, 
> Star
> Sent: 2021年9月28日 10:04
> To: devel@edk2.groups.io
> Cc: Zeng, Star 
> Subject: [edk2-devel] [PATCH] MdePkg,ShellPkg: Add 
> ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0
> 
> This patch adds ProcessorUpgradeSocketLGA4677 definition into Smbios.h from 
> SMBIOS 3.5.0 and entry into QueryTable.c.
> It also adds ProcessorUpgradeSocketLGA4189 and 
> ProcessorUpgradeSocketLGA1200 into from SMBIOS 3.4.0 and entries into 
> QueryTable.c.
> 
> Signed-off-by: Star Zeng 
> ---
>  MdePkg/Include/IndustryStandard/SmBios.h   |  7 +--
>  .../SmbiosView/QueryTable.c| 14 +-
>  2 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/SmBios.h 
> b/MdePkg/Include/IndustryStandard/SmBios.h
> index 6918f58cce44..2c2b32b8d462 100644
> --- a/MdePkg/Include/IndustryStandard/SmBios.h
> +++ b/MdePkg/Include/IndustryStandard/SmBios.h
> @@ -1,7 +1,7 @@
>  /** @file   Industry Standard Definitions of SMBIOS Table Specification 
> v3.3.0. -Copyright (c) 2006 - 2019, Intel Corporation. All
> rights reserved.+Copyright (c) 2006 - 2021, Intel Corporation. All 
> rights reserved. (C) Copyright 2015-2017 Hewlett Packard 
> Enterprise Development LP (C) Copyright 2015 - 2019 Hewlett 
> Packard Enterprise Development LP SPDX-
> License-Identifier: BSD-2-Clause-Patent@@ -810,7 +810,10 @@ typedef enum {
>ProcessorUpgradeSocketLGA2066   = 0x39,   ProcessorUpgradeSocketBGA1392   
> = 0x3A,   ProcessorUpgradeSocketBGA1510
> = 0x3B,-  ProcessorUpgradeSocketBGA1528   = 0x3C+  
> ProcessorUpgradeSocketBGA1528   = 0x3C,+
> ProcessorUpgradeSocketLGA4189   = 0x3D,+  ProcessorUpgradeSocketLGA1200   = 
> 0x3E,+  ProcessorUpgradeSocketLGA4677   =
> 0x3F } PROCESSOR_UPGRADE;  ///diff --git 
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
> index 7fc9d38a3b03..c312a7f8f227 100644
> --- 
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> +++ c
> @@ -2,7 +2,7 @@
>Build a table, each item is (Key, Info) pair.   And give a interface of 
> query a string out of a table. -  Copyright (c) 2005 - 2019,
> Intel Corporation. All rights reserved.+  Copyright (c) 2005 - 2021, 
> Intel Corporation. All rights reserved.   (C) Copyright
> 2016-2019 Hewlett Packard Enterprise Development LP   
> SPDX-License-Identifier: BSD-2-Clause-Patent @@ -589,6 +589,18
> @@ TABLE_ITEM  ProcessorUpgradeTable[] = {
>{ 0x3C, L"Socket BGA1528"+  },+  {+0x3D,+L"Socket 
> LGA4189"+  },+  {+0x3E,+L"Socket LGA1200"+  },+  {+0x3F,+
> L"Socket LGA4677"   } }; --
> 2.27.0.windows.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#81189): 
> https://edk2.groups.io/g/devel/message/81189
> Mute This Topic: https://groups.io/mt/85916590/1779220
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub 
> [star.z...@intel.com] -=-=-=-=-=-=
> 



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

[edk2-devel] [PATCH V2 1/2] MdePkg: Add ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0

2021-09-27 Thread Zeng, Star

This patch adds ProcessorUpgradeSocketLGA4677 definition into Smbios.h
from SMBIOS 3.5.0.
It also adds ProcessorUpgradeSocketLGA4189 and ProcessorUpgradeSocketLGA1200
definitions into from SMBIOS 3.4.0.

Signed-off-by: Star Zeng 
---
 MdePkg/Include/IndustryStandard/SmBios.h | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/SmBios.h 
b/MdePkg/Include/IndustryStandard/SmBios.h
index 6918f58cce44..2c2b32b8d462 100644
--- a/MdePkg/Include/IndustryStandard/SmBios.h
+++ b/MdePkg/Include/IndustryStandard/SmBios.h
@@ -1,7 +1,7 @@
 /** @file
   Industry Standard Definitions of SMBIOS Table Specification v3.3.0.
 
-Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
 (C) Copyright 2015-2017 Hewlett Packard Enterprise Development LP
 (C) Copyright 2015 - 2019 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -810,7 +810,10 @@ typedef enum {
   ProcessorUpgradeSocketLGA2066   = 0x39,
   ProcessorUpgradeSocketBGA1392   = 0x3A,
   ProcessorUpgradeSocketBGA1510   = 0x3B,
-  ProcessorUpgradeSocketBGA1528   = 0x3C
+  ProcessorUpgradeSocketBGA1528   = 0x3C,
+  ProcessorUpgradeSocketLGA4189   = 0x3D,
+  ProcessorUpgradeSocketLGA1200   = 0x3E,
+  ProcessorUpgradeSocketLGA4677   = 0x3F
 } PROCESSOR_UPGRADE;
 
 ///
-- 
2.27.0.windows.1



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

[edk2-devel] [PATCH V2 2/2] ShellPkg: Support ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0

2021-09-27 Thread Zeng, Star

This patch adds entry into QueryTable.c for ProcessorUpgradeSocketLGA4677
from SMBIOS 3.5.0.
It also adds entries into QueryTable.c for ProcessorUpgradeSocketLGA4189
and ProcessorUpgradeSocketLGA1200 from SMBIOS 3.4.0.

Signed-off-by: Star Zeng 
---
 .../SmbiosView/QueryTable.c| 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
index 7fc9d38a3b03..c312a7f8f227 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
@@ -2,7 +2,7 @@
   Build a table, each item is (Key, Info) pair.
   And give a interface of query a string out of a table.
 
-  Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
+  Copyright (c) 2005 - 2021, Intel Corporation. All rights reserved.
   (C) Copyright 2016-2019 Hewlett Packard Enterprise Development LP
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -589,6 +589,18 @@ TABLE_ITEM  ProcessorUpgradeTable[] = {
   {
 0x3C,
 L"Socket BGA1528"
+  },
+  {
+0x3D,
+L"Socket LGA4189"
+  },
+  {
+0x3E,
+L"Socket LGA1200"
+  },
+  {
+0x3F,
+L"Socket LGA4677"
   }
 };
 
-- 
2.27.0.windows.1



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

[edk2-devel] [PATCH V2 0/2] Add ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0

2021-09-27 Thread Zeng, Star

V2: Split patches for packages.

Star Zeng (2):
  MdePkg: Add ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0
  ShellPkg: Support ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0

 MdePkg/Include/IndustryStandard/SmBios.h   |  7 +--
 .../SmbiosView/QueryTable.c| 14 +-
 2 files changed, 18 insertions(+), 3 deletions(-)

-- 
2.27.0.windows.1



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

Re: [edk2-devel] [PATCH V8 3/3] OvmfPkg: Enable TDX in ResetVector

2021-09-27 Thread Min Xu

On September 27, 2021 4:43 PM, Gerd Hoffmann wrote:
>   Hi,
> 
> > +_Bfv:
> > +  DD TDX_BFV_RAW_DATA_OFFSET
> > +  DD TDX_BFV_RAW_DATA_SIZE
> > +  DQ TDX_BFV_MEMORY_BASE
> > +  DQ TDX_BFV_MEMORY_SIZE
> > +  DD TDX_METADATA_SECTION_TYPE_BFV
> > +  DD TDX_METADATA_ATTRIBUTES_EXTENDMR
> 
> Size is still added twice, doesn't make sense given that they are either equal
> or RAW_DATA_SIZE is zero.  One size field being 32bit and the other being
> 64bit is pointless too (see also my mail to Jiewen).
>
Gerd, I would like to hold on until Jiewen and you reach consensus. Thanks for 
your understanding.
> 
> > +  DD TDX_METADATA_SECTION_TYPE_TEMP_MEM
> 
> There are a bunch of TEMP_MEM entries, some of them are next to each
> other in MEMFD, so you can squash them into one entry.

Below is the layout of MEMFD (Used by TDX)
I will squash the TEMP_MEM entries into one entry if they're adjacent. For 
example,  Mailbox + WorkArea will be squash into one entry.
But the Heap/Stack cannot be squashed with Mailbox/Workarea, because there is a 
memory hole (0xD000 - 0x1) between these 2 entry.

++  0x2
| |
|  PcdOvmfSecPeiTempRam | * Tdx Heap/Stack (Mem)*
| |
++ 0x1
| |
++0xD000
| PcdOvmfSecGhcbBackupBase   |  *Tdx Mailbox (Mem)*
++0xC000
|PcdOvmWorkArea|  *WorkArea (Mem)*
++0xB000
|PcdOvmfSecGhcb  | *TdHob  (HOB)*
++0x9000
|PcdOvmfSecGhcbPageTable|
|PcdGuidedExtractHandlerTable  |
|PcdOvmfLockBoxStorage |
++ 0x6000
| |
|PcdOvmfSecPageTables   |  *PageTables (Mem)*
| | 
++0x

> 
> Can you move the metadata changes to a separate patch please?
> 
Yes, the metadata changes will be in a separate patch in the next version.

Thanks!
Min


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

Re: [edk2-devel] [PATCH] MdePkg,ShellPkg: Add ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0

2021-09-27 Thread Ni, Ray

Star,
It might be better to split the patch to two patches.
one is to change MdePkg adding the definitions.
The other is to change ShellPkg consuming the definitions.

> -Original Message-
> From: Zeng, Star 
> Sent: Tuesday, September 28, 2021 10:11 AM
> To: devel@edk2.groups.io; Zeng, Star 
> Cc: gaolim...@byosoft.com.cn; Kinney, Michael D ; 
> Liu, Zhiguang ; Ni,
> Ray ; Gao, Zhichao 
> Subject: RE: [edk2-devel] [PATCH] MdePkg,ShellPkg: Add 
> ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0
> 
> + Maintainers and Reviewers
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Zeng, Star
> Sent: 2021年9月28日 10:04
> To: devel@edk2.groups.io
> Cc: Zeng, Star 
> Subject: [edk2-devel] [PATCH] MdePkg,ShellPkg: Add 
> ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0
> 
> This patch adds ProcessorUpgradeSocketLGA4677 definition into Smbios.h from 
> SMBIOS 3.5.0 and entry into QueryTable.c.
> It also adds ProcessorUpgradeSocketLGA4189 and ProcessorUpgradeSocketLGA1200 
> into from SMBIOS 3.4.0 and entries into
> QueryTable.c.
> 
> Signed-off-by: Star Zeng 
> ---
>  MdePkg/Include/IndustryStandard/SmBios.h   |  7 +--
>  .../SmbiosView/QueryTable.c| 14 +-
>  2 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/SmBios.h 
> b/MdePkg/Include/IndustryStandard/SmBios.h
> index 6918f58cce44..2c2b32b8d462 100644
> --- a/MdePkg/Include/IndustryStandard/SmBios.h
> +++ b/MdePkg/Include/IndustryStandard/SmBios.h
> @@ -1,7 +1,7 @@
>  /** @file   Industry Standard Definitions of SMBIOS Table Specification 
> v3.3.0. -Copyright (c) 2006 - 2019, Intel Corporation. All
> rights reserved.+Copyright (c) 2006 - 2021, Intel Corporation. All rights 
> reserved. (C) Copyright 2015-2017 Hewlett
> Packard Enterprise Development LP (C) Copyright 2015 - 2019 Hewlett 
> Packard Enterprise Development LP SPDX-
> License-Identifier: BSD-2-Clause-Patent@@ -810,7 +810,10 @@ typedef enum {
>ProcessorUpgradeSocketLGA2066   = 0x39,   ProcessorUpgradeSocketBGA1392   
> = 0x3A,   ProcessorUpgradeSocketBGA1510
> = 0x3B,-  ProcessorUpgradeSocketBGA1528   = 0x3C+  
> ProcessorUpgradeSocketBGA1528   = 0x3C,+
> ProcessorUpgradeSocketLGA4189   = 0x3D,+  ProcessorUpgradeSocketLGA1200   = 
> 0x3E,+  ProcessorUpgradeSocketLGA4677   =
> 0x3F } PROCESSOR_UPGRADE;  ///diff --git 
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
> index 7fc9d38a3b03..c312a7f8f227 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> +++ c
> @@ -2,7 +2,7 @@
>Build a table, each item is (Key, Info) pair.   And give a interface of 
> query a string out of a table. -  Copyright (c) 2005 - 2019,
> Intel Corporation. All rights reserved.+  Copyright (c) 2005 - 2021, 
> Intel Corporation. All rights reserved.   (C) Copyright
> 2016-2019 Hewlett Packard Enterprise Development LP   
> SPDX-License-Identifier: BSD-2-Clause-Patent @@ -589,6 +589,18
> @@ TABLE_ITEM  ProcessorUpgradeTable[] = {
>{ 0x3C, L"Socket BGA1528"+  },+  {+0x3D,+L"Socket 
> LGA4189"+  },+  {+0x3E,+L"Socket LGA1200"+  },+  {+0x3F,+
> L"Socket LGA4677"   } }; --
> 2.27.0.windows.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#81189): https://edk2.groups.io/g/devel/message/81189
> Mute This Topic: https://groups.io/mt/85916590/1779220
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [star.z...@intel.com] 
> -=-=-=-=-=-=
> 



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

Re: [edk2-devel] [`edk2-devel][PATCH] UefiPayloadPkg: Build a HOB from bootloader ACPI table

2021-09-27 Thread Ni, Ray

I prefer we still let caller to provide the HOB pointer.
This also eliminates a global variable "mAcpiBoardInfo".

You could change the BuildHobFromAcpi() to return the HOB pointer.
So that the pointer can be directly passed to ParseMemoryInfo().

Thanks,
Ray

> -Original Message-
> From: Dong, Guo 
> Sent: Monday, September 27, 2021 2:32 AM
> To: Ni, Ray ; devel@edk2.groups.io
> Cc: Ma, Maurice ; You, Benjamin 
> Subject: RE: [`edk2-devel][PATCH] UefiPayloadPkg: Build a HOB from bootloader 
> ACPI table
> 
> 
> Hi Ray,
> 
> In this patch, we added a shared file AcpiTable.c for both universal payload 
> and non-universal payload.
> The exposed API from this file is:   EFI_STATUS  BuildHobFromAcpi ( IN   
> UINT64 AcpiTableBase);
> This function will build an ACPI board HOB based on the information from ACPI 
> table.
> 
> For universal payload, it calls this function to build a hob for other 
> modules. The main function is very simple and clear.
> 
> For non-universal payload, ACPI board HOB is used in the ParseMemoryInfo() 
> callback for PCIE base info.
> So we could get this HOB from the caller, or get this HOB inside the 
> callback. I select to do it inside the callback.
> 
> Thanks,
> Guo
> 
> -Original Message-
> From: Ni, Ray 
> Sent: Saturday, September 25, 2021 7:48 PM
> To: Dong, Guo ; devel@edk2.groups.io
> Cc: Ma, Maurice ; You, Benjamin 
> Subject: RE: [`edk2-devel][PATCH] UefiPayloadPkg: Build a HOB from bootloader 
> ACPI table
> 
> 
> -  Status = ParseMemoryInfo (MemInfoCallbackMmio, &AcpiBoardInfo);
> 
> +  Status = ParseMemoryInfo (MemInfoCallbackMmio, NULL);
> 
> Guo,
> I am curious why you changed this part.
> Without this change, MemInfoCallbackMmio() can get the AcpiBoardInfo from the 
> parameter.
> With the change, it has to locate the Guided HOB itself.
> 
> 
> Other parts look good to me.
> 
> Thanks,
> Ray



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

Re: [edk2-devel] [PATCH] MdePkg,ShellPkg: Add ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0

2021-09-27 Thread Zeng, Star

+ Maintainers and Reviewers

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Zeng, Star
Sent: 2021年9月28日 10:04
To: devel@edk2.groups.io
Cc: Zeng, Star 
Subject: [edk2-devel] [PATCH] MdePkg,ShellPkg: Add 
ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0

This patch adds ProcessorUpgradeSocketLGA4677 definition into Smbios.h from 
SMBIOS 3.5.0 and entry into QueryTable.c.
It also adds ProcessorUpgradeSocketLGA4189 and ProcessorUpgradeSocketLGA1200 
into from SMBIOS 3.4.0 and entries into QueryTable.c.

Signed-off-by: Star Zeng 
---
 MdePkg/Include/IndustryStandard/SmBios.h   |  7 +--
 .../SmbiosView/QueryTable.c| 14 +-
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/SmBios.h 
b/MdePkg/Include/IndustryStandard/SmBios.h
index 6918f58cce44..2c2b32b8d462 100644
--- a/MdePkg/Include/IndustryStandard/SmBios.h
+++ b/MdePkg/Include/IndustryStandard/SmBios.h
@@ -1,7 +1,7 @@
 /** @file   Industry Standard Definitions of SMBIOS Table Specification 
v3.3.0. -Copyright (c) 2006 - 2019, Intel Corporation. All rights 
reserved.+Copyright (c) 2006 - 2021, Intel Corporation. All rights 
reserved. (C) Copyright 2015-2017 Hewlett Packard Enterprise Development 
LP (C) Copyright 2015 - 2019 Hewlett Packard Enterprise Development LP 
SPDX-License-Identifier: BSD-2-Clause-Patent@@ -810,7 +810,10 @@ typedef enum {
   ProcessorUpgradeSocketLGA2066   = 0x39,   ProcessorUpgradeSocketBGA1392   = 
0x3A,   ProcessorUpgradeSocketBGA1510   = 0x3B,-  ProcessorUpgradeSocketBGA1528 
  = 0x3C+  ProcessorUpgradeSocketBGA1528   = 0x3C,+  
ProcessorUpgradeSocketLGA4189   = 0x3D,+  ProcessorUpgradeSocketLGA1200   = 
0x3E,+  ProcessorUpgradeSocketLGA4677   = 0x3F } PROCESSOR_UPGRADE;  ///diff 
--git a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
index 7fc9d38a3b03..c312a7f8f227 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
+++ c
@@ -2,7 +2,7 @@
   Build a table, each item is (Key, Info) pair.   And give a interface of 
query a string out of a table. -  Copyright (c) 2005 - 2019, Intel Corporation. 
All rights reserved.+  Copyright (c) 2005 - 2021, Intel Corporation. All 
rights reserved.   (C) Copyright 2016-2019 Hewlett Packard Enterprise 
Development LP   SPDX-License-Identifier: BSD-2-Clause-Patent @@ -589,6 
+589,18 @@ TABLE_ITEM  ProcessorUpgradeTable[] = {
   { 0x3C, L"Socket BGA1528"+  },+  {+0x3D,+L"Socket LGA4189"+  
},+  {+0x3E,+L"Socket LGA1200"+  },+  {+0x3F,+L"Socket LGA4677" 
  } }; -- 
2.27.0.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81189): https://edk2.groups.io/g/devel/message/81189
Mute This Topic: https://groups.io/mt/85916590/1779220
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [star.z...@intel.com] 
-=-=-=-=-=-=




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

[edk2-devel] [PATCH] UserAuthFeaturePkg/UserAuthenticationDxeSmm: The SMI to handle the user authentication should be unregister before booting to OS

2021-09-27 Thread Shi, Hao

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

Register SmmExitBootServices and SmmLegacyBoot callback function to unregister 
this handler.

Signed-off-by: Hao Shi 
Cc: Dandan Bi 
Cc: Liming Gao 
---
 .../UserAuthenticationSmm.c   | 39 +--
 .../UserAuthenticationSmm.inf |  2 +
 2 files changed, 38 insertions(+), 3 deletions(-)

diff --git 
a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.c
 
b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.c
index 07e834eb..3d66010b 100644
--- 
a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.c
+++ 
b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.c
@@ -13,6 +13,7 @@ UINTN   mAdminPasswordTryCount = 0;
 
 BOOLEAN mNeedReVerify = TRUE;
 BOOLEAN mPasswordVerified = FALSE;
+EFI_HANDLE  mSmmHandle = NULL;
 
 /**
   Verify if the password is correct.
@@ -612,6 +613,30 @@ EXIT:
   return EFI_SUCCESS;
 }
 
+/**
+  Performs Exit Boot Services UserAuthentication actions
+
+  @param[in] Protocol   Points to the protocol's unique identifier.
+  @param[in] Interface  Points to the interface instance.
+  @param[in] Handle The handle on which the interface was installed.
+
+  @retval EFI_SUCCESS   Notification runs successfully.
+**/
+EFI_STATUS
+EFIAPI
+UaExitBootServices (
+  IN CONST EFI_GUID *Protocol,
+  IN VOID   *Interface,
+  IN EFI_HANDLE Handle
+  )
+{
+  DEBUG ((DEBUG_INFO, "Unregister User Authentication Smi\n"));
+
+  gSmst->SmiHandlerUnRegister(mSmmHandle);
+
+  return EFI_SUCCESS;
+}
+
 /**
   Main entry for this driver.
 
@@ -629,10 +654,11 @@ PasswordSmmInit (
   )
 {
   EFI_STATUSStatus;
-  EFI_HANDLESmmHandle;
   EDKII_VARIABLE_LOCK_PROTOCOL  *VariableLock;
   CHAR16
PasswordHistoryName[sizeof(USER_AUTHENTICATION_VAR_NAME)/sizeof(CHAR16) + 5];
   UINTN Index;
+  EFI_EVENT ExitBootServicesEvent;
+  EFI_EVENT LegacyBootEvent;
 
   ASSERT (PASSWORD_HASH_SIZE == SHA256_DIGEST_SIZE);
   ASSERT (PASSWORD_HISTORY_CHECK_COUNT < 0x);
@@ -657,13 +683,20 @@ PasswordSmmInit (
 ASSERT_EFI_ERROR (Status);
   }
 
-  SmmHandle = NULL;
-  Status= gSmst->SmiHandlerRegister (SmmPasswordHandler, 
&gUserAuthenticationGuid, &SmmHandle);
+  Status = gSmst->SmiHandlerRegister (SmmPasswordHandler, 
&gUserAuthenticationGuid, &mSmmHandle);
   ASSERT_EFI_ERROR (Status);
   if (EFI_ERROR (Status)) {
 return Status;
   }
 
+  //
+  // Register for SmmExitBootServices and SmmLegacyBoot notification.
+  //
+  Status = gSmst->SmmRegisterProtocolNotify 
(&gEdkiiSmmExitBootServicesProtocolGuid, UaExitBootServices, 
&ExitBootServicesEvent);
+  ASSERT_EFI_ERROR (Status);
+  Status = gSmst->SmmRegisterProtocolNotify (&gEdkiiSmmLegacyBootProtocolGuid, 
UaExitBootServices, &LegacyBootEvent);
+  ASSERT_EFI_ERROR (Status);
+
   if (IsPasswordCleared()) {
 DEBUG ((DEBUG_INFO, "IsPasswordCleared\n"));
 SavePasswordToVariable (&gUserAuthenticationGuid, NULL, 0);
diff --git 
a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.inf
 
b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.inf
index 0b33b194..d73a2fe2 100644
--- 
a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.inf
+++ 
b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.inf
@@ -48,6 +48,8 @@
 [Protocols]
   gEdkiiVariableLockProtocolGuid## CONSUMES
   gEfiSmmVariableProtocolGuid   ## CONSUMES
+  gEdkiiSmmExitBootServicesProtocolGuid ## CONSUMES
+  gEdkiiSmmLegacyBootProtocolGuid   ## CONSUMES
 
 [Depex]
   gEfiSmmVariableProtocolGuid AND gEfiVariableWriteArchProtocolGuid
-- 
2.31.1.windows.1



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

[edk2-devel] [PATCH] MdePkg,ShellPkg: Add ProcessorUpgradeSocketLGA4677 from SMBIOS 3.5.0

2021-09-27 Thread Zeng, Star

This patch adds ProcessorUpgradeSocketLGA4677 definition into Smbios.h
from SMBIOS 3.5.0 and entry into QueryTable.c.
It also adds ProcessorUpgradeSocketLGA4189 and ProcessorUpgradeSocketLGA1200
into from SMBIOS 3.4.0 and entries into QueryTable.c.

Signed-off-by: Star Zeng 
---
 MdePkg/Include/IndustryStandard/SmBios.h   |  7 +--
 .../SmbiosView/QueryTable.c| 14 +-
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/SmBios.h 
b/MdePkg/Include/IndustryStandard/SmBios.h
index 6918f58cce44..2c2b32b8d462 100644
--- a/MdePkg/Include/IndustryStandard/SmBios.h
+++ b/MdePkg/Include/IndustryStandard/SmBios.h
@@ -1,7 +1,7 @@
 /** @file
   Industry Standard Definitions of SMBIOS Table Specification v3.3.0.
 
-Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
 (C) Copyright 2015-2017 Hewlett Packard Enterprise Development LP
 (C) Copyright 2015 - 2019 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -810,7 +810,10 @@ typedef enum {
   ProcessorUpgradeSocketLGA2066   = 0x39,
   ProcessorUpgradeSocketBGA1392   = 0x3A,
   ProcessorUpgradeSocketBGA1510   = 0x3B,
-  ProcessorUpgradeSocketBGA1528   = 0x3C
+  ProcessorUpgradeSocketBGA1528   = 0x3C,
+  ProcessorUpgradeSocketLGA4189   = 0x3D,
+  ProcessorUpgradeSocketLGA1200   = 0x3E,
+  ProcessorUpgradeSocketLGA4677   = 0x3F
 } PROCESSOR_UPGRADE;
 
 ///
diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
index 7fc9d38a3b03..c312a7f8f227 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
@@ -2,7 +2,7 @@
   Build a table, each item is (Key, Info) pair.
   And give a interface of query a string out of a table.
 
-  Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
+  Copyright (c) 2005 - 2021, Intel Corporation. All rights reserved.
   (C) Copyright 2016-2019 Hewlett Packard Enterprise Development LP
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -589,6 +589,18 @@ TABLE_ITEM  ProcessorUpgradeTable[] = {
   {
 0x3C,
 L"Socket BGA1528"
+  },
+  {
+0x3D,
+L"Socket LGA4189"
+  },
+  {
+0x3E,
+L"Socket LGA1200"
+  },
+  {
+0x3F,
+L"Socket LGA4677"
   }
 };
 
-- 
2.27.0.windows.1



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

Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg

2021-09-27 Thread Ni, Ray

Marvin,
I agree with your concerns, in a certain level. But I didn't treat it
as a very big problem of having caller pass the BufferOneElement
"intelligently".

I am ok to use your option 1), making BufferOneElement mandatory.
Caller should always supply the buffer that's sufficient to hold one
element.

By the way, I don't want to propose "swap-without-using-temporary-value"
method to avoid using the "BufferOneElement"?
Because that makes the simple thing complicated!

Thanks,
Ray

> -Original Message-
> From: Marvin Häuser 
> Sent: Monday, September 27, 2021 5:09 PM
> To: fanjianf...@byosoft.com.cn; devel@edk2.groups.io; Ni, Ray 
> ; 'gaoliming'
> ; Chan, Amy ; 'Andrew Fish' 
> 
> Cc: Kinney, Michael D ; 'Gao, Liming' 
> ; Liu, Zhiguang
> ; Wang, Jian J ; Gao, Zhichao 
> 
> Subject: Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg
> 
> On 27/09/2021 10:50, fanjianf...@byosoft.com.cn wrote:
> > For former caller, they could still keep as is to call the old API in
> > MdeModulePkg. I think Ray's design is compatible change for existing code.
> > Only when the existing code wants to remove the dependency on
> > MdeModuelPkg, they could migrate to the new API in baselib.
> >
> > I agree with one split-API desgin what you mentioned.
> > But my point is to define one API in baselib and to make the baselib
> > not depend on memory allocation. And another wrapper API could be
> > designed to be placed in any other class.
> 
> Oh sure, it could totally live in another class. I'd just like to have
> those two models (caller- and callee-owned buffer) strictly separate, I
> personally do not mind where exactly they are implemented. Thanks!
> 
> Best regards,
> Marvin
> 
> >
> > 
> > Jeff
> > fanjianf...@byosoft.com.cn
> >
> > *From:* Marvin Häuser 
> > *Date:* 2021-09-27 16:14
> > *To:* fanjianf...@byosoft.com.cn
> > ; devel@edk2.groups.io
> > ; Ni, Ray ;
> > 'gaoliming' ; Chan, Amy
> > ; 'Andrew Fish' 
> > *CC:* Kinney, Michael D ; 'Gao,
> > Liming' ; Liu, Zhiguang
> > ; Wang, Jian J
> > ; Gao, Zhichao
> > 
> > *Subject:* Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg
> > On 27/09/2021 02:45, fanjianf...@byosoft.com.cn wrote:
> > > Making baselib implementation depend on MemoryAllocationLib
> > > (indirectly on Pei Service and gBS), it may prevent
> > > this base API using at some seneraio. i don't think it's better.
> > That is why I asked about a split-API scenario, one of which does not
> > depend on dynamic memory allocation (SetVariable-like) and one does
> > (wrapper-like).
> > > Add this parameter and make this parameter is optional,
> > > 1, when NULL, use the local 256 bytes stack
> > > 2, if 256 bytes stack is not enough, return RETURE_BUFFER_TOO_SAMLL,
> > > 3, caller check the return status, to do nothing or to allocate
> > enough
> > > buffer for retry
> > >
> > > This is just like SetVariable()'s implementation.
> > Yes, and because that is SetVariable's implementation, we have
> > library
> > functions to make it less error-prone and more convenient [1]. As a
> > matter of fact, we have a (semi-lax) policy in our codebases to avoid
> > such functions like the plague and use those library wrappers
> > where-ever
> > it can make sense. The only super-rare exceptions I can think of are
> > when we know the size of the element ahead of time. Also
> > SetVariable has
> > no arbitrary constraint on when it may work the first time, and
> > there is
> > code that will fail when the first return is not EFI_BUFFER_TOO_SMALL.
> > This solution honestly yields even more problems, because it
> > introduces
> > a Status return which was not there before. For common code safety
> > and
> > quality policy, this requires the value *must* be retrieved and
> > checked
> > in some fashion. So all callers, no matter the prior knowledge of the
> > element size, now need either a runtime check and handling for a
> > status
> > that they (may) know can never be returned, or ASSERTs if the
> > function
> > spec really imposes the arbitrary 256 Bytes constraint. Latter
> > doesn't
> > really work I think. What if someone wants to sort in SEC and noticed
> > they only have 64 Bytes on the stack to work with, realistically? Any
> > code depending on the 256 Byte constraint, passing NULL and not doing
> > additional handling, would seize to work. Former is too
> >

[edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - 09/28/2021 #cal-reminder

2021-09-27 Thread devel@edk2.groups.io Calendar

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
REFRESH-INTERVAL;VALUE=DURATION:PT1H
X-PUBLISHED-TTL:PT1H
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
LAST-MODIFIED:20201011T015911Z
TZURL:http://tzurl.org/zoneinfo-outlook/America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZNAME:PDT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:PST
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
X-GIOIDS:Event:1083760 
UID:mlda.1580078539586725120.r...@groups.io
DTSTAMP:20210928T013001Z
ORGANIZER;CN=Liming Gao:mailto:gaolim...@byosoft.com.cn
DTSTART:20210929T013000Z
DTEND:20210929T023000Z
SUMMARY:TianoCore Bug Triage - APAC / NAMO
DESCRIPTION:TianoCore Bug Triage - APAC / NAMO\n\nHosted by Liming Gao\n\
 n
 \n\nMicrosoft Teams meeting\n\n*Join on your computer or mobile a
 pp*\n\nClick here to join the meeting ( https://teams.microsoft.com/l/mee
 tup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40
 thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255
 d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d )\n\n*Jo
 in with a video conferencing device*\n\nte...@conf.intel.com\n\nVideo Con
 ference ID: 116 062 094 0\n\nAlternate VTC dialing instructions ( https:/
 /conf.intel.com/teams/?conf=1160620940&ivr=teams&d=conf.intel.com&test=te
 st_call )\n\n*Or call in (audio only)*\n\n+1 916-245-6934\,\,77463821# ( 
 tel:+19162456934\,\,77463821# ) United States\, Sacramento\n\nPhone Confe
 rence ID: 774 638 21#\n\nFind a local number ( https://dialin.teams.micro
 soft.com/d195d438-2daa-420e-b9ea-da26f9d1d6d5?id=77463821 ) | Reset PIN (
  https://mysettings.lync.com/pstnconferencing )\n\nLearn More ( https://a
 ka.ms/JoinTeamsMeeting ) | Meeting options ( https://teams.microsoft.com/
 meetingOptions/?organizerId=b286b53a-1218-4db3-bfc9-3d4c5aa7669e&tenantId
 =46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_OTUyZTg2NjgtNDh
 lNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh@thread.v2&messageId=0&language=en-US )
LOCATION:https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2N
 jgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%2
 2%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-
 1218-4db3-bfc9-3d4c5aa7669e%22%7d
SEQUENCE:3
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector

2021-09-27 Thread Yao, Jiewen

For size field, please refer to PE/COFF specification 
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format

The "Section Table (Section Headers)" defines two fields:
===
VirtualSize - The total size of the section when loaded into memory. If this 
value is greater than SizeOfRawData, the section is zero-padded. This field is 
valid only for executable images and should be set to zero for object files.

SizeOfRawData - The size of the section (for object files) or the size of the 
initialized data on disk (for image files). For executable images, this must be 
a multiple of FileAlignment from the optional header. If this is less than 
VirtualSize, the remainder of the section is zero-filled. Because the 
SizeOfRawData field is rounded but the VirtualSize field is not, it is possible 
for SizeOfRawData to be greater than VirtualSize as well. When a section 
contains only uninitialized data, this field should be zero.
===

We took similar concept here.

RawDataSize == size in the file.
MemoryDataSize == size in the memory. They are totally different concept.

For example, you can have 0xC81 RawDataSize, but the MemoryDataSize is 0x1000.

If one project enforces RawDataSize == MemoryDataSize, then only one size is 
needed.
But if one project wants to RawDataSize <= MemoryDataSize, then we need two 
size fields.



Thank you
Yao Jiewen

> -Original Message-
> From: kra...@redhat.com 
> Sent: Monday, September 27, 2021 10:59 PM
> To: Yao, Jiewen 
> Cc: devel@edk2.groups.io; Xu, Min M ; Brijesh Singh
> ; Ard Biesheuvel ;
> Justen, Jordan L ; Erdem Aktas
> ; James Bottomley ; Tom
> Lendacky 
> Subject: Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector
> 
>   Hi,
> 
> > > struct {
> > > uint64_t load_address;
> > > uint32_t file_offset;
> > > uint32_t section_size;
> > > uint32_t section_type;
> > > uint32_t section_flags;
> > > };
> >
> > [Jiewen] This data structure does not work in a special use case - A
> > TD may want to have a fixed memory size.  It is TD that tells the VMM
> > how many DRAM should be allocated by using metadata table. Not the
> > case that a VMM tells the TD how many DRAM is allocated by using HOB.
> >
> > In that special case, the TD_HOB is NOT required. The VMM parses the
> > metadata to allocate the DRAM (AUG page).
> 
> Hmm.  Not covered in tdx-virtual-firmware-design-guide-rev-1.pdf
> 
> > The runtime section size must be UINT64, otherwise we cannot support > 4G
> memory section.
> > The build time section size can be UINT32. We don't expect to create a >4G
> binary in near future.
> > And we need both.
> 
> That still doesn't explain why you need two sizes.  Instead of depending
> on zero-fill in case MemoryDataSize > RawDataSize you can just use two
> entries, simliar to ELF binaries which have separate '.data' and '.bss'
> sections too.
> 
> > I can understand why you think there is no needed fields, based upon
> > what you see in EDKII/TDVF project.  However, the usage in current
> > TDVF is just a subset, but not all usages.
> 
> So you are doing stuff behind closed doors ...
> > The TDX metadata structure is carefully designed to support those
> > variants. Also, leaving some room for future is a common practice.
> > Besides EDKII/TDVF, we are doing other TDX related projects reusing
> > the same metadata structure. (But sorry, I cannot tell more at this
> > time.)
> 
> ... and don't want tell details.  Even the fact that you are doing that
> is disclosed only after poking for a while because the patches submitted
> leave a bunch of questions open.
> 
> This is NOT how Open Source Development works.
> 
> If the patches can't speak for themself in cases like this the very
> minimum requirement is proper documentation.  It is not acceptable
> that I have to ask five times to figure that the format is supposed
> to cover use cases beyond TDVF.
> 
> > The benefit is that the KVM or cloud hypervisor can have a common
> > logic to handle "TDX boot", instead of using different table in
> > different use cases.
> 
> The benefit of a unified table for tdx and sev is that the VMM can
> have common logic to find page ranges which need special
> initialization.
> 
> But I suspect at that point we are going to trade code sharing at one
> place for code sharing at another place.
> 
> > I think it is OK, if SEV wants to reuse the existing TDX metadata
> > table. (We need SEV people agree.) Then we can have one metadata
> > table.
> 
> So, when submitting the next revision of this series, please ...
> 
>   (1) Move the tdx metadata changes to a separate patch.
>   (2) Add *complete* documentation for the TDX metadata format
> 
> ... so the SEV people can make up their mind whenever they want use
> that or not.
> 
> Please do also clarify what the process to allocate section type numbers
> (or reserve a number range) for SEV would be.
> 
> > [Jiewen] We don't fork OVMF in config-B.
> >
> > Instead of we

Re: [edk2-devel] [PATCH 1/9] ArmVirtPkg/FdtClintDxe: Move FdtClientDxe to EmbeddedPkg

2021-09-27 Thread Ard Biesheuvel

On Mon, 27 Sept 2021 at 17:01, Abner Chang  wrote:
>
> This is one of the series patches to restructure the location of modules under
> ArmVirtPkg for RiscVVirtPkg. RiscVVirtPkg leverage FDT Client protocol to
> parse FDT nodes.
>
> Signed-off-by: Abner Chang 
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Cc: Sami Mujawar 
> Cc: Gerd Hoffmann 
> Cc: Daniel Schaefer 
> Cc: Sunil V L 
> ---
>  ArmVirtPkg/ArmVirtPkg.dec | 4 +---
>  EmbeddedPkg/EmbeddedPkg.dec   | 2 ++
>  ArmVirtPkg/ArmVirtCloudHv.dsc | 3 ++-
>  ArmVirtPkg/ArmVirtKvmTool.dsc | 3 ++-
>  ArmVirtPkg/ArmVirtQemu.dsc| 3 ++-
>  ArmVirtPkg/ArmVirtQemuKernel.dsc  | 3 ++-
>  ArmVirtPkg/ArmVirtXen.dsc | 3 ++-
>  EmbeddedPkg/EmbeddedPkg.dsc   | 2 ++
>  ArmVirtPkg/ArmVirtCloudHv.fdf | 3 ++-
>  ArmVirtPkg/ArmVirtKvmTool.fdf | 3 ++-
>  ArmVirtPkg/ArmVirtXen.fdf | 3 ++-
>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc  | 3 ++-
>  ArmVirtPkg/HighMemDxe/HighMemDxe.inf  | 2 ++
>  ArmVirtPkg/Library/ArmVirtGicArchLib/ArmVirtGicArchLib.inf| 2 ++
>  .../ArmVirtPL031FdtClientLib/ArmVirtPL031FdtClientLib.inf | 2 ++
>  .../ArmVirtPsciResetSystemLib/ArmVirtPsciResetSystemLib.inf   | 2 ++
>  .../ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf | 2 ++
>  .../Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf   | 2 ++
>  .../Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf | 2 ++
>  .../Library/KvmtoolRtcFdtClientLib/KvmtoolRtcFdtClientLib.inf | 2 ++
>  ArmVirtPkg/Library/NorFlashKvmtoolLib/NorFlashKvmtoolLib.inf  | 3 +++
>  ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf| 2 ++
>  ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf  | 2 ++
>  ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf  | 2 ++
>  ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf  | 2 ++
>  ArmVirtPkg/XenioFdtDxe/XenioFdtDxe.inf| 2 ++
>  .../Drivers}/FdtClientDxe/FdtClientDxe.inf| 2 +-
>  {ArmVirtPkg => EmbeddedPkg}/Include/Protocol/FdtClient.h  | 0
>  .../Drivers}/FdtClientDxe/FdtClientDxe.c  | 0
>  29 files changed, 53 insertions(+), 13 deletions(-)
>  rename {ArmVirtPkg => EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.inf 
> (88%)
>  rename {ArmVirtPkg => EmbeddedPkg}/Include/Protocol/FdtClient.h (100%)
>  rename {ArmVirtPkg => EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.c (100%)
>
> diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
> index 4e4d758015..f5d34283b9 100644
> --- a/ArmVirtPkg/ArmVirtPkg.dec
> +++ b/ArmVirtPkg/ArmVirtPkg.dec
> @@ -2,6 +2,7 @@
>  #
>  #  Copyright (c) 2014, Linaro Limited. All rights reserved.
>  #  Copyright (c) 2020, ARM Limited. All rights reserved.
> +#  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
>  #

Please remove these bogus copyright statements. This hunk takes the
cake because it claims copyright for the lines it removes (??), but in
general, a series that claims to only move code around should not be
adding these.


>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -35,9 +36,6 @@
>
>gArmVirtVariableGuid   = { 0x50bea1e5, 0xa2c5, 0x46e9, { 0x9b, 0x3a, 0x59, 
> 0x59, 0x65, 0x16, 0xb0, 0x0a } }
>
> -[Protocols]
> -  gFdtClientProtocolGuid = { 0xE11FACA0, 0x4710, 0x4C8E, { 0xA7, 0xA2, 0x01, 
> 0xBA, 0xA2, 0x59, 0x1B, 0x4C } }
> -
>  [PcdsFeatureFlag]
>#
># Feature Flag PCD that defines whether TPM2 support is enabled
> diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
> index 7638de..932d1b6077 100644
> --- a/EmbeddedPkg/EmbeddedPkg.dec
> +++ b/EmbeddedPkg/EmbeddedPkg.dec
> @@ -5,6 +5,7 @@
>  # Copyright (c) 2007, Intel Corporation. All rights reserved.
>  # Copyright (c) 2012-2015, ARM Ltd. All rights reserved.
>  # Copyright (c) 2017, Linaro Ltd. All rights reserved.
> +# (C) Copyright 2021 Hewlett Packard Enterprise Development LP
>  #
>  #SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -79,6 +80,7 @@
>gPlatformGpioProtocolGuid = { 0x52ce9845, 0x5af4, 0x43e2, {0xba, 0xfd, 
> 0x23, 0x08, 0x12, 0x54, 0x7a, 0xc2 }}
>gPlatformVirtualKeyboardProtocolGuid = { 0x0e3606d2, 0x1dc3, 0x4e6f, { 
> 0xbe, 0x65, 0x39, 0x49, 0x82, 0xa2, 0x65, 0x47 }}
>gAndroidBootImgProtocolGuid = { 0x9859bb19, 0x407c, 0x4f8b, {0xbc, 0xe1, 
> 0xf8, 0xda, 0x65, 0x65, 0xf4, 0xa5 }}
> +  gFdtClientProtocolGuid = { 0xE11FACA0, 0x4710, 0x4C8E, { 0xA7, 0xA2, 0x01, 
> 0xBA, 0xA2, 0x59, 0x1B, 0x4C } }
>
>  [Ppis]
>gEdkiiEmbeddedGpioPpiGuid = { 0x21c3b115, 0x4e0b, 0x470c, { 0x85, 0xc7, 
> 0xe1, 0x05, 0xa5, 0x75, 0xc9, 0x7b }}
> diff --git a/ArmVirtPkg/A

Re: [edk2-devel] [edk2-platforms][PATCH v3 1/5] Platform/ARM: Add DMC-620 ECC error handling driver

2021-09-27 Thread Sami Mujawar


Hi Omkar,

Thank you for this patch.

Please find my feedback marked inline as [SAMI].

Regards,

Sami Mujawar


On 24/08/2021 07:00 AM, Omkar Anand Kulkarni wrote:

DMC-620 memory controller improves system reliability by generating
interrupts on detecting ECC errors on the data. Add a initial DMC-620 MM
driver that implements a MMI handler for handling single-bit ECC error
events originating from the DRAM.

The driver implements the HEST error source descriptor protocol in order
to publish the GHES error source descriptor for single-bit DRAM errors.
The GHES error source descriptor that is published is of type 'memory
error'. A GHES error source descriptor is published for each instances
if the DMC-620 controller in the system.

The driver registers a MMI handler for handling 1-bit DRAM ECC error
events. The MMI handler, when invoked, reads the DMC-620 error record
registers and populates the EFI_PLATFORM_MEMORY_ERROR_DATA type error
section information structure with the corresponding information read
from the error record registers.

Co-authored-by: Thomas Abraham 
Signed-off-by: Omkar Anand Kulkarni 
---
  Platform/ARM/Drivers/Dmc620Mm/Dmc620Mm.dec  |  30 ++
  Platform/ARM/Drivers/Dmc620Mm/Dmc620Mm.inf  |  61 
  Platform/ARM/Drivers/Dmc620Mm/Dmc620Mm.h| 174 ++
  Platform/ARM/Drivers/Dmc620Mm/Dmc620Mm.c| 362 

  Platform/ARM/Drivers/Dmc620Mm/Dmc620MmErrorSourceInfo.c | 194 +++
  5 files changed, 821 insertions(+)

diff --git a/Platform/ARM/Drivers/Dmc620Mm/Dmc620Mm.dec 
b/Platform/ARM/Drivers/Dmc620Mm/Dmc620Mm.dec
new file mode 100644
index ..8f3508574203
--- /dev/null
+++ b/Platform/ARM/Drivers/Dmc620Mm/Dmc620Mm.dec
@@ -0,0 +1,30 @@
+## @file
+#  DMC-620 MM driver specific declrations.
+#
+#  This file defines GUIDs and declares PCD values for DMC-620 MM driver.
+#
+#  Copyright (c) 2020 - 2021, ARM Limited. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  DEC_SPECIFICATION  = 0x0001001A
+  PACKAGE_NAME   = Dmc620Mm
+  PACKAGE_GUID   = 94110B10-8E72-42A0-8963-D2B57FCF0F38
+  PACKAGE_VERSION= 0.1
+
+[Guids]
+  gDmc620MmTokenSpaceGuid = {0xc305f72a, 0xd10d, 0x45e8, { 0x81, 0x78, 0x51, 
0x8b, 0x78, 0x62, 0x77, 0x79 } }
+  gArmDmcEventHandlerGuid = { 0x5ef0afd5, 0xe01a, 0x4c30, { 0x86, 0x19, 0x45, 
0x46, 0x26, 0x91, 0x80, 0x98 }}
+
+[PcdsFixedAtBuild.common]
+  
gDmc620MmTokenSpaceGuid.PcdDmc620CorrectableErrorThreshold|10|UINT32|0x0004
+  gDmc620MmTokenSpaceGuid.PcdDmc620CtrlSize|0x10|UINT32|0x0003
+  gDmc620MmTokenSpaceGuid.PcdDmc620DramErrorSdeiEventBase|0|UINT32|0x0006
+  gDmc620MmTokenSpaceGuid.PcdDmc620DramOneBitErrorDataBase|0|UINT64|0x0007
+  gDmc620MmTokenSpaceGuid.PcdDmc620DramOneBitErrorDataSize|0|UINT64|0x0008
+  gDmc620MmTokenSpaceGuid.PcdDmc620DramOneBitErrorSourceId|0|UINT16|0x0009
+  gDmc620MmTokenSpaceGuid.PcdDmc620ErrSourceCount|1|UINT32|0x0005
+  gDmc620MmTokenSpaceGuid.PcdDmc620NumCtrl|2|UINT32|0x0001
+  gDmc620MmTokenSpaceGuid.PcdDmc620RegisterBase|0x4E00|UINT64|0x0002
diff --git a/Platform/ARM/Drivers/Dmc620Mm/Dmc620Mm.inf 
b/Platform/ARM/Drivers/Dmc620Mm/Dmc620Mm.inf
new file mode 100644
index ..8cad07749a23
--- /dev/null
+++ b/Platform/ARM/Drivers/Dmc620Mm/Dmc620Mm.inf
@@ -0,0 +1,61 @@
+## @file
+#  StandaloneMM driver for the DMC620 Memory Controller.
+#
+#  Driver to handle 1-bit Corrected DRAM errors for DMC(s).
+#
+#  Copyright (c) 2020 - 2021, ARM Limited. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001A
[SAMI] Please use latest INF version i.e. 0x0001001B (see 
https://edk2-docs.gitbook.io/edk-ii-inf-specification/2_inf_overview/24_-defines-_section).

+  BASE_NAME  = StandaloneMmDmc620Driver
+  FILE_GUID  = CB53ACD9-A1A1-43B3-A638-AC74DA5D9DA2
+  MODULE_TYPE= MM_STANDALONE
+  VERSION_STRING = 1.0
+  PI_SPECIFICATION_VERSION   = 0x00010032
+  ENTRY_POINT= Dmc620MmDriverInitialize
+
+[Sources]
+  Dmc620Mm.c
+  Dmc620MmErrorSourceInfo.c
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  Platform/ARM/Drivers/Dmc620Mm/Dmc620Mm.dec
+  StandaloneMmPkg/StandaloneMmPkg.dec
+
+[LibraryClasses]
+  ArmLib
+  ArmSvcLib
+  BaseMemoryLib
+  DebugLib
+  StandaloneMmDriverEntryPoint
+
+[Protocols]
+  gMmHestErrorSourceDescProtocolGuid  ##PRODUCES
+
+[FixedPcd]
+  gArmPlatformTokenSpaceGuid.PcdGhesGenericErrorDataMmBufferBase
+  gArmPlatformTokenSpaceGuid.PcdGhesGenericErrorDataMmBufferSize
+
+  gDmc620MmTokenSpaceGuid.PcdDmc620CorrectableErrorThreshold
+  gDmc620MmTokenSpaceGuid.PcdDmc620CtrlSize
+  gDmc620MmTokenSpaceGuid.PcdDmc620

[edk2-devel] [PATCH 5/9] ArmVirtPkg/HighMemDxe: Relocate HighMemDxe to OvmfPkg

2021-09-27 Thread Abner Chang

Relocate HighMemDxe to OvmfPkg/Fdt, this library is leverage by
both ARM and RISC-V archs.

Signed-off-by: Abner Chang 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Daniel Schaefer 
Cc: Sunil V L 
---
 ArmVirtPkg/ArmVirtCloudHv.dsc | 2 +-
 ArmVirtPkg/ArmVirtKvmTool.dsc | 2 +-
 ArmVirtPkg/ArmVirtQemu.dsc| 2 +-
 ArmVirtPkg/ArmVirtQemuKernel.dsc  | 2 +-
 ArmVirtPkg/ArmVirtCloudHv.fdf | 2 +-
 ArmVirtPkg/ArmVirtKvmTool.fdf | 2 +-
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc  | 2 +-
 {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.inf | 3 +--
 {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.c   | 1 +
 9 files changed, 9 insertions(+), 9 deletions(-)
 rename {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.inf (91%)
 rename {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.c (95%)

diff --git a/ArmVirtPkg/ArmVirtCloudHv.dsc b/ArmVirtPkg/ArmVirtCloudHv.dsc
index d8b3ad8d73..c7515ed69b 100644
--- a/ArmVirtPkg/ArmVirtCloudHv.dsc
+++ b/ArmVirtPkg/ArmVirtCloudHv.dsc
@@ -295,7 +295,7 @@
   #
   ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
   EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
-  ArmVirtPkg/HighMemDxe/HighMemDxe.inf
+  OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
   OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
   OvmfPkg/VirtioNetDxe/VirtioNet.inf
diff --git a/ArmVirtPkg/ArmVirtKvmTool.dsc b/ArmVirtPkg/ArmVirtKvmTool.dsc
index 16c695e3ea..a9716fa7b9 100644
--- a/ArmVirtPkg/ArmVirtKvmTool.dsc
+++ b/ArmVirtPkg/ArmVirtKvmTool.dsc
@@ -294,7 +294,7 @@
   ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf
   ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
   EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
-  ArmVirtPkg/HighMemDxe/HighMemDxe.inf
+  OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
   OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
   OvmfPkg/VirtioNetDxe/VirtioNet.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 0fde1368e9..e2d3d10997 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -406,7 +406,7 @@
   #
   ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
   EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
-  ArmVirtPkg/HighMemDxe/HighMemDxe.inf
+  OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
   OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
   OvmfPkg/VirtioNetDxe/VirtioNet.inf
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 0cdd4a19eb..fa63978f24 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -342,7 +342,7 @@
   #
   ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
   EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
-  ArmVirtPkg/HighMemDxe/HighMemDxe.inf
+  OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
   OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
   OvmfPkg/VirtioNetDxe/VirtioNet.inf
diff --git a/ArmVirtPkg/ArmVirtCloudHv.fdf b/ArmVirtPkg/ArmVirtCloudHv.fdf
index 899ec3e7f6..e3e5e10169 100644
--- a/ArmVirtPkg/ArmVirtCloudHv.fdf
+++ b/ArmVirtPkg/ArmVirtCloudHv.fdf
@@ -108,7 +108,7 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
   INF ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
   INF EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
-  INF ArmVirtPkg/HighMemDxe/HighMemDxe.inf
+  INF OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
 
   #
   # PI DXE Drivers producing Architectural Protocols (EFI Services)
diff --git a/ArmVirtPkg/ArmVirtKvmTool.fdf b/ArmVirtPkg/ArmVirtKvmTool.fdf
index 70299e42f6..cd2cbd3d4b 100644
--- a/ArmVirtPkg/ArmVirtKvmTool.fdf
+++ b/ArmVirtPkg/ArmVirtKvmTool.fdf
@@ -123,7 +123,7 @@ READ_LOCK_STATUS   = TRUE
   INF ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
   INF EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
   INF ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf
-  INF ArmVirtPkg/HighMemDxe/HighMemDxe.inf
+  INF OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
 
   #
   # PI DXE Drivers producing Architectural Protocols (EFI Services)
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index 0853d43519..164aedec8c 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -43,7 +43,7 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
   INF ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
   INF EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
-  INF ArmVirtPkg/HighMemDxe/HighMemDxe.inf
+  INF OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
 
   #
   # PI DXE Drivers producing Architectural Protocols (EFI Services)
diff --git a/ArmVirtPkg/HighMemDxe/HighMemDxe.inf 
b/OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
similarity index 91%
rename from ArmVirtPkg/HighMemDxe/HighMemDxe.inf
rename to OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
index 3633a42d47..88d5371932 100644
--- a

[edk2-devel] [PATCH 7/9] MdePkg: Add PcdPciMmio32(64)Translation PCDs

2021-09-27 Thread Abner Chang

PcdPciMmio32Translation and PcdPciMmio64Translation PCDs are added
to MdePkg as the common PCDs for ARM and RSIC-V archs.

The one under ArmPkg is removed in the next patch.

Signed-off-by: Abner Chang 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Gerd Hoffmann 
Cc: Daniel Schaefer 
Cc: Sunil V L 
---
 MdePkg/MdePkg.dec | 8 
 1 file changed, 8 insertions(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 08d259764a..9df95abc50 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2306,6 +2306,14 @@
   # @Prompt PCI I/O Memory Map Window Base Address.
   gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation|0x0|UINT64|0x0040
 
+  ## This value is used for the 32-bit PCI memory map I/O base address 
translation.
+  # @Prompt 32-bit PCI Memory Map I/O Base Address translation.
+  gEfiMdePkgTokenSpaceGuid.PcdPciMmio32Translation|0x0|UINT64|0x0041
+
+  ## This value is used for the 64-bit PCI memory map I/O base address 
translation.
+  # @Prompt 64-bit PCI Memory Map I/O Base Address translation.
+  gEfiMdePkgTokenSpaceGuid.PcdPciMmio64Translation|0x0|UINT64|0x0042
+
   ## This value is used to set the size of PCI express hierarchy. The default 
is 256 MB.
   # @Prompt PCI Express Base Size.
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize|0x1000|UINT64|0x000f
-- 
2.17.1



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

[edk2-devel] [PATCH 0/9] Migrate ArmVirtPkg modules to OvmfPkg

2021-09-27 Thread Abner Chang

This pacthes set is to migrate some modules from ArmVirtPkg
to under OvmfPkg for the upcoming RiscVVirtPkg that can leverage
those modules without the dependency with Arm*Pkg.

The modules moved from ArmVirtPkg to OvmfPkg are,
- FdtClientDxe
- PciPcdProducerLib
- HighMemDxe
- QemuFwCfgLib
- FdtPciHostBridgeLib
- VirtioFdtDxe

Below PCDs are moved to under MdePkg and leverage by RiscVVirtPkg.
This change also remove the dependency on ArmPkg of OvmfPkg.
- PcdPciIoTranslation
- PcdPciIoTranslation
- PcdPciMmio32(64)Translation

Signed-off-by: Abner Chang 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Daniel Schaefer 
Cc: Sunil V L 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Michael D Kinney 

Abner Chang (9):
  ArmVirtPkg/FdtClintDxe: Move FdtClientDxe to EmbeddedPkg
  MdePkg: Add PcdPciIoTranslation PCD
  ArmPkg: Use PcdPciIoTranslation PCD from MdePkg
  ArmVirtPkg/FdtPciPcdProducerLib: Relocate PciPcdProducerLib to OvmfPkg
  ArmVirtPkg/HighMemDxe: Relocate HighMemDxe to OvmfPkg
  ArmVirtPkg/QemuFwCfgLib: Relocate QemuFwCfgLib to OvmfPkg
  MdePkg: Add PcdPciMmio32(64)Translation PCDs
  ArmVirtPkg/FdtPciHostBridgeLib: Relocate FdtPciHostBridgeLib to
OvmfPkg/Fdt
  ArmVirtPkg/VirtioFdtDxe: Relocate VirtioFdtDxe to OvmfPkg/Fdt

 ArmPkg/ArmPkg.dec | 16 +++---
 ArmVirtPkg/ArmVirtPkg.dec |  4 +---
 EmbeddedPkg/EmbeddedPkg.dec   |  2 ++
 MdePkg/MdePkg.dec | 12 +++
 ArmVirtPkg/ArmVirtCloudHv.dsc | 19 +
 ArmVirtPkg/ArmVirtKvmTool.dsc | 19 +
 ArmVirtPkg/ArmVirtQemu.dsc| 21 ++-
 ArmVirtPkg/ArmVirtQemuKernel.dsc  | 21 ++-
 ArmVirtPkg/ArmVirtXen.dsc |  3 ++-
 EmbeddedPkg/EmbeddedPkg.dsc   |  2 ++
 ArmVirtPkg/ArmVirtCloudHv.fdf |  7 ---
 ArmVirtPkg/ArmVirtKvmTool.fdf |  7 ---
 ArmVirtPkg/ArmVirtXen.fdf |  3 ++-
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc  |  7 ---
 .../ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf   |  3 ++-
 .../ArmVirtGicArchLib/ArmVirtGicArchLib.inf   |  2 ++
 .../ArmVirtPL031FdtClientLib.inf  |  2 ++
 .../ArmVirtPsciResetSystemLib.inf |  2 ++
 .../ArmVirtTimerFdtClientLib.inf  |  2 ++
 .../KvmtoolRtcFdtClientLib.inf|  2 ++
 .../NorFlashKvmtoolLib/NorFlashKvmtoolLib.inf |  3 +++
 .../NorFlashQemuLib/NorFlashQemuLib.inf   |  2 ++
 .../XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf |  2 ++
 ArmVirtPkg/XenioFdtDxe/XenioFdtDxe.inf|  2 ++
 .../Drivers}/FdtClientDxe/FdtClientDxe.inf|  2 +-
 .../FdtPciHostBridgeLib.inf   | 12 +--
 .../FdtPciPcdProducerLib.inf  |  6 +++---
 .../Fdt}/HighMemDxe/HighMemDxe.inf|  5 +++--
 .../Fdt}/VirtioFdtDxe/VirtioFdtDxe.inf|  3 ++-
 .../Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf |  7 ---
 .../Include/Protocol/FdtClient.h  |  0
 .../Drivers}/FdtClientDxe/FdtClientDxe.c  |  0
 .../FdtPciHostBridgeLib/FdtPciHostBridgeLib.c |  0
 .../FdtPciPcdProducerLib.c|  1 +
 .../Fdt}/HighMemDxe/HighMemDxe.c  |  1 +
 .../Fdt}/VirtioFdtDxe/VirtioFdtDxe.c  |  1 +
 .../Library/QemuFwCfgLib/QemuFwCfgLibMMIO.c   |  7 ---
 Maintainers.txt   |  6 ++
 38 files changed, 135 insertions(+), 81 deletions(-)
 rename {ArmVirtPkg => EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.inf (88%)
 rename {ArmVirtPkg/Library => 
OvmfPkg/Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf (73%)
 rename {ArmVirtPkg/Library => 
OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf (83%)
 rename {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.inf (85%)
 rename {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.inf (87%)
 rename ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf => 
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf (81%)
 rename {ArmVirtPkg => EmbeddedPkg}/Include/Protocol/FdtClient.h (100%)
 rename {ArmVirtPkg => EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.c (100%)
 rename {ArmVirtPkg/Library => 
OvmfPkg/Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c (100%)
 rename {ArmVirtPkg/Library => 
OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.c (95%)
 rename {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.c (95%)
 rename {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.c (95%)
 rename ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c => 
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.c (93%)

-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81181): https://edk2.groups.io/g/devel/message/81181
Mute This Topic: https://groups.io/mt/85902628/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io

[edk2-devel] [PATCH 9/9] ArmVirtPkg/VirtioFdtDxe: Relocate VirtioFdtDxe to OvmfPkg/Fdt

2021-09-27 Thread Abner Chang

Relocate VirtioFdtDxe to OvmfPkg/Fdt, this driver is leverage by
both ARM and RISC-V archs.

Signed-off-by: Abner Chang 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Daniel Schaefer 
Cc: Sunil V L 
---
 ArmVirtPkg/ArmVirtCloudHv.dsc | 2 +-
 ArmVirtPkg/ArmVirtKvmTool.dsc | 2 +-
 ArmVirtPkg/ArmVirtQemu.dsc| 2 +-
 ArmVirtPkg/ArmVirtQemuKernel.dsc  | 2 +-
 ArmVirtPkg/ArmVirtCloudHv.fdf | 2 +-
 ArmVirtPkg/ArmVirtKvmTool.fdf | 2 +-
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc  | 2 +-
 {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.inf | 3 +--
 {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.c   | 1 +
 9 files changed, 9 insertions(+), 9 deletions(-)
 rename {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.inf (87%)
 rename {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.c (95%)

diff --git a/ArmVirtPkg/ArmVirtCloudHv.dsc b/ArmVirtPkg/ArmVirtCloudHv.dsc
index 973bf811b7..2cdd6f7fe1 100644
--- a/ArmVirtPkg/ArmVirtCloudHv.dsc
+++ b/ArmVirtPkg/ArmVirtCloudHv.dsc
@@ -293,7 +293,7 @@
   #
   # Platform Driver
   #
-  ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
+  OvmfPkg/Fdt/VirtioFdtDxe/VirtioFdtDxe.inf
   EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
   OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
diff --git a/ArmVirtPkg/ArmVirtKvmTool.dsc b/ArmVirtPkg/ArmVirtKvmTool.dsc
index c135cdd2a2..1c5bcd522d 100644
--- a/ArmVirtPkg/ArmVirtKvmTool.dsc
+++ b/ArmVirtPkg/ArmVirtKvmTool.dsc
@@ -292,7 +292,7 @@
   # Platform Driver
   #
   ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf
-  ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
+  OvmfPkg/Fdt/VirtioFdtDxe/VirtioFdtDxe.inf
   EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
   OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index bc8b61a13c..f7d50657eb 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -404,7 +404,7 @@
   #
   # Platform Driver
   #
-  ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
+  OvmfPkg/Fdt/VirtioFdtDxe/VirtioFdtDxe.inf
   EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
   OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 008ff2c89d..4465abd8ab 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -340,7 +340,7 @@
   #
   # Platform Driver
   #
-  ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
+  OvmfPkg/Fdt/VirtioFdtDxe/VirtioFdtDxe.inf
   EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
   OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
diff --git a/ArmVirtPkg/ArmVirtCloudHv.fdf b/ArmVirtPkg/ArmVirtCloudHv.fdf
index e3e5e10169..90ef02c55d 100644
--- a/ArmVirtPkg/ArmVirtCloudHv.fdf
+++ b/ArmVirtPkg/ArmVirtCloudHv.fdf
@@ -106,7 +106,7 @@ READ_LOCK_STATUS   = TRUE
 
   INF MdeModulePkg/Core/Dxe/DxeMain.inf
   INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
-  INF ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
+  INF OvmfPkg/Fdt/VirtioFdtDxe/VirtioFdtDxe.inf
   INF EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
   INF OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
 
diff --git a/ArmVirtPkg/ArmVirtKvmTool.fdf b/ArmVirtPkg/ArmVirtKvmTool.fdf
index cd2cbd3d4b..b1067d1e0d 100644
--- a/ArmVirtPkg/ArmVirtKvmTool.fdf
+++ b/ArmVirtPkg/ArmVirtKvmTool.fdf
@@ -120,7 +120,7 @@ READ_LOCK_STATUS   = TRUE
 
   INF MdeModulePkg/Core/Dxe/DxeMain.inf
   INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
-  INF ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
+  INF OvmfPkg/Fdt/VirtioFdtDxe/VirtioFdtDxe.inf
   INF EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
   INF ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf
   INF OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index 164aedec8c..36edc68948 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -41,7 +41,7 @@ READ_LOCK_STATUS   = TRUE
 
   INF MdeModulePkg/Core/Dxe/DxeMain.inf
   INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
-  INF ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
+  INF OvmfPkg/Fdt/VirtioFdtDxe/VirtioFdtDxe.inf
   INF EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
   INF OvmfPkg/Fdt/HighMemDxe/HighMemDxe.inf
 
diff --git a/ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf 
b/OvmfPkg/Fdt/VirtioFdtDxe/VirtioFdtDxe.inf
similarity index 87%
rename from ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
rename to OvmfPkg/Fdt/VirtioFdtDxe/VirtioFdtDxe.inf
index 7d1a93f305..cc311659e7 100644
--- a/ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
+++ b/OvmfPkg/Fdt/VirtioFdtDxe/VirtioFdtDxe.inf
@@ -2,7 +2,7 @@
 #  Virtio FDT client protocol driver for virtio,mmio D

[edk2-devel] [PATCH 8/9] ArmVirtPkg/FdtPciHostBridgeLib: Relocate FdtPciHostBridgeLib to OvmfPkg/Fdt

2021-09-27 Thread Abner Chang

Relocate FdtPciHostBridgeLib to OvmfPkg/Fdt, this library is
leverage by both ARM and RISC-V archs. Also use
PcdPciMmio32Translation and PcdPciMmio64Translation
PCDs provided by MdePkg instead of ArmPkg.

Signed-off-by: Abner Chang 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Daniel Schaefer 
Cc: Sunil V L 
---
 ArmPkg/ArmPkg.dec  | 10 --
 ArmVirtPkg/ArmVirtCloudHv.dsc  |  2 +-
 ArmVirtPkg/ArmVirtKvmTool.dsc  |  2 +-
 ArmVirtPkg/ArmVirtQemu.dsc |  2 +-
 ArmVirtPkg/ArmVirtQemuKernel.dsc   |  2 +-
 .../Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf   |  8 +++-
 .../Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c |  0
 7 files changed, 11 insertions(+), 15 deletions(-)
 rename {ArmVirtPkg/Library => 
OvmfPkg/Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf (82%)
 rename {ArmVirtPkg/Library => 
OvmfPkg/Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c (100%)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 5793094fa3..66bfe167ca 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -339,8 +339,8 @@
   #   UINT64 Mmio64CpuBase; // mapping target in 64-bit cpu-physical space
   #
   #   gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation = IoCpuBase - PcdPciIoBase;
-  #   PcdPciMmio32Translation = Mmio32CpuBase - (UINT64)PcdPciMmio32Base;
-  #   PcdPciMmio64Translation = Mmio64CpuBase - PcdPciMmio64Base;
+  #   gEfiMdePkgTokenSpaceGuid.PcdPciMmio32Translation = Mmio32CpuBase - 
(UINT64)PcdPciMmio32Base;
+  #   gEfiMdePkgTokenSpaceGuid.PcdPciMmio64Translation = Mmio64CpuBase - 
PcdPciMmio64Base;
   #
   # because (a) the target address space (ie. the cpu-physical space) is
   # 64-bit, and (b) the translation values are meant as offsets for *modular*
@@ -359,9 +359,9 @@
   #   TranslatedIoAddress = UntranslatedIoAddress +
   # gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation;
   #   TranslatedMmio32Address = (UINT64)UntranslatedMmio32Address +
-  # PcdPciMmio32Translation;
+  # 
gEfiMdePkgTokenSpaceGuid..PcdPciMmio32Translation;
   #   TranslatedMmio64Address = UntranslatedMmio64Address +
-  # PcdPciMmio64Translation;
+  # 
gEfiMdePkgTokenSpaceGuid.PcdPciMmio64Translation;
   #
   #  The modular arithmetic performed in UINT64 ensures that the translation
   #  works correctly regardless of the relation between IoCpuBase and
@@ -372,10 +372,8 @@
   gArmTokenSpaceGuid.PcdPciIoSize|0x0|UINT64|0x0051
   gArmTokenSpaceGuid.PcdPciMmio32Base|0x0|UINT32|0x0053
   gArmTokenSpaceGuid.PcdPciMmio32Size|0x0|UINT32|0x0054
-  gArmTokenSpaceGuid.PcdPciMmio32Translation|0x0|UINT64|0x0055
   gArmTokenSpaceGuid.PcdPciMmio64Base|0x0|UINT64|0x0056
   gArmTokenSpaceGuid.PcdPciMmio64Size|0x0|UINT64|0x0057
-  gArmTokenSpaceGuid.PcdPciMmio64Translation|0x0|UINT64|0x0058
 
   #
   # Inclusive range of allowed PCI buses.
diff --git a/ArmVirtPkg/ArmVirtCloudHv.dsc b/ArmVirtPkg/ArmVirtCloudHv.dsc
index c7515ed69b..973bf811b7 100644
--- a/ArmVirtPkg/ArmVirtCloudHv.dsc
+++ b/ArmVirtPkg/ArmVirtCloudHv.dsc
@@ -52,7 +52,7 @@
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
   PciPcdProducerLib|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
   PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf
-  
PciHostBridgeLib|ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
+  PciHostBridgeLib|OvmfPkg/Fdt/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
   
PciHostBridgeUtilityLib|ArmVirtPkg/Library/ArmVirtPciHostBridgeUtilityLib/ArmVirtPciHostBridgeUtilityLib.inf
 
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
diff --git a/ArmVirtPkg/ArmVirtKvmTool.dsc b/ArmVirtPkg/ArmVirtKvmTool.dsc
index a9716fa7b9..c135cdd2a2 100644
--- a/ArmVirtPkg/ArmVirtKvmTool.dsc
+++ b/ArmVirtPkg/ArmVirtKvmTool.dsc
@@ -60,7 +60,7 @@
 
   PciPcdProducerLib|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
   PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf
-  
PciHostBridgeLib|ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
+  PciHostBridgeLib|OvmfPkg/Fdt/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
   
PciHostBridgeUtilityLib|ArmVirtPkg/Library/ArmVirtPciHostBridgeUtilityLib/ArmVirtPciHostBridgeUtilityLib.inf
 
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index cde55af64c..bc8b61a13c 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -80,7 +80,7 @@
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
   PciPcdProducerLib|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf

[edk2-devel] [PATCH 4/9] ArmVirtPkg/FdtPciPcdProducerLib: Relocate PciPcdProducerLib to OvmfPkg

2021-09-27 Thread Abner Chang

Relocate PciPcdProducerLib to OvmfPkg/Fdt, this library is
leverage by both ARM and RISC-V archs.

Add OvmfPkg/Fdt maintainers in Maintainers.txt

Signed-off-by: Abner Chang 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Daniel Schaefer 
Cc: Sunil V L 
---
 ArmVirtPkg/ArmVirtCloudHv.dsc | 8 
 ArmVirtPkg/ArmVirtKvmTool.dsc | 8 
 ArmVirtPkg/ArmVirtQemu.dsc| 8 
 ArmVirtPkg/ArmVirtQemuKernel.dsc  | 8 
 .../Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf| 4 +---
 .../Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.c  | 1 +
 Maintainers.txt   | 6 ++
 7 files changed, 24 insertions(+), 19 deletions(-)
 rename {ArmVirtPkg/Library => 
OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf (87%)
 rename {ArmVirtPkg/Library => 
OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.c (95%)

diff --git a/ArmVirtPkg/ArmVirtCloudHv.dsc b/ArmVirtPkg/ArmVirtCloudHv.dsc
index 593663a6c5..d8b3ad8d73 100644
--- a/ArmVirtPkg/ArmVirtCloudHv.dsc
+++ b/ArmVirtPkg/ArmVirtCloudHv.dsc
@@ -50,7 +50,7 @@
   
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
-  
PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+  PciPcdProducerLib|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
   PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf
   
PciHostBridgeLib|ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
   
PciHostBridgeUtilityLib|ArmVirtPkg/Library/ArmVirtPciHostBridgeUtilityLib/ArmVirtPciHostBridgeUtilityLib.inf
@@ -342,12 +342,12 @@
   #
   ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf {
 
-  NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+  NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
   }
   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
   MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf {
 
-  NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+  NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
   }
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
@@ -361,5 +361,5 @@
   
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
   ArmVirtPkg/CloudHvAcpiPlatformDxe/CloudHvAcpiPlatformDxe.inf {
 
-  NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+  NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
   }
diff --git a/ArmVirtPkg/ArmVirtKvmTool.dsc b/ArmVirtPkg/ArmVirtKvmTool.dsc
index 64cc7d7cf0..16c695e3ea 100644
--- a/ArmVirtPkg/ArmVirtKvmTool.dsc
+++ b/ArmVirtPkg/ArmVirtKvmTool.dsc
@@ -58,7 +58,7 @@
 
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
 
-  
PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+  PciPcdProducerLib|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
   PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf
   
PciHostBridgeLib|ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
   
PciHostBridgeUtilityLib|ArmVirtPkg/Library/ArmVirtPciHostBridgeUtilityLib/ArmVirtPciHostBridgeUtilityLib.inf
@@ -339,17 +339,17 @@
   #
   ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf {
 
-  NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+  NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
   
NULL|ArmVirtPkg/Library/BaseCachingPciExpressLib/BaseCachingPciExpressLib.inf
   }
   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
 
-  NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+  NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
   
NULL|ArmVirtPkg/Library/BaseCachingPciExpressLib/BaseCachingPciExpressLib.inf
   }
   MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf {
 
-  NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+  NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
   
NULL|ArmVirtPkg/Library/BaseCachingPciExpressLib/BaseCachingPciExpressLib.inf
   }
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 04d283004e..0fde1368e9 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -78,7 +78,7 @@
   
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileEx

[edk2-devel] [PATCH 2/9] MdePkg: Add PcdPciIoTranslation PCD

2021-09-27 Thread Abner Chang

This PCD is moved from ArmPkg that is used to set the base address
of PCI MMIO window that provides I/O access. We relocate this PCD
because this PCD is common to ARM and RSIC-V arch.

Signed-off-by: Abner Chang 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Gerd Hoffmann 
Cc: Daniel Schaefer 
Cc: Sunil V L 
---
 MdePkg/MdePkg.dec | 4 
 1 file changed, 4 insertions(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index a28a2daaff..08d259764a 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2302,6 +2302,10 @@
   # @Prompt PCI Express Base Address.
   
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE000|UINT64|0x000a
 
+  ## This value is used to set the base address of PCI MMIO window that 
provides I/O access.
+  # @Prompt PCI I/O Memory Map Window Base Address.
+  gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation|0x0|UINT64|0x0040
+
   ## This value is used to set the size of PCI express hierarchy. The default 
is 256 MB.
   # @Prompt PCI Express Base Size.
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize|0x1000|UINT64|0x000f
-- 
2.17.1



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

[edk2-devel] [PATCH 6/9] ArmVirtPkg/QemuFwCfgLib: Relocate QemuFwCfgLib to OvmfPkg

2021-09-27 Thread Abner Chang

Relocate QemuFwCfgLib to OvmfPkg/Library/QemuFwCfgLib and rename
it to QemuFwCfgLibMMIO, this library is leverage by both ARM and
RISC-V archs.

Signed-off-by: Abner Chang 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Daniel Schaefer 
Cc: Sunil V L 
---
 ArmVirtPkg/ArmVirtQemu.dsc | 2 +-
 ArmVirtPkg/ArmVirtQemuKernel.dsc   | 2 +-
 .../Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf  | 5 ++---
 .../Library/QemuFwCfgLib/QemuFwCfgLibMMIO.c| 7 ---
 4 files changed, 8 insertions(+), 8 deletions(-)
 rename ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf => 
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf (88%)
 rename ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c => 
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.c (93%)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index e2d3d10997..cde55af64c 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -60,7 +60,7 @@
   # Virtio Support
   VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
   
VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
-  QemuFwCfgLib|ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
+  QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
   
QemuFwCfgSimpleParserLib|OvmfPkg/Library/QemuFwCfgSimpleParserLib/QemuFwCfgSimpleParserLib.inf
   
QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index fa63978f24..4ae5ef3172 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -58,7 +58,7 @@
   # Virtio Support
   VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
   
VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
-  QemuFwCfgLib|ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
+  QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
   
QemuFwCfgSimpleParserLib|OvmfPkg/Library/QemuFwCfgSimpleParserLib/QemuFwCfgSimpleParserLib.inf
   
QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf
diff --git a/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf
similarity index 88%
rename from ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
rename to OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf
index 74db3b01f4..f92dcf10b7 100644
--- a/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf
@@ -24,17 +24,16 @@
 # The following information is for reference only and not required by the build
 # tools.
 #
-#  VALID_ARCHITECTURES   = ARM AARCH64
+#  VALID_ARCHITECTURES   = ARM AARCH64 RISCV64
 #
 
 [Sources]
-  QemuFwCfgLib.c
+  QemuFwCfgLibMMIO.c
 
 [Packages]
   MdePkg/MdePkg.dec
   OvmfPkg/OvmfPkg.dec
   EmbeddedPkg/EmbeddedPkg.dec
-  ArmVirtPkg/ArmVirtPkg.dec
 
 [LibraryClasses]
   BaseLib
diff --git a/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.c
similarity index 93%
rename from ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
rename to OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.c
index e2ac4108d1..b953f2eb6c 100644
--- a/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.c
@@ -4,6 +4,7 @@
 
   Copyright (C) 2013 - 2014, Red Hat, Inc.
   Copyright (c) 2011 - 2013, Intel Corporation. All rights reserved.
+  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
@@ -239,7 +240,7 @@ MmioReadBytes (
   UINT8 *Ptr;
   UINT8 *End;
 
-#ifdef MDE_CPU_AARCH64
+#if defined(MDE_CPU_AARCH64) || defined(MDE_CPU_RISCV64)
   Left = Size & 7;
 #else
   Left = Size & 3;
@@ -249,7 +250,7 @@ MmioReadBytes (
   Ptr = Buffer;
   End = Ptr + Size;
 
-#ifdef MDE_CPU_AARCH64
+#if defined(MDE_CPU_AARCH64) || defined(MDE_CPU_RISCV64)
   while (Ptr < End) {
 *(UINT64 *)Ptr = MmioRead64 (mFwCfgDataAddress);
 Ptr += 8;
@@ -322,7 +323,7 @@ DmaTransferBytes (
   //
   // This will fire off the transfer.
   //
-#ifdef MDE_CPU_AARCH64
+#if defined(MDE_CPU_AARCH64) || defined(MDE_CPU_RISCV64)
   MmioWrite64 (mFwCfgDmaAddress, SwapBytes64 ((UINT64)&Access));
 #else
   MmioWrite32 ((UINT32)(mFwCfgDmaAddress + 4), SwapBytes32 ((UINT32)&Access));
-- 
2.17.1



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

[edk2-devel] [PATCH 1/9] ArmVirtPkg/FdtClintDxe: Move FdtClientDxe to EmbeddedPkg

2021-09-27 Thread Abner Chang

This is one of the series patches to restructure the location of modules under
ArmVirtPkg for RiscVVirtPkg. RiscVVirtPkg leverage FDT Client protocol to
parse FDT nodes.

Signed-off-by: Abner Chang 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Gerd Hoffmann 
Cc: Daniel Schaefer 
Cc: Sunil V L 
---
 ArmVirtPkg/ArmVirtPkg.dec | 4 +---
 EmbeddedPkg/EmbeddedPkg.dec   | 2 ++
 ArmVirtPkg/ArmVirtCloudHv.dsc | 3 ++-
 ArmVirtPkg/ArmVirtKvmTool.dsc | 3 ++-
 ArmVirtPkg/ArmVirtQemu.dsc| 3 ++-
 ArmVirtPkg/ArmVirtQemuKernel.dsc  | 3 ++-
 ArmVirtPkg/ArmVirtXen.dsc | 3 ++-
 EmbeddedPkg/EmbeddedPkg.dsc   | 2 ++
 ArmVirtPkg/ArmVirtCloudHv.fdf | 3 ++-
 ArmVirtPkg/ArmVirtKvmTool.fdf | 3 ++-
 ArmVirtPkg/ArmVirtXen.fdf | 3 ++-
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc  | 3 ++-
 ArmVirtPkg/HighMemDxe/HighMemDxe.inf  | 2 ++
 ArmVirtPkg/Library/ArmVirtGicArchLib/ArmVirtGicArchLib.inf| 2 ++
 .../ArmVirtPL031FdtClientLib/ArmVirtPL031FdtClientLib.inf | 2 ++
 .../ArmVirtPsciResetSystemLib/ArmVirtPsciResetSystemLib.inf   | 2 ++
 .../ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf | 2 ++
 .../Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf   | 2 ++
 .../Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf | 2 ++
 .../Library/KvmtoolRtcFdtClientLib/KvmtoolRtcFdtClientLib.inf | 2 ++
 ArmVirtPkg/Library/NorFlashKvmtoolLib/NorFlashKvmtoolLib.inf  | 3 +++
 ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf| 2 ++
 ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf  | 2 ++
 ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf  | 2 ++
 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf  | 2 ++
 ArmVirtPkg/XenioFdtDxe/XenioFdtDxe.inf| 2 ++
 .../Drivers}/FdtClientDxe/FdtClientDxe.inf| 2 +-
 {ArmVirtPkg => EmbeddedPkg}/Include/Protocol/FdtClient.h  | 0
 .../Drivers}/FdtClientDxe/FdtClientDxe.c  | 0
 29 files changed, 53 insertions(+), 13 deletions(-)
 rename {ArmVirtPkg => EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.inf (88%)
 rename {ArmVirtPkg => EmbeddedPkg}/Include/Protocol/FdtClient.h (100%)
 rename {ArmVirtPkg => EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.c (100%)

diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
index 4e4d758015..f5d34283b9 100644
--- a/ArmVirtPkg/ArmVirtPkg.dec
+++ b/ArmVirtPkg/ArmVirtPkg.dec
@@ -2,6 +2,7 @@
 #
 #  Copyright (c) 2014, Linaro Limited. All rights reserved.
 #  Copyright (c) 2020, ARM Limited. All rights reserved.
+#  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -35,9 +36,6 @@
 
   gArmVirtVariableGuid   = { 0x50bea1e5, 0xa2c5, 0x46e9, { 0x9b, 0x3a, 0x59, 
0x59, 0x65, 0x16, 0xb0, 0x0a } }
 
-[Protocols]
-  gFdtClientProtocolGuid = { 0xE11FACA0, 0x4710, 0x4C8E, { 0xA7, 0xA2, 0x01, 
0xBA, 0xA2, 0x59, 0x1B, 0x4C } }
-
 [PcdsFeatureFlag]
   #
   # Feature Flag PCD that defines whether TPM2 support is enabled
diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
index 7638de..932d1b6077 100644
--- a/EmbeddedPkg/EmbeddedPkg.dec
+++ b/EmbeddedPkg/EmbeddedPkg.dec
@@ -5,6 +5,7 @@
 # Copyright (c) 2007, Intel Corporation. All rights reserved.
 # Copyright (c) 2012-2015, ARM Ltd. All rights reserved.
 # Copyright (c) 2017, Linaro Ltd. All rights reserved.
+# (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -79,6 +80,7 @@
   gPlatformGpioProtocolGuid = { 0x52ce9845, 0x5af4, 0x43e2, {0xba, 0xfd, 0x23, 
0x08, 0x12, 0x54, 0x7a, 0xc2 }}
   gPlatformVirtualKeyboardProtocolGuid = { 0x0e3606d2, 0x1dc3, 0x4e6f, { 0xbe, 
0x65, 0x39, 0x49, 0x82, 0xa2, 0x65, 0x47 }}
   gAndroidBootImgProtocolGuid = { 0x9859bb19, 0x407c, 0x4f8b, {0xbc, 0xe1, 
0xf8, 0xda, 0x65, 0x65, 0xf4, 0xa5 }}
+  gFdtClientProtocolGuid = { 0xE11FACA0, 0x4710, 0x4C8E, { 0xA7, 0xA2, 0x01, 
0xBA, 0xA2, 0x59, 0x1B, 0x4C } }
 
 [Ppis]
   gEdkiiEmbeddedGpioPpiGuid = { 0x21c3b115, 0x4e0b, 0x470c, { 0x85, 0xc7, 
0xe1, 0x05, 0xa5, 0x75, 0xc9, 0x7b }}
diff --git a/ArmVirtPkg/ArmVirtCloudHv.dsc b/ArmVirtPkg/ArmVirtCloudHv.dsc
index f292ba6079..9e0dd6df0b 100644
--- a/ArmVirtPkg/ArmVirtCloudHv.dsc
+++ b/ArmVirtPkg/ArmVirtCloudHv.dsc
@@ -1,5 +1,6 @@
 #
 #  Copyright (c) 2021, ARM Limited. All rights reserved.
+#  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -293,7 +294,7 @@
   # Platform Driver
   #
   ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
-  ArmVirtPkg/FdtCli

[edk2-devel] [PATCH 3/9] ArmPkg: Use PcdPciIoTranslation PCD from MdePkg

2021-09-27 Thread Abner Chang

PcdPciIoTranslation PCD is relocated to MdePkg and leveraged by
both ARM and RISC-V arch. This patch removes the one from ArmPkg
and address the corresponding changes required for other modules
under ArmVirtPkg.

Signed-off-by: Abner Chang 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Gerd Hoffmann 
Cc: Daniel Schaefer 
Cc: Sunil V L 
---
 ArmPkg/ArmPkg.dec   | 6 +++---
 ArmVirtPkg/ArmVirtCloudHv.dsc   | 2 +-
 ArmVirtPkg/ArmVirtKvmTool.dsc   | 2 +-
 ArmVirtPkg/ArmVirtQemu.dsc  | 2 +-
 ArmVirtPkg/ArmVirtQemuKernel.dsc| 2 +-
 ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf  | 3 ++-
 .../Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf | 2 +-
 .../Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf   | 2 +-
 8 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 6ed51edd03..5793094fa3 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -3,6 +3,7 @@
 #
 # Copyright (c) 2009 - 2010, Apple Inc. All rights reserved.
 # Copyright (c) 2011 - 2021, ARM Limited. All rights reserved.
+# (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -337,7 +338,7 @@
   #   UINT64 Mmio32CpuBase; // mapping target in 64-bit cpu-physical space
   #   UINT64 Mmio64CpuBase; // mapping target in 64-bit cpu-physical space
   #
-  #   PcdPciIoTranslation = IoCpuBase - PcdPciIoBase;
+  #   gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation = IoCpuBase - PcdPciIoBase;
   #   PcdPciMmio32Translation = Mmio32CpuBase - (UINT64)PcdPciMmio32Base;
   #   PcdPciMmio64Translation = Mmio64CpuBase - PcdPciMmio64Base;
   #
@@ -356,7 +357,7 @@
   #   UINT64 TranslatedMmio64Address;   // output parameter
   #
   #   TranslatedIoAddress = UntranslatedIoAddress +
-  # PcdPciIoTranslation;
+  # gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation;
   #   TranslatedMmio32Address = (UINT64)UntranslatedMmio32Address +
   # PcdPciMmio32Translation;
   #   TranslatedMmio64Address = UntranslatedMmio64Address +
@@ -369,7 +370,6 @@
   #
   gArmTokenSpaceGuid.PcdPciIoBase|0x0|UINT64|0x0050
   gArmTokenSpaceGuid.PcdPciIoSize|0x0|UINT64|0x0051
-  gArmTokenSpaceGuid.PcdPciIoTranslation|0x0|UINT64|0x0052
   gArmTokenSpaceGuid.PcdPciMmio32Base|0x0|UINT32|0x0053
   gArmTokenSpaceGuid.PcdPciMmio32Size|0x0|UINT32|0x0054
   gArmTokenSpaceGuid.PcdPciMmio32Translation|0x0|UINT64|0x0055
diff --git a/ArmVirtPkg/ArmVirtCloudHv.dsc b/ArmVirtPkg/ArmVirtCloudHv.dsc
index 9e0dd6df0b..593663a6c5 100644
--- a/ArmVirtPkg/ArmVirtCloudHv.dsc
+++ b/ArmVirtPkg/ArmVirtCloudHv.dsc
@@ -193,7 +193,7 @@
   # PCD and PcdPciDisableBusEnumeration above have not been assigned yet
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x
 
-  gArmTokenSpaceGuid.PcdPciIoTranslation|0
+  gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation|0
 
   gEfiSecurityPkgTokenSpaceGuid.PcdTpmBaseAddress|0x0
 
diff --git a/ArmVirtPkg/ArmVirtKvmTool.dsc b/ArmVirtPkg/ArmVirtKvmTool.dsc
index 7587fd4ca0..64cc7d7cf0 100644
--- a/ArmVirtPkg/ArmVirtKvmTool.dsc
+++ b/ArmVirtPkg/ArmVirtKvmTool.dsc
@@ -185,7 +185,7 @@
   # PCD and PcdPciDisableBusEnumeration above have not been assigned yet
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x
 
-  gArmTokenSpaceGuid.PcdPciIoTranslation|0x0
+  gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation|0x0
 
   #
   # Set video resolution for boot options and for text setup.
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 4e39307e7c..04d283004e 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -248,7 +248,7 @@
   # PCD and PcdPciDisableBusEnumeration above have not been assigned yet
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x
 
-  gArmTokenSpaceGuid.PcdPciIoTranslation|0x0
+  gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation|0x0
 
   #
   # Set video resolution for boot options and for text setup.
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index f1bb1cd09e..c2f72c4ae2 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -228,7 +228,7 @@
   # PCD and PcdPciDisableBusEnumeration above have not been assigned yet
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x
 
-  gArmTokenSpaceGuid.PcdPciIoTranslation|0x0
+  gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation|0x0
 
   #
   # Set video resolution for boot options and for text setup.
diff --git a/ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf 
b/ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf
index 2bc4571d06..3ffec4148c 100644
--- a/ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf
+++ b/ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPci

Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector

2021-09-27 Thread Gerd Hoffmann

  Hi,

> > struct {
> > uint64_t load_address;
> > uint32_t file_offset;
> > uint32_t section_size;
> > uint32_t section_type;
> > uint32_t section_flags;
> > };
> 
> [Jiewen] This data structure does not work in a special use case - A
> TD may want to have a fixed memory size.  It is TD that tells the VMM
> how many DRAM should be allocated by using metadata table. Not the
> case that a VMM tells the TD how many DRAM is allocated by using HOB.
> 
> In that special case, the TD_HOB is NOT required. The VMM parses the
> metadata to allocate the DRAM (AUG page).

Hmm.  Not covered in tdx-virtual-firmware-design-guide-rev-1.pdf

> The runtime section size must be UINT64, otherwise we cannot support > 4G 
> memory section.
> The build time section size can be UINT32. We don't expect to create a >4G 
> binary in near future.
> And we need both.

That still doesn't explain why you need two sizes.  Instead of depending
on zero-fill in case MemoryDataSize > RawDataSize you can just use two
entries, simliar to ELF binaries which have separate '.data' and '.bss'
sections too.

> I can understand why you think there is no needed fields, based upon
> what you see in EDKII/TDVF project.  However, the usage in current
> TDVF is just a subset, but not all usages.

So you are doing stuff behind closed doors ...

> The TDX metadata structure is carefully designed to support those
> variants. Also, leaving some room for future is a common practice.
> Besides EDKII/TDVF, we are doing other TDX related projects reusing
> the same metadata structure. (But sorry, I cannot tell more at this
> time.)

... and don't want tell details.  Even the fact that you are doing that
is disclosed only after poking for a while because the patches submitted
leave a bunch of questions open.

This is NOT how Open Source Development works.

If the patches can't speak for themself in cases like this the very
minimum requirement is proper documentation.  It is not acceptable
that I have to ask five times to figure that the format is supposed
to cover use cases beyond TDVF.

> The benefit is that the KVM or cloud hypervisor can have a common
> logic to handle "TDX boot", instead of using different table in
> different use cases.

The benefit of a unified table for tdx and sev is that the VMM can
have common logic to find page ranges which need special
initialization.

But I suspect at that point we are going to trade code sharing at one
place for code sharing at another place.

> I think it is OK, if SEV wants to reuse the existing TDX metadata
> table. (We need SEV people agree.) Then we can have one metadata
> table. 

So, when submitting the next revision of this series, please ...

  (1) Move the tdx metadata changes to a separate patch.
  (2) Add *complete* documentation for the TDX metadata format

... so the SEV people can make up their mind whenever they want use
that or not.

Please do also clarify what the process to allocate section type numbers
(or reserve a number range) for SEV would be.

> [Jiewen] We don't fork OVMF in config-B.
>
> Instead of we will create new Tdvf/Tdvf.dsc and Tdvf/Tdvf.fdf in
> config-B, similar to
> https://github.com/tianocore/edk2/tree/master/OvmfPkg/AmdSev or
> https://github.com/tianocore/edk2/tree/master/OvmfPkg/Bhyve That is
> why I treat it as different platform.

The differences between Ovmf and AmdSev are very small.

Bhyve has more differences, but it's a different hypervisor
so it isn't surprising it has its own PlatformPei.

How does Tdvf handle the platform setup?  It must be done in SEC
somehow, so I suspect you have a (possibly stripped-down) version
of the PlatformPei adapted for SEC?  That is exactly the kind of
code duplication I want avoid.

> I reluctant to merge it back to Ovmf.dsc/fdf.

I don't worry that much about Ovmf.dsc/fdf files.  Whenever we add a
compile-time option (-D ENABLE_TDX) to Ovmf.dsc/fdf or whenever we add a
separate Tdvf.dsc/fdf doesn't make that much of a difference.

I'm more worried about the code duplication and the completely different
(PEI-less) initialization workflow.  When touching the platform setup
code both cases (with/without PEI) must be considered, which increases
development and testing and maintenance effort long-term.

I want less variants, not more.  Ideally I'd like to also get rid of the
OvmfPkgIa32X64.dsc/fdf for example.  It seems some features have a
dependency on PEI running in 32-bit mode though.

> The reason is the main Ovmf supports some features (such as S3, TPM)
> which may depend on PEI modules, but it is NOT needed in TDVF.

So using PEI in OVMF isn't that over-engineered, isn't it?

And I suspect SMM support can be added to the list of features which
depend on the PEI phase (at least when we want reuse the existing common
code in UefiCpuPkg, MdePkg and elsewhere).

> We need re-evaluate the effort to enable those features in non-PEI
> configuration in OVMF. - That is totally unnecessary in TDVF enabling
> task.

Well,

[edk2-devel] [edk2-platforms PATCH] SpcrFeaturePkg: Close event in callback routine.

2021-09-27 Thread Abdul Lateef Attar via groups.io

Adds CloseEvent in callbackroutine
OutOfBandACPITableConstruction(),
To avoid multiple installation of SPCR table.

Signed-off-by: Abdul Lateef Attar 
---
 .../OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c   | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c 
b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c
index 85ac48cfa5..86c40e90b8 100644
--- a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c
+++ b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c
@@ -368,6 +368,8 @@ OutOfBandACPITableConstruction (
 
   Handle  = NULL;
 
+  gBS->CloseEvent (Event);
+
   SavedDevicePath = GetSpcrDevice();
   if (SavedDevicePath == NULL) {
 return;
-- 
2.25.1



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

Re: [edk2-devel] [edk2-discuss] a question about X509 flag

2021-09-27 Thread wenyi,xie via groups.io




On 2021/9/27 17:21, Marvin Häuser wrote:
> Hey Wenyi,
> 
> Sorry, I cannot help with the time one, but "partial chain" is how virtually 
> any other crypto-solution works out-of-the-box. Basically there is a 
> disagreement about what defines a root certificate, and while some think it 
> is the OpenSSL default of requiring a self-signed certificate for root, many 
> people including myself strongly disagree and do not believe it follows from 
> the RFCs. I'm not aware of any bad security implications of either model. So, 
> this merely allows any certificate in the chain (the top one may be 
> self-signed *if* it even is a certificate, it may just as well be a trusted 
> public key for all we know) to be eligible to be added to the trust store and 
> root a trust chain.
> 

Thank you for your explanation in detail, it helps a lot. 
X509_V_FLAG_PARTIAL_CHAIN is clear to me now.

Wenyi

> Further reading: https://github.com/openssl/openssl/issues/7871
> 
> Cc CryptoPkg maintainers and edk2-devel for further feedback
> 
> Best regards,
> Marvin
> 
> On 27/09/2021 10:53, wenyi,xie via groups.io wrote:
>> Hello,
>>
>> I have a question about flag set in X509_STORE. Does anyone know why need to 
>> set flags X509_V_FLAG_PARTIAL_CHAIN and X509_V_FLAG_NO_CHECK_TIME to 
>> X509Store in TlsNew() (CryptoPkg\Library\TlsLib\TlsInit.c)
>>
>> Thanks
>> Wenyi
>>
>>
>> 
>>
>>
> 
> .


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

Re: [edk2-devel] [PATCH] UserAuthFeaturePkg/UserAuthenticationDxeSmm: The SMI to handle the user authentication should be unregister before booting to OS

2021-09-27 Thread Dandan Bi

Hi Hao,


Some minor comments below. Please check inline.



Thanks,
Dandan

> -Original Message-
> From: Shi, Hao 
> Sent: Thursday, September 23, 2021 12:02 PM
> To: devel@edk2.groups.io
> Cc: Shi, Hao ; Bi, Dandan 
> Subject: [PATCH] UserAuthFeaturePkg/UserAuthenticationDxeSmm: The
> SMI to handle the user authentication should be unregister before booting
> to OS
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3648
> 
> Register SmmExitBootServices and SmmLegacyBoot callback function to
> unregister this handler.
> 
> Signed-off-by: Hao Shi 
> 
> ---
>  .../UserAuthenticationSmm.c   | 34 +++
>  .../UserAuthenticationSmm.inf |  2 ++
>  2 files changed, 36 insertions(+)
> 
> diff --git
> a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDx
> eSmm/UserAuthenticationSmm.c
> b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDx
> eSmm/UserAuthenticationSmm.c
> index 07e834eb..30f889dd 100644
> ---
> a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDx
> eSmm/UserAuthenticationSmm.c
> +++
> b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthentication
> +++ DxeSmm/UserAuthenticationSmm.c
> @@ -13,6 +13,7 @@ UINTN   mAdminPasswordTryCount = 0;
> 
>  BOOLEAN mNeedReVerify = TRUE;
>  BOOLEAN mPasswordVerified = FALSE;
> +EFI_HANDLE  mSmmHandle = NULL;
> 
>  /**
>Verify if the password is correct.
> @@ -612,6 +613,30 @@ EXIT:
>return EFI_SUCCESS;
>  }
> 
> +/**
> +  Performs Exit Boot Services UserAuthentication actions
> +
> +  @param[in] Protocol   Points to the protocol's unique identifier.
> +  @param[in] Interface  Points to the interface instance.
> +  @param[in] Handle The handle on which the interface was installed.
> +
> +  @retval EFI_SUCCESS   Notification runs successfully.
> +**/
> +EFI_STATUS
> +EFIAPI
> +UaExitBootServices (
> +  IN CONST EFI_GUID *Protocol,
> +  IN VOID   *Interface,
> +  IN EFI_HANDLE Handle
> +  )
> +{
> +  DEBUG ((DEBUG_INFO, "Unregister User Authentication Smi\n"));
> +
> +  gSmst->SmiHandlerUnRegister(mSmmHandle);
> +
> +  return EFI_SUCCESS;
> +}
> +
>  /**
>Main entry for this driver.
> 
> @@ -633,6 +658,7 @@ PasswordSmmInit (
>EDKII_VARIABLE_LOCK_PROTOCOL  *VariableLock;
>CHAR16
> PasswordHistoryName[sizeof(USER_AUTHENTICATION_VAR_NAME)/sizeof(
> CHAR16) + 5];
>UINTN Index;
> +  EFI_EVENT   ExitBootServicesEvent;
Please take care the alignment between new added code and old ones.

> 
>ASSERT (PASSWORD_HASH_SIZE == SHA256_DIGEST_SIZE);
>ASSERT (PASSWORD_HISTORY_CHECK_COUNT < 0x); @@ -663,6
> +689,14 @@ PasswordSmmInit (
>if (EFI_ERROR (Status)) {
>  return Status;
>}
> +  mSmmHandle = SmmHandle;
Could we only use one global variable for register and unregister? Then can 
remove this statement.

> +  //
> +  // Register for SmmExitBootServices and SmmLegacyBoot notification.
> +  //
> +  Status = gSmst->SmmRegisterProtocolNotify
> + (&gEdkiiSmmExitBootServicesProtocolGuid, UaExitBootServices,
> + &ExitBootServicesEvent);  ASSERT_EFI_ERROR (Status);  Status =
> + gSmst->SmmRegisterProtocolNotify (&gEdkiiSmmLegacyBootProtocolGuid,
> + UaExitBootServices, &ExitBootServicesEvent);  ASSERT_EFI_ERROR
> + (Status);

Could we not use &ExitBootServicesEvent for these two RegisterProtocolNotify? 
One generic name for both or two specific names for each?

> 
>if (IsPasswordCleared()) {
>  DEBUG ((DEBUG_INFO, "IsPasswordCleared\n")); diff --git
> a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDx
> eSmm/UserAuthenticationSmm.inf
> b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDx
> eSmm/UserAuthenticationSmm.inf
> index 0b33b194..d73a2fe2 100644
> ---
> a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDx
> eSmm/UserAuthenticationSmm.inf
> +++
> b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthentication
> +++ DxeSmm/UserAuthenticationSmm.inf
> @@ -48,6 +48,8 @@
>  [Protocols]
>gEdkiiVariableLockProtocolGuid## CONSUMES
>gEfiSmmVariableProtocolGuid   ## CONSUMES
> +  gEdkiiSmmExitBootServicesProtocolGuid ## CONSUMES
> +  gEdkiiSmmLegacyBootProtocolGuid   ## CONSUMES
> 
>  [Depex]
>gEfiSmmVariableProtocolGuid AND gEfiVariableWriteArchProtocolGuid
> --
> 2.26.2.windows.1



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

Re: [edk2-devel] [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address based on Build Type

2021-09-27 Thread Zeng, Star

Typo "ignored" to "not ignored".

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Zeng, Star
Sent: 2021年9月27日 18:36
To: S, Ashraf Ali ; Chiu, Chasel 
; devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Kuo, Ted 
; Duggapu, Chinni B ; Chaganty, 
Rangasai V ; Solanki, Digant H 
; V, Sangeetha ; Ni, Ray 
; Zeng, Star 
Subject: Re: [edk2-devel] [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data 
address based on Build Type

If someone sets the PCD PcdFspmUpdDataAddress64 accidentally, it is better to 
be caught by some way but ignored.

BTW, if the function GetFspmUpdDataAddress() is a internal function in the 
module, no EFIAPI is needed in the declaration.

And, @Chiu, Chasel, is PcdFspmUpdDataAddress supposed to be always configured 
to be Dynamic type by platform?

If yes, maybe we can have two help functions in FspWrapperPlatformLib like 
below and remove "PcdsFixedAtBuild, PcdsPatchableInModule" in dec. Platform can 
use SetFspmUpdDataAddress() without need to be aware of the PCDs.

UINTN
EFIAPI
GetFspmUpdDataAddress (
  VOID
  )
{
  if (PcdGet64 (PcdFspmUpdDataAddress64) != 0) {
return (UINTN) PcdGet64 (PcdFspmUpdDataAddress64);
  } else {
return (UINTN) PcdGet32 (PcdFspmUpdDataAddress);
  }
}

VOID
EFIAPI
SetFspmUpdDataAddress (
  IN UINTN Address
  )
{
  if (Address <= MAX_UINT32) {
PcdSet32S (PcdFspmUpdDataAddress, (UINT32) Address);
  } else {
PcdSet64S (PcdFspmUpdDataAddress64, (UINT64) Address);
  }
}


-Original Message-
From: S, Ashraf Ali 
Sent: 2021年9月27日 18:16
To: Zeng, Star ; Chiu, Chasel ; 
devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Kuo, Ted 
; Duggapu, Chinni B ; Chaganty, 
Rangasai V ; Solanki, Digant H 
; V, Sangeetha ; Ni, Ray 

Subject: RE: [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address based on 
Build Type

Hi., @Zeng, Star

Creating a single function is doable, but the problem with that is If someone 
set the PCD  PcdFspmUpdDataAddress64 accidentally which should be applicable 
only in X64. Since the PCD has some junk value, it will return the false data 
in IA32 case. Which will break everything with respect to FSP-S/M.

To Avoid Such cases separating the IA32 vs X64 is more feasible. And easily 
differentiating with IA32 and X64. 

Regards,
Ashraf Ali S
Intel Technology India Pvt. Ltd. 

-Original Message-
From: Zeng, Star 
Sent: Monday, September 27, 2021 2:15 PM
To: Chiu, Chasel ; S, Ashraf Ali 
; devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Kuo, Ted 
; Duggapu, Chinni B ; Chaganty, 
Rangasai V ; Solanki, Digant H 
; V, Sangeetha ; Ni, Ray 
; Zeng, Star 
Subject: RE: [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address based on 
Build Type

Curious: It does not work to have one function implementation like below?

UINTN
EFIAPI
GetFspmUpdDataAddress (
  VOID
  )
{
  if (PcdGet64 (PcdFspmUpdDataAddress64) != 0) {
return (UINTN) PcdGet64 (PcdFspmUpdDataAddress64);
  } else {
return (UINTN) PcdGet32 (PcdFspmUpdDataAddress);
  }
}

Thanks,
Star

-Original Message-
From: Chiu, Chasel 
Sent: Monday, September 27, 2021 9:10 AM
To: S, Ashraf Ali ; devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Zeng, Star 
; Kuo, Ted ; Duggapu, Chinni B 
; Chaganty, Rangasai V 
; Solanki, Digant H 
; V, Sangeetha ; Ni, Ray 

Subject: RE: [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address based on 
Build Type


Reviewed-by: Chasel Chiu 

> -Original Message-
> From: S, Ashraf Ali 
> Sent: Friday, September 24, 2021 7:43 PM
> To: devel@edk2.groups.io
> Cc: S, Ashraf Ali ; Chiu, Chasel 
> ; Desimone, Nathaniel L 
> ; Zeng, Star ; 
> Kuo, Ted ; Duggapu, Chinni B 
> ; Chaganty, Rangasai V 
> ; Solanki, Digant H 
> ; V, Sangeetha ; 
> Ni, Ray 
> Subject: [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address 
> based on Build Type
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3642
> when the module is not building in IA32 mode which will lead to building 
> error.
> when a module built-in X64 function pointer will be the size of 64bit 
> width which cannot be fit in 32bit address which will lead to error.
> to overcome this issue introducing the 2 new PCD's for the 64bit modules can 
> consume it.
> Creating the API's to support different architecture
> 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Star Zeng 
> Cc: Kuo Ted 
> Cc: Duggapu Chinni B 
> Cc: Rangasai V Chaganty 
> Cc: Digant H Solanki 
> Cc: Sangeetha V 
> Cc: Ray Ni 
> Signed-off-by: Ashraf Ali S 
> ---
>  .../FspmWrapperPeim/FspmWrapperPeim.c | 19 +++---
>  .../FspmWrapperPeim/FspmWrapperPeim.inf   | 16 ++--
>  .../FspmWrapperPeim/IA32/FspmHelper.c | 26 +++
>  .../FspmWrapperPeim/X64/FspmHelper.c  | 26 +++
>  .../FspsWrapperPeim/FspsWrapperPeim.c | 17 +---
>  .../FspsWrapperPeim/FspsWrapperPeim.inf   | 14 +-
>  .../FspsWrapperPeim/IA32/FspsHelper.c | 26 +++
>  .../FspsWrapperPeim/X64/FspsHelper.c  |

Re: [edk2-devel] [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address based on Build Type

2021-09-27 Thread Zeng, Star

If someone sets the PCD PcdFspmUpdDataAddress64 accidentally, it is better to 
be caught by some way but ignored.

BTW, if the function GetFspmUpdDataAddress() is a internal function in the 
module, no EFIAPI is needed in the declaration.

And, @Chiu, Chasel, is PcdFspmUpdDataAddress supposed to be always configured 
to be Dynamic type by platform?

If yes, maybe we can have two help functions in FspWrapperPlatformLib like 
below and remove "PcdsFixedAtBuild, PcdsPatchableInModule" in dec. Platform can 
use SetFspmUpdDataAddress() without need to be aware of the PCDs.

UINTN
EFIAPI
GetFspmUpdDataAddress (
  VOID
  )
{
  if (PcdGet64 (PcdFspmUpdDataAddress64) != 0) {
return (UINTN) PcdGet64 (PcdFspmUpdDataAddress64);
  } else {
return (UINTN) PcdGet32 (PcdFspmUpdDataAddress);
  }
}

VOID
EFIAPI
SetFspmUpdDataAddress (
  IN UINTN Address
  )
{
  if (Address <= MAX_UINT32) {
PcdSet32S (PcdFspmUpdDataAddress, (UINT32) Address);
  } else {
PcdSet64S (PcdFspmUpdDataAddress64, (UINT64) Address);
  }
}


-Original Message-
From: S, Ashraf Ali  
Sent: 2021年9月27日 18:16
To: Zeng, Star ; Chiu, Chasel ; 
devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Kuo, Ted 
; Duggapu, Chinni B ; Chaganty, 
Rangasai V ; Solanki, Digant H 
; V, Sangeetha ; Ni, Ray 

Subject: RE: [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address based on 
Build Type

Hi., @Zeng, Star

Creating a single function is doable, but the problem with that is If someone 
set the PCD  PcdFspmUpdDataAddress64 accidentally which should be applicable 
only in X64. Since the PCD has some junk value, it will return the false data 
in IA32 case. Which will break everything with respect to FSP-S/M.

To Avoid Such cases separating the IA32 vs X64 is more feasible. And easily 
differentiating with IA32 and X64. 

Regards,
Ashraf Ali S
Intel Technology India Pvt. Ltd. 

-Original Message-
From: Zeng, Star 
Sent: Monday, September 27, 2021 2:15 PM
To: Chiu, Chasel ; S, Ashraf Ali 
; devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Kuo, Ted 
; Duggapu, Chinni B ; Chaganty, 
Rangasai V ; Solanki, Digant H 
; V, Sangeetha ; Ni, Ray 
; Zeng, Star 
Subject: RE: [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address based on 
Build Type

Curious: It does not work to have one function implementation like below?

UINTN
EFIAPI
GetFspmUpdDataAddress (
  VOID
  )
{
  if (PcdGet64 (PcdFspmUpdDataAddress64) != 0) {
return (UINTN) PcdGet64 (PcdFspmUpdDataAddress64);
  } else {
return (UINTN) PcdGet32 (PcdFspmUpdDataAddress);
  }
}

Thanks,
Star

-Original Message-
From: Chiu, Chasel 
Sent: Monday, September 27, 2021 9:10 AM
To: S, Ashraf Ali ; devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Zeng, Star 
; Kuo, Ted ; Duggapu, Chinni B 
; Chaganty, Rangasai V 
; Solanki, Digant H 
; V, Sangeetha ; Ni, Ray 

Subject: RE: [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address based on 
Build Type


Reviewed-by: Chasel Chiu 

> -Original Message-
> From: S, Ashraf Ali 
> Sent: Friday, September 24, 2021 7:43 PM
> To: devel@edk2.groups.io
> Cc: S, Ashraf Ali ; Chiu, Chasel 
> ; Desimone, Nathaniel L 
> ; Zeng, Star ; 
> Kuo, Ted ; Duggapu, Chinni B 
> ; Chaganty, Rangasai V 
> ; Solanki, Digant H 
> ; V, Sangeetha ; 
> Ni, Ray 
> Subject: [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address 
> based on Build Type
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3642
> when the module is not building in IA32 mode which will lead to building 
> error.
> when a module built-in X64 function pointer will be the size of 64bit 
> width which cannot be fit in 32bit address which will lead to error. 
> to overcome this issue introducing the 2 new PCD's for the 64bit modules can 
> consume it.
> Creating the API's to support different architecture
> 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Star Zeng 
> Cc: Kuo Ted 
> Cc: Duggapu Chinni B 
> Cc: Rangasai V Chaganty 
> Cc: Digant H Solanki 
> Cc: Sangeetha V 
> Cc: Ray Ni 
> Signed-off-by: Ashraf Ali S 
> ---
>  .../FspmWrapperPeim/FspmWrapperPeim.c | 19 +++---
>  .../FspmWrapperPeim/FspmWrapperPeim.inf   | 16 ++--
>  .../FspmWrapperPeim/IA32/FspmHelper.c | 26 +++
>  .../FspmWrapperPeim/X64/FspmHelper.c  | 26 +++
>  .../FspsWrapperPeim/FspsWrapperPeim.c | 17 +---
>  .../FspsWrapperPeim/FspsWrapperPeim.inf   | 14 +-
>  .../FspsWrapperPeim/IA32/FspsHelper.c | 26 +++
>  .../FspsWrapperPeim/X64/FspsHelper.c  | 26 +++
>  IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec   |  2 ++
>  9 files changed, 162 insertions(+), 10 deletions(-)  create mode 
> 100644 IntelFsp2WrapperPkg/FspmWrapperPeim/IA32/FspmHelper.c
>  create mode 100644
> IntelFsp2WrapperPkg/FspmWrapperPeim/X64/FspmHelper.c
>  create mode 100644
> IntelFsp2WrapperPkg/FspsWrapperPeim/IA32/FspsHelper.c
>  create mode 100644 
> IntelFsp2WrapperPkg/FspsWrapperPeim/X64/FspsHe

Re: [edk2-devel] [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address based on Build Type

2021-09-27 Thread Ashraf Ali S

Hi., @Zeng, Star

Creating a single function is doable, but the problem with that is 
If someone set the PCD  PcdFspmUpdDataAddress64 accidentally which should be 
applicable only in X64. Since the PCD has some junk value, it will return the 
false data in IA32 case. Which will break everything with respect to FSP-S/M.

To Avoid Such cases separating the IA32 vs X64 is more feasible. And easily 
differentiating with IA32 and X64. 

Regards,
Ashraf Ali S
Intel Technology India Pvt. Ltd. 

-Original Message-
From: Zeng, Star  
Sent: Monday, September 27, 2021 2:15 PM
To: Chiu, Chasel ; S, Ashraf Ali 
; devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Kuo, Ted 
; Duggapu, Chinni B ; Chaganty, 
Rangasai V ; Solanki, Digant H 
; V, Sangeetha ; Ni, Ray 
; Zeng, Star 
Subject: RE: [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address based on 
Build Type

Curious: It does not work to have one function implementation like below?

UINTN
EFIAPI
GetFspmUpdDataAddress (
  VOID
  )
{
  if (PcdGet64 (PcdFspmUpdDataAddress) != 0) {
return (UINTN) PcdGet64 (PcdFspmUpdDataAddress64);
  } else {
return (UINTN) PcdGet32 (PcdFspmUpdDataAddress);
  }
}

Thanks,
Star

-Original Message-
From: Chiu, Chasel  
Sent: Monday, September 27, 2021 9:10 AM
To: S, Ashraf Ali ; devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Zeng, Star 
; Kuo, Ted ; Duggapu, Chinni B 
; Chaganty, Rangasai V 
; Solanki, Digant H 
; V, Sangeetha ; Ni, Ray 

Subject: RE: [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address based on 
Build Type


Reviewed-by: Chasel Chiu 

> -Original Message-
> From: S, Ashraf Ali 
> Sent: Friday, September 24, 2021 7:43 PM
> To: devel@edk2.groups.io
> Cc: S, Ashraf Ali ; Chiu, Chasel 
> ; Desimone, Nathaniel L 
> ; Zeng, Star ; 
> Kuo, Ted ; Duggapu, Chinni B 
> ; Chaganty, Rangasai V 
> ; Solanki, Digant H 
> ; V, Sangeetha ; 
> Ni, Ray 
> Subject: [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address 
> based on Build Type
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3642
> when the module is not building in IA32 mode which will lead to building 
> error.
> when a module built-in X64 function pointer will be the size of 64bit 
> width which cannot be fit in 32bit address which will lead to error. 
> to overcome this issue introducing the 2 new PCD's for the 64bit modules can 
> consume it.
> Creating the API's to support different architecture
> 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Star Zeng 
> Cc: Kuo Ted 
> Cc: Duggapu Chinni B 
> Cc: Rangasai V Chaganty 
> Cc: Digant H Solanki 
> Cc: Sangeetha V 
> Cc: Ray Ni 
> Signed-off-by: Ashraf Ali S 
> ---
>  .../FspmWrapperPeim/FspmWrapperPeim.c | 19 +++---
>  .../FspmWrapperPeim/FspmWrapperPeim.inf   | 16 ++--
>  .../FspmWrapperPeim/IA32/FspmHelper.c | 26 +++
>  .../FspmWrapperPeim/X64/FspmHelper.c  | 26 +++
>  .../FspsWrapperPeim/FspsWrapperPeim.c | 17 +---
>  .../FspsWrapperPeim/FspsWrapperPeim.inf   | 14 +-
>  .../FspsWrapperPeim/IA32/FspsHelper.c | 26 +++
>  .../FspsWrapperPeim/X64/FspsHelper.c  | 26 +++
>  IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec   |  2 ++
>  9 files changed, 162 insertions(+), 10 deletions(-)  create mode 
> 100644 IntelFsp2WrapperPkg/FspmWrapperPeim/IA32/FspmHelper.c
>  create mode 100644
> IntelFsp2WrapperPkg/FspmWrapperPeim/X64/FspmHelper.c
>  create mode 100644
> IntelFsp2WrapperPkg/FspsWrapperPeim/IA32/FspsHelper.c
>  create mode 100644 
> IntelFsp2WrapperPkg/FspsWrapperPeim/X64/FspsHelper.c
> 
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> index 24ab534620..4a15136c39 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> @@ -3,7 +3,7 @@
>register TemporaryRamDonePpi to call TempRamExit API, and register 
> MemoryDiscoveredPpi
>notify to call FspSiliconInit API.
> 
> -  Copyright (c) 2014 - 2020, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2014 - 2021, Intel Corporation. All rights 
> + reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -39,6 +39,17 @@
> 
>  extern EFI_GUID gFspHobGuid;
> 
> +/**
> +  Get the Fspm Upd Data Address from the PCD
> +
> +  @return FSPM UPD Data Address
> +**/
> +UINTN
> +EFIAPI
> +GetFspmUpdDataAddress (
> +  VOID
> +  );
> +
>  /**
>Call FspMemoryInit API.
> 
> @@ -59,7 +70,7 @@ PeiFspMemoryInit (
> 
>DEBUG ((DEBUG_INFO, "PeiFspMemoryInit enter\n"));
> 
> -  FspHobListPtr = NULL;
> +  FspHobListPtr  = NULL;
>FspmUpdDataPtr = NULL;
> 
>FspmHeaderPtr = (FSP_INFO_HEADER *) FspFindFspHeader (PcdGet32 
> (PcdFspmBaseAddress)); @@ -68,7 +79,7 @@ PeiFspMemoryInit (
>  return EFI_DEVICE_ERROR;
>}
> 
> -  if (PcdGet32 (PcdFspmUpdDataAddress) == 0 && (FspmHeaderPtr-
> >CfgRegionSize

Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector

2021-09-27 Thread Yao, Jiewen

Comment below:

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Gerd
> Hoffmann
> Sent: Monday, September 27, 2021 4:05 PM
> To: Yao, Jiewen 
> Cc: devel@edk2.groups.io; Xu, Min M ; Brijesh Singh
> ; Ard Biesheuvel ;
> Justen, Jordan L ; Erdem Aktas
> ; James Bottomley ; Tom
> Lendacky 
> Subject: Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector
> 
>   Hi,
> 
> > > Possible alternative approach: Define an extension
> > > (EFI_FIRMWARE_VOLUME_EXT_HEADER) for the load address and use that
> > > instead of defining something new.
> >
> > [Jiewen] I would say it is terrible idea to use
> EFI_FIRMWARE_VOLUME_HEADER.
> >
> > [ ... details snipped ... ]
> 
> Ok, lets scratch the idea then.
> 
> > > Still not clear why the size is in there twice.  I think you could
> > > instead use a flag telling whenever a section must be loaded from
> > > the image or not.  This is what COFF and ELF are doing too.
> > >
> > > Also not clear why you want stick to 64bit base address.  Loading the
> > > firmware above 4G isn't going to work without also changing a bunch of
> > > other things and it will break backward compatibility anyway.
> >
> > [Jiewen] That is our previously experience, when we define a physical 
> > address,
> we always use 64bit to leave room for extension.
> > Like UEFI specification defines PHYSICAL_ADDRESS to be UINT64 even in IA32
> platform.
> 
> Sure, physical address space on IA32 is 64G which simply doesn't fit into
> UINT32 ...
> 
> > Defining UINT64 gives us enough flexibility for the future, including test 
> > in
> above 4G environment.
> > I am wondering that, do you really care to save 4 bytes from UINT64 to
> UINT32 ?
> 
> Well, MEMFD isn't that big, so we have to care about the size there ...
> 
> > For type, maybe 2^16 is enough. But for flags, I prefer 32bit.
> 
> Making one 16bit and the other 32bit doesn't make much sense due
> to struct padding and alignment.  So with 64-bit load address and
> fields reordered so we don't have any padding the struct could look
> like this:
> 
> struct {
> uint64_t load_address;
> uint32_t file_offset;
> uint32_t section_size;
> uint32_t section_type;
> uint32_t section_flags;
> };

[Jiewen] This data structure does not work in a special use case - A TD may 
want to have a fixed memory size.

It is TD that tells the VMM how many DRAM should be allocated by using metadata 
table. Not the case that a VMM tells the TD how many DRAM is allocated by using 
HOB.

In that special case, the TD_HOB is NOT required. The VMM parses the metadata 
to allocate the DRAM (AUG page).

The runtime section size must be UINT64, otherwise we cannot support > 4G 
memory section.
The build time section size can be UINT32. We don't expect to create a >4G 
binary in near future.
And we need both.

I can understand why you think there is no needed fields, based upon what you 
see in EDKII/TDVF project.
However, the usage in current TDVF is just a subset, but not all usages.

The TDX metadata structure is carefully designed to support those variants. 
Also, leaving some room for future is a common practice.
Besides EDKII/TDVF, we are doing other TDX related projects reusing the same 
metadata structure. (But sorry, I cannot tell more at this time.)
The benefit is that the KVM or cloud hypervisor can have a common logic to 
handle "TDX boot", instead of using different table in different use cases.

Defining something only feasible in EDKII/OVMF will bring a burden. That is NOT 
a way we want to go.

Let me say in this way:
I think it is OK, if SEV wants to reuse the existing TDX metadata table. (We 
need SEV people agree.) Then we can have one metadata table. 
But we cannot reuse the SEV defined metadata table in 
https://github.com/AMDESE/ovmf/blob/snp-v8/OvmfPkg/ResetVector/X64/OvmfMetadata.asm,
 because it missed some fields we need. If that is the case, then we have to 
use 2 metadata tables.




> 
> > > But, again, I don't want have two completely different initialization
> > > code paths in OVMF.  We can certainly investigate and discuss dropping
> > > PEI, but that clearly shouldn't be a TDX-only thing.  When we eliminate
> > > PEI, we should do it for all OVMF builds.
> >
> > [Jiewen] I think this is out of scope of TDVF config-B patch series.
> > I don't think it is fair to enable OVMF to remove PEI, just because
> > TDVF does not need PEI.
> 
> Hmm?  TDVF is based on OVMF.  My expectation would be that TDVF is
> basically OVMF with TDX support added and most code being identical.
> So with TDVF being able to boot without PEI most of the work should
> already be done ...
> 
> > Each platform owner can have their own choice.
> 
> Why do you consider TDVF a separate platform?  I see it as OVMF variant.
> 
> Or did you just fork OVMF for config-b?  Doing so is certainly easier
> for initial development and prototyping, but it's bad in the long run.
> Having similar code twice in the code base means more long-term

Re: [edk2-devel] [edk2-discuss] a question about X509 flag

2021-09-27 Thread Marvin Häuser


Hey Wenyi,

Sorry, I cannot help with the time one, but "partial chain" is how 
virtually any other crypto-solution works out-of-the-box. Basically 
there is a disagreement about what defines a root certificate, and while 
some think it is the OpenSSL default of requiring a self-signed 
certificate for root, many people including myself strongly disagree and 
do not believe it follows from the RFCs. I'm not aware of any bad 
security implications of either model. So, this merely allows any 
certificate in the chain (the top one may be self-signed *if* it even is 
a certificate, it may just as well be a trusted public key for all we 
know) to be eligible to be added to the trust store and root a trust chain.


Further reading: https://github.com/openssl/openssl/issues/7871

Cc CryptoPkg maintainers and edk2-devel for further feedback

Best regards,
Marvin

On 27/09/2021 10:53, wenyi,xie via groups.io wrote:

Hello,

I have a question about flag set in X509_STORE. Does anyone know why need to 
set flags X509_V_FLAG_PARTIAL_CHAIN and X509_V_FLAG_NO_CHECK_TIME to X509Store 
in TlsNew() (CryptoPkg\Library\TlsLib\TlsInit.c)

Thanks
Wenyi









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

Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg

2021-09-27 Thread Marvin Häuser


On 27/09/2021 10:50, fanjianf...@byosoft.com.cn wrote:
For former caller, they could still keep as is to call the old API in 
MdeModulePkg. I think Ray's design is compatible change for existing code.
Only when the existing code wants to remove the dependency on 
MdeModuelPkg, they could migrate to the new API in baselib.


I agree with one split-API desgin what you mentioned.
But my point is to define one API in baselib and to make the baselib 
not depend on memory allocation. And another wrapper API could be 
designed to be placed in any other class.


Oh sure, it could totally live in another class. I'd just like to have 
those two models (caller- and callee-owned buffer) strictly separate, I 
personally do not mind where exactly they are implemented. Thanks!


Best regards,
Marvin




Jeff
fanjianf...@byosoft.com.cn

*From:* Marvin Häuser 
*Date:* 2021-09-27 16:14
*To:* fanjianf...@byosoft.com.cn
; devel@edk2.groups.io
; Ni, Ray ;
'gaoliming' ; Chan, Amy
; 'Andrew Fish' 
*CC:* Kinney, Michael D ; 'Gao,
Liming' ; Liu, Zhiguang
; Wang, Jian J
; Gao, Zhichao

*Subject:* Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg
On 27/09/2021 02:45, fanjianf...@byosoft.com.cn wrote:
> Making baselib implementation depend on MemoryAllocationLib
> (indirectly on Pei Service and gBS), it may prevent
> this base API using at some seneraio. i don't think it's better.
That is why I asked about a split-API scenario, one of which does not
depend on dynamic memory allocation (SetVariable-like) and one does
(wrapper-like).
> Add this parameter and make this parameter is optional,
> 1, when NULL, use the local 256 bytes stack
> 2, if 256 bytes stack is not enough, return RETURE_BUFFER_TOO_SAMLL,
> 3, caller check the return status, to do nothing or to allocate
enough
> buffer for retry
>
> This is just like SetVariable()'s implementation.
Yes, and because that is SetVariable's implementation, we have
library
functions to make it less error-prone and more convenient [1]. As a
matter of fact, we have a (semi-lax) policy in our codebases to avoid
such functions like the plague and use those library wrappers
where-ever
it can make sense. The only super-rare exceptions I can think of are
when we know the size of the element ahead of time. Also
SetVariable has
no arbitrary constraint on when it may work the first time, and
there is
code that will fail when the first return is not EFI_BUFFER_TOO_SMALL.
This solution honestly yields even more problems, because it
introduces
a Status return which was not there before. For common code safety
and
quality policy, this requires the value *must* be retrieved and
checked
in some fashion. So all callers, no matter the prior knowledge of the
element size, now need either a runtime check and handling for a
status
that they (may) know can never be returned, or ASSERTs if the
function
spec really imposes the arbitrary 256 Bytes constraint. Latter
doesn't
really work I think. What if someone wants to sort in SEC and noticed
they only have 64 Bytes on the stack to work with, realistically? Any
code depending on the 256 Byte constraint, passing NULL and not doing
additional handling, would seize to work. Former is too
complicated, see
wrappers. In my opinion, the memory must *either* be fully managed by
the caller *or* the callee (and you may have both in separate
functions,
as I suggested), but not sometimes here, sometimes there.
Best regards,
Marvin
[1]

https://github.com/tianocore/edk2/blob/46b4606ba23498d3d0e66b53e498eb3d5d592586/MdePkg/Library/UefiLib/UefiLib.c#L1309-L1360
>
>

> Jeff
> fanjianf...@byosoft.com.cn
>
> *From:* Marvin Häuser 
> *Date:* 2021-09-26 19:20
> *To:* devel ; ray.ni
> ; gaoliming
> ; Chan, Amy
> ; 'Andrew Fish'

> *CC:* Kinney, Michael D ;
'Gao,
> Liming' ; Liu, Zhiguang
> ; Wang, Jian J
> ; Gao, Zhichao
>

Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg

2021-09-27 Thread Jeff Fan

In fact, my concern is that making BaseLib's APIs depend on PeiService & Boot 
Services is not good.  

For a instance,  AP functions by MP service are not allowed to invoke any 
PeriServices and Boot Services.  And exception handlers cannot invoke those 
services either.

Jeff
fanjianf...@byosoft.com.cn

From: Jeff Fan
Date: 2021-09-27 16:50
To: devel@edk2.groups.io; mhaeuser; Ni, Ray; 'gaoliming'; Chan, Amy; 'Andrew 
Fish'
CC: Kinney, Michael D; 'Gao, Liming'; Liu, Zhiguang; Wang, Jian J; Gao, Zhichao
Subject: Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg
For former caller, they could still keep as is to call the old API in 
MdeModulePkg. I think Ray's design is compatible change for existing code.
Only when the existing code wants to remove the dependency on MdeModuelPkg, 
they could migrate to the new API in baselib.

I agree with one split-API desgin what you mentioned. 
But my point is to define one API in baselib and to make the baselib not depend 
on memory allocation.  And another wrapper API could be designed to be placed 
in any other class.

Jeff
fanjianf...@byosoft.com.cn

From: Marvin Häuser
Date: 2021-09-27 16:14
To: fanjianf...@byosoft.com.cn; devel@edk2.groups.io; Ni, Ray; 'gaoliming'; 
Chan, Amy; 'Andrew Fish'
CC: Kinney, Michael D; 'Gao, Liming'; Liu, Zhiguang; Wang, Jian J; Gao, Zhichao
Subject: Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg
On 27/09/2021 02:45, fanjianf...@byosoft.com.cn wrote:
> Making baselib implementation depend on MemoryAllocationLib 
> (indirectly on Pei Service and gBS), it may prevent 
> this base API using at some seneraio. i don't think it's better.

That is why I asked about a split-API scenario, one of which does not 
depend on dynamic memory allocation (SetVariable-like) and one does 
(wrapper-like).

> Add this parameter and make this parameter is optional,
> 1, when NULL, use the local 256 bytes stack
> 2, if 256 bytes stack is not enough, return RETURE_BUFFER_TOO_SAMLL,
> 3, caller check the return status, to do nothing or to allocate enough 
> buffer for retry
>
> This is just like SetVariable()'s implementation.

Yes, and because that is SetVariable's implementation, we have library 
functions to make it less error-prone and more convenient [1]. As a 
matter of fact, we have a (semi-lax) policy in our codebases to avoid 
such functions like the plague and use those library wrappers where-ever 
it can make sense. The only super-rare exceptions I can think of are 
when we know the size of the element ahead of time. Also SetVariable has 
no arbitrary constraint on when it may work the first time, and there is 
code that will fail when the first return is not EFI_BUFFER_TOO_SMALL.

This solution honestly yields even more problems, because it introduces 
a Status return which was not there before. For common code safety and 
quality policy, this requires the value *must* be retrieved and checked 
in some fashion. So all callers, no matter the prior knowledge of the 
element size, now need either a runtime check and handling for a status 
that they (may) know can never be returned, or ASSERTs if the function 
spec really imposes the arbitrary 256 Bytes constraint. Latter doesn't 
really work I think. What if someone wants to sort in SEC and noticed 
they only have 64 Bytes on the stack to work with, realistically? Any 
code depending on the 256 Byte constraint, passing NULL and not doing 
additional handling, would seize to work. Former is too complicated, see 
wrappers. In my opinion, the memory must *either* be fully managed by 
the caller *or* the callee (and you may have both in separate functions, 
as I suggested), but not sometimes here, sometimes there.

Best regards,
Marvin

[1] 
https://github.com/tianocore/edk2/blob/46b4606ba23498d3d0e66b53e498eb3d5d592586/MdePkg/Library/UefiLib/UefiLib.c#L1309-L1360

>
> 
> Jeff
> fanjianf...@byosoft.com.cn
>
> *From:* Marvin Häuser 
> *Date:* 2021-09-26 19:20
> *To:* devel ; ray.ni
> ; gaoliming
> ; Chan, Amy
> ; 'Andrew Fish' 
> *CC:* Kinney, Michael D ; 'Gao,
> Liming' ; Liu, Zhiguang
> ; Wang, Jian J
> ; Gao, Zhichao
> 
> *Subject:* Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg
> Hey Ray,
> In my opinion that spec is too complicated. For some cases it is
> obvious, but I think the last anyone wants to see is a
> (STATIC_)ASSERT
> before most QuickSort calls to ensure the element size *really* is <=
> 256 Bytes. In my opinion, there are two roads:
> 1) Make the parameter required (I think this is what Liming
>

Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg

2021-09-27 Thread Jeff Fan

For former caller, they could still keep as is to call the old API in 
MdeModulePkg. I think Ray's design is compatible change for existing code.
Only when the existing code wants to remove the dependency on MdeModuelPkg, 
they could migrate to the new API in baselib.

I agree with one split-API desgin what you mentioned. 
But my point is to define one API in baselib and to make the baselib not depend 
on memory allocation.  And another wrapper API could be designed to be placed 
in any other class.

Jeff
fanjianf...@byosoft.com.cn

From: Marvin Häuser
Date: 2021-09-27 16:14
To: fanjianf...@byosoft.com.cn; devel@edk2.groups.io; Ni, Ray; 'gaoliming'; 
Chan, Amy; 'Andrew Fish'
CC: Kinney, Michael D; 'Gao, Liming'; Liu, Zhiguang; Wang, Jian J; Gao, Zhichao
Subject: Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg
On 27/09/2021 02:45, fanjianf...@byosoft.com.cn wrote:
> Making baselib implementation depend on MemoryAllocationLib 
> (indirectly on Pei Service and gBS), it may prevent 
> this base API using at some seneraio. i don't think it's better.

That is why I asked about a split-API scenario, one of which does not 
depend on dynamic memory allocation (SetVariable-like) and one does 
(wrapper-like).

> Add this parameter and make this parameter is optional,
> 1, when NULL, use the local 256 bytes stack
> 2, if 256 bytes stack is not enough, return RETURE_BUFFER_TOO_SAMLL,
> 3, caller check the return status, to do nothing or to allocate enough 
> buffer for retry
>
> This is just like SetVariable()'s implementation.

Yes, and because that is SetVariable's implementation, we have library 
functions to make it less error-prone and more convenient [1]. As a 
matter of fact, we have a (semi-lax) policy in our codebases to avoid 
such functions like the plague and use those library wrappers where-ever 
it can make sense. The only super-rare exceptions I can think of are 
when we know the size of the element ahead of time. Also SetVariable has 
no arbitrary constraint on when it may work the first time, and there is 
code that will fail when the first return is not EFI_BUFFER_TOO_SMALL.

This solution honestly yields even more problems, because it introduces 
a Status return which was not there before. For common code safety and 
quality policy, this requires the value *must* be retrieved and checked 
in some fashion. So all callers, no matter the prior knowledge of the 
element size, now need either a runtime check and handling for a status 
that they (may) know can never be returned, or ASSERTs if the function 
spec really imposes the arbitrary 256 Bytes constraint. Latter doesn't 
really work I think. What if someone wants to sort in SEC and noticed 
they only have 64 Bytes on the stack to work with, realistically? Any 
code depending on the 256 Byte constraint, passing NULL and not doing 
additional handling, would seize to work. Former is too complicated, see 
wrappers. In my opinion, the memory must *either* be fully managed by 
the caller *or* the callee (and you may have both in separate functions, 
as I suggested), but not sometimes here, sometimes there.

Best regards,
Marvin

[1] 
https://github.com/tianocore/edk2/blob/46b4606ba23498d3d0e66b53e498eb3d5d592586/MdePkg/Library/UefiLib/UefiLib.c#L1309-L1360

>
> 
> Jeff
> fanjianf...@byosoft.com.cn
>
> *From:* Marvin Häuser 
> *Date:* 2021-09-26 19:20
> *To:* devel ; ray.ni
> ; gaoliming
> ; Chan, Amy
> ; 'Andrew Fish' 
> *CC:* Kinney, Michael D ; 'Gao,
> Liming' ; Liu, Zhiguang
> ; Wang, Jian J
> ; Gao, Zhichao
> 
> *Subject:* Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg
> Hey Ray,
> In my opinion that spec is too complicated. For some cases it is
> obvious, but I think the last anyone wants to see is a
> (STATIC_)ASSERT
> before most QuickSort calls to ensure the element size *really* is <=
> 256 Bytes. In my opinion, there are two roads:
> 1) Make the parameter required (I think this is what Liming
> suggested).
> The caller would always need to provide said buffer, and it can do
> as it
> sees fit - on the stack, in a pool, in a page, who knows.
> 2) Remove the parameter entirely. The library would depend on
> MemoryAllocationLib again, but also would have an optimisation by
> choosing stack vs pool based on ElementSize.
> Usually I would prefer 2), as it is less prone to caller errors, but
> considering the low-level nature of edk2, I can totally see the
> point to
> allow the caller to control whether there are dynamic me

Re: [edk2-devel] [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address based on Build Type

2021-09-27 Thread Zeng, Star

Curious: It does not work to have one function implementation like below?

UINTN
EFIAPI
GetFspmUpdDataAddress (
  VOID
  )
{
  if (PcdGet64 (PcdFspmUpdDataAddress) != 0) {
return (UINTN) PcdGet64 (PcdFspmUpdDataAddress64);
  } else {
return (UINTN) PcdGet32 (PcdFspmUpdDataAddress);
  }
}

Thanks,
Star

-Original Message-
From: Chiu, Chasel  
Sent: Monday, September 27, 2021 9:10 AM
To: S, Ashraf Ali ; devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Zeng, Star 
; Kuo, Ted ; Duggapu, Chinni B 
; Chaganty, Rangasai V 
; Solanki, Digant H 
; V, Sangeetha ; Ni, Ray 

Subject: RE: [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address based on 
Build Type


Reviewed-by: Chasel Chiu 

> -Original Message-
> From: S, Ashraf Ali 
> Sent: Friday, September 24, 2021 7:43 PM
> To: devel@edk2.groups.io
> Cc: S, Ashraf Ali ; Chiu, Chasel 
> ; Desimone, Nathaniel L 
> ; Zeng, Star ; 
> Kuo, Ted ; Duggapu, Chinni B 
> ; Chaganty, Rangasai V 
> ; Solanki, Digant H 
> ; V, Sangeetha ; 
> Ni, Ray 
> Subject: [PATCH v7] IntelFsp2WrapperPkg : FSPM/S UPD data address 
> based on Build Type
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3642
> when the module is not building in IA32 mode which will lead to building 
> error.
> when a module built-in X64 function pointer will be the size of 64bit 
> width which cannot be fit in 32bit address which will lead to error. 
> to overcome this issue introducing the 2 new PCD's for the 64bit modules can 
> consume it.
> Creating the API's to support different architecture
> 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Star Zeng 
> Cc: Kuo Ted 
> Cc: Duggapu Chinni B 
> Cc: Rangasai V Chaganty 
> Cc: Digant H Solanki 
> Cc: Sangeetha V 
> Cc: Ray Ni 
> Signed-off-by: Ashraf Ali S 
> ---
>  .../FspmWrapperPeim/FspmWrapperPeim.c | 19 +++---
>  .../FspmWrapperPeim/FspmWrapperPeim.inf   | 16 ++--
>  .../FspmWrapperPeim/IA32/FspmHelper.c | 26 +++
>  .../FspmWrapperPeim/X64/FspmHelper.c  | 26 +++
>  .../FspsWrapperPeim/FspsWrapperPeim.c | 17 +---
>  .../FspsWrapperPeim/FspsWrapperPeim.inf   | 14 +-
>  .../FspsWrapperPeim/IA32/FspsHelper.c | 26 +++
>  .../FspsWrapperPeim/X64/FspsHelper.c  | 26 +++
>  IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec   |  2 ++
>  9 files changed, 162 insertions(+), 10 deletions(-)  create mode 
> 100644 IntelFsp2WrapperPkg/FspmWrapperPeim/IA32/FspmHelper.c
>  create mode 100644
> IntelFsp2WrapperPkg/FspmWrapperPeim/X64/FspmHelper.c
>  create mode 100644
> IntelFsp2WrapperPkg/FspsWrapperPeim/IA32/FspsHelper.c
>  create mode 100644 
> IntelFsp2WrapperPkg/FspsWrapperPeim/X64/FspsHelper.c
> 
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> index 24ab534620..4a15136c39 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> @@ -3,7 +3,7 @@
>register TemporaryRamDonePpi to call TempRamExit API, and register 
> MemoryDiscoveredPpi
>notify to call FspSiliconInit API.
> 
> -  Copyright (c) 2014 - 2020, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2014 - 2021, Intel Corporation. All rights 
> + reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -39,6 +39,17 @@
> 
>  extern EFI_GUID gFspHobGuid;
> 
> +/**
> +  Get the Fspm Upd Data Address from the PCD
> +
> +  @return FSPM UPD Data Address
> +**/
> +UINTN
> +EFIAPI
> +GetFspmUpdDataAddress (
> +  VOID
> +  );
> +
>  /**
>Call FspMemoryInit API.
> 
> @@ -59,7 +70,7 @@ PeiFspMemoryInit (
> 
>DEBUG ((DEBUG_INFO, "PeiFspMemoryInit enter\n"));
> 
> -  FspHobListPtr = NULL;
> +  FspHobListPtr  = NULL;
>FspmUpdDataPtr = NULL;
> 
>FspmHeaderPtr = (FSP_INFO_HEADER *) FspFindFspHeader (PcdGet32 
> (PcdFspmBaseAddress)); @@ -68,7 +79,7 @@ PeiFspMemoryInit (
>  return EFI_DEVICE_ERROR;
>}
> 
> -  if (PcdGet32 (PcdFspmUpdDataAddress) == 0 && (FspmHeaderPtr-
> >CfgRegionSize != 0) && (FspmHeaderPtr->CfgRegionOffset != 0)) {
> +  if (GetFspmUpdDataAddress () == 0 && (FspmHeaderPtr->CfgRegionSize 
> + !=
> + 0) && (FspmHeaderPtr->CfgRegionOffset != 0)) {
>  //
>  // Copy default FSP-M UPD data from Flash
>  //
> @@ -80,7 +91,7 @@ PeiFspMemoryInit (
>  //
>  // External UPD is ready, get the buffer from PCD pointer.
>  //
> -FspmUpdDataPtr = (FSPM_UPD_COMMON *)PcdGet32
> (PcdFspmUpdDataAddress);
> +FspmUpdDataPtr = (FSPM_UPD_COMMON *) GetFspmUpdDataAddress ();
>  ASSERT (FspmUpdDataPtr != NULL);
>}
> 
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> index 00166e56a0..5b4ad531e7 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
>

Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector

2021-09-27 Thread Gerd Hoffmann

  Hi,

> Thanks for reminder. I have updated the patch-set as you mentioned.
> But I am waiting for a conclusion of the Metadata, a unified metadata
> or two separate metadata.

I still don't see the point in having two different tables for the same
purpose.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH V8 3/3] OvmfPkg: Enable TDX in ResetVector

2021-09-27 Thread Gerd Hoffmann

  Hi,

> +_Bfv:
> +  DD TDX_BFV_RAW_DATA_OFFSET
> +  DD TDX_BFV_RAW_DATA_SIZE
> +  DQ TDX_BFV_MEMORY_BASE
> +  DQ TDX_BFV_MEMORY_SIZE
> +  DD TDX_METADATA_SECTION_TYPE_BFV
> +  DD TDX_METADATA_ATTRIBUTES_EXTENDMR

Size is still added twice, doesn't make sense given that they are either
equal or RAW_DATA_SIZE is zero.  One size field being 32bit and the other
being 64bit is pointless too (see also my mail to Jiewen).

> +  DD TDX_METADATA_SECTION_TYPE_TEMP_MEM

There are a bunch of TEMP_MEM entries, some of them are next to each
other in MEMFD, so you can squash them into one entry.

Can you move the metadata changes to a separate patch please?

take care,
  Gerd



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

Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg

2021-09-27 Thread Marvin Häuser

On 27/09/2021 02:45, fanjianf...@byosoft.com.cn wrote:
Making baselib implementation depend on MemoryAllocationLib 
(indirectly on Pei Service and gBS), it may prevent 
this base API using at some seneraio. i don't think it's better.

That is why I asked about a split-API scenario, one of which does not 
depend on dynamic memory allocation (SetVariable-like) and one does 
(wrapper-like).

Add this parameter and make this parameter is optional,
1, when NULL, use the local 256 bytes stack
2, if 256 bytes stack is not enough, return RETURE_BUFFER_TOO_SAMLL,
3, caller check the return status, to do nothing or to allocate enough 
buffer for retry

This is just like SetVariable()'s implementation.

Yes, and because that is SetVariable's implementation, we have library 
functions to make it less error-prone and more convenient [1]. As a 
matter of fact, we have a (semi-lax) policy in our codebases to avoid 
such functions like the plague and use those library wrappers where-ever 
it can make sense. The only super-rare exceptions I can think of are 
when we know the size of the element ahead of time. Also SetVariable has 
no arbitrary constraint on when it may work the first time, and there is 
code that will fail when the first return is not EFI_BUFFER_TOO_SMALL.

This solution honestly yields even more problems, because it introduces 
a Status return which was not there before. For common code safety and 
quality policy, this requires the value *must* be retrieved and checked 
in some fashion. So all callers, no matter the prior knowledge of the 
element size, now need either a runtime check and handling for a status 
that they (may) know can never be returned, or ASSERTs if the function 
spec really imposes the arbitrary 256 Bytes constraint. Latter doesn't 
really work I think. What if someone wants to sort in SEC and noticed 
they only have 64 Bytes on the stack to work with, realistically? Any 
code depending on the 256 Byte constraint, passing NULL and not doing 
additional handling, would seize to work. Former is too complicated, see 
wrappers. In my opinion, the memory must *either* be fully managed by 
the caller *or* the callee (and you may have both in separate functions, 
as I suggested), but not sometimes here, sometimes there.

Best regards,
Marvin

[1] 
https://github.com/tianocore/edk2/blob/46b4606ba23498d3d0e66b53e498eb3d5d592586/MdePkg/Library/UefiLib/UefiLib.c#L1309-L1360

Jeff
fanjianf...@byosoft.com.cn

*From:* Marvin Häuser 
*Date:* 2021-09-26 19:20
*To:* devel ; ray.ni
; gaoliming
; Chan, Amy
; 'Andrew Fish' 
*CC:* Kinney, Michael D ; 'Gao,
Liming' ; Liu, Zhiguang
; Wang, Jian J
; Gao, Zhichao

*Subject:* Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg
Hey Ray,
In my opinion that spec is too complicated. For some cases it is
obvious, but I think the last anyone wants to see is a
(STATIC_)ASSERT
before most QuickSort calls to ensure the element size *really* is <=
256 Bytes. In my opinion, there are two roads:
1) Make the parameter required (I think this is what Liming
suggested).
The caller would always need to provide said buffer, and it can do
as it
sees fit - on the stack, in a pool, in a page, who knows.
2) Remove the parameter entirely. The library would depend on
MemoryAllocationLib again, but also would have an optimisation by
choosing stack vs pool based on ElementSize.
Usually I would prefer 2), as it is less prone to caller errors, but
considering the low-level nature of edk2, I can totally see the
point to
allow the caller to control whether there are dynamic memory
allocations
made or not as possible with 1). 2) could technically also be a
wrapper
for 1) if you want granular control and convenience/safety (why not
actually?).
Both approaches have the advantage that it is crystal-clear what the
caller's job is - to always or to never allocate the buffer.
Best regards,
Marvin
On 26/09/2021 04:24, Ni, Ray wrote:
>
> Liming,
>
> The purpose of the optional BufferOneElement is to ease consumer’s
> life assuming most of the time the element size should be
smaller than
> 256.
>
> Are you saying that it’s a bit hard to calculate the actual
value of
> sizeof (Element) when writing code?
>
> I recommend consumer always allocates memory if it’s hard to judge
> sizeof (Element) < 256.
>
> Searching edk2 code, I can find below code using PerformQuickSort():
>
>

Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector

2021-09-27 Thread Gerd Hoffmann

  Hi,

> > Possible alternative approach: Define an extension
> > (EFI_FIRMWARE_VOLUME_EXT_HEADER) for the load address and use that
> > instead of defining something new.
> 
> [Jiewen] I would say it is terrible idea to use EFI_FIRMWARE_VOLUME_HEADER.
> 
> [ ... details snipped ... ]

Ok, lets scratch the idea then.

> > Still not clear why the size is in there twice.  I think you could
> > instead use a flag telling whenever a section must be loaded from
> > the image or not.  This is what COFF and ELF are doing too.
> > 
> > Also not clear why you want stick to 64bit base address.  Loading the
> > firmware above 4G isn't going to work without also changing a bunch of
> > other things and it will break backward compatibility anyway.
> 
> [Jiewen] That is our previously experience, when we define a physical 
> address, we always use 64bit to leave room for extension.
> Like UEFI specification defines PHYSICAL_ADDRESS to be UINT64 even in IA32 
> platform.

Sure, physical address space on IA32 is 64G which simply doesn't fit into 
UINT32 ...

> Defining UINT64 gives us enough flexibility for the future, including test in 
> above 4G environment.
> I am wondering that, do you really care to save 4 bytes from UINT64 to UINT32 
> ?

Well, MEMFD isn't that big, so we have to care about the size there ...

> For type, maybe 2^16 is enough. But for flags, I prefer 32bit.

Making one 16bit and the other 32bit doesn't make much sense due
to struct padding and alignment.  So with 64-bit load address and
fields reordered so we don't have any padding the struct could look
like this:

struct {
uint64_t load_address;
uint32_t file_offset;
uint32_t section_size;
uint32_t section_type;
uint32_t section_flags;
};

> > But, again, I don't want have two completely different initialization
> > code paths in OVMF.  We can certainly investigate and discuss dropping
> > PEI, but that clearly shouldn't be a TDX-only thing.  When we eliminate
> > PEI, we should do it for all OVMF builds.
> 
> [Jiewen] I think this is out of scope of TDVF config-B patch series.
> I don't think it is fair to enable OVMF to remove PEI, just because
> TDVF does not need PEI. 

Hmm?  TDVF is based on OVMF.  My expectation would be that TDVF is
basically OVMF with TDX support added and most code being identical.
So with TDVF being able to boot without PEI most of the work should
already be done ...

> Each platform owner can have their own choice.

Why do you consider TDVF a separate platform?  I see it as OVMF variant.

Or did you just fork OVMF for config-b?  Doing so is certainly easier
for initial development and prototyping, but it's bad in the long run.
Having similar code twice in the code base means more long-term
maintenance work, which isn't fair either.

> If you have intertest to remove PEI, I am happy to discuss with you on
> detail.  However, I would treat "removing PEI from OVMF" and "enable
> TDVF config-B" be two different tasks.

Given TDVF wants boot without PEI the later depends on the former
though.  Or TDVF config-B continues to use the PEI-based boot workflow
for now like config-A does, and we look into removing PEI from OVMF
later.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81156): https://edk2.groups.io/g/devel/message/81156
Mute This Topic: https://groups.io/mt/85761661/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] SecurityPkg: Fix SecureBootDefaultKeysDxe failed to start

2021-09-27 Thread Nhi Pham via groups.io

The dbt and dbx keys are optional, the driver entry should return
EFI_SUCCESS to start if they are not found in the firmware flash. This
patch is to fix it and update the description of retval as well.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Grzegorz Bernacki 
Signed-off-by: Nhi Pham 
---
 
SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.c
 | 21 +---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.c
 
b/SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.c
index f51d5243b7e8..10bdb1b58e6f 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.c
+++ 
b/SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.c
@@ -3,6 +3,7 @@
 
 Copyright (c) 2021, ARM Ltd. All rights reserved.
 Copyright (c) 2021, Semihalf All rights reserved.
+Copyright (c) 2021, Ampere Computing LLC. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -23,10 +24,10 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
   @param[in]  ImageHandleThe image handle of the driver.
   @param[in]  SystemTableThe system table.
 
-  @retval EFI_ALREADY_STARTEDThe driver already exists in system.
-  @retval EFI_OUT_OF_RESOURCES   Fail to execute entry point due to lack of 
resources.
-  @retval EFI_SUCCESSAll the related protocols are installed on 
the driver.
-  @retval Others Fail to get the SecureBootEnable variable.
+  @retval EFI_SUCCESSThe secure default keys are initialized 
successfully.
+  @retval EFI_UNSUPPORTEDOne of the secure default keys already exists.
+  @retval EFI_NOT_FOUND  One of the PK, KEK, or DB default keys is not 
found.
+  @retval Others Fail to initialize the secure default keys.
 
 **/
 EFI_STATUS
@@ -56,14 +57,20 @@ SecureBootDefaultKeysEntryPoint (
   }
 
   Status = SecureBootInitDbtDefault ();
-  if (EFI_ERROR (Status)) {
+  if (Status == EFI_NOT_FOUND) {
 DEBUG ((DEBUG_INFO, "%a: dbtDefault not initialized\n", __FUNCTION__));
+  } else if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: Cannot initialize dbtDefault: %r\n", 
__FUNCTION__, Status));
+return Status;
   }
 
   Status = SecureBootInitDbxDefault ();
-  if (EFI_ERROR (Status)) {
+  if (Status == EFI_NOT_FOUND) {
 DEBUG ((DEBUG_INFO, "%a: dbxDefault not initialized\n", __FUNCTION__));
+  } else if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: Cannot initialize dbxDefault: %r\n", 
__FUNCTION__, Status));
+return Status;
   }
 
-  return Status;
+  return EFI_SUCCESS;
 }
-- 
2.17.1



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

Re: [edk2-devel] [PATCH v1 06/10] DynamicTablesPkg: Add Configuration Manager Object parser

2021-09-27 Thread PierreGondois

Hi Joey,
Thanks for the review, I answered inline:


On 9/24/21 9:56 AM, Joey Gouly wrote:
> Hi,
>
> This looks good to me!
>
> [...]
>
>> +
>> +/** A parser for EArmObjFixedFeatureFlags.
>> +*/
>> +STATIC CONST CM_OBJ_PARSER CmArmFixedFeatureFlagsParser[] = {
>> +  {"Flags", 4, "0x%x", NULL}
>> +};
>> +
>> +/** A parser for EArmObjItsGroup.
>> +*/
>> +STATIC CONST CM_OBJ_PARSER CmArmItsGroupNodeParser[] = {
>> +  {"GTBlockTimerFrameToken", sizeof (CM_OBJECT_TOKEN), "0x%p", NULL},
> This should just be Token, not GTBlockTimerFrameToken.


The name of the field is 'GTBlockTimerFrameToken', cf
https://github.com/tianocore/edk2/blob/master/DynamicTablesPkg/Include/ArmNameSpaceObjects.h#L394
I am not sure I understand why this should 'Token' instead.

>
>> +  {"ItsIdCount", 4, "0x%x", NULL},
>> +  {"ItsIdToken", sizeof (CM_OBJECT_TOKEN), "0x%p", NULL}
>> +};
>> +
> [...]
>
>> diff --git 
>> a/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.h
>>  
>> b/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.h
>> new file mode 100644
>> index ..e229df7095d9
>> --- /dev/null
>> +++ 
>> b/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.h
> [...]
>
>> +/**
>> +  The CM_OBJ_PARSER structure describes the fields of an CmObject and
>> +  provides means for the parser to interpret and trace appropriately.
>> +
>> +  ParseAcpi() uses the format string specified by 'Format' for tracing
>> +  the field data.
>> +*/
>> +typedef struct CmObjParser CM_OBJ_PARSER;
>> +struct CmObjParser {
>> +
>> +  /// String describing the Cm Object
>> +  CONST CHAR8*NameStr;
>> +
>> +  /// The length of the field.
>> +  UINT32  Length;
>> +
>> +  /// Optional Print() style format string for tracing the data. If not
>> +  /// used this must be set to NULL.
>> +  CONST CHAR8*Format;
>> +
>> +  /// Optional pointer to a print formatter function which
>> +  /// is typically used to trace complex field information.
>> +  /// If not used this must be set to NULL.
>> +  /// The Format string is passed to the PrintFormatter function
>> +  /// but may be ignored by the implementation code.
>> +  FNPTR_PRINT_FORMATTER   PrintFormatter;
>> +
>> +  /// Optional pointer to print the fields of another CM_OBJ_PARSER
>> +  /// structure. This is useful to print sub-structures.
>> +  CONST CM_OBJ_PARSER *SubObjParser;
>> +
>> +  /// Count of items in the SubObj.
>> +  UINTN   SubObjItemCount;
> The SubObjParser doesn't actually seem to be used by any of the objects? 
> (Unless I misread when reading the list of them..)


The SubObjParser field is effectively not currently used. It will be
used in a later patch,
cf the 'UsageCounterRegister' field of
https://edk2.groups.io/g/devel/message/76954


>
>> +
>> +  /// Count of items
>> +  UINTN ItemCount;
>> +} CM_OBJ_PARSER_ARRAY;
>> +
>> +#endif // CONFIGURATION_MANAGER_OBJECT_PARSER_H_
>> diff --git 
>> a/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf 
>> b/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
>> index 5435f74aa0b8..abbf4bc38cab 100644
>> --- a/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
>> +++ b/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
>> @@ -15,6 +15,8 @@ [Defines]
>>LIBRARY_CLASS  = TableHelperLib
>>
>>  [Sources]
>> +  ConfigurationManagerObjectParser.c
>> +  ConfigurationManagerObjectParser.h
>>TableHelper.c
>>
>>  [Packages]
> Need to update the copyright year.
>
> Otherwise:
>   Reviewed-by: Joey Gouly 
>
> Thanks,
> Joey


Regards,
Pierre




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

[edk2-devel] [PATCH V3] MdeModulePkg/BootManagerMenuApp: Limit string drawing within one line

2021-09-27 Thread Gao, Zhichao

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

Limit the draw box always within the screen's column and row.
Limit the string drawing within one line.
For the incompleted string the last 3 characters in one line would
be replaced with "...".

Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Ray Ni 
Signed-off-by: Zhichao Gao 
Reviewed-by: Ray Ni 
---
V2:
Drop the change in UefiBootManagerLib in V1.
Add the limitation in BootManagerMenuApp instead.

V3:
Update the commit message only.

 .../BootManagerMenuApp/BootManagerMenu.c  | 72 ++-
 1 file changed, 69 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c 
b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c
index 9e729074ec..d4bdeba073 100644
--- a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c
+++ b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c
@@ -1,7 +1,7 @@
 /** @file
   The application to show the Boot Manager Menu.
 
-Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2021, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -45,9 +45,56 @@ PrintStringAt (
   IN CHAR16*String
   )
 {
+  UINTN ScreenWidth;
+  UINTN ScreenRows;
+  CHAR16*TurncateString;
+  EFI_STATUSStatus;
+  UINTN ShowingLength;
 
   gST->ConOut->SetCursorPosition (gST->ConOut, Column, Row);
-  return Print (L"%s", String);
+
+  gST->ConOut->QueryMode (
+ gST->ConOut,
+ gST->ConOut->Mode->Mode,
+ &ScreenWidth,
+ &ScreenRows
+ );
+
+  if (Column > (ScreenWidth - 1) || Row > (ScreenRows - 1)) {
+return 0;
+  }
+
+  if ((StrLen (String) + Column) > (ScreenWidth - 1)) {
+//
+// |  - ScreenWidth -   |
+// ...Column.
+// TurncateString length should leave one character for draw box and
+// require one character for string end.
+//
+ShowingLength = ScreenWidth - Column - 1;
+TurncateString = AllocatePool ((ShowingLength + 1) * sizeof (CHAR16));
+
+if (TurncateString == NULL) {
+  return 0;
+}
+
+Status = StrnCpyS (TurncateString, ShowingLength + 1, String, 
ShowingLength - 3);
+
+if (EFI_ERROR (Status)) {
+  FreePool (TurncateString);
+  return 0;
+}
+
+*(TurncateString + ShowingLength - 3) = L'.';
+*(TurncateString + ShowingLength - 2) = L'.';
+*(TurncateString + ShowingLength - 1) = L'.';
+*(TurncateString + ShowingLength) = L'\0';
+ShowingLength = Print (L"%s", TurncateString);
+FreePool (TurncateString);
+return ShowingLength;
+  } else {
+return Print (L"%s", String);
+  }
 }
 
 /**
@@ -68,7 +115,22 @@ PrintCharAt (
   CHAR16   Character
   )
 {
+  UINTN ScreenWidth;
+  UINTN ScreenRows;
+
   gST->ConOut->SetCursorPosition (gST->ConOut, Column, Row);
+
+  gST->ConOut->QueryMode (
+ gST->ConOut,
+ gST->ConOut->Mode->Mode,
+ &ScreenWidth,
+ &ScreenRows
+ );
+
+  if (Column > (ScreenWidth - 1) || Row > (ScreenRows - 1)) {
+return 0;
+  }
+
   return Print (L"%c", Character);
 }
 
@@ -193,7 +255,11 @@ InitializeBootMenuScreen (
 
   MaxPrintRows = Row - 6;
   UnSelectableItmes = TITLE_TOKEN_COUNT + 2 + HELP_TOKEN_COUNT + 2;
-  BootMenuData->MenuScreen.Width = MaxStrWidth + 8;
+  if (MaxStrWidth + 8 > Column) {
+BootMenuData->MenuScreen.Width = Column;
+  } else {
+BootMenuData->MenuScreen.Width = MaxStrWidth + 8;
+  }
   if (BootMenuData->ItemCount + UnSelectableItmes > MaxPrintRows) {
 BootMenuData->MenuScreen.Height = MaxPrintRows;
 BootMenuData->ScrollBarControl.HasScrollBar = TRUE;
-- 
2.31.1.windows.1



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

52 matches

Mail list logo