date:20190924

Re: [edk2-devel] [PATCH] MdeModulePkg: Add missing sourceX for Blt

2019-09-24 Thread Wu, Hao A

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Gao, Zhichao
> Sent: Tuesday, September 17, 2019 3:00 PM
> To: Ni, Ray
> Cc: Gris87; devel@edk2.groups.io
> Subject: Re: [edk2-devel] [PATCH] MdeModulePkg: Add missing sourceX for
> Blt
> 
> It is a bug in the blt interface. I have tested it with OvmfPkgX64.
> Here is the simple test step:
> 1. Change BootLogoLib.c line 213:
> Status = GraphicsOutput->Blt (
>GraphicsOutput,
>Blt,
>EfiBltBufferToVideo,
>0,
>0,
>(UINTN) DestX,
>(UINTN) DestY,
>Image.Width,
>Image.Height,
>Image.Width * sizeof 
> (EFI_GRAPHICS_OUTPUT_BLT_PIXEL)
>);
> ==>
> Status = GraphicsOutput->Blt (
>GraphicsOutput,
>Blt,
>EfiBltBufferToVideo,
>20,
>20,
>(UINTN) DestX,
>(UINTN) DestY,
>Image.Width - 20,
>Image.Height - 20,
>Image.Width * sizeof 
> (EFI_GRAPHICS_OUTPUT_BLT_PIXEL)
>);
> 2. build OvmfpkgX64 image and boot thru Qemu.
> 3. view the logo.
> The logo shows incorrect. It should show at the (20, 20), but the result is 
> (0,
> 20).
> Apply this patch, then the result is expected, i.e. it showed at (20, 20) of 
> the
> logo.bmp.
> 
> Tested-by: Zhichao Gao 
> Reviewed-by: Zhichao Gao 


The patch has been pushed via commit 96301aadc1.

Best Regards,
Hao Wu


