Re: [edk2-devel][Patch] IntelFspPkg: Remove them

2019-06-05 Thread Nate DeSimone
Please commit Chasel's fix for 
https://edk2.groups.io/g/devel/topic/31860753#41659

Once Chasel's fix is committed...

Reviewed-by: Nate DeSimone 

-Original Message-
From: Ni, Ray 
Sent: Thursday, May 16, 2019 1:38 AM
To: Chiu, Chasel ; Desimone, Nathaniel L 
; Zeng, Star 
Cc: devel@edk2.groups.io
Subject: [edk2-devel][Patch] IntelFspPkg: Remove them

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

Since there are V2 FSP packages (IntelFsp2Pkg, IntelFsp2WrapperPkg), this patch 
removes IntelFspPkg, IntelFspWrapperPkg to remove obsolete code in edk2 repo.

Signed-off-by: Ray Ni 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Star Zeng 
--
NOTE: This patch is to completely remove IntelFspPkg and IntelFspWrapperPkg 
folder in edk2 repo.
I don't want to flood people's inbox with a big patch just removing every line 
of code in this two packages.

The patch that modifies Maintainers.txt will be sent out later after 
IntelFspPkg and IntelFspWrapperPkg are removed.


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

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



[edk2-devel] Printing git commit in build

2019-06-05 Thread Udit Kumar
Dear Community, 

I like to print git commit id, which printing UEFI firmware build information. 
Could you help, how I can collect ' git describe' information in C file. 

Thanks
Udit 

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

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



Re: [edk2-devel] Hard Feature Freeze starts now for edk2-stable201905

2019-06-05 Thread Liming Gao


Last one for edk2-stable201905. This one just adds the missing PrintLib in 
OpensslLib. 
PrintLib is the basic library to be included in every platform. So, this change 
risk is low. 

[PATCH] CryptoPkg/OpensslLib: fix build break caused by missing library

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Liming 
> Gao
> Sent: Wednesday, June 5, 2019 4:03 PM
> To: devel@edk2.groups.io; Gao, Liming ; Wang, Jian J 
> ; Kinney, Michael D
> 
> Cc: leif.lindh...@linaro.org; Laszlo Ersek (ler...@redhat.com) 
> ; af...@apple.com
> Subject: Re: [edk2-devel] Hard Feature Freeze starts now for edk2-stable201905
> 
> Another two to catch edk2-stable201905.
> 
> [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build 
> problem
> [edk2-devel] [PATCH for-edk2-stable201905] Revert "UefiPayloadPkg: Remove 
> legacy PIC 8259 driver"
> 
> Thanks
> Liming
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
> > Liming Gao
> > Sent: Wednesday, June 5, 2019 8:01 AM
> > To: Wang, Jian J ; devel@edk2.groups.io; Kinney, 
> > Michael D 
> > Cc: leif.lindh...@linaro.org; Laszlo Ersek (ler...@redhat.com) 
> > ; af...@apple.com
> > Subject: Re: [edk2-devel] Hard Feature Freeze starts now for 
> > edk2-stable201905
> >
> > Another one is to fix Maintainers.txt.
> >
> > [edk2-devel] [Patch] Maintainers.txt: Remove Network maintainers for 
> > MdeModulePkg/Universal/Network
> >
> > >-Original Message-
> > >From: Wang, Jian J
> > >Sent: Wednesday, June 05, 2019 5:21 AM
> > >To: devel@edk2.groups.io; Kinney, Michael D ;
> > >Gao, Liming 
> > >Cc: leif.lindh...@linaro.org; Laszlo Ersek (ler...@redhat.com)
> > >; af...@apple.com
> > >Subject: RE: [edk2-devel] Hard Feature Freeze starts now for edk2-
> > >stable201905
> > >
> > >There's a fix for build failure.
> > >
> > >*[edk2-devel] [PATCH] CryptoPkg/OpensslLib: fix VS2017 build failure
> > >
> > >Regards,
> > >Jian
> > >
> > >
> > >> -Original Message-
> > >> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > >> Michael D Kinney
> > >> Sent: Wednesday, June 05, 2019 4:29 AM
> > >> To: Gao, Liming ; devel@edk2.groups.io; Kinney,
> > >> Michael D 
> > >> Cc: leif.lindh...@linaro.org; Laszlo Ersek (ler...@redhat.com)
> > >> ; af...@apple.com
> > >> Subject: Re: [edk2-devel] Hard Feature Freeze starts now for edk2-
> > >stable201905
> > >>
> > >> Hello,
> > >>
> > >> The patches for edk2-stable201905 were reviewed this morning.
> > >> The following 2 patches are in scope for the hard freeze.
> > >>
> > >> * [edk2-devel] [PATCH for-edk2-stable201905] Revert "EmulatorPkg: don't
> > >> display the cpu current speed"
> > >> * [edk2-devel] [Patch V2] edk2: Update additional licenses in Readme.md
> > >>
> > >> Please reply to this email if there are any additional patches or
> > >> issues that must be resolved in the hard freeze for this release.
> > >>
> > >> We are still targeting the release for 2019-06-06.
> > >>
> > >> Thanks,
> > >>
> > >> Mike
> > >>
> > >> ==
> > >>
> > >>
> > >> From: Gao, Liming
> > >> Sent: Sunday, June 2, 2019 9:02 PM
> > >> To: devel@edk2.groups.io
> > >> Cc: leif.lindh...@linaro.org; Laszlo Ersek (ler...@redhat.com)
> > >> ; af...@apple.com; Kinney, Michael D
> > >> 
> > >> Subject: Hard Feature Freeze starts now for edk2-stable201905
> > >>
> > >> Hi, all
> > >>   Openssl1.1.1 update has been resolved. So, we enter into Hard Feature
> > >Freeze
> > >> phase until edk2-stable201905 tag is created at 2019-06-06. In this 
> > >> phase,
> > >there
> > >> is no feature to be pushed. The bug fix is still allowed. Below is the 
> > >> updated
> > >> edk2-stable201905 tag planning.
> > >>
> > >> Date (00:00:00 UTC-8) Description
> > >> 2018-03-08 (12PM) Beginning of development
> > >> 2019-05-17 Soft Feature Freeze
> > >> 2019-06-03 Hard Feature Freeze
> > >> 2019-06-06 Release
> > >>
> > >> Thanks
> > >> Liming
> > >>
> > >>
> >
> >
> >
> 
> 
> 


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

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



Re: [edk2-devel] [PATCH] CryptoPkg/OpensslLib: fix build break caused by missing library

2019-06-05 Thread Liming Gao
Reviewed-by: Liming Gao 

> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, June 6, 2019 10:57 AM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Bi, Dandan 
> Subject: [PATCH] CryptoPkg/OpensslLib: fix build break caused by missing 
> library
> 
> CryptoPkg\Library\Include\CrtLibSupport.h maps str interfaces to
> edk2 PrintLib interfaces but related module inf file don't claim the
> use of it. This will cause unresolved symbol issue with VS2017 build
> which has enabled strict symbol check. This patch resolves the problem
> by adding PrintLib to inf files.
> 
> Cc: Liming Gao 
> Cc: Dandan Bi 
> Signed-off-by: Jian J Wang 
> ---
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf   | 1 +
>  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
> b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> index 5a2424fc16..5f36edeeef 100644
> --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> @@ -562,6 +562,7 @@
>BaseLib
>DebugLib
>TimerLib
> +  PrintLib
> 
>  [LibraryClasses.ARM]
>ArmSoftFloatLib
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf 
> b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> index 588da4c040..de05cac931 100644
> --- a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> +++ b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> @@ -518,6 +518,7 @@
>BaseLib
>DebugLib
>TimerLib
> +  PrintLib
> 
>  [LibraryClasses.ARM]
>ArmSoftFloatLib
> --
> 2.17.1.windows.2


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

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



Re: [edk2-devel] [PATCH] OvmfPkg/QemuVideoDxe: Shouldn't assume system in VGA alias mode.

2019-06-05 Thread Marc W Chen
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Wednesday, June 5, 2019 8:00 PM
> To: Chen, Marc W ; devel@edk2.groups.io
> Cc: Justen, Jordan L ; Ard Biesheuvel
> ; Anthony Perard ;
> Julien Grall ; Marc-André Lureau
> ; Stefan Berger 
> Subject: Re: [edk2-devel] [PATCH] OvmfPkg/QemuVideoDxe: Shouldn't
> assume system in VGA alias mode.
> 
> On 06/05/19 13:14, Marc W Chen wrote:
> > Query the supported attributes firstly, then AND (&&) both
> > VGA_IO and VGA_IO_16.
> 
> I don't think you mean "logical AND" above.
> 
> And if you mean "bitwise AND", then "&&" is incorrect.

Thanks for the feedback, yes, I mean "bitwise AND", I'll correct it in my 
commit message.
> 
> > Since the supported attributes should
> > only have VGA_IO or VGA_IO_16 set, the result of AND (&&) is
> > either VGA_IO or IO_16. Then the result can be passed to
> > PciIo->Attributes() to set the attributes.
> 
> I don't understand what the problem is.
> 
> In fact, do we have two problems? Such as,
> 
> (1) We don't consider VGA_IO_16, only VGA_IO. Are you saying that we
> should consider both, and (at the same time) make sure that at most one
> is set?

Yes, we should consider both since the mReserveVgaAliases in PciBusDxe driver 
is default FALSE(implies that device driver can only set VGA_IO_16 to 
PCI_ROOT_BRIDGE), and Platform code may not return EFI_RESERVE_VGA_IO_ALIAS in 
GetPlatformPolicy of PciPlatformProtocol to make mReserveVgaAliases become 
TRUE(implies that device driver can only set VGA_IO to PCI_ROOT_BRIDGE), 
currently OvmfPkg doesn't have issue due to it has hard code value in 
PCI_ROOT_BRIDGE's attribute field, so an IO read by PciIoProtocol will be 
success due to RootBridgeIoCheckParameter of PciRootBridgeIo.c will always get 
pass result for legacy IO access.
But in our design(Edk2Platform:Platform\Intel\MinPlatformPkg), we only set 
Supports field of PCI_ROOT_BRIDGE, and keep Attributes field of PCI_ROOT_BRIDGE 
as 0, and let device driver to update the attribute of PCI_ROOT_BRIDGE for IO 
accessing, in that case, if BIOS doesn't return EFI_RESERVE_VGA_IO_ALIAS in 
GetPlatformPolicy of PciPlatformProtocol, then only VGA_IO_16 can be enabled by 
device driver, so this QemuVideoDriver failed to do IO access in our case.
I believe if you change the Attributes filed of PCI_ROOT_BRIDGE of OvmfPkg to 
0, then you should be able to see the issue.
> 
> (2) We don't check whether VGA_IO* is supported, we just go ahead and
> enable them. Are you saying that we should check before we enable?
> 

Yes, please refer to my above explanation.
> Furthermore,
> 
> (3) did you encounter an practical problem with the current code? If so,
> can you describe it in the commit message please? The subject line helps
> a little (it implies that using VGA_IO over VGA_IO_16 assumes "VGA alias
> mode"), but it should be described in more detail please.

Yes, please refer to my above explanation, I'll update my commit message to 
describe it more detail.
> 
> >
> > Signed-off-by: Marc Chen 
> > Cc: Jordan Justen 
> > Cc: Laszlo Ersek 
> > Cc: Ard Biesheuvel 
> > Cc: Anthony Perard 
> > Cc: Julien Grall 
> > Cc: Marc-André Lureau 
> > Cc: Stefan Berger 
> > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1880
> > ---
> >  OvmfPkg/QemuVideoDxe/Driver.c | 22 +-
> >  1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/OvmfPkg/QemuVideoDxe/Driver.c
> b/OvmfPkg/QemuVideoDxe/Driver.c
> > index e8a613ef33..ba9210f24b 100644
> > --- a/OvmfPkg/QemuVideoDxe/Driver.c
> > +++ b/OvmfPkg/QemuVideoDxe/Driver.c
> > @@ -201,6 +201,7 @@ QemuVideoControllerDriverStart (
> >PCI_TYPE00Pci;
> >QEMU_VIDEO_CARD   *Card;
> >EFI_PCI_IO_PROTOCOL   *ChildPciIo;
> > +  UINT64Supports;
> >
> >OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
> >
> > @@ -277,13 +278,32 @@ QemuVideoControllerDriverStart (
> >  goto ClosePciIo;
> >}
> >
> > +  //
> > +  // Get supported PCI attributes
> > +  //
> > +  Status = Private->PciIo->Attributes (
> > +Private->PciIo,
> > +EfiPciIoAttributeOperationSupported,
> > +0,
> > +
> > +);
> 
> (4) The arguments and the closing parenthesis are incorrectly aligned,
> relative to the function designator.

I'll update in next patch.
> 
> 
> > +  if (EFI_ERROR (Status)) {
> > +goto ClosePciIo;
> > +  }
> > +
> > +  Supports &= (UINT64)(EFI_PCI_IO_ATTRIBUTE_VGA_IO |
> EFI_PCI_IO_ATTRIBUTE_VGA_IO_16);
> > +  if ((Supports == 0) || (Supports == (EFI_PCI_IO_ATTRIBUTE_VGA_IO |
> EFI_PCI_IO_ATTRIBUTE_VGA_IO_16))) {
> > +Status = EFI_UNSUPPORTED;
> > +goto ClosePciIo;
> > +  }
> > +
> 
> I have two comments on this:
> 
> (5) If we need a variable for tracking just these two bits, then it
> should be named something more to-the-point 

Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem

2019-06-05 Thread Liming Gao
Fish:

From: af...@apple.com [mailto:af...@apple.com]
Sent: Thursday, June 6, 2019 11:39 AM
To: devel@edk2.groups.io; Lu, XiaoyuX 
Cc: Gao, Liming ; Bi, Dandan ; Wang, 
Jian J 
Subject: Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 
IA32 build problem




On Jun 4, 2019, at 11:33 PM, Xiaoyu Lu 
mailto:xiaoyux...@intel.com>> wrote:

Hi Liming,


-Original Message-
From: Gao, Liming
Sent: Wednesday, June 5, 2019 1:57 PM
To: devel@edk2.groups.io; Lu, XiaoyuX 
mailto:xiaoyux...@intel.com>>
Cc: Bi, Dandan mailto:dandan...@intel.com>>; Wang, Jian J 
mailto:jian.j.w...@intel.com>>
Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
CLANG38 IA32 build problem

Xiaoyu:


-Original Message-
From: devel@edk2.groups.io 
[mailto:devel@edk2.groups.io] On Behalf Of
Xiaoyu Lu
Sent: Wednesday, June 05, 2019 1:25 PM
To: devel@edk2.groups.io
Cc: Lu, XiaoyuX mailto:xiaoyux...@intel.com>>; Bi, Dandan
mailto:dandan...@intel.com>>;

Wang, Jian J mailto:jian.j.w...@intel.com>>
Subject: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38
IA32 build problem

When use clang-3.8 to build the NetworkPkg, compiler optimization
may use memcpy for memory copy. For example:

CryptoPkg/Library/OpensslLib/openssl/ssl/ssl_rsa.c:918: undefined
reference to `memcpy'`

Compiler optimization is sophisticated, but we can work around it
use __attribute__((__used__)) to informs the compiler that symbol
should be retained in the object file, even if it may be
unreferenced.

Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
Cc: Dandan Bi mailto:dandan...@intel.com>>
Signed-off-by: Xiaoyu Lu mailto:xiaoyux...@intel.com>>
---
CryptoPkg/Library/IntrinsicLib/CopyMem.c | 13 +
1 file changed, 13 insertions(+)

diff --git a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
index e29b4918d200..7faf5a34d8c1 100644
--- a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
+++ b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
@@ -10,8 +10,21 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#include 
#include 

+#if defined(__clang__) && !defined(__APPLE__)

So, this change is only for CLANG tool chain.


+
+/* Copies bytes between buffers */
+static __attribute__((__used__))

What purpose for static?

Because I want __memcpy only use in this file scope.


+void * __memcpy (void *dest, const void *src, unsigned int count)
+{
+  return CopyMem (dest, src, (UINTN)count);
+}
+__attribute__((__alias__("__memcpy")))
+void * memcpy (void *dest, const void *src, unsigned int count);

__memcpy is IA32 Intrinsic API, memcpy is X64 Intrinsic API, right?

__memcpy isn't IA32 Intrinsic API, only memcpy is intrinsic API for both IA32 
and X64.

The reason I alias memcpy and use __attribute__((__used__)) is let compiler 
retain symbol in object file,
So it can link correct.

Is this correct?


I think this is a bug in clang that requires the __used__, we hit something 
like this with Xcode too. If the compiler emits the intrinsic it should tell 
the linker and some how that was getting missed. Thus the __used__ is a work 
around.

OK. It is for CLANG 3.8. I will check whether the latest CLANG8.0 fixes it.

Thanks,

Andrew Fish


Thanks
Liming


+
+#else
/* Copies bytes between buffers */
void * memcpy (void *dest, const void *src, unsigned int count)
{
 return CopyMem (dest, src, (UINTN)count);
}
+#endif
--
2.7.4







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

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



Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem

2019-06-05 Thread Andrew Fish via Groups.Io


> On Jun 4, 2019, at 11:33 PM, Xiaoyu Lu  wrote:
> 
> Hi Liming,
> 
>> -Original Message-
>> From: Gao, Liming
>> Sent: Wednesday, June 5, 2019 1:57 PM
>> To: devel@edk2.groups.io ; Lu, XiaoyuX 
>> mailto:xiaoyux...@intel.com>>
>> Cc: Bi, Dandan mailto:dandan...@intel.com>>; Wang, 
>> Jian J mailto:jian.j.w...@intel.com>>
>> Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
>> CLANG38 IA32 build problem
>> 
>> Xiaoyu:
>> 
>>> -Original Message-
>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>>> Xiaoyu Lu
>>> Sent: Wednesday, June 05, 2019 1:25 PM
>>> To: devel@edk2.groups.io
>>> Cc: Lu, XiaoyuX ; Bi, Dandan
>> ;
>>> Wang, Jian J 
>>> Subject: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38
>>> IA32 build problem
>>> 
>>> When use clang-3.8 to build the NetworkPkg, compiler optimization
>>> may use memcpy for memory copy. For example:
>>> 
>>> CryptoPkg/Library/OpensslLib/openssl/ssl/ssl_rsa.c:918: undefined
>>> reference to `memcpy'`
>>> 
>>> Compiler optimization is sophisticated, but we can work around it
>>> use __attribute__((__used__)) to informs the compiler that symbol
>>> should be retained in the object file, even if it may be
>>> unreferenced.
>>> 
>>> Cc: Jian J Wang 
>>> Cc: Dandan Bi 
>>> Signed-off-by: Xiaoyu Lu 
>>> ---
>>> CryptoPkg/Library/IntrinsicLib/CopyMem.c | 13 +
>>> 1 file changed, 13 insertions(+)
>>> 
>>> diff --git a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
>>> b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
>>> index e29b4918d200..7faf5a34d8c1 100644
>>> --- a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
>>> +++ b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
>>> @@ -10,8 +10,21 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>>> #include 
>>> #include 
>>> 
>>> +#if defined(__clang__) && !defined(__APPLE__)
>> 
>> So, this change is only for CLANG tool chain.
>> 
>>> +
>>> +/* Copies bytes between buffers */
>>> +static __attribute__((__used__))
>> 
>> What purpose for static?
>> 
> 
> Because I want __memcpy only use in this file scope.
> 
>>> +void * __memcpy (void *dest, const void *src, unsigned int count)
>>> +{
>>> +  return CopyMem (dest, src, (UINTN)count);
>>> +}
>>> +__attribute__((__alias__("__memcpy")))
>>> +void * memcpy (void *dest, const void *src, unsigned int count);
>> 
>> __memcpy is IA32 Intrinsic API, memcpy is X64 Intrinsic API, right?
>> 
> 
> __memcpy isn't IA32 Intrinsic API, only memcpy is intrinsic API for both IA32 
> and X64.
> 
> The reason I alias memcpy and use __attribute__((__used__)) is let compiler 
> retain symbol in object file,
> So it can link correct.
> 
> Is this correct?
> 

I think this is a bug in clang that requires the __used__, we hit something 
like this with Xcode too. If the compiler emits the intrinsic it should tell 
the linker and some how that was getting missed. Thus the __used__ is a work 
around. 

Thanks,

Andrew Fish

>> Thanks
>> Liming
> 
>>> +
>>> +#else
>>> /* Copies bytes between buffers */
>>> void * memcpy (void *dest, const void *src, unsigned int count)
>>> {
>>>  return CopyMem (dest, src, (UINTN)count);
>>> }
>>> +#endif
>>> --
>>> 2.7.4
>>> 
>>> 
>>> 
> 
> 
> 


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

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



Re: [edk2-devel] [PATCH for-edk2-stable201905] Revert "UefiPayloadPkg: Remove legacy PIC 8259 driver"

2019-06-05 Thread Liming Gao
Push @b66c4c4ff918f3663baca7a9321ecd8837cd8522

> -Original Message-
> From: Dong, Guo
> Sent: Wednesday, June 5, 2019 11:21 PM
> To: Gao, Liming ; devel@edk2.groups.io
> Cc: Ma, Maurice ; You, Benjamin 
> Subject: RE: [PATCH for-edk2-stable201905] Revert "UefiPayloadPkg: Remove 
> legacy PIC 8259 driver"
> 
> 
> Sorry missed the notice on the code freeze.
> Thanks Liming to create this patch.
> 
> Reviewed-by: Guo Dong 
> 
> 
> > -Original Message-
> > From: Gao, Liming
> > Sent: Wednesday, June 5, 2019 12:48 AM
> > To: devel@edk2.groups.io
> > Cc: Ma, Maurice ; Dong, Guo
> > ; You, Benjamin 
> > Subject: [PATCH for-edk2-stable201905] Revert "UefiPayloadPkg: Remove
> > legacy PIC 8259 driver"
> >
> > This reverts commit a1539c46958fb896dee8f7987f4a98e9f9d10796.
> > This change will be pushed after edk2-stable201905
> >
> > Cc: Maurice Ma 
> > Cc: Guo Dong 
> > Cc: Benjamin You 
> > Signed-off-by: Liming Gao 
> > ---
> >  UefiPayloadPkg/UefiPayloadPkg.fdf| 1 +
> >  UefiPayloadPkg/UefiPayloadPkgIa32.dsc| 1 +
> >  UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc | 1 +
> >  3 files changed, 3 insertions(+)
> >
> > diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf
> > b/UefiPayloadPkg/UefiPayloadPkg.fdf
> > index 4cd88a3f85..ce3b34999b 100644
> > --- a/UefiPayloadPkg/UefiPayloadPkg.fdf
> > +++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
> > @@ -104,6 +104,7 @@ INF
> > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
> >  INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
> >  INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> >  INF
> > MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryT
> > estDxe.inf
> > +INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> >  INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
> >  INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> >  INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
> > diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> > b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> > index 11cf17ca06..5b6ed36e9c 100644
> > --- a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> > +++ b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> > @@ -432,6 +432,7 @@
> >UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
> >MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> >
> > MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryT
> > estDxe.inf
> > +  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> >MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
> >MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> >MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
> > diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> > b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> > index 5b7994a62c..d57b5241dc 100644
> > --- a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> > +++ b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> > @@ -433,6 +433,7 @@
> >UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
> >MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> >
> > MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryT
> > estDxe.inf
> > +  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> >MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
> >MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> >MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
> > --
> > 2.13.0.windows.1


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

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



Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem

2019-06-05 Thread Liming Gao
Push @98d8f194e5a646b25b3390825c92949a76689d75

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Liming 
> Gao
> Sent: Wednesday, June 5, 2019 3:56 PM
> To: Lu, XiaoyuX ; devel@edk2.groups.io
> Cc: Bi, Dandan ; Wang, Jian J 
> Subject: Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 
> IA32 build problem
> 
> That good enough. Reviewed-by: Liming Gao 
> 
> Thanks
> Liming
> > -Original Message-
> > From: Lu, XiaoyuX
> > Sent: Wednesday, June 5, 2019 3:51 PM
> > To: Gao, Liming ; devel@edk2.groups.io
> > Cc: Bi, Dandan ; Wang, Jian J 
> > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix 
> > CLANG38 IA32 build problem
> >
> > Yes I verify them.
> >
> > build -p OvmfPkg/OvmfPkgX64.dsc -a X64 -t CLANG38
> > and
> > build -p OvmfPkg/OvmfPkgIA32.dsc -a IA32 -t CLANG38
> >
> > with qemu-system-x86_64
> >
> > > -Original Message-
> > > From: Gao, Liming
> > > Sent: Wednesday, June 5, 2019 3:37 PM
> > > To: Lu, XiaoyuX ; devel@edk2.groups.io
> > > Cc: Bi, Dandan ; Wang, Jian J 
> > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > CLANG38 IA32 build problem
> > >
> > > Do you cover IA32 & X64 arch both, and verify Ovmf boot?
> > >
> > > > -Original Message-
> > > > From: Lu, XiaoyuX
> > > > Sent: Wednesday, June 5, 2019 3:35 PM
> > > > To: Gao, Liming ; devel@edk2.groups.io
> > > > Cc: Bi, Dandan ; Wang, Jian J
> > > 
> > > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > CLANG38 IA32 build problem
> > > >
> > > > Liming,
> > > >
> > > > > -Original Message-
> > > > > From: Gao, Liming
> > > > > Sent: Wednesday, June 5, 2019 3:28 PM
> > > > > To: Lu, XiaoyuX ; devel@edk2.groups.io
> > > > > Cc: Bi, Dandan ; Wang, Jian J
> > > 
> > > > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > > > CLANG38 IA32 build problem
> > > > >
> > > > > Xiaoyu:
> > > > >
> > > > > > -Original Message-
> > > > > > From: Lu, XiaoyuX
> > > > > > Sent: Wednesday, June 5, 2019 2:34 PM
> > > > > > To: Gao, Liming ; devel@edk2.groups.io
> > > > > > Cc: Bi, Dandan ; Wang, Jian J
> > > > > 
> > > > > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > > > CLANG38 IA32 build problem
> > > > > >
> > > > > > Hi Liming,
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Gao, Liming
> > > > > > > Sent: Wednesday, June 5, 2019 1:57 PM
> > > > > > > To: devel@edk2.groups.io; Lu, XiaoyuX 
> > > > > > > Cc: Bi, Dandan ; Wang, Jian J
> > > > > 
> > > > > > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: 
> > > > > > > Fix
> > > > > > > CLANG38 IA32 build problem
> > > > > > >
> > > > > > > Xiaoyu:
> > > > > > >
> > > > > > > >-Original Message-
> > > > > > > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> > > Behalf
> > > > > Of
> > > > > > > >Xiaoyu Lu
> > > > > > > >Sent: Wednesday, June 05, 2019 1:25 PM
> > > > > > > >To: devel@edk2.groups.io
> > > > > > > >Cc: Lu, XiaoyuX ; Bi, Dandan
> > > > > > > ;
> > > > > > > >Wang, Jian J 
> > > > > > > >Subject: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > > > CLANG38
> > > > > > > >IA32 build problem
> > > > > > > >
> > > > > > > >When use clang-3.8 to build the NetworkPkg, compiler optimization
> > > > > > > >may use memcpy for memory copy. For example:
> > > > > > > >
> > > > > > > > CryptoPkg/Library/OpensslLib/openssl/ssl/ssl_rsa.c:918: 
> > > > > > > > undefined
> > > > > > > > reference to `memcpy'`
> > > > > > > >
> > > > > > > >Compiler optimization is sophisticated, but we can work around it
> > > > > > > >use __attribute__((__used__)) to informs the compiler that symbol
> > > > > > > >should be retained in the object file, even if it may be
> > > > > > > >unreferenced.
> > > > > > > >
> > > > > > > >Cc: Jian J Wang 
> > > > > > > >Cc: Dandan Bi 
> > > > > > > >Signed-off-by: Xiaoyu Lu 
> > > > > > > >---
> > > > > > > > CryptoPkg/Library/IntrinsicLib/CopyMem.c | 13 +
> > > > > > > > 1 file changed, 13 insertions(+)
> > > > > > > >
> > > > > > > >diff --git a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > > > > >b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > > > > >index e29b4918d200..7faf5a34d8c1 100644
> > > > > > > >--- a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > > > > >+++ b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > > > > >@@ -10,8 +10,21 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > > > > > > #include 
> > > > > > > > #include 
> > > > > > > >
> > > > > > > >+#if defined(__clang__) && !defined(__APPLE__)
> > > > > > >
> > > > > > > So, this change is only for CLANG tool chain.
> > > > > > >
> > > > > > > >+
> > > > > > > >+/* Copies bytes between buffers */
> > > > > > > >+static __attribute__((__used__))
> > > > > > >
> > > > > > > What purpose for static?
> > > > > > >
> > > > > >
> > > > > > Because I want __memcpy only use in this file 

[edk2-devel] [PATCH] CryptoPkg/OpensslLib: fix build break caused by missing library

2019-06-05 Thread Wang, Jian J
CryptoPkg\Library\Include\CrtLibSupport.h maps str interfaces to
edk2 PrintLib interfaces but related module inf file don't claim the
use of it. This will cause unresolved symbol issue with VS2017 build
which has enabled strict symbol check. This patch resolves the problem
by adding PrintLib to inf files.

Cc: Liming Gao 
Cc: Dandan Bi 
Signed-off-by: Jian J Wang 
---
 CryptoPkg/Library/OpensslLib/OpensslLib.inf   | 1 +
 CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf | 1 +
 2 files changed, 2 insertions(+)

diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
index 5a2424fc16..5f36edeeef 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
@@ -562,6 +562,7 @@
   BaseLib
   DebugLib
   TimerLib
+  PrintLib
 
 [LibraryClasses.ARM]
   ArmSoftFloatLib
diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
index 588da4c040..de05cac931 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
@@ -518,6 +518,7 @@
   BaseLib
   DebugLib
   TimerLib
+  PrintLib
 
 [LibraryClasses.ARM]
   ArmSoftFloatLib
-- 
2.17.1.windows.2


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

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



[edk2-devel] [PATCH] BaseTools:Build cache support the cache files for library package

2019-06-05 Thread Fan, ZhijuX
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1867

Current build cache cannot store the cache for library package.
build -p MdePkg\MdePkg.dsc -a IA32 -b DEBUG -t VS2015x86 --hash
--binary-destination=BinCache
After build, the expected result is the BinCache folder is generated
and the MdePkg build cache files (e.g. .hash and .lib) are stored in
the BinCache folder. But the BinCache folder is not generated at all.

This patch is going to fix that issue.

Cc: Liming Gao 
Cc: Bob Feng 
Cc: Steven Shi 
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py | 4 
 1 files changed, 4 insertions(+)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index a879b6259f..b8ecf3826f 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -3571,6 +3571,10 @@ class ModuleAutoGen(AutoGen):
 
 # Skip the following code for libraries
 if self.IsLibrary:
+try:
+self.CopyModuleToCache()
+except:
+pass
 return
 
 # Skip the following code for modules with no source files
-- 
2.14.1.windows.1


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

View/Reply Online (#41970): https://edk2.groups.io/g/devel/message/41970
Mute This Topic: https://groups.io/mt/31945498/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 0/7] Implement Capsule On Disk.

2019-06-05 Thread Zhang, Chao B
Hi Felix:
   We did this design for security consideration.
For Solution B:

1)  We don't want to introduce PartitionDxe and FatDxe into our trust 
boundary. It brings in new attack surface

2)  We reuse PEI storage stack as it is simple. But PEI FAT reduced attach 
surface by only accessing files in RootDir. That is why relocation happens
  For Solution A:

3)  It is considered securer with a smaller attack surface.  Because in 
Solution B, we may suffer from DMA attack when accessing PEI storage device

  Solution B is still valuable option as some platform may don't have Capsule 
in RAM support. That is why we provide both solution and leave option to user
We have a WIKI page to describe all cases 
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Capsule-on-Disk-Introducation
  Just feel free to ask question if anything is not clear

From: Kinney, Michael D
Sent: Thursday, June 6, 2019 6:37 AM
To: Felix Polyudov ; devel@edk2.groups.io; Xu, Wei6 
; Kinney, Michael D 
Cc: Wang, Jian J ; Wu, Hao A ; Gao, 
Liming ; Zhang, Chao B 
Subject: RE: [edk2-devel][Patch v2 0/7] Implement Capsule On Disk.

Hi Felix,

For (1), this is a limitation of UEFI Capsule On Disk
for capsules that must be processed before End of DXE.
This solution only work for EFI System Partitions that
can be accessed from PEI.  Platforms that require the
use of a UEFI Driver loaded from a PCI Option ROM to
access the EFI System Partition can not use the UEFI
Capsule On Disk feature.  They must use the UEFI Capsule
In Memory feature.

For (2), in order to access the capsule file in the
UEFI Spec defines location, the FAT PEIM would have to
be extended to support reading files from subdirectories.
The current FAT PEIM only supports reading files from the
root directory.  This is sufficient for reading recovery
images.  In order to minimize the size of complexity of
PEI phase modules, this solution uses the FAT PEIM "as is"
and uses the features of the UEFI FAT driver to move the
Capsule On Disk content into a location that is compatible
with the existing FAT PEIM.

Thanks,

Mike

> -Original Message-
> From: Felix Polyudov [mailto:fel...@ami.com]
> Sent: Wednesday, June 5, 2019 2:53 PM
> To: devel@edk2.groups.io; Xu, Wei6 
> mailto:wei6...@intel.com>>
> Cc: Wang, Jian J mailto:jian.j.w...@intel.com>>; Wu, 
> Hao A
> mailto:hao.a...@intel.com>>; Kinney, Michael D
> mailto:michael.d.kin...@intel.com>>; Gao, Liming
> mailto:liming@intel.com>>; Zhang, Chao B
> mailto:chao.b.zh...@intel.com>>
> Subject: RE: [edk2-devel][Patch v2 0/7] Implement
> Capsule On Disk.
>
> 1. It looks like the implementation processes capsule
> files in PEI.
> According to UEFI specification capsule files are stored
> on the active ESP.
> Not every UEFI boot device can be accessed in PEI.
> For example, RAID connected to the PCI plug in card
> cannot be accessed in PEI.
>
> 2. Solution B) below relocates capsule to "a temp file
> which will be stored in root directory". I think it is
> cleaner to reuse UEFI capsule-on-disk infrastructure and
> keep capsule file in  the dedicated \EFI\UpdateCapsule
> folder (refer to "Delivery of Capsules via file on Mass
> Storage device" section of the UEFI specification).
>
> -Original Message-
> From: devel@edk2.groups.io 
> [mailto:devel@edk2.groups.io]
> On Behalf Of Xu, Wei6
> Sent: Wednesday, June 05, 2019 11:42 AM
> To: devel@edk2.groups.io
> Cc: Jian J Wang; Hao A Wu; Michael D Kinney; Liming Gao;
> Chao B Zhang
> Subject: [edk2-devel][Patch v2 0/7] Implement Capsule On
> Disk.
>
> V2:
> Fix Ecc check failure.
>
> V1:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852
>
> This patch set implements Capsule On Disk.
> Depends on whether platform supports Capsule-In-Ram,
> Capsule On Disk feature is composed of 2 solutions:
> Solution A): Load capsules out of TCB, rely on
> UpdateCapsule() runtime service to deliver Capsule-On-
> Disk.
> Solution B): Relocate capsules into a temp file which
> will be stored in root directory on a platform specific
> storage device.
> Leverage existing storage stack in PEI to load all
> capsule on disk images and create capsule hobs for the
> capsules.
> This solution has bigger TCB, but can work without
> Capsule-In-RAM support.
>
>
> Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
> Cc: Hao A Wu mailto:hao.a...@intel.com>>
> Cc: Michael D Kinney 
> mailto:michael.d.kin...@intel.com>>
> Cc: Liming Gao mailto:liming@intel.com>>
> Cc: Chao B Zhang mailto:chao.b.zh...@intel.com>>
>
> xuwei6 (7):
>   MdePkg: Add Pei Boot In CapsuleOnDisk Mode Ppi
> definition.
>   MdeModulePkg: Add Capsule On Disk related definition.
>   MdeModulePkg: Add CapsuleOnDiskLoadPei PEIM.
>   MdeModulePkg/BdsDxe: Support Capsule On Disk.
>   MdeModulePkg/CapsuleRuntimeDxe: Introduce PCD to
> control this feature.
>   MdeModulePkg/DxeIpl: Support Capsule On Disk.
>   MdeModulePkg: Add 

