Re: [edk2] Does __attribute__ ((selectany)) make sense now for GCC?

2018-05-18 Thread Andrew Fish 
Tim,

 VC++ is a strange beast. See C99 support. VC++ seems to do strange things to 
support non standard hackyness of years past. So the only reason I can think of 
that  __attribute__ ((selectany)) is associated with dead stripping, is doing 
it correctly broke some chunk of code that was required for compatibility. From 
looking on the VC++ site it seems like COMDAT folding may be required for dead 
code removal, but again this not required to make it work, but to not break old 
crufty stuff. 

I guess on Windows GCC they could trying to "copy exact" VC++ behavior, but it 
is most definitely going to be ignored on the non-Windows versions. 

The answer from Microsoft on C99 is to use clang :)

Thanks,

Andrew Fish

> On May 18, 2018, at 3:43 PM, Tim Lewis  wrote:
> 
> Andrew -
> 
> 
> 
> I know for Visual Studio it does the same thing for data that /Gy does for
> code.
> 
> 
> 
> That is, if the data is unreferenced, then it doesn't get brought it.
> 
> 
> 
> Maybe link-time code generation has the same effect. That's what I'm curious
> about. 
> 
> 
> 
> Tim
> 
> 
> 
> From: af...@apple.com   > 
> Sent: Friday, May 18, 2018 3:39 PM
> To: Tim Lewis >
> Cc: edk2-devel@lists.01.org 
> Subject: Re: [edk2] Does __attribute__ ((selectany)) make sense now for GCC?
> 
> 
> 
> Tim,
> 
> 
> 
> Looks like that is only available on Windows versions of GCC, and is more
> about compatible behavior. 
> 
> 
> 
> selectany
> 
> The selectany attribute causes an initialized global variable to have
> link-once semantics. When multiple definitions of the variable are
> encountered by the linker, the first is selected and the remainder are
> discarded. Following usage by the Microsoft compiler, the linker is told not
> to warn about size or content differences of the multiple definitions.
> 
> Although the primary usage of this attribute is for POD types, the attribute
> can also be applied to global C++ objects that are initialized by a
> constructor. In this case, the static initialization and destruction code
> for the object is emitted in each translation defining the object, but the
> calls to the constructor and destructor are protected by a link-once guard
> variable.
> 
> The selectany attribute is only available on Microsoft Windows targets. You
> can use __declspec (selectany) as a synonym for __attribute__ ((selectany))
> for compatibility with other compilers.
> 
> 
> 
> What I've noticed with clang/LLVM is the unreferenced globals get removed
> when you enable link time optimizations. 
> 
> 
> 
> I'd actually ask the opposite question. Does __declspec(selectany) impact
> dead code removal on current versions of VC++? 
> 
> 
> 
> Thanks,
> 
> 
> 
> Andrew Fish
> 
> 
> 
> 
> 
> On May 18, 2018, at 3:22 PM, Tim Lewis  > > wrote:
> 
> 
> 
> In Visual Studio we have __declspec(selectany) to limit the impact of unused
> data.
> 
> 
> 
> I see that GCC for Windows has __attribute__ ((selectany)).
> 
> 
> 
> Should we me using this for GLOBAL_REMOVE_IF_UNREFERENCED in
> MdePkg\Include\Base.h?
> 
> 
> 
> Tim
> 
> ___
> edk2-devel mailing list
> > 
> edk2-devel@lists.01.org 
>  >
> https://lists.01.org/mailman/listinfo/edk2-devel 
> 
> 
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org 
> https://lists.01.org/mailman/listinfo/edk2-devel 
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Does __attribute__ ((selectany)) make sense now for GCC?

2018-05-18 Thread Tim Lewis 
Andrew -

 

I know for Visual Studio it does the same thing for data that /Gy does for
code.

 

That is, if the data is unreferenced, then it doesn't get brought it.

 

Maybe link-time code generation has the same effect. That's what I'm curious
about. 

 

Tim

 

From: af...@apple.com  
Sent: Friday, May 18, 2018 3:39 PM
To: Tim Lewis 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Does __attribute__ ((selectany)) make sense now for GCC?

 

Tim,

 

Looks like that is only available on Windows versions of GCC, and is more
about compatible behavior. 

 

selectany

The selectany attribute causes an initialized global variable to have
link-once semantics. When multiple definitions of the variable are
encountered by the linker, the first is selected and the remainder are
discarded. Following usage by the Microsoft compiler, the linker is told not
to warn about size or content differences of the multiple definitions.

Although the primary usage of this attribute is for POD types, the attribute
can also be applied to global C++ objects that are initialized by a
constructor. In this case, the static initialization and destruction code
for the object is emitted in each translation defining the object, but the
calls to the constructor and destructor are protected by a link-once guard
variable.

The selectany attribute is only available on Microsoft Windows targets. You
can use __declspec (selectany) as a synonym for __attribute__ ((selectany))
for compatibility with other compilers.

 

What I've noticed with clang/LLVM is the unreferenced globals get removed
when you enable link time optimizations. 

 

I'd actually ask the opposite question. Does __declspec(selectany) impact
dead code removal on current versions of VC++? 

 

Thanks,

 

Andrew Fish





On May 18, 2018, at 3:22 PM, Tim Lewis  > wrote:

 

In Visual Studio we have __declspec(selectany) to limit the impact of unused
data.



I see that GCC for Windows has __attribute__ ((selectany)).



Should we me using this for GLOBAL_REMOVE_IF_UNREFERENCED in
MdePkg\Include\Base.h?



Tim

___
edk2-devel mailing list
  edk2-devel@lists.01.org
 
https://lists.01.org/mailman/listinfo/edk2-devel

 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] BaseTools/Workspace: Fix ValueChain set

2018-05-18 Thread Marvin Häuser 
Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed ValueChain
from a dict to a set, but also changed the (former) key type from a
touple to two separate values, which was probably unintended and also
breaks build for packages involving Structured PCDs, because add()
only takes one argument.
This commit changes the values back to touples.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 BaseTools/Source/Python/Workspace/DscBuildData.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 8476543c5352..0262a91ed855 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -1347,7 +1347,7 @@ class DscBuildData(PlatformBuildClassObject):
 nextskuid = self.SkuIdMgr.GetNextSkuId(nextskuid)
 stru_pcd.SkuOverrideValues[skuid] = 
copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid]) if not NoDefault else 
copy.deepcopy({defaultstorename: stru_pcd.DefaultValues for defaultstorename in 
DefaultStores} if DefaultStores else 
{TAB_DEFAULT_STORES_DEFAULT:stru_pcd.DefaultValues})
 if not NoDefault:
-stru_pcd.ValueChain.add(skuid,'')
+stru_pcd.ValueChain.add((skuid,''))
 if stru_pcd.Type in 
[self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_HII], 
self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_EX_HII]]:
 for skuid in SkuIds:
 nextskuid = skuid
@@ -1366,7 +1366,7 @@ class DscBuildData(PlatformBuildClassObject):
 for defaultstoreid in DefaultStores:
 if defaultstoreid not in 
stru_pcd.SkuOverrideValues[skuid]:
 stru_pcd.SkuOverrideValues[skuid][defaultstoreid] 
= copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid][mindefaultstorename])
-stru_pcd.ValueChain.add(skuid,defaultstoreid)
+stru_pcd.ValueChain.add((skuid,defaultstoreid))
 S_pcd_set = DscBuildData.OverrideByFdfComm(S_pcd_set)
 Str_Pcd_Values = self.GenerateByteArrayValue(S_pcd_set)
 if Str_Pcd_Values:
-- 
2.17.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Does __attribute__ ((selectany)) make sense now for GCC?

2018-05-18 Thread Tim Lewis 
In Visual Studio we have __declspec(selectany) to limit the impact of unused
data.

 

I see that GCC for Windows has __attribute__ ((selectany)).

 

Should we me using this for GLOBAL_REMOVE_IF_UNREFERENCED in
MdePkg\Include\Base.h?

 

Tim

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] BaseTools/tools_def: add "-fno-unwind-tables" to GCC_AARCH64_CC_FLAGS

2018-05-18 Thread Laszlo Ersek 
The ElfConvert routines in GenFw don't handle the ".eh_frame" ELF section
emitted by gcc. For this reason, Leif disabled the generation of that
section for AARCH64 with "-fno-asynchronous-unwind-tables" in commit
28e80befa4fe [1], and Ard did the same for IA32 and X64 in commit
26ecc55c027d [2]. (The CLANG38 toolchain received the same flag at its
inception, in commit 6f756db5ea05 [3].)

However, ".eh_frame" is back now; in upstream gcc commit 9cbee213b579 [4]
(part of tag "gcc-8_1_0-release"), both "-fasynchronous-unwind-tables" and
"-funwind-tables" were made the default for AARCH64. (The patch author
described the effects on the gcc mailing list [5].) We have to counter the
latter flag with "-fno-unwind-tables", otherwise GenFw chokes on
".eh_frame" again (triggered for example on Fedora 28).

"-f[no-]unwind-tables" goes back to at least gcc-4.4 [6], so it's safe to
add to GCC_AARCH64_CC_FLAGS.

[1] https://github.com/tianocore/edk2/commit/28e80befa4fe
[2] https://github.com/tianocore/edk2/commit/26ecc55c027d
[3] https://github.com/tianocore/edk2/commit/6f756db5ea05
[4] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9cbee213b579
[5] 
http://mid.mail-archive.com/7b28c03a-c032-6cec-c127-1c12cbe98eeb@foss.arm.com
[6] https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Code-Gen-Options.html

Cc: "Danilo C. L. de Paula" 
Cc: Ard Biesheuvel 
Cc: Cole Robinson 
Cc: Gerd Hoffmann 
Cc: Leif Lindholm 
Cc: Liming Gao 
Cc: Paolo Bonzini 
Cc: Yonghong Zhu 
Reported-by: "Danilo C. L. de Paula" 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
Repo:   https://github.com/lersek/edk2.git
Branch: aarch64_no_unwind_tables

 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 03d700018550..9429033fe2e3 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4537,7 +4537,7 @@ DEFINE GCC_X64_CC_FLAGS= 