> 
> > -Original Message-
> > From: Ni, Ray
> > Sent: Tuesday, September 17, 2019 4:57 AM
> > To: Gao, Zhichao 
> > Cc: Gris87 ; devel@edk2.groups.io
> > Subject: RE: [PATCH] MdeModulePkg: Add missing sourceX for Blt
> >
> > + Zhichao for review.
> >
> > > -Original Message-
> > > From: Gris87 
> > > Sent: Monday, September 16, 2019 7:22 AM
> > > To: devel@edk2.groups.io
> > > Cc: Gris87 ; Ni, Ray 
> > > Subject: [PATCH] MdeModulePkg: Add missing sourceX for Blt
> > >
> > > There is no sourceX offset in case when
> > > Configure->PixelFormat == PixelBlueGreenRedReserved8BitPerColor.
> > > We are copying most left pixels instead of copying required rectangle.
> > >
> > > Signed-off-by: Gris87 
> > > Cc: Ruiyu Ni 
> > > ---
> > >  MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git
> a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > > b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > > index 47c5326e99..ff7979c962 100644
> > > --- a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > > +++ b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > > @@ -504,7 +504,7 @@ FrameBufferBltLibBufferToVideo (
> > >  Destination = Configure->FrameBuffer + Offset;
> > >
> > >  if (Configure->PixelFormat ==
> PixelBlueGreenRedReserved8BitPerColor)
> > {
> > > -  Source = (UINT8 *) BltBuffer + (SrcY * Delta);
> > > +  Source = (UINT8 *) BltBuffer + (SrcY * Delta) + SourceX * sizeof
> > (EFI_GRAPHICS_OUTPUT_BLT_PIXEL);
> > >  } else {
> > >for (IndexX = 0; IndexX < Width; IndexX++) {
> > >  Blt =
> > > --
> > > 2.19.1
> 
> 
> 


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

View/Reply Online (#48010): https://edk2.groups.io/g/devel/message/48010
Mute This Topic: https://groups.io/mt/34168097/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 Base.h: Define STATIC_ASSERT macro as empty for EBC arch

2019-09-24 Thread Michael D Kinney

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Gao, Liming 
> Sent: Tuesday, September 24, 2019 5:38 PM
> To: Leif Lindholm ;
> devel@edk2.groups.io
> Cc: Kinney, Michael D 
> Subject: RE: [edk2-devel] [Patch] MdePkg Base.h: Define
> STATIC_ASSERT macro as empty for EBC arch
> 
> Lefi:
>   Thanks for your comment. I will update the patch when
> submit it.
> 
> Thanks
> Liming
> >-Original Message-
> >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> >Sent: Wednesday, September 25, 2019 8:18 AM
> >To: devel@edk2.groups.io; Gao, Liming
> 
> >Cc: Kinney, Michael D 
> >Subject: Re: [edk2-devel] [Patch] MdePkg Base.h: Define
> STATIC_ASSERT
> >macro as empty for EBC arch
> >
> >On Tue, Sep 24, 2019 at 11:05:19PM +0800, Liming Gao
> wrote:
> >> EBC compiler doesn't support C11 static_assert macro.
> >> So, define STATIC_ASSERT as empty to pass EBC arch
> build.
> >> STATIC_ASSERT macro is introduced
> >@204ae9da230ecbf0910c21acac7aa5d5e8cbb8d0
> >>
> >> Cc: Michael D Kinney 
> >> Signed-off-by: Liming Gao 
> >> ---
> >>  MdePkg/Include/Base.h | 5 -
> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/MdePkg/Include/Base.h
> b/MdePkg/Include/Base.h index
> >> ed85b98318..70e4d8daf1 100644
> >> --- a/MdePkg/Include/Base.h
> >> +++ b/MdePkg/Include/Base.h
> >> @@ -799,12 +799,15 @@ typedef UINTN  *BASE_LIST;
> >>@param  Message Raised compiler diagnostic
> message when expression
> >is false.
> >>
> >>  **/
> >> -#ifdef _MSC_EXTENSIONS
> >> +#ifdef MDE_CPU_EBC
> >> +  #define STATIC_ASSERT(Expression, Message) #elif
> _MSC_EXTENSIONS
> >>#define STATIC_ASSERT static_assert  #else
> >>#define STATIC_ASSERT _Static_assert  #endif
> >>
> >> +
> >
> >Please delete this spurious added blank line.
> >With that:
> >Reviewed-by: Leif Lindholm 
> >
> >>  //
> >>  // Verify that ProcessorBind.h produced UEFI Data
> Types that are
> >> compliant
> >with
> >>  // Section 2.3.1 of the UEFI 2.3 Specification.
> >> --
> >> 2.13.0.windows.1
> >>
> >>
> >> 
> >>

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

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

Re: [edk2-devel] [PATCH 1/1] MdeModulePkg/SdMmcPciHcDxe: Fix bus timing switch sequence

2019-09-24 Thread Wu, Hao A

> -Original Message-
> From: Albecki, Mateusz
> Sent: Monday, September 23, 2019 4:37 PM
> To: devel@edk2.groups.io
> Cc: Albecki, Mateusz; Wu, Hao A; Marcin Wojtas
> Subject: [PATCH 1/1] MdeModulePkg/SdMmcPciHcDxe: Fix bus timing
> switch sequence
> 
> SD specification recommends switching card bus timing before
> switching bus timing in controller. Emmc driver used to do
> this switch other way around. This commit adds controller
> timing switch in EmmcSwitchBusTiming function to enforce this
> order and removes all controller timing programing from
> EmmcSwitchToXXX functions.


Hello Mateusz,

I think the changes in the patch look good.

Could you help to address the below things:

1. The 'Private' local variable is no longer being used by below functions:
EmmcSwitchToHighSpeed()
EmmcSwitchToHS200()
EmmcSwitchToHS400()

The GCC compiler seems not happy with it, could you help to resolve it?

2. I have submitted a Bugzilla tracker for this issue at:
https://bugzilla.tianocore.org/show_bug.cgi?id=2218

Could you help to add this information in the commit log message?

3. For the removal of bus clock stopping codes in EmmcSwitchToHS200(), could
you split them into another separate patch? I think they are not directly
related with the bus speed mode changing sequence.

4. I have performed the below tests on the eMMC device on my side, for
different eMMC bus modes:
HS400 (good)
HS200 (good)
High Speed DDR (good)
High Speed SDR (good)
Legacy MMC (NOT good)

For the Legacy MMC mode case, the error comes from the EmmcSwitchToHighSpeed()
function returning EFI_INVALID_PARAMETER for bus mode 'SdMmcMmcLegacy'. I think
for the EmmcSetBusMode() function, the below updates can be made:

  if (BusMode.BusTiming == SdMmcMmcHs400) {
Status = EmmcSwitchToHS400 (PciIo, PassThru, Slot, Rca, );
  } else if (BusMode.BusTiming == SdMmcMmcHs200) {
Status = EmmcSwitchToHS200 (PciIo, PassThru, Slot, Rca, );
  } else {  <== should be updated to:
  } else if (BusMode.BusTiming == SdMmcMmcHsSdr || BusMode.BusTiming == 
SdMmcMmcHsDdr) {
Status = EmmcSwitchToHighSpeed (PciIo, PassThru, Slot, Rca, );
  }

think for the Legacy MMC mode, no additional bus mode switch is needed. If
you agree with this, could you help to add another patch to change the above
logic (also the debug message after the above-shown code)?

Best  Regards,
Hao Wu


> 
> Signed-off-by: Mateusz Albecki 
> Cc: Hao A Wu 
> Cc: Marcin Wojtas 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c | 79 +++---
> ---
>  1 file changed, 20 insertions(+), 59 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> index 3f4a8e5413..06ee1208be 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> @@ -671,6 +671,7 @@ EmmcSwitchBusTiming (
>UINT8 CmdSet;
>UINT32DevStatus;
>SD_MMC_HC_PRIVATE_DATA*Private;
> +  UINT8 HostCtrl1;
> 
>Private = SD_MMC_HC_PRIVATE_FROM_THIS (PassThru);
>//
> @@ -704,6 +705,25 @@ EmmcSwitchBusTiming (
>  return Status;
>}
> 
> +  if (BusTiming == SdMmcMmcHsSdr || BusTiming == SdMmcMmcHsDdr) {
> +HostCtrl1 = BIT2;
> +Status = SdMmcHcOrMmio (PciIo, Slot, SD_MMC_HC_HOST_CTRL1, sizeof
> (HostCtrl1), );
> +if (EFI_ERROR (Status)) {
> +  return Status;
> +}
> +  } else {
> +HostCtrl1 = (UINT8)~BIT2;
> +Status = SdMmcHcAndMmio (PciIo, Slot, SD_MMC_HC_HOST_CTRL1,
> sizeof (HostCtrl1), );
> +if (EFI_ERROR (Status)) {
> +  return Status;
> +}
> +  }
> +
> +  Status = SdMmcHcUhsSignaling (Private->ControllerHandle, PciIo, Slot,
> BusTiming);
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +
>//
>// Convert the clock freq unit from MHz to KHz.
>//
> @@ -772,7 +792,6 @@ EmmcSwitchToHighSpeed (
>)
>  {
>EFI_STATUS  Status;
> -  UINT8   HostCtrl1;
>SD_MMC_HC_PRIVATE_DATA  *Private;
>BOOLEAN IsDdr;
> 
> @@ -794,20 +813,6 @@ EmmcSwitchToHighSpeed (
>  return Status;
>}
> 
> -  //
> -  // Set to High Speed timing
> -  //
> -  HostCtrl1 = BIT2;
> -  Status = SdMmcHcOrMmio (PciIo, Slot, SD_MMC_HC_HOST_CTRL1, sizeof
> (HostCtrl1), );
> -  if (EFI_ERROR (Status)) {
> -return Status;
> -  }
> -
> -  Status = SdMmcHcUhsSignaling (Private->ControllerHandle, PciIo, Slot,
> BusMode->BusTiming);
> -  if (EFI_ERROR (Status)) {
> -return Status;
> -  }
> -
>return EmmcSwitchBusTiming (PciIo, PassThru, Slot, Rca, BusMode-
> >DriverStrength, BusMode->BusTiming, BusMode->ClockFreq);
>  }
> 
> @@ -837,7 +842,6 @@ EmmcSwitchToHS200 (
>)
>  {
>EFI_STATUS   Status;
> -  UINT16   ClockCtrl;
>SD_MMC_HC_PRIVATE_DATA  *Private;
> 
>Private = SD_MMC_HC_PRIVATE_FROM_THIS (PassThru);
> @@ -851,39 +855,6 @@ EmmcSwitchToHS200 (
>if

Re: [edk2-devel] Cancelled Event: TianoCore Design / Bug Triage - EMEA - Wednesday, 25 September 2019 #cal-cancelled

2019-09-24 Thread Stephano Cetola

No topics, so we'll cancel this week.

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

View/Reply Online (#48007): https://edk2.groups.io/g/devel/message/48007
Mute This Topic: https://groups.io/mt/34283833/21656
Mute #cal-cancelled: https://groups.io/mk?hashtag=cal-cancelled=3846945
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Cancelled Event: TianoCore Design / Bug Triage - EMEA - Wednesday, 25 September 2019 #cal-cancelled

2019-09-24 Thread devel@edk2.groups.io Calendar

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:CANCEL
CALSCALE:GREGORIAN
BEGIN:VEVENT
STATUS:CANCELLED
UID:calendar.15...@groups.io
DTSTAMP:20190925T022431Z
ORGANIZER;CN=Stephano Cetola:mailto:stephano.cet...@linux.intel.com
DTSTART;TZID=America/Los_Angeles:20190925T08
DTEND;TZID=America/Los_Angeles:20190925T09
SUMMARY:TianoCore Design / Bug Triage - EMEA
DESCRIPTION:Join Zoom Meeting\n\nhttps://zoom.us/j/695893389\n\nOne tap mobile\n\n+17207072699,,695893389# US\n\n+16465588656,,695893389# US (New York)\n\nDial by your location\n\n+1 720 707 2699 US\n\n+1 646 558 8656 US (New York)\n\nMeeting ID: 695 893 389\n\nFind your local number: https://zoom.us/u/abOtdJckxL
LOCATION:https://zoom.us/j/695893389
RECURRENCE-ID;TZID=America/Los_Angeles:20190925T08
SEQUENCE:0
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [edk2-devel] [patch v3 0/5] Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Dandan Bi

Hi Hao,

Could you help to push this V3 patch series?


Thanks,
Dandan
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Dandan Bi
> Sent: Tuesday, September 24, 2019 9:17 PM
> To: devel@edk2.groups.io
> Cc: Leif Lindholm ; Ard Biesheuvel
> ; Wang, Jian J ; Wu,
> Hao A ; Ni, Ray ; Gao, Liming
> ; Gao, Zhichao ; Laszlo
> Ersek ; Philippe Mathieu-Daude 
> Subject: [edk2-devel] [patch v3 0/5] Unload image on
> EFI_SECURITY_VIOLATION
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> 
> v2:
> Just enahnce the code error handling logic in patch 3.
> Other patches are the same and pick up the Acked-by and Reviewed-by in
> other patches.
> 
> v2:
> (1) Just separate the patch in MdeModulePkg into module level, the changes
> in EmbeddedPkg and ShellPkg are the same with V1.
> (2) Drop the update in PciBusDxe module in MdeModulePkg since with
> EFI_SECURITY_VIOLATION returned, the image may be used later.
> 
> 
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval, the
> Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
> 
> But if the caller of LoadImage() doesn't have the option to defer the
> execution of an image, we can not treat EFI_SECURITY_VIOLATION like any
> other LoadImage() error, we should unload image for the
> EFI_SECURITY_VIOLATION to avoid resource leak.
> 
> This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly for
> the callers in edk2 which don't have the policy to defer the execution of the
> image.
> 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Cc: Liming Gao 
> Cc: Zhichao Gao 
> Cc: Laszlo Ersek 
> Cc: Philippe Mathieu-Daude  Dandan Bi (3):
>   EmbeddedPkg: Unload image on EFI_SECURITY_VIOLATION
>   MdeModulePkg/DxeCapsuleLibFmp: Unload image on
> EFI_SECURITY_VIOLATION
>   MdeModulePkg/UefiBootManager: Unload image on
> EFI_SECURITY_VIOLATION
>   MdeModulePkg/PlatformDriOverride: Unload image on
> EFI_SECURITY_VIOLATION
>   ShellPkg: Unload image on EFI_SECURITY_VIOLATION
> 
>  .../AndroidFastboot/Arm/BootAndroidBootImg.c |  9 +
>  .../Library/AndroidBootImgLib/AndroidBootImgLib.c| 12 
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c |  9 +
>  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c |  9 +
>  .../Library/UefiBootManagerLib/BmLoadOption.c| 14 --
>  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 14
> --
>  .../PlatformDriOverrideDxe/PlatDriOverrideLib.c  | 11 ++-
>  ShellPkg/Application/Shell/ShellManParser.c  |  9 +
>  .../Library/UefiShellDebug1CommandsLib/LoadPciRom.c  | 11 ++-
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c   | 11 ++-
>  10 files changed, 98 insertions(+), 5 deletions(-)
> 
> --
> 2.18.0.windows.1
> 
> 
> 


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

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

Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin maintainers to EDK II Releases section

2019-09-24 Thread Liming Gao

Laszlo:

>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Wednesday, September 25, 2019 1:27 AM
>To: Gao, Liming ; devel@edk2.groups.io
>Cc: Andrew Fish ; Leif Lindholm ;
>Kinney, Michael D 
>Subject: Re: [Patch] Maintainers.txt: Move ShellBin maintainers to EDK II
>Releases section
>
>Hi Liming,
>
>On 09/24/19 03:19, Liming Gao wrote:
>> ShellBinPkg is generated for each edk2 stable tag release.
>>
>> Cc: Andrew Fish 
>> Cc: Laszlo Ersek 
>> Cc: Leif Lindholm 
>> Cc: Michael D Kinney 
>> Signed-off-by: Liming Gao 
>> ---
>>  Maintainers.txt | 13 ++---
>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/Maintainers.txt b/Maintainers.txt
>> index f348d70df3..f75b35d5a8 100644
>> --- a/Maintainers.txt
>> +++ b/Maintainers.txt
>> @@ -82,6 +82,12 @@ EDK II Releases:
>>  W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-
>Planning
>>  M: Liming Gao 
>>
>> +W: https://github.com/tianocore/edk2/releases/download/edk2-
>stable20/ShellBinPkg.zip
>
>I'm not a fan of this link. It contains "", therefore it cannot work
>with a simple click (or copy & paste). And it's not easy to notice the
>"" part, and to substitute a valid stable tag identifier for it.
>
>All the links we provide should work without manual tweaking, in my
>opinion. They might not provide an immediately downloadable file (which
>is fine with me), but they should not result in a 404.
>
>How about the following:
>
>UEFI Shell Binaries (ShellBinPkg.zip) from EDK II Releases:
>---
>W: https://github.com/tianocore/edk2/releases/
>M: ...
>M: ...
>M: ...
>M: ...
>

Good suggestion. I will use this style. 

Thanks
Liming

>This allows users to go to the releases page, and search that page for
>"ShellBinPkg.zip".
>
>For me, the "Assets" block of the latest release is open immediately,
>upon loading the page, and so searching the page for "ShellBinPkg.zip"
>provides a hit at once. If a user wants an older build, they can locate
>the Assets blocks under older releases, and look for "ShellBinPkg.zip"
>there.
>
>Thanks
>Laszlo
>
>> +M: Ray Ni   (Ia32/X64)
>> +M: Zhichao Gao (Ia32/X64)
>> +M: Leif Lindholm(ARM/AArch64)
>> +M: Ard Biesheuvel  (ARM/AArch64)
>> +
>>  EDK II Architectures:
>>  -
>>  ARM, AARCH64
>> @@ -421,13 +427,6 @@ W:
>https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
>>  M: Ray Ni 
>>  M: Zhichao Gao 
>>
>> -Maintainers for stable Shell binaries generation
>> -when need to publish Shell binaries with edk2 release:
>> -M: Ray Ni   (Ia32/X64)
>> -M: Zhichao Gao (Ia32/X64)
>> -M: Leif Lindholm(ARM/AArch64)
>> -M: Ard Biesheuvel  (ARM/AArch64)
>> -
>>  SignedCapsulePkg
>>  F: SignedCapsulePkg/
>>  W:
>https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
>>


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

View/Reply Online (#48001): https://edk2.groups.io/g/devel/message/48001
Mute This Topic: https://groups.io/mt/34271643/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 Base.h: Define STATIC_ASSERT macro as empty for EBC arch

2019-09-24 Thread Leif Lindholm

On Tue, Sep 24, 2019 at 11:05:19PM +0800, Liming Gao wrote:
> EBC compiler doesn't support C11 static_assert macro.
> So, define STATIC_ASSERT as empty to pass EBC arch build.
> STATIC_ASSERT macro is introduced @204ae9da230ecbf0910c21acac7aa5d5e8cbb8d0
> 
> Cc: Michael D Kinney 
> Signed-off-by: Liming Gao 
> ---
>  MdePkg/Include/Base.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
> index ed85b98318..70e4d8daf1 100644
> --- a/MdePkg/Include/Base.h
> +++ b/MdePkg/Include/Base.h
> @@ -799,12 +799,15 @@ typedef UINTN  *BASE_LIST;
>@param  Message Raised compiler diagnostic message when expression is 
> false.
>  
>  **/
> -#ifdef _MSC_EXTENSIONS
> +#ifdef MDE_CPU_EBC
> +  #define STATIC_ASSERT(Expression, Message)
> +#elif _MSC_EXTENSIONS
>#define STATIC_ASSERT static_assert
>  #else
>#define STATIC_ASSERT _Static_assert
>  #endif
>  
> +

Please delete this spurious added blank line.
With that:
Reviewed-by: Leif Lindholm 

>  //
>  // Verify that ProcessorBind.h produced UEFI Data Types that are compliant 
> with
>  // Section 2.3.1 of the UEFI 2.3 Specification.
> -- 
> 2.13.0.windows.1
> 
> 
> 
> 

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

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

Re: [edk2-devel] [edk2-platforms][PATCH V2 00/15] Move ClevoOpenBoardPkg/N1xxWU Contents to KabylakeOpenBoardPkg

2019-09-24 Thread Sinha, Ankit

Reviewed-by: Ankit Sinha 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Kubacki, Michael 
A
Sent: Tuesday, September 24, 2019 11:13 AM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Desimone, Nathaniel L 
; Sinha, Ankit ; Jeremy 
Soller 
Subject: [edk2-devel] [edk2-platforms][PATCH V2 00/15] Move 
ClevoOpenBoardPkg/N1xxWU Contents to KabylakeOpenBoardPkg

This patch series moves the N1xxWU board contents currently in ClevoOpenBoardPkg
to KabylakeOpenBoardPkg. The actual systems being tested are System 76 Galago 
Pro
laptops so the board itself is renamed from "N1xxWU" to"GalagoPro3". The system
models supported are the galp2 (Kaby Lake) and galp3 (Kaby Lake-R). This is
clarified under the board support information in the Readme.md update.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 

Michael Kubacki (15):
  Platform/Intel: Remove N1xxWU board build option
  ClevoOpenBoardPkg: Remove package contents
  ClevoOpenBoardPkg: Remove global files and references
  KabylakeOpenBoardPkg: Move policy update libs to KabylakeRvp3 board
  KabylakeOpenBoardPkg: Move EcCommands.h to KabylakeRvp3 board
  KabylakeOpenBoardPkg: Move flash map to board
  KabylakeOpenBoardPkg: Add PeiSerialPortLibSpiFlash
  KabylakeOpenBoardPkg/GalagoPro3: Add headers
  KabylakeOpenBoardPkg/GalagoPro3: Add library instances
  KabylakeOpenBoardPkg/GalagoPro3: Add modules
  KabylakeOpenBoardPkg: Consolidate board IDs in a single file
  KabylakeOpenBoardPkg: Add board ID to Global NVS
  KabylakeOpenBoardPkg/BoardAcpiDxe: Add Synaptics PS/2 mouse
  KabylakeOpenBoardPkg/GalagoPro3: Add build files
  Add GalagoPro3 board details to global build and documentation

 Platform/Intel/ClevoOpenBoardPkg/OpenBoardPkg.dec  

|  305 
 Platform/Intel/KabylakeOpenBoardPkg/OpenBoardPkg.dec   

|   10 +-
 Platform/Intel/{ClevoOpenBoardPkg/N1xxWU => 
KabylakeOpenBoardPkg/GalagoPro3}/OpenBoardPkg.dsc   
   |8 +-
 Platform/Intel/{ClevoOpenBoardPkg/N1xxWU => 
KabylakeOpenBoardPkg/GalagoPro3}/OpenBoardPkgBuildOption.dsc
   |2 +-
 Platform/Intel/{ClevoOpenBoardPkg/N1xxWU => 
KabylakeOpenBoardPkg/GalagoPro3}/OpenBoardPkgConfig.dsc 
   |2 +-
 Platform/Intel/{ClevoOpenBoardPkg/N1xxWU => 
KabylakeOpenBoardPkg/GalagoPro3}/OpenBoardPkgPcd.dsc
   |2 +-
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc  

|6 +-
 Platform/Intel/{ClevoOpenBoardPkg/N1xxWU => 
KabylakeOpenBoardPkg/GalagoPro3}/Include/Fdf/FlashMapInclude.fdf
   |2 +-
 Platform/Intel/{ClevoOpenBoardPkg/N1xxWU => 
KabylakeOpenBoardPkg/GalagoPro3}/OpenBoardPkg.fdf   
   |6 +-
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/Include/Fdf/FlashMapInclude.fdf   
  |0
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf  

|2 +-
 Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe.inf

|   69 -
 Platform/Intel/ClevoOpenBoardPkg/Features/PciHotPlug/PciHotPlug.inf

|   59 -
 
Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/Library/DxeTbtPolicyLib/DxeTbtPolicyLib.inf

  |   67 -
 
Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/Library/PeiDxeSmmTbtCommonLib/TbtCommonLib.inf

   |   62 -
 
Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/Library/PeiTbtPolicyLib/PeiTbtPolicyLib.inf

  |   56 -
 
Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/Library/Private/PeiDTbtInitLib/PeiDTbtInitLib.inf

|   41 -
 Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/TbtInit/Dxe/TbtDxe.inf

Re: [edk2-devel] [edk2/master PATCHv1 1/1] OvmfPkg: Make SOURCE_DEBUG_ENABLE actually need to be set to TRUE

2019-09-24 Thread Laszlo Ersek

Hi Peter,

thanks for the patch. Two comments:

On 09/20/19 20:45, Peter Jones wrote:
> Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some
> tests check if it's defined or not.  Additionally, in UefiPayloadPkg as
> well as some other trees, we define it as FALSE in the .dsc file.
> 
> This patch changes all of the Ovmf platforms to explicitly define it as
> FALSE by default, and changes all of the checks to test if the value is
> TRUE.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1

(1) Please drop this line. (I cannot touch up this part for you.)

The Contributed-under line has not been necessary since
 was fixed.

> Signed-off-by: Peter Jones 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 17 +
>  OvmfPkg/OvmfPkgIa32.fdf|  2 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc | 19 ++-
>  OvmfPkg/OvmfPkgIa32X64.fdf |  2 +-
>  OvmfPkg/OvmfPkgX64.dsc | 19 ++-
>  OvmfPkg/OvmfPkgX64.fdf |  2 +-
>  OvmfPkg/OvmfXen.dsc| 17 +
>  OvmfPkg/OvmfXen.fdf|  2 +-
>  8 files changed, 42 insertions(+), 38 deletions(-)

[...]

> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index 785affeb90c8..c7622fcfb7b0 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -260,7 +260,7 @@ [FV.DXEFV]
>  INF  
> MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
>  
>  INF  OvmfPkg/SioBusDxe/SioBusDxe.inf
> -!ifndef $(SOURCE_DEBUG_ENABLE)
> +!if $(SOURCE_DEBUG_ENABLE) != TRUE

(2) Can you please write "== FALSE" here (in the other FDF files too)?
That has a tiny bit more precedent.

I'd be willing to fix up (2) for you just before pushing, but I can't
touch (1).

With (1) and (2) fixed, for v2:

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

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

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

Re: [edk2-devel] [PATCH] MdeModulePkg: Enable/Disable S3BootScript dynamically.

2019-09-24 Thread Laszlo Ersek

On 09/24/19 07:54, Chiu, Chasel wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2212
> 
> Current S3BootScriptLib can only support build time opt-out

I think this problem statement is wrong.

In the OVMF platform anyway, PiDxeS3BootScriptLib is linked into the following 
two modules:

  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
  MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf

Both modules honor "PcdAcpiS3Enable" already.

If the PCD is set to FALSE (which can be done dynamically, by platform PEI 
code, for example), then these modules exit their entry point functions with 
EFI_UNSUPPORTED.

As a consequence, the library DESTRUCTOR function will undo whatever the 
CONSTRUCTOR function did. Thus no resources should be leaked.

If you have a DXE driver that depends on the PiDxeS3BootScriptLib instance, 
such that it *cannot* exit from its entry point function with EFI_UNSUPPORTED, 
when PcdAcpiS3Enable is set to FALSE, then this patch could be justified. But 
then the use case should be described much more clearly. The current statement 
("can only support build time opt-out") is wrong; the destructor function 
supports unloading, and drivers can ask for being unloaded dependent on a 
dynamic PCD.

Thanks
Laszlo

> but in binary model the same binary should support both
> enabling and disabling scenarios.
> 
> To support this below PCD is expected to be used as
> DynamicPCD (or DynamicEx) to skip S3BootScript functions
> when PCD set to FALSE:
> gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable
> 
> Test: Verified on internal platform and S3BootScript
>   functions can be skipped by PCD during boot time.
> 
> Cc: Hao A Wu 
> Cc: Eric Dong 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Signed-off-by: Chasel Chiu 
> ---
>  MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c   | 13 
> -
>  MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf |  4 +++-
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c 
> b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
> index c116727531..c5353119f7 100644
> --- a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
> +++ b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
> @@ -1,7 +1,7 @@
>  /** @file
>Save the S3 data to S3 boot script.
>  
> -  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
> @@ -124,6 +124,7 @@ VOID 
> *mRegistrationSmmReadyToLock = NULL;
>  BOOLEAN  mS3BootScriptTableAllocated = FALSE;
>  BOOLEAN  mS3BootScriptTableSmmAllocated = FALSE;
>  EFI_SMM_SYSTEM_TABLE2*mBootScriptSmst = NULL;
> +BOOLEAN  mAcpiS3Enable = TRUE;
>  
>  /**
>This is an internal function to add a terminate node the entry, 
> recalculate the table
> @@ -436,6 +437,11 @@ S3BootScriptLibInitialize (
>BOOLEANInSmm;
>EFI_PHYSICAL_ADDRESS   Buffer;
>  
> +  if (!PcdGetBool (PcdAcpiS3Enable)) {
> +mAcpiS3Enable = FALSE;
> +return RETURN_SUCCESS;
> +  }
> +
>S3TablePtr = 
> (SCRIPT_TABLE_PRIVATE_DATA*)(UINTN)PcdGet64(PcdS3BootScriptTablePrivateDataPtr);
>//
>// The Boot script private data is not be initialized. create it
> @@ -810,6 +816,11 @@ S3BootScriptGetEntryAddAddress (
>  {
>UINT8* NewEntryPtr;
>  
> +  if (!mAcpiS3Enable) {
> +DEBUG ((DEBUG_INFO, "Skip S3BootScript because ACPI S3 disabled.\n"));
> +return NULL;
> +  }
> +
>if (mS3BootScriptTablePtr->SmmLocked) {
>  //
>  // We need check InSmm, because after SmmReadyToLock, only SMM driver is 
> allowed to write boot script.
> diff --git a/MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf 
> b/MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
> index 517ea69568..fa139b03ff 100644
> --- a/MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
> +++ b/MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  # DXE S3 boot script Library.
>  #
> -# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  #
>  # SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -65,4 +65,6 @@
>## SOMETIMES_PRODUCES
>gEfiMdeModulePkgTokenSpaceGuid.PcdS3BootScriptTablePrivateSmmDataPtr
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdS3BootScriptRuntimeTableReservePageNumber   
> ## CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable 
>## CONSUMES
> +
>  
> 


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

View/Reply Online (#47996):

Re: [edk2-devel] [edk2-platforms][PATCH V1 1/1] edk2-platforms: Add pycache to .gitignore

2019-09-24 Thread Leif Lindholm

On Tue, Sep 24, 2019 at 01:55:47PM -0700, Michael Kubacki wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2217
> 
> Python build is enabled for some platform code leading to .pyc files
> created in __pycache__ directories. This change adds the __pycache__
> directory to a .gitignore file to allow git to ignore Python cache files.
> 
> Cc: Ard Biesheuvel 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Leif Lindholm 
> Signed-off-by: Michael Kubacki 

LGTM
Reviewed-by: Leif Lindholm 


> ---
>  .gitignore | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.gitignore b/.gitignore
> new file mode 100644
> index 00..58200d4d73
> --- /dev/null
> +++ b/.gitignore
> @@ -0,0 +1 @@
> +__pycache__/
> -- 
> 2.16.2.windows.1
> 

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

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

[edk2-devel] [edk2-platforms][PATCH V1 1/1] edk2-platforms: Add pycache to .gitignore

2019-09-24 Thread Kubacki, Michael A

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

Python build is enabled for some platform code leading to .pyc files
created in __pycache__ directories. This change adds the __pycache__
directory to a .gitignore file to allow git to ignore Python cache files.

Cc: Ard Biesheuvel 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Leif Lindholm 
Signed-off-by: Michael Kubacki 
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 00..58200d4d73
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+__pycache__/
-- 
2.16.2.windows.1


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

View/Reply Online (#47994): https://edk2.groups.io/g/devel/message/47994
Mute This Topic: https://groups.io/mt/34280876/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] uefi-sct/SctPkg: network: missing EFIAPI

2019-09-24 Thread Heinrich Schuchardt

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

Avoid errors of type:

~/edk2/SctPkg/TestCase/RIVL/Protocol/Http/Http/HttpENTSTest.c:74:1:
error: conflicting types for ‘HttpENTSTestMain’
   74 | HttpENTSTestMain (
  | ^~~~
In file included from :
~/edk2/Build/UefiSct/RELEASE_GCC5/X64/SctPkg/TestCase/RIVL/Protocol/
Http/Http/HttpENTSTest/DEBUG/AutoGen.h:77:1:
note: previous declaration of ‘HttpENTSTestMain’ was here
   77 | HttpENTSTestMain (
  | ^~~~

Signed-off-by: Heinrich Schuchardt 
---
This is only a partial fix to the problem reported in #2126.
---
 uefi-sct/SctPkg/TestCase/RIVL/Protocol/Http/Http/HttpENTSTest.c  | 1 +
 .../Http/HttpServiceBinding/HttpServiceBindingENTSTest.c | 1 +
 .../Mtftp6/Mtftp6ServiceBinding/Mtftp6ServiceBindingENTSTest.c   | 1 +
 uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp4/Tcp4/Tcp4ENTSTest.c  | 1 +
 .../Tcp4/Tcp4ServiceBinding/Tcp4ServiceBindingENTSTest.c | 1 +
 uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp6/Tcp6/Tcp6ENTSTest.c  | 1 +
 .../Tcp6/Tcp6ServiceBinding/Tcp6ServiceBindingENTSTest.c | 1 +
 7 files changed, 7 insertions(+)

diff --git a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Http/Http/HttpENTSTest.c 
b/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Http/Http/HttpENTSTest.c
index 0e65fc0e..f380df70 100644
--- a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Http/Http/HttpENTSTest.c
+++ b/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Http/Http/HttpENTSTest.c
@@ -71,6 +71,7 @@ HttpENTSTestUnload (
 

 

 EFI_STATUS

+EFIAPI

 HttpENTSTestMain (

   IN EFI_HANDLEImageHandle,

   IN EFI_SYSTEM_TABLE  *SystemTable

diff --git 
a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Http/HttpServiceBinding/HttpServiceBindingENTSTest.c
 
b/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Http/HttpServiceBinding/HttpServiceBindingENTSTest.c
index 5a538ca7..0b2f0b15 100644
--- 
a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Http/HttpServiceBinding/HttpServiceBindingENTSTest.c
+++ 
b/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Http/HttpServiceBinding/HttpServiceBindingENTSTest.c
@@ -52,6 +52,7 @@ HttpServiceBindingENTSTestUnload (
 

 

 EFI_STATUS

+EFIAPI

 HttpServiceBindingENTSTestMain (

   IN EFI_HANDLEImageHandle,

   IN EFI_SYSTEM_TABLE  *SystemTable

diff --git 
a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Mtftp6/Mtftp6ServiceBinding/Mtftp6ServiceBindingENTSTest.c
 
b/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Mtftp6/Mtftp6ServiceBinding/Mtftp6ServiceBindingENTSTest.c
index b87a43ef..07a1ca0d 100644
--- 
a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Mtftp6/Mtftp6ServiceBinding/Mtftp6ServiceBindingENTSTest.c
+++ 
b/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Mtftp6/Mtftp6ServiceBinding/Mtftp6ServiceBindingENTSTest.c
@@ -53,6 +53,7 @@ Mtftp6ServiceBindingENTSTestUnload (
 

 

 EFI_STATUS

+EFIAPI

 Mtftp6ServiceBindingENTSTestMain (

   IN EFI_HANDLEImageHandle,

   IN EFI_SYSTEM_TABLE  *SystemTable

diff --git a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp4/Tcp4/Tcp4ENTSTest.c 
b/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp4/Tcp4/Tcp4ENTSTest.c
index 261e9adb..e8d472c2 100644
--- a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp4/Tcp4/Tcp4ENTSTest.c
+++ b/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp4/Tcp4/Tcp4ENTSTest.c
@@ -91,6 +91,7 @@ Tcp4ENTSTestUnload (
 

 

 EFI_STATUS

+EFIAPI

 Tcp4ENTSTestMain (

   IN EFI_HANDLEImageHandle,

   IN EFI_SYSTEM_TABLE  *SystemTable

diff --git 
a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp4/Tcp4ServiceBinding/Tcp4ServiceBindingENTSTest.c
 
b/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp4/Tcp4ServiceBinding/Tcp4ServiceBindingENTSTest.c
index 15e6b1cc..b887ee64 100644
--- 
a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp4/Tcp4ServiceBinding/Tcp4ServiceBindingENTSTest.c
+++ 
b/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp4/Tcp4ServiceBinding/Tcp4ServiceBindingENTSTest.c
@@ -52,6 +52,7 @@ Tcp4ServiceBindingENTSTestUnload (
 

 

 EFI_STATUS

+EFIAPI

 Tcp4ServiceBindingENTSTestMain (

   IN EFI_HANDLEImageHandle,

   IN EFI_SYSTEM_TABLE  *SystemTable

diff --git a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp6/Tcp6/Tcp6ENTSTest.c 
b/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp6/Tcp6/Tcp6ENTSTest.c
index 3d4d5a35..f643136d 100644
--- a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp6/Tcp6/Tcp6ENTSTest.c
+++ b/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp6/Tcp6/Tcp6ENTSTest.c
@@ -87,6 +87,7 @@ Tcp6ENTSTestUnload (
 

 

 EFI_STATUS

+EFIAPI

 Tcp6ENTSTestMain (

   IN EFI_HANDLEImageHandle,

   IN EFI_SYSTEM_TABLE  *SystemTable

diff --git 
a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp6/Tcp6ServiceBinding/Tcp6ServiceBindingENTSTest.c
 
b/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp6/Tcp6ServiceBinding/Tcp6ServiceBindingENTSTest.c
index e35f6fc1..6c49bd1d 100644
--- 
a/uefi-sct/SctPkg/TestCase/RIVL/Protocol/Tcp6/Tcp6ServiceBinding/Tcp6ServiceBindingENTSTest.c
+++

Re: [edk2-devel] [edk2-test][Patch] uefi-sct/SctPkg: Add MediaPresentSupported check

2019-09-24 Thread Heinrich Schuchardt


On 9/24/19 10:50 AM, xianhui liu wrote:

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2061
check MediaPresent while MediaPresentSupported is TRUE
sync change from EFI to IHV SimpleNetworkBBTestFunction


Thanks for addressing this issue.



Cc: Heinrich Schuchardt 


%s/Cc:/Reported-by:/


Cc: Supreeth Venkatesh 
Cc: Eric Jin 

Signed-off-by: xianhui liu 
---
  .../BlackBoxTest/SimpleNetworkBBTestFunction.c | 64 +++---
  1 file changed, 33 insertions(+), 31 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestFunction.c
index b4c7b5ee..8559e894 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestFunction.c
@@ -1888,38 +1888,40 @@ BBTestGetStatusFunctionTest (
Status = SnpInterface->GetStatus (SnpInterface, , );
Status1 = SnpInterface->GetStatus (SnpInterface, , );

-  if (SnpInterface->Mode->MediaPresent == FALSE) {
-if ((Status1 == EFI_SUCCESS) && (Status == EFI_SUCCESS) && 
(InterruptStatus == 0)) {
-  AssertionType = EFI_TEST_ASSERTION_PASSED;
-} else {
-  AssertionType = EFI_TEST_ASSERTION_FAILED;
-}
-  } else {
-if ((Status1 == EFI_SUCCESS) && (Status == EFI_SUCCESS)) {
-  AssertionType = EFI_TEST_ASSERTION_PASSED;
-  if (InterruptStatus &
- ~( EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT |
-EFI_SIMPLE_NETWORK_TRANSMIT_INTERRUPT |
-EFI_SIMPLE_NETWORK_COMMAND_INTERRUPT |
-EFI_SIMPLE_NETWORK_SOFTWARE_INTERRUPT)) {
-AssertionType = EFI_TEST_ASSERTION_FAILED;
-  }
-} else {
-  AssertionType = EFI_TEST_ASSERTION_FAILED;
-}
+  if (SnpInterface->Mode-> MediaPresentSupported == TRUE) {
+ if (SnpInterface->Mode->MediaPresent == FALSE) {



If MediaPresentSupported == FALSE shouldn't we assume that Media is present.

So isn't a single 'if' enough:

if (SnpInterface->Mode-> MediaPresentSupported == TRUE &&
SnpInterface->Mode->MediaPresent == FALSE) {

Best regards

Heinrich Schuchardt


+   if ((Status1 == EFI_SUCCESS) && (Status == EFI_SUCCESS) && 
(InterruptStatus == 0)) {
+ AssertionType = EFI_TEST_ASSERTION_PASSED;
+   } else {
+ AssertionType = EFI_TEST_ASSERTION_FAILED;
+   }
+ } else {
+   if ((Status1 == EFI_SUCCESS) && (Status == EFI_SUCCESS)) {
+ AssertionType = EFI_TEST_ASSERTION_PASSED;
+ if (InterruptStatus &
+~( EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT |
+   EFI_SIMPLE_NETWORK_TRANSMIT_INTERRUPT |
+   EFI_SIMPLE_NETWORK_COMMAND_INTERRUPT |
+   EFI_SIMPLE_NETWORK_SOFTWARE_INTERRUPT)) {
+   AssertionType = EFI_TEST_ASSERTION_FAILED;
+ }
+   } else {
+ AssertionType = EFI_TEST_ASSERTION_FAILED;
+   }
+ }
+ StandardLib->RecordAssertion (
+StandardLib,
+AssertionType,
+gSimpleNetworkBBTestFunctionAssertionGuid022,
+L"EFI_SIMPLE_NETWORK_PROTOCOL.GetStatus - Invoke GetStatus() 
and verify interface correctness within test case",
+L"%a:%d:Status - %r, Status1 - %r, InterruptStatus - %d",
+__FILE__,
+(UINTN)__LINE__,
+Status,
+Status1,
+InterruptStatus
+);
}
-  StandardLib->RecordAssertion (
- StandardLib,
- AssertionType,
- gSimpleNetworkBBTestFunctionAssertionGuid022,
- L"EFI_SIMPLE_NETWORK_PROTOCOL.GetStatus - Invoke GetStatus() and 
verify interface correctness within test case",
- L"%a:%d:Status - %r, Status1 - %r, InterruptStatus - %d",
- __FILE__,
- (UINTN)__LINE__,
- Status,
- Status1,
- InterruptStatus
- );

//
// Restore SNP State




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

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

Re: [edk2-devel] [RFC PATCH v2 04/44] OvmfPkg/ResetVector: Add support for a 32-bit SEV check

2019-09-24 Thread Lendacky, Thomas

On 9/24/19 8:42 AM, Laszlo Ersek wrote:
> On 09/19/19 21:52, Lendacky, Thomas wrote:
>> From: Tom Lendacky 
>>
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
>>
>> During BSP startup, the reset vector code will issue a CPUID instruction
>> while in 32-bit mode. When running as an SEV-ES guest, this will trigger
>> a #VC exception.
> 
> (1) In the assembly source code, please annotate both CPUID instructions
> under CheckSevFeature, such as
> 
>   ; raises #VC when in an SEV-ES guest

Will do.

> 
>>
>> Add exception handling support to the early reset vector code to catch
>> these exceptions.  Also, since the guest is in 32-bit mode at this point,
>> writes to the GHCB will be encrypted and thus not able to be read by the
>> hypervisor, so use the GHCB CPUID request/response protocol to obtain the
>> requested CPUID function values and provide these to the guest.
>>
>> The exception handling support is active during the SEV check and uses the
>> OVMF temporary RAM space for a stack. After the SEV check is complete, the
>> exception handling support is removed and the stack pointer cleared.
>>
>> Cc: Jordan Justen 
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Signed-off-by: Tom Lendacky 
>> ---
>>  OvmfPkg/ResetVector/ResetVector.inf   |   2 +
>>  OvmfPkg/ResetVector/Ia32/PageTables64.asm | 177 +-
>>  OvmfPkg/ResetVector/ResetVector.nasmb |   1 +
>>  3 files changed, 179 insertions(+), 1 deletion(-)
>>
>> diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
>> b/OvmfPkg/ResetVector/ResetVector.inf
>> index b0ddfa5832a2..960b47cd0797 100644
>> --- a/OvmfPkg/ResetVector/ResetVector.inf
>> +++ b/OvmfPkg/ResetVector/ResetVector.inf
>> @@ -35,3 +35,5 @@ [BuildOptions]
>>  [Pcd]
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
>> diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
>> b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
>> index abad009f20f5..40f7814c1134 100644
>> --- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
>> +++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
>> @@ -33,10 +33,21 @@ BITS32
>>  
>>  ; Check if Secure Encrypted Virtualization (SEV) feature is enabled
>>  ;
>> -; If SEV is enabled then EAX will be at least 32
>> +; Modified:  EAX, EBX, ECX, EDX, ESP
>> +;
>> +; If SEV is enabled then EAX will be at least 32.
>>  ; If SEV is disabled then EAX will be zero.
>>  ;
>>  CheckSevFeature:
>> +;
>> +; Set up exception handlers to check for SEV-ES
>> +;   Load temporary RAM stack based on PCDs
>> +;   Establish exception handlers
>> +;
>> +mov   esp, SEV_TOP_OF_STACK
> 
> (2) Can we %define SEV_TOP_OF_STACK in this file, or does it have to be
> in "ResetVector.nasmb"?

It looks like it has to be in ResetVector.nasmb for some reason. If I move
it into this file, it fails:

Ia32/PageTables64.asm:76: error: expecting `)'

> 
> (3) Do we have an estimate how much stack we need? This would be a
> constraint on PcdOvmfSecPeiTempRamSize. The limit would be nice to
> document (perhaps in a comment somewhere).

It's a fairly small amount of stack space, about 44 bytes (12 bytes for
the IRET frame and 32 bytes for the #VC "local" variables). The temporary
RAM size is 64K, so we're fine. I'll document the stack usage at the start
of the SevEsIdtVmmComm exception handler.

> 
>> +mov   eax, ADDR_OF(Idtr)
>> +lidt  [cs:eax]
>> +
>>  ; Check if we have a valid (0x8000_001F) CPUID leaf
>>  mov   eax, 0x8000
>>  cpuid
>> @@ -73,6 +84,15 @@ NoSev:
>>  xor   eax, eax
>>  
>>  SevExit:
>> +;
>> +; Clear exception handlers and stack
>> +;
>> +push  eax
>> +mov   eax, ADDR_OF(IdtrClear)
>> +lidt  [cs:eax]
>> +pop   eax
>> +mov   esp, 0
>> +
> 
> I'm not sure the resultant IDT and ESP contents are the same as before
> (pre-patch), but I guess these values should be OK too.

At this stage of the boot, both the IDT and ESP values are zero. They
haven't been set up this early in the boot.

> 
>>  OneTimeCallRet CheckSevFeature
>>  
>>  ;
>> @@ -146,3 +166,158 @@ pageTableEntriesLoop:
>>  mov cr3, eax
>>  
>>  OneTimeCallRet SetCr3ForPageTables64
>> +
>> +SevEsIdtCommon:
>> +hlt
>> +jmp SevEsIdtCommon
>> +iret
>> +
>> +SevEsIdtVmmComm:
>> +;
>> +; If we're here, then we are an SEV-ES guest and this
>> +; was triggered by a CPUID instruction
>> +;
>> +pop ecx ; Error code
>> +cmp ecx, 0x72   ; Be sure it was CPUID
>> +jne SevEsIdtCommon
> 
> (4) Can you steal the DebugLog / PrintStringSi code from
> "OvmfPkg/QemuVideoDxe/VbeShim.asm", and print a simple message to the
> QEMU debug port, whenever you jump to SevEsIdtCommon?
> 
> This is basically an ASSERT(). It should have a

[edk2-devel] [edk2-platforms][PATCH V2 05/15] KabylakeOpenBoardPkg: Move EcCommands.h to KabylakeRvp3 board

2019-09-24 Thread Kubacki, Michael A

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

EC command details may vary across Kaby Lake boards. This change moves
this set of EC commands to the KabylakeRvp3 directory since these
commands are specifically used by that board at this time.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 
---
 Platform/Intel/KabylakeOpenBoardPkg/{ => KabylakeRvp3}/Include/EcCommands.h | 0
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/Platform/Intel/KabylakeOpenBoardPkg/Include/EcCommands.h 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Include/EcCommands.h
similarity index 100%
rename from Platform/Intel/KabylakeOpenBoardPkg/Include/EcCommands.h
rename to Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Include/EcCommands.h
-- 
2.16.2.windows.1


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

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

[edk2-devel] [edk2-platforms][PATCH V2 07/15] KabylakeOpenBoardPkg: Add PeiSerialPortLibSpiFlash

2019-09-24 Thread Kubacki, Michael A

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

PeiSerialPortLibSpiFlash is currently used for early boot closed
chassis debug on production systems such as the System 76 Galago Pro
laptop. This change moves the library to KabylakeOpenBoardPkg from
ClevoOpenBoardPkg since the Clevo package is being removes for
code consolidation.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 
---
 Platform/Intel/KabylakeOpenBoardPkg/OpenBoardPkg.dec   
   |   6 +
 
Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/PeiSerialPortLibSpiFlash.inf
 |  50 +++
 
Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/PeiSerialPortLibSpiFlash.c
   | 320 
 3 files changed, 376 insertions(+)

diff --git a/Platform/Intel/KabylakeOpenBoardPkg/OpenBoardPkg.dec 
b/Platform/Intel/KabylakeOpenBoardPkg/OpenBoardPkg.dec
index 68977d081e..383c34537d 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/OpenBoardPkg.dec
+++ b/Platform/Intel/KabylakeOpenBoardPkg/OpenBoardPkg.dec
@@ -29,6 +29,8 @@ gBoardModuleTokenSpaceGuid=  {0x72d1fff7, 0xa42a, 
0x4219, {0xb9, 0x9
 
 gTianoLogoGuid=  {0x7BB28B99, 0x61BB, 0x11D5, {0x9A, 
0x5D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D}}
 
+gSpiFlashDebugHobGuid =  {0xcaaaf418, 0x38a5, 0x4d49, {0xbe, 
0x74, 0xe6, 0x06, 0xe4, 0x02, 0x6d, 0x25}}
+
 gTbtInfoHobGuid   =  {0x74a81eaa, 0x033c, 0x4783, {0xbe, 
0x2b, 0x84, 0x85, 0x74, 0xa6, 0x97, 0xb7}}
 
 gPlatformModuleTokenSpaceGuid =  {0x69d13bf0, 0xaf91, 0x4d96, {0xaa, 
0x9f, 0x21, 0x84, 0xc5, 0xce, 0x3b, 0xc0}}
@@ -65,6 +67,10 @@ 
gBoardModuleTokenSpaceGuid.PcdSwSmiDTbtEnumerate|0xF7|UINT8|0x00110
 
 gBoardModuleTokenSpaceGuid.PcdSmcExtSmiBitPosition|0x01|UINT8|0x9015
 
+gBoardModuleTokenSpaceGuid.PcdFlashNvDebugMessageBase|0x|UINT32|0x9030
+gBoardModuleTokenSpaceGuid.PcdFlashNvDebugMessageSize|0x|UINT32|0x9031
+gBoardModuleTokenSpaceGuid.PcdFlashNvDebugMessageOffset|0x|UINT32|0x9032
+
 [PcdsDynamic]
 
 # Board GPIO Table
diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/PeiSerialPortLibSpiFlash.inf
 
b/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/PeiSerialPortLibSpiFlash.inf
new file mode 100644
index 00..ed93d0785f
--- /dev/null
+++ 
b/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/PeiSerialPortLibSpiFlash.inf
@@ -0,0 +1,50 @@
+### @file
+# Component description file for Serial I/O Port library to write to SPI flash.
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = PeiSerialPortLibFlash
+  FILE_GUID  = 35A3BA89-04BE-409C-A3CA-DEF6B510F80F
+  VERSION_STRING = 1.1
+  MODULE_TYPE= PEIM
+  LIBRARY_CLASS  = SerialPortLib|PEIM PEI_CORE
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+# VALID_ARCHITECTURES = IA32 X64 IPF
+#
+
+[LibraryClasses]
+  BaseLib
+  BaseMemoryLib
+  HobLib
+  PcdLib
+  PeiServicesLib
+  SpiLib
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MinPlatformPkg/MinPlatformPkg.dec
+  KabylakeSiliconPkg/SiPkg.dec
+  KabylakeOpenBoardPkg/OpenBoardPkg.dec
+
+[Sources]
+  PeiSerialPortLibSpiFlash.c
+
+[Ppis]
+  gPchSpiPpiGuid
+
+[Guids]
+  gSpiFlashDebugHobGuid
+
+[Pcd]
+  gMinPlatformPkgTokenSpaceGuid.PcdFlashAreaBaseAddress   ## CONSUMES
+  gBoardModuleTokenSpaceGuid.PcdFlashNvDebugMessageBase   ## CONSUMES
+  gBoardModuleTokenSpaceGuid.PcdFlashNvDebugMessageSize   ## CONSUMES
diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/PeiSerialPortLibSpiFlash.c
 
b/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/PeiSerialPortLibSpiFlash.c
new file mode 100644
index 00..0230149a38
--- /dev/null
+++ 
b/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/PeiSerialPortLibSpiFlash.c
@@ -0,0 +1,320 @@
+/** @file
+  Serial I/O Port library implementation for output to SPI flash
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+typedef struct {
+  PCH_SPI_PPI   *PchSpiPpi;
+  UINT32CurrentWriteOffset;
+} SPI_FLASH_DEBUG_CONTEXT;
+
+/**
+  Update reference to the most recent PCH SPI PPI installed
+
+  @param PeiServices   An indirect pointer to the EFI_PEI_SERVICES table 
published by the PEI Foundation
+  @param NotifyDescriptor  Address of the notification descriptor data 
structure.
+  @param Ppi

[edk2-devel] [edk2-platforms][PATCH V2 12/15] KabylakeOpenBoardPkg: Add board ID to Global NVS

2019-09-24 Thread Kubacki, Michael A

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

Adds the board ID as a field in global NVS (BDID) to allow ACPI code
to take conditional actions based on the active board.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 
---
 Platform/Intel/KabylakeOpenBoardPkg/Include/Acpi/GlobalNvsAreaDef.h
 | 3 ++-
 
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeGalagoPro3AcpiTableLib.c
 | 2 ++
 
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeKabylakeRvp3AcpiTableLib.c
 | 2 ++
 Platform/Intel/KabylakeOpenBoardPkg/Include/Acpi/GlobalNvs.asl 
 | 3 ++-
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Include/Acpi/GlobalNvsAreaDef.h 
b/Platform/Intel/KabylakeOpenBoardPkg/Include/Acpi/GlobalNvsAreaDef.h
index 93c5a0b55a..3d0a3f4ed8 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/Include/Acpi/GlobalNvsAreaDef.h
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Include/Acpi/GlobalNvsAreaDef.h
@@ -1,7 +1,7 @@
 /** @file
   ACPI DSDT table
 
-Copyright (c) 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -111,6 +111,7 @@ typedef struct {
   UINT8TbtNativeOsHotPlug;  ///< Offset 81  
TbtNativeOsHotPlug
   UINT8TbtSelector; ///< Offset 82  
Thunderbolt(TM) Root port selector
   UINT8TbtSelector1;///< Offset 83  
Thunderbolt(TM) Root port selector
+  UINT8BoardId; ///< Offset 84  Board 
ID
 } EFI_GLOBAL_NVS_AREA;
 
 #pragma pack(pop)
diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeGalagoPro3AcpiTableLib.c
 
b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeGalagoPro3AcpiTableLib.c
index b9386d59b8..5b36f6dfb3 100644
--- 
a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeGalagoPro3AcpiTableLib.c
+++ 
b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeGalagoPro3AcpiTableLib.c
@@ -56,6 +56,8 @@ GalagoPro3UpdateGlobalNvs (
 
   mGlobalNvsArea.Area->Ps2MouseEnable = PcdGet8 (PcdPs2KbMsEnable);
   mGlobalNvsArea.Area->Ps2KbMsEnable  = PcdGet8 (PcdPs2KbMsEnable);
+
+  mGlobalNvsArea.Area->BoardId = (UINT8) LibPcdGetSku ();
 }
 
 EFI_STATUS
diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeKabylakeRvp3AcpiTableLib.c
 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeKabylakeRvp3AcpiTableLib.c
index 154d859090..eceac3d037 100644
--- 
a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeKabylakeRvp3AcpiTableLib.c
+++ 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeKabylakeRvp3AcpiTableLib.c
@@ -56,6 +56,8 @@ KabylakeRvp3UpdateGlobalNvs (
 
   mGlobalNvsArea.Area->Ps2MouseEnable = FALSE;
   mGlobalNvsArea.Area->Ps2KbMsEnable  = PcdGet8 (PcdPs2KbMsEnable);
+
+  mGlobalNvsArea.Area->BoardId = (UINT8) LibPcdGetSku ();
 }
 
 EFI_STATUS
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/Include/Acpi/GlobalNvs.asl 
b/Platform/Intel/KabylakeOpenBoardPkg/Include/Acpi/GlobalNvs.asl
index e0ff9d9bf5..92b4bc1e53 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/Include/Acpi/GlobalNvs.asl
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Include/Acpi/GlobalNvs.asl
@@ -1,7 +1,7 @@
 /** @file
   ACPI DSDT table
 
-Copyright (c) 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -111,4 +111,5 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
   Offset(81), TNAT, 8,  // Offset(81),TbtNativeOsHotPlug
   Offset(82), TBSE, 8,  // Offset(82),Thunderbolt(TM) Root port 
selector
   Offset(83), TBS1, 8,  // Offset(83),Thunderbolt(TM) Root port 
selector
+  Offset(84), BDID, 8,  // Offset(84),Board ID
   }
-- 
2.16.2.windows.1


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

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

[edk2-devel] [edk2-platforms][PATCH V2 10/15] KabylakeOpenBoardPkg/GalagoPro3: Add modules

2019-09-24 Thread Kubacki, Michael A

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

Adds the modules used for System 76 Galago Pro 3 board support.

This override should be removed in a future cleanup change. That is
outside the scope of this change which is to move the contents from
ClevoOpenBoardPkg/N1xxWU to KabylakeOpenBoardPkg/GalagoPro3.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 
---
 
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Override/Platform/Intel/MinPlatformPkg/PlatformInit/PlatformInitPei/PlatformInitPreMem.inf
 |  67 ++
 Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h  
   |   2 +-
 
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Override/Platform/Intel/MinPlatformPkg/PlatformInit/PlatformInitPei/PlatformInitPreMem.c
   | 640 
 3 files changed, 708 insertions(+), 1 deletion(-)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Override/Platform/Intel/MinPlatformPkg/PlatformInit/PlatformInitPei/PlatformInitPreMem.inf
 
b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Override/Platform/Intel/MinPlatformPkg/PlatformInit/PlatformInitPei/PlatformInitPreMem.inf
new file mode 100644
index 00..76dd67d1a8
--- /dev/null
+++ 
b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Override/Platform/Intel/MinPlatformPkg/PlatformInit/PlatformInitPei/PlatformInitPreMem.inf
@@ -0,0 +1,67 @@
+### @file
+# Component information file for the Platform Init Pre-Memory PEI module.
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+###
+
+[Defines]
+  INF_VERSION= 0x00010017
+  BASE_NAME  = PlatformInitPreMem
+  FILE_GUID  = 611D-F78F-4FB9-B868-55907F169280
+  VERSION_STRING = 1.0
+  MODULE_TYPE= PEIM
+  ENTRY_POINT= PlatformInitPreMemEntryPoint
+
+[LibraryClasses]
+  BaseMemoryLib
+  BoardInitLib
+  DebugLib
+  HobLib
+  IoLib
+  MemoryAllocationLib
+  MtrrLib
+  PeimEntryPoint
+  PeiServicesLib
+  ReportFvLib
+  TestPointCheckLib
+  TimerLib
+
+[Packages]
+  MinPlatformPkg/MinPlatformPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  UefiCpuPkg/UefiCpuPkg.dec
+
+[Pcd]
+  gMinPlatformPkgTokenSpaceGuid.PcdFspWrapperBootMode  ## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdFlashAreaBaseAddress## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdFlashAreaSize   ## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdStopAfterDebugInit  ## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdStopAfterMemInit## CONSUMES
+
+[FixedPcd]
+  gMinPlatformPkgTokenSpaceGuid.PcdPlatformEfiAcpiReclaimMemorySize  ## 
CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdPlatformEfiAcpiNvsMemorySize  ## 
CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdPlatformEfiReservedMemorySize ## 
CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdPlatformEfiRtDataMemorySize   ## 
CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdPlatformEfiRtCodeMemorySize   ## 
CONSUMES
+
+[Sources]
+  PlatformInitPreMem.c
+
+[Ppis]
+  gEfiPeiMemoryDiscoveredPpiGuid
+  gEfiPeiMasterBootModePpiGuid  ## PRODUCES
+  gEfiPeiBootInRecoveryModePpiGuid  ## PRODUCES
+  gEfiPeiReadOnlyVariable2PpiGuid
+  gPeiBaseMemoryTestPpiGuid
+  gPeiPlatformMemorySizePpiGuid
+
+[Guids]
+  gEfiMemoryTypeInformationGuid
+
+[Depex]
+  gEfiPeiReadOnlyVariable2PpiGuid
diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h 
b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h
index 5999f18edf..d85a7dcf52 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h
+++ b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h
@@ -8,6 +8,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #ifndef _GALAGO_PRO_3_ID_H_
 #define _GALAGO_PRO_3_ID_H_
 
-#define BoardIdGalagoPro3 0x60
+#define BoardIdGalagoPro3 0x20
 
 #endif
diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Override/Platform/Intel/MinPlatformPkg/PlatformInit/PlatformInitPei/PlatformInitPreMem.c
 
b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Override/Platform/Intel/MinPlatformPkg/PlatformInit/PlatformInitPei/PlatformInitPreMem.c
new file mode 100644
index 00..b784026c1b
--- /dev/null
+++ 
b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Override/Platform/Intel/MinPlatformPkg/PlatformInit/PlatformInitPei/PlatformInitPreMem.c
@@ -0,0 +1,640 @@
+/** @file
+  Source code file for Platform Init Pre-Memory PEI module
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include

[edk2-devel] [edk2-platforms][PATCH V2 06/15] KabylakeOpenBoardPkg: Move flash map to board

2019-09-24 Thread Kubacki, Michael A

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

The flash map currently in KabylakeOpenBoardPkg is only
applicable to the KabylakeRvp3 board. This change moves
the flash map to that board directory to prepare for other
boards to reside in the package.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 
---
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/Include/Fdf/FlashMapInclude.fdf | 0
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf  
| 2 +-
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/build_config.cfg  
| 2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Include/Fdf/FlashMapInclude.fdf 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Include/Fdf/FlashMapInclude.fdf
similarity index 100%
rename from Platform/Intel/KabylakeOpenBoardPkg/Include/Fdf/FlashMapInclude.fdf
rename to 
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Include/Fdf/FlashMapInclude.fdf
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf
index 7267d478ad..2b8eab36a1 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf
@@ -8,7 +8,7 @@
 ##
 
 [Defines]
-   !include $(PLATFORM_BOARD_PACKAGE)/Include/Fdf/FlashMapInclude.fdf
+   !include $(PROJECT)/Include/Fdf/FlashMapInclude.fdf
 
 

 #
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/build_config.cfg 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/build_config.cfg
index ab1a9a61c2..78f808bfaf 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/build_config.cfg
+++ b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/build_config.cfg
@@ -13,7 +13,7 @@ openssl_path =
 PLATFORM_BOARD_PACKAGE = KabylakeOpenBoardPkg
 PROJECT = KabylakeOpenBoardPkg/KabylakeRvp3
 BOARD = KabylakeRvp3
-FLASH_MAP_FDF = KabylakeOpenBoardPkg/Include/Fdf/FlashMapInclude.fdf
+FLASH_MAP_FDF = 
KabylakeOpenBoardPkg/KabylakeRvp3/Include/Fdf/FlashMapInclude.fdf
 PROJECT_DSC = KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
 BOARD_PKG_PCD_DSC = KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkgPcd.dsc
 ADDITIONAL_SCRIPTS = KabylakeOpenBoardPkg/KabylakeRvp3/build_board.py
-- 
2.16.2.windows.1


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

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

[edk2-devel] [edk2-platforms][PATCH V2 00/15] Move ClevoOpenBoardPkg/N1xxWU Contents to KabylakeOpenBoardPkg

2019-09-24 Thread Kubacki, Michael A

This patch series moves the N1xxWU board contents currently in ClevoOpenBoardPkg
to KabylakeOpenBoardPkg. The actual systems being tested are System 76 Galago 
Pro
laptops so the board itself is renamed from "N1xxWU" to"GalagoPro3". The system
models supported are the galp2 (Kaby Lake) and galp3 (Kaby Lake-R). This is
clarified under the board support information in the Readme.md update.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 

Michael Kubacki (15):
  Platform/Intel: Remove N1xxWU board build option
  ClevoOpenBoardPkg: Remove package contents
  ClevoOpenBoardPkg: Remove global files and references
  KabylakeOpenBoardPkg: Move policy update libs to KabylakeRvp3 board
  KabylakeOpenBoardPkg: Move EcCommands.h to KabylakeRvp3 board
  KabylakeOpenBoardPkg: Move flash map to board
  KabylakeOpenBoardPkg: Add PeiSerialPortLibSpiFlash
  KabylakeOpenBoardPkg/GalagoPro3: Add headers
  KabylakeOpenBoardPkg/GalagoPro3: Add library instances
  KabylakeOpenBoardPkg/GalagoPro3: Add modules
  KabylakeOpenBoardPkg: Consolidate board IDs in a single file
  KabylakeOpenBoardPkg: Add board ID to Global NVS
  KabylakeOpenBoardPkg/BoardAcpiDxe: Add Synaptics PS/2 mouse
  KabylakeOpenBoardPkg/GalagoPro3: Add build files
  Add GalagoPro3 board details to global build and documentation

 Platform/Intel/ClevoOpenBoardPkg/OpenBoardPkg.dec  

|  305 
 Platform/Intel/KabylakeOpenBoardPkg/OpenBoardPkg.dec   

|   10 +-
 Platform/Intel/{ClevoOpenBoardPkg/N1xxWU => 
KabylakeOpenBoardPkg/GalagoPro3}/OpenBoardPkg.dsc   
   |8 +-
 Platform/Intel/{ClevoOpenBoardPkg/N1xxWU => 
KabylakeOpenBoardPkg/GalagoPro3}/OpenBoardPkgBuildOption.dsc
   |2 +-
 Platform/Intel/{ClevoOpenBoardPkg/N1xxWU => 
KabylakeOpenBoardPkg/GalagoPro3}/OpenBoardPkgConfig.dsc 
   |2 +-
 Platform/Intel/{ClevoOpenBoardPkg/N1xxWU => 
KabylakeOpenBoardPkg/GalagoPro3}/OpenBoardPkgPcd.dsc
   |2 +-
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc  

|6 +-
 Platform/Intel/{ClevoOpenBoardPkg/N1xxWU => 
KabylakeOpenBoardPkg/GalagoPro3}/Include/Fdf/FlashMapInclude.fdf
   |2 +-
 Platform/Intel/{ClevoOpenBoardPkg/N1xxWU => 
KabylakeOpenBoardPkg/GalagoPro3}/OpenBoardPkg.fdf   
   |6 +-
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/Include/Fdf/FlashMapInclude.fdf   
  |0
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf  

|2 +-
 Platform/Intel/ClevoOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe.inf

|   69 -
 Platform/Intel/ClevoOpenBoardPkg/Features/PciHotPlug/PciHotPlug.inf

|   59 -
 
Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/Library/DxeTbtPolicyLib/DxeTbtPolicyLib.inf

  |   67 -
 
Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/Library/PeiDxeSmmTbtCommonLib/TbtCommonLib.inf

   |   62 -
 
Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/Library/PeiTbtPolicyLib/PeiTbtPolicyLib.inf

  |   56 -
 
Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/Library/Private/PeiDTbtInitLib/PeiDTbtInitLib.inf

|   41 -
 Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/TbtInit/Dxe/TbtDxe.inf   

|   49 -
 Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/TbtInit/Pei/PeiTbtInit.inf   

|   44 -
 Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/TbtInit/Smm/TbtSmm.inf

[edk2-devel] [edk2-platforms][PATCH V2 14/15] KabylakeOpenBoardPkg/GalagoPro3: Add build files

2019-09-24 Thread Kubacki, Michael A

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

 * Adds files required to build the GalagoPro3 board to the board
   directory.
 * Updates KabylakeOpenBoardPkg/OpenBoardPkg.dec to reference
   the new GalagoPro3 board directory.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 
---
 Platform/Intel/KabylakeOpenBoardPkg/OpenBoardPkg.dec   
|   4 +-
 Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/OpenBoardPkg.dsc
| 385 +++
 Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/OpenBoardPkgBuildOption.dsc 
| 151 +
 Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/OpenBoardPkgConfig.dsc  
| 132 
 Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/OpenBoardPkgPcd.dsc 
| 265 
 Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/Fdf/FlashMapInclude.fdf 
|  48 ++
 Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/OpenBoardPkg.fdf
| 716 
 Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/build_config.cfg
|  33 +
 8 files changed, 1732 insertions(+), 2 deletions(-)

diff --git a/Platform/Intel/KabylakeOpenBoardPkg/OpenBoardPkg.dec 
b/Platform/Intel/KabylakeOpenBoardPkg/OpenBoardPkg.dec
index 383c34537d..bdaf728af1 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/OpenBoardPkg.dec
+++ b/Platform/Intel/KabylakeOpenBoardPkg/OpenBoardPkg.dec
@@ -1,5 +1,5 @@
 ## @file
-# Module describe the entire platform configuration.
+# Declaration file for Kaby Lake based boards.
 #
 # The DEC files are used by the utilities that parse DSC and
 # INF files to generate AutoGen.c and AutoGen.h files
@@ -20,6 +20,7 @@ PACKAGE_GUID = 0A8BA6E8-C8AC-4AC1-87AC-52772FA6AE5E
 
 [Includes]
 Include
+GalagoPro3/Include
 KabylakeRvp3/Include
 Features/Tbt/Include
 
@@ -303,7 +304,6 @@ 
gBoardModuleTokenSpaceGuid.PcdIoExpanderPresent|FALSE|BOOLEAN|0x00EC
 
   gBoardModuleTokenSpaceGuid.PcdAcpiGnvsAddress|0|UINT64|0x4013
 
-  # gIntelPeiGraphicsVbtGuid =  {0x4ad46122, 0xffeb, 0x4a52, {0xbf, 0xb0, 
0x51, 0x8c, 0xfc, 0xa0, 0x2d, 0xb0}}
   gBoardModuleTokenSpaceGuid.PcdGraphicsVbtGuid|{0x22, 0x61, 0xd4, 0x4a, 0xeb, 
0xff, 0x52, 0x4a, 0xbf, 0xb0, 0x51, 0x8c, 0xfc, 0xa0, 0x2d, 
0xb0}|VOID*|0x4014
 
 [PcdsDynamicEx]
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/OpenBoardPkg.dsc 
b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/OpenBoardPkg.dsc
new file mode 100644
index 00..d67e0cc000
--- /dev/null
+++ b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/OpenBoardPkg.dsc
@@ -0,0 +1,385 @@
+## @file
+#  System 76 GalagoPro3 board description file.
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+[Defines]
+  #
+  # Set platform specific package/folder name, same as passed from PREBUILD 
script.
+  # PLATFORM_PACKAGE would be the same as PLATFORM_NAME as well as package 
build folder
+  # DEFINE only takes effect at R9 DSC and FDF.
+  #
+  DEFINE  PLATFORM_PACKAGE= MinPlatformPkg
+  DEFINE  PLATFORM_SI_PACKAGE = KabylakeSiliconPkg
+  DEFINE  PLATFORM_SI_BIN_PACKAGE = KabylakeSiliconBinPkg
+  DEFINE  PLATFORM_FSP_BIN_PACKAGE= KabylakeFspBinPkg
+  DEFINE  PLATFORM_BOARD_PACKAGE  = KabylakeOpenBoardPkg
+  DEFINE  BOARD   = GalagoPro3
+  DEFINE  PROJECT = 
$(PLATFORM_BOARD_PACKAGE)/$(BOARD)
+
+  #
+  # Platform On/Off features are defined here
+  #
+  !include OpenBoardPkgConfig.dsc
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME   = $(PLATFORM_PACKAGE)
+  PLATFORM_GUID   = 7324F33D-4E96-4F8B-A550-544DE6162AB7
+  PLATFORM_VERSION= 0.1
+  DSC_SPECIFICATION   = 0x00010005
+  OUTPUT_DIRECTORY= Build/$(PROJECT)
+  SUPPORTED_ARCHITECTURES = IA32|X64
+  BUILD_TARGETS   = DEBUG|RELEASE
+  SKUID_IDENTIFIER= ALL
+
+
+  FLASH_DEFINITION= $(PROJECT)/OpenBoardPkg.fdf
+
+  FIX_LOAD_TOP_MEMORY_ADDRESS = 0x0
+  DEFINE   TOP_MEMORY_ADDRESS = 0x0
+
+  #
+  # Default value for OpenBoardPkg.fdf use
+  #
+  DEFINE BIOS_SIZE_OPTION = SIZE_60
+
+
+#
+# SKU Identification section - list of all SKU IDs supported by this
+#  Platform.
+#
+
+[SkuIds]
+  0|DEFAULT  # The entry: 0|DEFAULT is reserved and always 
required.
+  0x20|GalagoPro3
+

[edk2-devel] [edk2-platforms][PATCH V2 15/15] Add GalagoPro3 board details to global build and documentation

2019-09-24 Thread Kubacki, Michael A

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

 * Updates maintainers for the System 76 GalagoPro3 board
 * Updated Readme.md with System 76 GalagoPro3 board details
 * Adds the ability to build the GalagoPro3 board to build.cfg

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 
---
 Maintainers.txt  |  3 ++
 Platform/Intel/Readme.md | 44 +---
 Platform/Intel/build.cfg |  1 +
 3 files changed, 34 insertions(+), 14 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index a30ee2f602..1260c8d246 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -87,6 +87,9 @@ M: Chasel Chiu 
 M: Michael Kubacki 
 M: Nate DeSimone 
 
+Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3
+R: Jeremy Soller 
+
 Platform/Intel/MinPlatformPkg
 M: Michael Kubacki 
 M: Chasel Chiu 
diff --git a/Platform/Intel/Readme.md b/Platform/Intel/Readme.md
index 6a9b1d2e00..03fa4c2315 100644
--- a/Platform/Intel/Readme.md
+++ b/Platform/Intel/Readme.md
@@ -83,6 +83,15 @@ A UEFI firmware implementation using MinPlatformPkg is 
constructed using the fol
 
||--||
 | Simics Quick Start Package| Nehalem  
  | SimicsOpenBoardPkg   | BoardX58Ich10  |
 
+ System 76
+
+***Galago Pro Laptop***
+
+| Machine Name  | Supported Chipsets   
  | BoardPkg | Board Name |
+||--||
+| galp2 | Kaby Lake
  | KabylakeOpenBoardPkg | GalagoPro3 |
+| galp3 & galp3-b   | Kaby Lake Refresh
  | KabylakeOpenBoardPkg | GalagoPro3 |
+
 ## Board Package Organization
 The board package follows the standard EDK II package structure with the 
following additional elements and guidelines:
 * Only code usable across more than one board at the root level.
@@ -217,28 +226,31 @@ return back to the minimum platform caller.
   |   || post-build, and clean 
functions.
   |   ||
   |   ||--KabylakeOpenBoardPkg
-  |   |||--KabylakeRvp3
-  |   ||  |---build_config.cfg: 
KabylakeRvp3 specific
-  |   ||  | build 
settings, environment variables.
-  |   ||  |---build_board.py: Optional 
board-specific pre-build, build
-  |   ||  and clean 
post-build functions.
+  |   ||   |--GalagoPro3
+  |   ||   |   |---build_config.cfg: System 76 
Galago Pro 3 specific build
+  |   ||   | settings 
environment variables.
+  |   ||   |--KabylakeRvp3
+  |   ||   |---build_config.cfg: KabylakeRvp3 
specific
+  |   ||   | build 
settings, environment variables.
+  |   ||   |---build_board.py: Optional 
board-specific pre-build, build
+  |   ||   and clean 
post-build functions.
   |   ||
   |   ||--PurleyOpenBoardPkg
   |   ||   |--BoardMtOlympus
-  |   |||---build_config.cfg: 
BoardMtOlympus specific
-  |   ||| build 
settings, environment variables.
-  |   |||---build_board.py: Optional 
board-specific pre-build,
-  |   ||build, 
post-build and clean functions.
+  |   ||   |---build_config.cfg: 
BoardMtOlympus specific
+  |   ||   | build 
settings, environment variables.
+  |   ||   |---build_board.py: Optional 
board-specific pre-build,
+  |   ||   build, 
post-build and clean functions.
   |   ||
   |   ||--SimicsOpenBoardPkg
   |   ||   |--BoardX58Ich10
-  |   |||---build_config.cfg: 
BoardX58Ich10 specific
-  |   ||| build 
settings, environment variables.
+  |   ||

[edk2-devel] [edk2-platforms][PATCH V2 11/15] KabylakeOpenBoardPkg: Consolidate board IDs in a single file

2019-09-24 Thread Kubacki, Michael A

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

Moves all Kaby Lake board ID definitions into a single header file
so it is easier to maintain the values and include the values
into common package files that need to make decisions based on board
ID.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 
---
 Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h  
  | 13 -
 
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardInitLib/PeiGalagoPro3InitLib.h
   |  2 +-
 Platform/Intel/KabylakeOpenBoardPkg/Include/PlatformBoardId.h  
  | 29 
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Include/KabylakeRvp3Id.h  
  | 15 --
 
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardInitLib/PeiKabylakeRvp3InitLib.h
   |  2 +-
 
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeGalagoPro3AcpiTableLib.c
  |  2 +-
 
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.c
|  2 +-
 
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/SmmGalagoPro3AcpiEnableLib.c
 |  2 +-
 
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/SmmMultiBoardAcpiSupportLib.c
|  2 +-
 
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardInitLib/PeiMultiBoardInitPostMemLib.c
|  2 +-
 
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardInitLib/PeiMultiBoardInitPreMemLib.c
 |  2 +-
 
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeKabylakeRvp3AcpiTableLib.c
  |  6 ++--
 
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.c
  |  2 +-
 
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/SmmKabylakeRvp3AcpiEnableLib.c
 |  4 +--
 
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/SmmMultiBoardAcpiSupportLib.c
  |  2 +-
 
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardInitLib/PeiBoardInitPreMemLib.c
|  2 +-
 
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardInitLib/PeiMultiBoardInitPostMemLib.c
  |  2 +-
 
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardInitLib/PeiMultiBoardInitPreMemLib.c
   |  2 +-
 18 files changed, 47 insertions(+), 46 deletions(-)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h 
b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h
deleted file mode 100644
index d85a7dcf52..00
--- a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/** @file
-
-Copyright (c) 2019, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#ifndef _GALAGO_PRO_3_ID_H_
-#define _GALAGO_PRO_3_ID_H_
-
-#define BoardIdGalagoPro3 0x20
-
-#endif
diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardInitLib/PeiGalagoPro3InitLib.h
 
b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardInitLib/PeiGalagoPro3InitLib.h
index 81d99f7295..742b5f5e04 100644
--- 
a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardInitLib/PeiGalagoPro3InitLib.h
+++ 
b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardInitLib/PeiGalagoPro3InitLib.h
@@ -18,7 +18,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 
-#include 
+#include 
 
 extern const UINT8 mDqByteMapSklRvp3[2][6][2];
 extern const UINT8 mDqsMapCpu2DramSklRvp3[2][8];
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/Include/PlatformBoardId.h 
b/Platform/Intel/KabylakeOpenBoardPkg/Include/PlatformBoardId.h
new file mode 100644
index 00..e83c56252d
--- /dev/null
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Include/PlatformBoardId.h
@@ -0,0 +1,29 @@
+/** @file
+Kaby Lake Platform Board Identifiers
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _PLATFORM_BOARD_ID_H_
+#define _PLATFORM_BOARD_ID_H_
+
+#define FlavorUnknown   0x0
+#define FlavorMobile0x1
+#define FlavorDesktop   0x2
+#define FlavorWorkstation   0x3
+#define FlavorUpServer  0x4
+#define FlavorEmbedded  0x5
+#define FlavorPlatformMax   0x6
+
+#define TypeUnknown 0x0
+#define TypeTrad0x1
+#define TypeUltUlx  0x2
+
+#define BoardIdSkylakeRvp3  0x4
+#define BoardIdGalagoPro3   0x20
+#define BoardIdKabyLakeYLpddr3Rvp3  0x60
+
+#define BoardIdUnknown1 0x
+
+#endif
diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Include/KabylakeRvp3Id.h

[edk2-devel] [edk2-platforms][PATCH V2 04/15] KabylakeOpenBoardPkg: Move policy update libs to KabylakeRvp3 board

2019-09-24 Thread Kubacki, Michael A

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

To prepare KabylakeOpenBoardPkg for multi-board support, the policy
update libraries should be moved to the individual board directory.
Prevously KabylakeOpenBoardPkg only supported the KabylakeRvp3 board
and the policy update libraries were kept above the board directory
level.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc  
 | 6 +++---
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf
 | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/Policy/Library/DxeSiliconPolicyUpdateLib/DxeSiliconPolicyUpdateLib.inf
   | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf
   | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiPchPolicyUpdate.h
 | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSaPolicyUpdate.h
  | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/Policy/Library/DxeSiliconPolicyUpdateLib/DxeGopPolicyInit.h   
   | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/Policy/Library/DxeSiliconPolicyUpdateLib/DxeSaPolicyInit.h
   | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PcieDeviceTable.c 
   | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspMiscUpdUpdateLib.c
 | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspPolicyUpdateLib.c
  | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiPchPolicyUpdate.c
 | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiPchPolicyUpdatePreMem.c
   | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSaPolicyUpdate.c
  | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSaPolicyUpdatePreMem.c
| 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/Policy/Library/DxeSiliconPolicyUpdateLib/DxeGopPolicyInit.c   
   | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/Policy/Library/DxeSiliconPolicyUpdateLib/DxeSaPolicyUpdate.c  
   | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/Policy/Library/DxeSiliconPolicyUpdateLib/DxeSiliconPolicyUpdateLib.c
 | 0
 Platform/Intel/KabylakeOpenBoardPkg/{ => 
KabylakeRvp3}/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.c
 | 0
 19 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
index 813ca040a1..7090852192 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
+++ b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
@@ -127,13 +127,13 @@
   #
   # Below library are used by FSP API mode
   #
-  
SiliconPolicyUpdateLib|$(PLATFORM_BOARD_PACKAGE)/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf
+  
SiliconPolicyUpdateLib|$(PROJECT)/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf
   
SiliconPolicyInitLib|$(PLATFORM_SI_PACKAGE)/Library/PeiSiliconPolicyInitLibFsp/PeiSiliconPolicyInitLibFsp.inf
 !else
   #
   # Below library are used by FSP Dispatch mode and non-FSP build (EDK2 build)
   #
-  
SiliconPolicyUpdateLib|$(PLATFORM_BOARD_PACKAGE)/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf
+  
SiliconPolicyUpdateLib|$(PROJECT)/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf
   
SiliconPolicyInitLib|$(PLATFORM_SI_PACKAGE)/Library/PeiSiliconPolicyInitLibFsp/PeiSiliconPolicyInitLibFspAml.inf
 !endif
 
@@ -196,7 +196,7 @@
   
BoardAcpiTableLib|$(PLATFORM_PACKAGE)/Acpi/Library/MultiBoardAcpiSupportLib/DxeMultiBoardAcpiSupportLib.inf
 
   
SiliconPolicyInitLib|$(PLATFORM_SI_PACKAGE)/Library/DxeSiliconPolicyInitLib/DxeSiliconPolicyInitLib.inf
-  
SiliconPolicyUpdateLib|$(PLATFORM_BOARD_PACKAGE)/Policy/Library/DxeSiliconPolicyUpdateLib/DxeSiliconPolicyUpdateLib.inf
+  
SiliconPolicyUpdateLib|$(PROJECT)/Policy/Library/DxeSiliconPolicyUpdateLib/DxeSiliconPolicyUpdateLib.inf
 
 #
 # Silicon Init Package
diff --git

[edk2-devel] [edk2-platforms][PATCH V2 13/15] KabylakeOpenBoardPkg/BoardAcpiDxe: Add Synaptics PS/2 mouse

2019-09-24 Thread Kubacki, Michael A

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

Moves the Synaptics PS/2 mouse support required for the Galago Pro 3
trackpad to function from the previous location in
ClevoOpenBoardPkg/N1xxWU to the common ASL file in KabylakeOpenBoardPkg.
The board ID is used to determine which PS/2 mouse device to expose.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 
---
 Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/LpcB.asl | 41 
+++-
 1 file changed, 39 insertions(+), 2 deletions(-)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/LpcB.asl 
b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/LpcB.asl
index 9f9d39c92c..d934c20beb 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/LpcB.asl
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/Dsdt/LpcB.asl
@@ -1,11 +1,12 @@
 /** @file
   ACPI DSDT table
 
-Copyright (c) 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
+#include "PlatformBoardId.h"
 
 // LPC Bridge - Device 31, Function 0
 scope (\_SB.PCI0.LPCB) {
@@ -66,7 +67,43 @@ scope (\_SB.PCI0.LPCB) {
   {
 If (P2MK) //Ps2 Keyboard and Mouse Enable
 {
-  Return(0x000F)
+  If (LNotEqual(BDID,BoardIdGalagoPro3))
+  {
+Return(0x000F)
+  }
+}
+  }
+  Return(0x)
+}
+
+Name(_CRS,ResourceTemplate()
+{
+  IRQ(Edge,ActiveHigh,Exclusive){0x0C}
+})
+
+Name(_PRS, ResourceTemplate(){
+  StartDependentFn(0, 0) {
+  IRQNoFlags(){12}
+  }
+  EndDependentFn()
+})
+  }
+
+  Device(SYNM)// Synaptics Mouse
+  {
+Name(_HID,"SYN1221")
+Name(_CID,EISAID("PNP0F13"))
+
+Method(_STA)
+{
+  If (P2ME) //Ps2 Mouse Enable
+  {
+If (P2MK) //Ps2 Keyboard and Mouse Enable
+{
+  If (LEqual(BDID,BoardIdGalagoPro3))
+  {
+Return(0x000F)
+  }
 }
   }
   Return(0x)
-- 
2.16.2.windows.1


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

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

[edk2-devel] [edk2-platforms][PATCH V2 01/15] Platform/Intel: Remove N1xxWU board build option

2019-09-24 Thread Kubacki, Michael A

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

The N1xxWU board contents will be moved to KabylakeOpenBoardPkg
to reduce code duplication between ClevoOpenBoardPkg and
KabylakeOpenBoardPkg.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 
---
 Platform/Intel/build.cfg | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Platform/Intel/build.cfg b/Platform/Intel/build.cfg
index 75cb446aa5..04e8f4fa64 100644
--- a/Platform/Intel/build.cfg
+++ b/Platform/Intel/build.cfg
@@ -55,6 +55,4 @@ NUMBER_OF_PROCESSORS = 0
 BoardMtOlympus = PurleyOpenBoardPkg/BoardMtOlympus/build_config.cfg
 BoardX58Ich10 = SimicsOpenBoardPkg/BoardX58Ich10/build_config.cfg
 KabylakeRvp3 = KabylakeOpenBoardPkg/KabylakeRvp3/build_config.cfg
-N1xxWU = ClevoOpenBoardPkg/N1xxWU/build_config.cfg
 WhiskeylakeURvp = WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/build_config.cfg
-
-- 
2.16.2.windows.1


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

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

[edk2-devel] [edk2-platforms][PATCH V2 08/15] KabylakeOpenBoardPkg/GalagoPro3: Add headers

2019-09-24 Thread Kubacki, Michael A

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

Adds the Galago Pro 3 board ID header file.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 
---
 Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h | 13 
+
 1 file changed, 13 insertions(+)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h 
b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h
new file mode 100644
index 00..5999f18edf
--- /dev/null
+++ b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h
@@ -0,0 +1,13 @@
+/** @file
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef _GALAGO_PRO_3_ID_H_
+#define _GALAGO_PRO_3_ID_H_
+
+#define BoardIdGalagoPro3 0x60
+
+#endif
-- 
2.16.2.windows.1


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

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

[edk2-devel] [edk2-platforms][PATCH V2 03/15] ClevoOpenBoardPkg: Remove global files and references

2019-09-24 Thread Kubacki, Michael A

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

Remove references to ClevoOpenBoardPkg external to the package
since the package is now removed.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Ankit Sinha 
Cc: Jeremy Soller 
Signed-off-by: Michael Kubacki 
---
 Maintainers.txt  |  5 -
 Platform/Intel/Readme.md | 18 --
 Readme.md|  1 -
 3 files changed, 24 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index c04cc23680..a30ee2f602 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -82,11 +82,6 @@ Platform/Intel/UserInterfaceFeaturePkg
 M: Dandan Bi 
 R: Liming Gao 
 
-Platform/Intel/ClevoOpenBoardPkg
-M: Michael Kubacki 
-M: Ankit Sinha 
-M: Nate DeSimone 
-
 Platform/Intel/KabylakeOpenBoardPkg
 M: Chasel Chiu 
 M: Michael Kubacki 
diff --git a/Platform/Intel/Readme.md b/Platform/Intel/Readme.md
index 2575d4ec52..6a9b1d2e00 100644
--- a/Platform/Intel/Readme.md
+++ b/Platform/Intel/Readme.md
@@ -53,7 +53,6 @@ A UEFI firmware implementation using MinPlatformPkg is 
constructed using the fol
 
 
 ## Board Support
-* The `ClevoOpenBoardPkg` contains board implementations for Clevo systems.
 * The `KabylakeOpenBoardPkg` contains board implementations for Kaby Lake 
systems.
 * The `PurleyOpenBoardPkg` contains board implementations for Purley systems.
 * The `SimicsOpenBoardPkg` contains board implementations for the Simics 
hardware simulator.
@@ -84,15 +83,6 @@ A UEFI firmware implementation using MinPlatformPkg is 
constructed using the fol
 
||--||
 | Simics Quick Start Package| Nehalem  
  | SimicsOpenBoardPkg   | BoardX58Ich10  |
 
- System 76
-
-***Galago Pro Laptop***
-
-| Machine Name  | Supported Chipsets   
  | BoardPkg | Board Name |
-||--||
-| galp2 (Clevo N130BU)  | Kaby Lake
  | ClevoOpenBoardPkg| N1xxWU |
-| galp3 & galp3-b (Clevo N1xxWU series) | Kaby Lake Refresh
  | ClevoOpenBoardPkg| N1xxWU |
-
 ## Board Package Organization
 The board package follows the standard EDK II package structure with the 
following additional elements and guidelines:
 * Only code usable across more than one board at the root level.
@@ -226,11 +216,6 @@ return back to the minimum platform caller.
   |   ||--build_bios.py: Main build script. Generic 
pre-build, build,
   |   || post-build, and clean 
functions.
   |   ||
-  |   ||--ClevoOpenBoardPkg
-  |   |||--N1xxWU
-  |   |||---build_config.cfg: N1xxWU 
specific build
-  |   ||  settings 
environment variables.
-  |   ||
   |   ||--KabylakeOpenBoardPkg
   |   |||--KabylakeRvp3
   |   ||  |---build_config.cfg: 
KabylakeRvp3 specific
@@ -277,9 +262,6 @@ errors.
 
 ### **Known limitations**
 
-**ClevoOpenBoardPkg**
-1. The firmware project has not been tested on the Galago Pro 3B.
-
 **KabylakeOpenBoardPkg**
 1. This firmware project has only been tested for Microsoft Windows 10 x64 
boot with AHCI mode and Integrated Graphic
Device.
diff --git a/Readme.md b/Readme.md
index e4f211eee6..efdbe8523f 100644
--- a/Readme.md
+++ b/Readme.md
@@ -225,7 +225,6 @@ they will be documented with the platform.
 
 ## Intel
 ### [Minimum Platforms](Platform/Intel/Readme.md)
-* [Clevo](Platform/Intel/ClevoOpenBoardPkg)
 * [Kaby Lake](Platform/Intel/KabylakeOpenBoardPkg)
 * [Purley](Platform/Intel/PurleyOpenBoardPkg)
 * [Whiskey Lake](Platform/Intel/WhiskeylakeOpenBoardPkg)
-- 
2.16.2.windows.1


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

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

Re: [edk2-devel] [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls

2019-09-24 Thread Laszlo Ersek

On 09/23/19 17:08, Philippe Mathieu-Daudé wrote:
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>> The last parameter of ReserveResourceInGcd() is "ImageHandle", forwarded
>> in turn to gDS->AllocateMemorySpace() or gDS->AllocateIoSpace() as "owner"
>> image handle.
>>
>> But BlDxeEntryPoint() passes "SystemTable" as "ImageHandle".
>>
>> Compilers have not flagged it because EFI_HANDLE (the type of
>> "ImageHandle") is unfortunately specified as (VOID*), and
>> (EFI_SYSTEM_TABLE*) converts to (VOID*) silently.
>>
>> Hand the entry point function's "ImageHandle" parameter to
>> ReserveResourceInGcd(). This fixes an actual bug.
> 
> Wow very buggy, so I assume this is mostly dead code, right?

Not necessarily; as long as noone tries to use the "owner" image handle
in practice, the issue may remain dormant.

Thanks
Laszlo

>> Cc: Benjamin You 
>> Cc: Guo Dong 
>> Cc: Maurice Ma 
>> Signed-off-by: Laszlo Ersek 
>> ---
>>
>> Notes:
>> build-tested only
>>
>>  UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c 
>> b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
>> index bcee4cd9bc41..28dfc8fc5545 100644
>> --- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
>> +++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
>> @@ -106,10 +106,10 @@ BlDxeEntryPoint (
>>//
>>// Report MMIO/IO Resources
>>//
>> -  Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 
>> 0xFEC0, SIZE_4KB, 0, SystemTable); // IOAPIC
>> +  Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 
>> 0xFEC0, SIZE_4KB, 0, ImageHandle); // IOAPIC
>>ASSERT_EFI_ERROR (Status);
>>
>> -  Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 
>> 0xFED0, SIZE_1KB, 0, SystemTable); // HPET
>> +  Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 
>> 0xFED0, SIZE_1KB, 0, ImageHandle); // HPET
>>ASSERT_EFI_ERROR (Status);
>>
>>//
>>
> 
> Reviewed-by: Philippe Mathieu-Daude 
> 


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

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

Re: [edk2-devel] [PATCH 10/35] MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call

2019-09-24 Thread Laszlo Ersek

On 09/23/19 13:45, Philippe Mathieu-Daudé wrote:
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>> The HiiConstructConfigHdr() function takes the "DriverHandle" parameter in
>> order to fetch the device path from it, and then turn the device path into
>> PATH routing information.
>>
>> The HiiConstructConfigHdr() function is called from
>> VariableCleanupHiiExtractConfig(), which is only installed when "Type" is
>> "VarCleanupManually" in PlatformVarCleanup().
>>
>> In that case, we create "Private->DriverHandle" as a new handle, and
>> install "mVarCleanupHiiVendorDevicePath" on it. Then we pass
>> "Private->DriverHandle" to HiiAddPackages(), which consumes the device
>> path for routing purposes.
>>
>> It follows that the "DriverHandle" argument pased to
> 
> "passed"

Good catch, thanks! (For the other reviews as well, of course!)
Laszlo

> 
>> HiiConstructConfigHdr() should be the same driver handle, for matching
>> routing.
>>
>> Currently we pass "Private->HiiHandle", which is clearly a typo, because
>> it is the return value of HiiAddPackages(), and stands for the published
>> HII package list.
> 
> Phew...
> 
>> Therefore this patch addresses an actual bug.
>>
>> The typo has not been flagged by compilers because the UEFI spec
>> regrettably defines both EFI_HANDLE and EFI_HII_HANDLE as (VOID*).
>>
>> Cc: Hao A Wu 
>> Cc: Jian J Wang 
>> Cc: Liming Gao 
>> Signed-off-by: Laszlo Ersek 
>> ---
>>
>> Notes:
>> build-tested only
>>
>>  MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c 
>> b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
>> index 968c044a316a..3875d614bb41 100644
>> --- a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
>> +++ b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
>> @@ -609,7 +609,11 @@ VariableCleanupHiiExtractConfig (
>>  // Allocate and fill a buffer large enough to hold the  
>> template
>>  // followed by "=0=" followed by a 
>> Null-terminator.
>>  //
>> -ConfigRequestHdr = HiiConstructConfigHdr (, 
>> mVarStoreName, Private->HiiHandle);
>> +ConfigRequestHdr = HiiConstructConfigHdr (
>> + ,
>> + mVarStoreName,
>> + Private->DriverHandle
>> + );
>>  Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);
>>  ConfigRequest = AllocateZeroPool (Size);
>>  ASSERT (ConfigRequest != NULL);
>>
> 
> Reviewed-by: Philippe Mathieu-Daude 
> 


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

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

Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin maintainers to EDK II Releases section

2019-09-24 Thread Laszlo Ersek

Hi Liming,

On 09/24/19 03:19, Liming Gao wrote:
> ShellBinPkg is generated for each edk2 stable tag release.
> 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Signed-off-by: Liming Gao 
> ---
>  Maintainers.txt | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index f348d70df3..f75b35d5a8 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -82,6 +82,12 @@ EDK II Releases:
>  W: 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
>  M: Liming Gao 
>  
> +W: 
> https://github.com/tianocore/edk2/releases/download/edk2-stable20/ShellBinPkg.zip

I'm not a fan of this link. It contains "", therefore it cannot work
with a simple click (or copy & paste). And it's not easy to notice the
"" part, and to substitute a valid stable tag identifier for it.

All the links we provide should work without manual tweaking, in my
opinion. They might not provide an immediately downloadable file (which
is fine with me), but they should not result in a 404.

How about the following:

UEFI Shell Binaries (ShellBinPkg.zip) from EDK II Releases:
---
W: https://github.com/tianocore/edk2/releases/
M: ...
M: ...
M: ...
M: ...

This allows users to go to the releases page, and search that page for
"ShellBinPkg.zip".

For me, the "Assets" block of the latest release is open immediately,
upon loading the page, and so searching the page for "ShellBinPkg.zip"
provides a hit at once. If a user wants an older build, they can locate
the Assets blocks under older releases, and look for "ShellBinPkg.zip"
there.

Thanks
Laszlo

> +M: Ray Ni   (Ia32/X64)
> +M: Zhichao Gao (Ia32/X64)
> +M: Leif Lindholm(ARM/AArch64)
> +M: Ard Biesheuvel  (ARM/AArch64)
> +
>  EDK II Architectures:
>  -
>  ARM, AARCH64
> @@ -421,13 +427,6 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
>  M: Ray Ni 
>  M: Zhichao Gao 
>  
> -Maintainers for stable Shell binaries generation
> -when need to publish Shell binaries with edk2 release:
> -M: Ray Ni   (Ia32/X64)
> -M: Zhichao Gao (Ia32/X64)
> -M: Leif Lindholm(ARM/AArch64)
> -M: Ard Biesheuvel  (ARM/AArch64)
> -
>  SignedCapsulePkg
>  F: SignedCapsulePkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> 

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

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

[edk2-devel] [PATCH] WinHost: Add SimplePointer support

2019-09-24 Thread Marvin Häuser

From: Marvin Haeuser 

Catch WM mouse events and expose them via the SimplePointer protocol.

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Signed-off-by: Marvin Haeuser 
---
 EmulatorPkg/Win/Host/WinGopInput.c  | 25 ++--
 EmulatorPkg/Win/Host/WinGopScreen.c | 41 
 EmulatorPkg/Win/Host/WinGop.h   |  5 +++
 EmulatorPkg/Win/Host/WinInclude.h   |  1 +
 4 files changed, 69 insertions(+), 3 deletions(-)

diff --git a/EmulatorPkg/Win/Host/WinGopInput.c 
b/EmulatorPkg/Win/Host/WinGopInput.c
index 0e8d11fc57ac..312a549847c5 100644
--- a/EmulatorPkg/Win/Host/WinGopInput.c
+++ b/EmulatorPkg/Win/Host/WinGopInput.c
@@ -409,9 +409,12 @@ WinNtWndCheckPointer (
 

   Private = GRAPHICS_PRIVATE_DATA_FROM_THIS (GraphicsIo);

 

-  return EFI_NOT_READY;

-}

+  if (!Private->PointerStateChanged) {

+return EFI_NOT_READY;

+  }

 

+  return EFI_SUCCESS;

+}

 

 EFI_STATUS

 EFIAPI

@@ -424,5 +427,21 @@ WinNtWndGetPointerState (
 

   Private = GRAPHICS_PRIVATE_DATA_FROM_THIS (GraphicsIo);

 

-  return EFI_NOT_READY;

+  if (!Private->PointerStateChanged) {

+return EFI_NOT_READY;

+  }

+

+  State->RelativeMovementX = Private->PointerState.RelativeMovementX;

+  State->RelativeMovementY = Private->PointerState.RelativeMovementY;

+  State->RelativeMovementZ = Private->PointerState.RelativeMovementZ;

+  State->LeftButton= Private->PointerState.LeftButton;

+  State->RightButton   = Private->PointerState.RightButton;

+

+  Private->PointerState.RelativeMovementX = 0;

+  Private->PointerState.RelativeMovementY = 0;

+  Private->PointerState.RelativeMovementZ = 0;

+

+  Private->PointerStateChanged = FALSE;

+

+  return EFI_SUCCESS;

 }

diff --git a/EmulatorPkg/Win/Host/WinGopScreen.c 
b/EmulatorPkg/Win/Host/WinGopScreen.c
index 8f42606823f1..fa34596497f8 100644
--- a/EmulatorPkg/Win/Host/WinGopScreen.c
+++ b/EmulatorPkg/Win/Host/WinGopScreen.c
@@ -399,6 +399,8 @@ WinNtGopThreadWindowProc (
   LPARAMIndex;

   EFI_INPUT_KEY Key;

   BOOLEAN   AltIsPress;

+  INT32 PosX;

+  INT32 PosY;

 

   //

   // Use mTlsIndex global to get a Thread Local Storage version of Private.

@@ -527,6 +529,45 @@ WinNtGopThreadWindowProc (
 WinNtGopConvertParamToEfiKeyShiftState (Private, , , FALSE);

 return 0;

 

+  case WM_MOUSEMOVE:

+PosX = GET_X_LPARAM (lParam);

+PosY = GET_Y_LPARAM (lParam);

+

+if (Private->PointerPreviousX != PosX) {

+  Private->PointerState.RelativeMovementX += (PosX - 
Private->PointerPreviousX);

+  Private->PointerPreviousX= PosX;

+  Private->PointerStateChanged = TRUE;

+}

+

+if (Private->PointerPreviousY != PosY) {

+  Private->PointerState.RelativeMovementY += (PosY - 
Private->PointerPreviousY);

+  Private->PointerPreviousY= PosY;

+  Private->PointerStateChanged = TRUE;

+}

+

+Private->PointerState.RelativeMovementZ  = 0;

+return 0;

+

+  case WM_LBUTTONDOWN:

+Private->PointerState.LeftButton = TRUE;

+Private->PointerStateChanged = TRUE;

+return 0;

+

+  case WM_LBUTTONUP:

+Private->PointerState.LeftButton = FALSE;

+Private->PointerStateChanged = TRUE;

+return 0;

+

+  case WM_RBUTTONDOWN:

+Private->PointerState.RightButton = TRUE;

+Private->PointerStateChanged  = TRUE;

+return 0;

+

+  case WM_RBUTTONUP:

+Private->PointerState.RightButton = FALSE;

+Private->PointerStateChanged  = TRUE;

+return 0;

+

   case WM_CLOSE:

 //

 // This close message is issued by user, core is not aware of this,

diff --git a/EmulatorPkg/Win/Host/WinGop.h b/EmulatorPkg/Win/Host/WinGop.h
index aa41db6dbc8c..5943ca93b22f 100644
--- a/EmulatorPkg/Win/Host/WinGop.h
+++ b/EmulatorPkg/Win/Host/WinGop.h
@@ -22,6 +22,7 @@ Abstract:
 

 #include 

 #include 

+#include 

 #include 

 #include 

 #include 

@@ -109,6 +110,10 @@ typedef struct {
   BOOLEAN   ScrollLock;

   BOOLEAN   CapsLock;

   BOOLEAN   IsPartialKeySupport;

+  INT32 PointerPreviousX;

+  INT32 PointerPreviousY;

+  BOOLEAN   PointerStateChanged;

+  EFI_SIMPLE_POINTER_STATE  PointerState;

 } GRAPHICS_PRIVATE_DATA;

 #define GRAPHICS_PRIVATE_DATA_SIGNATURE  SIGNATURE_32 ('g', 'f', 'x', 'd')

 #define GRAPHICS_PRIVATE_DATA_FROM_THIS(a)  \

diff --git a/EmulatorPkg/Win/Host/WinInclude.h 
b/EmulatorPkg/Win/Host/WinInclude.h
index ae02770d9fb0..8a9ae7d7465b 100644
--- a/EmulatorPkg/Win/Host/WinInclude.h
+++ b/EmulatorPkg/Win/Host/WinInclude.h
@@ -40,6 +40,7 @@ typedef UINT32 size_t ;
 #endif

 

 #include "windows.h"

+#include "windowsx.h"

 

 #undef GUID

 #undef _LIST_ENTRY

-- 
2.23.0.windows.1


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

[edk2-devel] [PATCH] MdeModulePkg/FrameBufferBltLib: Correctly consider SourceX

2019-09-24 Thread Marvin Häuser

From: Marvin Haeuser 

Currently, SourceX is not considered in the BufferToVideo operation
when the 8-bit pixel format is used. Correctly add the resulting
offset to prevent image corruption.

Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c 
b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
index 47c5326e9958..a084cc81d32e 100644
--- a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
+++ b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
@@ -504,7 +504,7 @@ FrameBufferBltLibBufferToVideo (
 Destination = Configure->FrameBuffer + Offset;

 

 if (Configure->PixelFormat == PixelBlueGreenRedReserved8BitPerColor) {

-  Source = (UINT8 *) BltBuffer + (SrcY * Delta);

+  Source = (UINT8 *) BltBuffer + (SrcY * Delta) + (SourceX * sizeof 
(EFI_GRAPHICS_OUTPUT_BLT_PIXEL));

 } else {

   for (IndexX = 0; IndexX < Width; IndexX++) {

 Blt =

-- 
2.23.0.windows.1


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

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

Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin maintainers to EDK II Releases section

2019-09-24 Thread Laszlo Ersek

On 09/24/19 12:41, Philippe Mathieu-Daudé wrote:
> Hi Liming,
> 
> On 9/24/19 3:19 AM, Liming Gao wrote:
>> ShellBinPkg is generated for each edk2 stable tag release.
>>
>> Cc: Andrew Fish 
>> Cc: Laszlo Ersek 
>> Cc: Leif Lindholm 
>> Cc: Michael D Kinney 
>> Signed-off-by: Liming Gao 
>> ---
>>  Maintainers.txt | 13 ++---
>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/Maintainers.txt b/Maintainers.txt
>> index f348d70df3..f75b35d5a8 100644
>> --- a/Maintainers.txt
>> +++ b/Maintainers.txt
>> @@ -82,6 +82,12 @@ EDK II Releases:
>>  W: 
>> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
>>  M: Liming Gao 
>>
> 
> Shouldn't you keep the F: tag too? Maybe:
> 
>  ShellPkg
>  (stable)
>  F: ShellPkg/

I think we should keep "F:" only if the related "M:" entries work as
expected, with the "BaseTools/Scripts/GetMaintainer.py" script.

(I haven't checked.)

Thanks
Laszlo

> 
> 
>> +W: 
>> https://github.com/tianocore/edk2/releases/download/edk2-stable20/ShellBinPkg.zip
>> +M: Ray Ni   (Ia32/X64)
>> +M: Zhichao Gao (Ia32/X64)
>> +M: Leif Lindholm(ARM/AArch64)
>> +M: Ard Biesheuvel  (ARM/AArch64)
>> +
>>  EDK II Architectures:
>>  -
>>  ARM, AARCH64
>> @@ -421,13 +427,6 @@ W: 
>> https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
>>  M: Ray Ni 
>>  M: Zhichao Gao 
>>
>> -Maintainers for stable Shell binaries generation
>> -when need to publish Shell binaries with edk2 release:
>> -M: Ray Ni   (Ia32/X64)
>> -M: Zhichao Gao (Ia32/X64)
>> -M: Leif Lindholm(ARM/AArch64)
>> -M: Ard Biesheuvel  (ARM/AArch64)
>> -
>>  SignedCapsulePkg
>>  F: SignedCapsulePkg/
>>  W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
>>


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

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

Re: [edk2-devel] [PATCH 6/7] OvmfPkg: strip trailing whitespace

2019-09-24 Thread Laszlo Ersek

On 09/20/19 12:24, Leif Lindholm wrote:
> 
> On Fri, Sep 20, 2019 at 08:13:36AM +0200, Laszlo Ersek wrote:
>> On 09/19/19 20:06, Leif Lindholm wrote:
>>> Cc: Jordan Justen 
>>> Cc: Laszlo Ersek 
>>> Cc: Ard Biesheuvel 
>>> Cc: Anthony Perard 
>>> Cc: Julien Grall 
>>> Cc: David Woodhouse 
>>> Signed-off-by: Leif Lindholm 
>>> ---
>>>  OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c |   4 ++--
>>>  OvmfPkg/AcpiPlatformDxe/Xen.c  |   8 
>>>  OvmfPkg/AcpiTables/Facs.aslc   |   6 +++---
>>>  OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr  |  18 
>>> +-
>>>  OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_32.h |   4 ++--
>>>  OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_64.h |   4 ++--
>>>  OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen.h|   4 ++--
>>>  OvmfPkg/Include/IndustryStandard/Xen/hvm/params.h  |   2 +-
>>>  OvmfPkg/Include/IndustryStandard/Xen/io/protocols.h|   2 +-
>>>  OvmfPkg/Include/IndustryStandard/Xen/io/ring.h |  34 
>>> +-
>>>  OvmfPkg/Include/IndustryStandard/Xen/memory.h  |   4 ++--
>>>  OvmfPkg/Include/IndustryStandard/Xen/xen-compat.h  |   4 ++--
>>>  OvmfPkg/Include/IndustryStandard/Xen/xen.h |  10 +-
>>>  OvmfPkg/Include/Register/QemuSmramSaveStateMap.h   |   2 +-
>>>  OvmfPkg/Library/DxePciLibI440FxQ35/PciLib.c|  12 
>>> ++--
>>>  OvmfPkg/Library/LockBoxLib/LockBoxDxe.c|   2 +-
>>>  OvmfPkg/Library/LockBoxLib/LockBoxLib.c|   2 +-
>>>  OvmfPkg/Library/LockBoxLib/LockBoxLib.h|   2 +-
>>>  OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.c  |   4 ++--
>>>  OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c|   2 +-
>>>  OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.c|   2 +-
>>>  OvmfPkg/PlatformPei/Xen.c  |   2 +-
>>>  OvmfPkg/SataControllerDxe/ComponentName.c  |   6 +++---
>>>  OvmfPkg/SataControllerDxe/SataController.c | 214 
>>> +++---
>>>  OvmfPkg/SataControllerDxe/SataController.h | 208 
>>> 
>>
>> (did you forget --stat-graph-width=20?)
> 
> Hmm...
> *scratches head*
> First of all, I saw that before sending out and didn't even reflect on
> it. Clearly past git-send-email-o-clock.
> 
> Secondly, I have
> [diff]
> statGraphWidth = 20
> in .git/config from running SetupGit.py.
> 
> Oh, rubbish. From git-diff manpage:
> ---
> The width of the graph part can be limited by using
> --stat-graph-width= (affects all commands generating a stat
> graph) or by setting diff.statGraphWidth= (does not affect git
> format-patch).
> ---
> I had missed that bit. So yeah, that setting in SetupGit.py is
> completely meaningless.
> (Why would you give those two different code paths?!?)

Right, no clue. It's pretty annoying.

> 
> Which given we already can't set --stat ...
> Do you think it might be a good idea to set up a few standard aliases?

Perhaps. Either way, it is asking people to do something "extra", and
then I like that "extra" to be "portable" to other projects.
"--stat-graph-width=..." is portable like that, an alias wouldn't be.

Not a strong preference in either direction from me, though.

Thanks!
Laszlo

> 
>>>  OvmfPkg/SataControllerDxe/SataControllerDxe.inf|   6 +++---
>>>  OvmfPkg/Sec/SecMain.c  |  34 
>>> +-
>>>  27 files changed, 301 insertions(+), 301 deletions(-)
>>
>> I've checked this patch with "git show -b" (--> nothing) and "git show
>> --word-diff" (--> output consists purely of context).
>>
>> Reviewed-by: Laszlo Ersek 
> 
> Thanks!
> 
> /
> Leif
> 


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

View/Reply Online (#47967): https://edk2.groups.io/g/devel/message/47967
Mute This Topic: https://groups.io/mt/34202575/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 Base.h: Define STATIC_ASSERT macro as empty for EBC arch

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/24/19 5:05 PM, Liming Gao wrote:
> EBC compiler doesn't support C11 static_assert macro.
> So, define STATIC_ASSERT as empty to pass EBC arch build.
> STATIC_ASSERT macro is introduced @204ae9da230ecbf0910c21acac7aa5d5e8cbb8d0
> 
> Cc: Michael D Kinney 
> Signed-off-by: Liming Gao 
> ---
>  MdePkg/Include/Base.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
> index ed85b98318..70e4d8daf1 100644
> --- a/MdePkg/Include/Base.h
> +++ b/MdePkg/Include/Base.h
> @@ -799,12 +799,15 @@ typedef UINTN  *BASE_LIST;
>@param  Message Raised compiler diagnostic message when expression is 
> false.
>
>  **/
> -#ifdef _MSC_EXTENSIONS
> +#ifdef MDE_CPU_EBC
> +  #define STATIC_ASSERT(Expression, Message)
> +#elif _MSC_EXTENSIONS
>#define STATIC_ASSERT static_assert
>  #else
>#define STATIC_ASSERT _Static_assert
>  #endif
>
> +
>  //
>  // Verify that ProcessorBind.h produced UEFI Data Types that are compliant 
> with
>  // Section 2.3.1 of the UEFI 2.3 Specification.
> 

Reviewed-by: Philippe Mathieu-Daude 


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

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

Re: [edk2-devel] [PATCH 28/35] ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> The ShellCommandRunConnect() function passes EFI_HANDLE -- (VOID*) --
> objects to ConvertAndConnectControllers(), and
> ConvertAndConnectControllers() passes those to gBS->OpenProtocol().
> 
> Accordingly, ConvertAndConnectControllers() should specify EFI_HANDLE
> parameter types, not (EFI_HANDLE*) -- (VOID**) -- types.
> 
> This typo is masked because (VOID*) converts to and from any
> pointer-to-object type silently.
> 
> Note that functionally speaking there is no problem, so this patch does
> not change beavior, only cleans up the code.
> 
> Cc: Jaben Carsey 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> tested with "connect -r"
> 
>  ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c 
> b/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
> index 359394dfd291..3f4e132674ea 100644
> --- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
> +++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
> @@ -346,8 +346,8 @@ ShellConnectFromDevPaths (
>  **/
>  EFI_STATUS
>  ConvertAndConnectControllers (
> -  IN EFI_HANDLE *Handle1 OPTIONAL,
> -  IN EFI_HANDLE *Handle2 OPTIONAL,
> +  IN EFI_HANDLE Handle1 OPTIONAL,
> +  IN EFI_HANDLE Handle2 OPTIONAL,
>IN CONST BOOLEAN  Recursive,
>IN CONST BOOLEAN  Output
>)
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [PATCH 13/35] MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx()

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> Clean up two issues around FindFileEx():
> 
> - The "AprioriFile" parameter's type differs between the function
>   declaration and the function definition. The correct type is
>   (EFI_PEI_FILE_HANDLE*).
> 
> - "FfsFileHeader" has type (EFI_FFS_FILE_HEADER*); for clarity, we should
>   cast it explicitly to EFI_PEI_FILE_HANDLE when assigning it to
>   (*AprioriFile).
> 
> This is a semantic cleanup, there is no functional change.
> 
> Cc: Dandan Bi 
> Cc: Hao A Wu 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> lightly tested: OVMF uses APRIORI PEI in the FDF files
> 
>  MdeModulePkg/Core/Pei/FwVol/FwVol.h | 2 +-
>  MdeModulePkg/Core/Pei/FwVol/FwVol.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.h 
> b/MdeModulePkg/Core/Pei/FwVol/FwVol.h
> index 4082cfbec1f8..ca80e84e0fcb 100644
> --- a/MdeModulePkg/Core/Pei/FwVol/FwVol.h
> +++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.h
> @@ -299,7 +299,7 @@ FindFileEx (
>IN  CONST EFI_GUID *FileName,   OPTIONAL
>INEFI_FV_FILETYPE  SearchType,
>IN OUTEFI_PEI_FILE_HANDLE  *FileHandle,
> -  IN OUTEFI_PEI_FV_HANDLE*AprioriFile  OPTIONAL
> +  IN OUTEFI_PEI_FILE_HANDLE  *AprioriFile  OPTIONAL
>);
>  
>  /**
> diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.c 
> b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> index 709db00694c2..f4642c47c13a 100644
> --- a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> +++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> @@ -407,7 +407,7 @@ FindFileEx (
>  } else if (AprioriFile != NULL) {
>if (FfsFileHeader->Type == EFI_FV_FILETYPE_FREEFORM) {
>  if (CompareGuid (>Name, 
> )) {
> -  *AprioriFile = FfsFileHeader;
> +  *AprioriFile = (EFI_PEI_FILE_HANDLE)FfsFileHeader;
>  }
>}
>  }
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> The HandleProtocol() boot service takes an EFI_HANDLE, not an
> (EFI_HANDLE*). Remove the bogus cast in the
> InternalImageHandleToFvHandle() function.
> 
> This is a semantic cleanup; there is no change in behavior.
> 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> lightly tested, most probably: it's practically impossible to build a
> platform without consuming DxeServicesLib
> 
>  MdePkg/Library/DxeServicesLib/DxeServicesLib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c 
> b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
> index c416b2dd8c65..0735b2f80400 100644
> --- a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
> +++ b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
> @@ -49,7 +49,7 @@ InternalImageHandleToFvHandle (
>ASSERT (ImageHandle != NULL);
>  
>Status = gBS->HandleProtocol (
> - (EFI_HANDLE *) ImageHandle,
> + ImageHandle,
>   ,
>   (VOID **) 
>   );
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin maintainers to EDK II Releases section

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/24/19 5:17 PM, Gao, Liming wrote:
>> -Original Message-
>> From: Philippe Mathieu-Daudé 
>> Sent: Tuesday, September 24, 2019 11:13 PM
>> To: Gao, Liming ; devel@edk2.groups.io; Leif Lindholm 
>> 
>> Cc: Andrew Fish ; Laszlo Ersek ; Kinney, 
>> Michael D 
>> Subject: Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin maintainers 
>> to EDK II Releases section
>>
>> On 9/24/19 5:08 PM, Gao, Liming wrote:
>>> Philipe:
>>>
 -Original Message-
 From: devel@edk2.groups.io  On Behalf Of Philippe 
 Mathieu-Daudé
 Sent: Tuesday, September 24, 2019 6:41 PM
 To: devel@edk2.groups.io; Gao, Liming ; Leif 
 Lindholm 
 Cc: Andrew Fish ; Laszlo Ersek ; 
 Kinney, Michael D 
 Subject: Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin 
 maintainers to EDK II Releases section

 Hi Liming,

 On 9/24/19 3:19 AM, Liming Gao wrote:
> ShellBinPkg is generated for each edk2 stable tag release.
>
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Signed-off-by: Liming Gao 
> ---
>  Maintainers.txt | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/Maintainers.txt b/Maintainers.txt
> index f348d70df3..f75b35d5a8 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -82,6 +82,12 @@ EDK II Releases:
>  W: 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
>  M: Liming Gao 
>

 Shouldn't you keep the F: tag too? Maybe:

  ShellPkg
  (stable)
  F: ShellPkg/

>>> ShellBinPkg doesn't exist in Edk2 repo. It will be generated for stable tag 
>>> release.
>>> Base on previous discussion, I list it into EDK II Releases section.
>>
>> I should have written "F: ShellBinPkg/", I was thinking someone run this
>> command in tarball extracted from stable:
>>
>> ./BaseTools/Scripts/GetMaintainer.py ShellBinPkg/...
> 
> GetMaintainer.py bases on git commit. But, there is no git commit for 
> ShellBinPkg. 
> So, the above command doesn't work. 

OK, thanks for clarifying!

> 
> Thanks
> Liming
>>
>>>
>>> Thanks
>>> Liming

> +W: 
> https://github.com/tianocore/edk2/releases/download/edk2-stable20/ShellBinPkg.zip
> +M: Ray Ni   (Ia32/X64)
> +M: Zhichao Gao (Ia32/X64)
> +M: Leif Lindholm(ARM/AArch64)
> +M: Ard Biesheuvel  (ARM/AArch64)
> +
>  EDK II Architectures:
>  -
>  ARM, AARCH64
> @@ -421,13 +427,6 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
>  M: Ray Ni 
>  M: Zhichao Gao 
>
> -Maintainers for stable Shell binaries generation
> -when need to publish Shell binaries with edk2 release:
> -M: Ray Ni   (Ia32/X64)
> -M: Zhichao Gao (Ia32/X64)
> -M: Leif Lindholm(ARM/AArch64)
> -M: Ard Biesheuvel  (ARM/AArch64)
> -
>  SignedCapsulePkg
>  F: SignedCapsulePkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
>

 
>>>

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

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

Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin maintainers to EDK II Releases section

2019-09-24 Thread Liming Gao



> -Original Message-
> From: Philippe Mathieu-Daudé 
> Sent: Tuesday, September 24, 2019 11:13 PM
> To: Gao, Liming ; devel@edk2.groups.io; Leif Lindholm 
> 
> Cc: Andrew Fish ; Laszlo Ersek ; Kinney, 
> Michael D 
> Subject: Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin maintainers 
> to EDK II Releases section
> 
> On 9/24/19 5:08 PM, Gao, Liming wrote:
> > Philipe:
> >
> >> -Original Message-
> >> From: devel@edk2.groups.io  On Behalf Of Philippe 
> >> Mathieu-Daudé
> >> Sent: Tuesday, September 24, 2019 6:41 PM
> >> To: devel@edk2.groups.io; Gao, Liming ; Leif 
> >> Lindholm 
> >> Cc: Andrew Fish ; Laszlo Ersek ; 
> >> Kinney, Michael D 
> >> Subject: Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin 
> >> maintainers to EDK II Releases section
> >>
> >> Hi Liming,
> >>
> >> On 9/24/19 3:19 AM, Liming Gao wrote:
> >>> ShellBinPkg is generated for each edk2 stable tag release.
> >>>
> >>> Cc: Andrew Fish 
> >>> Cc: Laszlo Ersek 
> >>> Cc: Leif Lindholm 
> >>> Cc: Michael D Kinney 
> >>> Signed-off-by: Liming Gao 
> >>> ---
> >>>  Maintainers.txt | 13 ++---
> >>>  1 file changed, 6 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/Maintainers.txt b/Maintainers.txt
> >>> index f348d70df3..f75b35d5a8 100644
> >>> --- a/Maintainers.txt
> >>> +++ b/Maintainers.txt
> >>> @@ -82,6 +82,12 @@ EDK II Releases:
> >>>  W: 
> >>> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
> >>>  M: Liming Gao 
> >>>
> >>
> >> Shouldn't you keep the F: tag too? Maybe:
> >>
> >>  ShellPkg
> >>  (stable)
> >>  F: ShellPkg/
> >>
> > ShellBinPkg doesn't exist in Edk2 repo. It will be generated for stable tag 
> > release.
> > Base on previous discussion, I list it into EDK II Releases section.
> 
> I should have written "F: ShellBinPkg/", I was thinking someone run this
> command in tarball extracted from stable:
> 
> ./BaseTools/Scripts/GetMaintainer.py ShellBinPkg/...

GetMaintainer.py bases on git commit. But, there is no git commit for 
ShellBinPkg. 
So, the above command doesn't work. 

Thanks
Liming
> 
> >
> > Thanks
> > Liming
> >>
> >>> +W: 
> >>> https://github.com/tianocore/edk2/releases/download/edk2-stable20/ShellBinPkg.zip
> >>> +M: Ray Ni   (Ia32/X64)
> >>> +M: Zhichao Gao (Ia32/X64)
> >>> +M: Leif Lindholm(ARM/AArch64)
> >>> +M: Ard Biesheuvel  (ARM/AArch64)
> >>> +
> >>>  EDK II Architectures:
> >>>  -
> >>>  ARM, AARCH64
> >>> @@ -421,13 +427,6 @@ W: 
> >>> https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
> >>>  M: Ray Ni 
> >>>  M: Zhichao Gao 
> >>>
> >>> -Maintainers for stable Shell binaries generation
> >>> -when need to publish Shell binaries with edk2 release:
> >>> -M: Ray Ni   (Ia32/X64)
> >>> -M: Zhichao Gao (Ia32/X64)
> >>> -M: Leif Lindholm(ARM/AArch64)
> >>> -M: Ard Biesheuvel  (ARM/AArch64)
> >>> -
> >>>  SignedCapsulePkg
> >>>  F: SignedCapsulePkg/
> >>>  W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> >>>
> >>
> >> 
> >

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

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

Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin maintainers to EDK II Releases section

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/24/19 5:08 PM, Gao, Liming wrote:
> Philipe:
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Philippe 
>> Mathieu-Daudé
>> Sent: Tuesday, September 24, 2019 6:41 PM
>> To: devel@edk2.groups.io; Gao, Liming ; Leif Lindholm 
>> 
>> Cc: Andrew Fish ; Laszlo Ersek ; Kinney, 
>> Michael D 
>> Subject: Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin maintainers 
>> to EDK II Releases section
>>
>> Hi Liming,
>>
>> On 9/24/19 3:19 AM, Liming Gao wrote:
>>> ShellBinPkg is generated for each edk2 stable tag release.
>>>
>>> Cc: Andrew Fish 
>>> Cc: Laszlo Ersek 
>>> Cc: Leif Lindholm 
>>> Cc: Michael D Kinney 
>>> Signed-off-by: Liming Gao 
>>> ---
>>>  Maintainers.txt | 13 ++---
>>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/Maintainers.txt b/Maintainers.txt
>>> index f348d70df3..f75b35d5a8 100644
>>> --- a/Maintainers.txt
>>> +++ b/Maintainers.txt
>>> @@ -82,6 +82,12 @@ EDK II Releases:
>>>  W: 
>>> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
>>>  M: Liming Gao 
>>>
>>
>> Shouldn't you keep the F: tag too? Maybe:
>>
>>  ShellPkg
>>  (stable)
>>  F: ShellPkg/
>>
> ShellBinPkg doesn't exist in Edk2 repo. It will be generated for stable tag 
> release. 
> Base on previous discussion, I list it into EDK II Releases section. 

I should have written "F: ShellBinPkg/", I was thinking someone run this
command in tarball extracted from stable:

./BaseTools/Scripts/GetMaintainer.py ShellBinPkg/...

> 
> Thanks
> Liming
>>
>>> +W: 
>>> https://github.com/tianocore/edk2/releases/download/edk2-stable20/ShellBinPkg.zip
>>> +M: Ray Ni   (Ia32/X64)
>>> +M: Zhichao Gao (Ia32/X64)
>>> +M: Leif Lindholm(ARM/AArch64)
>>> +M: Ard Biesheuvel  (ARM/AArch64)
>>> +
>>>  EDK II Architectures:
>>>  -
>>>  ARM, AARCH64
>>> @@ -421,13 +427,6 @@ W: 
>>> https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
>>>  M: Ray Ni 
>>>  M: Zhichao Gao 
>>>
>>> -Maintainers for stable Shell binaries generation
>>> -when need to publish Shell binaries with edk2 release:
>>> -M: Ray Ni   (Ia32/X64)
>>> -M: Zhichao Gao (Ia32/X64)
>>> -M: Leif Lindholm(ARM/AArch64)
>>> -M: Ard Biesheuvel  (ARM/AArch64)
>>> -
>>>  SignedCapsulePkg
>>>  F: SignedCapsulePkg/
>>>  W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
>>>
>>
>> 
> 

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

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

Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin maintainers to EDK II Releases section

2019-09-24 Thread Liming Gao

Philipe:

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Philippe 
> Mathieu-Daudé
> Sent: Tuesday, September 24, 2019 6:41 PM
> To: devel@edk2.groups.io; Gao, Liming ; Leif Lindholm 
> 
> Cc: Andrew Fish ; Laszlo Ersek ; Kinney, 
> Michael D 
> Subject: Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin maintainers 
> to EDK II Releases section
> 
> Hi Liming,
> 
> On 9/24/19 3:19 AM, Liming Gao wrote:
> > ShellBinPkg is generated for each edk2 stable tag release.
> >
> > Cc: Andrew Fish 
> > Cc: Laszlo Ersek 
> > Cc: Leif Lindholm 
> > Cc: Michael D Kinney 
> > Signed-off-by: Liming Gao 
> > ---
> >  Maintainers.txt | 13 ++---
> >  1 file changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index f348d70df3..f75b35d5a8 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -82,6 +82,12 @@ EDK II Releases:
> >  W: 
> > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
> >  M: Liming Gao 
> >
> 
> Shouldn't you keep the F: tag too? Maybe:
> 
>  ShellPkg
>  (stable)
>  F: ShellPkg/
> 
ShellBinPkg doesn't exist in Edk2 repo. It will be generated for stable tag 
release. 
Base on previous discussion, I list it into EDK II Releases section. 

Thanks
Liming
> 
> > +W: 
> > https://github.com/tianocore/edk2/releases/download/edk2-stable20/ShellBinPkg.zip
> > +M: Ray Ni   (Ia32/X64)
> > +M: Zhichao Gao (Ia32/X64)
> > +M: Leif Lindholm(ARM/AArch64)
> > +M: Ard Biesheuvel  (ARM/AArch64)
> > +
> >  EDK II Architectures:
> >  -
> >  ARM, AARCH64
> > @@ -421,13 +427,6 @@ W: 
> > https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
> >  M: Ray Ni 
> >  M: Zhichao Gao 
> >
> > -Maintainers for stable Shell binaries generation
> > -when need to publish Shell binaries with edk2 release:
> > -M: Ray Ni   (Ia32/X64)
> > -M: Zhichao Gao (Ia32/X64)
> > -M: Leif Lindholm(ARM/AArch64)
> > -M: Ard Biesheuvel  (ARM/AArch64)
> > -
> >  SignedCapsulePkg
> >  F: SignedCapsulePkg/
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> >
> 
> 


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

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

[edk2-devel] [Patch] MdePkg Base.h: Define STATIC_ASSERT macro as empty for EBC arch

2019-09-24 Thread Liming Gao

EBC compiler doesn't support C11 static_assert macro.
So, define STATIC_ASSERT as empty to pass EBC arch build.
STATIC_ASSERT macro is introduced @204ae9da230ecbf0910c21acac7aa5d5e8cbb8d0

Cc: Michael D Kinney 
Signed-off-by: Liming Gao 
---
 MdePkg/Include/Base.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index ed85b98318..70e4d8daf1 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -799,12 +799,15 @@ typedef UINTN  *BASE_LIST;
   @param  Message Raised compiler diagnostic message when expression is 
false.
 
 **/
-#ifdef _MSC_EXTENSIONS
+#ifdef MDE_CPU_EBC
+  #define STATIC_ASSERT(Expression, Message)
+#elif _MSC_EXTENSIONS
   #define STATIC_ASSERT static_assert
 #else
   #define STATIC_ASSERT _Static_assert
 #endif
 
+
 //
 // Verify that ProcessorBind.h produced UEFI Data Types that are compliant with
 // Section 2.3.1 of the UEFI 2.3 Specification.
-- 
2.13.0.windows.1


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

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

[edk2-devel] Upcoming Event: TianoCore Design / Bug Triage - EMEA - Wed, 09/25/2019 8:00am-9:00am #cal-reminder

2019-09-24 Thread devel@edk2.groups.io Calendar

*Reminder:* TianoCore Design / Bug Triage - EMEA

*When:* Wednesday, 25 September 2019, 8:00am to 9:00am, (GMT-07:00) America/Los 
Angeles

*Where:* https://zoom.us/j/695893389

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

*Organizer:* Stephano Cetola stephano.cet...@linux.intel.com ( 
stephano.cet...@linux.intel.com?subject=Re:%20Event:%20TianoCore%20Design%20%2F%20Bug%20Triage%20-%20EMEA
 )

*Description:*

Join Zoom Meeting

https://zoom.us/j/695893389

One tap mobile

+17207072699,,695893389# US

+16465588656,,695893389# US (New York)

Dial by your location

+1 720 707 2699 US

+1 646 558 8656 US (New York)

Meeting ID: 695 893 389

Find your local number: https://zoom.us/u/abOtdJckxL

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

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

Re: [edk2-devel] [RFC PATCH v2 03/44] OvmfPkg: Add support to perform SEV-ES initialization

2019-09-24 Thread Lendacky, Thomas

On 9/24/19 6:59 AM, Laszlo Ersek wrote:
> On 09/19/19 21:52, Lendacky, Thomas wrote:
>> From: Tom Lendacky 
>>
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
>>
>> When SEV-ES is active, then SEV is also active. Add support to the SEV
>> initialization function to also check for SEV-ES being active. If SEV-ES
>> is active, set the SEV-ES active PCD (PcdSevEsActive).
>>
>> Cc: Jordan Justen 
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Signed-off-by: Tom Lendacky 
>> ---
>>  OvmfPkg/OvmfPkgIa32.dsc |  3 +++
>>  OvmfPkg/OvmfPkgIa32X64.dsc  |  3 +++
>>  OvmfPkg/OvmfPkgX64.dsc  |  3 +++
>>  OvmfPkg/PlatformPei/PlatformPei.inf |  1 +
>>  OvmfPkg/PlatformPei/AmdSev.c| 26 ++
>>  5 files changed, 36 insertions(+)
>>
>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>> index 6ab730018694..0ce5c01722ef 100644
>> --- a/OvmfPkg/OvmfPkgIa32.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32.dsc
>> @@ -558,6 +558,9 @@ [PcdsDynamicDefault]
>># Set memory encryption mask
>>gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
>>  
>> +  # Set SEV-ES defaults
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSevEsActive|0
>> +
>>  !if $(SMM_REQUIRE) == TRUE
>>gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
>> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>> index f163aa267132..e7455e35a55d 100644
>> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
>> @@ -570,6 +570,9 @@ [PcdsDynamicDefault]
>># Set memory encryption mask
>>gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
>>  
>> +  # Set SEV-ES defaults
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSevEsActive|0
>> +
>>  !if $(SMM_REQUIRE) == TRUE
>>gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
>> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>> index fa98f16a3fb3..0b8305cd10a2 100644
>> --- a/OvmfPkg/OvmfPkgX64.dsc
>> +++ b/OvmfPkg/OvmfPkgX64.dsc
>> @@ -569,6 +569,9 @@ [PcdsDynamicDefault]
>># Set memory encryption mask
>>gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
>>  
>> +  # Set SEV-ES defaults
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSevEsActive|0
>> +
>>  !if $(SMM_REQUIRE) == TRUE
>>gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
>> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
>> b/OvmfPkg/PlatformPei/PlatformPei.inf
>> index d9fd9c8f05b3..2736347a2e03 100644
>> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
>> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
>> @@ -100,6 +100,7 @@ [Pcd]
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSevEsActive
> 
> (1) Can you add this next to
> "gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask"?

Will do.

> 
>>  
>>  [FixedPcd]
>>gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
>> diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
>> index 2ae8126ccf8a..7ae2f26a2ba7 100644
>> --- a/OvmfPkg/PlatformPei/AmdSev.c
>> +++ b/OvmfPkg/PlatformPei/AmdSev.c
>> @@ -19,6 +19,27 @@
>>  
>>  #include "Platform.h"
>>  
>> +/**
>> +
>> +  Initialize SEV-ES support if running an SEV-ES guest.
> 
> (2) s/an/in an/? (Just asking)

Yup. I'll change that to "running as an SEV-ES guest".

> 
>> +
>> +  **/
>> +STATIC
>> +VOID
>> +AmdSevEsInitialize (
>> +  VOID
>> +  )
>> +{
>> +  RETURN_STATUS PcdStatus;
>> +
>> +  if (!MemEncryptSevEsIsEnabled ()) {
>> +return;
>> +  }
>> +
>> +  PcdStatus = PcdSetBoolS (PcdSevEsActive, 1);
> 
> (3) Please write TRUE, not 1.

Will do.

Thanks,
Tom

> 
>> +  ASSERT_RETURN_ERROR (PcdStatus);
>> +}
>> +
>>  /**
>>  
>>Function checks if SEV support is available, if present then it sets
>> @@ -89,4 +110,9 @@ AmdSevInitialize (
>>EfiBootServicesData// MemoryType
>>);
>>}
>> +
>> +  //
>> +  // Check and perform SEV-ES initialization if required.
>> +  //
>> +  AmdSevEsInitialize ();
>>  }
>>
> 
> With (1) and (3) fixed:
> 
> Reviewed-by: Laszlo Ersek 
> 
> Thanks
> Laszlo
> 

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

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

Re: [edk2-devel] [RFC PATCH v2 00/44] SEV-ES guest support

2019-09-24 Thread Lendacky, Thomas

On 9/23/19 8:55 PM, Dong, Eric wrote:
> Hi Tom,

Hi Eric,

> 
> Thanks for you to contribute such a big changes. Seems like this is a big 
> changes for current code, can you help to do a design review in TianoCore 
> Design Meeting? It will be helpful for us to understand the code change and 
> review it.
> 
> Ray is the owner of that meeting, you can contact him for the arrangement of 
> your topic.

Thanks for the info, Eric.

Ray, I see on the TianoCore wiki that I should contact Stephano to be
added to the meeting agenda. Should I follow those directions?

Thanks,
Tom

> 
> Thanks,
> Eric
> 
>> -Original Message-
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Lendacky, Thomas
>> Sent: Saturday, September 21, 2019 3:25 AM
>> To: devel@edk2.groups.io
>> Cc: Justen, Jordan L ; Laszlo Ersek
>> ; Ard Biesheuvel ; Kinney,
>> Michael D ; Gao, Liming
>> ; Dong, Eric ; Ni, Ray
>> ; Singh, Brijesh ; You, Benjamin
>> ; Bi, Dandan ; Dong, Guo
>> ; Wu, Hao A ; Wang, Jian J
>> ; Ma, Maurice 
>> Subject: Re: [edk2-devel] [RFC PATCH v2 00/44] SEV-ES guest support
>>
>> On 9/19/19 2:52 PM, Lendacky, Thomas wrote:
>>> From: Tom Lendacky 
>>>
>>> This patch series provides support for running EDK2/OVMF under SEV-ES.
>>
>> I wanted to provide the full series so that everyone can see what is involved
>> with the support.
>>
>> Providing multiple, smaller series of patches might be easier to review.
>> If that is desired, any suggestions/recommendations on how to best approach
>> that would be great.
>>
>> Thanks,
>> Tom
>>
>>>
>>> Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on
>>> the SEV support to protect the guest register state from the
>>> hypervisor. See
>>> "AMD64 Architecture Programmer's Manual Volume 2: System
>> Programming",
>>> section "15.35 Encrypted State (SEV-ES)" [1].
>>>
>>> In order to allow a hypervisor to perform functions on behalf of a
>>> guest, there is architectural support for notifying a guest's
>>> operating system when certain types of VMEXITs are about to occur.
>>> This allows the guest to selectively share information with the
>>> hypervisor to satisfy the requested function. The notification is
>>> performed using a new exception, the VMM Communication exception
>>> (#VC). The information is shared through the Guest-Hypervisor
>> Communication Block (GHCB) using the VMGEXIT instruction.
>>> The GHCB format and the protocol for using it is documented in "SEV-ES
>>> Guest-Hypervisor Communication Block Standardization" [2].
>>>
>>> The main areas of the EDK2 code that are updated to support SEV-ES are
>>> around the exception handling support and the AP boot support.
>>>
>>> Exception support is required starting in Sec, continuing through Pei
>>> and into Dxe in order to handle #VC exceptions that are generated.
>>> Each AP requires it's own GHCB page as well as a page to hold values
>>> specific to that AP.
>>>
>>> AP booting poses some interesting challenges. The INIT-SIPI-SIPI
>>> sequence is typically used to boot the APs. However, the hypervisor is
>>> not allowed to update the guest registers. The GHCB document [2] talks
>>> about how SMP booting under SEV-ES is performed.
>>>
>>> Since the GHCB page must be a shared (unencrypted) page, the processor
>>> must be running in long mode in order for the guest and hypervisor to
>>> communicate with each other. As a result, SEV-ES is only supported
>>> under the X64 architecture.
>>>
>>> [1] https://www.amd.com/system/files/TechDocs/24593.pdf
>>> [2] https://developer.amd.com/wp-content/resources/56421.pdf
>>>
>>> ---
>>>
>>> These patches are based on commit:
>>> ada905ab5c0e ("MdeModulePkg DxeCore: Fix for missing Memory Attributes
>>> Table (MAT) update")
>>>
>>> A version of the tree can be found at:
>>> https://github.com/AMDESE/ovmf/tree/sev-es-v7
>>>
>>> Cc: Ard Biesheuvel 
>>> Cc: Benjamin You 
>>> Cc: Dandan Bi 
>>> Cc: Eric Dong 
>>> Cc: Guo Dong 
>>> Cc: Hao A Wu 
>>> Cc: Jian J Wang 
>>> Cc: Jordan Justen 
>>> Cc: Laszlo Ersek 
>>> Cc: Liming Gao 
>>> Cc: Maurice Ma 
>>> Cc: Michael D Kinney 
>>> Cc: Ray Ni 
>>>
>>> Changes since v1:
>>> - Patches reworked to be more specific to the component/area being
>> updated
>>>and order of definition/usage
>>> - Created a library for VMGEXIT-related functions to replace use of inline
>>>functions
>>> - Allocation method for GDT changed from AllocatePool to AllocatePages
>>> - Early caching only enabled for SEV-ES guests
>>> - Ensure AP loop mode set to halt loop mode for SEV-ES guests
>>> - Reserved SEC GHCB-related memory areas when S3 is enabled
>>>
>>> Tom Lendacky (44):
>>>MdePkg: Create PCDs to be used in support of SEV-ES
>>>OvmfPkg/MemEncryptSevLib: Add an SEV-ES guest indicator function
>>>OvmfPkg: Add support to perform SEV-ES initialization
>>>OvmfPkg/ResetVector: Add support for a 32-bit SEV check
>>>MdePkg: Add the MSR definition for the GHCB register
>>>OvmfPkg: Create a GHCB page

Re: [edk2-devel] [RFC] EDK II Continuous Integration Phase 1

2019-09-24 Thread Liming Gao

Mike:

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael D 
> Kinney
> Sent: Tuesday, September 24, 2019 1:44 AM
> To: Sean Brogan ; devel@edk2.groups.io; 
> r...@edk2.groups.io; Kinney, Michael D
> 
> Cc: Bret Barkelew 
> Subject: Re: [edk2-devel] [RFC] EDK II Continuous Integration Phase 1
> 
> Hi Sean,
> 
> For host based tests, I agree that VS2017 or VS2019
> would be a good choice.  Pick the one with the best
> coverage and easiest for developers to get feedback on
> the test results and test coverage.  That may be sufficient
> for automated CI tests.  Enabling other tool chains for
> host based testing will be required to support developers
> that implement unit tests and want to test them locally
> before adding to the automated CI tests.
> 
> For build tests, I think we need VS2015, VS2017, GCC,
> and XCODE5.  We can add VS2019 if there is a request to make
> that one of the fully validated tool chains for EDK II.
VS2019 tool chain has been added for IA32/X64/ARM/AARH64/EBC archs. 
CLANG9 tool chain for IA32/X64 will be added. I request to add CLANG9 build 
test. 

Thanks
Liming
> For pre-commit gates, we could choose to do build tests of
> only the libs/modules touched by the patch series.  Then
> perform complete package/platform build tests in a
> Daily/Weekly/Release scope.
> 
> We need to update the RFC with the specific tool chains and
> tool versions for both Host Based tests and Code Compilation
> Tests.  They are not the same.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Sean Brogan 
> > Sent: Friday, September 20, 2019 2:30 PM
> > To: Kinney, Michael D ;
> > devel@edk2.groups.io; r...@edk2.groups.io; Kinney,
> > Michael D 
> > Cc: Bret Barkelew 
> > Subject: RE: [edk2-devel] [RFC] EDK II Continuous
> > Integration Phase 1
> >
> > Currently it is building on Windows with VS2019.
> > VS2017 would be trivial but not worth it in my
> > perspective given how aligned the two are.   If you
> > really wanted to do a weekly or nightly build it could
> > be added to that but I have been focused on a PR build.
> > I have a pipeline for GCC on linux.  It doesn't'
> > support host based unit tests but I am working to get
> > the rest of the tests running.
> > I do not have a pipeline for Mac or LLVM/Clang.  That
> > would be next and I think your files below should help.
> >
> > To date we use PYTOOLs features to install our extra
> > tools.  This makes it super easy and works for both
> > local and server based builds.  It gives strong
> > versioning and management of that.  It also tracks
> > those versions and you can see them on every build in
> > the Built Tool Report artifact.   It can be downloaded
> > here for html version.
> > https://dev.azure.com/tianocore/edk2-ci-
> > play/_build/results?buildId=803=artifacts.
> > BUILD_TOOL_REPORT.html
> >
> > Here it is pasted as plain text below.  You can see the
> > iasl and nasm versions here.
> >
> > Key Value   Type
> > TOOL_CHAIN_TAG  VS2019  TOOL
> > VC Version  14.22.27905 TOOL
> > d:\a\1\s\Conf\build_rule.txt1.04INFO
> > d:\a\1\s\Conf\target.txt1.03INFO
> > d:\a\1\s\Conf\tools_def.txt 1.22INFO
> > iasl20190215.0.0INFO
> > Mu-Basetools2019.03.1   INFO
> > mu_nasm 2.14.02 INFO
> >
> >
> > Hope that helps.
> >
> > I would be happy to queue up this topic for next design
> > meeting and open it up to questions?  I hope others
> > would take a look prior to meeting.
> >
> > Thanks
> > Sean
> >
> >
> >
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Thursday, September 19, 2019 2:56 PM
> > To: devel@edk2.groups.io; Sean Brogan
> > ; r...@edk2.groups.io;
> > Kinney, Michael D 
> > Cc: Bret Barkelew 
> > Subject: RE: [edk2-devel] [RFC] EDK II Continuous
> > Integration Phase 1
> >
> > Hi Sean,
> >
> > Which OS/Compiler configurations are currently enabled
> > for the Code Compilation Test?
> >
> > I have been working on enabling multiple OS/Compiler
> > configurations in Azure Pipelines.  There are some
> > tools that need to be installed for each of these
> > environments.
> > Examples include NASM, iASL, Python.
> >
> > For the work you have done, how are these extra tools
> > installed?  Is it in the YML files or in the Python
> > scripts.
> >
> > One critical task is to identify the tools and their
> > specific versions that the CI system is configured to
> > use.
> > These configurations should be documented in a Wiki
> > page and updated as new tools are released and adopted
> > by EDK II.
> > The inventory of tools used to validate a release
> > should Also be documented in a release notes for a
> > stable tag.
> >
> > Here are the YML files that install the additional
> > tools required to support EDK II builds.  I need the
> > source and versions of these tools to be reviewed and
> > approved.
> >
> > https://nam06.safelinks.protection.outlook.com/?url=htt
> > ps%3A%2F%2Fgithub.com%2Fmdkinney%2Fedk2-
> >

Re: [edk2-devel] [RFC PATCH v2 04/44] OvmfPkg/ResetVector: Add support for a 32-bit SEV check

2019-09-24 Thread Laszlo Ersek

On 09/24/19 15:42, Laszlo Ersek wrote:
> On 09/19/19 21:52, Lendacky, Thomas wrote:

>> +mov   esp, SEV_TOP_OF_STACK

> (3) Do we have an estimate how much stack we need? This would be a
> constraint on PcdOvmfSecPeiTempRamSize. The limit would be nice to
> document (perhaps in a comment somewhere).

Ah I've just been reminded by [RFC PATCH v2 06/44]:

we could use "%if" + "%error" to catch (at compile time) if the stack is
too small.

(Not sure if this is overly useful; it might not be, if the stack demand
is negligible.)

Thanks
Laszlo

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

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

Re: [edk2-devel] [patch v3 3/5] MdeModulePkg/UefiBootManager: Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Gao, Zhichao

Nice catch. Moving the check into the if conditional section would avoid the 
additional check when the status is EFI_SUCCESS.

Reviewed-by: Zhichao Gao 

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Philippe Mathieu-Daudé
> Sent: Tuesday, September 24, 2019 9:22 PM
> To: devel@edk2.groups.io; Bi, Dandan 
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray ; Gao, Zhichao ; Gao,
> Liming ; Laszlo Ersek 
> Subject: Re: [edk2-devel] [patch v3 3/5] MdeModulePkg/UefiBootManager:
> Unload image on EFI_SECURITY_VIOLATION
> 
> On 9/24/19 3:16 PM, Dandan Bi wrote:
> > For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> > the Image was loaded and an ImageHandle was created with a valid
> > EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right
> now.
> > This follows UEFI Spec.
> >
> > But if the caller of LoadImage() doesn't have the option to defer the
> > execution of an image, we can not treat EFI_SECURITY_VIOLATION like
> > any other LoadImage() error, we should unload image for the
> > EFI_SECURITY_VIOLATION to avoid resource leak.
> >
> > This patch is to do error handling for EFI_SECURITY_VIOLATION
> > explicitly for the callers in UefiBootManagerLib which don't have the
> > policy to defer the execution of the image.
> >
> > Cc: Jian J Wang 
> > Cc: Hao A Wu 
> > Cc: Ray Ni 
> > Cc: Zhichao Gao 
> > Cc: Liming Gao 
> > Cc: Laszlo Ersek 
> > Cc: Philippe Mathieu-Daude 
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> > Signed-off-by: Dandan Bi 
> > ---
> > V3: Enahnce the error handling logic in BmLoadOption.c and BmMisc.c.
> >  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |  9 +
> >  .../Library/UefiBootManagerLib/BmLoadOption.c  | 14 --
> >  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c   | 14
> --
> >  3 files changed, 33 insertions(+), 4 deletions(-)
> >
> > diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > index 952033fc82..760d7647b8 100644
> > --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > @@ -1859,10 +1859,19 @@ EfiBootManagerBoot (
> >  if (FilePath != NULL) {
> >FreePool (FilePath);
> >  }
> >
> >  if (EFI_ERROR (Status)) {
> > +  //
> > +  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an
> ImageHandle was created
> > +  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not
> be started right now.
> > +  // If the caller doesn't have the option to defer the execution of an
> image, we should
> > +  // unload image for the EFI_SECURITY_VIOLATION to avoid resource
> leak.
> > +  //
> > +  if (Status == EFI_SECURITY_VIOLATION) {
> > +gBS->UnloadImage (ImageHandle);
> > +  }
> >//
> >// Report Status Code with the failure status to indicate that the 
> > failure
> to load boot option
> >//
> >BmReportLoadFailure
> (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR, Status);
> >BootOption->Status = Status;
> > diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> > b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> > index 07592f8ebd..89372b3b97 100644
> > --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> > +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> > @@ -1,9 +1,9 @@
> >  /** @file
> >Load option library functions which relate with creating and processing
> load options.
> >
> > -Copyright (c) 2011 - 2018, Intel Corporation. All rights
> > reserved.
> > +Copyright (c) 2011 - 2019, Intel Corporation. All rights
> > +reserved.
> >  (C) Copyright 2015-2018 Hewlett Packard Enterprise Development LP
> >  SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> >
> > @@ -1409,11 +1409,21 @@ EfiBootManagerProcessLoadOption (
> >  FileSize,
> >  
> >  );
> >  FreePool (FileBuffer);
> >
> > -if (!EFI_ERROR (Status)) {
> > +if (EFI_ERROR (Status)) {
> > +  //
> > +  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an
> ImageHandle was created
> > +  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not
> be started right now.
> > +  // If the caller doesn't have the option to defer the execution of an
> image, we should
> > +  // unload image for the EFI_SECURITY_VIOLATION to avoid resource
> leak.
> > +  //
> > +  if (Status == EFI_SECURITY_VIOLATION) {
> > +gBS->UnloadImage (ImageHandle);
> > +  }
> > +} else {
> 
> Thanks for changing this Dandan!
> 
> >Status = gBS->HandleProtocol (ImageHandle,
> , (VOID **));
> >ASSERT_EFI_ERROR (Status);
> >
> >ImageInfo->LoadOptionsSize = LoadOption->OptionalDataSize;
> >ImageInfo->LoadOptions = LoadOption->OptionalData; diff

Re: [edk2-devel] [RFC PATCH v2 04/44] OvmfPkg/ResetVector: Add support for a 32-bit SEV check

2019-09-24 Thread Laszlo Ersek

On 09/19/19 21:52, Lendacky, Thomas wrote:
> From: Tom Lendacky 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> During BSP startup, the reset vector code will issue a CPUID instruction
> while in 32-bit mode. When running as an SEV-ES guest, this will trigger
> a #VC exception.

(1) In the assembly source code, please annotate both CPUID instructions
under CheckSevFeature, such as

  ; raises #VC when in an SEV-ES guest

> 
> Add exception handling support to the early reset vector code to catch
> these exceptions.  Also, since the guest is in 32-bit mode at this point,
> writes to the GHCB will be encrypted and thus not able to be read by the
> hypervisor, so use the GHCB CPUID request/response protocol to obtain the
> requested CPUID function values and provide these to the guest.
> 
> The exception handling support is active during the SEV check and uses the
> OVMF temporary RAM space for a stack. After the SEV check is complete, the
> exception handling support is removed and the stack pointer cleared.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Tom Lendacky 
> ---
>  OvmfPkg/ResetVector/ResetVector.inf   |   2 +
>  OvmfPkg/ResetVector/Ia32/PageTables64.asm | 177 +-
>  OvmfPkg/ResetVector/ResetVector.nasmb |   1 +
>  3 files changed, 179 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
> b/OvmfPkg/ResetVector/ResetVector.inf
> index b0ddfa5832a2..960b47cd0797 100644
> --- a/OvmfPkg/ResetVector/ResetVector.inf
> +++ b/OvmfPkg/ResetVector/ResetVector.inf
> @@ -35,3 +35,5 @@ [BuildOptions]
>  [Pcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
> diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
> b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> index abad009f20f5..40f7814c1134 100644
> --- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> +++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> @@ -33,10 +33,21 @@ BITS32
>  
>  ; Check if Secure Encrypted Virtualization (SEV) feature is enabled
>  ;
> -; If SEV is enabled then EAX will be at least 32
> +; Modified:  EAX, EBX, ECX, EDX, ESP
> +;
> +; If SEV is enabled then EAX will be at least 32.
>  ; If SEV is disabled then EAX will be zero.
>  ;
>  CheckSevFeature:
> +;
> +; Set up exception handlers to check for SEV-ES
> +;   Load temporary RAM stack based on PCDs
> +;   Establish exception handlers
> +;
> +mov   esp, SEV_TOP_OF_STACK

(2) Can we %define SEV_TOP_OF_STACK in this file, or does it have to be
in "ResetVector.nasmb"?

(3) Do we have an estimate how much stack we need? This would be a
constraint on PcdOvmfSecPeiTempRamSize. The limit would be nice to
document (perhaps in a comment somewhere).

> +mov   eax, ADDR_OF(Idtr)
> +lidt  [cs:eax]
> +
>  ; Check if we have a valid (0x8000_001F) CPUID leaf
>  mov   eax, 0x8000
>  cpuid
> @@ -73,6 +84,15 @@ NoSev:
>  xor   eax, eax
>  
>  SevExit:
> +;
> +; Clear exception handlers and stack
> +;
> +push  eax
> +mov   eax, ADDR_OF(IdtrClear)
> +lidt  [cs:eax]
> +pop   eax
> +mov   esp, 0
> +

I'm not sure the resultant IDT and ESP contents are the same as before
(pre-patch), but I guess these values should be OK too.

>  OneTimeCallRet CheckSevFeature
>  
>  ;
> @@ -146,3 +166,158 @@ pageTableEntriesLoop:
>  mov cr3, eax
>  
>  OneTimeCallRet SetCr3ForPageTables64
> +
> +SevEsIdtCommon:
> +hlt
> +jmp SevEsIdtCommon
> +iret
> +
> +SevEsIdtVmmComm:
> +;
> +; If we're here, then we are an SEV-ES guest and this
> +; was triggered by a CPUID instruction
> +;
> +pop ecx ; Error code
> +cmp ecx, 0x72   ; Be sure it was CPUID
> +jne SevEsIdtCommon

(4) Can you steal the DebugLog / PrintStringSi code from
"OvmfPkg/QemuVideoDxe/VbeShim.asm", and print a simple message to the
QEMU debug port, whenever you jump to SevEsIdtCommon?

This is basically an ASSERT(). It should have a message, if possible.
(I'm not sure if the OUT instruction will work with SEV-ES at this
stage, i.e. in 32-bit mode.)

> +
> +;
> +; Set up local variable room on the stack
> +;   CPUID function  : + 28
> +;   CPUID register  : + 24
> +;   GHCB MSR (EAX)  : + 20
> +;   GHCB MSR (EDX)  : + 16
> +;   CPUID result (EDX)  : + 12
> +;   CPUID result (ECX)  : + 8
> +;   CPUID result (EBX)  : + 4
> +;   CPUID result (EAX)  : + 0
> +sub esp, 32

(5) Can we %define macros for these offsets? (Including the size
constant 32.)

> +
> +; Save CPUID function and initial register request
> +mov [esp + 28], eax
> +xor eax, eax
> +mov [esp + 24],

Re: [edk2-devel] [patch v3 3/5] MdeModulePkg/UefiBootManager: Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/24/19 3:16 PM, Dandan Bi wrote:
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
> 
> But if the caller of LoadImage() doesn't have the option to defer
> the execution of an image, we can not treat EFI_SECURITY_VIOLATION
> like any other LoadImage() error, we should unload image for the
> EFI_SECURITY_VIOLATION to avoid resource leak.
> 
> This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
> for the callers in UefiBootManagerLib which don't have the policy to defer
> the execution of the image.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Cc: Liming Gao 
> Cc: Laszlo Ersek 
> Cc: Philippe Mathieu-Daude 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> Signed-off-by: Dandan Bi 
> ---
> V3: Enahnce the error handling logic in BmLoadOption.c and BmMisc.c.
>  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |  9 +
>  .../Library/UefiBootManagerLib/BmLoadOption.c  | 14 --
>  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c   | 14 --
>  3 files changed, 33 insertions(+), 4 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> index 952033fc82..760d7647b8 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> @@ -1859,10 +1859,19 @@ EfiBootManagerBoot (
>  if (FilePath != NULL) {
>FreePool (FilePath);
>  }
>  
>  if (EFI_ERROR (Status)) {
> +  //
> +  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
> ImageHandle was created
> +  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
> started right now.
> +  // If the caller doesn't have the option to defer the execution of an 
> image, we should
> +  // unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
> +  //
> +  if (Status == EFI_SECURITY_VIOLATION) {
> +gBS->UnloadImage (ImageHandle);
> +  }
>//
>// Report Status Code with the failure status to indicate that the 
> failure to load boot option
>//
>BmReportLoadFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR, Status);
>BootOption->Status = Status;
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> index 07592f8ebd..89372b3b97 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> @@ -1,9 +1,9 @@
>  /** @file
>Load option library functions which relate with creating and processing 
> load options.
>  
> -Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
>  (C) Copyright 2015-2018 Hewlett Packard Enterprise Development LP
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
>  
> @@ -1409,11 +1409,21 @@ EfiBootManagerProcessLoadOption (
>  FileSize,
>  
>  );
>  FreePool (FileBuffer);
>  
> -if (!EFI_ERROR (Status)) {
> +if (EFI_ERROR (Status)) {
> +  //
> +  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
> ImageHandle was created
> +  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
> started right now.
> +  // If the caller doesn't have the option to defer the execution of an 
> image, we should
> +  // unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
> +  //
> +  if (Status == EFI_SECURITY_VIOLATION) {
> +gBS->UnloadImage (ImageHandle);
> +  }
> +} else {

Thanks for changing this Dandan!

>Status = gBS->HandleProtocol (ImageHandle, 
> , (VOID **));
>ASSERT_EFI_ERROR (Status);
>  
>ImageInfo->LoadOptionsSize = LoadOption->OptionalDataSize;
>ImageInfo->LoadOptions = LoadOption->OptionalData;
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> index 6b8fb4d924..89595747af 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> @@ -1,9 +1,9 @@
>  /** @file
>Misc library functions.
>  
> -Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
>  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
>  
> @@ -491,11 +491,21 @@ EfiBootManagerDispatchDeferredImages (
>  ImageDevicePath,
>  NULL,
>  0,
>  
>);
> -  if (!EFI_ERROR (Status)) {
> +

Re: [edk2-devel] [PATCH] MdeModulePkg/FrameBufferBltLib: Correctly consider SourceX

2019-09-24 Thread Wu, Hao A

> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, September 24, 2019 9:15 PM
> To: Wu, Hao A; Marvin Häuser; devel@edk2.groups.io; Ni, Ray
> Cc: Wang, Jian J
> Subject: RE: [PATCH] MdeModulePkg/FrameBufferBltLib: Correctly consider
> SourceX
> 
> I have just viewed a same patch of this issue. See
> https://edk2.groups.io/g/devel/topic/34168097#47297.
> The two patches are doing the same thing.


Yes. The 2 patches look the same to me.

Since the above patch has been reviewed and tested, I will push the above one
later if there is no other comments.

Best Regards,
Hao Wu


> 
> Thanks,
> Zhichao
> 
> > -Original Message-
> > From: Wu, Hao A
> > Sent: Tuesday, September 24, 2019 9:02 PM
> > To: Marvin Häuser ;
> devel@edk2.groups.io;
> > Gao, Zhichao ; Ni, Ray 
> > Cc: Wang, Jian J 
> > Subject: RE: [PATCH] MdeModulePkg/FrameBufferBltLib: Correctly
> consider
> > SourceX
> >
> > > -Original Message-
> > > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > > Sent: Tuesday, September 24, 2019 8:46 PM
> > > To: devel@edk2.groups.io
> > > Cc: Wang, Jian J; Wu, Hao A
> > > Subject: [PATCH] MdeModulePkg/FrameBufferBltLib: Correctly consider
> > > SourceX
> > >
> > > From: Marvin Haeuser 
> > >
> > > Currently, SourceX is not considered in the BufferToVideo operation
> > > when the 8-bit pixel format is used. Correctly add the resulting
> > > offset to prevent image corruption.
> > >
> > > Cc: Jian J Wang 
> > > Cc: Hao A Wu 
> >
> >
> > Hello Marvin,
> >
> > In the future, could you help to run the below script:
> > BaseTools/Scripts/GetMaintainer.py
> > to get the reviewers for the proposed patch? Thanks in advance.
> >
> > Hello Zhichao and Ray,
> >
> > Could you help to take a look at this patch? Thanks.
> >
> > Best Regards,
> > Hao Wu
> >
> >
> > > Signed-off-by: Marvin Haeuser 
> > > ---
> > >  MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > > b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > > index 47c5326e9958..a084cc81d32e 100644
> > > --- a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > > +++ b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > > @@ -504,7 +504,7 @@ FrameBufferBltLibBufferToVideo (
> > >  Destination = Configure->FrameBuffer + Offset;
> > >
> > >
> > >
> > >  if (Configure->PixelFormat ==
> > > PixelBlueGreenRedReserved8BitPerColor) {
> > >
> > > -  Source = (UINT8 *) BltBuffer + (SrcY * Delta);
> > >
> > > +  Source = (UINT8 *) BltBuffer + (SrcY * Delta) + (SourceX *
> > > + sizeof
> > > (EFI_GRAPHICS_OUTPUT_BLT_PIXEL));
> > >
> > >  } else {
> > >
> > >for (IndexX = 0; IndexX < Width; IndexX++) {
> > >
> > >  Blt =
> > >
> > > --
> > > 2.23.0.windows.1


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

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

[edk2-devel] [patch v3 4/5] MdeModulePkg/PlatformDriOverride: Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Dandan Bi

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.

But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.

This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the caller in PlatformDriOverrideDxe which don't have the policy to
defer the execution of the image.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Liming Gao 
Cc: Laszlo Ersek 
Cc: Philippe Mathieu-Daude 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi 
Reviewed-by: Hao A Wu 
Reviewed-by: Philippe Mathieu-Daude 
---
 .../PlatformDriOverrideDxe/PlatDriOverrideLib.c   | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c 
b/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c
index 2d3736b468..f91f038b7a 100644
--- a/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c
+++ b/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c
@@ -1,9 +1,9 @@
 /** @file
   Implementation of the shared functions to do the platform driver vverride 
mapping.
 
-  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
 #include "InternalPlatDriOverrideDxe.h"
@@ -1484,10 +1484,19 @@ GetDriverFromMapping (
);
 ASSERT (DriverBinding != NULL);
 DriverImageInfo->ImageHandle = ImageHandle;
   }
 } else {
+  //
+  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and 
an ImageHandle was created
+  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not 
be started right now.
+  // If the caller doesn't have the option to defer the execution 
of an image, we should
+  // unload image for the EFI_SECURITY_VIOLATION to avoid resource 
leak.
+  //
+  if (Status == EFI_SECURITY_VIOLATION) {
+gBS->UnloadImage (ImageHandle);
+  }
   DriverImageInfo->UnLoadable = TRUE;
   DriverImageInfo->ImageHandle = NULL;
 }
   }
 }
-- 
2.18.0.windows.1


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

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

[edk2-devel] [patch v3 5/5] ShellPkg: Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Dandan Bi

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.

But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.

This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in ShellPkg which don't have the policy to defer the
execution of the image.

Cc: Ray Ni 
Cc: Zhichao Gao 
Cc: Laszlo Ersek 
Cc: Philippe Mathieu-Daude 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi 
Reviewed-by: Zhichao Gao 
Reviewed-by: Philippe Mathieu-Daude 
---
 ShellPkg/Application/Shell/ShellManParser.c   |  9 +
 .../Library/UefiShellDebug1CommandsLib/LoadPciRom.c   | 11 ++-
 ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c| 11 ++-
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Application/Shell/ShellManParser.c 
b/ShellPkg/Application/Shell/ShellManParser.c
index 6909f29441..4d5a5668aa 100644
--- a/ShellPkg/Application/Shell/ShellManParser.c
+++ b/ShellPkg/Application/Shell/ShellManParser.c
@@ -643,10 +643,19 @@ ProcessManFile(
   goto Done;
 }
 DevPath = 
ShellInfoObject.NewEfiShellProtocol->GetDevicePathFromFilePath(CmdFilePathName);
 Status  = gBS->LoadImage(FALSE, gImageHandle, DevPath, NULL, 0, 
);
 if(EFI_ERROR(Status)) {
+  //
+  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+  // If the caller doesn't have the option to defer the execution of an 
image, we should
+  // unload image for the EFI_SECURITY_VIOLATION to avoid the resource 
leak.
+  //
+  if (Status == EFI_SECURITY_VIOLATION) {
+gBS->UnloadImage (CmdFileImgHandle);
+  }
   *HelpText = NULL;
   goto Done;
 }
 Status = gBS->OpenProtocol(
 CmdFileImgHandle,
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
index 1b169d0d3c..5b6cba17f3 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
@@ -1,10 +1,10 @@
 /** @file
   Main file for LoadPciRom shell Debug1 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
 #include "UefiShellDebug1CommandsLib.h"
@@ -332,10 +332,19 @@ LoadEfiDriversFromRomImage (
 ImageBuffer,
 ImageLength,
 
);
   if (EFI_ERROR (Status)) {
+//
+// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not 
be started right now.
+// If the caller doesn't have the option to defer the execution of 
an image, we should
+// unload image for the EFI_SECURITY_VIOLATION to avoid resource 
leak.
+//
+if (Status == EFI_SECURITY_VIOLATION) {
+  gBS->UnloadImage (ImageHandle);
+}
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN 
(STR_LOADPCIROM_LOAD_FAIL), gShellDebug1HiiHandle, L"loadpcirom", FileName, 
ImageIndex);
 //PrintToken (STRING_TOKEN (STR_LOADPCIROM_LOAD_IMAGE_ERROR), 
HiiHandle, ImageIndex, Status);
   } else {
 Status = gBS->StartImage (ImageHandle, NULL, NULL);
 if (EFI_ERROR (Status)) {
diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
index 6a94b48c86..b6e7c952fa 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
@@ -1,10 +1,10 @@
 /** @file
   Main file for attrib shell level 2 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
 #include "UefiShellLevel2CommandsLib.h"
@@ -110,10 +110,19 @@ LoadDriver(
 NULL,
 0,
 );
 
   if (EFI_ERROR(Status)) {
+//
+// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started

[edk2-devel] [patch v3 3/5] MdeModulePkg/UefiBootManager: Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Dandan Bi

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.

But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.

This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in UefiBootManagerLib which don't have the policy to defer
the execution of the image.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Zhichao Gao 
Cc: Liming Gao 
Cc: Laszlo Ersek 
Cc: Philippe Mathieu-Daude 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi 
---
V3: Enahnce the error handling logic in BmLoadOption.c and BmMisc.c.
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |  9 +
 .../Library/UefiBootManagerLib/BmLoadOption.c  | 14 --
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c   | 14 --
 3 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 952033fc82..760d7647b8 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -1859,10 +1859,19 @@ EfiBootManagerBoot (
 if (FilePath != NULL) {
   FreePool (FilePath);
 }
 
 if (EFI_ERROR (Status)) {
+  //
+  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+  // If the caller doesn't have the option to defer the execution of an 
image, we should
+  // unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
+  //
+  if (Status == EFI_SECURITY_VIOLATION) {
+gBS->UnloadImage (ImageHandle);
+  }
   //
   // Report Status Code with the failure status to indicate that the 
failure to load boot option
   //
   BmReportLoadFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR, Status);
   BootOption->Status = Status;
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index 07592f8ebd..89372b3b97 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -1,9 +1,9 @@
 /** @file
   Load option library functions which relate with creating and processing load 
options.
 
-Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
 (C) Copyright 2015-2018 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
@@ -1409,11 +1409,21 @@ EfiBootManagerProcessLoadOption (
 FileSize,
 
 );
 FreePool (FileBuffer);
 
-if (!EFI_ERROR (Status)) {
+if (EFI_ERROR (Status)) {
+  //
+  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+  // If the caller doesn't have the option to defer the execution of an 
image, we should
+  // unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
+  //
+  if (Status == EFI_SECURITY_VIOLATION) {
+gBS->UnloadImage (ImageHandle);
+  }
+} else {
   Status = gBS->HandleProtocol (ImageHandle, , 
(VOID **));
   ASSERT_EFI_ERROR (Status);
 
   ImageInfo->LoadOptionsSize = LoadOption->OptionalDataSize;
   ImageInfo->LoadOptions = LoadOption->OptionalData;
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
index 6b8fb4d924..89595747af 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
@@ -1,9 +1,9 @@
 /** @file
   Misc library functions.
 
-Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
 (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
@@ -491,11 +491,21 @@ EfiBootManagerDispatchDeferredImages (
 ImageDevicePath,
 NULL,
 0,
 
   );
-  if (!EFI_ERROR (Status)) {
+  if (EFI_ERROR (Status)) {
+//
+// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+// If the caller doesn't have the option to defer the execution of an 
image,

[edk2-devel] [patch v3 2/5] MdeModulePkg/DxeCapsuleLibFmp: Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Dandan Bi

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.

But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.

This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in DxeCapsuleLibFmp which don't have the policy to defer
the execution of the image.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Liming Gao 
Cc: Laszlo Ersek 
Cc: Philippe Mathieu-Daude 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi 
Reviewed-by: Hao A Wu 
Reviewed-by: Philippe Mathieu-Daude 
---
 MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c 
b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
index 95aa9de087..5dda561a04 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
@@ -1028,10 +1028,19 @@ StartFmpImage (
   ImageSize,
   
   );
   DEBUG((DEBUG_INFO, "FmpCapsule: LoadImage - %r\n", Status));
   if (EFI_ERROR(Status)) {
+//
+// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+// If the caller doesn't have the option to defer the execution of an 
image, we should
+// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
+//
+if (Status == EFI_SECURITY_VIOLATION) {
+  gBS->UnloadImage (ImageHandle);
+}
 FreePool(DriverDevicePath);
 return Status;
   }
 
   DEBUG((DEBUG_INFO, "FmpCapsule: StartImage ...\n"));
-- 
2.18.0.windows.1


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

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

[edk2-devel] [patch v3 1/5] EmbeddedPkg: Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Dandan Bi

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.

But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.

This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in EmbeddedPkg which don't have the policy to defer the
execution of the image.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Laszlo Ersek 
Cc: Philippe Mathieu-Daude 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi 
Acked-by: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Reviewed-by: Philippe Mathieu-Daude 
---
 .../AndroidFastboot/Arm/BootAndroidBootImg.c |  9 +
 .../Library/AndroidBootImgLib/AndroidBootImgLib.c| 12 
 2 files changed, 21 insertions(+)

diff --git a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c 
b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
index 591afbe7cc..fe05878b4b 100644
--- a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
+++ b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
@@ -71,10 +71,19 @@ StartEfiApplication (
 
   // Load the image from the device path with Boot Services function
   Status = gBS->LoadImage (TRUE, ParentImageHandle, DevicePath, NULL, 0,
   );
   if (EFI_ERROR (Status)) {
+//
+// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+// If the caller doesn't have the option to defer the execution of an 
image, we should
+// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
+//
+if (Status == EFI_SECURITY_VIOLATION) {
+  gBS->UnloadImage (ImageHandle);
+}
 return Status;
   }
 
   // Passed LoadOptions to the EFI Application
   if (LoadOptionsSize != 0) {
diff --git a/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c 
b/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c
index d9e7aa7d2b..e1036954ee 100644
--- a/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c
+++ b/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c
@@ -439,10 +439,22 @@ AndroidBootImgBoot (
+ KernelSize;
 
   Status = gBS->LoadImage (TRUE, gImageHandle,
(EFI_DEVICE_PATH *),
(VOID*)(UINTN)Kernel, KernelSize, );
+  if (EFI_ERROR (Status)) {
+//
+// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+// If the caller doesn't have the option to defer the execution of an 
image, we should
+// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
+//
+if (Status == EFI_SECURITY_VIOLATION) {
+  gBS->UnloadImage (ImageHandle);
+}
+return Status;
+  }
 
   // Set kernel arguments
   Status = gBS->HandleProtocol (ImageHandle, ,
 (VOID **) );
   ImageInfo->LoadOptions = NewKernelArg;
-- 
2.18.0.windows.1


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

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

[edk2-devel] [patch v3 0/5] Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Dandan Bi

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

v2:
Just enahnce the code error handling logic in patch 3.
Other patches are the same and pick up the Acked-by and Reviewed-by in other 
patches.

v2:
(1) Just separate the patch in MdeModulePkg into module level, the changes in 
EmbeddedPkg and ShellPkg are the same with V1.
(2) Drop the update in PciBusDxe module in MdeModulePkg since with 
EFI_SECURITY_VIOLATION returned, the image may be used later.


For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.

But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.

This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in edk2 which don't have the policy to defer the
execution of the image.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Liming Gao 
Cc: Zhichao Gao 
Cc: Laszlo Ersek 
Cc: Philippe Mathieu-Daude 
Dandan Bi (3):
  EmbeddedPkg: Unload image on EFI_SECURITY_VIOLATION
  MdeModulePkg/DxeCapsuleLibFmp: Unload image on EFI_SECURITY_VIOLATION
  MdeModulePkg/UefiBootManager: Unload image on EFI_SECURITY_VIOLATION
  MdeModulePkg/PlatformDriOverride: Unload image on
EFI_SECURITY_VIOLATION
  ShellPkg: Unload image on EFI_SECURITY_VIOLATION

 .../AndroidFastboot/Arm/BootAndroidBootImg.c |  9 +
 .../Library/AndroidBootImgLib/AndroidBootImgLib.c| 12 
 .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c |  9 +
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c |  9 +
 .../Library/UefiBootManagerLib/BmLoadOption.c| 14 --
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 14 --
 .../PlatformDriOverrideDxe/PlatDriOverrideLib.c  | 11 ++-
 ShellPkg/Application/Shell/ShellManParser.c  |  9 +
 .../Library/UefiShellDebug1CommandsLib/LoadPciRom.c  | 11 ++-
 ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c   | 11 ++-
 10 files changed, 98 insertions(+), 5 deletions(-)

-- 
2.18.0.windows.1


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

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

Re: [edk2-devel] [PATCH] MdeModulePkg/FrameBufferBltLib: Correctly consider SourceX

2019-09-24 Thread Gao, Zhichao

I have just viewed a same patch of this issue. See 
https://edk2.groups.io/g/devel/topic/34168097#47297.
The two patches are doing the same thing.

Thanks,
Zhichao

> -Original Message-
> From: Wu, Hao A
> Sent: Tuesday, September 24, 2019 9:02 PM
> To: Marvin Häuser ; devel@edk2.groups.io;
> Gao, Zhichao ; Ni, Ray 
> Cc: Wang, Jian J 
> Subject: RE: [PATCH] MdeModulePkg/FrameBufferBltLib: Correctly consider
> SourceX
> 
> > -Original Message-
> > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > Sent: Tuesday, September 24, 2019 8:46 PM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J; Wu, Hao A
> > Subject: [PATCH] MdeModulePkg/FrameBufferBltLib: Correctly consider
> > SourceX
> >
> > From: Marvin Haeuser 
> >
> > Currently, SourceX is not considered in the BufferToVideo operation
> > when the 8-bit pixel format is used. Correctly add the resulting
> > offset to prevent image corruption.
> >
> > Cc: Jian J Wang 
> > Cc: Hao A Wu 
> 
> 
> Hello Marvin,
> 
> In the future, could you help to run the below script:
> BaseTools/Scripts/GetMaintainer.py
> to get the reviewers for the proposed patch? Thanks in advance.
> 
> Hello Zhichao and Ray,
> 
> Could you help to take a look at this patch? Thanks.
> 
> Best Regards,
> Hao Wu
> 
> 
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
> > a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > index 47c5326e9958..a084cc81d32e 100644
> > --- a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > +++ b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > @@ -504,7 +504,7 @@ FrameBufferBltLibBufferToVideo (
> >  Destination = Configure->FrameBuffer + Offset;
> >
> >
> >
> >  if (Configure->PixelFormat ==
> > PixelBlueGreenRedReserved8BitPerColor) {
> >
> > -  Source = (UINT8 *) BltBuffer + (SrcY * Delta);
> >
> > +  Source = (UINT8 *) BltBuffer + (SrcY * Delta) + (SourceX *
> > + sizeof
> > (EFI_GRAPHICS_OUTPUT_BLT_PIXEL));
> >
> >  } else {
> >
> >for (IndexX = 0; IndexX < Width; IndexX++) {
> >
> >  Blt =
> >
> > --
> > 2.23.0.windows.1


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

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

Re: [edk2-devel] [PATCH] MdeModulePkg/FrameBufferBltLib: Correctly consider SourceX

2019-09-24 Thread Wu, Hao A

> -Original Message-
> From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> Sent: Tuesday, September 24, 2019 8:46 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A
> Subject: [PATCH] MdeModulePkg/FrameBufferBltLib: Correctly consider
> SourceX
> 
> From: Marvin Haeuser 
> 
> Currently, SourceX is not considered in the BufferToVideo operation
> when the 8-bit pixel format is used. Correctly add the resulting
> offset to prevent image corruption.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 


Hello Marvin,

In the future, could you help to run the below script:
BaseTools/Scripts/GetMaintainer.py
to get the reviewers for the proposed patch? Thanks in advance.

Hello Zhichao and Ray,

Could you help to take a look at this patch? Thanks.

Best Regards,
Hao Wu


> Signed-off-by: Marvin Haeuser 
> ---
>  MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> index 47c5326e9958..a084cc81d32e 100644
> --- a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> +++ b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> @@ -504,7 +504,7 @@ FrameBufferBltLibBufferToVideo (
>  Destination = Configure->FrameBuffer + Offset;
> 
> 
> 
>  if (Configure->PixelFormat == PixelBlueGreenRedReserved8BitPerColor) {
> 
> -  Source = (UINT8 *) BltBuffer + (SrcY * Delta);
> 
> +  Source = (UINT8 *) BltBuffer + (SrcY * Delta) + (SourceX * sizeof
> (EFI_GRAPHICS_OUTPUT_BLT_PIXEL));
> 
>  } else {
> 
>for (IndexX = 0; IndexX < Width; IndexX++) {
> 
>  Blt =
> 
> --
> 2.23.0.windows.1


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

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

Re: [edk2-devel] [Patch 05/10 V8] BaseTools: Enable Multiple Process AutoGen

2019-09-24 Thread dann frazier

On Mon, Sep 23, 2019 at 8:25 PM Feng, Bob C  wrote:
>
> Hi Dann,
>
> Thanks for raising this issue.
>
> Would you provide the static_library_files.list file, so that I can have a 
> check?

Hi Bob,
  Sure - it occurs to me that bugzilla might be a better place to
share this material, so I've opened a new issue:
https://bugzilla.tianocore.org/show_bug.cgi?id=2216

I'll provide the requested files, as well as full build logs there.

> As this patch was pushed month ago, I'd like to ask if this build failure 
> always happens since this patch was pushed?

AFAICT, yes. I'm just noticing now because I'm working on packaging
the latest stable tag for Debian.

  -dann

> Thanks,
> Bob
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of dann 
> frazier
> Sent: Tuesday, September 24, 2019 9:19 AM
> To: devel@edk2.groups.io; Feng, Bob C 
> Cc: Gao, Liming 
> Subject: Re: [edk2-devel] [Patch 05/10 V8] BaseTools: Enable Multiple Process 
> AutoGen
>
> On Wed, Aug 07, 2019 at 12:25:32PM +0800, Bob Feng wrote:
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1875
> >
> > Assign the Module AutoGen tasks into multiple sub process.
> >
> > Cc: Liming Gao 
> > Signed-off-by: Bob Feng 
> > ---
> >  .../Source/Python/AutoGen/AutoGenWorker.py| 191 ++
> >  BaseTools/Source/Python/AutoGen/DataPipe.py   |  17 +-
> >  BaseTools/Source/Python/AutoGen/GenC.py   |   4 +-
> >  .../Source/Python/AutoGen/ModuleAutoGen.py|   2 +-
> >  .../Source/Python/AutoGen/PlatformAutoGen.py  |  16 +-
> >  .../Source/Python/AutoGen/WorkspaceAutoGen.py |   6 +-
> >  BaseTools/Source/Python/build/build.py| 125 
> >  7 files changed, 306 insertions(+), 55 deletions(-)  create mode
> > 100644 BaseTools/Source/Python/AutoGen/AutoGenWorker.py
>
> I've bisected a regression building the ArmVirt architecture of 
> ArmVirtPkg/ArmVirtQemu.dsc to this commit.
>
> $ build -a ARM -p ArmVirtPkg/ArmVirtQemu.dsc -t GCC49 [...] 
> "arm-linux-gnueabihf-gcc" -o 
> /home/dannf/git/edk2.debug/Build/ArmVirtQemu-ARM/DEBUG_GCC49/ARM/MdeModulePkg/Logo/LogoDxe/DEBUG/LogoDxe.dll
>  -Wl,--emit-relocs -nostdlib -Wl,--gc-sections -u _ModuleEntryPoint 
> -Wl,-e,_ModuleEntryPoint,-Map,/home/dannf/git/edk2.debug/Build/ArmVirtQemu-ARM/DEBUG_GCC49/ARM/MdeModulePkg/Logo/LogoDxe/DEBUG/LogoDxe.map
>  -z common-page-size=0x20 -Wl,--pic-veneer -Wl,--oformat=elf32-littlearm -z 
> common-page-size=0x1000 
> -Wl,--start-group,@/home/dannf/git/edk2.debug/Build/ArmVirtQemu-ARM/DEBUG_GCC49/ARM/MdeModulePkg/Logo/LogoDxe/OUTPUT/static_library_files.lst,--end-group
>  -mthumb -march=armv7-a -g -Os -fshort-wchar -fno-builtin 
> -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h 
> -fno-common -mlittle-endian -mabi=aapcs -fno-short-enums -funsigned-char 
> -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb 
> -mfloat-abi=soft -fno-pic -fno-pie -fstack-protector -mword-relocations -O0 
> -DDISABLE_NEW_DEPRECATED_INTERFACES 
> -Wl,--script=/home/dannf/git/edk2.debug/BaseTools/Scripts/GccBase.lds 
> -Wl,--defsym=PECOFF_HEADER_SIZE=0x220
> /usr/lib/gcc-cross/arm-linux-gnueabihf/9/../../../../arm-linux-gnueabihf/bin/ld:
>  error: source object 
> /home/dannf/git/edk2.debug/Build/ArmVirtQemu-ARM/DEBUG_GCC49/ARM/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint/OUTPUT/UefiDriverEntryPoint.lib(DriverEntryPoint.obj)
>  has EABI version 5, but target 
> /home/dannf/git/edk2.debug/Build/ArmVirtQemu-ARM/DEBUG_GCC49/ARM/MdeModulePkg/Logo/LogoDxe/DEBUG/LogoDxe.dll
>  has EABI version 0
> /usr/lib/gcc-cross/arm-linux-gnueabihf/9/../../../../arm-linux-gnueabihf/bin/ld:
>  failed to merge target specific data of file 
> /home/dannf/git/edk2.debug/Build/ArmVirtQemu-ARM/DEBUG_GCC49/ARM/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint/OUTPUT/UefiDriverEntryPoint.lib(DriverEntryPoint.obj)
> /usr/lib/gcc-cross/arm-linux-gnueabihf/9/../../../../arm-linux-gnueabihf/bin/ld:
>  error: source object 
> /home/dannf/git/edk2.debug/Build/ArmVirtQemu-ARM/DEBUG_GCC49/ARM/MdeModulePkg/Logo/LogoDxe/OUTPUT/LogoDxe.lib(AutoGen.obj)
>  has EABI version 5, but target 
> /home/dannf/git/edk2.debug/Build/ArmVirtQemu-ARM/DEBUG_GCC49/ARM/MdeModulePkg/Logo/LogoDxe/DEBUG/LogoDxe.dll
>  has EABI version 0 [...]
>
> It looks like this maybe a side-effect of the ordering of the entries in 
> static_library_files.list. Previous to this commit, LogoDxehii.lib would 
> appear near the end of the file - now it is near the beginning.
> Moving it back to the end of the file allows the linking to continue.
>
> Also, is it expected that this does not report being an EABI5 object?
> $ file 
> Build/ArmVirtQemu-ARM/DEBUG_GCC49/ARM/MdeModulePkg/Logo/LogoDxe/OUTPUT/LogoDxehii.lib
> Build/ArmVirtQemu-ARM/DEBUG_GCC49/ARM/MdeModulePkg/Logo/LogoDxe/OUTPUT/LogoDxehii.lib:
>  ELF 32-bit LSB relocatable, ARM, version 1 (ARM), not stripped
>
>  -dann
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You

Re: [edk2-devel] [Qemu-devel] [PATCH 1/2] q35: implement 128K SMRAM at default SMBASE address

2019-09-24 Thread Paolo Bonzini

On 20/09/19 11:28, Laszlo Ersek wrote:
>> On QEMU side,  we can drop black-hole approach and allocate
>> dedicated SMRAM region, which explicitly gets mapped into
>> RAM address space and after SMI hanlder initialization, gets
>> unmapped (locked). So that SMRAM would be accessible only
>> from SMM context. That way RAM at 0x3 could be used as
>> normal when SMRAM is unmapped.
>
> I prefer the black-hole approach, introduced in your current patch
> series, if it can work. Way less opportunity for confusion.

Another possibility would be to alias the 0xA..0xB SMRAM to
0x3..0x4 (only when in SMM).

I'm not super enthusiastic about adding this kind of QEMU-only feature.
 The alternative would be to implement VT-d range locking through the
intel-iommu device's PCI configuration space (which includes _adding_
the configuration space, i.e. making the IOMMU a PCI device in the first
place, and the support to the firmware for configuring the VT-d BAR at
0xfed9).  This would be the right way to do it, but it would entail
a lot of work throughout the stack. :(  So I guess some variant of this
would be okay, as long as it's peppered with "this is not how real
hardware does it" comments in both QEMU and EDK2.

Thanks,

Paolo

> I've started work on the counterpart OVMF patches; I'll report back.

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

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

Re: [edk2-devel] [RFC PATCH v2 03/44] OvmfPkg: Add support to perform SEV-ES initialization

2019-09-24 Thread Laszlo Ersek

On 09/19/19 21:52, Lendacky, Thomas wrote:
> From: Tom Lendacky 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> When SEV-ES is active, then SEV is also active. Add support to the SEV
> initialization function to also check for SEV-ES being active. If SEV-ES
> is active, set the SEV-ES active PCD (PcdSevEsActive).
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Tom Lendacky 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc |  3 +++
>  OvmfPkg/OvmfPkgIa32X64.dsc  |  3 +++
>  OvmfPkg/OvmfPkgX64.dsc  |  3 +++
>  OvmfPkg/PlatformPei/PlatformPei.inf |  1 +
>  OvmfPkg/PlatformPei/AmdSev.c| 26 ++
>  5 files changed, 36 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 6ab730018694..0ce5c01722ef 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -558,6 +558,9 @@ [PcdsDynamicDefault]
># Set memory encryption mask
>gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
>  
> +  # Set SEV-ES defaults
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSevEsActive|0
> +
>  !if $(SMM_REQUIRE) == TRUE
>gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index f163aa267132..e7455e35a55d 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -570,6 +570,9 @@ [PcdsDynamicDefault]
># Set memory encryption mask
>gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
>  
> +  # Set SEV-ES defaults
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSevEsActive|0
> +
>  !if $(SMM_REQUIRE) == TRUE
>gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index fa98f16a3fb3..0b8305cd10a2 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -569,6 +569,9 @@ [PcdsDynamicDefault]
># Set memory encryption mask
>gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
>  
> +  # Set SEV-ES defaults
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSevEsActive|0
> +
>  !if $(SMM_REQUIRE) == TRUE
>gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index d9fd9c8f05b3..2736347a2e03 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -100,6 +100,7 @@ [Pcd]
>gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSevEsActive

(1) Can you add this next to
"gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask"?

>  
>  [FixedPcd]
>gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
> diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
> index 2ae8126ccf8a..7ae2f26a2ba7 100644
> --- a/OvmfPkg/PlatformPei/AmdSev.c
> +++ b/OvmfPkg/PlatformPei/AmdSev.c
> @@ -19,6 +19,27 @@
>  
>  #include "Platform.h"
>  
> +/**
> +
> +  Initialize SEV-ES support if running an SEV-ES guest.

(2) s/an/in an/? (Just asking)

> +
> +  **/
> +STATIC
> +VOID
> +AmdSevEsInitialize (
> +  VOID
> +  )
> +{
> +  RETURN_STATUS PcdStatus;
> +
> +  if (!MemEncryptSevEsIsEnabled ()) {
> +return;
> +  }
> +
> +  PcdStatus = PcdSetBoolS (PcdSevEsActive, 1);

(3) Please write TRUE, not 1.

> +  ASSERT_RETURN_ERROR (PcdStatus);
> +}
> +
>  /**
>  
>Function checks if SEV support is available, if present then it sets
> @@ -89,4 +110,9 @@ AmdSevInitialize (
>EfiBootServicesData// MemoryType
>);
>}
> +
> +  //
> +  // Check and perform SEV-ES initialization if required.
> +  //
> +  AmdSevEsInitialize ();
>  }
> 

With (1) and (3) fixed:

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

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

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

Re: [edk2-devel] [RFC PATCH v2 02/44] OvmfPkg/MemEncryptSevLib: Add an SEV-ES guest indicator function

2019-09-24 Thread Laszlo Ersek

On 09/19/19 21:52, Lendacky, Thomas wrote:
> From: Tom Lendacky 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> Create a function that can be used to determine if the VM is running
> as an SEV-ES guest.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Tom Lendacky 
> ---
>  OvmfPkg/Include/Library/MemEncryptSevLib.h| 12 +++
>  .../MemEncryptSevLibInternal.c| 77 ---
>  2 files changed, 62 insertions(+), 27 deletions(-)
> 
> diff --git a/OvmfPkg/Include/Library/MemEncryptSevLib.h 
> b/OvmfPkg/Include/Library/MemEncryptSevLib.h
> index 64dd6977b0f8..a50a0de9c870 100644
> --- a/OvmfPkg/Include/Library/MemEncryptSevLib.h
> +++ b/OvmfPkg/Include/Library/MemEncryptSevLib.h
> @@ -13,6 +13,18 @@
>  
>  #include 
>  
> +/**
> +  Returns a boolean to indicate whether SEV-ES is enabled
> +
> +  @retval TRUE   SEV-ES is enabled
> +  @retval FALSE  SEV-ES is not enabled
> +**/
> +BOOLEAN
> +EFIAPI
> +MemEncryptSevEsIsEnabled (
> +  VOID
> +  );
> +
>  /**
>Returns a boolean to indicate whether SEV is enabled
>  
> diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c 
> b/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c
> index 96a66e373f11..9c1d68e017fe 100644
> --- a/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c
> +++ b/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c
> @@ -20,19 +20,17 @@
>  #include 
>  
>  STATIC BOOLEAN mSevStatus = FALSE;
> +STATIC BOOLEAN mSevEsStatus = FALSE;
>  STATIC BOOLEAN mSevStatusChecked = FALSE;
>  
>  /**
>  
> -  Returns a boolean to indicate whether SEV is enabled
> -
> -  @retval TRUE   SEV is enabled
> -  @retval FALSE  SEV is not enabled
> +  Reads and sets the status of SEV features
>**/
>  STATIC
> -BOOLEAN
> +VOID
>  EFIAPI
> -InternalMemEncryptSevIsEnabled (
> +InternalMemEncryptSevStatus (
>VOID
>)
>  {
> @@ -56,32 +54,57 @@ InternalMemEncryptSevIsEnabled (
>//
>Msr.Uint32 = AsmReadMsr32 (MSR_SEV_STATUS);
>if (Msr.Bits.SevBit) {
> -return TRUE;
> +mSevStatus = TRUE;
> +  }
> +
> +  if (Eax.Bits.SevEsBit) {
> +//
> +// Check MSR_0xC0010131 Bit 1 (Sev-Es Enabled)
> +//
> +if (Msr.Bits.SevEsBit) {
> +  mSevEsStatus = TRUE;
> +}
>}
>  }
>}
>  
> -  return FALSE;
> -}
> -
> -/**
> -  Returns a boolean to indicate whether SEV is enabled
> -
> -  @retval TRUE   SEV is enabled
> -  @retval FALSE  SEV is not enabled
> -**/
> -BOOLEAN
> -EFIAPI
> -MemEncryptSevIsEnabled (
> -  VOID
> -  )
> -{
> -  if (mSevStatusChecked) {
> -return mSevStatus;
> -  }
> -
> -  mSevStatus = InternalMemEncryptSevIsEnabled();
>mSevStatusChecked = TRUE;
> +}
> +
> +/**
> +  Returns a boolean to indicate whether SEV-ES is enabled
> +
> +  @retval TRUE   SEV-ES is enabled
> +  @retval FALSE  SEV-ES is not enabled
> +**/
> +BOOLEAN
> +EFIAPI
> +MemEncryptSevEsIsEnabled (
> +  VOID
> +  )
> +{
> +  if (!mSevStatusChecked) {
> +InternalMemEncryptSevStatus();
> +  }
> +
> +  return mSevEsStatus;
> +}
> +
> +/**
> +  Returns a boolean to indicate whether SEV is enabled
> +
> +  @retval TRUE   SEV is enabled
> +  @retval FALSE  SEV is not enabled
> +**/
> +BOOLEAN
> +EFIAPI
> +MemEncryptSevIsEnabled (
> +  VOID
> +  )
> +{
> +  if (!mSevStatusChecked) {
> +InternalMemEncryptSevStatus();
> +  }
>  
>return mSevStatus;
>  }
> 

Reviewed-by: Laszlo Ersek 

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

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

Re: [edk2-devel] [PATCH wave 1 02/10] OvmfPkg/IndustryStandard: increase vertical whitespace in Q35 macro defs

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/24/19 1:34 PM, Laszlo Ersek wrote:
> In a subsequent patch, we'll introduce new DRAM controller macros in
> "Q35MchIch9.h". Their names are too long for the currently available
> vertical whitespace, so increase the latter first.
> 
> There is no functional change in this patch ("git show -b" displays
> nothing).
> 
> Cc: Ard Biesheuvel 
> Cc: Boris Ostrovsky 
> Cc: Brijesh Singh 
> Cc: Igor Mammedov 
> Cc: Jiewen Yao 
> Cc: Joao M Martins 
> Cc: Jordan Justen 
> Cc: Jun Nakajima 
> Cc: Michael Kinney 
> Cc: Paolo Bonzini 
> Cc: Phillip Goerl 
> Cc: Yingwen Chen 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/Include/IndustryStandard/Q35MchIch9.h | 100 ++--
>  1 file changed, 50 insertions(+), 50 deletions(-)
> 
> diff --git a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h 
> b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
> index 391cb466..614699ab38f1 100644
> --- a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
> +++ b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
> @@ -27,56 +27,56 @@
>  //
>  #define DRAMC_REGISTER_Q35(Offset) PCI_LIB_ADDRESS (0, 0, 0, (Offset))
>  
> -#define MCH_EXT_TSEG_MB   0x50
> -#define MCH_EXT_TSEG_MB_QUERY   0x
> -
> -#define MCH_GGC   0x52
> -#define MCH_GGC_IVD BIT1
> -
> -#define MCH_PCIEXBAR_LOW  0x60
> -#define MCH_PCIEXBAR_LOWMASK0x0FFF
> -#define MCH_PCIEXBAR_BUS_FF 0
> -#define MCH_PCIEXBAR_EN BIT0
> -
> -#define MCH_PCIEXBAR_HIGH 0x64
> -#define MCH_PCIEXBAR_HIGHMASK   0xFFF0
> -
> -#define MCH_PAM0  0x90
> -#define MCH_PAM1  0x91
> -#define MCH_PAM2  0x92
> -#define MCH_PAM3  0x93
> -#define MCH_PAM4  0x94
> -#define MCH_PAM5  0x95
> -#define MCH_PAM6  0x96
> -
> -#define MCH_SMRAM 0x9D
> -#define MCH_SMRAM_D_LCK BIT4
> -#define MCH_SMRAM_G_SMRAME  BIT3
> -
> -#define MCH_ESMRAMC   0x9E
> -#define MCH_ESMRAMC_H_SMRAMEBIT7
> -#define MCH_ESMRAMC_E_SMERR BIT6
> -#define MCH_ESMRAMC_SM_CACHEBIT5
> -#define MCH_ESMRAMC_SM_L1   BIT4
> -#define MCH_ESMRAMC_SM_L2   BIT3
> -#define MCH_ESMRAMC_TSEG_EXT(BIT2 | BIT1)
> -#define MCH_ESMRAMC_TSEG_8MBBIT2
> -#define MCH_ESMRAMC_TSEG_2MBBIT1
> -#define MCH_ESMRAMC_TSEG_1MB0
> -#define MCH_ESMRAMC_TSEG_MASK   (BIT2 | BIT1)
> -#define MCH_ESMRAMC_T_ENBIT0
> -
> -#define MCH_GBSM  0xA4
> -#define MCH_GBSM_MB_SHIFT   20
> -
> -#define MCH_BGSM  0xA8
> -#define MCH_BGSM_MB_SHIFT   20
> -
> -#define MCH_TSEGMB0xAC
> -#define MCH_TSEGMB_MB_SHIFT 20
> -
> -#define MCH_TOLUD 0xB0
> -#define MCH_TOLUD_MB_SHIFT  4
> +#define MCH_EXT_TSEG_MB   0x50
> +#define MCH_EXT_TSEG_MB_QUERY   0x
> +
> +#define MCH_GGC   0x52
> +#define MCH_GGC_IVD BIT1
> +
> +#define MCH_PCIEXBAR_LOW  0x60
> +#define MCH_PCIEXBAR_LOWMASK0x0FFF
> +#define MCH_PCIEXBAR_BUS_FF 0
> +#define MCH_PCIEXBAR_EN BIT0
> +
> +#define MCH_PCIEXBAR_HIGH 0x64
> +#define MCH_PCIEXBAR_HIGHMASK   0xFFF0
> +
> +#define MCH_PAM0  0x90
> +#define MCH_PAM1  0x91
> +#define MCH_PAM2  0x92
> +#define MCH_PAM3  0x93
> +#define MCH_PAM4  0x94
> +#define MCH_PAM5  0x95
> +#define MCH_PAM6  0x96
> +
> +#define MCH_SMRAM 0x9D
> +#define MCH_SMRAM_D_LCK BIT4
> +#define MCH_SMRAM_G_SMRAME  BIT3
> +
> +#define MCH_ESMRAMC   0x9E
> +#define MCH_ESMRAMC_H_SMRAMEBIT7
> +#define MCH_ESMRAMC_E_SMERR BIT6
> +#define MCH_ESMRAMC_SM_CACHEBIT5
> +#define MCH_ESMRAMC_SM_L1   BIT4
> +#define MCH_ESMRAMC_SM_L2   BIT3
> +#define MCH_ESMRAMC_TSEG_EXT(BIT2 | BIT1)
> +#define MCH_ESMRAMC_TSEG_8MBBIT2
> +#define MCH_ESMRAMC_TSEG_2MBBIT1
> +#define MCH_ESMRAMC_TSEG_1MB0
> +#define MCH_ESMRAMC_TSEG_MASK   (BIT2 | BIT1)
> +#define MCH_ESMRAMC_T_ENBIT0
> +
> +#define MCH_GBSM  0xA4
> +#define MCH_GBSM_MB_SHIFT   20
> +
> +#define MCH_BGSM  0xA8
> +#define MCH_BGSM_MB_SHIFT   20
> +
> +#define MCH_TSEGMB0xAC
> +#define MCH_TSEGMB_MB_SHIFT 20
> +
> +#define MCH_TOLUD 0xB0
> +#define MCH_TOLUD_MB_SHIFT  4
>  
>  //
>  // B/D/F/Type: 0/0x1f/0/PCI
> 

Reviewed-by: Philippe Mathieu-Daude 
Tested-by: Philippe Mathieu-Daude 

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

View/Reply Online (#47936): https://edk2.groups.io/g/devel/message/47936
Mute This Topic: https://groups.io/mt/34274937/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub

Re: [edk2-devel] [PATCH wave 1 04/10] OvmfPkg/PlatformPei: factor out Q35BoardVerification()

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/24/19 1:34 PM, Laszlo Ersek wrote:
> Before adding another SMM-related, and therefore Q35-only, dynamically
> detectable feature, extract the current board type check from
> Q35TsegMbytesInitialization() to a standalone function.
> 
> Cc: Ard Biesheuvel 
> Cc: Boris Ostrovsky 
> Cc: Brijesh Singh 
> Cc: Igor Mammedov 
> Cc: Jiewen Yao 
> Cc: Joao M Martins 
> Cc: Jordan Justen 
> Cc: Jun Nakajima 
> Cc: Michael Kinney 
> Cc: Paolo Bonzini 
> Cc: Phillip Goerl 
> Cc: Yingwen Chen 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/PlatformPei/MemDetect.c | 13 +--
>  OvmfPkg/PlatformPei/Platform.c  | 23 
>  2 files changed, 24 insertions(+), 12 deletions(-)
> 
> diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
> index d451989f31c9..58b171fba1c8 100644
> --- a/OvmfPkg/PlatformPei/MemDetect.c
> +++ b/OvmfPkg/PlatformPei/MemDetect.c
> @@ -53,18 +53,7 @@ Q35TsegMbytesInitialization (
>UINT16ExtendedTsegMbytes;
>RETURN_STATUS PcdStatus;
>  
> -  if (mHostBridgeDevId != INTEL_Q35_MCH_DEVICE_ID) {
> -DEBUG ((
> -  DEBUG_ERROR,
> -  "%a: no TSEG (SMRAM) on host bridge DID=0x%04x; "
> -  "only DID=0x%04x (Q35) is supported\n",
> -  __FUNCTION__,
> -  mHostBridgeDevId,
> -  INTEL_Q35_MCH_DEVICE_ID
> -  ));
> -ASSERT (FALSE);
> -CpuDeadLoop ();
> -  }
> +  ASSERT (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID);
>  
>//
>// Check if QEMU offers an extended TSEG.
> diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
> index 3ba2459872d9..ca6d37cb1549 100644
> --- a/OvmfPkg/PlatformPei/Platform.c
> +++ b/OvmfPkg/PlatformPei/Platform.c
> @@ -563,6 +563,28 @@ S3Verification (
>  }
>  
>  
> +VOID
> +Q35BoardVerification (
> +  VOID
> +  )
> +{
> +  if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
> +return;
> +  }
> +
> +  DEBUG ((
> +DEBUG_ERROR,
> +"%a: no TSEG (SMRAM) on host bridge DID=0x%04x; "
> +"only DID=0x%04x (Q35) is supported\n",
> +__FUNCTION__,
> +mHostBridgeDevId,
> +INTEL_Q35_MCH_DEVICE_ID
> +));
> +  ASSERT (FALSE);
> +  CpuDeadLoop ();
> +}
> +
> +
>  /**
>Fetch the number of boot CPUs from QEMU and expose it to UefiCpuPkg 
> modules.
>Set the mMaxCpuCount variable.
> @@ -646,6 +668,7 @@ InitializePlatform (
>mHostBridgeDevId = PciRead16 (OVMF_HOSTBRIDGE_DID);
>  
>if (FeaturePcdGet (PcdSmmSmramRequire)) {
> +Q35BoardVerification ();
>  Q35TsegMbytesInitialization ();
>}
>  
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

[edk2-devel] [PATCH wave 1 08/10] OvmfPkg/SEV: don't manage the lifecycle of the SMRAM at the default SMBASE

2019-09-24 Thread Laszlo Ersek

When OVMF runs in a SEV guest, the initial SMM Save State Map is

(1) allocated as EfiBootServicesData type memory in OvmfPkg/PlatformPei,
function AmdSevInitialize(), for preventing unintended information
sharing with the hypervisor;

(2) decrypted in AmdSevDxe;

(3) re-encrypted in OvmfPkg/Library/SmmCpuFeaturesLib, function
SmmCpuFeaturesSmmRelocationComplete(), which is called by
PiSmmCpuDxeSmm right after initial SMBASE relocation;

(4) released to DXE at the same location.

The SMRAM at the default SMBASE is a superset of the initial Save State
Map. The reserved memory allocation in InitializeRamRegions(), from the
previous patch, must override the allocating and freeing in (1) and (4),
respectively. (Note: the decrypting and re-encrypting in (2) and (3) are
unaffected.)

In AmdSevInitialize(), only assert the containment of the initial Save
State Map, in the larger area already allocated by InitializeRamRegions().

In SmmCpuFeaturesSmmRelocationComplete(), preserve the allocation of the
initial Save State Map into OS runtime, as part of the allocation done by
InitializeRamRegions(). Only assert containment.

These changes only affect the normal boot path (the UEFI memory map is
untouched during S3 resume).

Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Brijesh Singh 
Cc: Igor Mammedov 
Cc: Jiewen Yao 
Cc: Joao M Martins 
Cc: Jordan Justen 
Cc: Jun Nakajima 
Cc: Michael Kinney 
Cc: Paolo Bonzini 
Cc: Phillip Goerl 
Cc: Yingwen Chen 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf |  4 
 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c   | 21 +++--
 OvmfPkg/PlatformPei/AmdSev.c| 24 

 3 files changed, 42 insertions(+), 7 deletions(-)

diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
index dd316f2b1bd8..97a10afb6e27 100644
--- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
@@ -30,5 +30,9 @@ [LibraryClasses]
   BaseMemoryLib
   DebugLib
   MemEncryptSevLib
+  PcdLib
   SmmServicesTableLib
   UefiBootServicesTableLib
+
+[Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase
diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
index 0bfdeda78d33..7ef7ed98342e 100644
--- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
@@ -6,14 +6,17 @@
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 //
@@ -215,8 +218,22 @@ SmmCpuFeaturesSmmRelocationComplete (
 
   ZeroMem ((VOID *)MapPagesBase, EFI_PAGES_TO_SIZE (MapPagesCount));
 
-  Status = gBS->FreePages (MapPagesBase, MapPagesCount);
-  ASSERT_EFI_ERROR (Status);
+  if (PcdGetBool (PcdQ35SmramAtDefaultSmbase)) {
+//
+// The initial SMRAM Save State Map has been covered as part of a larger
+// reserved memory allocation in PlatformPei's InitializeRamRegions(). That
+// allocation is supposed to survive into OS runtime; we must not release
+// any part of it. Only re-assert the containment here.
+//
+ASSERT (SMM_DEFAULT_SMBASE <= MapPagesBase);
+ASSERT (
+  (MapPagesBase + EFI_PAGES_TO_SIZE (MapPagesCount) <=
+   SMM_DEFAULT_SMBASE + MCH_DEFAULT_SMBASE_SIZE)
+  );
+  } else {
+Status = gBS->FreePages (MapPagesBase, MapPagesCount);
+ASSERT_EFI_ERROR (Status);
+  }
 }
 
 /**
diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
index 2ae8126ccf8a..e484f4b311fe 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/PlatformPei/AmdSev.c
@@ -9,6 +9,7 @@
 //
 // The package level header files this module uses
 //
+#include 
 #include 
 #include 
 #include 
@@ -16,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "Platform.h"
 
@@ -83,10 +85,22 @@ AmdSevInitialize (
 );
 ASSERT_RETURN_ERROR (LocateMapStatus);
 
-BuildMemoryAllocationHob (
-  MapPagesBase,  // BaseAddress
-  EFI_PAGES_TO_SIZE (MapPagesCount), // Length
-  EfiBootServicesData// MemoryType
-  );
+if (mQ35SmramAtDefaultSmbase) {
+  //
+  // The initial SMRAM Save State Map has been covered as part of a larger
+  // reserved memory allocation in InitializeRamRegions().
+  //
+  ASSERT (SMM_DEFAULT_SMBASE <= MapPagesBase);
+  ASSERT (
+(MapPagesBase + EFI_PAGES_TO_SIZE (MapPagesCount) <=
+ SMM_DEFAULT_SMBASE + MCH_DEFAULT_SMBASE_SIZE)
+);
+} else {
+  BuildMemoryAllocationHob (
+MapPagesBase,  // BaseAddress
+EFI_PAGES_TO_SIZE

[edk2-devel] [PATCH wave 1 10/10] OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real)

2019-09-24 Thread Laszlo Ersek

Now that the SMRAM at the default SMBASE is honored everywhere necessary,
implement the actual detection. The (simple) steps are described in
previous patch "OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register
macros".

Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Brijesh Singh 
Cc: Igor Mammedov 
Cc: Jiewen Yao 
Cc: Joao M Martins 
Cc: Jordan Justen 
Cc: Jun Nakajima 
Cc: Michael Kinney 
Cc: Paolo Bonzini 
Cc: Phillip Goerl 
Cc: Yingwen Chen 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/MemDetect.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 8fdc9c2ed7c9..3364193b4952 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -98,14 +98,23 @@ Q35SmramAtDefaultSmbaseInitialization (
   VOID
   )
 {
+  UINTN CtlReg;
+  UINT8 CtlRegVal;
   RETURN_STATUS PcdStatus;
 
   ASSERT (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID);
 
-  mQ35SmramAtDefaultSmbase = FALSE;
+  CtlReg = DRAMC_REGISTER_Q35 (MCH_DEFAULT_SMBASE_CTL);
+  PciWrite8 (CtlReg, MCH_DEFAULT_SMBASE_QUERY);
+  CtlRegVal = PciRead8 (CtlReg);
+
+  mQ35SmramAtDefaultSmbase = (BOOLEAN)(CtlRegVal == MCH_DEFAULT_SMBASE_IN_RAM);
   PcdStatus = PcdSetBoolS (PcdQ35SmramAtDefaultSmbase,
 mQ35SmramAtDefaultSmbase);
   ASSERT_RETURN_ERROR (PcdStatus);
+  if (mQ35SmramAtDefaultSmbase) {
+DEBUG ((DEBUG_INFO, "%a: SMRAM at default SMBASE found\n", __FUNCTION__));
+  }
 }
 
 
-- 
2.19.1.3.g30247aa5d201


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

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

[edk2-devel] [PATCH wave 1 06/10] OvmfPkg/PlatformPei: assert there's no permanent PEI RAM at default SMBASE

2019-09-24 Thread Laszlo Ersek

The permanent PEI RAM that is published on the normal boot path starts
strictly above MEMFD_BASE_ADDRESS (8 MB -- see the FDF files), regardless
of whether PEI decompression will be necessary on S3 resume due to
SMM_REQUIRE. Therefore the normal boot permanent PEI RAM never overlaps
with the SMRAM at the default SMBASE (192 KB).

The S3 resume permanent PEI RAM is strictly above the normal boot one.
Therefore the no-overlap statement holds true on the S3 resume path as
well.

Assert the no-overlap condition commonly for both boot paths in
PublishPeiMemory().

Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Brijesh Singh 
Cc: Igor Mammedov 
Cc: Jiewen Yao 
Cc: Joao M Martins 
Cc: Jordan Justen 
Cc: Jun Nakajima 
Cc: Michael Kinney 
Cc: Paolo Bonzini 
Cc: Phillip Goerl 
Cc: Yingwen Chen 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/MemDetect.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 2bc1c46dffc2..4879ee87b797 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -17,6 +17,7 @@ Module Name:
 #include 
 #include 
 #include 
+#include 
 
 //
 // The Library classes this module consumes
@@ -626,6 +627,15 @@ PublishPeiMemory (
 }
   }
 
+  //
+  // MEMFD_BASE_ADDRESS separates the SMRAM at the default SMBASE from the
+  // normal boot permanent PEI RAM. Regarding the S3 boot path, the S3
+  // permanent PEI RAM is located even higher.
+  //
+  if (FeaturePcdGet (PcdSmmSmramRequire) && mQ35SmramAtDefaultSmbase) {
+ASSERT (SMM_DEFAULT_SMBASE + MCH_DEFAULT_SMBASE_SIZE <= MemoryBase);
+  }
+
   //
   // Publish this memory to the PEI Core
   //
-- 
2.19.1.3.g30247aa5d201



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

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

[edk2-devel] [PATCH wave 1 04/10] OvmfPkg/PlatformPei: factor out Q35BoardVerification()

2019-09-24 Thread Laszlo Ersek

Before adding another SMM-related, and therefore Q35-only, dynamically
detectable feature, extract the current board type check from
Q35TsegMbytesInitialization() to a standalone function.

Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Brijesh Singh 
Cc: Igor Mammedov 
Cc: Jiewen Yao 
Cc: Joao M Martins 
Cc: Jordan Justen 
Cc: Jun Nakajima 
Cc: Michael Kinney 
Cc: Paolo Bonzini 
Cc: Phillip Goerl 
Cc: Yingwen Chen 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/MemDetect.c | 13 +--
 OvmfPkg/PlatformPei/Platform.c  | 23 
 2 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index d451989f31c9..58b171fba1c8 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -53,18 +53,7 @@ Q35TsegMbytesInitialization (
   UINT16ExtendedTsegMbytes;
   RETURN_STATUS PcdStatus;
 
-  if (mHostBridgeDevId != INTEL_Q35_MCH_DEVICE_ID) {
-DEBUG ((
-  DEBUG_ERROR,
-  "%a: no TSEG (SMRAM) on host bridge DID=0x%04x; "
-  "only DID=0x%04x (Q35) is supported\n",
-  __FUNCTION__,
-  mHostBridgeDevId,
-  INTEL_Q35_MCH_DEVICE_ID
-  ));
-ASSERT (FALSE);
-CpuDeadLoop ();
-  }
+  ASSERT (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID);
 
   //
   // Check if QEMU offers an extended TSEG.
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 3ba2459872d9..ca6d37cb1549 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -563,6 +563,28 @@ S3Verification (
 }
 
 
+VOID
+Q35BoardVerification (
+  VOID
+  )
+{
+  if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
+return;
+  }
+
+  DEBUG ((
+DEBUG_ERROR,
+"%a: no TSEG (SMRAM) on host bridge DID=0x%04x; "
+"only DID=0x%04x (Q35) is supported\n",
+__FUNCTION__,
+mHostBridgeDevId,
+INTEL_Q35_MCH_DEVICE_ID
+));
+  ASSERT (FALSE);
+  CpuDeadLoop ();
+}
+
+
 /**
   Fetch the number of boot CPUs from QEMU and expose it to UefiCpuPkg modules.
   Set the mMaxCpuCount variable.
@@ -646,6 +668,7 @@ InitializePlatform (
   mHostBridgeDevId = PciRead16 (OVMF_HOSTBRIDGE_DID);
 
   if (FeaturePcdGet (PcdSmmSmramRequire)) {
+Q35BoardVerification ();
 Q35TsegMbytesInitialization ();
   }
 
-- 
2.19.1.3.g30247aa5d201



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

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

[edk2-devel] [PATCH wave 1 01/10] OvmfPkg: introduce PcdQ35SmramAtDefaultSmbase

2019-09-24 Thread Laszlo Ersek

For supporting VCPU hotplug with SMM enabled/required, QEMU offers the
(dynamically detectable) feature called "SMRAM at default SMBASE". When
the feature is enabled, the firmware can lock down the 128 KB range
starting at the default SMBASE; that is, the [0x3_, 0x4_]
interval. The goal is to shield the very first SMI handler of the
hotplugged VCPU from OS influence.

Multiple modules in OVMF will have to inter-operate for locking down this
range. Introduce a dynamic PCD that will reflect the feature (to be
negotiated by PlatformPei), for coordination between drivers.

Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Brijesh Singh 
Cc: Igor Mammedov 
Cc: Jiewen Yao 
Cc: Joao M Martins 
Cc: Jordan Justen 
Cc: Jun Nakajima 
Cc: Michael Kinney 
Cc: Paolo Bonzini 
Cc: Phillip Goerl 
Cc: Yingwen Chen 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec| 6 ++
 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 4 files changed, 9 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index d5fee805ef4a..57034c784f88 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -257,6 +257,12 @@ [PcdsDynamic, PcdsDynamicEx]
   #  This PCD is only accessed if PcdSmmSmramRequire is TRUE (see below).
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8|UINT16|0x20
 
+  ## Set to TRUE by PlatformPei if the Q35 board supports the "SMRAM at default
+  #  SMBASE" feature.
+  #
+  #  This PCD is only accessed if PcdSmmSmramRequire is TRUE (see below).
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase|FALSE|BOOLEAN|0x34
+
 [PcdsFeatureFlag]
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderPciTranslation|TRUE|BOOLEAN|0x1c
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderMmioTranslation|FALSE|BOOLEAN|0x1d
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 66e944436a69..8a970a40cc62 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -561,6 +561,7 @@ [PcdsDynamicDefault]
 
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase|FALSE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|10
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 51c2bfb44f14..2a3ba9ec2ca1 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -573,6 +573,7 @@ [PcdsDynamicDefault]
 
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase|FALSE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|10
 !endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index ba7a75884490..17a135a8edfe 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -572,6 +572,7 @@ [PcdsDynamicDefault]
 
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase|FALSE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|10
 !endif
-- 
2.19.1.3.g30247aa5d201



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

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

[edk2-devel] [PATCH wave 1 09/10] OvmfPkg/SmmAccess: close and lock SMRAM at default SMBASE

2019-09-24 Thread Laszlo Ersek

During normal boot, when EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed
by platform BDS, the SMM IPL locks SMRAM (TSEG) through
EFI_SMM_ACCESS2_PROTOCOL.Lock(). See SmmIplReadyToLockEventNotify() in
"MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c".

During S3 resume, S3Resume2Pei locks SMRAM (TSEG) through
PEI_SMM_ACCESS_PPI.Lock(), before executing the boot script. See
S3ResumeExecuteBootScript() in
"UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c".

Those are precisely the places where the SMRAM at the default SMBASE
should be locked too. Add such an action to SmramAccessLock().

Notes:

- The SMRAM at the default SMBASE doesn't support the "closed and
  unlocked" state (and so it can't be closed without locking it, and it
  cannot be opened after closing it).

- The SMRAM at the default SMBASE isn't (and shouldn't) be exposed with
  another EFI_SMRAM_DESCRIPTOR in the GetCapabilities() members of
  EFI_SMM_ACCESS2_PROTOCOL / PEI_SMM_ACCESS_PPI. That's because the SMRAM
  in question is not "general purpose"; it's only QEMU's solution to
  protect the initial SMI handler from the OS, when a VCPU is hot-plugged.

  Consequently, the state of the SMRAM at the default SMBASE is not
  reflected in the "OpenState" / "LockState" fields of the protocol and
  PPI.

- An alternative to extending SmramAccessLock() would be to register an
  EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL notify in SmmAccess2Dxe (for locking
  at normal boot), and an EDKII_S3_SMM_INIT_DONE_GUID PPI notify in
  SmmAccessPei (for locking at S3 resume).

Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Brijesh Singh 
Cc: Igor Mammedov 
Cc: Jiewen Yao 
Cc: Joao M Martins 
Cc: Jordan Justen 
Cc: Jun Nakajima 
Cc: Michael Kinney 
Cc: Paolo Bonzini 
Cc: Phillip Goerl 
Cc: Yingwen Chen 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/SmmAccess/SmmAccess2Dxe.inf |  1 +
 OvmfPkg/SmmAccess/SmmAccessPei.inf  |  1 +
 OvmfPkg/SmmAccess/SmramInternal.h   |  8 +++
 OvmfPkg/SmmAccess/SmmAccess2Dxe.c   |  7 ++
 OvmfPkg/SmmAccess/SmmAccessPei.c|  6 +
 OvmfPkg/SmmAccess/SmramInternal.c   | 25 
 6 files changed, 48 insertions(+)

diff --git a/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf 
b/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
index 7ced6b4e7ff4..d86381d0fbe2 100644
--- a/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+++ b/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
@@ -49,6 +49,7 @@ [FeaturePcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
 
 [Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
 
 [Depex]
diff --git a/OvmfPkg/SmmAccess/SmmAccessPei.inf 
b/OvmfPkg/SmmAccess/SmmAccessPei.inf
index d73a029cc790..1698c4ce6c92 100644
--- a/OvmfPkg/SmmAccess/SmmAccessPei.inf
+++ b/OvmfPkg/SmmAccess/SmmAccessPei.inf
@@ -54,6 +54,7 @@ [FeaturePcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
 
 [Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
 
 [Ppis]
diff --git a/OvmfPkg/SmmAccess/SmramInternal.h 
b/OvmfPkg/SmmAccess/SmramInternal.h
index 74d962b4ecae..a4d8827adfe4 100644
--- a/OvmfPkg/SmmAccess/SmramInternal.h
+++ b/OvmfPkg/SmmAccess/SmramInternal.h
@@ -38,6 +38,14 @@ InitQ35TsegMbytes (
   VOID
   );
 
+/**
+  Save PcdQ35SmramAtDefaultSmbase into mQ35SmramAtDefaultSmbase.
+**/
+VOID
+InitQ35SmramAtDefaultSmbase (
+  VOID
+  );
+
 /**
   Read the MCH_SMRAM and ESMRAMC registers, and update the LockState and
   OpenState fields in the PEI_SMM_ACCESS_PPI / EFI_SMM_ACCESS2_PROTOCOL object,
diff --git a/OvmfPkg/SmmAccess/SmmAccess2Dxe.c 
b/OvmfPkg/SmmAccess/SmmAccess2Dxe.c
index e098f6f15f77..3691a6cd1f10 100644
--- a/OvmfPkg/SmmAccess/SmmAccess2Dxe.c
+++ b/OvmfPkg/SmmAccess/SmmAccess2Dxe.c
@@ -145,6 +145,13 @@ SmmAccess2DxeEntryPoint (
 
   InitQ35TsegMbytes ();
   GetStates (, );
+
+  //
+  // SmramAccessLock() depends on "mQ35SmramAtDefaultSmbase"; init the latter
+  // just before exposing the former via EFI_SMM_ACCESS2_PROTOCOL.Lock().
+  //
+  InitQ35SmramAtDefaultSmbase ();
+
   return gBS->InstallMultipleProtocolInterfaces (,
 , ,
 NULL);
diff --git a/OvmfPkg/SmmAccess/SmmAccessPei.c b/OvmfPkg/SmmAccess/SmmAccessPei.c
index d67850651c58..c8bbc17e907a 100644
--- a/OvmfPkg/SmmAccess/SmmAccessPei.c
+++ b/OvmfPkg/SmmAccess/SmmAccessPei.c
@@ -372,6 +372,12 @@ SmmAccessPeiEntryPoint (
   CopyMem (GuidHob, [DescIdxSmmS3ResumeState],
 sizeof SmramMap[DescIdxSmmS3ResumeState]);
 
+  //
+  // SmramAccessLock() depends on "mQ35SmramAtDefaultSmbase"; init the latter
+  // just before exposing the former via PEI_SMM_ACCESS_PPI.Lock().
+  //
+  InitQ35SmramAtDefaultSmbase ();
+
   //
   // We're done. The next step should succeed, but even if it fails, we can't
   // roll back the above BuildGuidHob() allocation, because PEI doesn't support
diff --git a/OvmfPkg/SmmAccess/SmramInternal.c 
b/OvmfPkg/SmmAccess/SmramInternal.c
index 09657d0f9b0f..0b07dc667b3f 100644
---

[edk2-devel] [PATCH wave 1 07/10] OvmfPkg/PlatformPei: reserve the SMRAM at the default SMBASE, if it exists

2019-09-24 Thread Laszlo Ersek

The 128KB SMRAM at the default SMBASE will be used for protecting the
initial SMI handler for hot-plugged VCPUs. After platform reset, the SMRAM
in question is open (and looks just like RAM). When BDS signals
EFI_DXE_MM_READY_TO_LOCK_PROTOCOL (and so TSEG is locked down), we're
going to lock the SMRAM at the default SMBASE too.

For this, we have to reserve said SMRAM area as early as possible, from
components in PEI, DXE, and OS runtime.

* QemuInitializeRam() currently produces a single resource descriptor HOB,
  for exposing the system RAM available under 1GB. This occurs during both
  normal boot and S3 resume identically (the latter only for the sake of
  CpuMpPei borrowing low RAM for the AP startup vector).

  But, the SMRAM at the default SMBASE falls in the middle of the current
  system RAM HOB. Split the HOB, and cover the SMRAM with a reserved
  memory HOB in the middle. CpuMpPei (via MpInitLib) skips reserved memory
  HOBs.

* InitializeRamRegions() is responsible for producing memory allocation
  HOBs, carving out parts of the resource descriptor HOBs produced in
  QemuInitializeRam(). Allocate the above-introduced reserved memory
  region in full, similarly to how we treat TSEG, so that DXE and the OS
  avoid the locked SMRAM (black hole) in this area.

  (Note that these allocations only occur on the normal boot path, as they
  matter for the UEFI memory map, which cannot be changed during S3
  resume.)

Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Brijesh Singh 
Cc: Igor Mammedov 
Cc: Jiewen Yao 
Cc: Joao M Martins 
Cc: Jordan Justen 
Cc: Jun Nakajima 
Cc: Michael Kinney 
Cc: Paolo Bonzini 
Cc: Phillip Goerl 
Cc: Yingwen Chen 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/MemDetect.c | 37 ++--
 1 file changed, 35 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 4879ee87b797..8fdc9c2ed7c9 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -646,6 +646,28 @@ PublishPeiMemory (
 }
 
 
+STATIC
+VOID
+QemuInitializeRamBelow1gb (
+  VOID
+  )
+{
+  if (FeaturePcdGet (PcdSmmSmramRequire) && mQ35SmramAtDefaultSmbase) {
+AddMemoryRangeHob (0, SMM_DEFAULT_SMBASE);
+AddReservedMemoryBaseSizeHob (SMM_DEFAULT_SMBASE, MCH_DEFAULT_SMBASE_SIZE,
+  TRUE /* Cacheable */);
+STATIC_ASSERT (
+  SMM_DEFAULT_SMBASE + MCH_DEFAULT_SMBASE_SIZE < BASE_512KB + BASE_128KB,
+  "end of SMRAM at default SMBASE ends at, or exceeds, 640KB"
+  );
+AddMemoryRangeHob (SMM_DEFAULT_SMBASE + MCH_DEFAULT_SMBASE_SIZE,
+  BASE_512KB + BASE_128KB);
+  } else {
+AddMemoryRangeHob (0, BASE_512KB + BASE_128KB);
+  }
+}
+
+
 /**
   Peform Memory Detection for QEMU / KVM
 
@@ -690,12 +712,12 @@ QemuInitializeRam (
 // allocation HOBs, and to honor preexistent memory allocation HOBs when
 // looking for an area to borrow.
 //
-AddMemoryRangeHob (0, BASE_512KB + BASE_128KB);
+QemuInitializeRamBelow1gb ();
   } else {
 //
 // Create memory HOBs
 //
-AddMemoryRangeHob (0, BASE_512KB + BASE_128KB);
+QemuInitializeRamBelow1gb ();
 
 if (FeaturePcdGet (PcdSmmSmramRequire)) {
   UINT32 TsegSize;
@@ -861,6 +883,17 @@ InitializeRamRegions (
 TsegSize,
 EfiReservedMemoryType
 );
+  //
+  // Similarly, allocate away the (already reserved) SMRAM at the default
+  // SMBASE, if it exists.
+  //
+  if (mQ35SmramAtDefaultSmbase) {
+BuildMemoryAllocationHob (
+  SMM_DEFAULT_SMBASE,
+  MCH_DEFAULT_SMBASE_SIZE,
+  EfiReservedMemoryType
+  );
+  }
 }
   }
 }
-- 
2.19.1.3.g30247aa5d201



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

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

[edk2-devel] [PATCH wave 1 05/10] OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (skeleton)

2019-09-24 Thread Laszlo Ersek

Introduce the Q35SmramAtDefaultSmbaseInitialization() function for
detecting the "SMRAM at default SMBASE" feature.

For now, the function is only a skeleton, so that we can gradually build
upon the result while the result is hard-coded as FALSE. The actual
detection will occur in a later patch.

Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Brijesh Singh 
Cc: Igor Mammedov 
Cc: Jiewen Yao 
Cc: Joao M Martins 
Cc: Jordan Justen 
Cc: Jun Nakajima 
Cc: Michael Kinney 
Cc: Paolo Bonzini 
Cc: Phillip Goerl 
Cc: Yingwen Chen 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/PlatformPei.inf |  1 +
 OvmfPkg/PlatformPei/Platform.h  |  7 +++
 OvmfPkg/PlatformPei/MemDetect.c | 18 ++
 OvmfPkg/PlatformPei/Platform.c  |  1 +
 4 files changed, 27 insertions(+)

diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index d9fd9c8f05b3..2b0c2c886929 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -84,6 +84,7 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase
   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
diff --git a/OvmfPkg/PlatformPei/Platform.h b/OvmfPkg/PlatformPei/Platform.h
index 2f3cebcd3a6a..43f20f067f22 100644
--- a/OvmfPkg/PlatformPei/Platform.h
+++ b/OvmfPkg/PlatformPei/Platform.h
@@ -52,6 +52,11 @@ Q35TsegMbytesInitialization (
   VOID
   );
 
+VOID
+Q35SmramAtDefaultSmbaseInitialization (
+  VOID
+  );
+
 EFI_STATUS
 PublishPeiMemory (
   VOID
@@ -119,6 +124,8 @@ extern UINT32 mMaxCpuCount;
 
 extern UINT16 mHostBridgeDevId;
 
+extern BOOLEAN mQ35SmramAtDefaultSmbase;
+
 extern UINT32 mQemuUc32Base;
 
 #endif // _PLATFORM_PEI_H_INCLUDED_
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 58b171fba1c8..2bc1c46dffc2 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -43,6 +43,8 @@ STATIC UINT32 mS3AcpiReservedMemorySize;
 
 STATIC UINT16 mQ35TsegMbytes;
 
+BOOLEAN mQ35SmramAtDefaultSmbase;
+
 UINT32 mQemuUc32Base;
 
 VOID
@@ -90,6 +92,22 @@ Q35TsegMbytesInitialization (
 }
 
 
+VOID
+Q35SmramAtDefaultSmbaseInitialization (
+  VOID
+  )
+{
+  RETURN_STATUS PcdStatus;
+
+  ASSERT (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID);
+
+  mQ35SmramAtDefaultSmbase = FALSE;
+  PcdStatus = PcdSetBoolS (PcdQ35SmramAtDefaultSmbase,
+mQ35SmramAtDefaultSmbase);
+  ASSERT_RETURN_ERROR (PcdStatus);
+}
+
+
 VOID
 QemuUc32BaseInitialization (
   VOID
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index ca6d37cb1549..6989712b0645 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -670,6 +670,7 @@ InitializePlatform (
   if (FeaturePcdGet (PcdSmmSmramRequire)) {
 Q35BoardVerification ();
 Q35TsegMbytesInitialization ();
+Q35SmramAtDefaultSmbaseInitialization ();
   }
 
   PublishPeiMemory ();
-- 
2.19.1.3.g30247aa5d201



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

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

[edk2-devel] [PATCH wave 1 03/10] OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register macros

2019-09-24 Thread Laszlo Ersek

In Intel datasheet 316966-002 (the "q35 spec"), Table 5-1 "DRAM Controller
Register Address Map (D0:F0)" leaves the byte register at config space
offset 0x9C unused.

On QEMU's Q35 board, for detecting the "SMRAM at default SMBASE" feature,
firmware is expected to write MCH_DEFAULT_SMBASE_QUERY (0xFF) to offset
MCH_DEFAULT_SMBASE_CTL (0x9C), and read back the register. If the value is
MCH_DEFAULT_SMBASE_IN_RAM (0x01), then the feature is available, and the
range mentioned below is open (accessible to code running outside of SMM).

Then, once firmware writes MCH_DEFAULT_SMBASE_LCK (0x02) to the register,
the MCH_DEFAULT_SMBASE_SIZE (128KB) range at 0x3_ (SMM_DEFAULT_SMBASE)
gets closed and locked down, and the register becomes read-only. The area
is reopened, and the register becomes read/write, at platform reset.

Add the above-listed macros to "Q35MchIch9.h".

(There are some other unused offsets in Table 5-1; for example we had
scavenged 0x50 for implementing the extended TSEG feature. 0x9C is the
first byte-wide register standing in isolation after 0x50.)

Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Brijesh Singh 
Cc: Igor Mammedov 
Cc: Jiewen Yao 
Cc: Joao M Martins 
Cc: Jordan Justen 
Cc: Jun Nakajima 
Cc: Michael Kinney 
Cc: Paolo Bonzini 
Cc: Phillip Goerl 
Cc: Yingwen Chen 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Include/IndustryStandard/Q35MchIch9.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h 
b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
index 614699ab38f1..eac57b10d77e 100644
--- a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
+++ b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
@@ -49,6 +49,12 @@
 #define MCH_PAM5  0x95
 #define MCH_PAM6  0x96
 
+#define MCH_DEFAULT_SMBASE_CTL0x9C
+#define MCH_DEFAULT_SMBASE_QUERY0xFF
+#define MCH_DEFAULT_SMBASE_IN_RAM   0x01
+#define MCH_DEFAULT_SMBASE_LCK  0x02
+#define MCH_DEFAULT_SMBASE_SIZE SIZE_128KB
+
 #define MCH_SMRAM 0x9D
 #define MCH_SMRAM_D_LCK BIT4
 #define MCH_SMRAM_G_SMRAME  BIT3
-- 
2.19.1.3.g30247aa5d201



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

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

[edk2-devel] [PATCH wave 1 02/10] OvmfPkg/IndustryStandard: increase vertical whitespace in Q35 macro defs

2019-09-24 Thread Laszlo Ersek

In a subsequent patch, we'll introduce new DRAM controller macros in
"Q35MchIch9.h". Their names are too long for the currently available
vertical whitespace, so increase the latter first.

There is no functional change in this patch ("git show -b" displays
nothing).

Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Brijesh Singh 
Cc: Igor Mammedov 
Cc: Jiewen Yao 
Cc: Joao M Martins 
Cc: Jordan Justen 
Cc: Jun Nakajima 
Cc: Michael Kinney 
Cc: Paolo Bonzini 
Cc: Phillip Goerl 
Cc: Yingwen Chen 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Include/IndustryStandard/Q35MchIch9.h | 100 ++--
 1 file changed, 50 insertions(+), 50 deletions(-)

diff --git a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h 
b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
index 391cb466..614699ab38f1 100644
--- a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
+++ b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
@@ -27,56 +27,56 @@
 //
 #define DRAMC_REGISTER_Q35(Offset) PCI_LIB_ADDRESS (0, 0, 0, (Offset))
 
-#define MCH_EXT_TSEG_MB   0x50
-#define MCH_EXT_TSEG_MB_QUERY   0x
-
-#define MCH_GGC   0x52
-#define MCH_GGC_IVD BIT1
-
-#define MCH_PCIEXBAR_LOW  0x60
-#define MCH_PCIEXBAR_LOWMASK0x0FFF
-#define MCH_PCIEXBAR_BUS_FF 0
-#define MCH_PCIEXBAR_EN BIT0
-
-#define MCH_PCIEXBAR_HIGH 0x64
-#define MCH_PCIEXBAR_HIGHMASK   0xFFF0
-
-#define MCH_PAM0  0x90
-#define MCH_PAM1  0x91
-#define MCH_PAM2  0x92
-#define MCH_PAM3  0x93
-#define MCH_PAM4  0x94
-#define MCH_PAM5  0x95
-#define MCH_PAM6  0x96
-
-#define MCH_SMRAM 0x9D
-#define MCH_SMRAM_D_LCK BIT4
-#define MCH_SMRAM_G_SMRAME  BIT3
-
-#define MCH_ESMRAMC   0x9E
-#define MCH_ESMRAMC_H_SMRAMEBIT7
-#define MCH_ESMRAMC_E_SMERR BIT6
-#define MCH_ESMRAMC_SM_CACHEBIT5
-#define MCH_ESMRAMC_SM_L1   BIT4
-#define MCH_ESMRAMC_SM_L2   BIT3
-#define MCH_ESMRAMC_TSEG_EXT(BIT2 | BIT1)
-#define MCH_ESMRAMC_TSEG_8MBBIT2
-#define MCH_ESMRAMC_TSEG_2MBBIT1
-#define MCH_ESMRAMC_TSEG_1MB0
-#define MCH_ESMRAMC_TSEG_MASK   (BIT2 | BIT1)
-#define MCH_ESMRAMC_T_ENBIT0
-
-#define MCH_GBSM  0xA4
-#define MCH_GBSM_MB_SHIFT   20
-
-#define MCH_BGSM  0xA8
-#define MCH_BGSM_MB_SHIFT   20
-
-#define MCH_TSEGMB0xAC
-#define MCH_TSEGMB_MB_SHIFT 20
-
-#define MCH_TOLUD 0xB0
-#define MCH_TOLUD_MB_SHIFT  4
+#define MCH_EXT_TSEG_MB   0x50
+#define MCH_EXT_TSEG_MB_QUERY   0x
+
+#define MCH_GGC   0x52
+#define MCH_GGC_IVD BIT1
+
+#define MCH_PCIEXBAR_LOW  0x60
+#define MCH_PCIEXBAR_LOWMASK0x0FFF
+#define MCH_PCIEXBAR_BUS_FF 0
+#define MCH_PCIEXBAR_EN BIT0
+
+#define MCH_PCIEXBAR_HIGH 0x64
+#define MCH_PCIEXBAR_HIGHMASK   0xFFF0
+
+#define MCH_PAM0  0x90
+#define MCH_PAM1  0x91
+#define MCH_PAM2  0x92
+#define MCH_PAM3  0x93
+#define MCH_PAM4  0x94
+#define MCH_PAM5  0x95
+#define MCH_PAM6  0x96
+
+#define MCH_SMRAM 0x9D
+#define MCH_SMRAM_D_LCK BIT4
+#define MCH_SMRAM_G_SMRAME  BIT3
+
+#define MCH_ESMRAMC   0x9E
+#define MCH_ESMRAMC_H_SMRAMEBIT7
+#define MCH_ESMRAMC_E_SMERR BIT6
+#define MCH_ESMRAMC_SM_CACHEBIT5
+#define MCH_ESMRAMC_SM_L1   BIT4
+#define MCH_ESMRAMC_SM_L2   BIT3
+#define MCH_ESMRAMC_TSEG_EXT(BIT2 | BIT1)
+#define MCH_ESMRAMC_TSEG_8MBBIT2
+#define MCH_ESMRAMC_TSEG_2MBBIT1
+#define MCH_ESMRAMC_TSEG_1MB0
+#define MCH_ESMRAMC_TSEG_MASK   (BIT2 | BIT1)
+#define MCH_ESMRAMC_T_ENBIT0
+
+#define MCH_GBSM  0xA4
+#define MCH_GBSM_MB_SHIFT   20
+
+#define MCH_BGSM  0xA8
+#define MCH_BGSM_MB_SHIFT   20
+
+#define MCH_TSEGMB0xAC
+#define MCH_TSEGMB_MB_SHIFT 20
+
+#define MCH_TOLUD 0xB0
+#define MCH_TOLUD_MB_SHIFT  4
 
 //
 // B/D/F/Type: 0/0x1f/0/PCI
-- 
2.19.1.3.g30247aa5d201



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

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

[edk2-devel] [PATCH wave 1 00/10] support QEMU's "SMRAM at default SMBASE" feature

2019-09-24 Thread Laszlo Ersek

Ref:https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Repo:   https://github.com/lersek/edk2.git
Branch: smram_at_default_smbase_bz_1512_wave_1

This is the firmware-side patch series for the QEMU feature that Igor is
proposing in

  [Qemu-devel] [PATCH 0/2]
  q35: mch: allow to lock down 128K RAM at default SMBASE address

posted at

  20190917130708.10281-1-imammedo@redhat.com">http://mid.mail-archive.com/20190917130708.10281-1-imammedo@redhat.com
  https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03538.html
  https://edk2.groups.io/g/devel/message/47364

This OVMF patch series is supposed to be the first "wave" of patch sets,
working towards VCPU hotplug with SMM enabled.

We want the hot-plugged VCPU to execute its very first instruction from
SMRAM, running in SMM, for protection from OS and PCI DMA interference.
In the (long!) discussion at

  20190905174503.2acaa46a@redhat.com">http://mid.mail-archive.com/20190905174503.2acaa46a@redhat.com
  https://edk2.groups.io/g/devel/message/46910
  https://bugzilla.tianocore.org/show_bug.cgi?id=1512#c9

we considered diverging from the specs and changing the default SMBASE
to an address different from 0x3_, so that it would point into
SMRAM. However, Igor had the idea to keep the default SMBASE intact, and
replace the underlying system RAM (128 KB of it) with lockable SMRAM.
This conforms to the language of the Intel SDM, namely, "[t]he actual
physical location of the SMRAM can be in system memory or in a separate
RAM memory". When firmware locks this QEMU-specific SMRAM, the latter
completely disappears from the address space of code that runs outside
of SMM (including PCI devices doing DMA). We call the remaining MMIO
area a "black hole".

The present patch set detects the QEMU feature, locks the SMRAM at the
right times, and informs firmware and OS components to stay away form
the SMRAM at the default SMBASE.

I've tested the set extensively:

  c18f1ada-3eca-d5f1-da4f-e74181c5a862@redhat.com">http://mid.mail-archive.com/c18f1ada-3eca-d5f1-da4f-e74181c5a862@redhat.com
  https://edk2.groups.io/g/devel/message/47864

Going forward, if I understand correctly, the plan is to populate the
new SMRAM with the hotplug SMI handler. (This would likely be put in
place by OvmfPkg/PlatformPei, from NASM source code. The
SmmRelocateBases() function in UefiCpuPkg/PiSmmCpuDxeSmm backs up the
original contents before, and restores them after, the initial SMBASE
relocation of the cold-plugged VCPUs. Thus the hotplug SMI handler would
survive the initial relocation of the cold-plugged VCPUs.)

Further, when a VCPU is hot-plugged, we seem to intend to raise an SMI
for it (perhaps internally to QEMU?), which will remain pending until
the VCPU is launched with INIT-SIPI-SIPI. Once the INIT-SIPI-SIPI is
sent, the VCPU will immediately enter SMM, and run the SMI handler in
the locked SMRAM at the default SMBASE. At RSM, it may continue at the
vector requested in the INIT-SIPI-SIPI.

Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Brijesh Singh 
Cc: Igor Mammedov 
Cc: Jiewen Yao 
Cc: Joao M Martins 
Cc: Jordan Justen 
Cc: Jun Nakajima 
Cc: Michael Kinney 
Cc: Paolo Bonzini 
Cc: Phillip Goerl 
Cc: Yingwen Chen 

Thanks
Laszlo

Laszlo Ersek (10):
  OvmfPkg: introduce PcdQ35SmramAtDefaultSmbase
  OvmfPkg/IndustryStandard: increase vertical whitespace in Q35 macro
defs
  OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register macros
  OvmfPkg/PlatformPei: factor out Q35BoardVerification()
  OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (skeleton)
  OvmfPkg/PlatformPei: assert there's no permanent PEI RAM at default
SMBASE
  OvmfPkg/PlatformPei: reserve the SMRAM at the default SMBASE, if it
exists
  OvmfPkg/SEV: don't manage the lifecycle of the SMRAM at the default
SMBASE
  OvmfPkg/SmmAccess: close and lock SMRAM at default SMBASE
  OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real)

 OvmfPkg/Include/IndustryStandard/Q35MchIch9.h   | 106 
+++-
 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c   |  21 +++-
 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf |   4 +
 OvmfPkg/OvmfPkg.dec |   6 ++
 OvmfPkg/OvmfPkgIa32.dsc |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc  |   1 +
 OvmfPkg/OvmfPkgX64.dsc  |   1 +
 OvmfPkg/PlatformPei/AmdSev.c|  24 -
 OvmfPkg/PlatformPei/MemDetect.c |  87 +---
 OvmfPkg/PlatformPei/Platform.c  |  24 +
 OvmfPkg/PlatformPei/Platform.h  |   7 ++
 OvmfPkg/PlatformPei/PlatformPei.inf |   1 +
 OvmfPkg/SmmAccess/SmmAccess2Dxe.c   |   7 ++
 OvmfPkg/SmmAccess/SmmAccess2Dxe.inf |   1 +
 OvmfPkg/SmmAccess/SmmAccessPei.c|   6 ++
 OvmfPkg/SmmAccess/SmmAccessPei.inf

Re: [edk2-devel] [Qemu-devel] [PATCH 1/2] q35: implement 128K SMRAM at default SMBASE address

2019-09-24 Thread Igor Mammedov

On Mon, 23 Sep 2019 20:35:02 +0200
"Laszlo Ersek"  wrote:

> On 09/20/19 11:28, Laszlo Ersek wrote:
> > On 09/20/19 10:28, Igor Mammedov wrote:  
> >> On Thu, 19 Sep 2019 19:02:07 +0200
> >> "Laszlo Ersek"  wrote:
> >>  
> >>> Hi Igor,
> >>>
> >>> (+Brijesh)
> >>>
> >>> long-ish pondering ahead, with a question at the end.  
> >> [...]
> >>  
> >>> Finally: can you please remind me why we lock down 128KB (32 pages) at
> >>> 0x3_, and not just half of that? What do we need the range at
> >>> [0x4_..0x4_] for?  
> >>
> >>
> >> If I recall correctly, CPU consumes 64K of save/restore area.
> >> The rest 64K are temporary RAM for using in SMI relocation handler,
> >> if it's possible to get away without it then we can drop it and
> >> lock only 64K required for CPU state. It won't help with SEV
> >> conflict though as it's in the first 64K.  
> > 
> > OK. Let's go with 128KB for now. Shrinking the area is always easier
> > than growing it.
> >   
> >> On QEMU side,  we can drop black-hole approach and allocate
> >> dedicated SMRAM region, which explicitly gets mapped into
> >> RAM address space and after SMI hanlder initialization, gets
> >> unmapped (locked). So that SMRAM would be accessible only
> >> from SMM context. That way RAM at 0x3 could be used as
> >> normal when SMRAM is unmapped.  
> > 
> > I prefer the black-hole approach, introduced in your current patch
> > series, if it can work. Way less opportunity for confusion.
> > 
> > I've started work on the counterpart OVMF patches; I'll report back.  
> 
> I've got good results. For this (1/2) QEMU patch:
> 
> Tested-by: Laszlo Ersek 
> 
> I tested the following scenarios. In every case, I verified the OVMF
> log, and also the "info mtree" monitor command's result (i.e. whether
> "smbase-blackhole" / "smbase-window" were disabled or enabled). Mostly,
> I diffed these text files between the test scenarios (looking for
> desired / undesired differences). In the Linux guests, I checked /
> compared the dmesg too (wrt. the UEFI memmap).
> 
> - unpatched OVMF (regression test), Fedora guest, normal boot and S3
> 
> - patched OVMF, but feature disabled with "-global mch.smbase-smram=off"
> (another regression test), Fedora guest, normal boot and S3
> 
> - patched OVMF, feature enabled, Fedora and various Windows guests
> (win7, win8, win10 families, client/server), normal boot and S3
> 
> - a subset of the above guests, with S3 disabled (-global
>   ICH9-LPC.disable_s3=1), and obviously S3 resume not tested
> 
> SEV: used 5.2-ish Linux guest, with S3 disabled (no support under SEV
> for that now):
> 
> - unpatched OVMF (regression test), normal boot
> 
> - patched OVMF but feature disabled on the QEMU cmdline (another
> regression test), normal boot
> 
> - patched OVMF, feature enabled, normal boot.
> 
> I plan to post the OVMF patches tomorrow, for discussion.
> 
> (It's likely too early to push these QEMU / edk2 patches right now -- we
> don't know yet if this path will take us to the destination. For now, it
> certainly looks great.)

Laszlo, thanks for trying it out.
It's nice to hear that approach is somewhat usable.
Hopefully we won't have to invent 'paused' cpu mode.

Pls CC me on your patches
(not that I qualify for reviewing,
but may be I could learn a thing or two from it)

> Thanks
> Laszlo
> 
> 
> 


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

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

Re: [edk2-devel] [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> NetLibGetSnpHandle() returns an EFI_HANDLE, not an (EFI_HANDLE*).
> NetLibGetMacAddress() only uses the return value ("SnpHandle") for a
> NULL-check. Fix the type of "SnpHandle".
> 
> This patch is a no-op.
> 
> Cc: Jiaxin Wu 
> Cc: Siyuan Fu 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> lightly tested: MAC strings are displayed in UiApp
> 
>  NetworkPkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c 
> b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> index 8e2f720666ea..a39c20be3d34 100644
> --- a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> +++ b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
> @@ -2182,7 +2182,7 @@ NetLibGetMacAddress (
>EFI_SIMPLE_NETWORK_MODE  SnpModeData;
>EFI_MANAGED_NETWORK_PROTOCOL *Mnp;
>EFI_SERVICE_BINDING_PROTOCOL *MnpSb;
> -  EFI_HANDLE   *SnpHandle;
> +  EFI_HANDLE   SnpHandle;
>EFI_HANDLE   MnpChildHandle;
>  
>ASSERT (MacAddress != NULL);
> 

Since SnpHandle is only checked for being non-null, this change is
indeed a no-op, else it would probably fixed some bug.

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
> the notification handle to have type (VOID*). The notification handle has
> nothing to do with the EFI_HANDLE type.
> 
> This change is a semantic fix; functionally, it's a no-op.
> 
> Cc: Dandan Bi 
> Cc: Eric Dong 
> Cc: Hao A Wu 
> Cc: Jian J Wang 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> lightly tested: ConSplitterDxe is part of the ArmVirt and OVMF platforms
> 
>  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c | 2 +-
>  MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c   | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c 
> b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> index 63c814ae1816..9c38271b65f9 100644
> --- a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> +++ b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> @@ -4026,7 +4026,7 @@ ConSplitterTextInRegisterKeyNotify (
>if (NewNotify == NULL) {
>  return EFI_OUT_OF_RESOURCES;
>}
> -  NewNotify->NotifyHandleList = (EFI_HANDLE *) AllocateZeroPool (sizeof 
> (EFI_HANDLE) *  Private->TextInExListCount);
> +  NewNotify->NotifyHandleList = (VOID **) AllocateZeroPool (sizeof (VOID *) 
> *  Private->TextInExListCount);

TEXT_IN_EX_SPLITTER_NOTIFY->NotifyHandleList is of type (VOID **), OK.

>if (NewNotify->NotifyHandleList == NULL) {
>  gBS->FreePool (NewNotify);
>  return EFI_OUT_OF_RESOURCES;
> diff --git a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c 
> b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> index 7cfd5c178861..f98797225b63 100644
> --- a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> +++ b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> @@ -143,7 +143,7 @@ InternalStartMonitor(
>EFI_HANDLE*Handles;
>UINTN HandleCount;
>UINTN HandleIndex;
> -  EFI_HANDLENotifyHandle;
> +  VOID  *NotifyHandle;
>  
>Status = gBS->LocateHandleBuffer (
>ByProtocol,
> @@ -202,7 +202,7 @@ InternalStopMonitor(
>EFI_KEY_DATA  KeyData;
>UINTN HandleCount;
>UINTN HandleIndex;
> -  EFI_HANDLENotifyHandle;
> +  VOID  *NotifyHandle;
>  
>Status = gBS->LocateHandleBuffer (
>  ByProtocol,
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [PATCH 08/35] MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of EFI_HII_HANDLE

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> HiiGetHiiHandles() returns an array of EFI_HII_HANDLEs, not EFI_HANDLEs.
> HiiGetString() takes an EFI_HII_HANDLE, not an EFI_HANDLE.
> 
> This change is a no-op in practice; it's a semantic improvement.
> 
> Cc: Dandan Bi 
> Cc: Eric Dong 
> Cc: Hao A Wu 
> Cc: Jian J Wang 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> lightly tested, as UefiHiiLib is used by both ArmVirt and OVMF
> 
>  MdeModulePkg/Library/UefiHiiLib/HiiString.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/UefiHiiLib/HiiString.c 
> b/MdeModulePkg/Library/UefiHiiLib/HiiString.c
> index 498f245dce1f..95229f8a8c9f 100644
> --- a/MdeModulePkg/Library/UefiHiiLib/HiiString.c
> +++ b/MdeModulePkg/Library/UefiHiiLib/HiiString.c
> @@ -173,8 +173,8 @@ HiiGetPackageString (
>IN CONST CHAR8 *Language  OPTIONAL
>)
>  {
> -  EFI_HANDLE  *HiiHandleBuffer;
> -  EFI_HANDLE  HiiHandle;
> +  EFI_HII_HANDLE  *HiiHandleBuffer;
> +  EFI_HII_HANDLE  HiiHandle;
>  
>ASSERT (PackageListGuid != NULL);
>  
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> - The 2nd parameter of EFI_SERVICE_BINDING_CREATE_CHILD is:
> 
>   IN OUT EFI_HANDLE *ChildHandle
> 
> - The 2nd parameter of EFI_SERVICE_BINDING_DESTROY_CHILD is:
> 
>   IN EFI_HANDLE ChildHandle
> 
> Fix the DestroyChild() call in TcpFastbootTransportStop().
> 
> This is an actual bugfix; I don't know why the current code doesn't crash.
> Perhaps the function is never reached in practice? (It could be tied to an
> error path.)
> 
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> build-tested only
> 
>  EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c | 
> 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c 
> b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
> index 29f23a82c75f..34f9ba74e4db 100644
> --- 
> a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
> +++ 
> b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
> @@ -503,7 +503,7 @@ TcpFastbootTransportStop (
>Status = mTcpListener->Configure (mTcpListener, NULL);
>ASSERT_EFI_ERROR (Status);
>  
> -  Status = mTcpServiceBinding->DestroyChild (mTcpServiceBinding, 
> );
> +  Status = mTcpServiceBinding->DestroyChild (mTcpServiceBinding, mTcpHandle);
>  
>// Free any data the user didn't pick up
>Entry = (FASTBOOT_TCP_PACKET_LIST *) GetFirstNode ();
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
> the notification handle to have type (VOID*). The notification handle has
> nothing to do with the EFI_HANDLE type.
> 
> This change is a semantic fix; functionally, it's a no-op.
> 
> Cc: Andrew Fish 
> Cc: Jordan Justen 
> Cc: Ray Ni 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> build-tested only
> 
>  EmulatorPkg/EmuGopDxe/GopInput.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/EmulatorPkg/EmuGopDxe/GopInput.c 
> b/EmulatorPkg/EmuGopDxe/GopInput.c
> index fdd0b4911555..2a23564a2173 100644
> --- a/EmulatorPkg/EmuGopDxe/GopInput.c
> +++ b/EmulatorPkg/EmuGopDxe/GopInput.c
> @@ -517,7 +517,7 @@ EmuGopSimpleTextInExRegisterKeyNotify (
>IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL  *This,
>IN EFI_KEY_DATA   *KeyData,
>IN EFI_KEY_NOTIFY_FUNCTIONKeyNotificationFunction,
> -  OUT EFI_HANDLE*NotifyHandle
> +  OUT VOID  **NotifyHandle
>)
>  {
>EFI_STATUS  Status;
> @@ -600,7 +600,7 @@ EFI_STATUS
>  EFIAPI
>  EmuGopSimpleTextInExUnregisterKeyNotify (
>IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL  *This,
> -  IN EFI_HANDLE NotificationHandle
> +  IN VOID   *NotificationHandle
>)
>  /*++
>  
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [PATCH 07/35] MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> GetModuleInfoFromHandle() takes an EFI_HANDLE -- (VOID*) -- as first
> parameter, but InsertFpdtRecord() passes (EFI_HANDLE*) -- (VOID**).
> (VOID**) converts silently to (VOID*), which is why the wrong cast is
> masked.
> 
> Note that the *value* that is passed is alright -- therefore this patch
> does not change behavior --, it's just semantically wrong to pass an
> (EFI_HANDLE*) where an EFI_HANDLE is expected.
> 
> Cc: Dandan Bi 
> Cc: Eric Dong 
> Cc: Hao A Wu 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> Cc: Ray Ni 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> lightly tested, as DxeCorePerformanceLib is linked into ArmVirtQemu's
> DxeCore
> 
>  MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c | 12 
> ++--
>  MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c |  8 
> 
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git 
> a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c 
> b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
> index 0d507c445210..f500e20b320b 100644
> --- a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
> +++ b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
> @@ -998,7 +998,7 @@ InsertFpdtRecord (
>switch (PerfId) {
>case MODULE_START_ID:
>case MODULE_END_ID:
> -GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
> +GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
>  StringPtr = ModuleName;
>  //
>  // Cache the offset of start image start record and use to update the 
> start image end record if needed.
> @@ -1031,7 +1031,7 @@ InsertFpdtRecord (
>  
>case MODULE_LOADIMAGE_START_ID:
>case MODULE_LOADIMAGE_END_ID:
> -GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
> +GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
>  StringPtr = ModuleName;
>  if (PerfId == MODULE_LOADIMAGE_START_ID) {
>mLoadImageCount ++;
> @@ -1071,7 +1071,7 @@ InsertFpdtRecord (
>case MODULE_DB_SUPPORT_END_ID:
>case MODULE_DB_STOP_START_ID:
>case MODULE_DB_STOP_END_ID:
> -GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
> +GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
>  StringPtr = ModuleName;
>  if (!PcdGetBool (PcdEdkiiFpdtStringRecordEnableOnly)) {
>FpdtRecordPtr.GuidQwordEvent->Header.Type   = 
> FPDT_GUID_QWORD_EVENT_TYPE;
> @@ -1085,7 +1085,7 @@ InsertFpdtRecord (
>  break;
>  
>case MODULE_DB_END_ID:
> -GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
> +GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
>  StringPtr = ModuleName;
>  if (!PcdGetBool (PcdEdkiiFpdtStringRecordEnableOnly)) {
>FpdtRecordPtr.GuidQwordStringEvent->Header.Type = 
> FPDT_GUID_QWORD_STRING_EVENT_TYPE;
> @@ -1131,7 +1131,7 @@ InsertFpdtRecord (
>case PERF_INMODULE_END_ID:
>case PERF_CROSSMODULE_START_ID:
>case PERF_CROSSMODULE_END_ID:
> -GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
> +GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
>  if (String != NULL) {
>StringPtr = String;
>  } else {
> @@ -1153,7 +1153,7 @@ InsertFpdtRecord (
>  
>default:
>  if (Attribute != PerfEntry) {
> -  GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
> +  GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
>if (String != NULL) {
>  StringPtr = String;
>} else {
> diff --git 
> a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c 
> b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
> index 5f07464c4ec7..b4f22c14ae73 100644
> --- a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
> +++ b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
> @@ -587,7 +587,7 @@ InsertFpdtRecord (
>switch (PerfId) {
>case MODULE_START_ID:
>case MODULE_END_ID:
> -GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
> +GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, 
> sizeof (ModuleName), );
>  StringPtr = ModuleName;
>  //
>  // Cache the offset of start image start record and use to update the 
> start image end record if needed.
> @@ -612,7 +612,7 @@ InsertFpdtRecord (
>  
>case MODULE_LOADIMAGE_START_ID:
>case MODULE_LOADIMAGE_END_ID:
> -

Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin maintainers to EDK II Releases section

2019-09-24 Thread Philippe Mathieu-Daudé

Hi Liming,

On 9/24/19 3:19 AM, Liming Gao wrote:
> ShellBinPkg is generated for each edk2 stable tag release.
> 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Signed-off-by: Liming Gao 
> ---
>  Maintainers.txt | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index f348d70df3..f75b35d5a8 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -82,6 +82,12 @@ EDK II Releases:
>  W: 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
>  M: Liming Gao 
>  

Shouldn't you keep the F: tag too? Maybe:

 ShellPkg
 (stable)
 F: ShellPkg/


> +W: 
> https://github.com/tianocore/edk2/releases/download/edk2-stable20/ShellBinPkg.zip
> +M: Ray Ni   (Ia32/X64)
> +M: Zhichao Gao (Ia32/X64)
> +M: Leif Lindholm(ARM/AArch64)
> +M: Ard Biesheuvel  (ARM/AArch64)
> +
>  EDK II Architectures:
>  -
>  ARM, AARCH64
> @@ -421,13 +427,6 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
>  M: Ray Ni 
>  M: Zhichao Gao 
>  
> -Maintainers for stable Shell binaries generation
> -when need to publish Shell binaries with edk2 release:
> -M: Ray Ni   (Ia32/X64)
> -M: Zhichao Gao (Ia32/X64)
> -M: Leif Lindholm(ARM/AArch64)
> -M: Ard Biesheuvel  (ARM/AArch64)
> -
>  SignedCapsulePkg
>  F: SignedCapsulePkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> 

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

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

Re: [edk2-devel] [patch v2 4/5] MdeModulePkg/PlatformDriOverride: Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/18/19 5:05 AM, Dandan Bi wrote:
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
> 
> But if the caller of LoadImage() doesn't have the option to defer
> the execution of an image, we can not treat EFI_SECURITY_VIOLATION
> like any other LoadImage() error, we should unload image for the
> EFI_SECURITY_VIOLATION to avoid resource leak.
> 
> This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
> for the caller in PlatformDriOverrideDxe which don't have the policy to
> defer the execution of the image.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Liming Gao 
> Cc: Laszlo Ersek 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> Signed-off-by: Dandan Bi 
> ---
>  .../PlatformDriOverrideDxe/PlatDriOverrideLib.c   | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c 
> b/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c
> index 2d3736b468..f91f038b7a 100644
> --- a/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c
> +++ b/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c
> @@ -1,9 +1,9 @@
>  /** @file
>Implementation of the shared functions to do the platform driver vverride 
> mapping.
>  
> -  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
>  
>  #include "InternalPlatDriOverrideDxe.h"
> @@ -1484,10 +1484,19 @@ GetDriverFromMapping (
> );
>  ASSERT (DriverBinding != NULL);
>  DriverImageInfo->ImageHandle = ImageHandle;
>}
>  } else {
> +  //
> +  // With EFI_SECURITY_VIOLATION retval, the Image was loaded 
> and an ImageHandle was created
> +  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can 
> not be started right now.
> +  // If the caller doesn't have the option to defer the 
> execution of an image, we should
> +  // unload image for the EFI_SECURITY_VIOLATION to avoid 
> resource leak.
> +  //
> +  if (Status == EFI_SECURITY_VIOLATION) {
> +gBS->UnloadImage (ImageHandle);
> +  }
>DriverImageInfo->UnLoadable = TRUE;
>DriverImageInfo->ImageHandle = NULL;
>  }
>}
>  }
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [patch v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/18/19 5:05 AM, Dandan Bi wrote:
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
> 
> But if the caller of LoadImage() doesn't have the option to defer
> the execution of an image, we can not treat EFI_SECURITY_VIOLATION
> like any other LoadImage() error, we should unload image for the
> EFI_SECURITY_VIOLATION to avoid resource leak.
> 
> This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
> for the callers in DxeCapsuleLibFmp which don't have the policy to defer
> the execution of the image.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Liming Gao 
> Cc: Laszlo Ersek 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> Signed-off-by: Dandan Bi 
> ---
>  MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c 
> b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> index 95aa9de087..5dda561a04 100644
> --- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> +++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> @@ -1028,10 +1028,19 @@ StartFmpImage (
>ImageSize,
>
>);
>DEBUG((DEBUG_INFO, "FmpCapsule: LoadImage - %r\n", Status));
>if (EFI_ERROR(Status)) {
> +//
> +// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
> ImageHandle was created
> +// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
> started right now.
> +// If the caller doesn't have the option to defer the execution of an 
> image, we should
> +// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
> +//
> +if (Status == EFI_SECURITY_VIOLATION) {
> +  gBS->UnloadImage (ImageHandle);
> +}
>  FreePool(DriverDevicePath);
>  return Status;
>}
>  
>DEBUG((DEBUG_INFO, "FmpCapsule: StartImage ...\n"));
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [patch v2 3/5] MdeModulePkg/UefiBootManager: Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Philippe Mathieu-Daudé

Hi Dandan,

On 9/18/19 5:05 AM, Dandan Bi wrote:
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
> 
> But if the caller of LoadImage() doesn't have the option to defer
> the execution of an image, we can not treat EFI_SECURITY_VIOLATION
> like any other LoadImage() error, we should unload image for the
> EFI_SECURITY_VIOLATION to avoid resource leak.
> 
> This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
> for the callers in UefiBootManagerLib which don't have the policy to defer
> the execution of the image.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Cc: Liming Gao 
> Cc: Laszlo Ersek 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> Signed-off-by: Dandan Bi 
> ---
>  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c  |  9 +
>  .../Library/UefiBootManagerLib/BmLoadOption.c | 11 ++-
>  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c  | 11 ++-
>  3 files changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> index 952033fc82..760d7647b8 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> @@ -1859,10 +1859,19 @@ EfiBootManagerBoot (
>  if (FilePath != NULL) {
>FreePool (FilePath);
>  }
>  
>  if (EFI_ERROR (Status)) {
> +  //
> +  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
> ImageHandle was created
> +  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
> started right now.
> +  // If the caller doesn't have the option to defer the execution of an 
> image, we should
> +  // unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
> +  //
> +  if (Status == EFI_SECURITY_VIOLATION) {
> +gBS->UnloadImage (ImageHandle);

OK

> +  }
>//
>// Report Status Code with the failure status to indicate that the 
> failure to load boot option
>//
>BmReportLoadFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR, Status);
>BootOption->Status = Status;
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> index 07592f8ebd..af47b787d1 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> @@ -1,9 +1,9 @@
>  /** @file
>Load option library functions which relate with creating and processing 
> load options.
>  
> -Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
>  (C) Copyright 2015-2018 Hewlett Packard Enterprise Development LP
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
>  
> @@ -1409,10 +1409,19 @@ EfiBootManagerProcessLoadOption (
>  FileSize,
>  
>  );
>  FreePool (FileBuffer);
>  

What about:

   if (EFI_ERROR (Status)) {

> +//
> +// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
> ImageHandle was created
> +// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
> started right now.
> +// If the caller doesn't have the option to defer the execution of an 
> image, we should
> +// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
> +//
> +if (Status == EFI_SECURITY_VIOLATION) {
> +  gBS->UnloadImage (ImageHandle);
> +}

-  if (!EFI_ERROR (Status)) {
   } else {

>Status = gBS->HandleProtocol (ImageHandle, 
> , (VOID **));
>ASSERT_EFI_ERROR (Status);
>  
>ImageInfo->LoadOptionsSize = LoadOption->OptionalDataSize;
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> index 6b8fb4d924..833e38c6fe 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> @@ -1,9 +1,9 @@
>  /** @file
>Misc library functions.
>  
> -Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
>  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
>  
> @@ -491,10 +491,19 @@ EfiBootManagerDispatchDeferredImages (
>  ImageDevicePath,
>  NULL,
>  0,
>  
>);
> +  //
> +  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
> ImageHandle was created
> +  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
> started right now.
> +

Re: [edk2-devel] [patch v2 5/5] ShellPkg: Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/18/19 5:05 AM, Dandan Bi wrote:
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
> 
> But if the caller of LoadImage() doesn't have the option to defer
> the execution of an image, we can not treat EFI_SECURITY_VIOLATION
> like any other LoadImage() error, we should unload image for the
> EFI_SECURITY_VIOLATION to avoid resource leak.
> 
> This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
> for the callers in ShellPkg which don't have the policy to defer the
> execution of the image.
> 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Cc: Laszlo Ersek 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> Signed-off-by: Dandan Bi 
> Reviewed-by: Zhichao Gao 
> ---
>  ShellPkg/Application/Shell/ShellManParser.c   |  9 +
>  .../Library/UefiShellDebug1CommandsLib/LoadPciRom.c   | 11 ++-
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c| 11 ++-
>  3 files changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/ShellPkg/Application/Shell/ShellManParser.c 
> b/ShellPkg/Application/Shell/ShellManParser.c
> index 6909f29441..4d5a5668aa 100644
> --- a/ShellPkg/Application/Shell/ShellManParser.c
> +++ b/ShellPkg/Application/Shell/ShellManParser.c
> @@ -643,10 +643,19 @@ ProcessManFile(
>goto Done;
>  }
>  DevPath = 
> ShellInfoObject.NewEfiShellProtocol->GetDevicePathFromFilePath(CmdFilePathName);
>  Status  = gBS->LoadImage(FALSE, gImageHandle, DevPath, NULL, 0, 
> );
>  if(EFI_ERROR(Status)) {
> +  //
> +  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
> ImageHandle was created
> +  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
> started right now.
> +  // If the caller doesn't have the option to defer the execution of an 
> image, we should
> +  // unload image for the EFI_SECURITY_VIOLATION to avoid the resource 
> leak.
> +  //
> +  if (Status == EFI_SECURITY_VIOLATION) {
> +gBS->UnloadImage (CmdFileImgHandle);
> +  }

OK

>*HelpText = NULL;
>goto Done;
>  }
>  Status = gBS->OpenProtocol(
>  CmdFileImgHandle,
> diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c 
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
> index 1b169d0d3c..5b6cba17f3 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
> @@ -1,10 +1,10 @@
>  /** @file
>Main file for LoadPciRom shell Debug1 function.
>  
>(C) Copyright 2015 Hewlett-Packard Development Company, L.P.
> -  Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
>  
>  #include "UefiShellDebug1CommandsLib.h"
> @@ -332,10 +332,19 @@ LoadEfiDriversFromRomImage (
>  ImageBuffer,
>  ImageLength,
>  
> );
>if (EFI_ERROR (Status)) {
> +//
> +// With EFI_SECURITY_VIOLATION retval, the Image was loaded and 
> an ImageHandle was created
> +// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not 
> be started right now.
> +// If the caller doesn't have the option to defer the execution 
> of an image, we should
> +// unload image for the EFI_SECURITY_VIOLATION to avoid resource 
> leak.
> +//
> +if (Status == EFI_SECURITY_VIOLATION) {
> +  gBS->UnloadImage (ImageHandle);
> +}

OK

>  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN 
> (STR_LOADPCIROM_LOAD_FAIL), gShellDebug1HiiHandle, L"loadpcirom", FileName, 
> ImageIndex);
>  //PrintToken (STRING_TOKEN (STR_LOADPCIROM_LOAD_IMAGE_ERROR), 
> HiiHandle, ImageIndex, Status);
>} else {
>  Status = gBS->StartImage (ImageHandle, NULL, NULL);
>  if (EFI_ERROR (Status)) {
> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c 
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
> index 6a94b48c86..b6e7c952fa 100644
> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
> @@ -1,10 +1,10 @@
>  /** @file
>Main file for attrib shell level 2 function.
>  
>(C) Copyright 2015 Hewlett-Packard Development Company, L.P.
> -  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2009 - 2019, Intel Corporation. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
>  
>  #include "UefiShellLevel2CommandsLib.h"
> @@ -110,10 +110,19 @@ LoadDriver(
>  NULL,
>  0,
>

Re: [edk2-devel] [patch v2 1/5] EmbeddedPkg: Unload image on EFI_SECURITY_VIOLATION

2019-09-24 Thread Philippe Mathieu-Daudé

On 9/18/19 5:05 AM, Dandan Bi wrote:
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
> 
> But if the caller of LoadImage() doesn't have the option to defer
> the execution of an image, we can not treat EFI_SECURITY_VIOLATION
> like any other LoadImage() error, we should unload image for the
> EFI_SECURITY_VIOLATION to avoid resource leak.
> 
> This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
> for the callers in EmbeddedPkg which don't have the policy to defer the
> execution of the image.
> 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Laszlo Ersek 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> Signed-off-by: Dandan Bi 
> Acked-by: Ard Biesheuvel 
> Acked-by: Laszlo Ersek 
> ---
>  .../AndroidFastboot/Arm/BootAndroidBootImg.c |  9 +
>  .../Library/AndroidBootImgLib/AndroidBootImgLib.c| 12 
>  2 files changed, 21 insertions(+)
> 
> diff --git a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c 
> b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
> index 591afbe7cc..fe05878b4b 100644
> --- a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
> +++ b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
> @@ -71,10 +71,19 @@ StartEfiApplication (
>  
>// Load the image from the device path with Boot Services function
>Status = gBS->LoadImage (TRUE, ParentImageHandle, DevicePath, NULL, 0,
>);
>if (EFI_ERROR (Status)) {
> +//
> +// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
> ImageHandle was created
> +// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
> started right now.
> +// If the caller doesn't have the option to defer the execution of an 
> image, we should
> +// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
> +//
> +if (Status == EFI_SECURITY_VIOLATION) {
> +  gBS->UnloadImage (ImageHandle);
> +}
>  return Status;
>}
>  
>// Passed LoadOptions to the EFI Application
>if (LoadOptionsSize != 0) {
> diff --git a/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c 
> b/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c
> index d9e7aa7d2b..e1036954ee 100644
> --- a/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c
> +++ b/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c
> @@ -439,10 +439,22 @@ AndroidBootImgBoot (
> + KernelSize;
>  
>Status = gBS->LoadImage (TRUE, gImageHandle,
> (EFI_DEVICE_PATH *),
> (VOID*)(UINTN)Kernel, KernelSize, );
> +  if (EFI_ERROR (Status)) {
> +//
> +// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
> ImageHandle was created
> +// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
> started right now.
> +// If the caller doesn't have the option to defer the execution of an 
> image, we should
> +// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
> +//
> +if (Status == EFI_SECURITY_VIOLATION) {
> +  gBS->UnloadImage (ImageHandle);
> +}
> +return Status;
> +  }
>  
>// Set kernel arguments
>Status = gBS->HandleProtocol (ImageHandle, ,
>  (VOID **) );
>ImageInfo->LoadOptions = NewKernelArg;
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

[edk2-devel] [edk2-test][Patch] uefi-sct/SctPkg: Add MediaPresentSupported check

2019-09-24 Thread xianhui liu

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2061
check MediaPresent while MediaPresentSupported is TRUE
sync change from EFI to IHV SimpleNetworkBBTestFunction

Cc: Heinrich Schuchardt 
Cc: Supreeth Venkatesh 
Cc: Eric Jin 

Signed-off-by: xianhui liu 
---
 .../BlackBoxTest/SimpleNetworkBBTestFunction.c | 64 +++---
 1 file changed, 33 insertions(+), 31 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestFunction.c
index b4c7b5ee..8559e894 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestFunction.c
@@ -1888,38 +1888,40 @@ BBTestGetStatusFunctionTest (
   Status = SnpInterface->GetStatus (SnpInterface, , );
   Status1 = SnpInterface->GetStatus (SnpInterface, , );
 
-  if (SnpInterface->Mode->MediaPresent == FALSE) {
-if ((Status1 == EFI_SUCCESS) && (Status == EFI_SUCCESS) && 
(InterruptStatus == 0)) {
-  AssertionType = EFI_TEST_ASSERTION_PASSED;
-} else {
-  AssertionType = EFI_TEST_ASSERTION_FAILED;
-}
-  } else {
-if ((Status1 == EFI_SUCCESS) && (Status == EFI_SUCCESS)) {
-  AssertionType = EFI_TEST_ASSERTION_PASSED;
-  if (InterruptStatus &
- ~( EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT |
-EFI_SIMPLE_NETWORK_TRANSMIT_INTERRUPT |
-EFI_SIMPLE_NETWORK_COMMAND_INTERRUPT |
-EFI_SIMPLE_NETWORK_SOFTWARE_INTERRUPT)) {
-AssertionType = EFI_TEST_ASSERTION_FAILED;
-  }
-} else {
-  AssertionType = EFI_TEST_ASSERTION_FAILED;
-}
+  if (SnpInterface->Mode-> MediaPresentSupported == TRUE) {
+ if (SnpInterface->Mode->MediaPresent == FALSE) {
+   if ((Status1 == EFI_SUCCESS) && (Status == EFI_SUCCESS) && 
(InterruptStatus == 0)) {
+ AssertionType = EFI_TEST_ASSERTION_PASSED;
+   } else {
+ AssertionType = EFI_TEST_ASSERTION_FAILED;
+   }
+ } else {
+   if ((Status1 == EFI_SUCCESS) && (Status == EFI_SUCCESS)) {
+ AssertionType = EFI_TEST_ASSERTION_PASSED;
+ if (InterruptStatus &
+~( EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT |
+   EFI_SIMPLE_NETWORK_TRANSMIT_INTERRUPT |
+   EFI_SIMPLE_NETWORK_COMMAND_INTERRUPT |
+   EFI_SIMPLE_NETWORK_SOFTWARE_INTERRUPT)) {
+   AssertionType = EFI_TEST_ASSERTION_FAILED;
+ }
+   } else {
+ AssertionType = EFI_TEST_ASSERTION_FAILED;
+   }
+ }
+ StandardLib->RecordAssertion (
+StandardLib,
+AssertionType,
+gSimpleNetworkBBTestFunctionAssertionGuid022,
+L"EFI_SIMPLE_NETWORK_PROTOCOL.GetStatus - Invoke 
GetStatus() and verify interface correctness within test case",
+L"%a:%d:Status - %r, Status1 - %r, InterruptStatus - %d",
+__FILE__,
+(UINTN)__LINE__,
+Status,
+Status1,
+InterruptStatus
+);
   }
-  StandardLib->RecordAssertion (
- StandardLib,
- AssertionType,
- gSimpleNetworkBBTestFunctionAssertionGuid022,
- L"EFI_SIMPLE_NETWORK_PROTOCOL.GetStatus - Invoke GetStatus() 
and verify interface correctness within test case",
- L"%a:%d:Status - %r, Status1 - %r, InterruptStatus - %d",
- __FILE__,
- (UINTN)__LINE__,
- Status,
- Status1,
- InterruptStatus
- );
 
   //
   // Restore SNP State
-- 
2.14.1.windows.1


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

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

Re: [edk2-devel] BaseTools --hash malfunction after migrate from stable201905 to stable201908

2019-09-24 Thread Steven Shi

Hi Derek,
I took a look at this issue, and add back the -hash functionality in this 
branch: https://github.com/shijunjing/edk2/tree/hashcache_v1. The attachment is 
the patch based on latest edk2.
The current -hash fix performance is not as good as the edk2-stable201905,  
because the edk2-stable201905 -hash doesn't parse source code header files and 
not include the header files as the module's hash dependency which is not 
sound. After add the header files dependency, the -hash become slow.
Let me know whether the attached fix works for you. I might continue to tune 
its performance.


Thanks

Steven Shi
Intel\SSG\FID\Firmware Infrastructure

From: Shi, Steven
Sent: Monday, September 23, 2019 3:52 PM
To: 'Lin, Derek (HPS SW)' ; devel@edk2.groups.io
Cc: Feng, Bob C ; Gao, Liming (liming@intel.com) 

Subject: RE: BaseTools --hash malfunction after migrate from stable201905 to 
stable201908

Hi Derek,
Thank you to raise this issue. We will fix it and add back the --hash original 
functionality.


Thanks
Steven

From: Lin, Derek (HPS SW) [mailto:derek.l...@hpe.com]
Sent: Friday, September 20, 2019 2:54 PM
To: devel@edk2.groups.io
Cc: Feng, Bob C mailto:bob.c.f...@intel.com>>; Shi, 
Steven mailto:steven@intel.com>>
Subject: BaseTools --hash malfunction after migrate from stable201905 to 
stable201908

Hi BaseTools experts,

We saw the clean build performance improvement after updating from 
edk2-stable201905 to edk2-stable201908, which is promising.
But we found the incremental build time increase 25%~35%, which is not good.

We're building server platform. And we use --hash to speed up incremental build 
as described in https://github.com/BobCF/edk2/wiki/Incremental-Build
After upgrading to edk2-stable201908, none of AutoGen is skipped when I did an 
incremental build without any code change.

Dig into the issue, it is caused by commit 
https://github.com/tianocore/edk2/commit/0e7e7a264cd80ab71ea0f9e9da2d0617d4b539c4
>From the code change logic, it seems like it require both --hash and 
>--binary-source to perform cache based incremental build. However, when we 
>only have --hash in build flag, it is not functional.


Here's a build time log retrieved from -y report.log.

201905 incremental |  201908 
incremental |  201905 clean | 201908 clean
Build Duration:00:03:4400:04:40 
   00:07:12 00:06:19
AutoGen Duration:  00:02:4000:03:15 
   00:04:28 00:03:09
Make Duration:00:00:3600:00:39  
  00:01:21 00:01:34
GenFds Duration: 00:00:2700:00:28   
 00:01:22 00:01:18

We could see the AutoGen Duration has almost no change between clean and 
incremental build in 201908.

Could we fix this?

Thanks,
Derek


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

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



0001-Fix-the-hash-functionality-for-increamental-build.patch
Description: 0001-Fix-the-hash-functionality-for-increamental-build.patch

95 matches

Mail list logo