Re: [edk2-devel] [edk2-platforms] [patch] Platform/Intel/DebugFeaturePkg: Remove redundant comments

2019-06-05 Thread Dong, Eric
Reviewed-by: Eric Dong 

> -Original Message-
> From: Bi, Dandan
> Sent: Wednesday, June 5, 2019 3:42 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Gao, Liming 
> Subject: [edk2-platforms] [patch] Platform/Intel/DebugFeaturePkg: Remove
> redundant comments
> 
> Cc: Eric Dong 
> Cc: Liming Gao 
> Signed-off-by: Dandan Bi 
> ---
>  .../Intel/DebugFeaturePkg/Include/Library/Usb3DebugPortLib.h | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git
> a/Platform/Intel/DebugFeaturePkg/Include/Library/Usb3DebugPortLib.h
> b/Platform/Intel/DebugFeaturePkg/Include/Library/Usb3DebugPortLib.h
> index 61adf654..0bee2b63 100644
> --- a/Platform/Intel/DebugFeaturePkg/Include/Library/Usb3DebugPortLib.h
> +++
> b/Platform/Intel/DebugFeaturePkg/Include/Library/Usb3DebugPortLib.h
> @@ -49,15 +49,10 @@ Usb3DebugPortWrite (
>IN UINT8 *Buffer,
>IN UINTN NumberOfBytes
>);
> 
> 
> -/**
> -  Read data from USB3 debug port and save the datas in buffer.
> -
> -  Reads NumberOfBytes data bytes from a serial device into the buffer
> -  specified by Buffer. The number of bytes actua
>  /**
>Polls a USB3 debug port to see if there is any data waiting to be read.
> 
>Polls a serial device to see if there is any data waiting to be read.
>If there is data waiting to be read from the serial device, then TRUE is
> returned.
> --
> 2.18.0.windows.1


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

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



[edk2-devel] [PATCH] BaseTools:Build Cache output notification message

2019-06-05 Thread Fan, ZhijuX
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1868

Build need output the cache miss or hit notification
message when consume the build cache. Current build does not
output any message which is not clear for user to know
whether the module built result is from cache or not.

This patch adds message about the cache miss or hit when
build is to consume the build cache.

Cc: Liming Gao 
Cc: Bob Feng 
Cc: Steven Shi 
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index f1b8f9364b..a3de730d1f 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -3957,7 +3957,9 @@ class ModuleAutoGen(AutoGen):
 shutil.copy(File, destination_dir)
 if self.Name == "PcdPeim" or self.Name == "PcdDxe":
 CreatePcdDatabaseCode(self, TemplateString(), 
TemplateString())
+EdkLogger.quiet("Cache hit ... %s[%s]" % 
(self.MetaFile.Path,self.Arch))
 return True
+EdkLogger.quiet("Cache miss ... %s[%s]" % (self.MetaFile.Path, 
self.Arch))
 return False
 
 ## Create makefile for the module and its dependent libraries
-- 
2.17.1.windows.2


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

View/Reply Online (#41968): https://edk2.groups.io/g/devel/message/41968
Mute This Topic: https://groups.io/mt/31945437/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 0/7] Implement Capsule On Disk.

2019-06-05 Thread Michael D Kinney
Hi Felix,

For (1), this is a limitation of UEFI Capsule On Disk
for capsules that must be processed before End of DXE.
This solution only work for EFI System Partitions that
can be accessed from PEI.  Platforms that require the
use of a UEFI Driver loaded from a PCI Option ROM to
access the EFI System Partition can not use the UEFI 
Capsule On Disk feature.  They must use the UEFI Capsule
In Memory feature.

For (2), in order to access the capsule file in the
UEFI Spec defines location, the FAT PEIM would have to
be extended to support reading files from subdirectories.
The current FAT PEIM only supports reading files from the
root directory.  This is sufficient for reading recovery
images.  In order to minimize the size of complexity of
PEI phase modules, this solution uses the FAT PEIM "as is"
and uses the features of the UEFI FAT driver to move the
Capsule On Disk content into a location that is compatible
with the existing FAT PEIM.

Thanks,

Mike

> -Original Message-
> From: Felix Polyudov [mailto:fel...@ami.com]
> Sent: Wednesday, June 5, 2019 2:53 PM
> To: devel@edk2.groups.io; Xu, Wei6 
> Cc: Wang, Jian J ; Wu, Hao A
> ; Kinney, Michael D
> ; Gao, Liming
> ; Zhang, Chao B
> 
> Subject: RE: [edk2-devel][Patch v2 0/7] Implement
> Capsule On Disk.
> 
> 1. It looks like the implementation processes capsule
> files in PEI.
> According to UEFI specification capsule files are stored
> on the active ESP.
> Not every UEFI boot device can be accessed in PEI.
> For example, RAID connected to the PCI plug in card
> cannot be accessed in PEI.
> 
> 2. Solution B) below relocates capsule to "a temp file
> which will be stored in root directory". I think it is
> cleaner to reuse UEFI capsule-on-disk infrastructure and
> keep capsule file in  the dedicated \EFI\UpdateCapsule
> folder (refer to "Delivery of Capsules via file on Mass
> Storage device" section of the UEFI specification).
> 
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> On Behalf Of Xu, Wei6
> Sent: Wednesday, June 05, 2019 11:42 AM
> To: devel@edk2.groups.io
> Cc: Jian J Wang; Hao A Wu; Michael D Kinney; Liming Gao;
> Chao B Zhang
> Subject: [edk2-devel][Patch v2 0/7] Implement Capsule On
> Disk.
> 
> V2:
> Fix Ecc check failure.
> 
> V1:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852
> 
> This patch set implements Capsule On Disk.
> Depends on whether platform supports Capsule-In-Ram,
> Capsule On Disk feature is composed of 2 solutions:
> Solution A): Load capsules out of TCB, rely on
> UpdateCapsule() runtime service to deliver Capsule-On-
> Disk.
> Solution B): Relocate capsules into a temp file which
> will be stored in root directory on a platform specific
> storage device.
> Leverage existing storage stack in PEI to load all
> capsule on disk images and create capsule hobs for the
> capsules.
> This solution has bigger TCB, but can work without
> Capsule-In-RAM support.
> 
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Chao B Zhang 
> 
> xuwei6 (7):
>   MdePkg: Add Pei Boot In CapsuleOnDisk Mode Ppi
> definition.
>   MdeModulePkg: Add Capsule On Disk related definition.
>   MdeModulePkg: Add CapsuleOnDiskLoadPei PEIM.
>   MdeModulePkg/BdsDxe: Support Capsule On Disk.
>   MdeModulePkg/CapsuleRuntimeDxe: Introduce PCD to
> control this feature.
>   MdeModulePkg/DxeIpl: Support Capsule On Disk.
>   MdeModulePkg: Add Capsule On Disk APIs into
> CapsuleLib.
> 
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h  |
> 3 +-
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|
> 20 +-
>  MdeModulePkg/Core/DxeIplPeim/DxeLoad.c |
> 37 +-
>  MdeModulePkg/Include/Library/CapsuleLib.h  |
> 94 +-
>  MdeModulePkg/Include/Ppi/CapsuleOnDisk.h   |
> 48 +
>  .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.c   |
> 1983 
>  .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.h   |
> 63 +
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c   |
> 56 +-
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf |
> 21 +-
>  .../DxeCapsuleLibFmp/DxeCapsuleProcessLib.c|
> 121 +-
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c |
> 67 +-
>  .../DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf  |
> 3 +-
>  .../Library/DxeCapsuleLibNull/DxeCapsuleLibNull.c  |
> 85 +-
>  MdeModulePkg/MdeModulePkg.dec  |
> 43 +
>  MdeModulePkg/MdeModulePkg.dsc  |
> 4 +
>  MdeModulePkg/MdeModulePkg.uni  |
> 32 +
>  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf   |
> 3 +-
>  MdeModulePkg/Universal/BdsDxe/BdsEntry.c   |
> 6 +-
>  .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c|
> 442 +
>  .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.inf  |
> 64 +
>  .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.uni  |
> 15 +
>  .../CapsuleOnDiskLoadPeiExtra.uni  |
> 14 +
>  .../CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf|
> 1 +
>  

Re: [edk2-devel][Patch v2 0/7] Implement Capsule On Disk.

2019-06-05 Thread Felix Polyudov
1. It looks like the implementation processes capsule files in PEI.
According to UEFI specification capsule files are stored on the active ESP.
Not every UEFI boot device can be accessed in PEI.
For example, RAID connected to the PCI plug in card cannot be accessed in PEI.

2. Solution B) below relocates capsule to "a temp file which will be stored in 
root directory". I think it is cleaner to reuse UEFI capsule-on-disk 
infrastructure and keep capsule file in  the dedicated \EFI\UpdateCapsule 
folder (refer to "Delivery of Capsules via file on Mass Storage device" section 
of the UEFI specification).

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Xu, Wei6
Sent: Wednesday, June 05, 2019 11:42 AM
To: devel@edk2.groups.io
Cc: Jian J Wang; Hao A Wu; Michael D Kinney; Liming Gao; Chao B Zhang
Subject: [edk2-devel][Patch v2 0/7] Implement Capsule On Disk.

V2:
Fix Ecc check failure.

V1:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852

This patch set implements Capsule On Disk.
Depends on whether platform supports Capsule-In-Ram, Capsule On Disk feature is 
composed of 2 solutions:
Solution A): Load capsules out of TCB, rely on UpdateCapsule() runtime service 
to deliver Capsule-On-Disk.
Solution B): Relocate capsules into a temp file which will be stored in root 
directory on a platform specific storage device.
Leverage existing storage stack in PEI to load all capsule on disk images and 
create capsule hobs for the capsules.
This solution has bigger TCB, but can work without Capsule-In-RAM support.


Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Chao B Zhang 

xuwei6 (7):
  MdePkg: Add Pei Boot In CapsuleOnDisk Mode Ppi definition.
  MdeModulePkg: Add Capsule On Disk related definition.
  MdeModulePkg: Add CapsuleOnDiskLoadPei PEIM.
  MdeModulePkg/BdsDxe: Support Capsule On Disk.
  MdeModulePkg/CapsuleRuntimeDxe: Introduce PCD to control this feature.
  MdeModulePkg/DxeIpl: Support Capsule On Disk.
  MdeModulePkg: Add Capsule On Disk APIs into CapsuleLib.

 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h  |3 +-
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   20 +-
 MdeModulePkg/Core/DxeIplPeim/DxeLoad.c |   37 +-
 MdeModulePkg/Include/Library/CapsuleLib.h  |   94 +-
 MdeModulePkg/Include/Ppi/CapsuleOnDisk.h   |   48 +
 .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.c   | 1983 
 .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.h   |   63 +
 .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c   |   56 +-
 .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf |   21 +-
 .../DxeCapsuleLibFmp/DxeCapsuleProcessLib.c|  121 +-
 .../Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c |   67 +-
 .../DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf  |3 +-
 .../Library/DxeCapsuleLibNull/DxeCapsuleLibNull.c  |   85 +-
 MdeModulePkg/MdeModulePkg.dec  |   43 +
 MdeModulePkg/MdeModulePkg.dsc  |4 +
 MdeModulePkg/MdeModulePkg.uni  |   32 +
 MdeModulePkg/Universal/BdsDxe/BdsDxe.inf   |3 +-
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c   |6 +-
 .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c|  442 +
 .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.inf  |   64 +
 .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.uni  |   15 +
 .../CapsuleOnDiskLoadPeiExtra.uni  |   14 +
 .../CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf|1 +
 .../Universal/CapsuleRuntimeDxe/CapsuleService.c   |   10 +-
 MdePkg/Include/Ppi/BootInRecoveryMode.h|9 +-
 MdePkg/MdePkg.dec  |3 +
 26 files changed, 3205 insertions(+), 42 deletions(-)
 create mode 100644 MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
 create mode 100644 MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c
 create mode 100644 MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.h
 create mode 100644 
MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c
 create mode 100644 
MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.inf
 create mode 100644 
MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.uni
 create mode 100644 
MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPeiExtra.uni

--
2.16.2.windows.1





Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary 
to American Megatrends, Inc.  This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited.  Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.

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

Re: [edk2-devel][Patch v2 1/7] MdePkg: Add Pei Boot In CapsuleOnDisk Mode Ppi definition.

2019-06-05 Thread Felix Polyudov
1. It is my understanding that edk2 convention is to keep each PPI in a 
separate header file. If this is the case, new PPI definition should not be 
added to BootInRecoveryMode.h.
2. gEfiPeiBootInCapsuleOnDiskModePpiGuid is a bad name. New PPI is not defined 
by UEFI/PI specifications and as such cannot have EFI prefix. Arguably, it 
shouldn't even be in the MdePkg.

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Xu, Wei6
Sent: Wednesday, June 05, 2019 11:42 AM
To: devel@edk2.groups.io
Cc: Michael D Kinney; Liming Gao; Chao B Zhang; Wei6 Xu
Subject: [edk2-devel][Patch v2 1/7] MdePkg: Add Pei Boot In CapsuleOnDisk Mode 
Ppi definition.

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

This PPI indicates current boot mode is capsule on disk mode.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Chao B Zhang 
Signed-off-by: Wei6 Xu 
---
 MdePkg/Include/Ppi/BootInRecoveryMode.h | 9 -
 MdePkg/MdePkg.dec   | 3 +++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Ppi/BootInRecoveryMode.h 
b/MdePkg/Include/Ppi/BootInRecoveryMode.h
index ae40744d9b..71b0ca8586 100644
--- a/MdePkg/Include/Ppi/BootInRecoveryMode.h
+++ b/MdePkg/Include/Ppi/BootInRecoveryMode.h
@@ -1,10 +1,10 @@
 /** @file
   This PPI is installed by the platform PEIM to designate that a recovery boot
   is in progress.

-  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

   @par Revision Reference:
   This PPI is introduced in PI Version 1.0.

@@ -19,6 +19,13 @@
   }


 extern EFI_GUID gEfiPeiBootInRecoveryModePpiGuid;

+#define EFI_PEI_BOOT_IN_CAPSULE_ON_DISK_MODE_PPI \
+  { \
+0xb08a11e4, 0xe2b7, 0x4b75, { 0xb5, 0x15, 0xaf, 0x61, 0x6, 0x68, 0xbf, 
0xd1 } \
+  }
+
+extern EFI_GUID gEfiPeiBootInCapsuleOnDiskModePpiGuid;
+
 #endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 6c563375ee..ec02b8c7c7 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -790,10 +790,13 @@
   gEfiPeiMemoryDiscoveredPpiGuid = {0xf894643d, 0xc449, 0x42d1, {0x8e, 0xa8, 
0x85, 0xbd, 0xd8, 0xc6, 0x5b, 0xde } }

   ## Include/Ppi/BootInRecoveryMode.h
   gEfiPeiBootInRecoveryModePpiGuid = { 0x17ee496a, 0xd8e4, 0x4b9a, {0x94, 
0xd1, 0xce, 0x82, 0x72, 0x30, 0x8, 0x50 } }

+  ## Include/Ppi/BootInRecoveryMode.h
+  gEfiPeiBootInCapsuleOnDiskModePpiGuid = { 0xb08a11e4, 0xe2b7, 0x4b75, { 
0xb5, 0x15, 0xaf, 0x61, 0x6, 0x68, 0xbf, 0xd1 } }
+
   ## Include/Ppi/EndOfPeiPhase.h
   gEfiEndOfPeiSignalPpiGuid = {0x605EA650, 0xC65C, 0x42e1, {0xBA, 0x80, 0x91, 
0xA5, 0x2A, 0xB6, 0x18, 0xC6 } }

   ## Include/Ppi/Reset.h
   gEfiPeiResetPpiGuid = { 0xef398d58, 0x9dfd, 0x4103, {0xbf, 0x94, 0x78, 0xc6, 
0xf4, 0xfe, 0x71, 0x2f } }
--
2.16.2.windows.1





Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary 
to American Megatrends, Inc.  This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited.  Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.

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

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



Re: [edk2-devel] [PATCH 2/2] KabylakeOpenBoardPkg: FSP 2.1 SEC handling.

2019-06-05 Thread Nate DeSimone
Reviewed-by: Nate DeSimone 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Chiu, Chasel
Sent: Friday, May 31, 2019 4:43 AM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Desimone, Nathaniel L 
; Kubacki, Michael A 
; Chaganty, Rangasai V 

Subject: [edk2-devel] [PATCH 2/2] KabylakeOpenBoardPkg: FSP 2.1 SEC handling.

From: "Chasel, Chiu" 

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

To support FSP Dispatch mode, PlatformSecLib should consume 
FSP_TEMP_RAM_EXIT_PPI to disable temporary memory, and also report 
PeiCoreFvLocation PPI to SecMain so PeiCore form FSP-M can be launched.

Test: API mode no impact and can still booted.

Cc: Nate DeSimone 
Cc: Michael A Kubacki 
Cc: Sai Chaganty 
Signed-off-by: Chasel Chiu 
---
 
Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/FspWrapperPlatformSecLib.c
  | 186 
++
 
Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/PlatformInit.c
  |  47 +++
 
Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecGetPerformance.c
 |  89 
+
 
Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecPlatformInformation.c
|  78 
++
 
Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecRamInitData.c
|  36 
 
Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecTempRamDone.c
|  73 
+
 
Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/FsptCoreUpd.h
   |  40 
 
Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/Ia32/Fsp.h
  |  42 ++
 
Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/Ia32/PeiCoreEntry.nasm
  | 130 
++
 
Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/Ia32/SecEntry.nasm
  | 361 
+
 
Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/Ia32/Stack.nasm
 |  72 

 
Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf
 |  97 
+
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc  
|   2 +-
 13 files changed, 1252 insertions(+), 1 deletion(-)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/FspWrapperPlatformSecLib.c
 
b/Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/FspWrapperPlatformSecLib.c
new file mode 100644
index 00..d73fc77f69
--- /dev/null
+++ b/Platform/Intel/KabylakeOpenBoardPkg/FspWrapper/Library/SecFspWrapp
+++ erPlatformSecLib/FspWrapperPlatformSecLib.c
@@ -0,0 +1,186 @@
+/** @file
+  Provide FSP wrapper platform sec related function.
+
+Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+#include  #include  
+#include  #include  
+#include  #include 
+
+
+#include 
+#include 
+#include 
+#include 
+
+/**
+  This interface conveys state information out of the Security (SEC) phase 
into PEI.
+
+  @param[in] PeiServices   Pointer to the PEI Services Table.
+  @param[in,out] StructureSize Pointer to the variable describing 
size of the input buffer.
+  @param[out]PlatformInformationRecord Pointer to the 
EFI_SEC_PLATFORM_INFORMATION_RECORD.
+
+  @retval EFI_SUCCESS   The data was successfully returned.
+  @retval EFI_BUFFER_TOO_SMALL  The buffer was too small.
+
+**/
+EFI_STATUS
+EFIAPI

Re: [edk2-devel] [PATCH 1/2] KabylakeSiliconPkg: FSP 2.1 SEC handling.

2019-06-05 Thread Nate DeSimone
Hi Chasel,

FSP_TEMP_RAM_EXIT_PPI is defined by the FSP 2.1 specification. The definition 
for it should not go in KabyLakeSiliconPkg, it should be placed in 
IntelFsp2Pkg/Include/Ppi.

Thanks,
Nate

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Chiu, Chasel
Sent: Friday, May 31, 2019 4:43 AM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Desimone, Nathaniel L 
; Kubacki, Michael A 
; Chaganty, Rangasai V 

Subject: [edk2-devel] [PATCH 1/2] KabylakeSiliconPkg: FSP 2.1 SEC handling.

From: "Chasel, Chiu" 

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

To support FSP Dispatch mode, PlatformSecLib should consume 
FSP_TEMP_RAM_EXIT_PPI to disable temporary memory. This patch added the 
definition of this FSP_TEMP_RAM_EXIT_PPI.

Test: API mode no impact and can still booted.

Cc: Nate DeSimone 
Cc: Michael A Kubacki 
Cc: Sai Chaganty 
Signed-off-by: Chasel Chiu 
---
 Silicon/Intel/KabylakeSiliconPkg/Include/Ppi/TempRamExitPpi.h | 50 
++
 Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec|  2 ++
 2 files changed, 52 insertions(+)

diff --git a/Silicon/Intel/KabylakeSiliconPkg/Include/Ppi/TempRamExitPpi.h 
b/Silicon/Intel/KabylakeSiliconPkg/Include/Ppi/TempRamExitPpi.h
new file mode 100644
index 00..9e728a5d4d
--- /dev/null
+++ b/Silicon/Intel/KabylakeSiliconPkg/Include/Ppi/TempRamExitPpi.h
@@ -0,0 +1,50 @@
+/** @file
+  This file defines the Silicon Temp Ram Exit PPI which implements the
+  required programming steps for disabling temporary memory.
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef _FSP_TEMP_RAM_EXIT_PPI_H_
+#define _FSP_TEMP_RAM_EXIT_PPI_H_
+
+///
+/// Global ID for the FSP_TEMP_RAM_EXIT_PPI.
+///
+#define FSP_TEMP_RAM_EXIT_GUID \
+  { \
+0xbc1cfbdb, 0x7e50, 0x42be, { 0xb4, 0x87, 0x22, 0xe0, 0xa9, 0x0c, 
+0xb0, 0x52 } \
+  }
+
+//
+// Forward declaration for the FSP_TEMP_RAM_EXIT_PPI.
+//
+typedef struct _FSP_TEMP_RAM_EXIT_PPI FSP_TEMP_RAM_EXIT_PPI;
+
+/**
+  Silicon function for disabling temporary memory.
+  @param[in] TempRamExitParamPtr - Pointer to the TempRamExit parameters 
structure.
+   This structure is normally defined in the 
Integration
+   Guide. If it is not defined in the 
Integration Guide,
+   pass NULL.
+  @retval EFI_SUCCESS- Execution was completed successfully.
+  @retval Status - Error status reported by sub-functions if 
implemented.
+**/
+typedef
+EFI_STATUS
+(EFIAPI *FSP_TEMP_RAM_EXIT) (
+  IN  VOID*TempRamExitParamPtr
+  );
+
+///
+/// This PPI provides function to disable temporary memory.
+///
+struct _FSP_TEMP_RAM_EXIT_PPI {
+  FSP_TEMP_RAM_EXIT   TempRamExit;
+};
+
+extern EFI_GUID gFspTempRamExitPpiGuid;
+
+#endif // _FSP_TEMP_RAM_EXIT_PPI_H_
diff --git a/Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec 
b/Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec
index a613079dd4..874cbee7a7 100644
--- a/Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec
+++ b/Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec
@@ -347,6 +347,8 @@ gPeiTpmInitializationDonePpiGuid = {0xa030d115, 0x54dd, 
0x447b, { 0x90, 0x64, 0x  ##  gSiPolicyPpiGuid  =  {0xaebffa01, 0x7edc, 0x49ff, 
{0x8d, 0x88, 0xcb, 0x84, 0x8c, 0x5e, 0x86, 0x70}}  gSiPreMemPolicyPpiGuid = 
{0xc133fe57, 0x17c7, 0x4b09, {0x8b, 0x3c, 0x97, 0xc1, 0x89, 0xd0, 0xab, 0x8d}}
+gFspTempRamExitPpiGuid  = {0xbc1cfbdb, 0x7e50, 0x42be, {0xb4, 0x87, 0x22, 
0xe0, 0xa9, 0x0c, 0xb0, 0x52}}
+
 ##
 ## SystemAgent
 ##
--
2.19.1.windows.1





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

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



Re: [edk2-devel] [PATCH 2/2] KabylakeOpenBoardPkg: Support DynamicExPCD from FSP.

2019-06-05 Thread Nate DeSimone
Reviewed-by: Nate DeSimone 

-Original Message-
From: Chiu, Chasel 
Sent: Friday, May 31, 2019 4:42 AM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Kubacki, Michael A 
; Chaganty, Rangasai V 
; Desimone, Nathaniel L 

Subject: [PATCH 2/2] KabylakeOpenBoardPkg: Support DynamicExPCD from FSP.

From: "Chasel, Chiu" 

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

Cleaned up unused PciExpress related PCD from INF and remove unnecessary DEFINE 
from DSC.
Defines some PCDs as different types per API mode or Dispatch mode, also 
enlarge PeiMemory for Dispatch mode as both FSP and boot loader shares the same 
PeiMemory.

Test: Boot with FSP API mode successfully.

Cc: Michael A Kubacki 
Cc: Sai Chaganty 
Cc: Nate DeSimone 
Signed-off-by: Chasel Chiu 
---
 Platform/Intel/KabylakeOpenBoardPkg/Features/Tbt/TbtInit/Smm/TbtSmm.inf |  3 
+--
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc   | 17 
-
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkgPcd.dsc| 25 
+++--
 3 files changed, 36 insertions(+), 9 deletions(-)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Features/Tbt/TbtInit/Smm/TbtSmm.inf 
b/Platform/Intel/KabylakeOpenBoardPkg/Features/Tbt/TbtInit/Smm/TbtSmm.inf
index 9218c8fe67..8bc2f8729f 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/Features/Tbt/TbtInit/Smm/TbtSmm.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Features/Tbt/TbtInit/Smm/TbtSm
+++ m.inf
@@ -1,7 +1,7 @@
 ### @file
 # Component information file for the ThunderBolt Smm module.
 #
-# Copyright (c) 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2018 - 2019, Intel Corporation. All rights 
+reserved.
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -44,7 +44,6 @@
 
 [Pcd]
   gBoardModuleTokenSpaceGuid.PcdSwSmiDTbtEnumerate ## CONSUMES
-  gSiPkgTokenSpaceGuid.PcdPciExpressRegionLength  ## CONSUMES
 
 [FixedPcd]
   gSiPkgTokenSpaceGuid.PcdAcpiBaseAddress   ## CONSUMES
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
index 1dfe49a7ad..8dbdf25787 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
+++ b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
@@ -15,7 +15,6 @@
   DEFINE  PLATFORM_PACKAGE= MinPlatformPkg
   DEFINE  PLATFORM_SI_PACKAGE = KabylakeSiliconPkg
   DEFINE  PLATFORM_SI_BIN_PACKAGE = KabylakeSiliconBinPkg
-  DEFINE  PLATFORM_FSP_BIN_PACKAGE= AmberLakeFspBinPkg
   DEFINE  PLATFORM_BOARD_PACKAGE  = KabylakeOpenBoardPkg
   DEFINE  BOARD   = KabylakeRvp3
   DEFINE  PROJECT = 
$(PLATFORM_BOARD_PACKAGE)/$(BOARD)
@@ -40,6 +39,22 @@
   DEFINE  PLATFORM_FSP_BIN_PACKAGE= AmberLakeFspBinPkg
 !endif
 
+[PcdsDynamicExDefault.common.DEFAULT]
+!if gMinPlatformPkgTokenSpaceGuid.PcdFspWrapperBootMode == TRUE !if 
+gIntelFsp2WrapperTokenSpaceGuid.PcdFspModeSelection == 0
+  #
+  # Include FSP DynamicEx PCD settings in Dispatch mode
+  #
+  !include $(PLATFORM_FSP_BIN_PACKAGE)/FspPcds.dsc
+
+  #
+  # Override some FSP consumed PCD default value to match platform requirement.
+  #
+  gSiPkgTokenSpaceGuid.PcdSiPciExpressBaseAddress 
+|gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
+
+gSiPkgTokenSpaceGuid.PcdSiPciExpressRegionLength|gMinPlatformPkgTokenSp
+aceGuid.PcdPciExpressRegionLength
+!endif
+!endif
+
 

 #
 # Defines Section - statements that will be processed to create a Makefile.
diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkgPcd.dsc 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkgPcd.dsc
index 63d0c4c2e6..fbd43a6947 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkgPcd.dsc
+++ b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkgPcd.d
+++ sc
@@ -48,7 +48,7 @@
   gMinPlatformPkgTokenSpaceGuid.PcdMaxCpuSocketCount|1
 
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE000
-  gSiPkgTokenSpaceGuid.PcdPciExpressRegionLength|0x1000
+  gMinPlatformPkgTokenSpaceGuid.PcdPciExpressRegionLength|0x1000
   gSiPkgTokenSpaceGuid.PcdTemporaryRamBase|0xFEF8
   gSiPkgTokenSpaceGuid.PcdTemporaryRamSize|0x0004
   gIntelFsp2PkgTokenSpaceGuid.PcdTemporaryRamBase|0xFEF0
@@ -147,6 +147,15 @@ gSiPkgTokenSpaceGuid.PcdTsegSize|0x80
   gIntelFsp2WrapperTokenSpaceGuid.PcdFsptBaseAddress|0xFFEBC000
   gIntelFsp2WrapperTokenSpaceGuid.PcdFspmBaseAddress|0xFFE0
 
+  ## Specifies timeout value in microseconds for the BSP to detect all APs for 
the first time.
+  # @Prompt Timeout for the BSP to detect all APs for the first time.
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds|1000
+
+!if (gMinPlatformPkgTokenSpaceGuid.PcdFspWrapperBootMode == FALSE) || 

Re: [edk2-devel] [PATCH 1/2] KabylakeSiliconPkg: Support DynamicExPCD from FSP.

2019-06-05 Thread Nate DeSimone
Reviewed-by: Nate DeSimone 

-Original Message-
From: Chiu, Chasel 
Sent: Friday, May 31, 2019 4:42 AM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Kubacki, Michael A 
; Chaganty, Rangasai V 
; Desimone, Nathaniel L 

Subject: [PATCH 1/2] KabylakeSiliconPkg: Support DynamicExPCD from FSP.

From: "Chasel, Chiu" 

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

FSP Dispatch mode can consume DynamicEx PCD from boot loader so it must include 
those PCD in PCD database for FSP to consume.
PeiPostMemSiliconPolicyInitLib.inf (this is for FSP Dispatch mode) has all PCDs 
included to ensure they can be built into PCD database.

Also cleaned up unused PciExpress related PCD from INFs.

Cc: Michael A Kubacki 
Cc: Sai Chaganty 
Cc: Nate DeSimone 
Signed-off-by: Chasel Chiu 
---
 Silicon/Intel/KabylakeSiliconPkg/Library/PeiDxeSmmMmPciLib/PeiDxeSmmMmPciLib.c 
| 8 ++--
 
Silicon/Intel/KabylakeSiliconPkg/Cpu/Library/PeiDxeSmmCpuPlatformLib/PeiDxeSmmCpuPlatformLib.inf
   | 7 +--
 Silicon/Intel/KabylakeSiliconPkg/KabylakeSiliconPkg.dsc
| 6 +-
 
Silicon/Intel/KabylakeSiliconPkg/Library/PeiDxeSmmMmPciLib/PeiDxeSmmMmPciLib.inf
   | 5 +++--
 Silicon/Intel/KabylakeSiliconPkg/Library/SiliconInitLib/SiliconInitLib.inf 
| 3 +--
 Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec 
| 8 ++--
 
Silicon/Intel/KabylakeSiliconPkg/SystemAgent/Library/PeiDxeSmmSaPlatformLib/PeiDxeSmmSaPlatformLib.inf
 | 7 +--
 
Silicon/Intel/KabylakeSiliconPkg/SystemAgent/Library/PeiSaPolicyLib/PeiSaPolicyLib.inf
 | 3 +--
 Silicon/Intel/KabylakeSiliconPkg/SystemAgent/SaInit/Dxe/SaInitDxe.inf  
| 3 +--
 9 files changed, 25 insertions(+), 25 deletions(-)

diff --git 
a/Silicon/Intel/KabylakeSiliconPkg/Library/PeiDxeSmmMmPciLib/PeiDxeSmmMmPciLib.c
 
b/Silicon/Intel/KabylakeSiliconPkg/Library/PeiDxeSmmMmPciLib/PeiDxeSmmMmPciLib.c
index 51a06528e0..d99ee8e644 100644
--- 
a/Silicon/Intel/KabylakeSiliconPkg/Library/PeiDxeSmmMmPciLib/PeiDxeSmmMmPciLib.c
+++ b/Silicon/Intel/KabylakeSiliconPkg/Library/PeiDxeSmmMmPciLib/PeiDxeS
+++ mmMmPciLib.c
@@ -1,7 +1,7 @@
 /** @file
   This file contains routines that get PCI Express Address
 
-Copyright (c) 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -27,5 +27,9 @@ MmPciBase (
 {
   ASSERT ((Bus <= 0xFF) && (Device <= 0x1F) && (Function <= 0x7));
 
-  return ((UINTN) PcdGet64 (PcdPciExpressBaseAddress) + (UINTN) (Bus << 20) + 
(UINTN) (Device << 15) + (UINTN) (Function << 12));
+#ifdef FSP_FLAG
+  return ((UINTN) PcdGet64 (PcdSiPciExpressBaseAddress) + (UINTN) (Bus 
+<< 20) + (UINTN) (Device << 15) + (UINTN) (Function << 12)); #else
+  return ((UINTN) PcdGet64 (PcdPciExpressBaseAddress)   + (UINTN) (Bus << 20) 
+ (UINTN) (Device << 15) + (UINTN) (Function << 12));
+#endif
 }
diff --git 
a/Silicon/Intel/KabylakeSiliconPkg/Cpu/Library/PeiDxeSmmCpuPlatformLib/PeiDxeSmmCpuPlatformLib.inf
 
b/Silicon/Intel/KabylakeSiliconPkg/Cpu/Library/PeiDxeSmmCpuPlatformLib/PeiDxeSmmCpuPlatformLib.inf
index 21d441a577..d2e813fea3 100644
--- 
a/Silicon/Intel/KabylakeSiliconPkg/Cpu/Library/PeiDxeSmmCpuPlatformLib/PeiDxeSmmCpuPlatformLib.inf
+++ b/Silicon/Intel/KabylakeSiliconPkg/Cpu/Library/PeiDxeSmmCpuPlatformL
+++ ib/PeiDxeSmmCpuPlatformLib.inf
@@ -1,7 +1,7 @@
 ## @file
 # Component description file for CPU Platform Lib  # -# Copyright (c) 2017, 
Intel Corporation. All rights reserved.
+# Copyright (c) 2017 - 2019, Intel Corporation. All rights 
+reserved.
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -34,11 +34,6 @@ 
MdePkg/MdePkg.dec  UefiCpuPkg/UefiCpuPkg.dec  KabylakeSiliconPkg/SiPkg.dec
 
-
-[Pcd]
-gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
-
-
 [Sources]
 CpuPlatformLibrary.h
 CpuPlatformLibrary.c
diff --git a/Silicon/Intel/KabylakeSiliconPkg/KabylakeSiliconPkg.dsc 
b/Silicon/Intel/KabylakeSiliconPkg/KabylakeSiliconPkg.dsc
index 5b114ae99e..aa481d0307 100644
--- a/Silicon/Intel/KabylakeSiliconPkg/KabylakeSiliconPkg.dsc
+++ b/Silicon/Intel/KabylakeSiliconPkg/KabylakeSiliconPkg.dsc
@@ -47,7 +47,11 @@ gSiPkgTokenSpaceGuid.PcdSiCatalogDebugEnable |FALSE
 
 [PcdsFixedAtBuild.common]
 gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE000
-gSiPkgTokenSpaceGuid.PcdPciExpressRegionLength   |0x1000
+gSiPkgTokenSpaceGuid.PcdSiPciExpressRegionLength |0x1000
+#
+# This DSC mainly for GreenH Silicon code build so 
+PciExpressBaseAddress can be FixedAtBuild # 
+gSiPkgTokenSpaceGuid.PcdSiPciExpressBaseAddress|gEfiMdePkgTokenSpaceGui
+d.PcdPciExpressBaseAddress
 
 [Defines]
   PLATFORM_NAME = KabylakeSiliconPkg
diff --git 
a/Silicon/Intel/KabylakeSiliconPkg/Library/PeiDxeSmmMmPciLib/PeiDxeSmmMmPciLib.inf
 

Re: [edk2-devel] [PATCH] IntelFsp2Pkg/SplitFspBin.py: Revert FSP 1.x support.

2019-06-05 Thread Nate DeSimone
Reviewed-by: Nate DeSimone 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Chiu, Chasel
Sent: Friday, May 31, 2019 12:09 AM
To: devel@edk2.groups.io
Cc: Gao, Liming 
Subject: [edk2-devel] [PATCH] IntelFsp2Pkg/SplitFspBin.py: Revert FSP 1.x 
support.

This reverts commit:
  591b8cb7f3d026d2fa4483c59f3d5fb14be181bf.
Will submit again after freeze done.

Cc: Liming Gao 
Signed-off-by: Chasel Chiu 
---
 IntelFsp2Pkg/Tools/SplitFspBin.py   | 21 
-
 IntelFsp2Pkg/Tools/UserManuals/SplitFspBinUserManual.md | 47 
++-
 2 files changed, 30 insertions(+), 38 deletions(-)

diff --git a/IntelFsp2Pkg/Tools/SplitFspBin.py 
b/IntelFsp2Pkg/Tools/SplitFspBin.py
index 15c8bebee2..2458231d09 100644
--- a/IntelFsp2Pkg/Tools/SplitFspBin.py
+++ b/IntelFsp2Pkg/Tools/SplitFspBin.py
@@ -1,6 +1,6 @@
 ## @ FspTool.py
 #
-# Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
+# Copyright (c) 2015 - 2018, Intel Corporation. All rights 
+reserved.
 # SPDX-License-Identifier: BSD-2-Clause-Patent  #  ## @@ -14,12 +14,12 @@ 
import argparse
 from   ctypes import *
 
 """
-This utility supports some operations for Intel FSP 1.x/2.x image.
+This utility supports some operations for Intel FSP 2.0 image.
 It supports:
-- Display FSP 1.x/2.x information header
-- Split FSP 2.x image into individual FSP-T/M/S/O component
-- Rebase FSP 1.x/2.x components to a different base address
-- Generate FSP 1.x/2.x mapping C header file
+- Display FSP 2.0 information header
+- Split FSP 2.0 image into individual FSP-T/M/S/O component
+- Rebase FSP 2.0 components to a different base address
+- Generate FSP mapping C header file
 """
 
 CopyRightHeaderFile = """/*
@@ -500,6 +500,8 @@ class FirmwareDevice:
 
 fih = None
 for fsp in self.FspList:
+if fsp.Fih.HeaderRevision < 3:
+raise Exception("ERROR: FSP 1.x is not supported by 
+ this tool !")
 if not fih:
 fih = fsp.Fih
 else:
@@ -711,8 +713,6 @@ def SplitFspBin (fspfile, outdir, nametemplate):
 fd.ParseFsp ()
 
 for fsp in fd.FspList:
-if fsp.Fih.HeaderRevision < 3:
-raise Exception("ERROR: FSP 1.x is not supported by the split 
command !")
 ftype = fsp.Type
 if not nametemplate:
 nametemplate = fspfile
@@ -742,11 +742,6 @@ def RebaseFspBin (FspBinary, FspComponent, FspBase, 
OutputDir, OutputFile):
 
 found = False
 for fsp in fd.FspList:
-# Is this FSP 1.x single binary?
-if fsp.Fih.HeaderRevision < 3:
-found = True
-ftype = 'X'
-break
 ftype = fsp.Type.lower()
 if ftype == fspcomp:
 found = True
diff --git a/IntelFsp2Pkg/Tools/UserManuals/SplitFspBinUserManual.md 
b/IntelFsp2Pkg/Tools/UserManuals/SplitFspBinUserManual.md
index 06d87bbb2e..064e0ac845 100644
--- a/IntelFsp2Pkg/Tools/UserManuals/SplitFspBinUserManual.md
+++ b/IntelFsp2Pkg/Tools/UserManuals/SplitFspBinUserManual.md
@@ -1,71 +1,68 @@
-# SplitFspBin.py is a python script to support some operations on Intel FSP 
1.x/2.x image.
+# SplitFspBin.py is a python script to support some operations on Intel FSP 
2.0 image.
 
 It supports:
 
-- Split Intel FSP 2.x image into individual FSP-T/M/S/O component
+- Split Intel FSP 2.0 image into individual FSP-T/M/S/O component
 
-- Rebase Intel FSP 1.x/2.x components to different base addresses
+- Rebase Intel FSP 2.0 components to different base addresses
 
-- Generate Intel FSP 1.x/2.x C header file
+- Generate Intel FSP 2.0 C header file
 
-- Display Intel FSP 1.x/2.x information header for each FSP component
+- Display Intel FSP 2.0 information header for each FSP component
 
-## Split Intel FSP 2.x image
+## Split Intel FSP 2.0 image
 
-FSP 1.x image is not supported by split command.
-To split individual FSP component in Intel FSP 2.x image, the following
+To split individual FSP component in Intel FSP 2.0 image, the following
 command can be used:
 
**python SplitFspBin.py split [-h] -f FSPBINARY [-o OUTPUTDIR] [-n 
NAMETEMPLATE]**
 
-For example:
+For example:  
 
`python SplitFspBin.py split -f FSP.bin`
 
It will create FSP_T.bin, FSP_M.bin and FSP_S.bin in current directory.
 
-## Rebase Intel FSP 1.x/2.x components
+## Rebase Intel FSP 2.0 components
 
-To rebase one or multiple FSP components in Intel FSP 1.x/2.x image, the 
following
+To rebase one or multiple FSP components in Intel FSP 2.0 image, the 
+following
 command can be used:
 
**python SplitFspBin.py rebase [-h] -f FSPBINARY -c {t,m,s,o} [{t,m,s,o} 
...] -b FSPBASE [FSPBASE ...] [-o OUTPUTDIR] [-n OUTPUTFILE]**
 
-For example:
+For example:  
 
-   `python SplitFspBin.py rebase -f FSP.bin -c t -b 0xFFF0 -n FSP_new.bin`
+   `python SplitFspBin.py rebase -f FSP.bin –c t –b 0xFFF0 –n 
+ FSP_new.bin`

Re: [edk2-devel] [RFC] Proposal to move IntelSiliconPkg from edk2 repo to edk2-platforms repo

2019-06-05 Thread Chaganty, Rangasai V
/master/Silicon/Intel seems to be the logical place for this package but other 
suggestions are welcome.

Regards,
Sai

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

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



Re: [edk2-devel] [PATCH] OvmfPkg/QemuVideoDxe: Shouldn't assume system in VGA alias mode.

2019-06-05 Thread Laszlo Ersek
On 06/05/19 14:00, Laszlo Ersek wrote:
> On 06/05/19 13:14, Marc W Chen wrote:
>> Query the supported attributes firstly, then AND (&&) both
>> VGA_IO and VGA_IO_16.
> 
> I don't think you mean "logical AND" above.

On second thought, you do mean "logical AND" above, it's just that the
wording is a bit difficult to understand (to me anyway). So please
ignore this part of my review (but please answer the rest of the questions).

Thanks
Laszlo

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

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



Re: [edk2-devel] [PATCH v1 1/1] BaseTools: don't use WHOLEARCHIVE linker flag for VS2017 toolchain

2019-06-05 Thread Liming Gao
I build edk2 OVMF with VS2015 and VS2017. Their image size are almost same. 
Have you the additional options to disable the optimization? In fact, /GL 
option will remove the unused function and logic. 

> -Original Message-
> From: Roman Agafonov [mailto:roman.agafo...@aquantia.com]
> Sent: Wednesday, June 5, 2019 1:21 AM
> To: Gao, Liming ; devel@edk2.groups.io
> Cc: Feng, Bob C ; Zhu, Yonghong 
> Subject: Re: [PATCH v1 1/1] BaseTools: don't use WHOLEARCHIVE linker flag for 
> VS2017 toolchain
> 
> Hi Liming,
> 
> Sure. Here is what I get after building our NIC driver binary with VS2015x86 
> and VS2017 toolchains:
> 
> pcfist@pcfist-pc:/mnt/c/src/uefi/udk2018$ du -h 
> Build/xgbe_atl/RELEASE_VS2015x86/X64/xgbe_atl.efi
> Build/xgbe_atl/RELEASE_VS2017/X64/xgbe_atl.efi
> 36K     Build/xgbe_atl/RELEASE_VS2015x86/X64/xgbe_atl.efi
> 68K     Build/xgbe_atl/RELEASE_VS2017/X64/xgbe_atl.efi
> 
> Best regards,
> Roman
> 
> From: Gao, Liming 
> Sent: Tuesday, June 4, 2019 6:54 PM
> To: Roman Agafonov; devel@edk2.groups.io
> Cc: Feng, Bob C; Zhu, Yonghong
> Subject: RE: [PATCH v1 1/1] BaseTools: don't use WHOLEARCHIVE linker flag for 
> VS2017 toolchain
> 
> Can you show the size data with VS2017 and VS2015 for the same code?
> 
> Thanks
> Liming
> > -Original Message-
> > From: Roman Agafonov [mailto:roman.agafo...@aquantia.com]
> > Sent: Tuesday, June 4, 2019 11:41 PM
> > To: devel@edk2.groups.io
> > Cc: Feng, Bob C ; Gao, Liming ; 
> > Zhu, Yonghong 
> > Subject: [PATCH v1 1/1] BaseTools: don't use WHOLEARCHIVE linker flag for 
> > VS2017 toolchain
> >
> > I have noticed the resulting binaries are about twice as large when
> > using VS2017 toolchain compared to the ones built with VS2015. It appears
> > this is caused by /WHOLEARCHIVE linker flag used by this toolchain. This
> > flag was previously removed from VS2015 toolchain due to compatibility
> > issues. I believe it should not be used with VS2017 as well.
> >
> > Cc: Bob Feng 
> > Cc: Liming Gao 
> > Cc: Yonghong Zhu 
> > Signed-off-by: Roman Agafonov 
> > ---
> >  BaseTools/Conf/tools_def.template | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/BaseTools/Conf/tools_def.template 
> > b/BaseTools/Conf/tools_def.template
> > index 26a2cf604f74..482a526f3052 100755
> > --- a/BaseTools/Conf/tools_def.template
> > +++ b/BaseTools/Conf/tools_def.template
> > @@ -1545,7 +1545,7 @@ NOOPT_VS2015x86_X64_DLINK_FLAGS    = /NOLOGO 
> > /NODEFAULTLIB /IGNORE:4001 /OPT:REF
> >  *_VS2017_*_APP_FLAGS   = /nologo /E /TC
> >  *_VS2017_*_PP_FLAGS    = /nologo /E /TC /FIAutoGen.h
> >  *_VS2017_*_VFRPP_FLAGS = /nologo /E /TC /DVFRCOMPILE 
> >/FI$(MODULE_NAME)StrDefs.h
> > -*_VS2017_*_DLINK2_FLAGS    = /WHOLEARCHIVE
> > +*_VS2017_*_DLINK2_FLAGS    =
> >  *_VS2017_*_ASM16_PATH  = DEF(VS2017_BIN_IA32)\ml.exe
> >
> >  ##
> > --
> > 2.9.0.windows.1


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

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



[edk2-devel][Patch v2 7/7] MdeModulePkg: Add Capsule On Disk APIs into CapsuleLib.

2019-06-05 Thread Xu, Wei6
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852

CoDCheckCapsuleOnDiskFlag() is to check if CapsuleOnDisk flag in
"OsIndications" Variable is enabled. It is used to indicate whether
capsule on disk is provisioned in normal boot path.

CoDClearCapsuleOnDiskFlag() is to to clear CapsuleOnDisk flags,
including "OsIndications" and "BootNext" variable.

CoDRelocateCapsule() is to relocate the capsules from EFI system
partition. Depends on PcdCapsuleInRamSupport, there are two solutions
to relocate the capsule on disk images:
When Capsule In Ram is supported, the Capsule On Disk images are
relocated into memory, and call UpdateCapsule() service to deliver
the capsules.
When Capsule In Ram is not supported, the Capsule On Disk images are
relocated into a temp file which will be stored in root directory on
a platform specific storage device. CapsuleOnDiskLoadPei PEIM will
retrieve the capsules from the relocation temp file and report
capsule hobs for them.

CoDRemoveTempFile() is to remove the relocation temp file in the next
boot after capsules are processed.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Chao B Zhang 
Signed-off-by: Wei6 Xu 
---
 MdeModulePkg/Include/Library/CapsuleLib.h  |   94 +-
 .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.c   | 1983 
 .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.h   |   63 +
 .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c   |   56 +-
 .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf |   21 +-
 .../DxeCapsuleLibFmp/DxeCapsuleProcessLib.c|  121 +-
 .../Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c |   67 +-
 .../DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf  |3 +-
 .../Library/DxeCapsuleLibNull/DxeCapsuleLibNull.c  |   85 +-
 9 files changed, 2466 insertions(+), 27 deletions(-)
 create mode 100644 MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c
 create mode 100644 MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.h

diff --git a/MdeModulePkg/Include/Library/CapsuleLib.h 
b/MdeModulePkg/Include/Library/CapsuleLib.h
index 1fc2fba3a2..f3cb17cbf9 100644
--- a/MdeModulePkg/Include/Library/CapsuleLib.h
+++ b/MdeModulePkg/Include/Library/CapsuleLib.h
@@ -1,17 +1,37 @@
 /** @file
 
   This library class defines a set of interfaces for how to process capsule 
image updates.
 
-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
 
 **/
 
 #ifndef __CAPSULE_LIB_H__
 #define __CAPSULE_LIB_H__
 
+#include 
+
+
+typedef struct {
+  //
+  // image address.
+  //
+  VOID *ImageAddress;
+  //
+  // The file info of the image comes from.
+  //  if FileInfo == NULL. means image does not come from file
+  //
+  EFI_FILE_INFO*FileInfo;
+} IMAGE_INFO;
+
+//
+// BOOLEAN Variable to save the total size of all Capsule On Disk during 
relocation
+//
+#define COD_RELOCATION_INFO_VAR_NAME   L"CodRelocationInfo"
+
 /**
   The firmware checks whether the capsule image is supported
   by the CapsuleGuid in CapsuleHeader or if there is other specific 
information in
   the capsule image.
 
@@ -79,6 +99,78 @@ EFI_STATUS
 EFIAPI
 ProcessCapsules (
   VOID
   );
 
+/**
+  This routine is called to check if CapsuleOnDisk flag in OsIndications 
Variable
+  is enabled.
+
+  @retval TRUE Flag is enabled
+  @retval FALSEFlag is not enabled
+
+**/
+BOOLEAN
+EFIAPI
+CoDCheckCapsuleOnDiskFlag(
+  VOID
+  );
+
+
+/**
+  This routine is called to clear CapsuleOnDisk flags including OsIndications 
and BootNext variable
+
+  @retval EFI_SUCCESS   All Capsule On Disk flags are cleared
+
+**/
+EFI_STATUS
+EFIAPI
+CoDClearCapsuleOnDiskFlag(
+  VOID
+  );
+
+/**
+  Relocate Capsule on Disk from EFI system partition.
+
+  Two solution to deliver Capsule On Disk:
+  Solution A: If PcdCapsuleInRamSupport is enabled, relocate Capsule On Disk 
to memory and call UpdateCapsule().
+  Solution B: If PcdCapsuleInRamSupport is disabled, relocate Capsule On Disk 
to a platform-specific NV storage
+  device with BlockIo protocol.
+
+  Device enumeration like USB costs time, user can input MaxRetry to tell 
function to retry.
+  Function will stall 100ms between each retry.
+
+  Side Effects:
+Capsule Delivery Supported Flag in OsIndication variable and BootNext 
variable will be cleared.
+Solution B: Content corruption. Block IO write directly touches low level 
write. Orignal partitions, file
+  systems of the relocation device will be corrupted.
+
+  @param[in]MaxRetry Max Connection Retry. Stall 100ms between 
each connection try to ensure
+ devices like USB can get enumerated.
+
+  @retval EFI_SUCCESS   Capsule on Disk images are sucessfully relocated.
+
+**/
+EFI_STATUS
+EFIAPI
+CoDRelocateCapsule(
+  UINTN MaxRetry
+  );
+
+/**
+  Remove the temp file from the root of EFI System Partition.
+  Device enumeration like USB costs time, user can input MaxRetry to tell 

[edk2-devel][Patch v2 3/7] MdeModulePkg: Add CapsuleOnDiskLoadPei PEIM.

2019-06-05 Thread Xu, Wei6
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852

This module provides PPI to load Capsule On Disk temp relocation file
from Root Directory file system, retrieve the capsules from the temp
file and create capsule hobs for these capsules.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Chao B Zhang 
Signed-off-by: Wei6 Xu 
---
 MdeModulePkg/MdeModulePkg.dsc  |   4 +
 .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c| 442 +
 .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.inf  |  64 +++
 .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.uni  |  15 +
 .../CapsuleOnDiskLoadPeiExtra.uni  |  14 +
 5 files changed, 539 insertions(+)
 create mode 100644 
MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c
 create mode 100644 
MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.inf
 create mode 100644 
MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.uni
 create mode 100644 
MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPeiExtra.uni

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 995fd805e1..615edddbcc 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -197,10 +197,13 @@
   gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x06
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizeNonPopulateCapsule|0x0
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizePopulateCapsule|0x0
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxPeiPerformanceLogEntries|28
 
+[PcdsDynamicExDefault]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdRecoveryFileName|L"FVMAIN.FV"
+
 [Components]
   MdeModulePkg/Application/HelloWorld/HelloWorld.inf
   MdeModulePkg/Application/DumpDynPcd/DumpDynPcd.inf
   MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.inf
 
@@ -315,10 +318,11 @@
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
   }
   MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   MdeModulePkg/Universal/BootManagerPolicyDxe/BootManagerPolicyDxe.inf
   MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
+  MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
   MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
   MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
   MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
   MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf
diff --git a/MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c 
b/MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c
new file mode 100644
index 00..40d25f3d3b
--- /dev/null
+++ b/MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c
@@ -0,0 +1,442 @@
+/** @file
+  Recovery module.
+
+  Caution: This module requires additional review when modified.
+  This module will have external input - Capsule-on-Disk Temp Relocation image.
+  This external input must be validated carefully to avoid security issue like
+  buffer overflow, integer overflow.
+
+  RetrieveRelocatedCapsule() will receive untrusted input and do basic 
validation.
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+//
+// The package level header files this module uses
+//
+#include 
+#include 
+
+//
+// The protocols, PPI and GUID defintions for this module
+//
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+//
+// The Library classes this module consumes
+//
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+  Loads a DXE capsule from some media into memory and updates the HOB table
+  with the DXE firmware volume information.
+
+  @param[in]  PeiServices   General-purpose services that are available to 
every PEIM.
+  @param[in]  This  Indicates the EFI_PEI_RECOVERY_MODULE_PPI instance.
+
+  @retval EFI_SUCCESSThe capsule was loaded correctly.
+  @retval EFI_DEVICE_ERROR   A device error occurred.
+  @retval EFI_NOT_FOUND  A recovery DXE capsule cannot be found.
+
+**/
+EFI_STATUS
+EFIAPI
+LoadCapsuleOnDisk (
+  IN EFI_PEI_SERVICES  **PeiServices,
+  IN EFI_PEI_CAPSULE_ON_DISK_PPI   *This
+  );
+
+EFI_PEI_CAPSULE_ON_DISK_PPI mCapsuleOnDiskPpi = {
+  LoadCapsuleOnDisk
+};
+
+EFI_PEI_PPI_DESCRIPTOR mCapsuleOnDiskPpiList = {
+  (EFI_PEI_PPI_DESCRIPTOR_PPI | EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
+  ,
+  
+};
+
+/**
+  Determine if capsule comes from memory by checking Capsule PPI.
+
+  @param[in]  PeiServices General purpose services available to every PEIM.
+
+  @retval TRUE   Capsule comes from memory.
+  @retval FALSE  No capsule comes from memory.
+
+**/
+STATIC
+BOOLEAN
+CheckCapsuleFromRam (
+  IN CONST EFI_PEI_SERVICES  **PeiServices
+  )
+{
+  EFI_STATUS  Status;
+  

[edk2-devel][Patch v2 5/7] MdeModulePkg/CapsuleRuntimeDxe: Introduce PCD to control this feature.

2019-06-05 Thread Xu, Wei6
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852

Introduce PcdCapsuleInRamSupport to turn on/off Capsule In Ram feature.
Platform could choose to drop CapsulePei/CapsuleX64 and not to support
Capsule In Ram.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Chao B Zhang 
Signed-off-by: Wei6 Xu 
---
 MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf |  1 +
 MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleService.c  | 10 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf 
b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
index 338577e293..9da450722b 100644
--- a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
+++ b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
@@ -88,10 +88,11 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode  ## CONSUMES
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizeNonPopulateCapsule   ## 
SOMETIMES_CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizePopulateCapsule  ## 
SOMETIMES_CONSUMES # Populate Image requires reset support.
+  gEfiMdeModulePkgTokenSpaceGuid.PcdCapsuleInRamSupport ## CONSUMES
 
 [Pcd.X64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdCapsulePeiLongModeStackSize   ## 
SOMETIMES_CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable## 
SOMETIMES_CONSUMES
 
diff --git a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleService.c 
b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleService.c
index aaf819c4c6..53a1af44e2 100644
--- a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleService.c
+++ b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleService.c
@@ -2,11 +2,11 @@
   Capsule Runtime Driver produces two UEFI capsule runtime services.
   (UpdateCapsule, QueryCapsuleCapabilities)
   It installs the Capsule Architectural Protocol defined in PI1.0a to signify
   the capsule runtime services are ready.
 
-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
 
 **/
 
 #include "CapsuleService.h"
@@ -69,10 +69,18 @@ UpdateCapsule (
   BOOLEAN   NeedReset;
   BOOLEAN   InitiateReset;
   CHAR16CapsuleVarName[30];
   CHAR16*TempVarName;
 
+  //
+  // Check if platform support Capsule In RAM or not.
+  // Platform could choose to drop CapsulePei/CapsuleX64 and do not support 
Capsule In RAM.
+  //
+  if (!PcdGetBool(PcdCapsuleInRamSupport)) {
+return EFI_UNSUPPORTED;
+  }
+
   //
   // Capsule Count can't be less than one.
   //
   if (CapsuleCount < 1) {
 return EFI_INVALID_PARAMETER;
-- 
2.16.2.windows.1


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

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



[edk2-devel][Patch v2 2/7] MdeModulePkg: Add Capsule On Disk related definition.

2019-06-05 Thread Xu, Wei6
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852

This patch will add Capsule On Disk related definition, including
GUID, PPI and PCDs:
The Capsule On Disk Name GUID indicates the capsule is to store
Capsule On Disk file names.
The Pei Capsule On Disk PPI provides service to retrieve capsules
from Capsule On Disk temp relocation file on mass storage devices
and create capsule hob for these capsules.
PcdCapsuleOnDiskSupport is used to enable/disable Capsule On Disk.
PcdCapsuleInRamSupport is used to enabble/disable Capsule In Ram.
PcdCoDRelocationFileName specifies the Capsule On Disk temp
relocation file name.
PcdCodRelocationDevPath specifies platform specific device to store
Capsule On Disk tem relocation file.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Chao B Zhang 
Signed-off-by: Wei6 Xu 
---
 MdeModulePkg/Include/Ppi/CapsuleOnDisk.h | 48 
 MdeModulePkg/MdeModulePkg.dec| 43 
 MdeModulePkg/MdeModulePkg.uni| 32 +
 3 files changed, 123 insertions(+)
 create mode 100644 MdeModulePkg/Include/Ppi/CapsuleOnDisk.h

diff --git a/MdeModulePkg/Include/Ppi/CapsuleOnDisk.h 
b/MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
new file mode 100644
index 00..28be6e42be
--- /dev/null
+++ b/MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
@@ -0,0 +1,48 @@
+/** @file
+  This file declares Capsule On Disk PPI.  This PPI is used to find and load 
the
+  capsule on files that are relocated into a temp file under rootdir.
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef __PEI_CAPSULE_ON_DISK_PPI_H__
+#define __PEI_CAPSULE_ON_DISK_PPI_H__
+
+#define EFI_PEI_CAPSULE_ON_DISK_PPI_GUID \
+  { \
+0x71a9ea61, 0x5a35, 0x4a5d, {0xac, 0xef, 0x9c, 0xf8, 0x6d, 0x6d, 0x67, 
0xe0 } \
+  }
+
+typedef struct _EFI_PEI_CAPSULE_ON_DISK_PPI EFI_PEI_CAPSULE_ON_DISK_PPI;
+
+/**
+  Loads a DXE capsule from some media into memory and updates the HOB table
+  with the DXE firmware volume information.
+
+  @param  PeiServices   General-purpose services that are available to every 
PEIM.
+  @param  This  Indicates the EFI_PEI_RECOVERY_MODULE_PPI instance.
+
+  @retval EFI_SUCCESSThe capsule was loaded correctly.
+  @retval EFI_DEVICE_ERROR   A device error occurred.
+  @retval EFI_NOT_FOUND  A recovery DXE capsule cannot be found.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_LOAD_CAPSULE_ON_DISK)(
+  IN EFI_PEI_SERVICES **PeiServices,
+  IN EFI_PEI_CAPSULE_ON_DISK_PPI  *This
+  );
+
+///
+///  Finds and loads the recovery files.
+///
+struct _EFI_PEI_CAPSULE_ON_DISK_PPI {
+  EFI_PEI_LOAD_CAPSULE_ON_DISK LoadCapsuleOnDisk;  ///< Loads a DXE binary 
capsule into memory.
+};
+
+extern EFI_GUID gEdkiiPeiCapsuleOnDiskPpiGuid;
+
+#endif
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 6cba729982..d80b728313 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -394,10 +394,13 @@
   gEdkiiS3SmmInitDoneGuid = { 0x8f9d4825, 0x797d, 0x48fc, { 0x84, 0x71, 0x84, 
0x50, 0x25, 0x79, 0x2e, 0xf6 } }
 
   ## Include/Guid/S3StorageDeviceInitList.h
   gS3StorageDeviceInitListGuid = { 0x310e9b8c, 0xcf90, 0x421e, { 0x8e, 0x9b, 
0x9e, 0xef, 0xb6, 0x17, 0xc8, 0xef } }
 
+  ## GUID indicates the capsule is to store Capsule On Disk file names.
+  gEdkiiCapsuleOnDiskNameGuid = { 0x98c80a4f, 0xe16b, 0x4d11, { 0x93, 0x9a, 
0xab, 0xe5, 0x61, 0x26, 0x3, 0x30 } }
+
 [Ppis]
   ## Include/Ppi/AtaController.h
   gPeiAtaControllerPpiGuid   = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0, 0x7a, 
0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
 
   ## Include/Ppi/UsbHostController.h
@@ -464,10 +467,13 @@
   gEdkiiPeiAtaPassThruPpiGuid   = { 0xa16473fd, 0xd474, 0x4c89, { 
0xae, 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 0x9  } }
 
   ## Include/Ppi/Debug.h
   gEdkiiDebugPpiGuid= { 0x999e699c, 0xb013, 0x475e, { 
0xb1, 0x7b, 0xf3, 0xa8, 0xae, 0x5c, 0x48, 0x75 } }
 
+  ## Include/Ppi/CapsuleOnDisk.h
+  gEdkiiPeiCapsuleOnDiskPpiGuid =  {0x71a9ea61, 0x5a35, 0x4a5d, 
{0xac, 0xef, 0x9c, 0xf8, 0x6d, 0x6d, 0x67, 0xe0}}
+
 [Protocols]
   ## Load File protocol provides capability to load and unload EFI image into 
memory and execute it.
   #  Include/Protocol/LoadPe32Image.h
   #  This protocol is deprecated. Native EDKII module should NOT use this 
protocol to load/unload image.
   #  If developer need implement such functionality, they should use 
BasePeCoffLib.
@@ -1473,10 +1479,26 @@
 
   ## Indicates the allowable maximum number of Reset Filters, Reset 
Notifications or Reset Handlers in PEI phase.
   # @Prompt Maximum Number of PEI Reset Filters, Reset Notifications or Reset 
Handlers.
   
gEfiMdeModulePkgTokenSpaceGuid.PcdMaximumPeiResetNotifies|0x10|UINT32|0x010A
 
+  ## Capsule On Disk is to deliver capsules via files on Mass Storage 
device.
+  #  This PCD indicates if the Capsule On Disk 

[edk2-devel][Patch v2 0/7] Implement Capsule On Disk.

2019-06-05 Thread Xu, Wei6
V2:
Fix Ecc check failure.

V1:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852

This patch set implements Capsule On Disk.
Depends on whether platform supports Capsule-In-Ram, Capsule On Disk feature is 
composed of 2 solutions:
Solution A): Load capsules out of TCB, rely on UpdateCapsule() runtime service 
to deliver Capsule-On-Disk.
Solution B): Relocate capsules into a temp file which will be stored in root 
directory on a platform specific storage device.
Leverage existing storage stack in PEI to load all capsule on disk images and 
create capsule hobs for the capsules.
This solution has bigger TCB, but can work without Capsule-In-RAM support.


Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Chao B Zhang 

xuwei6 (7):
  MdePkg: Add Pei Boot In CapsuleOnDisk Mode Ppi definition.
  MdeModulePkg: Add Capsule On Disk related definition.
  MdeModulePkg: Add CapsuleOnDiskLoadPei PEIM.
  MdeModulePkg/BdsDxe: Support Capsule On Disk.
  MdeModulePkg/CapsuleRuntimeDxe: Introduce PCD to control this feature.
  MdeModulePkg/DxeIpl: Support Capsule On Disk.
  MdeModulePkg: Add Capsule On Disk APIs into CapsuleLib.

 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h  |3 +-
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   20 +-
 MdeModulePkg/Core/DxeIplPeim/DxeLoad.c |   37 +-
 MdeModulePkg/Include/Library/CapsuleLib.h  |   94 +-
 MdeModulePkg/Include/Ppi/CapsuleOnDisk.h   |   48 +
 .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.c   | 1983 
 .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.h   |   63 +
 .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c   |   56 +-
 .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf |   21 +-
 .../DxeCapsuleLibFmp/DxeCapsuleProcessLib.c|  121 +-
 .../Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c |   67 +-
 .../DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf  |3 +-
 .../Library/DxeCapsuleLibNull/DxeCapsuleLibNull.c  |   85 +-
 MdeModulePkg/MdeModulePkg.dec  |   43 +
 MdeModulePkg/MdeModulePkg.dsc  |4 +
 MdeModulePkg/MdeModulePkg.uni  |   32 +
 MdeModulePkg/Universal/BdsDxe/BdsDxe.inf   |3 +-
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c   |6 +-
 .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c|  442 +
 .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.inf  |   64 +
 .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.uni  |   15 +
 .../CapsuleOnDiskLoadPeiExtra.uni  |   14 +
 .../CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf|1 +
 .../Universal/CapsuleRuntimeDxe/CapsuleService.c   |   10 +-
 MdePkg/Include/Ppi/BootInRecoveryMode.h|9 +-
 MdePkg/MdePkg.dec  |3 +
 26 files changed, 3205 insertions(+), 42 deletions(-)
 create mode 100644 MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
 create mode 100644 MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c
 create mode 100644 MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.h
 create mode 100644 
MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c
 create mode 100644 
MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.inf
 create mode 100644 
MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.uni
 create mode 100644 
MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPeiExtra.uni

-- 
2.16.2.windows.1


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

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



[edk2-devel][Patch v2 6/7] MdeModulePkg/DxeIpl: Support Capsule On Disk.

2019-06-05 Thread Xu, Wei6
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852

If Capsule On Disk mode, call Capsule On Disk Load PPI to load
capsules. When it fails, still goes to Firmware Update boot path.
BDS will clear corresponding indicator and reboot later on.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Chao B Zhang 
Signed-off-by: Wei6 Xu 
---
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h   |  3 ++-
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 20 ++
 MdeModulePkg/Core/DxeIplPeim/DxeLoad.c  | 37 -
 3 files changed, 49 insertions(+), 11 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
index 063fefb414..90b5b5b211 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
@@ -1,10 +1,10 @@
 /** @file
   Master header file for DxeIpl PEIM. All source files in this module should
   include this file for common definitions.
 
-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
 
 **/
 
 #ifndef __PEI_DXEIPL_H__
@@ -19,10 +19,11 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
 #include 
 #include 
diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
index 62bb3f3077..ff036d8688 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
@@ -3,11 +3,11 @@
 #
 #  This module produces a special PPI named the DXE Initial Program Load (IPL)
 #  PPI to discover and dispatch the DXE Foundation and components that are
 #  needed to run the DXE Foundation.
 #
-#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 #  Copyright (c) 2017, AMD Incorporated. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 ##
@@ -74,21 +74,23 @@
 
 [LibraryClasses.ARM, LibraryClasses.AARCH64]
   ArmMmuLib
 
 [Ppis]
-  gEfiDxeIplPpiGuid ## PRODUCES
-  gEfiPeiDecompressPpiGuid  ## PRODUCES
-  gEfiEndOfPeiSignalPpiGuid ## SOMETIMES_PRODUCES # Not produced on S3 
boot path
-  gEfiPeiReadOnlyVariable2PpiGuid   ## SOMETIMES_CONSUMES
-  gEfiPeiLoadFilePpiGuid## SOMETIMES_CONSUMES
-  gEfiPeiS3Resume2PpiGuid   ## SOMETIMES_CONSUMES # Consumed on S3 
boot path
-  gEfiPeiRecoveryModulePpiGuid  ## SOMETIMES_CONSUMES # Consumed on 
recovery boot path
+  gEfiDxeIplPpiGuid  ## PRODUCES
+  gEfiPeiDecompressPpiGuid   ## PRODUCES
+  gEfiEndOfPeiSignalPpiGuid  ## SOMETIMES_PRODUCES # Not produced 
on S3 boot path
+  gEfiPeiReadOnlyVariable2PpiGuid## SOMETIMES_CONSUMES
+  gEfiPeiLoadFilePpiGuid ## SOMETIMES_CONSUMES
+  gEfiPeiS3Resume2PpiGuid## SOMETIMES_CONSUMES # Consumed on 
S3 boot path
+  gEfiPeiRecoveryModulePpiGuid   ## SOMETIMES_CONSUMES # Consumed on 
recovery boot path
   ## SOMETIMES_CONSUMES
   ## UNDEFINED # HOB
   gEfiVectorHandoffInfoPpiGuid
-  gEfiPeiMemoryDiscoveredPpiGuid## SOMETIMES_CONSUMES
+  gEfiPeiMemoryDiscoveredPpiGuid ## SOMETIMES_CONSUMES
+  gEfiPeiBootInCapsuleOnDiskModePpiGuid  ## SOMETIMES_CONSUMES
+  gEdkiiPeiCapsuleOnDiskPpiGuid  ## SOMETIMES_CONSUMES # Consumed on 
firmware update boot path
 
 [Guids]
   ## SOMETIMES_CONSUMES ## Variable:L"MemoryTypeInformation"
   ## SOMETIMES_PRODUCES ## HOB
   gEfiMemoryTypeInformationGuid
diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c 
b/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
index c6e5b83309..9dc2d4485f 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
@@ -1,11 +1,11 @@
 /** @file
   Last PEIM.
   Responsibility of this module is to load the DXE Core from a Firmware Volume.
 
 Copyright (c) 2016 HP Development Company, L.P.
-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
 
 **/
 
 #include "DxeIpl.h"
@@ -263,17 +263,38 @@ DxeLoadCore (
   UINTN Instance;
   UINT32AuthenticationState;
   UINTN DataSize;
   EFI_PEI_S3_RESUME2_PPI*S3Resume;
   EFI_PEI_RECOVERY_MODULE_PPI   *PeiRecovery;
+  EFI_PEI_CAPSULE_ON_DISK_PPI   *PeiCapsuleOnDisk;
   EFI_MEMORY_TYPE_INFORMATION   MemoryData[EfiMaxMemoryType + 1];
+  VOID  *CapsuleOnDiskModePpi;
+  BOOLEAN   IsCapsuleOnDiskMode;
+
+  IsCapsuleOnDiskMode = FALSE;
 
   //
   // if in S3 Resume, restore configure
   //
   BootMode = GetBootModeHob ();
 
+  //
+  // 

[edk2-devel][Patch v2 1/7] MdePkg: Add Pei Boot In CapsuleOnDisk Mode Ppi definition.

2019-06-05 Thread Xu, Wei6
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852

This PPI indicates current boot mode is capsule on disk mode.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Chao B Zhang 
Signed-off-by: Wei6 Xu 
---
 MdePkg/Include/Ppi/BootInRecoveryMode.h | 9 -
 MdePkg/MdePkg.dec   | 3 +++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Ppi/BootInRecoveryMode.h 
b/MdePkg/Include/Ppi/BootInRecoveryMode.h
index ae40744d9b..71b0ca8586 100644
--- a/MdePkg/Include/Ppi/BootInRecoveryMode.h
+++ b/MdePkg/Include/Ppi/BootInRecoveryMode.h
@@ -1,10 +1,10 @@
 /** @file
   This PPI is installed by the platform PEIM to designate that a recovery boot
   is in progress.
 
-  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
 
   @par Revision Reference:
   This PPI is introduced in PI Version 1.0.
 
@@ -19,6 +19,13 @@
   }
 
 
 extern EFI_GUID gEfiPeiBootInRecoveryModePpiGuid;
 
+#define EFI_PEI_BOOT_IN_CAPSULE_ON_DISK_MODE_PPI \
+  { \
+0xb08a11e4, 0xe2b7, 0x4b75, { 0xb5, 0x15, 0xaf, 0x61, 0x6, 0x68, 0xbf, 
0xd1 } \
+  }
+
+extern EFI_GUID gEfiPeiBootInCapsuleOnDiskModePpiGuid;
+
 #endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 6c563375ee..ec02b8c7c7 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -790,10 +790,13 @@
   gEfiPeiMemoryDiscoveredPpiGuid = {0xf894643d, 0xc449, 0x42d1, {0x8e, 0xa8, 
0x85, 0xbd, 0xd8, 0xc6, 0x5b, 0xde } }
 
   ## Include/Ppi/BootInRecoveryMode.h
   gEfiPeiBootInRecoveryModePpiGuid = { 0x17ee496a, 0xd8e4, 0x4b9a, {0x94, 
0xd1, 0xce, 0x82, 0x72, 0x30, 0x8, 0x50 } }
 
+  ## Include/Ppi/BootInRecoveryMode.h
+  gEfiPeiBootInCapsuleOnDiskModePpiGuid = { 0xb08a11e4, 0xe2b7, 0x4b75, { 
0xb5, 0x15, 0xaf, 0x61, 0x6, 0x68, 0xbf, 0xd1 } }
+
   ## Include/Ppi/EndOfPeiPhase.h
   gEfiEndOfPeiSignalPpiGuid = {0x605EA650, 0xC65C, 0x42e1, {0xBA, 0x80, 0x91, 
0xA5, 0x2A, 0xB6, 0x18, 0xC6 } }
 
   ## Include/Ppi/Reset.h
   gEfiPeiResetPpiGuid = { 0xef398d58, 0x9dfd, 0x4103, {0xbf, 0x94, 0x78, 0xc6, 
0xf4, 0xfe, 0x71, 0x2f } }
-- 
2.16.2.windows.1


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

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



Re: [edk2-devel] [PATCH for-edk2-stable201905] Revert "UefiPayloadPkg: Remove legacy PIC 8259 driver"

2019-06-05 Thread Guo Dong


Sorry missed the notice on the code freeze.
Thanks Liming to create this patch.

Reviewed-by: Guo Dong 


> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, June 5, 2019 12:48 AM
> To: devel@edk2.groups.io
> Cc: Ma, Maurice ; Dong, Guo
> ; You, Benjamin 
> Subject: [PATCH for-edk2-stable201905] Revert "UefiPayloadPkg: Remove
> legacy PIC 8259 driver"
> 
> This reverts commit a1539c46958fb896dee8f7987f4a98e9f9d10796.
> This change will be pushed after edk2-stable201905
> 
> Cc: Maurice Ma 
> Cc: Guo Dong 
> Cc: Benjamin You 
> Signed-off-by: Liming Gao 
> ---
>  UefiPayloadPkg/UefiPayloadPkg.fdf| 1 +
>  UefiPayloadPkg/UefiPayloadPkgIa32.dsc| 1 +
>  UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf
> b/UefiPayloadPkg/UefiPayloadPkg.fdf
> index 4cd88a3f85..ce3b34999b 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.fdf
> +++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
> @@ -104,6 +104,7 @@ INF
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
>  INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>  INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>  INF
> MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryT
> estDxe.inf
> +INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
>  INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
>  INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
>  INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
> diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> index 11cf17ca06..5b6ed36e9c 100644
> --- a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> +++ b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> @@ -432,6 +432,7 @@
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> 
> MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryT
> estDxe.inf
> +  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
>MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
> diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> index 5b7994a62c..d57b5241dc 100644
> --- a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> +++ b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> @@ -433,6 +433,7 @@
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> 
> MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryT
> estDxe.inf
> +  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
>MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
> --
> 2.13.0.windows.1


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

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



Re: [edk2-devel] [RFC] Proposal to move IntelSiliconPkg from edk2 repo to edk2-platforms repo

2019-06-05 Thread Liming Gao
Have BZ for this change? Which stable tag is it for?

Thanks
Liming
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Zeng, Star
Sent: Wednesday, June 5, 2019 10:33 PM
To: devel@edk2.groups.io; Chaganty, Rangasai V 
Cc: Kinney, Michael D ; Ni, Ray ; 
Zeng, Star ; Yao, Jiewen 
Subject: Re: [edk2-devel] [RFC] Proposal to move IntelSiliconPkg from edk2 repo 
to edk2-platforms repo

Just curious about where the IntelSiliconPkg will be put in edk2-platforms repo?


Thanks,
Star

From: devel@edk2.groups.io 
[mailto:devel@edk2.groups.io] On Behalf Of Chaganty, Rangasai V
Sent: Wednesday, May 22, 2019 3:13 PM
To: devel@edk2.groups.io
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Ni, Ray 
mailto:ray...@intel.com>>
Subject: [edk2-devel] [RFC] Proposal to move IntelSiliconPkg from edk2 repo to 
edk2-platforms repo

Hello Everyone,
As we are noticing, there are some activities in progress to reduce edk2 repo.

I would like to propose to move IntelSiliconPkg from edk2 repo to 
edk2-platforms repo.
There is no dependency on this package from any other module in edk2 repo so it 
should be safe to move to edk2-platforms repo.

Regards,
Sai



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

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



Re: [edk2-devel] [RFC] Proposal to move IntelSiliconPkg from edk2 repo to edk2-platforms repo

2019-06-05 Thread Zeng, Star
Just curious about where the IntelSiliconPkg will be put in edk2-platforms repo?


Thanks,
Star

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Chaganty, 
Rangasai V
Sent: Wednesday, May 22, 2019 3:13 PM
To: devel@edk2.groups.io
Cc: Kinney, Michael D ; Ni, Ray 
Subject: [edk2-devel] [RFC] Proposal to move IntelSiliconPkg from edk2 repo to 
edk2-platforms repo

Hello Everyone,
As we are noticing, there are some activities in progress to reduce edk2 repo.

I would like to propose to move IntelSiliconPkg from edk2 repo to 
edk2-platforms repo.
There is no dependency on this package from any other module in edk2 repo so it 
should be safe to move to edk2-platforms repo.

Regards,
Sai



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

View/Reply Online (#41944): https://edk2.groups.io/g/devel/message/41944
Mute This Topic: https://groups.io/mt/31718107/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] EmulatorPkg: don't diaplay the cpu current speed

2019-06-05 Thread Zeng, Star
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Wednesday, June 5, 2019 4:03 PM
> To: Ni, Ray ; Gao, Liming ;
> ard.biesheu...@linaro.org; Leif Lindholm ; Kinney,
> Michael D ; Liu, Zhiguang
> ; Justen, Jordan L ;
> Andrew Fish 
> Cc: devel@edk2.groups.io
> Subject: Re: [edk2-devel] [Patch V2] EmulatorPkg: don't diaplay the cpu
> current speed
> 
> On 06/05/19 03:10, Ni, Ray wrote:
> > Hi everyone,
> >
> > Hao pushed the patch because:
> > 1. it's a bug fix
> > 2. it got a R-b.
> > I don't think it's his fault.
> >
> > For #1, it's gap in process.
> > For #2, it's my fault. Because even the patch title says EmulatorPkg but the
> patch itself changes MdeModulePkg, I am still the person who can approve
> changes in both packages.
> >
> > In Maintainers.txt:
> > R: Ray Ni 
> >   (especially for Bus, Universal/Console, Universal/Disk,
> >Universal/BdsDxe and related libraries, header files)
> >
> > The UiApp actually is not in the "especially" part, but the word 
> > "especially"
> > means I can also R-b to other components. In fact, I am not quite
> > qualified on the other components, e.g.: UiApp.
> > So I propose to assign clear reviewers for each components in
> MdeModulePkg.
> > What do you think?
> 
> Fully agreed. MdeModulePkg is huge and we should have fine-grained
> maintainership assignments.

I also agree.

> 
> Thanks
> Laszlo
> 
> 


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

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



Re: [edk2-devel] [PATCH] CryptoPkg/OpensslLib: fix VS2017 build failure

2019-06-05 Thread Wang, Jian J
Laszlo,

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Wednesday, June 05, 2019 7:00 PM
> To: devel@edk2.groups.io; Wang, Jian J 
> Cc: Bi, Dandan ; Lu, XiaoyuX 
> Subject: Re: [edk2-devel] [PATCH] CryptoPkg/OpensslLib: fix VS2017 build 
> failure
> 
> Hi Jian,
> 
> On 06/04/19 23:18, Wang, Jian J wrote:
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1878
> >
> > This issue is specific to VS2017 which tries to resolve symbol referenced
> > by a symbol not really referenced eventually.
> >
> > ossl_init_load_crypto_strings
> > -> err_load_crypto_strings_int (not really referenced)
> > -> ERR_load_OSSL_STORE_strings
> >
> > Because OPENSSL_NO_ERR and OPENSSL_NO_AUTOERRINIT are not defined
> by
> > default, err_load_crypto_strings_int() will not be actually referenced
> > by ossl_init_load_crypto_strings().
> >
> > Since err_load_crypto_strings_int() is not actually referenced at all,
> > the fix can be done simply by removing crypto/err/err_all.c from build.
> >
> > Cc: Dandan Bi 
> > Cc: Xiaoyu Lu 
> > Signed-off-by: Jian J Wang 
> > ---
> >  CryptoPkg/Library/OpensslLib/OpensslLib.inf   | 1 -
> >  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf | 1 -
> >  2 files changed, 2 deletions(-)
> >
> > diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > index 378fa6588e..5a2424fc16 100644
> > --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > @@ -218,7 +218,6 @@
> >$(OPENSSL_PATH)/crypto/dso/dso_win32.c
> >$(OPENSSL_PATH)/crypto/ebcdic.c
> >$(OPENSSL_PATH)/crypto/err/err.c
> > -  $(OPENSSL_PATH)/crypto/err/err_all.c
> >$(OPENSSL_PATH)/crypto/err/err_prn.c
> >$(OPENSSL_PATH)/crypto/evp/bio_b64.c
> >$(OPENSSL_PATH)/crypto/evp/bio_enc.c
> > diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> > index 24d3d96459..588da4c040 100644
> > --- a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> > +++ b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> > @@ -218,7 +218,6 @@
> >$(OPENSSL_PATH)/crypto/dso/dso_win32.c
> >$(OPENSSL_PATH)/crypto/ebcdic.c
> >$(OPENSSL_PATH)/crypto/err/err.c
> > -  $(OPENSSL_PATH)/crypto/err/err_all.c
> >$(OPENSSL_PATH)/crypto/err/err_prn.c
> >$(OPENSSL_PATH)/crypto/evp/bio_b64.c
> >$(OPENSSL_PATH)/crypto/evp/bio_enc.c
> >
> 
> after the edk2-stable201905 tag, we might want to update
> "CryptoPkg/Library/OpensslLib/process_files.pl" as well, to exclude this
> file. In order to fix the build issue for the stable tag, this patch is
> acceptable (I see it's been pushed already, and that's fine); but in the
> longer term, we should not manually update the section that's marked as
> "Autogenerated files list starts here".
> 
> If you agree, can you please file a TianoCore BZ about this? (I.e.
> special handling for "err_all.c" in "process_files.pl".)
> 

Agree. The fix is a bit rush. A BZ has been filed. Thanks for catching it.

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

Regards,
Jian

> Thanks
> Laszlo
> 
> 


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

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



Re: [edk2-devel] [PATCH for-next] MdeModulePkg/PciBusDxe: catch unimplemented extended config space reads

2019-06-05 Thread Ard Biesheuvel
On Wed, 5 Jun 2019 at 12:15, Laszlo Ersek  wrote:
>
> On 06/05/19 11:25, Ard Biesheuvel wrote:
> > On Tue, 4 Jun 2019 at 23:44, Laszlo Ersek  wrote:
> >>
> >> When assigning a physical PCIe device to a QEMU/KVM guest, PciBusDxe may
> >> find that the extended config space is not (fully) implemented. In
> >> LocatePciExpressCapabilityRegBlock(), "CapabilityEntry" may be read as
> >> 0x_ at a given config space offset, after which the loop gets
> >> stuck spinning on offset 0xFFC (the read at offset 0xFFC returns
> >> 0x_ most likely as well).
> >>
> >> Another scenario (not related to virtualization) for triggering the above
> >> is when a Conventional PCI bus -- exposed by a PCIe-to-PCI bridge in the
> >> topology -- intervenes between a PCI Express Root Port and a PCI Express
> >> Endpoint. The Conventional PCI bus limits the accessible config space of
> >> the PCI Express Endpoint, even though the endpoint advertizes the PCI
> >> Express capability. Here's a diagram, courtesy of Alex Williamson:
> >>
> >>   [PCIe Root Port]--[PCIe-to-PCI]--[PCI-to-PCIe]--[PCIe EP]
> >>   ->|  |<- Conventional PCI bus
> >>
> >> Catch reads of 0x_ in LocatePciExpressCapabilityRegBlock(), and
> >> break out of the scan with a warning message. The function will return
> >> EFI_NOT_FOUND.
> >>
> >> Cc: Alex Williamson 
> >> Cc: Hao A Wu 
> >> Cc: Jian J Wang 
> >> Cc: Ray Ni 
> >> Cc: Star Zeng 
> >> Signed-off-by: Laszlo Ersek 
> >> ---
> >>
> >> Notes:
> >> Repo:   https://github.com/lersek/edk2.git
> >> Branch: pcibus_no_ext_conf
> >>
> >>  MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c | 13 +
> >>  1 file changed, 13 insertions(+)
> >>
> >> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c 
> >> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> >> index 214aeecdd40a..6283d602207c 100644
> >> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> >> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> >> @@ -236,6 +236,19 @@ LocatePciExpressCapabilityRegBlock (
> >>break;
> >>  }
> >>
> >> +if (CapabilityEntry == MAX_UINT32) {
> >
> > Should we check here that the offset > 0x100 ? Otherwise, this affects
> > more than just the extended config space.
>
> A separate function exists for locating caps in the conventional config
> space (LocateCapabilityRegBlock()).
>
> Whereas the function being patched --
> LocatePciExpressCapabilityRegBlock() -- is supposed to start with a
> capability offset into the extended config space, passed in by the
> caller via *Offset, or else at 0x100 if *Offset is 0.
>
> And, my understanding is that an extended cap shall never chain to a
> conventional cap. The spec says,
>
> Next Capability Offset – This field contains the offset to the next
> PCI Express Capability structure or 000h if no other items exist in
> the linked list of Capabilities.
>
> For Extended Capabilities implemented in Configuration Space, this
> offset is relative to the beginning of PCI compatible Configuration
> Space and thus must always be either 000h (for terminating list of
> Capabilities) or greater than 0FFh.
>
> The bottom 2 bits of this offset are Reserved and must be
> implemented as 00b although software must mask them to allow for
> future uses of these bits.
>
> Additionally, the capability header is different for conventional
> capabilities: EFI_PCI_CAPABILITY_HDR -- 2 bytes -- vs.
> PCI_EXPRESS_EXTENDED_CAPABILITIES_HEADER -- 4 bytes. So if this loop
> ever crossed over into normal config space, it would break horribly,
> regardless of this patch.
>
> A more general question would be how much we should armor such functions
> -- i.e., capability list scanning -- with sanity checks.
>
> My answer to that was authoring PciCapLib, which detects loops in cap
> lists, oversized capability reads/writes, an absent extended config
> space in spite of a present express capability; maybe more. Basically
> everything I could think of and/or had encountered by then.
>
> You probably remember that I originally attempted to get PciCapLib and
> its accessories into MdePkg, with an intent to rebase core PCI drivers
> to them -- including PciBusDxe. (The original "sales pitch" can be found
> at
> .)
> I hadn't received either positive or negative feedback regarding that
> idea for a month or so, after which we merged the library into OvmfPkg,
> in the end. (And it is now used by ArmVirtQemu* and OVMF only, as part
> of OvmfPkg/PciHotPlugInitDxe and OvmfPkg/Virtio10Dxe).
>
> I did file a longer-term reminder BZ at
> . But, I gave up on
> that as well in about 4 months.
>
> The upshot is that now I can only contribute piecemeal fixes for
> PciBusDxe, whenever I come across something. This particular issue has
> bitten us at RH twice by now -- unfortunately, both RHBZs are private,
> 

Re: [edk2-devel] [PATCH] OvmfPkg/QemuVideoDxe: Shouldn't assume system in VGA alias mode.

2019-06-05 Thread Laszlo Ersek
On 06/05/19 13:14, Marc W Chen wrote:
> Query the supported attributes firstly, then AND (&&) both
> VGA_IO and VGA_IO_16.

I don't think you mean "logical AND" above.

And if you mean "bitwise AND", then "&&" is incorrect.

> Since the supported attributes should
> only have VGA_IO or VGA_IO_16 set, the result of AND (&&) is
> either VGA_IO or IO_16. Then the result can be passed to
> PciIo->Attributes() to set the attributes.

I don't understand what the problem is.

In fact, do we have two problems? Such as,

(1) We don't consider VGA_IO_16, only VGA_IO. Are you saying that we
should consider both, and (at the same time) make sure that at most one
is set?

(2) We don't check whether VGA_IO* is supported, we just go ahead and
enable them. Are you saying that we should check before we enable?

Furthermore,

(3) did you encounter an practical problem with the current code? If so,
can you describe it in the commit message please? The subject line helps
a little (it implies that using VGA_IO over VGA_IO_16 assumes "VGA alias
mode"), but it should be described in more detail please.

> 
> Signed-off-by: Marc Chen 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Anthony Perard 
> Cc: Julien Grall 
> Cc: Marc-André Lureau 
> Cc: Stefan Berger 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1880
> ---
>  OvmfPkg/QemuVideoDxe/Driver.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
> index e8a613ef33..ba9210f24b 100644
> --- a/OvmfPkg/QemuVideoDxe/Driver.c
> +++ b/OvmfPkg/QemuVideoDxe/Driver.c
> @@ -201,6 +201,7 @@ QemuVideoControllerDriverStart (
>PCI_TYPE00Pci;
>QEMU_VIDEO_CARD   *Card;
>EFI_PCI_IO_PROTOCOL   *ChildPciIo;
> +  UINT64Supports;
>
>OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
>
> @@ -277,13 +278,32 @@ QemuVideoControllerDriverStart (
>  goto ClosePciIo;
>}
>
> +  //
> +  // Get supported PCI attributes
> +  //
> +  Status = Private->PciIo->Attributes (
> +Private->PciIo,
> +EfiPciIoAttributeOperationSupported,
> +0,
> +
> +);

(4) The arguments and the closing parenthesis are incorrectly aligned,
relative to the function designator.


> +  if (EFI_ERROR (Status)) {
> +goto ClosePciIo;
> +  }
> +
> +  Supports &= (UINT64)(EFI_PCI_IO_ATTRIBUTE_VGA_IO | 
> EFI_PCI_IO_ATTRIBUTE_VGA_IO_16);
> +  if ((Supports == 0) || (Supports == (EFI_PCI_IO_ATTRIBUTE_VGA_IO | 
> EFI_PCI_IO_ATTRIBUTE_VGA_IO_16))) {
> +Status = EFI_UNSUPPORTED;
> +goto ClosePciIo;
> +  }
> +

I have two comments on this:

(5) If we need a variable for tracking just these two bits, then it
should be named something more to-the-point than just "Supports". For
example, "SupportedVgaIo" or similar.

(6) I'm not convinced this logic is correct, according to the UEFI spec.
The spec seems to suggest that (VGA_IO | VGA_IO_16) should not be
*enabled* at the same time. However, it doesn't seem to require that a
PciIo protocol instance report at most one of these attributes as
*supported*.

The spec says, near VGA_IO_16, "This bit may not be combined with
EFI_PCI_IO_ATTRIBUTE_VGA_IO [...]". I'm unsure whether this applies to
both EfiPciIoAttributeOperationSupported and
EfiPciIoAttributeOperationEnable.

I think we have two options here:
- if the spec guarantees this exclusion, then we can either drop the
"both set" check, or even ASSERT that it never happens
- if the spec does not guarantee the exclusion, then we should pick
VGA_IO_16 first, and VGA_IO second (in this priority order).

I think the last option is the most robust one.

Thanks,
Laszlo

>//
>// Set new PCI attributes
>//
>Status = Private->PciIo->Attributes (
>  Private->PciIo,
>  EfiPciIoAttributeOperationEnable,
> -EFI_PCI_DEVICE_ENABLE | 
> EFI_PCI_IO_ATTRIBUTE_VGA_MEMORY | EFI_PCI_IO_ATTRIBUTE_VGA_IO,
> +EFI_PCI_DEVICE_ENABLE | 
> EFI_PCI_IO_ATTRIBUTE_VGA_MEMORY | Supports,
>  NULL
>  );
>if (EFI_ERROR (Status)) {
> 


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

View/Reply Online (#41940): https://edk2.groups.io/g/devel/message/41940
Mute This Topic: https://groups.io/mt/31935803/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 0/2] Fix the issue that OS complains memory < 1MB changes across S3

2019-06-05 Thread Laszlo Ersek
On 06/05/19 07:49, Ni, Ray wrote:
> v2:
>   Answer Laszlo's comments:
> 1. Add 1/2 patch to change IA32 waking up vector assembly code to increase
>NumApsExecuting only for ApInitConfig.
> 2. Change 2/2 patch to remove the unnecessary debug messages.
> 
> Ray Ni (2):
>   UefiCpuPkg/MpInitLib: increase NumApsExecuting only for ApInitConfig
>   UefiCpuPkg/MpInitLib: Decrease NumApsExecuting only for ApInitConfig
> 
>  UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm | 14 +++---
>  UefiCpuPkg/Library/MpInitLib/MpLib.c   |  5 +++--
>  2 files changed, 10 insertions(+), 9 deletions(-)
> 

For the series:

Reviewed-by: Laszlo Ersek 
Regression-tested-by: Laszlo Ersek 

Thanks,
Laszlo

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

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



[edk2-devel] [PATCH] OvmfPkg/QemuVideoDxe: Shouldn't assume system in VGA alias mode.

2019-06-05 Thread Marc W Chen
Query the supported attributes firstly, then AND (&&) both
VGA_IO and VGA_IO_16. Since the supported attributes should
only have VGA_IO or VGA_IO_16 set, the result of AND (&&) is
either VGA_IO or IO_16. Then the result can be passed to
PciIo->Attributes() to set the attributes.

Signed-off-by: Marc Chen 
Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Anthony Perard 
Cc: Julien Grall 
Cc: Marc-André Lureau 
Cc: Stefan Berger 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1880
---
 OvmfPkg/QemuVideoDxe/Driver.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index e8a613ef33..ba9210f24b 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -201,6 +201,7 @@ QemuVideoControllerDriverStart (
   PCI_TYPE00Pci;
   QEMU_VIDEO_CARD   *Card;
   EFI_PCI_IO_PROTOCOL   *ChildPciIo;
+  UINT64Supports;
 
   OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
 
@@ -277,13 +278,32 @@ QemuVideoControllerDriverStart (
 goto ClosePciIo;
   }
 
+  //
+  // Get supported PCI attributes
+  //
+  Status = Private->PciIo->Attributes (
+Private->PciIo,
+EfiPciIoAttributeOperationSupported,
+0,
+
+);
+  if (EFI_ERROR (Status)) {
+goto ClosePciIo;
+  }
+
+  Supports &= (UINT64)(EFI_PCI_IO_ATTRIBUTE_VGA_IO | 
EFI_PCI_IO_ATTRIBUTE_VGA_IO_16);
+  if ((Supports == 0) || (Supports == (EFI_PCI_IO_ATTRIBUTE_VGA_IO | 
EFI_PCI_IO_ATTRIBUTE_VGA_IO_16))) {
+Status = EFI_UNSUPPORTED;
+goto ClosePciIo;
+  }
+
   //
   // Set new PCI attributes
   //
   Status = Private->PciIo->Attributes (
 Private->PciIo,
 EfiPciIoAttributeOperationEnable,
-EFI_PCI_DEVICE_ENABLE | 
EFI_PCI_IO_ATTRIBUTE_VGA_MEMORY | EFI_PCI_IO_ATTRIBUTE_VGA_IO,
+EFI_PCI_DEVICE_ENABLE | 
EFI_PCI_IO_ATTRIBUTE_VGA_MEMORY | Supports,
 NULL
 );
   if (EFI_ERROR (Status)) {
-- 
2.16.2.windows.1


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

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



Re: [edk2-devel] [PATCH] CryptoPkg/OpensslLib: fix VS2017 build failure

2019-06-05 Thread Laszlo Ersek
Hi Jian,

On 06/04/19 23:18, Wang, Jian J wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1878
> 
> This issue is specific to VS2017 which tries to resolve symbol referenced
> by a symbol not really referenced eventually.
> 
> ossl_init_load_crypto_strings
> -> err_load_crypto_strings_int (not really referenced)
> -> ERR_load_OSSL_STORE_strings
> 
> Because OPENSSL_NO_ERR and OPENSSL_NO_AUTOERRINIT are not defined by
> default, err_load_crypto_strings_int() will not be actually referenced
> by ossl_init_load_crypto_strings().
> 
> Since err_load_crypto_strings_int() is not actually referenced at all,
> the fix can be done simply by removing crypto/err/err_all.c from build.
> 
> Cc: Dandan Bi 
> Cc: Xiaoyu Lu 
> Signed-off-by: Jian J Wang 
> ---
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf   | 1 -
>  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
> b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> index 378fa6588e..5a2424fc16 100644
> --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> @@ -218,7 +218,6 @@
>$(OPENSSL_PATH)/crypto/dso/dso_win32.c
>$(OPENSSL_PATH)/crypto/ebcdic.c
>$(OPENSSL_PATH)/crypto/err/err.c
> -  $(OPENSSL_PATH)/crypto/err/err_all.c
>$(OPENSSL_PATH)/crypto/err/err_prn.c
>$(OPENSSL_PATH)/crypto/evp/bio_b64.c
>$(OPENSSL_PATH)/crypto/evp/bio_enc.c
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf 
> b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> index 24d3d96459..588da4c040 100644
> --- a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> +++ b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> @@ -218,7 +218,6 @@
>$(OPENSSL_PATH)/crypto/dso/dso_win32.c
>$(OPENSSL_PATH)/crypto/ebcdic.c
>$(OPENSSL_PATH)/crypto/err/err.c
> -  $(OPENSSL_PATH)/crypto/err/err_all.c
>$(OPENSSL_PATH)/crypto/err/err_prn.c
>$(OPENSSL_PATH)/crypto/evp/bio_b64.c
>$(OPENSSL_PATH)/crypto/evp/bio_enc.c
> 

after the edk2-stable201905 tag, we might want to update
"CryptoPkg/Library/OpensslLib/process_files.pl" as well, to exclude this
file. In order to fix the build issue for the stable tag, this patch is
acceptable (I see it's been pushed already, and that's fine); but in the
longer term, we should not manually update the section that's marked as
"Autogenerated files list starts here".

If you agree, can you please file a TianoCore BZ about this? (I.e.
special handling for "err_all.c" in "process_files.pl".)

Thanks
Laszlo

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

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



[edk2-devel] [PATCH] OvmfPkg/QemuVideoDxe: Shouldn't assume system in VGA alias mode.

2019-06-05 Thread Marc W Chen
Query the supported attributes firstly, then AND (&&) both
VGA_IO and VGA_IO_16. Since the supported attributes should
only have VGA_IO or VGA_IO_16 set, the result of AND (&&) is
either VGA_IO or IO_16. Then the result can be passed to
PciIo->Attributes() to set the attributes.

Signed-off-by: Marc Chen 
Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Anthony Perard 
Cc: Julien Grall 
Cc: Marc-André Lureau 
Cc: Stefan Berger 
---
 OvmfPkg/QemuVideoDxe/Driver.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index e8a613ef33..ba9210f24b 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -201,6 +201,7 @@ QemuVideoControllerDriverStart (
   PCI_TYPE00Pci;
   QEMU_VIDEO_CARD   *Card;
   EFI_PCI_IO_PROTOCOL   *ChildPciIo;
+  UINT64Supports;
 
   OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
 
@@ -277,13 +278,32 @@ QemuVideoControllerDriverStart (
 goto ClosePciIo;
   }
 
+  //
+  // Get supported PCI attributes
+  //
+  Status = Private->PciIo->Attributes (
+Private->PciIo,
+EfiPciIoAttributeOperationSupported,
+0,
+
+);
+  if (EFI_ERROR (Status)) {
+goto ClosePciIo;
+  }
+
+  Supports &= (UINT64)(EFI_PCI_IO_ATTRIBUTE_VGA_IO | 
EFI_PCI_IO_ATTRIBUTE_VGA_IO_16);
+  if ((Supports == 0) || (Supports == (EFI_PCI_IO_ATTRIBUTE_VGA_IO | 
EFI_PCI_IO_ATTRIBUTE_VGA_IO_16))) {
+Status = EFI_UNSUPPORTED;
+goto ClosePciIo;
+  }
+
   //
   // Set new PCI attributes
   //
   Status = Private->PciIo->Attributes (
 Private->PciIo,
 EfiPciIoAttributeOperationEnable,
-EFI_PCI_DEVICE_ENABLE | 
EFI_PCI_IO_ATTRIBUTE_VGA_MEMORY | EFI_PCI_IO_ATTRIBUTE_VGA_IO,
+EFI_PCI_DEVICE_ENABLE | 
EFI_PCI_IO_ATTRIBUTE_VGA_MEMORY | Supports,
 NULL
 );
   if (EFI_ERROR (Status)) {
-- 
2.16.2.windows.1


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

View/Reply Online (#41936): https://edk2.groups.io/g/devel/message/41936
Mute This Topic: https://groups.io/mt/31935803/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 0/2] BaseTools: add script to set up git environment

2019-06-05 Thread Bob Feng
Hi Leif,

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers
 is a great resource. It's very useful.

I tested this scripts. I found a minor issue that I have a local edk2 repo 
which was cloned by the command: "git clone https://github.com/tianocore/edk2;  
not "git clone https://github.com/tianocore/edk2.git; and when I run this 
script, it reported "Unknown upstream ".

The script works well if the git url is https://github.com/tianocore/edk2.git

So would you update the script to support the url with or without the ".git" 
suffix?


Thanks,
Bob

-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org] 
Sent: Friday, May 31, 2019 12:00 AM
To: devel@edk2.groups.io
Cc: Feng, Bob C ; Gao, Liming ; 
Zhu, Yonghong ; Andrew Fish ; Laszlo 
Ersek ; Kinney, Michael D 
Subject: [RFC PATCH 0/2] BaseTools: add script to set up git environment

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers
is a great resource, but it's a lot of manual steps to go through for each 
repository (especially as the number seems to grow).

Script works with python2/3 under both Posix and Windows.

Note: the script does require the 'gitpython' module to be installed.
Under Linux, this can be achieved with your distribution package manager.
Under Windows, you can install this from the Visual Studio python 
environment->packages (pypi), and searching for 'gitpython'.

Note2: for simplicity's sake, the script uses a single copy of the 
configuration files for each repository - pointing all of them to the copies in 
edk2 BaseTools.

Note3: we're hardcoding absolute paths here, so if you move repositories 
around, you need to re-run the script.

Note4: all of the settings are done only on a per-repository basis, so as not 
to mess with environments for unlelated projects. This also means many settings 
that are common across all repositories are set in each of them.

Note4: the script identifies repositories based on their 'origin' URL, so if 
someone had a good use-case for something cute, there may be more work required.


Future plans:
It would be useful to also add common git-hook scripts to install.
I already have some for my own maintainer use.

Even though we only modify settings for the current repository, it would also 
make sense to add some sanity checking for global settings (name, email, mail 
server config...).

Leif Lindholm (2):
  BaseTools: add centralized location for git config files
  BaseTools: add script to configure local git options

 BaseTools/Conf/diff.order |   8 ++
 BaseTools/Conf/gitattributes  |  14   BaseTools/Scripts/SetupGit.py | 187 
++
 3 files changed, 209 insertions(+)
 create mode 100644 BaseTools/Conf/diff.order  create mode 100644 
BaseTools/Conf/gitattributes  create mode 100644 BaseTools/Scripts/SetupGit.py

--
2.11.0


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

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



Re: [edk2-devel] [PATCH for-next] MdeModulePkg/PciBusDxe: catch unimplemented extended config space reads

2019-06-05 Thread Laszlo Ersek
On 06/05/19 11:25, Ard Biesheuvel wrote:
> On Tue, 4 Jun 2019 at 23:44, Laszlo Ersek  wrote:
>>
>> When assigning a physical PCIe device to a QEMU/KVM guest, PciBusDxe may
>> find that the extended config space is not (fully) implemented. In
>> LocatePciExpressCapabilityRegBlock(), "CapabilityEntry" may be read as
>> 0x_ at a given config space offset, after which the loop gets
>> stuck spinning on offset 0xFFC (the read at offset 0xFFC returns
>> 0x_ most likely as well).
>>
>> Another scenario (not related to virtualization) for triggering the above
>> is when a Conventional PCI bus -- exposed by a PCIe-to-PCI bridge in the
>> topology -- intervenes between a PCI Express Root Port and a PCI Express
>> Endpoint. The Conventional PCI bus limits the accessible config space of
>> the PCI Express Endpoint, even though the endpoint advertizes the PCI
>> Express capability. Here's a diagram, courtesy of Alex Williamson:
>>
>>   [PCIe Root Port]--[PCIe-to-PCI]--[PCI-to-PCIe]--[PCIe EP]
>>   ->|  |<- Conventional PCI bus
>>
>> Catch reads of 0x_ in LocatePciExpressCapabilityRegBlock(), and
>> break out of the scan with a warning message. The function will return
>> EFI_NOT_FOUND.
>>
>> Cc: Alex Williamson 
>> Cc: Hao A Wu 
>> Cc: Jian J Wang 
>> Cc: Ray Ni 
>> Cc: Star Zeng 
>> Signed-off-by: Laszlo Ersek 
>> ---
>>
>> Notes:
>> Repo:   https://github.com/lersek/edk2.git
>> Branch: pcibus_no_ext_conf
>>
>>  MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c | 13 +
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c 
>> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
>> index 214aeecdd40a..6283d602207c 100644
>> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
>> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
>> @@ -236,6 +236,19 @@ LocatePciExpressCapabilityRegBlock (
>>break;
>>  }
>>
>> +if (CapabilityEntry == MAX_UINT32) {
> 
> Should we check here that the offset > 0x100 ? Otherwise, this affects
> more than just the extended config space.

A separate function exists for locating caps in the conventional config
space (LocateCapabilityRegBlock()).

Whereas the function being patched --
LocatePciExpressCapabilityRegBlock() -- is supposed to start with a
capability offset into the extended config space, passed in by the
caller via *Offset, or else at 0x100 if *Offset is 0.

And, my understanding is that an extended cap shall never chain to a
conventional cap. The spec says,

Next Capability Offset – This field contains the offset to the next
PCI Express Capability structure or 000h if no other items exist in
the linked list of Capabilities.

For Extended Capabilities implemented in Configuration Space, this
offset is relative to the beginning of PCI compatible Configuration
Space and thus must always be either 000h (for terminating list of
Capabilities) or greater than 0FFh.

The bottom 2 bits of this offset are Reserved and must be
implemented as 00b although software must mask them to allow for
future uses of these bits.

Additionally, the capability header is different for conventional
capabilities: EFI_PCI_CAPABILITY_HDR -- 2 bytes -- vs.
PCI_EXPRESS_EXTENDED_CAPABILITIES_HEADER -- 4 bytes. So if this loop
ever crossed over into normal config space, it would break horribly,
regardless of this patch.

A more general question would be how much we should armor such functions
-- i.e., capability list scanning -- with sanity checks.

My answer to that was authoring PciCapLib, which detects loops in cap
lists, oversized capability reads/writes, an absent extended config
space in spite of a present express capability; maybe more. Basically
everything I could think of and/or had encountered by then.

You probably remember that I originally attempted to get PciCapLib and
its accessories into MdePkg, with an intent to rebase core PCI drivers
to them -- including PciBusDxe. (The original "sales pitch" can be found
at
.)
I hadn't received either positive or negative feedback regarding that
idea for a month or so, after which we merged the library into OvmfPkg,
in the end. (And it is now used by ArmVirtQemu* and OVMF only, as part
of OvmfPkg/PciHotPlugInitDxe and OvmfPkg/Virtio10Dxe).

I did file a longer-term reminder BZ at
. But, I gave up on
that as well in about 4 months.

The upshot is that now I can only contribute piecemeal fixes for
PciBusDxe, whenever I come across something. This particular issue has
bitten us at RH twice by now -- unfortunately, both RHBZs are private,
hence I didn't reference them in the commit message. (It's super
annoying if you click a BZ link, just to be rejected access.)

In summary, adding a standalone check for "next" cap offsets that fall
into the forbidden range [1, 255] (inclusive) would be 

Re: [edk2-devel] [PATCH for-next] MdeModulePkg/PciBusDxe: catch unimplemented extended config space reads

2019-06-05 Thread Ard Biesheuvel
On Tue, 4 Jun 2019 at 23:44, Laszlo Ersek  wrote:
>
> When assigning a physical PCIe device to a QEMU/KVM guest, PciBusDxe may
> find that the extended config space is not (fully) implemented. In
> LocatePciExpressCapabilityRegBlock(), "CapabilityEntry" may be read as
> 0x_ at a given config space offset, after which the loop gets
> stuck spinning on offset 0xFFC (the read at offset 0xFFC returns
> 0x_ most likely as well).
>
> Another scenario (not related to virtualization) for triggering the above
> is when a Conventional PCI bus -- exposed by a PCIe-to-PCI bridge in the
> topology -- intervenes between a PCI Express Root Port and a PCI Express
> Endpoint. The Conventional PCI bus limits the accessible config space of
> the PCI Express Endpoint, even though the endpoint advertizes the PCI
> Express capability. Here's a diagram, courtesy of Alex Williamson:
>
>   [PCIe Root Port]--[PCIe-to-PCI]--[PCI-to-PCIe]--[PCIe EP]
>   ->|  |<- Conventional PCI bus
>
> Catch reads of 0x_ in LocatePciExpressCapabilityRegBlock(), and
> break out of the scan with a warning message. The function will return
> EFI_NOT_FOUND.
>
> Cc: Alex Williamson 
> Cc: Hao A Wu 
> Cc: Jian J Wang 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Signed-off-by: Laszlo Ersek 
> ---
>
> Notes:
> Repo:   https://github.com/lersek/edk2.git
> Branch: pcibus_no_ext_conf
>
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> index 214aeecdd40a..6283d602207c 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> @@ -236,6 +236,19 @@ LocatePciExpressCapabilityRegBlock (
>break;
>  }
>
> +if (CapabilityEntry == MAX_UINT32) {

Should we check here that the offset > 0x100 ? Otherwise, this affects
more than just the extended config space.

> +  DEBUG ((
> +DEBUG_WARN,
> +"%a: [%02x|%02x|%02x] failed to access config space at offset 
> 0x%x\n",
> +__FUNCTION__,
> +PciIoDevice->BusNumber,
> +PciIoDevice->DeviceNumber,
> +PciIoDevice->FunctionNumber,
> +CapabilityPtr
> +));
> +  break;
> +}
> +
>  CapabilityID = (UINT16) CapabilityEntry;
>
>  if (CapabilityID == CapId) {
> --
> 2.19.1.3.g30247aa5d201
>
>
> 
> Groups.io Links: You receive all messages sent to this group.
>
> View/Reply Online (#41893): https://edk2.groups.io/g/devel/message/41893
> Mute This Topic: https://groups.io/mt/31931246/1761188
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub  [ard.biesheu...@linaro.org]
> 
>

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

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



Re: [edk2-devel] [PATCH for-next] MdeModulePkg/PciBusDxe: catch unimplemented extended config space reads

2019-06-05 Thread Philippe Mathieu-Daudé
On 6/4/19 11:44 PM, Laszlo Ersek wrote:
> When assigning a physical PCIe device to a QEMU/KVM guest, PciBusDxe may
> find that the extended config space is not (fully) implemented. In
> LocatePciExpressCapabilityRegBlock(), "CapabilityEntry" may be read as
> 0x_ at a given config space offset, after which the loop gets
> stuck spinning on offset 0xFFC (the read at offset 0xFFC returns
> 0x_ most likely as well).
> 
> Another scenario (not related to virtualization) for triggering the above
> is when a Conventional PCI bus -- exposed by a PCIe-to-PCI bridge in the
> topology -- intervenes between a PCI Express Root Port and a PCI Express
> Endpoint. The Conventional PCI bus limits the accessible config space of
> the PCI Express Endpoint, even though the endpoint advertizes the PCI
> Express capability. Here's a diagram, courtesy of Alex Williamson:
> 
>   [PCIe Root Port]--[PCIe-to-PCI]--[PCI-to-PCIe]--[PCIe EP]
>   ->|  |<- Conventional PCI bus
> 
> Catch reads of 0x_ in LocatePciExpressCapabilityRegBlock(), and
> break out of the scan with a warning message. The function will return
> EFI_NOT_FOUND.
> 
> Cc: Alex Williamson 
> Cc: Hao A Wu 
> Cc: Jian J Wang 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> Repo:   https://github.com/lersek/edk2.git
> Branch: pcibus_no_ext_conf
> 
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> index 214aeecdd40a..6283d602207c 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> @@ -236,6 +236,19 @@ LocatePciExpressCapabilityRegBlock (
>break;
>  }
>  
> +if (CapabilityEntry == MAX_UINT32) {
> +  DEBUG ((
> +DEBUG_WARN,
> +"%a: [%02x|%02x|%02x] failed to access config space at offset 
> 0x%x\n",
> +__FUNCTION__,
> +PciIoDevice->BusNumber,
> +PciIoDevice->DeviceNumber,
> +PciIoDevice->FunctionNumber,
> +CapabilityPtr
> +));
> +  break;
> +}
> +
>  CapabilityID = (UINT16) CapabilityEntry;
>  
>  if (CapabilityID == CapId) {
> 

Reviewed-by: Philippe Mathieu-Daude 

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

View/Reply Online (#41932): https://edk2.groups.io/g/devel/message/41932
Mute This Topic: https://groups.io/mt/31931246/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] edk2: Update additional licenses in Readme.md

2019-06-05 Thread Philippe Mathieu-Daudé
On 6/5/19 3:15 AM, Michael D Kinney wrote:
> Update the list of additional licenses in Readme.md.  For additional
> licenses from a git submodule, provide a link to the license file
> in the remote git repository.  This makes the links in Readme.md
> when viewed from the edk2 repository GitHub landing page
> https://github.com/tianocore/edk2/ functional from a web browser.
> 
> * Remove references EdkCompatibilityPkg
> * Update link to OpenSSL to license file in the git submodule link
>   to https://github.com/openssl/openssl
> * Add link to license file in the git submodule like to
>   https://github.com/ucb-bar/berkeley-softfloat-3 for
>   ArmSoftFloatLib
> 
> Signed-off-by: Michael D Kinney 
> Reviewed-by: Laszlo Ersek 
> ---
>  Readme.md | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Readme.md b/Readme.md
> index 1feba16075..e564c6c09b 100644
> --- a/Readme.md
> +++ b/Readme.md
> @@ -12,10 +12,10 @@ contains the following components that are covered by 
> additional licenses:
>  * 
> [MdeModulePkg/Library/LzmaCustomDecompressLib](MdeModulePkg/Library/LzmaCustomDecompressLib/LZMA-SDK-README.txt)
>  * 
> [IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/Sdk](IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LZMA-SDK-README.txt)
>  * 
> [BaseTools/Source/C/VfrCompile/Pccts](BaseTools/Source/C/VfrCompile/Pccts/RIGHTS)
> -* 
> [EdkCompatibilityPkg/Other/Maintained/Tools/Pccts](EdkCompatibilityPkg/Other/Maintained/Tools/Pccts/README)
>  * 
> [MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma](MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/README)
>  * [OvmfPkg](OvmfPkg/License.txt)
> -* 
> [CryptoPkg/Library/OpensslLib/openssl](CryptoPkg/Library/OpensslLib/openssl/LICENSE)
> +* 
> [CryptoPkg/Library/OpensslLib/openssl](https://github.com/openssl/openssl/blob/50eaac9f3337667259de725451f201e784599687/LICENSE)
> +* 
> [ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3](https://github.com/ucb-bar/berkeley-softfloat-3/blob/b64af41c3276f97f0e181920400ee056b9c88037/COPYING.txt)
>  
>  The EDK II Project is composed of packages.  The maintainers for each package
>  are listed in [Maintainers.txt](Maintainers.txt).
> 

Reviewed-by: Philippe Mathieu-Daude 

This patch seems worthwhile its inclusion for the 201905 stable release.

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

View/Reply Online (#41931): https://edk2.groups.io/g/devel/message/41931
Mute This Topic: https://groups.io/mt/31932893/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: Remove Yonghong from BaseTools Reviewer

2019-06-05 Thread Bob Feng
Reviewed-by: Bob Feng  

-Original Message-
From: Zhu, Yonghong 
Sent: Wednesday, June 5, 2019 8:51 AM
To: devel@edk2.groups.io
Cc: Feng, Bob C ; Gao, Liming 
Subject: [Patch] Maintainers.txt: Remove Yonghong from BaseTools Reviewer

As Yonghong has some other focus, remove him from the reviewer.

Cc: Bob Feng 
Cc: Liming Gao 
Signed-off-by: Yonghong Zhu 
---
 Maintainers.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt index 010ec31..b41bd59 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -82,11 +82,10 @@ R: Julien Grall 
 
 BaseTools
 W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
 M: Bob Feng 
 M: Liming Gao 
-R: Yonghong Zhu 
 
 CryptoPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/CryptoPkg
 M: Jian Wang 
 R: Ting Ye 
--
2.6.1.windows.1


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

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



Re: [edk2-devel] [PATCH] CryptoPkg/OpensslLib: fix VS2017 build failure

2019-06-05 Thread Liming Gao
Push @0a1b13fd4d2210e2c379ace4fd961fb80126b7e9

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Liming 
> Gao
> Sent: Wednesday, June 5, 2019 8:23 AM
> To: devel@edk2.groups.io; Wang, Jian J 
> Cc: Bi, Dandan ; Lu, XiaoyuX 
> Subject: Re: [edk2-devel] [PATCH] CryptoPkg/OpensslLib: fix VS2017 build 
> failure
> 
> Reviewed-by: Liming Gao 
> 
> >-Original Message-
> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> >Wang, Jian J
> >Sent: Wednesday, June 05, 2019 5:19 AM
> >To: devel@edk2.groups.io
> >Cc: Bi, Dandan ; Lu, XiaoyuX 
> >Subject: [edk2-devel] [PATCH] CryptoPkg/OpensslLib: fix VS2017 build failure
> >
> >BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1878
> >
> >This issue is specific to VS2017 which tries to resolve symbol referenced
> >by a symbol not really referenced eventually.
> >
> >ossl_init_load_crypto_strings
> >-> err_load_crypto_strings_int (not really referenced)
> >-> ERR_load_OSSL_STORE_strings
> >
> >Because OPENSSL_NO_ERR and OPENSSL_NO_AUTOERRINIT are not defined
> >by
> >default, err_load_crypto_strings_int() will not be actually referenced
> >by ossl_init_load_crypto_strings().
> >
> >Since err_load_crypto_strings_int() is not actually referenced at all,
> >the fix can be done simply by removing crypto/err/err_all.c from build.
> >
> >Cc: Dandan Bi 
> >Cc: Xiaoyu Lu 
> >Signed-off-by: Jian J Wang 
> >---
> > CryptoPkg/Library/OpensslLib/OpensslLib.inf   | 1 -
> > CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf | 1 -
> > 2 files changed, 2 deletions(-)
> >
> >diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> >b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> >index 378fa6588e..5a2424fc16 100644
> >--- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> >+++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> >@@ -218,7 +218,6 @@
> >   $(OPENSSL_PATH)/crypto/dso/dso_win32.c
> >   $(OPENSSL_PATH)/crypto/ebcdic.c
> >   $(OPENSSL_PATH)/crypto/err/err.c
> >-  $(OPENSSL_PATH)/crypto/err/err_all.c
> >   $(OPENSSL_PATH)/crypto/err/err_prn.c
> >   $(OPENSSL_PATH)/crypto/evp/bio_b64.c
> >   $(OPENSSL_PATH)/crypto/evp/bio_enc.c
> >diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> >b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> >index 24d3d96459..588da4c040 100644
> >--- a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> >+++ b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> >@@ -218,7 +218,6 @@
> >   $(OPENSSL_PATH)/crypto/dso/dso_win32.c
> >   $(OPENSSL_PATH)/crypto/ebcdic.c
> >   $(OPENSSL_PATH)/crypto/err/err.c
> >-  $(OPENSSL_PATH)/crypto/err/err_all.c
> >   $(OPENSSL_PATH)/crypto/err/err_prn.c
> >   $(OPENSSL_PATH)/crypto/evp/bio_b64.c
> >   $(OPENSSL_PATH)/crypto/evp/bio_enc.c
> >--
> >2.17.1.windows.2
> >
> >
> >
> 
> 
> 


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

View/Reply Online (#41929): https://edk2.groups.io/g/devel/message/41929
Mute This Topic: https://groups.io/mt/31930984/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: Remove Network maintainers for MdeModulePkg/Universal/Network

2019-06-05 Thread Liming Gao
Push @cbfdc1b2df65dee011cf33add1dff88de3d9c46d

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, June 5, 2019 12:56 AM
> To: Leif Lindholm ; Gao, Liming 
> 
> Cc: devel@edk2.groups.io; Andrew Fish ; Kinney, Michael D 
> 
> Subject: Re: [Patch] Maintainers.txt: Remove Network maintainers for 
> MdeModulePkg/Universal/Network
> 
> On 06/04/19 16:35, Leif Lindholm wrote:
> > On Tue, Jun 04, 2019 at 10:10:59PM +0800, Liming Gao wrote:
> >> MdeModulePkg/Universal/Network has been moved to NetworkPkg. So,
> >> MdeModulePkg/Universal/Network can be removed in Maintainers.txt.
> >>
> >> Signed-off-by: Liming Gao 
> >> Cc: Andrew Fish 
> >> Cc: Laszlo Ersek 
> >> Cc: Leif Lindholm 
> >> Cc: Michael D Kinney 
> >> ---
> >> Because MdeModulePkg/Universal/Network has been moved to NetworkPkg,
> >> I suggest to fix Maintainers.txt for 201905 stable tag.
> >
> > I agree. Since
> > 1) it is not a code fix
> > and
> > 2) it corrects the maintainership state at the time of the stable tag
> >
> > Reviewed-by: Leif Lindholm 
> 
> Reviewed-by: Laszlo Ersek 
> 
> Thanks!
> Laszlo
> 
> >>  Maintainers.txt | 2 --
> >>  1 file changed, 2 deletions(-)
> >>
> >> diff --git a/Maintainers.txt b/Maintainers.txt
> >> index 010ec31404..3bab8a2db4 100644
> >> --- a/Maintainers.txt
> >> +++ b/Maintainers.txt
> >> @@ -161,8 +161,6 @@ MdeModulePkg
> >>  W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> >>  M: Jian J Wang 
> >>  M: Hao A Wu 
> >> -M: NetworkPkg maintainers
> >> -  (Universal/Network and related libraries, header files)
> >>  R: Ray Ni 
> >>(especially for Bus, Universal/Console, Universal/Disk,
> >> Universal/BdsDxe and related libraries, header files)
> >> --
> >> 2.13.0.windows.1
> >>


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

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



Re: [edk2-devel] Help needed in building UEFI qcow2 images

2019-06-05 Thread Gerd Hoffmann
  Hi,

> However: you're using a systemd-related UEFI boot loader, and I have
> no clue whether it implements the above-referenced "fallback"
> behavior. For now, I would suggest trying the shim+grub2 variant, and
> even Fedora 29 rather than Fedora 28:
> "fedora-29-efi-grub2-x86_64.qcow2.xz".

I can boot the images just fine with empty vars.

Just noticed that the systemd image has a lowercase efi directory, so
the fallback bootloader path is "efi/BOOT/BOOTX64.EFI" not
"EFI/BOOT/BOOTX64.EFI".  Possibly that is the root cause for the
problem.  In theory it should not, FAT is case-insensitive after all,
but who knows ...

> ... I guess it's also possible that the UEFI boot loader in the disk
> image that you've tried isn't properly signed, against the
> certificates enrolled in "/usr/share/OVMF/OVMF_VARS.secboot.fd". If
> that's the case, the OVMF debug log will show it.

Oh, in secure boot mode.  The systemd images don't use shim, so that
most likely isn't going to fly due to bootloader being unsigned.  The
grub2 variants should work.  Never actually tested that though.  

cheers,
  Gerd


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

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



Re: [edk2-devel] [PATCH for-edk2-stable201905] Revert "EmulatorPkg: don't display the cpu current speed"

2019-06-05 Thread Laszlo Ersek
On 06/05/19 02:23, Liming Gao wrote:
> Reviewed-by: Liming Gao 

Thanks, patch pushed as commit be689ecc93e5.

Laszlo

>> -Original Message-
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Laszlo Ersek
>> Sent: Wednesday, June 05, 2019 2:59 AM
>> To: edk2-devel-groups-io 
>> Cc: Ard Biesheuvel ; Wu, Hao A
>> ; Wang, Jian J ; Gao, Liming
>> ; Ni, Ray ; Zeng, Star
>> 
>> Subject: [edk2-devel] [PATCH for-edk2-stable201905] Revert "EmulatorPkg:
>> don't display the cpu current speed"
>>
>> This reverts commit 7cea4d71a8a87a93924a07ab32348332f5881ef9.
>>
>> Said commit was not suitable for pushing during the edk2-stable201905 hard
>> feature freeze; it was pushed only by mistake. The subject line referenced
>> EmulatorPkg, but the patch changed MdeModulePkg/UiApp, regressing the
>> display of the CPU speed from SMBIOS in multiple platforms.
>>
>> Cc: Ard Biesheuvel 
>> Cc: Hao A Wu 
>> Cc: Jian J Wang 
>> Cc: Liming Gao 
>> Cc: Ray Ni 
>> Cc: Star Zeng 
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1877
>> Signed-off-by: Laszlo Ersek 
>> ---
>>
>> Notes:
>>Repo:   https://github.com/lersek/edk2.git
>>Branch: revert_cpu_speed_hide
>>
>> MdeModulePkg/Application/UiApp/FrontPage.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/MdeModulePkg/Application/UiApp/FrontPage.c
>> b/MdeModulePkg/Application/UiApp/FrontPage.c
>> index fded7634062a..4b95cccb5cf5 100644
>> --- a/MdeModulePkg/Application/UiApp/FrontPage.c
>> +++ b/MdeModulePkg/Application/UiApp/FrontPage.c
>> @@ -621,6 +621,11 @@ UpdateFrontPageBannerStrings (
>> HiiSetString (gFrontPagePrivate.HiiHandle, STRING_TOKEN
>> (STR_FRONT_PAGE_CPU_MODEL), NewString, NULL);
>> FreePool (NewString);
>>
>> +ConvertProcessorToString(Type4Record->CurrentSpeed, 6, );
>> +UiCustomizeFrontPageBanner (2, FALSE, );
>> +HiiSetString (gFrontPagePrivate.HiiHandle, STRING_TOKEN
>> (STR_FRONT_PAGE_CPU_SPEED), NewString, NULL);
>> +FreePool (NewString);
>> +
>> FoundCpu = TRUE;
>>   }
>> }
>> --
>> 2.19.1.3.g30247aa5d201
>>
>>
>> -=-=-=-=-=-=
>> Groups.io Links: You receive all messages sent to this group.
>>
>> View/Reply Online (#41886): https://edk2.groups.io/g/devel/message/41886
>> Mute This Topic: https://groups.io/mt/31929712/1759384
>> Group Owner: devel+ow...@edk2.groups.io
>> Unsubscribe: https://edk2.groups.io/g/devel/unsub  [liming@intel.com]
>> -=-=-=-=-=-=
> 
> 
> 
> 


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

View/Reply Online (#41926): https://edk2.groups.io/g/devel/message/41926
Mute This Topic: https://groups.io/mt/31929712/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] EmulatorPkg: don't diaplay the cpu current speed

2019-06-05 Thread Laszlo Ersek
On 06/05/19 03:10, Ni, Ray wrote:
> Hi everyone,
> 
> Hao pushed the patch because:
> 1. it's a bug fix
> 2. it got a R-b.
> I don't think it's his fault.
> 
> For #1, it's gap in process.
> For #2, it's my fault. Because even the patch title says EmulatorPkg but the 
> patch itself changes MdeModulePkg, I am still the person who can approve 
> changes in both packages.
> 
> In Maintainers.txt:
> R: Ray Ni 
>   (especially for Bus, Universal/Console, Universal/Disk,
>Universal/BdsDxe and related libraries, header files)
> 
> The UiApp actually is not in the "especially" part, but the word "especially"
> means I can also R-b to other components. In fact, I am not quite qualified on
> the other components, e.g.: UiApp.
> So I propose to assign clear reviewers for each components in MdeModulePkg.
> What do you think?

Fully agreed. MdeModulePkg is huge and we should have fine-grained
maintainership assignments.

Thanks
Laszlo

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

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



Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem

2019-06-05 Thread Liming Gao
That good enough. Reviewed-by: Liming Gao 

Thanks
Liming
> -Original Message-
> From: Lu, XiaoyuX
> Sent: Wednesday, June 5, 2019 3:51 PM
> To: Gao, Liming ; devel@edk2.groups.io
> Cc: Bi, Dandan ; Wang, Jian J 
> Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 
> IA32 build problem
> 
> Yes I verify them.
> 
> build -p OvmfPkg/OvmfPkgX64.dsc -a X64 -t CLANG38
> and
> build -p OvmfPkg/OvmfPkgIA32.dsc -a IA32 -t CLANG38
> 
> with qemu-system-x86_64
> 
> > -Original Message-
> > From: Gao, Liming
> > Sent: Wednesday, June 5, 2019 3:37 PM
> > To: Lu, XiaoyuX ; devel@edk2.groups.io
> > Cc: Bi, Dandan ; Wang, Jian J 
> > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > CLANG38 IA32 build problem
> >
> > Do you cover IA32 & X64 arch both, and verify Ovmf boot?
> >
> > > -Original Message-
> > > From: Lu, XiaoyuX
> > > Sent: Wednesday, June 5, 2019 3:35 PM
> > > To: Gao, Liming ; devel@edk2.groups.io
> > > Cc: Bi, Dandan ; Wang, Jian J
> > 
> > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > CLANG38 IA32 build problem
> > >
> > > Liming,
> > >
> > > > -Original Message-
> > > > From: Gao, Liming
> > > > Sent: Wednesday, June 5, 2019 3:28 PM
> > > > To: Lu, XiaoyuX ; devel@edk2.groups.io
> > > > Cc: Bi, Dandan ; Wang, Jian J
> > 
> > > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > > CLANG38 IA32 build problem
> > > >
> > > > Xiaoyu:
> > > >
> > > > > -Original Message-
> > > > > From: Lu, XiaoyuX
> > > > > Sent: Wednesday, June 5, 2019 2:34 PM
> > > > > To: Gao, Liming ; devel@edk2.groups.io
> > > > > Cc: Bi, Dandan ; Wang, Jian J
> > > > 
> > > > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > > CLANG38 IA32 build problem
> > > > >
> > > > > Hi Liming,
> > > > >
> > > > > > -Original Message-
> > > > > > From: Gao, Liming
> > > > > > Sent: Wednesday, June 5, 2019 1:57 PM
> > > > > > To: devel@edk2.groups.io; Lu, XiaoyuX 
> > > > > > Cc: Bi, Dandan ; Wang, Jian J
> > > > 
> > > > > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > > > > CLANG38 IA32 build problem
> > > > > >
> > > > > > Xiaoyu:
> > > > > >
> > > > > > >-Original Message-
> > > > > > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> > Behalf
> > > > Of
> > > > > > >Xiaoyu Lu
> > > > > > >Sent: Wednesday, June 05, 2019 1:25 PM
> > > > > > >To: devel@edk2.groups.io
> > > > > > >Cc: Lu, XiaoyuX ; Bi, Dandan
> > > > > > ;
> > > > > > >Wang, Jian J 
> > > > > > >Subject: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > > CLANG38
> > > > > > >IA32 build problem
> > > > > > >
> > > > > > >When use clang-3.8 to build the NetworkPkg, compiler optimization
> > > > > > >may use memcpy for memory copy. For example:
> > > > > > >
> > > > > > > CryptoPkg/Library/OpensslLib/openssl/ssl/ssl_rsa.c:918: undefined
> > > > > > > reference to `memcpy'`
> > > > > > >
> > > > > > >Compiler optimization is sophisticated, but we can work around it
> > > > > > >use __attribute__((__used__)) to informs the compiler that symbol
> > > > > > >should be retained in the object file, even if it may be
> > > > > > >unreferenced.
> > > > > > >
> > > > > > >Cc: Jian J Wang 
> > > > > > >Cc: Dandan Bi 
> > > > > > >Signed-off-by: Xiaoyu Lu 
> > > > > > >---
> > > > > > > CryptoPkg/Library/IntrinsicLib/CopyMem.c | 13 +
> > > > > > > 1 file changed, 13 insertions(+)
> > > > > > >
> > > > > > >diff --git a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > > > >b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > > > >index e29b4918d200..7faf5a34d8c1 100644
> > > > > > >--- a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > > > >+++ b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > > > >@@ -10,8 +10,21 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > > > > > #include 
> > > > > > > #include 
> > > > > > >
> > > > > > >+#if defined(__clang__) && !defined(__APPLE__)
> > > > > >
> > > > > > So, this change is only for CLANG tool chain.
> > > > > >
> > > > > > >+
> > > > > > >+/* Copies bytes between buffers */
> > > > > > >+static __attribute__((__used__))
> > > > > >
> > > > > > What purpose for static?
> > > > > >
> > > > >
> > > > > Because I want __memcpy only use in this file scope.
> > > > >
> > > > > > >+void * __memcpy (void *dest, const void *src, unsigned int count)
> > > > > > >+{
> > > > > > >+  return CopyMem (dest, src, (UINTN)count);
> > > > > > >+}
> > > > > > >+__attribute__((__alias__("__memcpy")))
> > > > > > >+void * memcpy (void *dest, const void *src, unsigned int count);
> > > > > >
> > > > > > __memcpy is IA32 Intrinsic API, memcpy is X64 Intrinsic API, right?
> > > > > >
> > > > >
> > > > > __memcpy isn't IA32 Intrinsic API, only memcpy is intrinsic API for
> > both
> > > > IA32 and X64.
> > > > >
> > > > > The reason I alias memcpy and use __attribute__((__used__)) is let
> > > > compiler retain symbol in 

Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem

2019-06-05 Thread Xiaoyu Lu
Yes I verify them.

build -p OvmfPkg/OvmfPkgX64.dsc -a X64 -t CLANG38
and
build -p OvmfPkg/OvmfPkgIA32.dsc -a IA32 -t CLANG38

with qemu-system-x86_64

> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, June 5, 2019 3:37 PM
> To: Lu, XiaoyuX ; devel@edk2.groups.io
> Cc: Bi, Dandan ; Wang, Jian J 
> Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> CLANG38 IA32 build problem
> 
> Do you cover IA32 & X64 arch both, and verify Ovmf boot?
> 
> > -Original Message-
> > From: Lu, XiaoyuX
> > Sent: Wednesday, June 5, 2019 3:35 PM
> > To: Gao, Liming ; devel@edk2.groups.io
> > Cc: Bi, Dandan ; Wang, Jian J
> 
> > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> CLANG38 IA32 build problem
> >
> > Liming,
> >
> > > -Original Message-
> > > From: Gao, Liming
> > > Sent: Wednesday, June 5, 2019 3:28 PM
> > > To: Lu, XiaoyuX ; devel@edk2.groups.io
> > > Cc: Bi, Dandan ; Wang, Jian J
> 
> > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > CLANG38 IA32 build problem
> > >
> > > Xiaoyu:
> > >
> > > > -Original Message-
> > > > From: Lu, XiaoyuX
> > > > Sent: Wednesday, June 5, 2019 2:34 PM
> > > > To: Gao, Liming ; devel@edk2.groups.io
> > > > Cc: Bi, Dandan ; Wang, Jian J
> > > 
> > > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > CLANG38 IA32 build problem
> > > >
> > > > Hi Liming,
> > > >
> > > > > -Original Message-
> > > > > From: Gao, Liming
> > > > > Sent: Wednesday, June 5, 2019 1:57 PM
> > > > > To: devel@edk2.groups.io; Lu, XiaoyuX 
> > > > > Cc: Bi, Dandan ; Wang, Jian J
> > > 
> > > > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > > > CLANG38 IA32 build problem
> > > > >
> > > > > Xiaoyu:
> > > > >
> > > > > >-Original Message-
> > > > > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> Behalf
> > > Of
> > > > > >Xiaoyu Lu
> > > > > >Sent: Wednesday, June 05, 2019 1:25 PM
> > > > > >To: devel@edk2.groups.io
> > > > > >Cc: Lu, XiaoyuX ; Bi, Dandan
> > > > > ;
> > > > > >Wang, Jian J 
> > > > > >Subject: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > CLANG38
> > > > > >IA32 build problem
> > > > > >
> > > > > >When use clang-3.8 to build the NetworkPkg, compiler optimization
> > > > > >may use memcpy for memory copy. For example:
> > > > > >
> > > > > > CryptoPkg/Library/OpensslLib/openssl/ssl/ssl_rsa.c:918: undefined
> > > > > > reference to `memcpy'`
> > > > > >
> > > > > >Compiler optimization is sophisticated, but we can work around it
> > > > > >use __attribute__((__used__)) to informs the compiler that symbol
> > > > > >should be retained in the object file, even if it may be
> > > > > >unreferenced.
> > > > > >
> > > > > >Cc: Jian J Wang 
> > > > > >Cc: Dandan Bi 
> > > > > >Signed-off-by: Xiaoyu Lu 
> > > > > >---
> > > > > > CryptoPkg/Library/IntrinsicLib/CopyMem.c | 13 +
> > > > > > 1 file changed, 13 insertions(+)
> > > > > >
> > > > > >diff --git a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > > >b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > > >index e29b4918d200..7faf5a34d8c1 100644
> > > > > >--- a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > > >+++ b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > > >@@ -10,8 +10,21 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > > > > #include 
> > > > > > #include 
> > > > > >
> > > > > >+#if defined(__clang__) && !defined(__APPLE__)
> > > > >
> > > > > So, this change is only for CLANG tool chain.
> > > > >
> > > > > >+
> > > > > >+/* Copies bytes between buffers */
> > > > > >+static __attribute__((__used__))
> > > > >
> > > > > What purpose for static?
> > > > >
> > > >
> > > > Because I want __memcpy only use in this file scope.
> > > >
> > > > > >+void * __memcpy (void *dest, const void *src, unsigned int count)
> > > > > >+{
> > > > > >+  return CopyMem (dest, src, (UINTN)count);
> > > > > >+}
> > > > > >+__attribute__((__alias__("__memcpy")))
> > > > > >+void * memcpy (void *dest, const void *src, unsigned int count);
> > > > >
> > > > > __memcpy is IA32 Intrinsic API, memcpy is X64 Intrinsic API, right?
> > > > >
> > > >
> > > > __memcpy isn't IA32 Intrinsic API, only memcpy is intrinsic API for
> both
> > > IA32 and X64.
> > > >
> > > > The reason I alias memcpy and use __attribute__((__used__)) is let
> > > compiler retain symbol in object file,
> > > > So it can link correct.
> > > >
> > > > Is this correct?
> > > >
> > >
> > > Make sense. What test have been done by you? Build pass and Boot
> pass?
> > >
> >
> > Build pass and BaseCryptLib functions test pass.
> > I don't test http boot.
> >
> > Thanks,
> > Xiaoyu
> >
> > > > > Thanks
> > > > > Liming
> > > >
> > > > > >+
> > > > > >+#else
> > > > > > /* Copies bytes between buffers */
> > > > > > void * memcpy (void *dest, const void *src, unsigned int count)
> > > > > > {
> > > > > >   return CopyMem (dest, src, (UINTN)count);
> > > > > > }
> > > > > 

[edk2-devel] [PATCH for-edk2-stable201905] Revert "UefiPayloadPkg: Remove legacy PIC 8259 driver"

2019-06-05 Thread Liming Gao
This reverts commit a1539c46958fb896dee8f7987f4a98e9f9d10796.
This change will be pushed after edk2-stable201905

Cc: Maurice Ma 
Cc: Guo Dong 
Cc: Benjamin You 
Signed-off-by: Liming Gao 
---
 UefiPayloadPkg/UefiPayloadPkg.fdf| 1 +
 UefiPayloadPkg/UefiPayloadPkgIa32.dsc| 1 +
 UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc | 1 +
 3 files changed, 3 insertions(+)

diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf 
b/UefiPayloadPkg/UefiPayloadPkg.fdf
index 4cd88a3f85..ce3b34999b 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.fdf
+++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
@@ -104,6 +104,7 @@ INF 
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
 INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
 INF MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
+INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
 INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
 INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
 INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc 
b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
index 11cf17ca06..5b6ed36e9c 100644
--- a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
@@ -432,6 +432,7 @@
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
+  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc 
b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
index 5b7994a62c..d57b5241dc 100644
--- a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
@@ -433,6 +433,7 @@
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
+  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
-- 
2.13.0.windows.1


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

View/Reply Online (#41921): https://edk2.groups.io/g/devel/message/41921
Mute This Topic: https://groups.io/mt/31934954/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] edk2: Update additional licenses in Readme.md

2019-06-05 Thread Ard Biesheuvel
On Wed, 5 Jun 2019 at 03:15, Michael D Kinney
 wrote:
>
> Update the list of additional licenses in Readme.md.  For additional
> licenses from a git submodule, provide a link to the license file
> in the remote git repository.  This makes the links in Readme.md
> when viewed from the edk2 repository GitHub landing page
> https://github.com/tianocore/edk2/ functional from a web browser.
>
> * Remove references EdkCompatibilityPkg
> * Update link to OpenSSL to license file in the git submodule link
>   to https://github.com/openssl/openssl
> * Add link to license file in the git submodule like to
>   https://github.com/ucb-bar/berkeley-softfloat-3 for
>   ArmSoftFloatLib
>
> Signed-off-by: Michael D Kinney 
> Reviewed-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>  Readme.md | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Readme.md b/Readme.md
> index 1feba16075..e564c6c09b 100644
> --- a/Readme.md
> +++ b/Readme.md
> @@ -12,10 +12,10 @@ contains the following components that are covered by 
> additional licenses:
>  * 
> [MdeModulePkg/Library/LzmaCustomDecompressLib](MdeModulePkg/Library/LzmaCustomDecompressLib/LZMA-SDK-README.txt)
>  * 
> [IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/Sdk](IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LZMA-SDK-README.txt)
>  * 
> [BaseTools/Source/C/VfrCompile/Pccts](BaseTools/Source/C/VfrCompile/Pccts/RIGHTS)
> -* 
> [EdkCompatibilityPkg/Other/Maintained/Tools/Pccts](EdkCompatibilityPkg/Other/Maintained/Tools/Pccts/README)
>  * 
> [MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma](MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/README)
>  * [OvmfPkg](OvmfPkg/License.txt)
> -* 
> [CryptoPkg/Library/OpensslLib/openssl](CryptoPkg/Library/OpensslLib/openssl/LICENSE)
> +* 
> [CryptoPkg/Library/OpensslLib/openssl](https://github.com/openssl/openssl/blob/50eaac9f3337667259de725451f201e784599687/LICENSE)
> +* 
> [ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3](https://github.com/ucb-bar/berkeley-softfloat-3/blob/b64af41c3276f97f0e181920400ee056b9c88037/COPYING.txt)
>
>  The EDK II Project is composed of packages.  The maintainers for each package
>  are listed in [Maintainers.txt](Maintainers.txt).
> --
> 2.21.0.windows.1
>
>
> 
>

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

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



Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem

2019-06-05 Thread Liming Gao
Do you cover IA32 & X64 arch both, and verify Ovmf boot?

> -Original Message-
> From: Lu, XiaoyuX
> Sent: Wednesday, June 5, 2019 3:35 PM
> To: Gao, Liming ; devel@edk2.groups.io
> Cc: Bi, Dandan ; Wang, Jian J 
> Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 
> IA32 build problem
> 
> Liming,
> 
> > -Original Message-
> > From: Gao, Liming
> > Sent: Wednesday, June 5, 2019 3:28 PM
> > To: Lu, XiaoyuX ; devel@edk2.groups.io
> > Cc: Bi, Dandan ; Wang, Jian J 
> > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > CLANG38 IA32 build problem
> >
> > Xiaoyu:
> >
> > > -Original Message-
> > > From: Lu, XiaoyuX
> > > Sent: Wednesday, June 5, 2019 2:34 PM
> > > To: Gao, Liming ; devel@edk2.groups.io
> > > Cc: Bi, Dandan ; Wang, Jian J
> > 
> > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > CLANG38 IA32 build problem
> > >
> > > Hi Liming,
> > >
> > > > -Original Message-
> > > > From: Gao, Liming
> > > > Sent: Wednesday, June 5, 2019 1:57 PM
> > > > To: devel@edk2.groups.io; Lu, XiaoyuX 
> > > > Cc: Bi, Dandan ; Wang, Jian J
> > 
> > > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > > CLANG38 IA32 build problem
> > > >
> > > > Xiaoyu:
> > > >
> > > > >-Original Message-
> > > > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf
> > Of
> > > > >Xiaoyu Lu
> > > > >Sent: Wednesday, June 05, 2019 1:25 PM
> > > > >To: devel@edk2.groups.io
> > > > >Cc: Lu, XiaoyuX ; Bi, Dandan
> > > > ;
> > > > >Wang, Jian J 
> > > > >Subject: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > CLANG38
> > > > >IA32 build problem
> > > > >
> > > > >When use clang-3.8 to build the NetworkPkg, compiler optimization
> > > > >may use memcpy for memory copy. For example:
> > > > >
> > > > > CryptoPkg/Library/OpensslLib/openssl/ssl/ssl_rsa.c:918: undefined
> > > > > reference to `memcpy'`
> > > > >
> > > > >Compiler optimization is sophisticated, but we can work around it
> > > > >use __attribute__((__used__)) to informs the compiler that symbol
> > > > >should be retained in the object file, even if it may be
> > > > >unreferenced.
> > > > >
> > > > >Cc: Jian J Wang 
> > > > >Cc: Dandan Bi 
> > > > >Signed-off-by: Xiaoyu Lu 
> > > > >---
> > > > > CryptoPkg/Library/IntrinsicLib/CopyMem.c | 13 +
> > > > > 1 file changed, 13 insertions(+)
> > > > >
> > > > >diff --git a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > >b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > >index e29b4918d200..7faf5a34d8c1 100644
> > > > >--- a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > >+++ b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > > >@@ -10,8 +10,21 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > > > #include 
> > > > > #include 
> > > > >
> > > > >+#if defined(__clang__) && !defined(__APPLE__)
> > > >
> > > > So, this change is only for CLANG tool chain.
> > > >
> > > > >+
> > > > >+/* Copies bytes between buffers */
> > > > >+static __attribute__((__used__))
> > > >
> > > > What purpose for static?
> > > >
> > >
> > > Because I want __memcpy only use in this file scope.
> > >
> > > > >+void * __memcpy (void *dest, const void *src, unsigned int count)
> > > > >+{
> > > > >+  return CopyMem (dest, src, (UINTN)count);
> > > > >+}
> > > > >+__attribute__((__alias__("__memcpy")))
> > > > >+void * memcpy (void *dest, const void *src, unsigned int count);
> > > >
> > > > __memcpy is IA32 Intrinsic API, memcpy is X64 Intrinsic API, right?
> > > >
> > >
> > > __memcpy isn't IA32 Intrinsic API, only memcpy is intrinsic API for both
> > IA32 and X64.
> > >
> > > The reason I alias memcpy and use __attribute__((__used__)) is let
> > compiler retain symbol in object file,
> > > So it can link correct.
> > >
> > > Is this correct?
> > >
> >
> > Make sense. What test have been done by you? Build pass and Boot pass?
> >
> 
> Build pass and BaseCryptLib functions test pass.
> I don't test http boot.
> 
> Thanks,
> Xiaoyu
> 
> > > > Thanks
> > > > Liming
> > >
> > > > >+
> > > > >+#else
> > > > > /* Copies bytes between buffers */
> > > > > void * memcpy (void *dest, const void *src, unsigned int count)
> > > > > {
> > > > >   return CopyMem (dest, src, (UINTN)count);
> > > > > }
> > > > >+#endif
> > > > >--
> > > > >2.7.4
> > > > >
> > > > >
> > > > >


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

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



Re: [edk2-devel] UefiPayloadPkg: Remove legacy PIC 8259 driver

2019-06-05 Thread Liming Gao
Ard:

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ard 
> Biesheuvel
> Sent: Wednesday, June 5, 2019 2:25 PM
> To: edk2-devel-groups-io ; Ma, Maurice 
> ; Laszlo Ersek ; Leif
> Lindholm ; Gao, Liming ; 
> Kinney, Michael D 
> Cc: Dong, Guo ; You, Benjamin 
> Subject: Re: [edk2-devel] UefiPayloadPkg: Remove legacy PIC 8259 driver
> 
> On Fri, 31 May 2019 at 01:06, Ma, Maurice  wrote:
> >
> > Reviewed-by: Maurice Ma 
> >
> 
> This patch has now been pushed, while I don't think it is a bugfix,
> and we are in the middle of the hard freeze period.

Seemly, not every person well knows the hard feature freeze period for 201905 
stable tag.
201905 stable tag period is deferred than original plan. So, some people may 
not notice it.

I can prepare the patch to roll back it for 201905 stable tag. 

> 
> 
> > > -Original Message-
> > > From: Dong, Guo
> > > Sent: Thursday, May 30, 2019 2:52
> > > To: devel@edk2.groups.io
> > > Cc: Ma, Maurice ; You, Benjamin
> > > ; Dong, Guo 
> > > Subject: [edk2-devel] UefiPayloadPkg: Remove legacy PIC 8259 driver
> > >
> > > Since legacy PIC 8259 driver would be removed from edk2, update UEFI 
> > > payload
> > > to remove 8259 driver.
> > > If required, bootloader could disable 8259.
> > >
> > > Signed-off-by: Guo Dong 
> > > ---
> > >  UefiPayloadPkg/UefiPayloadPkg.fdf| 1 -
> > >  UefiPayloadPkg/UefiPayloadPkgIa32.dsc| 1 -
> > >  UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc | 1 -
> > >  3 files changed, 3 deletions(-)
> > >
> > > diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf
> > > b/UefiPayloadPkg/UefiPayloadPkg.fdf
> > > index ce3b34999b..4cd88a3f85 100644
> > > --- a/UefiPayloadPkg/UefiPayloadPkg.fdf
> > > +++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
> > > @@ -104,7 +104,6 @@ INF
> > > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
> > >  INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
> > >  INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> > >  INF
> > > MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestD
> > > xe.inf
> > > -INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> > >  INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
> > >  INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> > >  INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
> > > diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> > > b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> > > index 5b6ed36e9c..11cf17ca06 100644
> > > --- a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> > > +++ b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> > > @@ -432,7 +432,6 @@
> > >UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
> > >MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> > >
> > > MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestD
> > > xe.inf
> > > -  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> > >MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
> > >MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> > >MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
> > > diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> > > b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> > > index d57b5241dc..5b7994a62c 100644
> > > --- a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> > > +++ b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> > > @@ -433,7 +433,6 @@
> > >UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
> > >MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> > >
> > > MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestD
> > > xe.inf
> > > -  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> > >MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
> > >MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> > >MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
> > > --
> > > 2.16.2.windows.1
> >
> >
> >
> >
> 
> 


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

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



Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem

2019-06-05 Thread Xiaoyu Lu
Liming,

> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, June 5, 2019 3:28 PM
> To: Lu, XiaoyuX ; devel@edk2.groups.io
> Cc: Bi, Dandan ; Wang, Jian J 
> Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> CLANG38 IA32 build problem
> 
> Xiaoyu:
> 
> > -Original Message-
> > From: Lu, XiaoyuX
> > Sent: Wednesday, June 5, 2019 2:34 PM
> > To: Gao, Liming ; devel@edk2.groups.io
> > Cc: Bi, Dandan ; Wang, Jian J
> 
> > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> CLANG38 IA32 build problem
> >
> > Hi Liming,
> >
> > > -Original Message-
> > > From: Gao, Liming
> > > Sent: Wednesday, June 5, 2019 1:57 PM
> > > To: devel@edk2.groups.io; Lu, XiaoyuX 
> > > Cc: Bi, Dandan ; Wang, Jian J
> 
> > > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > > CLANG38 IA32 build problem
> > >
> > > Xiaoyu:
> > >
> > > >-Original Message-
> > > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf
> Of
> > > >Xiaoyu Lu
> > > >Sent: Wednesday, June 05, 2019 1:25 PM
> > > >To: devel@edk2.groups.io
> > > >Cc: Lu, XiaoyuX ; Bi, Dandan
> > > ;
> > > >Wang, Jian J 
> > > >Subject: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> CLANG38
> > > >IA32 build problem
> > > >
> > > >When use clang-3.8 to build the NetworkPkg, compiler optimization
> > > >may use memcpy for memory copy. For example:
> > > >
> > > > CryptoPkg/Library/OpensslLib/openssl/ssl/ssl_rsa.c:918: undefined
> > > > reference to `memcpy'`
> > > >
> > > >Compiler optimization is sophisticated, but we can work around it
> > > >use __attribute__((__used__)) to informs the compiler that symbol
> > > >should be retained in the object file, even if it may be
> > > >unreferenced.
> > > >
> > > >Cc: Jian J Wang 
> > > >Cc: Dandan Bi 
> > > >Signed-off-by: Xiaoyu Lu 
> > > >---
> > > > CryptoPkg/Library/IntrinsicLib/CopyMem.c | 13 +
> > > > 1 file changed, 13 insertions(+)
> > > >
> > > >diff --git a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > >b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > >index e29b4918d200..7faf5a34d8c1 100644
> > > >--- a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > >+++ b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > > >@@ -10,8 +10,21 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > > #include 
> > > > #include 
> > > >
> > > >+#if defined(__clang__) && !defined(__APPLE__)
> > >
> > > So, this change is only for CLANG tool chain.
> > >
> > > >+
> > > >+/* Copies bytes between buffers */
> > > >+static __attribute__((__used__))
> > >
> > > What purpose for static?
> > >
> >
> > Because I want __memcpy only use in this file scope.
> >
> > > >+void * __memcpy (void *dest, const void *src, unsigned int count)
> > > >+{
> > > >+  return CopyMem (dest, src, (UINTN)count);
> > > >+}
> > > >+__attribute__((__alias__("__memcpy")))
> > > >+void * memcpy (void *dest, const void *src, unsigned int count);
> > >
> > > __memcpy is IA32 Intrinsic API, memcpy is X64 Intrinsic API, right?
> > >
> >
> > __memcpy isn't IA32 Intrinsic API, only memcpy is intrinsic API for both
> IA32 and X64.
> >
> > The reason I alias memcpy and use __attribute__((__used__)) is let
> compiler retain symbol in object file,
> > So it can link correct.
> >
> > Is this correct?
> >
> 
> Make sense. What test have been done by you? Build pass and Boot pass?
> 

Build pass and BaseCryptLib functions test pass.
I don't test http boot.

Thanks,
Xiaoyu

> > > Thanks
> > > Liming
> >
> > > >+
> > > >+#else
> > > > /* Copies bytes between buffers */
> > > > void * memcpy (void *dest, const void *src, unsigned int count)
> > > > {
> > > >   return CopyMem (dest, src, (UINTN)count);
> > > > }
> > > >+#endif
> > > >--
> > > >2.7.4
> > > >
> > > >
> > > >


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

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



Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem

2019-06-05 Thread Liming Gao
Xiaoyu:

> -Original Message-
> From: Lu, XiaoyuX
> Sent: Wednesday, June 5, 2019 2:34 PM
> To: Gao, Liming ; devel@edk2.groups.io
> Cc: Bi, Dandan ; Wang, Jian J 
> Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 
> IA32 build problem
> 
> Hi Liming,
> 
> > -Original Message-
> > From: Gao, Liming
> > Sent: Wednesday, June 5, 2019 1:57 PM
> > To: devel@edk2.groups.io; Lu, XiaoyuX 
> > Cc: Bi, Dandan ; Wang, Jian J 
> > Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> > CLANG38 IA32 build problem
> >
> > Xiaoyu:
> >
> > >-Original Message-
> > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > >Xiaoyu Lu
> > >Sent: Wednesday, June 05, 2019 1:25 PM
> > >To: devel@edk2.groups.io
> > >Cc: Lu, XiaoyuX ; Bi, Dandan
> > ;
> > >Wang, Jian J 
> > >Subject: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38
> > >IA32 build problem
> > >
> > >When use clang-3.8 to build the NetworkPkg, compiler optimization
> > >may use memcpy for memory copy. For example:
> > >
> > > CryptoPkg/Library/OpensslLib/openssl/ssl/ssl_rsa.c:918: undefined
> > > reference to `memcpy'`
> > >
> > >Compiler optimization is sophisticated, but we can work around it
> > >use __attribute__((__used__)) to informs the compiler that symbol
> > >should be retained in the object file, even if it may be
> > >unreferenced.
> > >
> > >Cc: Jian J Wang 
> > >Cc: Dandan Bi 
> > >Signed-off-by: Xiaoyu Lu 
> > >---
> > > CryptoPkg/Library/IntrinsicLib/CopyMem.c | 13 +
> > > 1 file changed, 13 insertions(+)
> > >
> > >diff --git a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > >b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > >index e29b4918d200..7faf5a34d8c1 100644
> > >--- a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > >+++ b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> > >@@ -10,8 +10,21 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > #include 
> > > #include 
> > >
> > >+#if defined(__clang__) && !defined(__APPLE__)
> >
> > So, this change is only for CLANG tool chain.
> >
> > >+
> > >+/* Copies bytes between buffers */
> > >+static __attribute__((__used__))
> >
> > What purpose for static?
> >
> 
> Because I want __memcpy only use in this file scope.
> 
> > >+void * __memcpy (void *dest, const void *src, unsigned int count)
> > >+{
> > >+  return CopyMem (dest, src, (UINTN)count);
> > >+}
> > >+__attribute__((__alias__("__memcpy")))
> > >+void * memcpy (void *dest, const void *src, unsigned int count);
> >
> > __memcpy is IA32 Intrinsic API, memcpy is X64 Intrinsic API, right?
> >
> 
> __memcpy isn't IA32 Intrinsic API, only memcpy is intrinsic API for both IA32 
> and X64.
> 
> The reason I alias memcpy and use __attribute__((__used__)) is let compiler 
> retain symbol in object file,
> So it can link correct.
> 
> Is this correct?
> 

Make sense. What test have been done by you? Build pass and Boot pass?

> > Thanks
> > Liming
> 
> > >+
> > >+#else
> > > /* Copies bytes between buffers */
> > > void * memcpy (void *dest, const void *src, unsigned int count)
> > > {
> > >   return CopyMem (dest, src, (UINTN)count);
> > > }
> > >+#endif
> > >--
> > >2.7.4
> > >
> > >
> > >


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

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



Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem

2019-06-05 Thread Xiaoyu Lu
Hi Liming,

> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, June 5, 2019 1:57 PM
> To: devel@edk2.groups.io; Lu, XiaoyuX 
> Cc: Bi, Dandan ; Wang, Jian J 
> Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
> CLANG38 IA32 build problem
> 
> Xiaoyu:
> 
> >-Original Message-
> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> >Xiaoyu Lu
> >Sent: Wednesday, June 05, 2019 1:25 PM
> >To: devel@edk2.groups.io
> >Cc: Lu, XiaoyuX ; Bi, Dandan
> ;
> >Wang, Jian J 
> >Subject: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38
> >IA32 build problem
> >
> >When use clang-3.8 to build the NetworkPkg, compiler optimization
> >may use memcpy for memory copy. For example:
> >
> > CryptoPkg/Library/OpensslLib/openssl/ssl/ssl_rsa.c:918: undefined
> > reference to `memcpy'`
> >
> >Compiler optimization is sophisticated, but we can work around it
> >use __attribute__((__used__)) to informs the compiler that symbol
> >should be retained in the object file, even if it may be
> >unreferenced.
> >
> >Cc: Jian J Wang 
> >Cc: Dandan Bi 
> >Signed-off-by: Xiaoyu Lu 
> >---
> > CryptoPkg/Library/IntrinsicLib/CopyMem.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> >diff --git a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> >b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> >index e29b4918d200..7faf5a34d8c1 100644
> >--- a/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> >+++ b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
> >@@ -10,8 +10,21 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > #include 
> > #include 
> >
> >+#if defined(__clang__) && !defined(__APPLE__)
> 
> So, this change is only for CLANG tool chain.
> 
> >+
> >+/* Copies bytes between buffers */
> >+static __attribute__((__used__))
> 
> What purpose for static?
> 

Because I want __memcpy only use in this file scope.

> >+void * __memcpy (void *dest, const void *src, unsigned int count)
> >+{
> >+  return CopyMem (dest, src, (UINTN)count);
> >+}
> >+__attribute__((__alias__("__memcpy")))
> >+void * memcpy (void *dest, const void *src, unsigned int count);
> 
> __memcpy is IA32 Intrinsic API, memcpy is X64 Intrinsic API, right?
> 

__memcpy isn't IA32 Intrinsic API, only memcpy is intrinsic API for both IA32 
and X64.

The reason I alias memcpy and use __attribute__((__used__)) is let compiler 
retain symbol in object file,
So it can link correct.

Is this correct?

> Thanks
> Liming

> >+
> >+#else
> > /* Copies bytes between buffers */
> > void * memcpy (void *dest, const void *src, unsigned int count)
> > {
> >   return CopyMem (dest, src, (UINTN)count);
> > }
> >+#endif
> >--
> >2.7.4
> >
> >
> >


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

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