DEF(GCC_ALL_CC_FLAGS) -mno-red-zone -Wno-ad
 DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
-minline-int-divide-min-latency
 DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections 
-fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft 
-fno-pic -fno-pie
 DEFINE GCC_ARM_CC_XIPFLAGS = -mno-unaligned-access
-DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections 
-fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic -fno-pie 
-ffixed-x18
+DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections 
-fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-unwind-tables 
-fno-pic -fno-pie -ffixed-x18
 DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align -mgeneral-regs-only
 DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
 DEFINE GCC_DLINK2_FLAGS_COMMON = 
-Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
-- 
2.14.1.3.gb7cf6e02401b

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v2 0/3][platforms/devel-dynamictables] Update for ACPICA compiler enhancements

2018-05-18 Thread Evan Lloyd 
Reviewed-by: Evan Lloyd 

Leif, Ard - are you happy to accept this for the patchset, or should I respond 
to each patch?

Regards,
Evan

> -Original Message-
> From: edk2-devel  On Behalf Of Sami
> Mujawar
> Sent: 18 May 2018 14:13
> To: edk2-devel@lists.01.org
> Cc: nd ; Arvind Chauhan ;
> ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Stephanie Hughes-Fitt
> 
> Subject: [edk2] [PATCH edk2-platforms v2 0/3][platforms/devel-
> dynamictables] Update for ACPICA compiler enhancements
> 
> The ACPICA iAsl compiler has recently been enhanced to support a feature
> required by Dynamic Tables Framework for processing ASL files. The
> compiler however generates slightly different symbol names to what was
> previously referenced in the Configuration Manager.
> 
> This patchset adapts to the latest iASL compiler options.
> 
> The changes can be seen at
> https://github.com/samimujawar/edk2-
> platforms/tree/258_reflect_acpica_compiler_enhancement_v2
> 
> Sami Mujawar (3):
>   Platform/ARM: Match asl compiler output for Juno
>   Platform/ARM: Match asl compiler output for FVP
>   Update Readme.md to reflect ACPICA compiler update
> 
> 
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/C
> onfigurationManager.c |  8 +++
> 
> Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerD
> xe/ConfigurationManager.c |  2 +-
>  Readme.md
> | 25
> +---
>  3 files changed, 21 insertions(+), 14 deletions(-)
> 
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [staging/dynamictables PATCH v2] Update Readme.md to reflect ACPICA compiler update

2018-05-18 Thread Evan Lloyd 

Reviewed-by: Evan Lloyd 

> -Original Message-
> From: Sami Mujawar 
> Sent: 18 May 2018 12:09
> To: edk2-devel@lists.01.org
> Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Matteo Carlini
> ; Stephanie Hughes-Fitt  f...@arm.com>; nd ; Evan Lloyd 
> Subject: [staging/dynamictables PATCH v2] Update Readme.md to reflect
> ACPICA compiler update
> 
> The ACPICA iASL compiler has been enhanced to support the generation of
> an AML hex file which is required by the Dynamic Tables Framework. The
> patch for this enhancement has been integrated in the ACPICA repository.
> Therefore the Prerequisites section in the Readme has been updated
> accordingly.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sami Mujawar 
> ---
> 
> The changes can be seen at https://github.com/samimujawar/edk2-
> staging/tree/258_reflect_acpica_compiler_enhancement_v2
> 
> Notes:
> v2:
> - Add patch commit date and info about presentation.  [LEIF]
> - Updated Readme.md to add date for referencing ACPICA patch.
>   Also annotated the UEFI presentation.   [SAMI]
> 
> v1:
> - Update ACPICA iAsl compiler usage guidelines.   [SAMI]
> 
>  Readme.md | 25 +---
>  1 file changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/Readme.md b/Readme.md
> index
> b72efca18e8ab5de17cab06f0a1a0725991256d4..6501623503d6ec8ef4840aeb
> c70561d44cf1ca12 100644
> --- a/Readme.md
> +++ b/Readme.md
> @@ -87,9 +87,9 @@ contains the Dynamic Tables Framework.
>  ### ACPICA iASL compiler
>  The RAW table generator, used to process the DSDT/SSDT files depends on
> the iASL compiler to convert the DSDT/SSDT ASL files to a C array containing -
> the hex AML code. The current implementation of the iASL compiler does not
> -support generation of a C header file suitable for including from a C source 
> -
> file.
> +the hex AML code. The "-tc" option of the iASL compiler has been
> +enhanced to support generation of an AML hex file (C header) with a
> +unique symbol name so that it is suitable for inclusion from a C source file.
> 
>  Related Links
>  --
> @@ -135,16 +135,23 @@ or
> 
>  Prerequisites
>  -
> -ACPICA iASL compiler with support for generating a C header file.
> +ACPICA iASL compiler with the enhanced "-tc" option to support
> +generation of AML hex (C header) files with unique symbol names.
> 
> -A patch ***'Modify hex AML C header file generation'***, to enable -this
> support has been submitted to the ACPICA source repository.
> -
> +A patch *'[iASL: Enhance the -tc option (create AML hex file in
> +C)](https://github.com/acpica/acpica/commit/f9a88a4c1cd020b6a5475d63
> b29626852a0b5f37)'*, dated 16 March 2018 (2018-03-16), to enable this
> support has been integrated to the ACPICA source repository.
> +
> +Ensure that the iASL compiler used for building *Dynamic Tables
> Framework* has this feature enabled.
> +
> +This feature was made available in the *ACPICA Compiler update [Version
> +20180508](https://www.acpica.org/node/156)*, dated 8 May 2018 (2018-
> 05-08).
> 
>  Documentation
>  -
> -A description document is in preparation, and should be available in the -
> near future.
> +
> +Refer to the following presentation from *UEFI Plugfest Seattle 2018*:
> +
> +[Dynamic Tables Framework: A Step Towards Automatic Generation of
> +Advanced Configuration and Power Interface (ACPI) & System Management
> +BIOS (SMBIOS) Tables – Sami Mujawar
> +(Arm).](http://www.uefi.org/sites/default/files/resources/Arm_Dynamic%2
> +0Tables%20Framework%20A%20Step%20Towards%20Automatic%20Gener
> ation%20of%
> +20Advanced%20Configuration%20and%20Power%20Interface%20%28ACPI
> %29%20%26
> +%20System%20Management%20BIOS%20%28SMBIOS%29%20Tables%20_0.
> pdf)
> 
>  Miscellaneous
>  -
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v2 1/3][platforms/devel-dynamictables] Platform/ARM: Match asl compiler output for Juno

2018-05-18 Thread Sami Mujawar 
The iASL compiler's -tc option has been updated to generate
output that is suitable for including from a C file. The iASL
compiler uniquely names the C array containing the processed
table data as _aml_code.The patch for this update,
'iASL: Enhance the -tc option (create AML hex file in C)',
dated 16 March 2018 (2018-03-16), can be seen in the ACPICA git
repository at
https://github.com/acpica/acpica/commit/f9a88a4c1cd020b6a5475d63b29626852a0b5f37

A corresponding change is required in the ConfigurationManager
and this patch contains the necessary changes to adapt to the
generated iASL compiler output.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---

Notes:
v2:
- Add patch commit date.  [LEIF]
- Updated commit message to add date for referenced ACPICA patch. [SAMI]

v1:
- Update Configuration Manager to match iASL compiler output. [SAMI]

 
Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 
b/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
index 
0e67dfa1f47cc3004b775ec43d02e07754675e26..4c878f663ab247307a17582c07f303ddb11b7d41
 100644
