Re: [edk2] [PATCH 03/26] Vlv2TbltDevicePkg: assume GCC48 or later

2019-01-03 Thread Sun, Zailiang
Reviewed-by: Zailiang Sun > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, January 3, 2019 10:48 AM > To: edk2-devel-01 > Cc: Sun, Zailiang ; Qian, Yi > Subject: [PATCH 03/26] Vlv2TbltDevicePkg: assume GCC48 or later > > We're about to remove

Re: [edk2] [PATCH] BaseTools/GenFds: permit stripped MM_CORE_STANDALONE binaries

2019-01-03 Thread Feng, Bob C
Reviewed-by: Bob Feng -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Friday, January 4, 2019 2:28 AM To: edk2-devel@lists.01.org Cc: Ard Biesheuvel ; Laszlo Ersek ; Leif Lindholm ; Kinney, Michael D ; Gao, Liming ; Wang, Jian J ; Wu, Hao A ;

Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT build failure

2019-01-03 Thread Wang, Jian J
Reviewed-by: Jian J Wang > -Original Message- > From: Wu, Hao A > Sent: Friday, January 04, 2019 10:42 AM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A ; Bi, Dandan ; > Wang, Jian J ; Ni, Ray > Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT > build failure > >

Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT build failure

2019-01-03 Thread Bi, Dandan
Reviewed-by: Bi Dandan Thanks, Dandan > -Original Message- > From: Wu, Hao A > Sent: Friday, January 4, 2019 10:42 AM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A ; Bi, Dandan ; > Wang, Jian J ; Ni, Ray > Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT > build

Re: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update

2019-01-03 Thread Gao, Liming
Laszlo: This issue has been fixed in edk2 master. I just cherry pick those fixes from edk2 master to my Python3 branch (https://github.com/lgao4/edk2/tree/Python3). Thanks Liming >-Original Message- >From: Laszlo Ersek [mailto:ler...@redhat.com] >Sent: Monday, December 31, 2018 8:16

[edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT build failure

2019-01-03 Thread Hao Wu
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1425 This commit will resolve the VS2015 IA32 NOOPT build failure within SdMmcPciHcDxe. More specifically, this commit will use BaseLib API RShiftU64() to perform right-shift operations for UINT64 type operators. Cc: Dandan Bi Cc: Jian J Wang

Re: [edk2] [Patch] BaseTools: Correct PcdArray value assigment statement

2019-01-03 Thread Gao, Liming
Reviewed-by: Liming Gao >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >BobCF >Sent: Saturday, December 29, 2018 4:43 PM >To: edk2-devel@lists.01.org >Cc: Gao, Liming >Subject: [edk2] [Patch] BaseTools: Correct PcdArray value assigment

Re: [edk2] Uninstalling Invalid Protocol Interfaces

2019-01-03 Thread Ashish Singhal
Hi Mike, Call to UninstallMultipleProtocolInterfaces at https://github.com/tianocore/edk2/blob/master/NetworkPkg/IScsiDxe/IScsiDriver.c#L1864 fails because the component name interface may not be installed depending on the state of PCD. Thanks Ashish From: Kinney, Michael D Sent: Thursday,

Re: [edk2] Uninstalling Invalid Protocol Interfaces

2019-01-03 Thread Kinney, Michael D
Hi Ashish, Can you provide a pointer to the UninstallMultipleProtocolInterfaces() call that is causing this failure? I agree that the UefiLib could provide additional services to simplify the implementation of the unload handlers. Matching the UefiLib APIs that install the Uefi Driver Model

[edk2] Uninstalling Invalid Protocol Interfaces

2019-01-03 Thread Ashish Singhal
Hello, As part of moving from MdeModulePkg implementation of IScsiDxe to the implementation in NetworkPkg, I started hitting exception in the driver loaded after IScsiDxe if IScsiDxe's installation fails for some reason. Upon debugging, I found out that calls to

Re: [edk2] [edk2-announce][RFC] Collaboration Software: Microsoft Teams

2019-01-03 Thread Jeremiah Cox via edk2-devel
On the topic of Microsoft Teams, it has a free option, limited to 300 users. More than 300 users requires an enterprise license, starting at $8/user/month. There is a steep discount for some types of non-profits, but I don't know if we would qualify. More details on the offering here:

Re: [edk2] [PATCH 00/26] remove the GCC44 through GCC47 toolchains

2019-01-03 Thread Jordan Justen
On 2019-01-02 18:47:50, Laszlo Ersek wrote: > Repo: https://github.com/lersek/edk2.git > Branch: drop_gcc44_gcc47_tiano1377 > > (0) This series is meant as an alternative to > > [edk2] [Patch 0/5] Remove unused tool chains in tools_def.template >

Re: [edk2] [PATCH 0/6] implement standalone MM versions of the variable runtime drivers

2019-01-03 Thread Ard Biesheuvel
On Thu, 3 Jan 2019 at 19:28, Ard Biesheuvel wrote: > > This series proposed an alternative approach to the series sent out by > Jagadeesh [0]. In particular, it gets rid of the InMm() calls and the > special PCD, as well as some other if() conditionals. > That would be [0]

[edk2] [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version

2019-01-03 Thread Ard Biesheuvel
Implement a new version of the fault tolerant write driver that can be used in the context of a standalone MM implementation. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c

[edk2] [PATCH 2/6] MdePkg: implement MmServicesTableLib based on traditional SMM

2019-01-03 Thread Ard Biesheuvel
The definitions of the rebranded MM protocol stack were chosen such that the existing SMM based core drivers can be reused. So let's implement MmServicesTableLib based on gEfiMmBaseProtocolGuid, which is simply gEfiSmmBase2ProtocolGuid under the hood. Contributed-under: TianoCore Contribution

[edk2] [PATCH 6/6] MdeModulePkg/VariableRuntimeDxe: implement standalone MM version

2019-01-03 Thread Ard Biesheuvel
Reuse most of the existing code to implement a variable runtime driver that will be able to execute in the context of standalone MM. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c |

[edk2] [PATCH 3/6] MdeModulePkg/FaultTolerantWriteDxe: factor out boot service accesses

2019-01-03 Thread Ard Biesheuvel
In preparation of providing a standalone MM based FTW driver, move the existing SMM driver to the new MM services table, and factor out some pieces that are specific to the traditional driver, mainly related to the use of UEFI boot services, which are not accessible to standalone MM drivers.

[edk2] [PATCH 5/6] MdeModulePkg/VariableRuntimeDxe: factor out boot service accesses

2019-01-03 Thread Ard Biesheuvel
In preparation of providing a standalone MM based variable runtime driver, move the existing SMM driver to the new MM services table, and factor out some pieces that are specific to the traditional driver, mainly related to the use of UEFI boot services, which are not accessible to standalone MM

[edk2] [PATCH 0/6] implement standalone MM versions of the variable runtime drivers

2019-01-03 Thread Ard Biesheuvel
This series proposed an alternative approach to the series sent out by Jagadeesh [0]. In particular, it gets rid of the InMm() calls and the special PCD, as well as some other if() conditionals. The primary difference is that this series defines and implements MmServicesTableLib in such a way

[edk2] [PATCH 1/6] MdePkg/Include: add MmServicesTableLib header file

2019-01-03 Thread Ard Biesheuvel
From: Jagadeesh Ujja SMM has been rebranded as MM, and can be implemented in traditional mode or standalone mode, using the same prototype for the services table. Expose this table via MmServicesTableLib, permitting the respective implementations to expose a traditional or standalone version.

[edk2] [PATCH] BaseTools/GenFds: permit stripped MM_CORE_STANDALONE binaries

2019-01-03 Thread Ard Biesheuvel
The standalone MM core is executed in place, and resides in a separate execution context which may be space constrained. Since code and data may be mapped with different attributes for security reasons, the PE/COFF binary could have a section alignment of 4 KB. This means that any relocation data

Re: [edk2] [PATCH v2 04/11] MdePkg/Include: Add StandaloneMmServicesTableLib library

2019-01-03 Thread Laszlo Ersek
On 01/03/19 12:03, Ard Biesheuvel wrote: > On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja wrote: >> >> Some of the existing DXE drivers can be refactored to execute within >> the Standalone MM execution environment as well. Allow such drivers to >> get access to the Standalone MM services tables. >>

Re: [edk2] [PATCH] BaseTools/GenFds: permit stripped MM_CORE_STANDALONE binaries

2019-01-03 Thread Carsey, Jaben
Reviewed-by: Jaben Carsey > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Ard Biesheuvel > Sent: Thursday, January 03, 2019 4:13 AM > To: edk2-devel@lists.01.org > Cc: Gao, Liming > Subject: [edk2] [PATCH] BaseTools/GenFds: permit

Re: [edk2] [PATCH 26/26] Revert "MdePkg: avoid __builtin_unreachable() on GCC v4.4"

2019-01-03 Thread Marvin Häuser
> -Original Message- > From: Laszlo Ersek > Sent: Thursday, January 3, 2019 3:48 AM > To: edk2-devel-01 > Cc: Ard Biesheuvel ; Liming Gao > ; Marvin Haeuser ; > Michael D Kinney > Subject: [PATCH 26/26] Revert "MdePkg: avoid __builtin_unreachable() on > GCC v4.4" > > This reverts

[edk2] [PATCH] BaseTools/GenFds: permit stripped MM_CORE_STANDALONE binaries

2019-01-03 Thread Ard Biesheuvel
The standalone MM core is executed in place, and resides in a separate execution context which may be space constrained. Since code and data may be mapped with different attributes for security reasons, the PE/COFF binary could have a section alignment of 4 KB. This means that any relocation data

Re: [edk2] [PATCH v2 04/11] MdePkg/Include: Add StandaloneMmServicesTableLib library

2019-01-03 Thread Ard Biesheuvel
On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja wrote: > > Some of the existing DXE drivers can be refactored to execute within > the Standalone MM execution environment as well. Allow such drivers to > get access to the Standalone MM services tables. > > Add a mechanism to determine the execution

Re: [edk2] [PATCH 00/13] Extend secure variable service to be usable from Standalone MM

2019-01-03 Thread Ard Biesheuvel
On Thu, 3 Jan 2019 at 10:52, Ard Biesheuvel wrote: > > On Thu, 3 Jan 2019 at 08:43, Jagadeesh Ujja wrote: > > > > hi Ard > > > > On Wed, Jan 2, 2019 at 10:45 PM Ard Biesheuvel > > wrote: > > > > > > On Thu, 20 Dec 2018 at 15:23, Gao, Liming wrote: > > > > > > > > Jagadeesh: > > > >

Re: [edk2] [PATCH 00/13] Extend secure variable service to be usable from Standalone MM

2019-01-03 Thread Ard Biesheuvel
On Thu, 3 Jan 2019 at 08:43, Jagadeesh Ujja wrote: > > hi Ard > > On Wed, Jan 2, 2019 at 10:45 PM Ard Biesheuvel > wrote: > > > > On Thu, 20 Dec 2018 at 15:23, Gao, Liming wrote: > > > > > > Jagadeesh: > > > MdeModulePkg Variable service/Fault tolerant/Nor Flash driver depends > > > on

Re: [edk2] [PATCH 26/26] Revert "MdePkg: avoid __builtin_unreachable() on GCC v4.4"

2019-01-03 Thread Ard Biesheuvel
On Thu, 3 Jan 2019 at 03:49, Laszlo Ersek wrote: > > This reverts commit 357cec385d4f ("MdePkg: avoid __builtin_unreachable() > on GCC v4.4", 2016-07-21). > > We've removed BaseTools support for GCC44..GCC47, therefore we need not > catch the GCC44 corner case for __builtin_unreachable(). > > No

Re: [edk2] [PATCH 24/26] ArmPkg/ArmSoftFloatLib: drop build flags specific to GCC46/GCC47

2019-01-03 Thread Ard Biesheuvel
On Thu, 3 Jan 2019 at 03:49, Laszlo Ersek wrote: > > We've removed BaseTools support for GCC44..GCC47. Drop > ArmPkg/ArmSoftFloatLib build flags that are specific to any of those gcc > versions. (See also commit 01627dba0911, "ArmPkg/ArmSoftfloatLib: restrict > -fno-tree-vrp option to GCC46 and

Re: [edk2] [PATCH 02/26] OvmfPkg: require GCC48 or later

2019-01-03 Thread Ard Biesheuvel
On Thu, 3 Jan 2019 at 03:48, Laszlo Ersek wrote: > > We're about to remove BaseTools support for GCC44..GCC47. Reject those gcc > versions cleanly in "OvmfPkg/build.sh". In "OvmfPkg/README", upgrade any > mentions of the same gcc versions to GCC48. > > No GCC44..GCC47 references remain under