--- 
a/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
+++ 
b/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
@@ -74,7 +74,7 @@ EFI_PLATFORM_REPOSITORY_INFO ArmJunoPlatformRepositoryInfo = {
 {
   EFI_ACPI_6_2_DIFFERENTIATED_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
   CREATE_STD_ACPI_TABLE_GEN_ID (ESTD_ACPI_TABLE_ID_DSDT),
-  (EFI_ACPI_DESCRIPTION_HEADER*)dsdt_AmlCode
+  (EFI_ACPI_DESCRIPTION_HEADER*)dsdt_aml_code
 },
 // DBG2 Table
 {
@@ -86,13 +86,13 @@ EFI_PLATFORM_REPOSITORY_INFO ArmJunoPlatformRepositoryInfo 
= {
 {
   EFI_ACPI_6_2_SECONDARY_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
   CREATE_STD_ACPI_TABLE_GEN_ID (ESTD_ACPI_TABLE_ID_SSDT),
-  (EFI_ACPI_DESCRIPTION_HEADER*)ssdtjunousb_AmlCode
+  (EFI_ACPI_DESCRIPTION_HEADER*)ssdtjunousb_aml_code
 },
 // SSDT table describing the PL011 UART
 {
   EFI_ACPI_6_2_SECONDARY_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
   CREATE_STD_ACPI_TABLE_GEN_ID (ESTD_ACPI_TABLE_ID_SSDT),
-  (EFI_ACPI_DESCRIPTION_HEADER*)ssdtuart_AmlCode
+  (EFI_ACPI_DESCRIPTION_HEADER*)ssdtuart_aml_code
 },
 
 /* PCI MCFG Table
@@ -109,7 +109,7 @@ EFI_PLATFORM_REPOSITORY_INFO ArmJunoPlatformRepositoryInfo 
= {
 {
   EFI_ACPI_6_2_SECONDARY_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
   CREATE_STD_ACPI_TABLE_GEN_ID (ESTD_ACPI_TABLE_ID_SSDT),
-  (EFI_ACPI_DESCRIPTION_HEADER*)ssdtpci_AmlCode
+  (EFI_ACPI_DESCRIPTION_HEADER*)ssdtpci_aml_code
 }
   },
 
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v2 2/3][platforms/devel-dynamictables] Platform/ARM: Match asl compiler output for FVP

2018-05-18 Thread Sami Mujawar 
The iASL compiler's -tc option has been updated to generate
output that is suitable for including from a C file. The iASL
compiler uniquely names the C array containing the processed
table data as _aml_code. The patch for this update,
'iASL: Enhance the -tc option (create AML hex file in C)',
dated 16 March 2018 (2018-03-16), can be seen in the ACPICA git
repository at
https://github.com/acpica/acpica/commit/f9a88a4c1cd020b6a5475d63b29626852a0b5f37

A corresponding change is required in the ConfigurationManager
and this patch contains the necessary changes to adapt to the
generated iASL compiler output.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---

Notes:
v2:
- Add patch commit date.  [LEIF]
- Updated commit message to add date for referenced ACPICA patch. [SAMI]

v1:
- Update Configuration Manager to match iASL compiler output.   [SAMI]

 
Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 
b/Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
index 
d45528813e2db9f44e1745392dfd35ffe05f1dca..2e1be34acf49962fd1899d84dec96c8cb9155b2c
 100644
--- 
a/Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
+++ 
b/Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
@@ -71,7 +71,7 @@ EFI_PLATFORM_REPOSITORY_INFO VExpressPlatRepositoryInfo = {
 {
   EFI_ACPI_6_2_DIFFERENTIATED_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
   CREATE_STD_ACPI_TABLE_GEN_ID (ESTD_ACPI_TABLE_ID_DSDT),
-  (EFI_ACPI_DESCRIPTION_HEADER*)dsdt_AmlCode
+  (EFI_ACPI_DESCRIPTION_HEADER*)dsdt_aml_code
 },
 // DBG2 Table
 {
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v2 0/3][platforms/devel-dynamictables] Update for ACPICA compiler enhancements

2018-05-18 Thread Sami Mujawar 
The ACPICA iAsl compiler has recently been enhanced to support a
feature required by Dynamic Tables Framework for processing ASL
files. The compiler however generates slightly different symbol
names to what was previously referenced in the Configuration Manager.

This patchset adapts to the latest iASL compiler options.

The changes can be seen at
https://github.com/samimujawar/edk2-platforms/tree/258_reflect_acpica_compiler_enhancement_v2

Sami Mujawar (3):
  Platform/ARM: Match asl compiler output for Juno
  Platform/ARM: Match asl compiler output for FVP
  Update Readme.md to reflect ACPICA compiler update

 
Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 |  8 +++
 
Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 |  2 +-
 Readme.md  
  | 25 +---
 3 files changed, 21 insertions(+), 14 deletions(-)

-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v2 3/3][platforms/devel-dynamictables] Update Readme.md to reflect ACPICA compiler update

2018-05-18 Thread Sami Mujawar 
The ACPICA iASL compiler has been enhanced to support the
generation of an AML hex file which is required by the
Dynamic Tables Framework. The patch for this enhancement
has been integrated in the ACPICA repository. Therefore
the Prerequisites section in the Readme has been updated
accordingly.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---

Notes:
v2:
- Add patch commit date and info about presentation.  [LEIF]
- Updated Readme.md to add date for referencing ACPICA patch.
  Also annotated the UEFI presentation.   [SAMI]

v1:
- Update ACPICA iAsl compiler usage guidelines.   [SAMI]

 Readme.md | 25 +---
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/Readme.md b/Readme.md
index 
b72efca18e8ab5de17cab06f0a1a0725991256d4..6501623503d6ec8ef4840aebc70561d44cf1ca12
 100644
--- a/Readme.md
+++ b/Readme.md
@@ -87,9 +87,9 @@ contains the Dynamic Tables Framework.
 ### ACPICA iASL compiler
 The RAW table generator, used to process the DSDT/SSDT files depends on
 the iASL compiler to convert the DSDT/SSDT ASL files to a C array containing
-the hex AML code. The current implementation of the iASL compiler does not
-support generation of a C header file suitable for including from a C source
-file.
+the hex AML code. The "-tc" option of the iASL compiler has been enhanced to
+support generation of an AML hex file (C header) with a unique symbol name
+so that it is suitable for inclusion from a C source file.
 
 Related Links
 --
@@ -135,16 +135,23 @@ or
 
 Prerequisites
 -
-ACPICA iASL compiler with support for generating a C header file.
+ACPICA iASL compiler with the enhanced "-tc" option to support generation of
+AML hex (C header) files with unique symbol names.
 
-A patch ***'Modify hex AML C header file generation'***, to enable
-this support has been submitted to the ACPICA source repository.
-
+A patch *'[iASL: Enhance the -tc option (create AML hex file in 
C)](https://github.com/acpica/acpica/commit/f9a88a4c1cd020b6a5475d63b29626852a0b5f37)'*,
 dated 16 March 2018 (2018-03-16),
+to enable this support has been integrated to the ACPICA source repository.
+
+Ensure that the iASL compiler used for building *Dynamic Tables Framework* has 
this feature enabled.
+
+This feature was made available in the *ACPICA Compiler update
+[Version 20180508](https://www.acpica.org/node/156)*, dated 8 May 2018 
(2018-05-08).
 
 Documentation
 -
-A description document is in preparation, and should be available in the
-near future.
+
+Refer to the following presentation from *UEFI Plugfest Seattle 2018*:
+
+[Dynamic Tables Framework: A Step Towards Automatic Generation of Advanced 
Configuration and Power Interface (ACPI) & System Management BIOS (SMBIOS) 
Tables – Sami Mujawar 
(Arm).](http://www.uefi.org/sites/default/files/resources/Arm_Dynamic%20Tables%20Framework%20A%20Step%20Towards%20Automatic%20Generation%20of%20Advanced%20Configuration%20and%20Power%20Interface%20%28ACPI%29%20%26%20System%20Management%20BIOS%20%28SMBIOS%29%20Tables%20_0.pdf)
 
 Miscellaneous
 -
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/4] RFC: ovmf: Add support for TPM Physical Presence interface

2018-05-18 Thread Stefan Berger 

On 05/18/2018 08:23 AM, marcandre.lur...@redhat.com wrote:

From: Marc-André Lureau 

Hi,

The following series adds basic TPM PPI 1.3 support for OVMF-on-QEMU
with TPM2 (I haven't looked at TPM1, for lack of interest).

PPI test runs successfully with Windows 10 WHLK, despite the limited
number of supported funcions (tpm2_ppi_funcs table, in particular, no
function allows to manipulate Tcg2PhysicalPresenceFlags)

The way it works is relatively simple: a memory region is allocated by
QEMU to save PPI related variables. An ACPI interface is exposed by
QEMU to let the guest manipulate those. At boot, ovmf processes and
updates the PPI qemu region and request variables.

I build edk2 with:

$ build -DTPM2_ENABLE

I test with qemu & swtpm/libtpms (tpm2 branches, swtpm_setup.sh --tpm2
  --tpm-state tpmstatedir)

$ swtpm socket --tpmstate tpmstatedir --ctrl type=unixio,path=tpmsock
   --tpm2 &


Make this:

swtpm socket --tpmstate dir=tpmstatedir --ctrl type=unixio,path=tpmsock 
--tpm2




$ qemu .. -chardev socket,id=chrtpm,path=tpmsock -tpmdev
   emulator,id=tpm0,chardev=chrtpm -device tpm-crb,tpmdev=tpm0

Github trees:
https://github.com/elmarco/edk2/tree/tpm-ppi
https://github.com/elmarco/qemu/tree/tpm-ppi

Thanks

v3: after Laszlo review
  - dropped DxeTcg2PhysicalPresenceLib.uni
  - removed mTpm2PPIFuncs static initialization, use hard-coded assignments
  - declared STATIC the functions that should be
  - fixed an OUT/IN decorator
  - use EFI_PROTOCOL_ERROR instead of EFI_INVALID_PARAMETER when PPI
initialization fails
  - replaced EFI_D_INFO with DEBUG_INFO
  - added a check for mPpi address that it doesn't cross a page boundary
  - added a GetMemorySpaceDescriptor() check for memory type
  - declared *mPpi as volatile, to correct mmio access
  - a few more style changes
  - comments updated
  - some minor dead code/inclusion/defines removal
  - added a few r-b tags

v2:
  - style and commit message fixes

Marc-André Lureau (4):
   OvmfPkg: add Tcg2PhysicalPresenceLibNull when !TPM2_ENABLE
   OvmfPkg/IndustryStandard: add QemuTpm.h header
   OvmfPkg: add Tcg2PhysicalPresenceLibQemu
   OvmfPkg/PlatformBootManagerLib: process TPM PPI request

  OvmfPkg/OvmfPkgIa32.dsc   |   4 +-
  OvmfPkg/OvmfPkgIa32X64.dsc|   4 +-
  OvmfPkg/OvmfPkgX64.dsc|   4 +-
  .../PlatformBootManagerLib.inf|   2 +
  .../DxeTcg2PhysicalPresenceLib.inf|  33 +
  .../DxeTcg2PhysicalPresenceLib.inf|  46 +-
  OvmfPkg/Include/IndustryStandard/QemuTpm.h|  69 ++
  .../PlatformBootManagerLib/BdsPlatform.c  |   6 +
  .../DxeTcg2PhysicalPresenceLib.c  |  20 +-
  .../DxeTcg2PhysicalPresenceLib.c  | 919 ++
  .../PhysicalPresenceStrings.uni   |  33 +-
  11 files changed, 1081 insertions(+), 59 deletions(-)
  create mode 100644 
OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
  copy {SecurityPkg/Library/DxeTcg2PhysicalPresenceLib => 
OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu}/DxeTcg2PhysicalPresenceLib.inf (66%)
  create mode 100644 OvmfPkg/Include/IndustryStandard/QemuTpm.h
  copy 
EdkCompatibilityPkg/Foundation/Library/EdkIIGlueLib/Library/BaseLib/Ia32/CpuSleep.c
 => OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.c 
(55%)
  create mode 100644 
OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.c
  copy {SecurityPkg/Library/DxeTcg2PhysicalPresenceLib => 
OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu}/PhysicalPresenceStrings.uni (56%)



___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 3/4] OvmfPkg: add Tcg2PhysicalPresenceLibQemu

2018-05-18 Thread marcandre . lureau 
From: Marc-André Lureau 

Cloned "SecurityPkg/Library/DxeTcg2PhysicalPresenceLib" and:

- removed all the functions that are unreachable from
  Tcg2PhysicalPresenceLibProcessRequest() [called from platform BDS],
  or SubmitRequestToPreOSFunction() and
  ReturnOperationResponseToOsFunction() [called from Tcg2Dxe].

- replaced everything that's related to the
  TCG2_PHYSICAL_PRESENCE*_VARIABLE variables, with direct access to
  the QEMU structures.

This commit is based on initial experimental work from Stefan Berger.
In particular, he wrote most of QEMU PPI support, and designed the
qemu/firmware interaction. Initially, Stefan tried to reuse the
existing SecurityPkg code, but we eventually decided to get rid of the
variables and simplify the ovmf/qemu version.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau 
---
 OvmfPkg/OvmfPkgIa32.dsc
|   2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc 
|   2 +-
 OvmfPkg/OvmfPkgX64.dsc 
|   2 +-
 {SecurityPkg/Library/DxeTcg2PhysicalPresenceLib => 
OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu}/DxeTcg2PhysicalPresenceLib.inf |  
46 +-
 OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.c   
| 919 
 {SecurityPkg/Library/DxeTcg2PhysicalPresenceLib => 
OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu}/PhysicalPresenceStrings.uni|  
33 +-
 6 files changed, 955 insertions(+), 49 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 6c361b73cd55..251434a9ff7c 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -206,7 +206,7 @@ [LibraryClasses]
 
 !if $(TPM2_ENABLE) == TRUE
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
-  
Tcg2PhysicalPresenceLib|SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.inf
+  
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
   
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
 !else
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 62a6075a671d..ce247a59d61a 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -211,7 +211,7 @@ [LibraryClasses]
 
 !if $(TPM2_ENABLE) == TRUE
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
-  
Tcg2PhysicalPresenceLib|SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.inf
+  
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
   
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
 !else
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index cbab1aa328c6..67f7e155ee3e 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -211,7 +211,7 @@ [LibraryClasses]
 
 !if $(TPM2_ENABLE) == TRUE
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
-  
Tcg2PhysicalPresenceLib|SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.inf
+  
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
   
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
 !else
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
diff --git 
a/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.inf 
b/OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
similarity index 66%
copy from 
SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.inf
copy to 
OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
index fc10129989f6..c9c0106afdef 100644
--- 
a/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.inf
+++ b/OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
@@ -1,13 +1,25 @@
 ## @file
 #  Executes TPM 2.0 requests from OS or BIOS
 #
-#  This library will check and execute TPM 2.0 request from OS or BIOS. The 
request may
-#  ask for user confirmation before execution.
+#  This library will check and execute TPM 2.0 request from OS or
+#  BIOS. The request may ask for user confirmation before
+#  execution. It is a clone of
+#  "SecurityPkg/Library/DxeTcg2PhysicalPresenceLib" with:
+#
+#  - removed all the functions that are

[edk2] [PATCH v3 4/4] OvmfPkg/PlatformBootManagerLib: process TPM PPI request

2018-05-18 Thread marcandre . lureau 
From: Marc-André Lureau 

Call Tcg2PhysicalPresenceLibProcessRequest() to process pending PPI
requests from PlatformBootManagerAfterConsole().

Laszlo understanding of edk2 is that the PPI operation processing was
meant to occur *entirely* before End-Of-Dxe, so that 3rd party UEFI
drivers couldn't interfere with PPI opcode processing *at all*.

He suggested that we should *not* call
Tcg2PhysicalPresenceLibProcessRequest() from BeforeConsole(). Because,
an "auth" console, i.e. one that does not depend on a 3rd party
driver, is *in general* impossible to guarantee. Instead we could opt
to trust 3rd party drivers, and use the "normal" console(s) in
AfterConsole(), in order to let the user confirm the PPI requests. It
will depend on the user to enable Secure Boot, so that the
trustworthiness of those 3rd party drivers is ensured. If an attacker
roots the guest OS from within, queues some TPM2 PPI requests, and
also modifies drivers on the EFI system partition and/or in GPU option
ROMs (?), then those drivers will not load after guest reboot, and
thus the dependent console(s) won't be used for confirming the PPI
requests.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 2 ++
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c  | 6 ++
 2 files changed, 8 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 27789b7377bc..4b72c44bcf0a 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -38,6 +38,7 @@ [Packages]
   IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
   SourceLevelDebugPkg/SourceLevelDebugPkg.dec
   OvmfPkg/OvmfPkg.dec
+  SecurityPkg/SecurityPkg.dec
 
 [LibraryClasses]
   BaseLib
@@ -56,6 +57,7 @@ [LibraryClasses]
   LoadLinuxLib
   QemuBootOrderLib
   UefiLib
+  Tcg2PhysicalPresenceLib
 
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 004b753f4d26..aa036bbba567 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 //
@@ -1410,6 +1411,11 @@ PlatformBootManagerAfterConsole (
   //
   PciAcpiInitialization ();
 
+  //
+  // Process TPM PPI request
+  //
+  Tcg2PhysicalPresenceLibProcessRequest (NULL);
+
   //
   // Process QEMU's -kernel command line option
   //
-- 
2.17.0.253.g3dd125b46d

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 1/4] OvmfPkg: add Tcg2PhysicalPresenceLibNull when !TPM2_ENABLE

2018-05-18 Thread marcandre . lureau 
From: Marc-André Lureau 

This NULL library will let us call
Tcg2PhysicalPresenceLibProcessRequest() unconditionally from
BdsPlatform when building without TPM2_ENABLE.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau 
---
 OvmfPkg/OvmfPkgIa32.dsc

 |  2 ++
 OvmfPkg/OvmfPkgIa32X64.dsc 

 |  2 ++
 OvmfPkg/OvmfPkgX64.dsc 

 |  2 ++
 OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf 

 | 33 
 
EdkCompatibilityPkg/Foundation/Library/EdkIIGlueLib/Library/BaseLib/Ia32/CpuSleep.c
 => OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.c | 
20 ++--
 5 files changed, 49 insertions(+), 10 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 2d6c4c4615b6..6c361b73cd55 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -208,6 +208,8 @@ [LibraryClasses]
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
   
Tcg2PhysicalPresenceLib|SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.inf
   
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
+!else
+  
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
 !endif
 
 [LibraryClasses.common]
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 43158c5f0627..62a6075a671d 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -213,6 +213,8 @@ [LibraryClasses]
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
   
Tcg2PhysicalPresenceLib|SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.inf
   
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
+!else
+  
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
 !endif
 
 [LibraryClasses.common]
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index d1fdf7c307c2..cbab1aa328c6 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -213,6 +213,8 @@ [LibraryClasses]
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
   
Tcg2PhysicalPresenceLib|SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.inf
   
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
+!else
+  
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
 !endif
 
 [LibraryClasses.common]
diff --git 
a/OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf 
b/OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
new file mode 100644
index ..92ce5f04b37f
--- /dev/null
+++ b/OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
@@ -0,0 +1,33 @@
+## @file
+#  NULL Tcg2PhysicalPresenceLib library instance
+#
+# Under SecurityPkg, the corresponding library instance will check and
+# execute TPM 2.0 request from OS or BIOS; the request may ask for user
+# confirmation before execution. This Null instance implements a no-op
+# Tcg2PhysicalPresenceLibProcessRequest(), without user interaction.
+#
+# Copyright (C) 2018, Red Hat, Inc.
+# Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD 
License
+# which accompanies this distribution. The full text of the license may be 
found at
+# http://opensource.org/licenses/bsd-license.php
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = DxeTcg2PhysicalPresenceLibNull
+  FILE_GUID  = 2A6BA243-DC22-42D8-9C3D-AE3728DC7AFA
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = Tcg2PhysicalPresenceLib|DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SAL_DRIVER UEFI_APPLICATION UEFI_DRIVER
+
+[Sources]
+  DxeTcg2PhysicalPresenceLib.c
+
+[Packages]
+  MdeModulePkg/MdeModulePkg.dec
+  SecurityPkg/SecurityPkg.dec
diff --git 
a/EdkCompatibilityPkg/Foundation/Library/EdkIIGlueLib/Library/BaseLib/Ia32/CpuSleep.c

[edk2] [PATCH v3 0/4] RFC: ovmf: Add support for TPM Physical Presence interface

2018-05-18 Thread marcandre . lureau 
From: Marc-André Lureau 

Hi,

The following series adds basic TPM PPI 1.3 support for OVMF-on-QEMU
with TPM2 (I haven't looked at TPM1, for lack of interest).

PPI test runs successfully with Windows 10 WHLK, despite the limited
number of supported funcions (tpm2_ppi_funcs table, in particular, no
function allows to manipulate Tcg2PhysicalPresenceFlags)

The way it works is relatively simple: a memory region is allocated by
QEMU to save PPI related variables. An ACPI interface is exposed by
QEMU to let the guest manipulate those. At boot, ovmf processes and
updates the PPI qemu region and request variables.

I build edk2 with:

$ build -DTPM2_ENABLE

I test with qemu & swtpm/libtpms (tpm2 branches, swtpm_setup.sh --tpm2
 --tpm-state tpmstatedir)

$ swtpm socket --tpmstate tpmstatedir --ctrl type=unixio,path=tpmsock
  --tpm2 &

$ qemu .. -chardev socket,id=chrtpm,path=tpmsock -tpmdev
  emulator,id=tpm0,chardev=chrtpm -device tpm-crb,tpmdev=tpm0

Github trees:
https://github.com/elmarco/edk2/tree/tpm-ppi
https://github.com/elmarco/qemu/tree/tpm-ppi

Thanks

v3: after Laszlo review
 - dropped DxeTcg2PhysicalPresenceLib.uni
 - removed mTpm2PPIFuncs static initialization, use hard-coded assignments
 - declared STATIC the functions that should be
 - fixed an OUT/IN decorator
 - use EFI_PROTOCOL_ERROR instead of EFI_INVALID_PARAMETER when PPI
   initialization fails
 - replaced EFI_D_INFO with DEBUG_INFO
 - added a check for mPpi address that it doesn't cross a page boundary
 - added a GetMemorySpaceDescriptor() check for memory type
 - declared *mPpi as volatile, to correct mmio access
 - a few more style changes
 - comments updated
 - some minor dead code/inclusion/defines removal
 - added a few r-b tags

v2:
 - style and commit message fixes

Marc-André Lureau (4):
  OvmfPkg: add Tcg2PhysicalPresenceLibNull when !TPM2_ENABLE
  OvmfPkg/IndustryStandard: add QemuTpm.h header
  OvmfPkg: add Tcg2PhysicalPresenceLibQemu
  OvmfPkg/PlatformBootManagerLib: process TPM PPI request

 OvmfPkg/OvmfPkgIa32.dsc   |   4 +-
 OvmfPkg/OvmfPkgIa32X64.dsc|   4 +-
 OvmfPkg/OvmfPkgX64.dsc|   4 +-
 .../PlatformBootManagerLib.inf|   2 +
 .../DxeTcg2PhysicalPresenceLib.inf|  33 +
 .../DxeTcg2PhysicalPresenceLib.inf|  46 +-
 OvmfPkg/Include/IndustryStandard/QemuTpm.h|  69 ++
 .../PlatformBootManagerLib/BdsPlatform.c  |   6 +
 .../DxeTcg2PhysicalPresenceLib.c  |  20 +-
 .../DxeTcg2PhysicalPresenceLib.c  | 919 ++
 .../PhysicalPresenceStrings.uni   |  33 +-
 11 files changed, 1081 insertions(+), 59 deletions(-)
 create mode 100644 
OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
 copy {SecurityPkg/Library/DxeTcg2PhysicalPresenceLib => 
OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu}/DxeTcg2PhysicalPresenceLib.inf 
(66%)
 create mode 100644 OvmfPkg/Include/IndustryStandard/QemuTpm.h
 copy 
EdkCompatibilityPkg/Foundation/Library/EdkIIGlueLib/Library/BaseLib/Ia32/CpuSleep.c
 => OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.c 
(55%)
 create mode 100644 
OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.c
 copy {SecurityPkg/Library/DxeTcg2PhysicalPresenceLib => 
OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu}/PhysicalPresenceStrings.uni (56%)

-- 
2.17.0.253.g3dd125b46d

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 2/4] OvmfPkg/IndustryStandard: add QemuTpm.h header

2018-05-18 Thread marcandre . lureau 
From: Marc-André Lureau 

Add some common macros and type definitions corresponding to the QEMU
TPM interface.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau 
Acked-by: Laszlo Ersek 
---
 OvmfPkg/Include/IndustryStandard/QemuTpm.h | 69 
 1 file changed, 69 insertions(+)

diff --git a/OvmfPkg/Include/IndustryStandard/QemuTpm.h 
b/OvmfPkg/Include/IndustryStandard/QemuTpm.h
new file mode 100644
index ..a342cbc347f1
--- /dev/null
+++ b/OvmfPkg/Include/IndustryStandard/QemuTpm.h
@@ -0,0 +1,69 @@
+/** @file
+  Macro and type definitions corresponding to the QEMU TPM interface.
+
+  Refer to "docs/specs/tpm.txt" in the QEMU source directory.
+
+  Copyright (C) 2018, Red Hat, Inc.
+  Copyright (c) 2018, IBM Corporation. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution. The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#ifndef __QEMU_TPM_H__
+#define __QEMU_TPM_H__
+
+#include 
+
+//
+// whether function is blocked by BIOS settings; bits 0, 1, 2
+//
+#define QEMU_TPM_PPI_FUNC_NOT_IMPLEMENTED (0 << 0)
+#define QEMU_TPM_PPI_FUNC_BIOS_ONLY   (1 << 0)
+#define QEMU_TPM_PPI_FUNC_BLOCKED (2 << 0)
+#define QEMU_TPM_PPI_FUNC_ALLOWED_USR_REQ (3 << 0)
+#define QEMU_TPM_PPI_FUNC_ALLOWED_USR_NOT_REQ (4 << 0)
+#define QEMU_TPM_PPI_FUNC_MASK(7 << 0)
+
+//
+// The following structure is shared between firmware and ACPI.
+//
+#pragma pack (1)
+typedef struct {
+  UINT8  Func[256];   // func
+  UINT8  In;  // ppin
+  UINT32 Ip;  // ppip
+  UINT32 Response;// pprp
+  UINT32 Request; // pprq
+  UINT32 RequestParameter;// pprm
+  UINT32 LastRequest; // lppr
+  UINT32 FRet;// fret
+  UINT8  Res1[0x40];  // res1
+  UINT8  NextStep;// next_step
+} QEMU_TPM_PPI;
+#pragma pack ()
+
+//
+// The following structure is for the fw_cfg etc/tpm/config file.
+//
+#pragma pack (1)
+typedef struct {
+  UINT32 PpiAddress;
+  UINT8  TpmVersion;
+  UINT8  PpiVersion;
+} QEMU_FWCFG_TPM_CONFIG;
+#pragma pack ()
+
+#define QEMU_TPM_VERSION_UNSPEC0
+#define QEMU_TPM_VERSION_1_2   1
+#define QEMU_TPM_VERSION_2 2
+
+#define QEMU_TPM_PPI_VERSION_NONE  0
+#define QEMU_TPM_PPI_VERSION_1_30  1
+
+#endif
-- 
2.17.0.253.g3dd125b46d

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] ArmVirtPkg, OvmfPkg: connect Virtio RNG devices again

2018-05-18 Thread Laszlo Ersek 
On 05/18/18 11:09, Ard Biesheuvel wrote:
> On 18 May 2018 at 08:20, Laszlo Ersek  wrote:
>> Repo:   https://github.com/lersek/edk2.git
>> Branch: connect_vrng_bz1579518
>>
>> This is a fix for another regression from the March 2018 series
>>
>>   [edk2] [PATCH 0/6] OvmfPkg, ArmVirtQemu: leaner platform BDS policy
>>  for connecting devices
>>
>> Turns out EfiBootManagerConnectAll() used to connect devices one doesn't
>> really think about every day. I stumbled upon this when an aarch64 guest
>> kernel printed
>>
>>> EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
>>
>> whereas I had just looked at the domain XML and seen the virtio-rng
>> device model in it.
>>
>> Tested extensively as described in
>>  and
>> .
>>
>> Cc: Ard Biesheuvel 
>> Cc: Jordan Justen 
>>
>> Thanks,
>> Laszlo
>>
>> Laszlo Ersek (2):
>>   ArmVirtPkg/PlatformBootManagerLib: connect Virtio RNG devices again
>>   OvmfPkg/PlatformBootManagerLib: connect Virtio RNG devices again
>>
> 
> Thanks for spotting that
> 
> Reviewed-by: Ard Biesheuvel 

Thank you! Commit range 333f32ec23dd..7ebad830d6ab.

Cheers
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v2 0/5] Remove X86 ASM and S files

2018-05-18 Thread Laszlo Ersek 
Hi Limint,

On 05/18/18 11:32, Liming Gao wrote:
> For IA32 and X64, NASM has replaced ASM and S files.
> 1. Remove ASM from all modules.
> 2. Remove S files from the drivers only.
> 3. https://bugzilla.tianocore.org/show_bug.cgi?id=881
> After NASM is updated, S files can be removed from Library.
> 
> V2:
> Update commit message.
> 
> The patch set are in https://github.com/lgao4/edk2/tree/AsmClean

the commit message of v2 5/5 looks good to me -- if those commit message
changes are the only ones on the patch, relative to v1 5/5 [*], then
please add my

Reviewed-by: Laszlo Ersek 

to v2 5/5.

[*]
be509a29-1f64-79b6-9c75-64f88d29322c@redhat.com">http://mid.mail-archive.com/be509a29-1f64-79b6-9c75-64f88d29322c@redhat.com

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [staging/dynamictables PATCH v2] Update Readme.md to reflect ACPICA compiler update

2018-05-18 Thread Sami Mujawar 
The ACPICA iASL compiler has been enhanced to support the
generation of an AML hex file which is required by the
Dynamic Tables Framework. The patch for this enhancement
has been integrated in the ACPICA repository. Therefore
the Prerequisites section in the Readme has been updated
accordingly.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---

The changes can be seen at 
https://github.com/samimujawar/edk2-staging/tree/258_reflect_acpica_compiler_enhancement_v2

Notes:
v2:
- Add patch commit date and info about presentation.  [LEIF]
- Updated Readme.md to add date for referencing ACPICA patch.
  Also annotated the UEFI presentation.   [SAMI]

v1:
- Update ACPICA iAsl compiler usage guidelines.   [SAMI]

 Readme.md | 25 +---
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/Readme.md b/Readme.md
index 
b72efca18e8ab5de17cab06f0a1a0725991256d4..6501623503d6ec8ef4840aebc70561d44cf1ca12
 100644
--- a/Readme.md
+++ b/Readme.md
@@ -87,9 +87,9 @@ contains the Dynamic Tables Framework.
 ### ACPICA iASL compiler
 The RAW table generator, used to process the DSDT/SSDT files depends on
 the iASL compiler to convert the DSDT/SSDT ASL files to a C array containing
-the hex AML code. The current implementation of the iASL compiler does not
-support generation of a C header file suitable for including from a C source
-file.
+the hex AML code. The "-tc" option of the iASL compiler has been enhanced to
+support generation of an AML hex file (C header) with a unique symbol name
+so that it is suitable for inclusion from a C source file.
 
 Related Links
 --
@@ -135,16 +135,23 @@ or
 
 Prerequisites
 -
-ACPICA iASL compiler with support for generating a C header file.
+ACPICA iASL compiler with the enhanced "-tc" option to support generation of
+AML hex (C header) files with unique symbol names.
 
-A patch ***'Modify hex AML C header file generation'***, to enable
-this support has been submitted to the ACPICA source repository.
-
+A patch *'[iASL: Enhance the -tc option (create AML hex file in 
C)](https://github.com/acpica/acpica/commit/f9a88a4c1cd020b6a5475d63b29626852a0b5f37)'*,
 dated 16 March 2018 (2018-03-16),
+to enable this support has been integrated to the ACPICA source repository.
+
+Ensure that the iASL compiler used for building *Dynamic Tables Framework* has 
this feature enabled.
+
+This feature was made available in the *ACPICA Compiler update
+[Version 20180508](https://www.acpica.org/node/156)*, dated 8 May 2018 
(2018-05-08).
 
 Documentation
 -
-A description document is in preparation, and should be available in the
-near future.
+
+Refer to the following presentation from *UEFI Plugfest Seattle 2018*:
+
+[Dynamic Tables Framework: A Step Towards Automatic Generation of Advanced 
Configuration and Power Interface (ACPI) & System Management BIOS (SMBIOS) 
Tables – Sami Mujawar 
(Arm).](http://www.uefi.org/sites/default/files/resources/Arm_Dynamic%20Tables%20Framework%20A%20Step%20Towards%20Automatic%20Generation%20of%20Advanced%20Configuration%20and%20Power%20Interface%20%28ACPI%29%20%26%20System%20Management%20BIOS%20%28SMBIOS%29%20Tables%20_0.pdf)
 
 Miscellaneous
 -
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch v2 0/5] Remove X86 ASM and S files

2018-05-18 Thread Liming Gao 
For IA32 and X64, NASM has replaced ASM and S files.
1. Remove ASM from all modules.
2. Remove S files from the drivers only.
3. https://bugzilla.tianocore.org/show_bug.cgi?id=881
After NASM is updated, S files can be removed from Library.

V2:
Update commit message.

The patch set are in https://github.com/lgao4/edk2/tree/AsmClean

Liming Gao (5):
  IntelFrameworkModulePkg: Remove X86 ASM and S files
  MdeModulePkg: Remove X86 ASM and S files
  MdePkg: Remove X86 ASM and S files
  SourceLevelDebugPkg: Remove X86 ASM and S files
  UefiCpuPkg: Remove X86 ASM and S files

 .../Csm/LegacyBiosDxe/IA32/InterruptTable.S|  67 ---
 .../Csm/LegacyBiosDxe/IA32/InterruptTable.asm  |  73 ---
 .../Csm/LegacyBiosDxe/LegacyBiosDxe.inf|   4 -
 .../Csm/LegacyBiosDxe/X64/InterruptTable.S |  72 ---
 .../Csm/LegacyBiosDxe/X64/InterruptTable.asm   |  71 ---
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   2 -
 MdeModulePkg/Core/DxeIplPeim/Ia32/IdtVectorAsm.S   |  80 ---
 MdeModulePkg/Core/DxeIplPeim/Ia32/IdtVectorAsm.asm |  88 ---
 .../BootScriptExecutorDxe.inf  |   4 -
 .../Acpi/BootScriptExecutorDxe/IA32/S3Asm.S|  66 ---
 .../Acpi/BootScriptExecutorDxe/IA32/S3Asm.asm  |  71 ---
 .../Acpi/BootScriptExecutorDxe/X64/S3Asm.S | 130 -
 .../Acpi/BootScriptExecutorDxe/X64/S3Asm.asm   | 135 -
 MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf   |   2 -
 .../Universal/CapsulePei/X64/PageFaultHandler.S|  81 ---
 .../Universal/CapsulePei/X64/PageFaultHandler.asm  |  87 ---
 .../Universal/DebugSupportDxe/DebugSupportDxe.inf  |   4 -
 .../Universal/DebugSupportDxe/Ia32/AsmFuncs.S  | 407 --
 .../Universal/DebugSupportDxe/Ia32/AsmFuncs.asm| 509 --
 .../Universal/DebugSupportDxe/X64/AsmFuncs.S   | 551 ---
 .../Universal/DebugSupportDxe/X64/AsmFuncs.asm | 596 -
 MdeModulePkg/Universal/EbcDxe/EbcDebugger.inf  |   4 -
 MdeModulePkg/Universal/EbcDxe/EbcDxe.inf   |   4 -
 MdeModulePkg/Universal/EbcDxe/Ia32/EbcLowLevel.S   |  83 ---
 MdeModulePkg/Universal/EbcDxe/Ia32/EbcLowLevel.asm | 207 ---
 MdeModulePkg/Universal/EbcDxe/X64/EbcLowLevel.S| 147 -
 MdeModulePkg/Universal/EbcDxe/X64/EbcLowLevel.asm  | 246 -
 MdePkg/Library/BaseCpuLib/BaseCpuLib.inf   |   4 -
 MdePkg/Library/BaseCpuLib/Ia32/CpuFlushTlb.asm |  40 --
 MdePkg/Library/BaseCpuLib/Ia32/CpuSleep.asm|  39 --
 MdePkg/Library/BaseCpuLib/X64/CpuFlushTlb.asm  |  38 --
 MdePkg/Library/BaseCpuLib/X64/CpuSleep.asm |  37 --
 .../BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf  |   2 -
 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.asm  | 141 -
 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.asm   | 127 -
 MdePkg/Library/BaseLib/BaseLib.inf | 246 -
 MdePkg/Library/BaseLib/Ia32/ARShiftU64.asm |  48 --
 MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.asm  |  40 --
 MdePkg/Library/BaseLib/Ia32/CpuId.asm  |  66 ---
 MdePkg/Library/BaseLib/Ia32/CpuIdEx.asm|  68 ---
 MdePkg/Library/BaseLib/Ia32/CpuPause.asm   |  40 --
 MdePkg/Library/BaseLib/Ia32/DisableCache.asm   |  45 --
 MdePkg/Library/BaseLib/Ia32/DisableInterrupts.asm  |  40 --
 MdePkg/Library/BaseLib/Ia32/DisablePaging32.asm|  57 --
 MdePkg/Library/BaseLib/Ia32/DivU64x32.asm  |  46 --
 MdePkg/Library/BaseLib/Ia32/DivU64x32Remainder.asm |  51 --
 MdePkg/Library/BaseLib/Ia32/DivU64x64Remainder.asm |  92 
 MdePkg/Library/BaseLib/Ia32/EnableCache.asm|  45 --
 .../BaseLib/Ia32/EnableDisableInterrupts.asm   |  41 --
 MdePkg/Library/BaseLib/Ia32/EnableInterrupts.asm   |  40 --
 MdePkg/Library/BaseLib/Ia32/EnablePaging32.asm |  57 --
 MdePkg/Library/BaseLib/Ia32/EnablePaging64.asm |  68 ---
 MdePkg/Library/BaseLib/Ia32/FlushCacheLine.asm |  55 --
 MdePkg/Library/BaseLib/Ia32/FxRestore.asm  |  42 --
 MdePkg/Library/BaseLib/Ia32/FxSave.asm |  42 --
 MdePkg/Library/BaseLib/Ia32/Invd.asm   |  40 --
 MdePkg/Library/BaseLib/Ia32/LRotU64.asm|  51 --
 MdePkg/Library/BaseLib/Ia32/LShiftU64.asm  |  48 --
 MdePkg/Library/BaseLib/Ia32/LongJump.asm   |  46 --
 MdePkg/Library/BaseLib/Ia32/ModU64x32.asm  |  45 --
 MdePkg/Library/BaseLib/Ia32/Monitor.asm|  45 --
 MdePkg/Library/BaseLib/Ia32/MultU64x32.asm |  43 --
 MdePkg/Library/BaseLib/Ia32/MultU64x64.asm |  47 --
 MdePkg/Library/BaseLib/Ia32/Mwait.asm  |  43 --
 MdePkg/Library/BaseLib/Ia32/RRotU64.asm|  51 --
 MdePkg/Library/BaseLib/Ia32/RShiftU64.asm  |  48 --
 MdePkg/Library/BaseLib/Ia32/RdRand.asm |  94 
 MdePkg/Library/BaseLib/Ia32/ReadCr0.asm|  40 --
 MdePkg/Library/BaseLib/Ia32/ReadCr2.asm|  40 --
 MdePkg/Library/BaseLib/Ia32/ReadCr3.asm|  40 --
 MdePkg/Library/BaseLib/Ia32/ReadCr4.asm

[edk2] reg: EDK2 - HTTP Boot Image Validation

2018-05-18 Thread Sivaraman Nainar 
Hello all,
When HTTP Boot performed the code checking if the Image type as EFI ISO and 
IMG. If not the boot not proceeding when the content type is as "Content-type: 
text/plain".
https://github.com/tianocore/edk2/blob/master/NetworkPkg/HttpBootDxe/HttpBootSupport.c
 (HttpBootCheckImageType())

But as per RFC it described below. 
https://tools.ietf.org/html/rfc2616#section-7.2.1:
"If and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URI used to identify the
resource."
Can you please comment if this need to be addressed such a way we can skip the 
validation of image types.
-Siva
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] reg: EDK2 - HTTP Boot

2018-05-18 Thread Sivaraman Nainar 
Hello All,
There is an observation found during HTTP Boot that, when HTTP 1.1 server does 
not support keep-alives, the system sometimes failed boot when connections are 
not persistent.
RFC 2616 section 8.2.1 says "HTTP/1.1 servers SHOULD maintain persistent 
connections and use TCP's flow control mechanisms to resolve temporary 
overloads, rather than terminating connections with the expectation that 
clients will retry. The latter technique can exacerbate network congestion."
https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html
So the understanding here is Server should not assume or expect that client 
will retry. Would like to confirm if the EDK II implementation expects the 
Server should persistent connection.
-Siva
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] ArmVirtPkg, OvmfPkg: connect Virtio RNG devices again

2018-05-18 Thread Ard Biesheuvel 
On 18 May 2018 at 08:20, Laszlo Ersek  wrote:
> Repo:   https://github.com/lersek/edk2.git
> Branch: connect_vrng_bz1579518
>
> This is a fix for another regression from the March 2018 series
>
>   [edk2] [PATCH 0/6] OvmfPkg, ArmVirtQemu: leaner platform BDS policy
>  for connecting devices
>
> Turns out EfiBootManagerConnectAll() used to connect devices one doesn't
> really think about every day. I stumbled upon this when an aarch64 guest
> kernel printed
>
>> EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
>
> whereas I had just looked at the domain XML and seen the virtio-rng
> device model in it.
>
> Tested extensively as described in
>  and
> .
>
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
>
> Thanks,
> Laszlo
>
> Laszlo Ersek (2):
>   ArmVirtPkg/PlatformBootManagerLib: connect Virtio RNG devices again
>   OvmfPkg/PlatformBootManagerLib: connect Virtio RNG devices again
>

Thanks for spotting that

Reviewed-by: Ard Biesheuvel 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] How to retrieve HII form's default value

2018-05-18 Thread Gao, Liming 
Intel provides FCE tool. It can parse the generated BIOS image and output the 
default value for every HII question. You can try it. 

Here is the latest version 
https://firmware.intel.com/sites/default/files/2018-WW13-FCE.34-Release.zip

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>methavanitpong.pi...@socionext.com
>Sent: Friday, May 18, 2018 10:09 AM
>To: edk2-devel@lists.01.org
>Cc: ard.biesheu...@linaro.org
>Subject: [edk2] How to retrieve HII form's default value
>
>Hi,
>
>I'm working on changing SynQuacer/PlatformDxe initial HII configuration.
>
>In the current implementation, SynQuacerPlatformSettings HII variable
>doesn't set its initial value from PcdPlatfromSettings.
>
>* PcdPlatformSettings is initially set with value in dsc at build time
>
>* https://github.com/tianocore/edk2-
>platforms/blob/master/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
>#L439
>
>* SynQuacerPlatformSettings is initially set to zeros at run time
>
>* https://github.com/tianocore/edk2-
>platforms/blob/master/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pl
>atformDxe.c#L246
>
>They are unsync, but are both initially assigned to 0 independently.
>
>What I want to do with this issue is
>
>* Set initial SynQuacerPlatformSettings value from its
>  SYNQUACER_PLATFORM_FORMSET_GUID form's default value
>* Set initial PcdPlatformSettings value from its
>  SYNQUACER_PLATFORM_FORMSET_GUID form's default value
>
>Could anyone give me an advice on retrieving default value from a HII form
>and assign in C and DSC files?
>
>
>Thanks,
>--
>Pipat Methavanitpong
>Software Developer, S-Project 3
>Socionext Inc.
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms/devel-IntelAtomProcessorE3900] Platform/ReadMe.MD

2018-05-18 Thread Guo, Mang 
Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: Guo Mang 
---
 Platform/ReadMe.MD | 186 +
 1 file changed, 175 insertions(+), 11 deletions(-)

diff --git a/Platform/ReadMe.MD b/Platform/ReadMe.MD
index 9f5ae85..5381de3 100644
--- a/Platform/ReadMe.MD
+++ b/Platform/ReadMe.MD
@@ -1,19 +1,183 @@
-#   Intel Atom(R) Processor E3900 Series Platforms
+# UEFI Firmware Project for Intel Atom(R) Processor E3900 Series 
platforms
 
-This codebase is designed for Intel Atom(R) Processor E3900 Series 
platforms.(https://www.intel.com/content/www/us/en/embedded/products/apollo-lake/overview.html)
 (formerly Apollo Lake).
+This codebase is designed for Intel Atom(R) Processor E3900 Series platforms 
(formerly Apollo Lake). 
https://www.intel.com/content/www/us/en/embedded/products/apollo-lake/overview.html
 
-Contributions to this open source project are covered by the
-[TianoCore Contribution Agreement 1.1](Contributions.txt)
+## Download Official Releases
 
-The majority of the content in the this open source project uses a
-[BSD 2-Clause License](License.txt).
+Please refer to the release notes to download official releases (source code 
and binary images). Information is available at 
https://firmware.intel.com/projects/minnowboard3
 
-The maintainers are listed in [Maintainers.txt](Maintainers.txt).
+## Download the Latest Source Code
 
-# Resources
+Official source releases are recommended since they have passed stability 
testing. Use the directions below to download the latest code.
+```
+1. Create a new folder (directory) on the root of your local development 
machine
+   for use as your workspace (this example uses "C:\MyWorkspace").
 
-* [devel-IntelAtomProcessorE3900](Platform/ReadMe.MD) -- Instructions
+2. Get devel-IntelAtomProcessorE3900 branch from GitHub*
+   git clone https://github.com/tianocore/edk2-platforms.git -b 
devel-IntelAtomProcessorE3900
 
-* http://minnowboard.org/ -- Platform Information.
+3. Get EDK II packages
+   git clone -b vUDK2018 https://github.com/tianocore/edk2.git
+
+4. Get the Intel(R) Firmware Support Package(Intel(R) FSP)
+   1.git clone -b ApolloLake https://github.com/IntelFsp/FSP.git
+   2.cd FSP
+   3.git checkout a57c66616e78b471515a1e1862796bf61d3824d8
+   4.Copy the ApolloLakeFspBinPkg to the folder
+ "C:\MyWorkspace\edk2-platforms\Silicon\BroxtonSoC\BroxtonFspPkg".
+
+5. Install UEFI UNDI driver:
+   1.Install UEFI UNDI driver for Intel i210 Ethernet Controller
+   Download PREBOOT.EXE Version 21.1 from the "Intel® Ethernet Connections 
+   Boot Utility, Preboot Images, and EFI Drivers" page.
+ 
https://downloadcenter.intel.com/download/19186/Intel-Ethernet-Connections-Boot-Utility-Preboot-Images-and-EFI-Drivers
+
+   Windows user:
+   a. Install PREBOOT.EXE into the default folder (C:\Intel21.1).
+   b. Copy the UEFI x64 PCI-E gigabit driver 
(C:\Intel21.1\APPS\EFI\EFIx64\E7320X3.EFI) 
+  to the platform package directory below, create the folder if it does 
not exist:
+  
"C:\MyWorkspace\edk2-platforms\Platform\BroxtonPlatformPkg\Common\Binaries\UNDI\I210PcieUndiDxe"
+
+   Linux user:
+   a. Use command "unzip PREBOOT.EXE" to extract UEFI x64 PCI-E gigabit driver 
+  (preboot/APPS/EFI/EFIx64/E7320X3.EFI)
+   b. Copy E7320X3.EFI to platform package directory below, create the folder
+  if it does not exist:
+  
"~/src/MyWorkspace/edk2-platforms/Platform/BroxtonPlatformPkg/Common/Binaries/UNDI/I210PcieUndiDxe"
+
+   2.Install UNDI driver for AX88179 USB-to-LAN adapter
+   a. Download AX88179_178A_UEFI_V2.8.0.zip from 
http://www.asix.com.tw/FrootAttach/driver/AX88179_178A_UEFI_V2.8.0.zip.
+   b. Unzip AX88179_178A_UEFI_V2.8.0.zip to get 
AX88179_178A_UEFI_V2.8.0_X64.efi and AX88179_178A_UEFI_V2.8.0_IA32.efi.
+   C. Copy AX88179_178A_UEFI_V2.8.0_X64.efi and 
AX88179_178A_UEFI_V2.8.0_IA32.efi to below directory, create the folder
+  if it does not exist:
+  Windows user: 
"C:\MyWorkspace\edk2-platforms\Platform\BroxtonPlatformPkg\Common\Binaries\UNDI\AX88179\"
+  Linux user: 
"~/src/MyWorkspace/edk2-platforms/Platform/BroxtonPlatformPkg/Common/Binaries/UNDI/AX88179/"
+
+6. Follow the instructions found in the "OpenSSL-HOWTO.txt" file located in 
the Workspace
+   (e.g. "C:\MyWorkspace\edk2\CryptoPkg\Library\OpensslLib\OpenSSL-HOWTO.txt")
+   to install the OpenSSL* source code and enable the CryptoPkg module.   
+
+7. Download "IntelAtomE3900-0.70-Binary.Objects.zip" Binary Object Modules
+   a. Download the "IntelAtomE3900-0.70-Binary.Objects.zip" from the project 
page:
+  https://firmware.intel.com/projects/IntelAtomProcessorE3900
+
+   b. Unzip and copy the folders into the directory below, and create the 
folder if it does not exist:
+  "C:\MyWorkspace\edk2-platforms\Platform\BroxtonPlatformPkg\Board\"
+```
+
+## **Windows Build Instructions**
+
+### Pre-requisites
+
+* Microsoft Visual Studio
+  - Install C

[edk2] [PATCH 0/2] ArmVirtPkg, OvmfPkg: connect Virtio RNG devices again

2018-05-18 Thread Laszlo Ersek 
Repo:   https://github.com/lersek/edk2.git
Branch: connect_vrng_bz1579518

This is a fix for another regression from the March 2018 series

  [edk2] [PATCH 0/6] OvmfPkg, ArmVirtQemu: leaner platform BDS policy
 for connecting devices

Turns out EfiBootManagerConnectAll() used to connect devices one doesn't
really think about every day. I stumbled upon this when an aarch64 guest
kernel printed

> EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied

whereas I had just looked at the domain XML and seen the virtio-rng
device model in it.

Tested extensively as described in
 and
.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 

Thanks,
Laszlo

Laszlo Ersek (2):
  ArmVirtPkg/PlatformBootManagerLib: connect Virtio RNG devices again
  OvmfPkg/PlatformBootManagerLib: connect Virtio RNG devices again

 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 129 

 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   1 +
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 105 

 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h |   1 +
 4 files changed, 236 insertions(+)

-- 
2.14.1.3.gb7cf6e02401b

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/2] OvmfPkg/PlatformBootManagerLib: connect Virtio RNG devices again

2018-05-18 Thread Laszlo Ersek 
Virtio RNG devices are never boot devices, so in commit 245c643cc8b7 we
stopped connecting them. This is a problem because an OS boot loader may
depend on EFI_RNG_PROTOCOL to seed the OS's RNG.

Connect Virtio RNG devices again. And, while commit 245c643cc8b7 removed
that from PlatformBootManagerAfterConsole(), reintroduce it now to
PlatformBootManagerBeforeConsole() -- this way Driver options launched
between both functions may access EFI_RNG_PROTOCOL too.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Fixes: 245c643cc8b73240c3b88cb55b2911b285a8c10d
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1579518
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h |   1 +
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 105 
 2 files changed, 106 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
index 97ffbb514825..4948ca6518ec 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
@@ -30,6 +30,7 @@ Abstract:
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 004b753f4d26..5d4d323d7306 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -318,6 +318,15 @@ ConnectRootBridge (
   IN VOID*Context
   );
 
+STATIC
+EFI_STATUS
+EFIAPI
+ConnectVirtioPciRng (
+  IN EFI_HANDLE Handle,
+  IN VOID   *Instance,
+  IN VOID   *Context
+  );
+
 STATIC
 VOID
 SaveS3BootScript (
@@ -399,6 +408,13 @@ PlatformBootManagerBeforeConsole (
   ASSERT_RETURN_ERROR (PcdStatus);
 
   PlatformRegisterOptionsAndKeys ();
+
+  //
+  // Install both VIRTIO_DEVICE_PROTOCOL and (dependent) EFI_RNG_PROTOCOL
+  // instances on Virtio PCI RNG devices.
+  //
+  VisitAllInstancesOfProtocol (, ConnectVirtioPciRng,
+NULL);
 }
 
 
@@ -427,6 +443,95 @@ ConnectRootBridge (
 }
 
 
+STATIC
+EFI_STATUS
+EFIAPI
+ConnectVirtioPciRng (
+  IN EFI_HANDLE Handle,
+  IN VOID   *Instance,
+  IN VOID   *Context
+  )
+{
+  EFI_PCI_IO_PROTOCOL *PciIo;
+  EFI_STATUS  Status;
+  UINT16  VendorId;
+  UINT16  DeviceId;
+  UINT8   RevisionId;
+  BOOLEAN Virtio10;
+  UINT16  SubsystemId;
+
+  PciIo = Instance;
+
+  //
+  // Read and check VendorId.
+  //
+  Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16, PCI_VENDOR_ID_OFFSET,
+1, );
+  if (EFI_ERROR (Status)) {
+goto Error;
+  }
+  if (VendorId != VIRTIO_VENDOR_ID) {
+return EFI_SUCCESS;
+  }
+
+  //
+  // Read DeviceId and RevisionId.
+  //
+  Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16, PCI_DEVICE_ID_OFFSET,
+1, );
+  if (EFI_ERROR (Status)) {
+goto Error;
+  }
+  Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint8, PCI_REVISION_ID_OFFSET,
+1, );
+  if (EFI_ERROR (Status)) {
+goto Error;
+  }
+
+  //
+  // From DeviceId and RevisionId, determine whether the device is a
+  // modern-only Virtio 1.0 device. In case of Virtio 1.0, DeviceId can
+  // immediately be restricted to VIRTIO_SUBSYSTEM_ENTROPY_SOURCE, and
+  // SubsystemId will only play a sanity-check role. Otherwise, DeviceId can
+  // only be sanity-checked, and SubsystemId will decide.
+  //
+  if (DeviceId == 0x1040 + VIRTIO_SUBSYSTEM_ENTROPY_SOURCE &&
+  RevisionId >= 0x01) {
+Virtio10 = TRUE;
+  } else if (DeviceId >= 0x1000 && DeviceId <= 0x103F && RevisionId == 0x00) {
+Virtio10 = FALSE;
+  } else {
+return EFI_SUCCESS;
+  }
+
+  //
+  // Read and check SubsystemId as dictated by Virtio10.
+  //
+  Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16,
+PCI_SUBSYSTEM_ID_OFFSET, 1, );
+  if (EFI_ERROR (Status)) {
+goto Error;
+  }
+  if ((Virtio10 && SubsystemId >= 0x40) ||
+  (!Virtio10 && SubsystemId == VIRTIO_SUBSYSTEM_ENTROPY_SOURCE)) {
+Status = gBS->ConnectController (
+Handle, // ControllerHandle
+NULL,   // DriverImageHandle -- connect all drivers
+NULL,   // RemainingDevicePath -- produce all child handles
+FALSE   // Recursive -- don't follow child handles
+);
+if (EFI_ERROR (Status)) {
+  goto Error;
+}
+  }
+  return EFI_SUCCESS;
+
+Error:
+  DEBUG ((DEBUG_ERROR, "%a: %r\n", __FUNCTION__, Status));
+  return Status;
+}
+
+
 /**
   Add IsaKeyboard to ConIn; add IsaSerial to ConOut, ConIn, ErrOut.
 
-- 
2.14.1.3.gb7cf6e02401b

___
edk2-devel mailing list
edk2-devel@lists.01.org

[edk2] [PATCH 1/2] ArmVirtPkg/PlatformBootManagerLib: connect Virtio RNG devices again

2018-05-18 Thread Laszlo Ersek 
Virtio RNG devices are never boot devices, so in commit ff1d0fbfbaec we
stopped connecting them. This is a problem because an OS boot loader may
depend on EFI_RNG_PROTOCOL to seed the OS's RNG.

Connect Virtio RNG devices again. And, while commit ff1d0fbfbaec removed
that from PlatformBootManagerAfterConsole(), reintroduce it now to
PlatformBootManagerBeforeConsole() -- this way Driver options launched
between both functions may access EFI_RNG_PROTOCOL too.

Cc: Ard Biesheuvel 
Fixes: ff1d0fbfbaec55038ccf888759588fa4e21516f4
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1579518
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   1 +
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 129 

 2 files changed, 130 insertions(+)

diff --git 
a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 1e22f8bb38ef..d6c1ef95dc44 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -83,3 +83,4 @@ [Protocols]
   gEfiLoadedImageProtocolGuid
   gEfiPciRootBridgeIoProtocolGuid
   gEfiSimpleFileSystemProtocolGuid
+  gVirtioDeviceProtocolGuid
diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
index 5d5e51d8c870..62cce6a01e1a 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -16,6 +16,7 @@
 **/
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -260,6 +262,121 @@ IsPciDisplay (
 }
 
 
+/**
+  This FILTER_FUNCTION checks if a handle corresponds to a Virtio RNG device at
+  the VIRTIO_DEVICE_PROTOCOL level.
+**/
+STATIC
+BOOLEAN
+EFIAPI
+IsVirtioRng (
+  IN EFI_HANDLE   Handle,
+  IN CONST CHAR16 *ReportText
+  )
+{
+  EFI_STATUS Status;
+  VIRTIO_DEVICE_PROTOCOL *VirtIo;
+
+  Status = gBS->HandleProtocol (Handle, ,
+  (VOID**));
+  if (EFI_ERROR (Status)) {
+return FALSE;
+  }
+  return (BOOLEAN)(VirtIo->SubSystemDeviceId ==
+   VIRTIO_SUBSYSTEM_ENTROPY_SOURCE);
+}
+
+
+/**
+  This FILTER_FUNCTION checks if a handle corresponds to a Virtio RNG device at
+  the EFI_PCI_IO_PROTOCOL level.
+**/
+STATIC
+BOOLEAN
+EFIAPI
+IsVirtioPciRng (
+  IN EFI_HANDLE   Handle,
+  IN CONST CHAR16 *ReportText
+  )
+{
+  EFI_STATUS  Status;
+  EFI_PCI_IO_PROTOCOL *PciIo;
+  UINT16  VendorId;
+  UINT16  DeviceId;
+  UINT8   RevisionId;
+  BOOLEAN Virtio10;
+  UINT16  SubsystemId;
+
+  Status = gBS->HandleProtocol (Handle, ,
+  (VOID**));
+  if (EFI_ERROR (Status)) {
+return FALSE;
+  }
+
+  //
+  // Read and check VendorId.
+  //
+  Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16, PCI_VENDOR_ID_OFFSET,
+1, );
+  if (EFI_ERROR (Status)) {
+goto PciError;
+  }
+  if (VendorId != VIRTIO_VENDOR_ID) {
+return FALSE;
+  }
+
+  //
+  // Read DeviceId and RevisionId.
+  //
+  Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16, PCI_DEVICE_ID_OFFSET,
+1, );
+  if (EFI_ERROR (Status)) {
+goto PciError;
+  }
+  Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint8, PCI_REVISION_ID_OFFSET,
+1, );
+  if (EFI_ERROR (Status)) {
+goto PciError;
+  }
+
+  //
+  // From DeviceId and RevisionId, determine whether the device is a
+  // modern-only Virtio 1.0 device. In case of Virtio 1.0, DeviceId can
+  // immediately be restricted to VIRTIO_SUBSYSTEM_ENTROPY_SOURCE, and
+  // SubsystemId will only play a sanity-check role. Otherwise, DeviceId can
+  // only be sanity-checked, and SubsystemId will decide.
+  //
+  if (DeviceId == 0x1040 + VIRTIO_SUBSYSTEM_ENTROPY_SOURCE &&
+  RevisionId >= 0x01) {
+Virtio10 = TRUE;
+  } else if (DeviceId >= 0x1000 && DeviceId <= 0x103F && RevisionId == 0x00) {
+Virtio10 = FALSE;
+  } else {
+return FALSE;
+  }
+
+  //
+  // Read and check SubsystemId as dictated by Virtio10.
+  //
+  Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16,
+PCI_SUBSYSTEM_ID_OFFSET, 1, );
+  if (EFI_ERROR (Status)) {
+goto PciError;
+  }
+  if (Virtio10 && SubsystemId >= 0x40) {
+return TRUE;
+  }
+  if (!Virtio10 && SubsystemId == VIRTIO_SUBSYSTEM_ENTROPY_SOURCE) {
+return TRUE;
+  }
+  return FALSE;
+
+PciError:
+  DEBUG ((DEBUG_ERROR, "%a: %s: %r\n", __FUNCTION__, ReportText, Status));
+  return FALSE;
+}
+
+
 /**
   This CALLBACK_FUNCTION attempts to connect a handle non-recursively, asking
   the matching driver to produce all

[edk2] [patch] IntelFrameworkPkg/UefiLib: Fix build fail caused by commit b6d5def2fa

2018-05-18 Thread Dandan Bi 
In commit b6d5def2faf56334128ea2f056356d7e3852831e
when adding 'OUT' decorator for the parameter in AddUnicodeString(),
it delete the function name by mistake. This patch is to fix this
issue.

CC: Marvin Haeuser 
CC: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c 
b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c
index 61a32e29760..443a7391721 100644
--- a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c
+++ b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c
@@ -863,10 +863,11 @@ LookupUnicodeString2 (
   member of SupportedLanguages.
 
 **/
 EFI_STATUS
 EFIAPI
+AddUnicodeString (
   IN CONST CHAR8   *Language,
   IN CONST CHAR8   *SupportedLanguages,
   IN OUT EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
   IN CONST CHAR16  *UnicodeString
   )
-- 
2.14.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel