Re: [edk2] [PATCH] MdePkg/WSMT.h: update header comment to use official URL link.

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Yao, Jiewen 
Sent: Friday, May 20, 2016 8:58 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Gao, Liming 

Subject: [PATCH] MdePkg/WSMT.h: update header comment to use official URL link.

Update WSMT table link to official MSDN URL.

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdePkg/Include/IndustryStandard/WindowsSmmSecurityMitigationTable.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/MdePkg/Include/IndustryStandard/WindowsSmmSecurityMitigationTable.h 
b/MdePkg/Include/IndustryStandard/WindowsSmmSecurityMitigationTable.h
index bfbcf81..2b0a644 100644
--- a/MdePkg/Include/IndustryStandard/WindowsSmmSecurityMitigationTable.h
+++ b/MdePkg/Include/IndustryStandard/WindowsSmmSecurityMitigationTable.h
@@ -1,6 +1,6 @@
 /** @file
   Defines Windows SMM Security Mitigation Table
-  @ 
http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx
+  @ 
https://msdn.microsoft.com/windows/hardware/drivers/bringup/acpi-system-description-tables#wsmt
 
   Copyright (c) 2016, Intel Corporation. All rights reserved.
   This program and the accompanying materials 
-- 
2.7.4.windows.1

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

Re: [edk2] [Patch 0/4] MdeModulePkg/PciBus Do not improperly degrade resource

[Laszlo Ersek]

Ray,

On 05/18/16 13:35, Laszlo Ersek wrote:

> For #1 through #3:
> Reviewed-by: Laszlo Ersek 

[snip]

> - Anyway I'll leave the above two points up to your consideration. For patch 
> #4 too:
> Reviewed-by: Laszlo Ersek 

I would *greatly* appreciate if you didn't ignore my (positive) reviews.

Just because I'm not an official package maintainer for MdeModulePkg, I
do expect that my Reviewed-by tags be picked up, when I make the effort
to review MdeModulePkg patches.

I have just noticed that you didn't pick up my above Reviewed-by tags,
for commits

cf81d5a68052 MdeModulePkg/PciBus: use better name for local variables.
48495aae386a MdeModulePkg/PciBus: Remove unused fields in PCI_BAR
ea669c1ba331 MdeModulePkg/PciBus: Use shorter global variable name
05070c1b471b MdeModulePkg/PciBus: do not improperly degrade resource

I see that you picked up my Tested-by tag (for all of the patches in
this series), but I didn't just test these patches, I also reviewed them.

I see the exact same occur in commit

0b58c4894dad MdeModulePkg/PciHostBridgeDxe: Add CpuArch protocol
 dependency

I reviewed that patch on the list, but the committed version does not
have my R-b.

In general, if you receive *any* kind of feedback tag from anyone in the
community, it is more or less your "duty" to preserve those tags when
you commit the patch. If you squander reviews that you get (even if they
are positive reviews), that's a big dis-incentive for future feedback.

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

Re: [edk2] [BaseTools] PACKAGES_PATH issue?

[Gao, Liming]

Andrew:
  If the source module INF is listed in FDF file, it is also required to be 
placed into DSC file. The module in DSC will be built into build output 
directory. The module in FDF will be integrated into FFS, FV. If there is no 
matched build output, GenFds can’t integrate it.

Thanks
Liming
From: af...@apple.com [mailto:af...@apple.com]
Sent: Tuesday, May 24, 2016 11:52 AM
To: Gao, Liming 
Cc: edk2-devel 
Subject: Re: [edk2] [BaseTools] PACKAGES_PATH issue?

Liming,

I finally figured out what was causing the issue. It looks like it is a DEFINE 
combined with PACKAGES_PATH seems to cause the issue in the FDF file.

The DSC file is still set to OvmfPkg/AcpiTables/AcpiTables.inf, I'm not sure if 
that is also required. It seems like if the DEFINE is relative to WORKSPACE 
everything works, if it has to be processed with PACKAGES_PATH that seems to 
bring out the issue.

~/work/src/edk2(master)>OvmfPkg/build.sh
...
build.py...
: error 7000: Failed to execute command
GenFds -f /Users/andrewfish/work/src/edk2/OvmfPkg/OvmfPkgX64.fdf 
--conf=/Users/andrewfish/work/src/edk2/Conf -o 
/Users/andrewfish/work/src/edk2/Build/OvmfX64/DEBUG_XCODE5 -t XCODE5 -b DEBUG 
-p /Users/andrewfish/work/src/edk2/OvmfPkg/OvmfPkgX64.dsc -a X64 -D 
"EFI_SOURCE=/Users/andrewfish/work/src/edk2/EdkCompatibilityPkg" -D 
"EDK_SOURCE=/Users/andrewfish/work/src/edk2/EdkCompatibilityPkg" -D 
"TOOL_CHAIN_TAG=XCODE5" -D "TOOLCHAIN=XCODE5" -D "TARGET=DEBUG" -D 
"WORKSPACE=/Users/andrewfish/work/src/edk2" -D 
"EDK_TOOLS_PATH=/Users/andrewfish/work/src/edk2/BaseTools" -D "ARCH=X64" -D 
"ECP_SOURCE=/Users/andrewfish/work/src/edk2/EdkCompatibilityPkg" 
[/Users/andrewfish/work/src/edk2]


~/work/src/edk2(master)>export PACKAGES_PATH="$WORKSPACE/OvmfPkg"
~/work/src/edk2(master)>git diff OvmfPkg/
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 84a40a3..7094648 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -17,7 +17,7 @@

[Defines]
!include OvmfPkg.fdf.inc
-
+DEFINE ACPI = AcpiTables
#
# Build the variable store and the firmware code as one unified flash device
# image.
@@ -272,7 +272,7 @@ INF OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf

INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
INF OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
-INF RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
+INF RuleOverride=ACPITABLE $(ACPI)/AcpiTables.inf
INF MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
INF MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf

Thanks,

Andrew Fish


> On May 23, 2016, at 8:34 AM, Andrew Fish wrote:
>
>
>> On May 23, 2016, at 5:52 AM, Gao, Liming wrote:
>>
>> Andrew:
>> The buid output path is always in $(WORKSPACE)\Build directory.
>
> You mean the path in $(WORKSPACE)\Build does not match the WORKSPACE relative 
> path of the file? That seems to imply that code from different packages could 
> get mixed together in the $(WORKSPACE)\Build output. That seems very very 
> confusing to the user.
>
>> It is not related to $(PACKAGES_PATH). PACKAGES_PATH is designed to search 
>> source files, doesn’t impact build output directory.
>>
>
> That is not what I was seeing? I'm seeing $(WORKSPACE) relative paths in 
> $(WORKSPACE)\Build and then I'm see logic that is not using the full path to 
> search for files?
>
> I have output that looks like:
> Build/X/DEBUG_XCODE5/X64/edk2/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/OUTPUT/
> But I saw the Python searching a location like this for files:
> Build/X/DEBUG_XCODE5/X64/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/OUTPUT/
>
> Thanks,
>
> Andrew Fish
>
>> I try Ovmf platform. Its AcpiTables can be found and be built into FFS.
>>
>> Thanks
>> Liming <>
>> <>From: af...@apple.com [mailto:af...@apple.com 
>>  ]
>> Sent: Saturday, May 21, 2016 8:21 AM
>> To: Gao, Liming >
>> Cc: edk2-devel >
>> Subject: Re: [edk2] [BaseTools] PACKAGES_PATH issue?
>>
>> Liming,
>>
>> I found one more issues. My ACPI tables are breaking the build. It looks 
>> like the failure is no input files. What I've figured out in GetFileList() 
>> is FfsInf.EfiOutputPath is constructed incorrectly. The path does not 
>> included the prefix from the PACKAGES_PATH and thus the directory does not 
>> exist and no files are found. It looks like the issue is 
>> __GetEFIOutPutPath__() as it is using self.InfFileName and that has not been 
>> adjusted for PACKAGES_PATH?
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>> On May 20, 2016, at 1:34 AM, Gao, Liming wrote:
>>>
>>> Andrew:
>>> Thanks for your point out. It is bug. Your fix is correct. I will send the 
>>> patch for it.
>>>
>>> Thanks
>>> Liming
 -Original Message-
 From: af...@apple.com [mailto:af...@apple.com 
  ]
 Sent: Friday, May 20, 2016 1:25 PM
 To: Gao, Liming
 Cc: edk2-devel
 Subject: Re: [edk2] [BaseTools] RuleOver

Re: [edk2] [BaseTools] PACKAGES_PATH issue?

[Andrew Fish]

> On May 24, 2016, at 6:29 AM, Gao, Liming  wrote:
> 
> Andrew:
>   If the source module INF is listed in FDF file, it is also required to be 
> placed into DSC file.

Well they are they both resolve to the same INF file after you apply the 
PACKAGES_PATH rules. The extensions I made expanded the build output path to 
match the location in the $WORKSPACE. 

> The module in DSC will be built into build output directory. The module in 
> FDF will be integrated into FFS, FV. If there is no matched build output, 
> GenFds can’t integrate it.

What code is setting the build output directory, I'd like to fix the Build 
directories to be the actual path in the tree. I guess I have to fix both the 
DSC and FDF derived paths to match. So there are two locations I need to path. 
I'm willing to modify our copy of the tools to get back our old behavior. 

Thanks,

Andrew Fish

>  
> Thanks
> Liming <>
>  <>From: af...@apple.com  [mailto:af...@apple.com 
> ] 
> Sent: Tuesday, May 24, 2016 11:52 AM
> To: Gao, Liming mailto:liming@intel.com>>
> Cc: edk2-devel mailto:edk2-devel@lists.01.org>>
> Subject: Re: [edk2] [BaseTools] PACKAGES_PATH issue?
>  
> Liming,
> 
> I finally figured out what was causing the issue. It looks like it is a 
> DEFINE combined with PACKAGES_PATH seems to cause the issue in the FDF file. 
> 
> The DSC file is still set to OvmfPkg/AcpiTables/AcpiTables.inf, I'm not sure 
> if that is also required. It seems like if the DEFINE is relative to 
> WORKSPACE everything works, if it has to be processed with PACKAGES_PATH that 
> seems to bring out the issue. 
> 
> ~/work/src/edk2(master)>OvmfPkg/build.sh
> ...
> build.py...
> : error 7000: Failed to execute command
> GenFds -f /Users/andrewfish/work/src/edk2/OvmfPkg/OvmfPkgX64.fdf 
> --conf=/Users/andrewfish/work/src/edk2/Conf -o 
> /Users/andrewfish/work/src/edk2/Build/OvmfX64/DEBUG_XCODE5 -t XCODE5 -b DEBUG 
> -p /Users/andrewfish/work/src/edk2/OvmfPkg/OvmfPkgX64.dsc -a X64 -D 
> "EFI_SOURCE=/Users/andrewfish/work/src/edk2/EdkCompatibilityPkg" -D 
> "EDK_SOURCE=/Users/andrewfish/work/src/edk2/EdkCompatibilityPkg" -D 
> "TOOL_CHAIN_TAG=XCODE5" -D "TOOLCHAIN=XCODE5" -D "TARGET=DEBUG" -D 
> "WORKSPACE=/Users/andrewfish/work/src/edk2" -D 
> "EDK_TOOLS_PATH=/Users/andrewfish/work/src/edk2/BaseTools" -D "ARCH=X64" -D 
> "ECP_SOURCE=/Users/andrewfish/work/src/edk2/EdkCompatibilityPkg" 
> [/Users/andrewfish/work/src/edk2]
> 
> 
> ~/work/src/edk2(master)>export PACKAGES_PATH="$WORKSPACE/OvmfPkg"
> ~/work/src/edk2(master)>git diff OvmfPkg/
> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> index 84a40a3..7094648 100644
> --- a/OvmfPkg/OvmfPkgX64.fdf
> +++ b/OvmfPkg/OvmfPkgX64.fdf
> @@ -17,7 +17,7 @@
> 
> [Defines]
> !include OvmfPkg.fdf.inc
> -
> +DEFINE ACPI = AcpiTables
> #
> # Build the variable store and the firmware code as one unified flash device
> # image.
> @@ -272,7 +272,7 @@ INF OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
> 
> INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> INF OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> -INF RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
> +INF RuleOverride=ACPITABLE $(ACPI)/AcpiTables.inf
> INF MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
> INF 
> MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> > On May 23, 2016, at 8:34 AM, Andrew Fish wrote:
> > 
> > 
> >> On May 23, 2016, at 5:52 AM, Gao, Liming wrote:
> >> 
> >> Andrew:
> >> The buid output path is always in $(WORKSPACE)\Build directory.
> > 
> > You mean the path in $(WORKSPACE)\Build does not match the WORKSPACE 
> > relative path of the file? That seems to imply that code from different 
> > packages could get mixed together in the $(WORKSPACE)\Build output. That 
> > seems very very confusing to the user. 
> > 
> >> It is not related to $(PACKAGES_PATH). PACKAGES_PATH is designed to search 
> >> source files, doesn’t impact build output directory. 
> >> 
> > 
> > That is not what I was seeing? I'm seeing $(WORKSPACE) relative paths in 
> > $(WORKSPACE)\Build and then I'm see logic that is not using the full path 
> > to search for files? 
> > 
> > I have output that looks like: 
> > Build/X/DEBUG_XCODE5/X64/edk2/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/OUTPUT/
> > But I saw the Python searching a location like this for files:
> > Build/X/DEBUG_XCODE5/X64/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/OUTPUT/
> > 
> > Thanks,
> > 
> > Andrew Fish
> > 
> >> I try Ovmf platform. Its AcpiTables can be found and be built into FFS.
> >> 
> >> Thanks
> >> Liming <>
> >> <>From: af...@apple.com  [mailto:af...@apple.com  
> >> ] 
> >> Sent: Saturday, May 21, 2016 8:21 AM
> >> To: Gao, Liming >
> >> Cc: edk2-devel >
> >> Subject: Re: [edk2] [BaseTools] PACKAGES_PATH issue?
> >> 
> >> Liming,
> >> 
> >> I found one mor

Re: [edk2] [Patch 0/4] MdeModulePkg/PciBus Do not improperly degrade resource

[Ni, Ruiyu]

Laszlo,
I am terribly sorry about that! For this patch serials, I didn't noticed your 
r-b. That's why I offline asked Jeff to send his r-b. I can add your tested by 
tag, there is no reason to ignore your review by!

For the dependency patch, I forgot your review by mail after a weekend.

I will search related mails when committing patches to avoid ignoring mails 
again.(Outlook doesn't organize these mails from this mail list in thread style)

Thanks,
Ray

> 在 2016年5月24日，下午8:28，Laszlo Ersek  写道：
> 
> Ray,
> 
>> On 05/18/16 13:35, Laszlo Ersek wrote:
>> 
>> For #1 through #3:
>> Reviewed-by: Laszlo Ersek 
> 
> [snip]
> 
>> - Anyway I'll leave the above two points up to your consideration. For patch 
>> #4 too:
>> Reviewed-by: Laszlo Ersek 
> 
> I would *greatly* appreciate if you didn't ignore my (positive) reviews.
> 
> Just because I'm not an official package maintainer for MdeModulePkg, I
> do expect that my Reviewed-by tags be picked up, when I make the effort
> to review MdeModulePkg patches.
> 
> I have just noticed that you didn't pick up my above Reviewed-by tags,
> for commits
> 
> cf81d5a68052 MdeModulePkg/PciBus: use better name for local variables.
> 48495aae386a MdeModulePkg/PciBus: Remove unused fields in PCI_BAR
> ea669c1ba331 MdeModulePkg/PciBus: Use shorter global variable name
> 05070c1b471b MdeModulePkg/PciBus: do not improperly degrade resource
> 
> I see that you picked up my Tested-by tag (for all of the patches in
> this series), but I didn't just test these patches, I also reviewed them.
> 
> I see the exact same occur in commit
> 
> 0b58c4894dad MdeModulePkg/PciHostBridgeDxe: Add CpuArch protocol
> dependency
> 
> I reviewed that patch on the list, but the committed version does not
> have my R-b.
> 
> In general, if you receive *any* kind of feedback tag from anyone in the
> community, it is more or less your "duty" to preserve those tags when
> you commit the patch. If you squander reviews that you get (even if they
> are positive reviews), that's a big dis-incentive for future feedback.
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [BaseTools] PACKAGES_PATH issue?

[Andrew Fish]

> On May 24, 2016, at 7:44 AM, Andrew Fish  wrote:
> 
> 
>> On May 24, 2016, at 6:29 AM, Gao, Liming  wrote:
>> 
>> Andrew:
>>  If the source module INF is listed in FDF file, it is also required to be 
>> placed into DSC file.
> 
> Well they are they both resolve to the same INF file after you apply the 
> PACKAGES_PATH rules. The extensions I made expanded the build output path to 
> match the location in the $WORKSPACE. 
> 
>> The module in DSC will be built into build output directory. The module in 
>> FDF will be integrated into FFS, FV. If there is no matched build output, 
>> GenFds can’t integrate it.
> 
> What code is setting the build output directory, I'd like to fix the Build 
> directories to be the actual path in the tree. I guess I have to fix both the 
> DSC and FDF derived paths to match. So there are two locations I need to 
> path. I'm willing to modify our copy of the tools to get back our old 
> behavior. 
> 

Liming,

I would also posit if you want to keep the current behavior you need to warn 
when the DSC and FDF don't use the exact same path to specify the same file. 
The current error checking only tests to make sure the INF file exists in the 
workspace, but as you point out that is no longer enough. It was really hard 
for me to track down this issue, so we really need a warning. 

Of course if the Build output path was just normalized to the WORKSPACE path 
then it would just work, and this error would not be possible. 

Thanks,

Andrew Fish

> Thanks,
> 
> Andrew Fish
> 
>> 
>> Thanks
>> Liming <>
>> <>From: af...@apple.com  [mailto:af...@apple.com 
>> ] 
>> Sent: Tuesday, May 24, 2016 11:52 AM
>> To: Gao, Liming mailto:liming@intel.com>>
>> Cc: edk2-devel mailto:edk2-devel@lists.01.org>>
>> Subject: Re: [edk2] [BaseTools] PACKAGES_PATH issue?
>> 
>> Liming,
>> 
>> I finally figured out what was causing the issue. It looks like it is a 
>> DEFINE combined with PACKAGES_PATH seems to cause the issue in the FDF file. 
>> 
>> The DSC file is still set to OvmfPkg/AcpiTables/AcpiTables.inf, I'm not sure 
>> if that is also required. It seems like if the DEFINE is relative to 
>> WORKSPACE everything works, if it has to be processed with PACKAGES_PATH 
>> that seems to bring out the issue. 
>> 
>> ~/work/src/edk2(master)>OvmfPkg/build.sh
>> ...
>> build.py...
>> : error 7000: Failed to execute command
>> GenFds -f /Users/andrewfish/work/src/edk2/OvmfPkg/OvmfPkgX64.fdf 
>> --conf=/Users/andrewfish/work/src/edk2/Conf -o 
>> /Users/andrewfish/work/src/edk2/Build/OvmfX64/DEBUG_XCODE5 -t XCODE5 -b 
>> DEBUG -p /Users/andrewfish/work/src/edk2/OvmfPkg/OvmfPkgX64.dsc -a X64 -D 
>> "EFI_SOURCE=/Users/andrewfish/work/src/edk2/EdkCompatibilityPkg" -D 
>> "EDK_SOURCE=/Users/andrewfish/work/src/edk2/EdkCompatibilityPkg" -D 
>> "TOOL_CHAIN_TAG=XCODE5" -D "TOOLCHAIN=XCODE5" -D "TARGET=DEBUG" -D 
>> "WORKSPACE=/Users/andrewfish/work/src/edk2" -D 
>> "EDK_TOOLS_PATH=/Users/andrewfish/work/src/edk2/BaseTools" -D "ARCH=X64" -D 
>> "ECP_SOURCE=/Users/andrewfish/work/src/edk2/EdkCompatibilityPkg" 
>> [/Users/andrewfish/work/src/edk2]
>> 
>> 
>> ~/work/src/edk2(master)>export PACKAGES_PATH="$WORKSPACE/OvmfPkg"
>> ~/work/src/edk2(master)>git diff OvmfPkg/
>> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
>> index 84a40a3..7094648 100644
>> --- a/OvmfPkg/OvmfPkgX64.fdf
>> +++ b/OvmfPkg/OvmfPkgX64.fdf
>> @@ -17,7 +17,7 @@
>> 
>> [Defines]
>> !include OvmfPkg.fdf.inc
>> -
>> +DEFINE ACPI = AcpiTables
>> #
>> # Build the variable store and the firmware code as one unified flash device
>> # image.
>> @@ -272,7 +272,7 @@ INF OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
>> 
>> INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
>> INF OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>> -INF RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
>> +INF RuleOverride=ACPITABLE $(ACPI)/AcpiTables.inf
>> INF MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
>> INF 
>> MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>>> On May 23, 2016, at 8:34 AM, Andrew Fish wrote:
>>> 
>>> 
 On May 23, 2016, at 5:52 AM, Gao, Liming wrote:
 
 Andrew:
 The buid output path is always in $(WORKSPACE)\Build directory.
>>> 
>>> You mean the path in $(WORKSPACE)\Build does not match the WORKSPACE 
>>> relative path of the file? That seems to imply that code from different 
>>> packages could get mixed together in the $(WORKSPACE)\Build output. That 
>>> seems very very confusing to the user. 
>>> 
 It is not related to $(PACKAGES_PATH). PACKAGES_PATH is designed to search 
 source files, doesn’t impact build output directory. 
 
>>> 
>>> That is not what I was seeing? I'm seeing $(WORKSPACE) relative paths in 
>>> $(WORKSPACE)\Build and then I'm see logic that is not using the full path 
>>> to search for files? 
>>> 
>>> I have output that looks like: 

Re: [edk2] [Patch 0/4] MdeModulePkg/PciBus Do not improperly degrade resource

[Laszlo Ersek]

On 05/24/16 17:29, Ni, Ruiyu wrote:
> Laszlo,
> I am terribly sorry about that! For this patch serials, I didn't noticed your 
> r-b. That's why I offline asked Jeff to send his r-b. I can add your tested 
> by tag, there is no reason to ignore your review by!
> 
> For the dependency patch, I forgot your review by mail after a weekend.
> 
> I will search related mails when committing patches to avoid ignoring mails 
> again.(Outlook doesn't organize these mails from this mail list in thread 
> style)

Ah, sorry. In this case I'll clearly blame Outlook. It is plain
impossible to work with patches and review feedback if the MUA doesn't
support threading.

Barring a MUA switch on your side, I guess I could recommend reviewing
the patch series thread on GMANE (in the mailing list archive) one last
time, before committing the patches. GMANE has a great threading WebUI,
which would likely provide you with all the feedback for a patch series,
in a nice centralized view.

Thanks,
Laszlo

>> 在 2016年5月24日，下午8:28，Laszlo Ersek  写道：
>>
>> Ray,
>>
>>> On 05/18/16 13:35, Laszlo Ersek wrote:
>>>
>>> For #1 through #3:
>>> Reviewed-by: Laszlo Ersek 
>>
>> [snip]
>>
>>> - Anyway I'll leave the above two points up to your consideration. For 
>>> patch #4 too:
>>> Reviewed-by: Laszlo Ersek 
>>
>> I would *greatly* appreciate if you didn't ignore my (positive) reviews.
>>
>> Just because I'm not an official package maintainer for MdeModulePkg, I
>> do expect that my Reviewed-by tags be picked up, when I make the effort
>> to review MdeModulePkg patches.
>>
>> I have just noticed that you didn't pick up my above Reviewed-by tags,
>> for commits
>>
>> cf81d5a68052 MdeModulePkg/PciBus: use better name for local variables.
>> 48495aae386a MdeModulePkg/PciBus: Remove unused fields in PCI_BAR
>> ea669c1ba331 MdeModulePkg/PciBus: Use shorter global variable name
>> 05070c1b471b MdeModulePkg/PciBus: do not improperly degrade resource
>>
>> I see that you picked up my Tested-by tag (for all of the patches in
>> this series), but I didn't just test these patches, I also reviewed them.
>>
>> I see the exact same occur in commit
>>
>> 0b58c4894dad MdeModulePkg/PciHostBridgeDxe: Add CpuArch protocol
>> dependency
>>
>> I reviewed that patch on the list, but the committed version does not
>> have my R-b.
>>
>> In general, if you receive *any* kind of feedback tag from anyone in the
>> community, it is more or less your "duty" to preserve those tags when
>> you commit the patch. If you squander reviews that you get (even if they
>> are positive reviews), that's a big dis-incentive for future feedback.
>>
>> Thanks
>> Laszlo

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

Re: [edk2] TCP4: Failure to Acknowledge due to DPC Dispatch Nesting

[Cohen, Eugene]

Siyuan,

Thanks for clarifying the intended design.

Given your response I understand that it's considered acceptable for DPC 
functions to preempt each other, even at the same registered TPL level and even 
sometimes with the same exact function (and in the case of TCP operating on the 
exact same connection).  This would seem to present a substantial challenge for 
DPCs to be written correctly because you have to assume that any protocol or 
library you call may result in a DPC dispatch and cause other routines at your 
TPL level (or even another instance of the same function) to be called again.  
Are there restrictions to when DispatchDPC is allowed to be called or can 
anyone do it anytime?  What if, for some evil reason, someone decided to use 
DPCs as part of a specialized DebugLib causing the stack to be preempted 
constantly - do you expect all DPC handlers to behave correctly under these 
circumstances?  Wouldn't it be safer to remove this form of preemption (or at 
least the same-TPL preemption)?

To change the TCP code as you mention, what do you recommend?  Right now we 
have a routine:

  if (TcpTransmitSegment (Tcb, Nbuf) == 0) {
TCP_CLEAR_FLG (Tcb->CtrlFlag, TCP_CTRL_ACK_NOW);
Tcb->DelayedAck = 0;
  }

That attempts the transmit and clears the DelayedAck flag as a function of the 
return status.  Are you recommending that we clear CTRL_ACK_NOW and DelayedAck 
before attempting the transmit?  In the case of an error we would need a way to 
restore the ACK_NOW and DelayedAck these flags which presents the same problem 
again.

But generally I don't think this methodology can be applied to other areas with 
the same exposure.  Consider the TcpToSendData function.  It does this:

if (TcpTransmitSegment (Tcb, Nbuf) != 0) {
NetbufTrim (Nbuf, (Nbuf->Tcp->HeadLen << 2), NET_BUF_HEAD);
Nbuf->Tcp = NULL;

if ((Flag & TCP_FLG_FIN) != 0)  {
  TCP_SET_FLG (Tcb->CtrlFlag, TCP_CTRL_FIN_SENT);
}

goto OnError;
  }

which as you can see sets a flag (FIN_SENT) after a DPC preemption point 
(TcpTransmitSegment) and even later it sets other TCB data after the DPC 
preemption point:

  //
  // update status in TCB
  //
  Tcb->DelayedAck = 0;

  if ((Flag & TCP_FLG_FIN) != 0) {
TCP_SET_FLG (Tcb->CtrlFlag, TCP_CTRL_FIN_SENT);
  }

So it seems like the TCB contents may be at risk in a number of places because 
of DPC preemption.

If we the DPC rules were changed such that DPCs at the same TPL didn't preempt 
each other it would seem to prevent this (to the extent that DPC callbacks use 
a consistent TPL level to provide protection).

Thanks,

Eugene

From: Fu, Siyuan [mailto:siyuan...@intel.com]
Sent: Monday, May 23, 2016 8:45 PM
To: Ye, Ting ; Cohen, Eugene ; 
edk2-devel@lists.01.org; Wu, Jiaxin ; Zhang, Lubo 

Cc: Vaughn, Gregory (IPG LJ Printer Lab) 
Subject: RE: TCP4: Failure to Acknowledge due to DPC Dispatch Nesting

Hi, Eugene

Thanks for your detail analysis to help understanding the problem. We think 
it’s a bug about the DelayedAck flag update in TCP driver, not in DPC, and here 
is the detail.

At the time the TcpTicking() is running, the under layer (MnpSystemPoll) also 
has a timer to receive network packets and queue them to the DPC. In you 
described case, when TcpTickingDpc() calls TcpSendAck() to send a delayed ACK 
to the remote, it first calls TcpTransmitSegment to transmit the ACK (point 1), 
then clear the TCP_CTRL_ACK_NOW and set DelayedAck to zero (point 2) as below.

   TcpTicking
  TcpSendAck
 TcpTransmitSegment (#1)
 Clear Tcb’s flag (#2)

But there are some DispatchDpc between #1 and #2, it not only transmited the 
ACK message to the under layer driver, but also invoked these MNP queued DPC 
and delivered these packets to the upper layer driver (TCP), then set the Tcb’s 
flag. So things come to:

   TcpTicking
  TcpSendAck
 TcpTransmitSegment (#1)
DispatchDpc
   New 
TCP packet arrived, and set the Tcb’s flag (#3)
 Clear Tcb’s flag (#2)

In another word, the TcpSendAck() function transmit the packet first, then 
clear the flag later, while the flag may be set by the incoming data during the 
transmit, so the clear operation is incorrect. The correct to operate the flag 
is to set the flag first, then make transmit. In this way, if the transmit 
operation invoke the DPC and deliver some new data to upper layer, the new set 
flag won’t be override.

Best Regards
Siyuan

From: Ye, Ting
Sent: Tuesday, May 24, 2016 9:23 AM
To: Cohen, Eugene mailto:eug...@hp.com>>; 
edk2-devel@lists.01.org; Fu, Siyuan 
mailto:siyuan...@intel.com>>; Wu, Jiaxin 
ma

[edk2] Question on CLANG build

[Palmer, Thomas]

EDK2 Clang users:

I've been curious about using CLANG on one of our systems to 
try out the llvm ecosystem.  I can compile my project in both GCC48 and VS2013, 
however, when I tried CLANG35 on  a Ubuntu 14.04 system, I got this error:

Building ... 
MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf 
[IA32]
MdePkg/Library/PeiMemoryAllocationLib/MemoryAllocationLib.c:58:10: warning: 
cast to 'void *' from smaller integer type 'UINTN' (aka 'unsigned int') 
[-Wint-to-void-pointer-cast]
  return (VOID *) (UINTN) Memory;

I surmise the VOID* or UINTN must be incorrectly configured somewhere?  Or 
perhaps I missed some crucial setup steps?

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

Re: [edk2] Question on CLANG build

[Andrew Fish]

> On May 24, 2016, at 1:19 PM, Palmer, Thomas  wrote:
> 
> EDK2 Clang users:
> 
>I've been curious about using CLANG on one of our systems to 
> try out the llvm ecosystem.  I can compile my project in both GCC48 and 
> VS2013, however, when I tried CLANG35 on  a Ubuntu 14.04 system, I got this 
> error:
> 
> Building ... 
> MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
>  [IA32]
> MdePkg/Library/PeiMemoryAllocationLib/MemoryAllocationLib.c:58:10: warning: 
> cast to 'void *' from smaller integer type 'UINTN' (aka 'unsigned int') 
> [-Wint-to-void-pointer-cast]
>  return (VOID *) (UINTN) Memory;
> 
> I surmise the VOID* or UINTN must be incorrectly configured somewhere?  Or 
> perhaps I missed some crucial setup steps?
> 

Thomas,

VOID * is just a pointer. UINTN should be the size of a pointer. The only way I 
can reproduce this error is to try and compile IA32 code with the x86_64 
version of the compiler. I'm not 100% sure but I think you only get this error 
if sizeof(unsigned int) < sizeof (void *). For IA32 I would expect UINTN to be 
an unsigned int and a pointer fits into an int? 

UINTN is defined here: 
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Ia32/ProcessorBind.h
 for IA32. 

Are you sure you are using the correct compiler flags for IA32, for the Xcode 
version of clang that means pass: -arch i386. No arch usually defaults to 
x86_64. 

~/work/Compiler>cat void.c 

typedef unsigned long long  UINT64;
typedef unsigned intUINT32;
typedef UINT32  UINTN;


void *
Test (UINT64 Memory)
{
  return (void *) (UINTN) Memory;
}
~/work/Compiler>clang -S void.c
void.c:10:10: warning: cast to 'void *' from smaller integer type 'UINTN' (aka 
'unsigned int')
  [-Wint-to-void-pointer-cast]
  return (void *) (UINTN) Memory;
 ^
1 warning generated.
~/work/Compiler>clang -arch i386 -S void.c 


Thanks,

Andrew Fish

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

Re: [edk2] [PATCH] OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM

[Jordan Justen]

Reviewed-by: Jordan Justen 

On 2016-05-18 15:12:53, Laszlo Ersek wrote:
> According to edk2 commit
> 
>   "MdeModulePkg/PciBus: do not improperly degrade resource"
> 
> and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the
> Platform Init 1.4a specification, a platform can provide such a protocol
> in order to influence the PCI resource allocation performed by the PCI Bus
> driver.
> 
> In particular it is possible instruct the PCI Bus driver, with a
> "wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit
> address space, regardless of whether the device features an option ROM.
> 
> (By default, the PCI Bus driver considers an option ROM reason enough for
> allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if
> BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS
> binary from a combined option ROM could be dispatched, and fail to access
> MMIO BARs in 64-bit address space.)
> 
> In platform code we can ascertain whether a CSM is present or not. If not,
> then legacy BIOS binaries in option ROMs can't be dispatched, hence the
> BAR degradation is detrimental, and we should prevent it. This is expected
> to conserve the 32-bit address space for 32-bit MMIO BARs.
> 
> The driver added in this patch could be simplified based on the following
> facts:
> 
> - In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence
>   the driver will exit immediately. Therefore the driver could be omitted
>   from the Ia32 build.
> 
> - In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE
>   was defined (because in that case the degradation would be justified).
>   On the other hand, if CSM_ENABLE was undefined, then the driver could be
>   included, and it could provide the hint unconditionally (without looking
>   for the Legacy BIOS protocol).
> 
> These short-cuts are not taken because they would increase the differences
> between the OVMF DSC/FDF files. If we can manage without extreme
> complexity, we should use dynamic logic (vs. build time configuration),
> plus keep conditional compilation to a minimum.
> 
> Cc: Jordan Justen 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> This patch will make a difference only when Ray's patch at
> 
> is committed.
> 
>  OvmfPkg/OvmfPkgIa32.dsc  |   
> 1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc   |   
> 1 +
>  OvmfPkg/OvmfPkgX64.dsc   |   
> 1 +
>  OvmfPkg/OvmfPkgIa32.fdf  |   
> 1 +
>  OvmfPkg/OvmfPkgIa32X64.fdf   |   
> 1 +
>  OvmfPkg/OvmfPkgX64.fdf   |   
> 1 +
>  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf |  
> 50 +++
>  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c   | 
> 353 
>  8 files changed, 409 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 45569f2875b5..1becb65cd878 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -552,6 +552,7 @@ [Components]
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
>  
>PciHostBridgeLib|OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 05ff1c914455..3d838cdcb125 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -561,6 +561,7 @@ [Components.X64]
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
>  
>PciHostBridgeLib|OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 54d4413f11f6..16d58bad7865 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -559,6 +559,7 @@ [Components]
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
>  
>PciHostBridgeLib|OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index 594e84fd713b..8ab1633f

Re: [edk2] Question on CLANG build

[Palmer, Thomas]

Andrew,

I agree the C code is correct, which is why I figure I must not be 
using CLANG correctly.  

I do not see the -arch 386 flag in the compile command.  I see that 
flag for XCLANG, but not for CLANG35.   I'll try to hack the Conf file to 
include that flag for IA32.

Thomas


-Original Message-
From: af...@apple.com [mailto:af...@apple.com] 
Sent: Tuesday, May 24, 2016 3:46 PM
To: Palmer, Thomas 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Question on CLANG build


> On May 24, 2016, at 1:19 PM, Palmer, Thomas  wrote:
> 
> EDK2 Clang users:
> 
>I've been curious about using CLANG on one of our systems to 
> try out the llvm ecosystem.  I can compile my project in both GCC48 and 
> VS2013, however, when I tried CLANG35 on  a Ubuntu 14.04 system, I got this 
> error:
> 
> Building ... 
> MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLi
> bIdt.inf [IA32]
> MdePkg/Library/PeiMemoryAllocationLib/MemoryAllocationLib.c:58:10: 
> warning: cast to 'void *' from smaller integer type 'UINTN' (aka 
> 'unsigned int') [-Wint-to-void-pointer-cast]  return (VOID *) (UINTN) 
> Memory;
> 
> I surmise the VOID* or UINTN must be incorrectly configured somewhere?  Or 
> perhaps I missed some crucial setup steps?
> 

Thomas,

VOID * is just a pointer. UINTN should be the size of a pointer. The only way I 
can reproduce this error is to try and compile IA32 code with the x86_64 
version of the compiler. I'm not 100% sure but I think you only get this error 
if sizeof(unsigned int) < sizeof (void *). For IA32 I would expect UINTN to be 
an unsigned int and a pointer fits into an int? 

UINTN is defined here: 
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Ia32/ProcessorBind.h
 for IA32. 

Are you sure you are using the correct compiler flags for IA32, for the Xcode 
version of clang that means pass: -arch i386. No arch usually defaults to 
x86_64. 

~/work/Compiler>cat void.c 

typedef unsigned long long  UINT64;
typedef unsigned intUINT32;
typedef UINT32  UINTN;


void *
Test (UINT64 Memory)
{
  return (void *) (UINTN) Memory;
}
~/work/Compiler>clang -S void.c
void.c:10:10: warning: cast to 'void *' from smaller integer type 'UINTN' (aka 
'unsigned int')
  [-Wint-to-void-pointer-cast]
  return (void *) (UINTN) Memory;
 ^
1 warning generated.
~/work/Compiler>clang -arch i386 -S void.c 


Thanks,

Andrew Fish

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

Re: [edk2] Question on CLANG build

[Andrew Fish]

> On May 24, 2016, at 2:02 PM, Palmer, Thomas  wrote:
> 
> Andrew,
> 
>   I agree the C code is correct, which is why I figure I must not be 
> using CLANG correctly.  
> 
>   I do not see the -arch 386 flag in the compile command.  I see that 
> flag for XCLANG, but not for CLANG35.   I'll try to hack the Conf file to 
> include that flag for IA32.
> 

XCODE5 is the current clang that ships with Xcode on a Mac so it is the best 
one to copy. You have to specify -arch or -target or you will get the compiler 
defaults. The -target flag is more about cross compilers. For example 
*XCODE5_X64_CC_FLAGS sets -target x86_64-pc-win32-macho to compile using the 
Windows/EFI Calling convention but to generate a Mach-O (Image format on a Mac 
like ELF or PE/COFF) to make the debugger happy. 

I did not see IA32 or X64 targets for CLANG35 in master?

Thanks,

Andrew Fish

> Thomas
> 
> 
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com] 
> Sent: Tuesday, May 24, 2016 3:46 PM
> To: Palmer, Thomas 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Question on CLANG build
> 
> 
>> On May 24, 2016, at 1:19 PM, Palmer, Thomas  wrote:
>> 
>> EDK2 Clang users:
>> 
>>   I've been curious about using CLANG on one of our systems to 
>> try out the llvm ecosystem.  I can compile my project in both GCC48 and 
>> VS2013, however, when I tried CLANG35 on  a Ubuntu 14.04 system, I got this 
>> error:
>> 
>> Building ... 
>> MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLi
>> bIdt.inf [IA32]
>> MdePkg/Library/PeiMemoryAllocationLib/MemoryAllocationLib.c:58:10: 
>> warning: cast to 'void *' from smaller integer type 'UINTN' (aka 
>> 'unsigned int') [-Wint-to-void-pointer-cast]  return (VOID *) (UINTN) 
>> Memory;
>> 
>> I surmise the VOID* or UINTN must be incorrectly configured somewhere?  Or 
>> perhaps I missed some crucial setup steps?
>> 
> 
> Thomas,
> 
> VOID * is just a pointer. UINTN should be the size of a pointer. The only way 
> I can reproduce this error is to try and compile IA32 code with the x86_64 
> version of the compiler. I'm not 100% sure but I think you only get this 
> error if sizeof(unsigned int) < sizeof (void *). For IA32 I would expect 
> UINTN to be an unsigned int and a pointer fits into an int? 
> 
> UINTN is defined here: 
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Ia32/ProcessorBind.h
>  for IA32. 
> 
> Are you sure you are using the correct compiler flags for IA32, for the Xcode 
> version of clang that means pass: -arch i386. No arch usually defaults to 
> x86_64. 
> 
> ~/work/Compiler>cat void.c 
> 
> typedef unsigned long long  UINT64;
> typedef unsigned intUINT32;
> typedef UINT32  UINTN;
> 
> 
> void *
> Test (UINT64 Memory)
> {
>  return (void *) (UINTN) Memory;
> }
> ~/work/Compiler>clang -S void.c
> void.c:10:10: warning: cast to 'void *' from smaller integer type 'UINTN' 
> (aka 'unsigned int')
>  [-Wint-to-void-pointer-cast]
>  return (void *) (UINTN) Memory;
> ^
> 1 warning generated.
> ~/work/Compiler>clang -arch i386 -S void.c 
> 
> 
> Thanks,
> 
> Andrew Fish
> 

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

Re: [edk2] [PATCH 0/6] OvmfPkg, ArmVirtPkg: remove compatibility with IntelFrameworkModulePkg BDS

[Jordan Justen]

Series Reviewed-by: Jordan Justen 

On 2016-05-17 12:59:10, Laszlo Ersek wrote:
> Mainly triggered by
> 
> from about a week ago. In patch #2 the reasons are listed in more
> detail.
> 
> Public branch: .
> 
> Cc: Ard Biesheuvel 
> Cc: Gary Ching-Pang Lin 
> Cc: Jordan Justen 
> Cc: Ruiyu Ni 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (6):
>   OvmfPkg/README: refer to MdeModulePkg & PlatformBootManagerLib in
> examples
>   OvmfPkg: remove USE_OLD_BDS build fallback macro
>   OvmfPkg: remove PlatformBdsLib instance
>   OvmfPkg: remove QemuBootOrderLib instance
>   OvmfPkg, ArmVirtPkg: clean up SetBootOrderFromQemu() parameter list
>   OvmfPkg, ArmVirtPkg: rename QemuNewBootOrderLib to QemuBootOrderLib
> 
>  ArmVirtPkg/ArmVirtQemu.dsc   |2 +-
>  ArmVirtPkg/ArmVirtQemuKernel.dsc |2 +-
>  OvmfPkg/OvmfPkgIa32.dsc  |   21 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc   |   21 +-
>  OvmfPkg/OvmfPkgX64.dsc   |   21 +-
>  OvmfPkg/OvmfPkgIa32.fdf  |4 -
>  OvmfPkg/OvmfPkgIa32X64.fdf   |4 -
>  OvmfPkg/OvmfPkgX64.fdf   |4 -
>  OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf|   73 -
>  OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf|8 +-
>  OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.inf |   68 -
>  OvmfPkg/Include/Library/QemuBootOrderLib.h   |   11 +-
>  OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h |  292 ---
>  OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.h|   40 -
>  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   |2 +-
>  OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c | 1592 
> 
>  OvmfPkg/Library/PlatformBdsLib/PlatformData.c|   51 -
>  OvmfPkg/Library/PlatformBdsLib/QemuKernel.c  |  170 --
>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c |2 +-
>  OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c  |  163 +-
>  OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.c|  313 
>  OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.c   | 1954 
> 
>  OvmfPkg/README   |4 +-
>  23 files changed, 126 insertions(+), 4696 deletions(-)
>  delete mode 100644 OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
>  delete mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.inf
>  delete mode 100644 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h
>  delete mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.h
>  delete mode 100644 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
>  delete mode 100644 OvmfPkg/Library/PlatformBdsLib/PlatformData.c
>  delete mode 100644 OvmfPkg/Library/PlatformBdsLib/QemuKernel.c
>  delete mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.c
>  delete mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.c
> 
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question on CLANG build

[Palmer, Thomas]

I hacked the tools_def template and got -arch 386 into the build command, 
however I saw this fly across the screen:

clang: warning: argument unused during compilation: '-arch 386'

The clang I have is from Ubuntu's repos:
clang --version
Ubuntu clang version 3.5.0-4ubuntu2~trusty2 (tags/RELEASE_350/final) (based on 
LLVM 3.5.0)
Target: x86_64-pc-linux-gnu
Thread model: posix

Bummer.  I suppose I'll have to make my own clang-3.5 instead of using Ubuntu's 
packages.  


So I then tried to build  BaseLib.inf using -a X64, and I get a totally 
different kind of error:

build.py...
 : error C0DE: Unknown fatal error when processing 
[MdePkg/Library/BaseLib/BaseLib.inf]

(Please send email to edk2-devel@lists.01.org for help, attaching following 
call stack trace!)

(Python 2.7.6 on linux2) Traceback (most recent call last):
  File "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
line 2298, in Main
MyBuild.Launch()
  File "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
line 2054, in Launch
self._BuildModule()
  File "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
line 1721, in _BuildModule
self._Build(self.Target, Ma, BuildModule=True)
  File "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
line 1243, in _Build
AutoGenObject.CreateMakeFile(CreateDepsMakeFile)
  File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 3931, in 
CreateMakeFile
if Makefile.Generate():
  File "BaseTools/Source/Python/AutoGen/GenMake.py", line 184, in Generate
FileContent = self._TEMPLATE_.Replace(self._TemplateDict)
  File "BaseTools/Source/Python/AutoGen/GenMake.py", line 512, in 
_CreateTemplateDict
RespDict = self.CommandExceedLimit()
  File "BaseTools/Source/Python/AutoGen/GenMake.py", line 702, in 
CommandExceedLimit
Str = self._AutoGenObject._BuildOption[Tool]['FLAGS']
KeyError: 'FLAGS'

Fun times ... 

Thomas

-Original Message-
From: af...@apple.com [mailto:af...@apple.com] 
Sent: Tuesday, May 24, 2016 4:13 PM
To: Palmer, Thomas 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Question on CLANG build


> On May 24, 2016, at 2:02 PM, Palmer, Thomas  wrote:
> 
> Andrew,
> 
>   I agree the C code is correct, which is why I figure I must not be 
> using CLANG correctly.  
> 
>   I do not see the -arch 386 flag in the compile command.  I see that 
> flag for XCLANG, but not for CLANG35.   I'll try to hack the Conf file to 
> include that flag for IA32.
> 

XCODE5 is the current clang that ships with Xcode on a Mac so it is the best 
one to copy. You have to specify -arch or -target or you will get the compiler 
defaults. The -target flag is more about cross compilers. For example 
*XCODE5_X64_CC_FLAGS sets -target x86_64-pc-win32-macho to compile using the 
Windows/EFI Calling convention but to generate a Mach-O (Image format on a Mac 
like ELF or PE/COFF) to make the debugger happy. 

I did not see IA32 or X64 targets for CLANG35 in master?

Thanks,

Andrew Fish

> Thomas
> 
> 
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Tuesday, May 24, 2016 3:46 PM
> To: Palmer, Thomas 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Question on CLANG build
> 
> 
>> On May 24, 2016, at 1:19 PM, Palmer, Thomas  wrote:
>> 
>> EDK2 Clang users:
>> 
>>   I've been curious about using CLANG on one of our systems to 
>> try out the llvm ecosystem.  I can compile my project in both GCC48 and 
>> VS2013, however, when I tried CLANG35 on  a Ubuntu 14.04 system, I got this 
>> error:
>> 
>> Building ... 
>> MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerL
>> i
>> bIdt.inf [IA32]
>> MdePkg/Library/PeiMemoryAllocationLib/MemoryAllocationLib.c:58:10: 
>> warning: cast to 'void *' from smaller integer type 'UINTN' (aka 
>> 'unsigned int') [-Wint-to-void-pointer-cast]  return (VOID *) (UINTN) 
>> Memory;
>> 
>> I surmise the VOID* or UINTN must be incorrectly configured somewhere?  Or 
>> perhaps I missed some crucial setup steps?
>> 
> 
> Thomas,
> 
> VOID * is just a pointer. UINTN should be the size of a pointer. The only way 
> I can reproduce this error is to try and compile IA32 code with the x86_64 
> version of the compiler. I'm not 100% sure but I think you only get this 
> error if sizeof(unsigned int) < sizeof (void *). For IA32 I would expect 
> UINTN to be an unsigned int and a pointer fits into an int? 
> 
> UINTN is defined here: 
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Ia32/ProcessorBind.h
>  for IA32. 
> 
> Are you sure you are using the correct compiler flags for IA32, for the Xcode 
> version of clang that means pass: -arch i386. No arch usually defaults to 
> x86_64. 
> 
> ~/work/Compiler>cat void.c
> 
> typedef unsigned long long  UINT64;
> typedef unsigned intUINT32;
> typedef UINT32  UINTN;
> 
> 
> void *
> Test (UINT64 Memory)
> {
>  return (void *) (UINTN) Memory;
> }
> ~/work/Compile

Re: [edk2] Question on CLANG build

[Kinney, Michael D]

Thomas,

You might look at this fork of the edk2 project that is working through CLANG38 
toolchain issues.

https://github.com/shijunjing/edk2/tree/llvm

Archive of email discussion 

http://thread.gmane.org/gmane.comp.bios.edk2.devel/11866

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Palmer, Thomas
> Sent: Tuesday, May 24, 2016 2:28 PM
> To: af...@apple.com
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Question on CLANG build
> 
> I hacked the tools_def template and got -arch 386 into the build command, 
> however I
> saw this fly across the screen:
> 
> clang: warning: argument unused during compilation: '-arch 386'
> 
> The clang I have is from Ubuntu's repos:
> clang --version
> Ubuntu clang version 3.5.0-4ubuntu2~trusty2 (tags/RELEASE_350/final) (based 
> on LLVM
> 3.5.0)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> 
> Bummer.  I suppose I'll have to make my own clang-3.5 instead of using 
> Ubuntu's
> packages.
> 
> 
> So I then tried to build  BaseLib.inf using -a X64, and I get a totally 
> different
> kind of error:
> 
> build.py...
>  : error C0DE: Unknown fatal error when processing
> [MdePkg/Library/BaseLib/BaseLib.inf]
> 
> (Please send email to edk2-devel@lists.01.org for help, attaching following 
> call
> stack trace!)
> 
> (Python 2.7.6 on linux2) Traceback (most recent call last):
>   File "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
> line
> 2298, in Main
> MyBuild.Launch()
>   File "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
> line
> 2054, in Launch
> self._BuildModule()
>   File "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
> line
> 1721, in _BuildModule
> self._Build(self.Target, Ma, BuildModule=True)
>   File "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
> line
> 1243, in _Build
> AutoGenObject.CreateMakeFile(CreateDepsMakeFile)
>   File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 3931, in 
> CreateMakeFile
> if Makefile.Generate():
>   File "BaseTools/Source/Python/AutoGen/GenMake.py", line 184, in Generate
> FileContent = self._TEMPLATE_.Replace(self._TemplateDict)
>   File "BaseTools/Source/Python/AutoGen/GenMake.py", line 512, in 
> _CreateTemplateDict
> RespDict = self.CommandExceedLimit()
>   File "BaseTools/Source/Python/AutoGen/GenMake.py", line 702, in 
> CommandExceedLimit
> Str = self._AutoGenObject._BuildOption[Tool]['FLAGS']
> KeyError: 'FLAGS'
> 
> Fun times ...
> 
> Thomas
> 
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Tuesday, May 24, 2016 4:13 PM
> To: Palmer, Thomas 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Question on CLANG build
> 
> 
> > On May 24, 2016, at 2:02 PM, Palmer, Thomas  wrote:
> >
> > Andrew,
> >
> > I agree the C code is correct, which is why I figure I must not be 
> > using CLANG
> correctly.
> >
> > I do not see the -arch 386 flag in the compile command.  I see that 
> > flag for
> XCLANG, but not for CLANG35.   I'll try to hack the Conf file to include that 
> flag
> for IA32.
> >
> 
> XCODE5 is the current clang that ships with Xcode on a Mac so it is the best 
> one to
> copy. You have to specify -arch or -target or you will get the compiler 
> defaults. The
> -target flag is more about cross compilers. For example *XCODE5_X64_CC_FLAGS 
> sets -
> target x86_64-pc-win32-macho to compile using the Windows/EFI Calling 
> convention but
> to generate a Mach-O (Image format on a Mac like ELF or PE/COFF) to make the 
> debugger
> happy.
> 
> I did not see IA32 or X64 targets for CLANG35 in master?
> 
> Thanks,
> 
> Andrew Fish
> 
> > Thomas
> >
> >
> > -Original Message-
> > From: af...@apple.com [mailto:af...@apple.com]
> > Sent: Tuesday, May 24, 2016 3:46 PM
> > To: Palmer, Thomas 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] Question on CLANG build
> >
> >
> >> On May 24, 2016, at 1:19 PM, Palmer, Thomas  wrote:
> >>
> >> EDK2 Clang users:
> >>
> >>   I've been curious about using CLANG on one of our systems to 
> >> try out
> the llvm ecosystem.  I can compile my project in both GCC48 and VS2013, 
> however, when
> I tried CLANG35 on  a Ubuntu 14.04 system, I got this error:
> >>
> >> Building ...
> >> MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerL
> >> i
> >> bIdt.inf [IA32]
> >> MdePkg/Library/PeiMemoryAllocationLib/MemoryAllocationLib.c:58:10:
> >> warning: cast to 'void *' from smaller integer type 'UINTN' (aka
> >> 'unsigned int') [-Wint-to-void-pointer-cast]  return (VOID *) (UINTN)
> >> Memory;
> >>
> >> I surmise the VOID* or UINTN must be incorrectly configured somewhere?  Or 
> >> perhaps
> I missed some crucial setup steps?
> >>
> >
> > Thomas,
> >
> > VOID * is just a pointer. UINTN should be the size of a pointer. The only 
> > way I can
> reproduce this error is to try and compile IA32 code wit

Re: [edk2] [PATCH v2 0/3] *** Add Nvme.h and NvmExpressLib ***

[Tian, Feng]

Hi, Darbin

At patch #1, Could you please add the NVME I/O Cmd Opcodes to Nvme.h as well? I 
didn't see them except NVME ADMIN cmd opcodes.

At patch #2, after you add NVME I/O Cmd Opcodes to Nvme.h, those I/O opcodes 
definitions should be removed from NvmExpress.h.

For patch #3, I have given comments at other thread. I copy it to here for your 
reference.
1). Please don't use a common name as function name. usually we add a 
"NvmExpress" prefix prior to such function name.
2). Please remove UefiLib.h at NvmExpressLib.h, it should be redundant.
3). Identify() looks like a little overlap with IdentifyController(). GetLog() 
is same case with other GetLog variant. Do we need all of them?
4). Suggest you to follow the style of UefiScsiLib, then we can put it to 
MdePkg. Such as the library instance name is UefiNvmExpressLib rather than 
DxeNvmExpressLib.
Such as you can fill INF like this  LIBRARY_CLASS   = UefiNvmExpressLib 
|DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER UEFI_APPLICATION 
UEFI_DRIVER

Last, I would suggest you do the patch #1 & 2 first, I can help commit after 
passing review. As for patch #3, I suggest you submit it with NVMe firmware 
Management protocol patch together.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
darbin.emm.re...@hpe.com
Sent: Wednesday, May 18, 2016 5:16 AM
To: edk2-devel@lists.01.org
Cc: Tian, Feng ; Darbin Reyes ; 
Gao, Liming ; Kinney, Michael D 
; Zeng, Star 
Subject: [edk2] [PATCH v2 0/3] *** Add Nvme.h and NvmExpressLib ***

From: Darbin Reyes 

*** Add Nvme.h and NvmExpressLib ***

Darbin Reyes (3):
  MdePkg: Add a header for NVMe v1.1 spec. definitions.
  MdeModulePkg: Move/Replace NvmExpressHci.h definitions to Nvme.h.
  MdeModulePkg: Add NvmExpressLib.

 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h|   2 +
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h | 557 +--
 MdeModulePkg/Include/Library/NvmExpressLib.h   | 279 
 .../Library/DxeNvmExpressLib/DxeNvmExpressLib.c| 635 +
 .../Library/DxeNvmExpressLib/DxeNvmExpressLib.inf  |  41 ++
 MdeModulePkg/MdeModulePkg.dec  |   4 +
 MdePkg/Include/IndustryStandard/Nvme.h | 771 +
 7 files changed, 1733 insertions(+), 556 deletions(-)  create mode 100644 
MdeModulePkg/Include/Library/NvmExpressLib.h
 create mode 100644 MdeModulePkg/Library/DxeNvmExpressLib/DxeNvmExpressLib.c
 create mode 100644 MdeModulePkg/Library/DxeNvmExpressLib/DxeNvmExpressLib.inf
 create mode 100644 MdePkg/Include/IndustryStandard/Nvme.h

--
2.8.2

___
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] [patch] MdeModulePkg: Make function comments and function match in UI codes

[Qiu, Shumin]

Reviewed-by: Qiu Shumin 
-Original Message-
From: Bi, Dandan 
Sent: Monday, May 23, 2016 3:10 PM
To: edk2-devel@lists.01.org
Cc: Qiu, Shumin; Dong, Eric
Subject: [patch] MdeModulePkg: Make function comments and function match in UI 
codes

Cc: Qiu Shumin 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 .../Application/UiApp/FrontPageCustomizedUiSupport.c|  5 +
 .../Application/UiApp/FrontPageCustomizedUiSupport.h| 10 +-
 .../BootMaintenanceManagerCustomizedUiSupport.c | 13 +++--
 .../BootMaintenanceManagerCustomizedUiSupport.h |  5 +++--
 4 files changed, 8 insertions(+), 25 deletions(-)

diff --git a/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c 
b/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
index b838222..dfb37ec 100644
--- a/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
+++ b/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
@@ -234,15 +234,12 @@ UiSupportLibCallbackHandler (
 
 /**
   Create Select language menu in the front page with oneof opcode.
 
   @param[in]HiiHandle   The hii handle for the Uiapp driver.
-  @param[in]QuestionId  Question ID
   @param[in]StartOpCodeHandle   The opcode handle to save the new opcode.
 
-  @retval   EFI_SUCCESS Search the driver success
-
 **/
 VOID
 UiCreateLanguageMenu (
   IN EFI_HII_HANDLE  HiiHandle,
   IN VOID*StartOpCodeHandle
@@ -545,12 +542,12 @@ RequiredDriver (
   Search the drivers in the system which need to show in the front page
   and insert the menu to the front page.
 
   @paramHiiHandle   The hii handle for the Uiapp driver.
   @paramClassGuid   The class guid for the driver which is the 
target.
+  @paramSpecialHandlerFnThe pointer to the specail handler function, 
if any.
   @paramStartOpCodeHandle   The opcode handle to save the new opcode.
-  @paramSpecialHandler  The pointer to the specail handler function, 
if any.
 
   @retval   EFI_SUCCESS Search the driver success
 
 **/
 EFI_STATUS
diff --git a/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.h 
b/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.h
index ce3ecd5..9dda98a 100644
--- a/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.h
+++ b/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.h
@@ -19,12 +19,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
   Create continue menu in the front page.
 
   @param[in]HiiHandle   The hii handle for the Uiapp driver.
   @param[in]StartOpCodeHandle   The opcode handle to save the new opcode.
 
-  @retval   EFI_SUCCESS Search the driver success
-
 **/
 VOID
 UiCreateContinueMenu (
   IN EFI_HII_HANDLE  HiiHandle,
   IN VOID*StartOpCodeHandle
@@ -34,12 +32,10 @@ UiCreateContinueMenu (
   Create empty line menu.
 
   @paramHiiHandle   The hii handle for the Uiapp driver.
   @paramStartOpCodeHandle   The opcode handle to save the new opcode.
 
-  @retval   EFI_SUCCESS Search the driver success
-
 **/
 VOID
 UiCreateEmptyLine (
   IN EFI_HII_HANDLE  HiiHandle,
   IN VOID*StartOpCodeHandle
@@ -49,12 +45,10 @@ UiCreateEmptyLine (
   Create Select language menu in the front page with oneof opcode.
 
   @param[in]HiiHandle   The hii handle for the Uiapp driver.
   @param[in]StartOpCodeHandle   The opcode handle to save the new opcode.
 
-  @retval   EFI_SUCCESS Search the driver success
-
 **/
 VOID
 UiCreateLanguageMenu (
   IN EFI_HII_HANDLE  HiiHandle,
   IN VOID*StartOpCodeHandle
@@ -64,12 +58,10 @@ UiCreateLanguageMenu (
   Create Reset menu.
 
   @param[in]HiiHandle   The hii handle for the Uiapp driver.
   @param[in]StartOpCodeHandle   The opcode handle to save the new opcode.
 
-  @retval   EFI_SUCCESS Search the driver success
-
 **/
 VOID
 UiCreateResetMenu (
   IN EFI_HII_HANDLE  HiiHandle,
   IN VOID*StartOpCodeHandle
@@ -97,12 +89,12 @@ BOOLEAN
   Search the drivers in the system which need to show in the front page
   and insert the menu to the front page.
 
   @paramHiiHandle   The hii handle for the Uiapp driver.
   @paramClassGuid   The class guid for the driver which is the 
target.
+  @paramSpecialHandlerFn  The pointer to the specail handler function, 
if any.
   @paramStartOpCodeHandle   The opcode handle to save the new opcode.
-  @paramSpecialHandler  The pointer to the specail handler function, 
if any.
 
   @retval   EFI_SUCCESS Search the driver success
 
 **/
 EFI_STATUS
diff --git 
a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerCustomized

[edk2] [PATCH] MdeModulePkg NvmExpressDxe: Fix VS2010 build error

[Hao Wu]

Potentially uninitialized 'Status' might be returned in functions
NvmeCreateIoCompletionQueue() and NvmeCreateIoSubmissionQueue() in file
NvmExpressHci.c.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
index dcfe1e8..09e8263 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
@@ -684,7 +684,7 @@ NvmeCreateIoCompletionQueue (
   NVME_ADMIN_CRIOCQCrIoCq;
   UINT32   Index;
 
-  for (Index = 1; Index < NVME_MAX_QUEUES; Index++) {
+  for (Index = 1, Status = EFI_SUCCESS; Index < NVME_MAX_QUEUES; Index++) {
 ZeroMem (&CommandPacket, sizeof(EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET));
 ZeroMem (&Command, sizeof(EFI_NVM_EXPRESS_COMMAND));
 ZeroMem (&Completion, sizeof(EFI_NVM_EXPRESS_COMPLETION));
@@ -740,7 +740,7 @@ NvmeCreateIoSubmissionQueue (
   NVME_ADMIN_CRIOSQCrIoSq;
   UINT32   Index;
 
-  for (Index = 1; Index < NVME_MAX_QUEUES; Index++) {
+  for (Index = 1, Status = EFI_SUCCESS; Index < NVME_MAX_QUEUES; Index++) {
 ZeroMem (&CommandPacket, sizeof(EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET));
 ZeroMem (&Command, sizeof(EFI_NVM_EXPRESS_COMMAND));
 ZeroMem (&Completion, sizeof(EFI_NVM_EXPRESS_COMPLETION));
-- 
1.9.5.msysgit.0

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

Re: [edk2] [PATCH] MdeModulePkg NvmExpressDxe: Fix VS2010 build error

[Qiu, Shumin]

Reviewed-by: Qiu Shumin 

-Original Message-
From: Wu, Hao A 
Sent: Wednesday, May 25, 2016 10:16 AM
To: edk2-devel@lists.01.org; Tian, Feng; Qiu, Shumin
Cc: Wu, Hao A
Subject: [PATCH] MdeModulePkg NvmExpressDxe: Fix VS2010 build error

Potentially uninitialized 'Status' might be returned in functions
NvmeCreateIoCompletionQueue() and NvmeCreateIoSubmissionQueue() in file 
NvmExpressHci.c.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
index dcfe1e8..09e8263 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
@@ -684,7 +684,7 @@ NvmeCreateIoCompletionQueue (
   NVME_ADMIN_CRIOCQCrIoCq;
   UINT32   Index;
 
-  for (Index = 1; Index < NVME_MAX_QUEUES; Index++) {
+  for (Index = 1, Status = EFI_SUCCESS; Index < NVME_MAX_QUEUES; 
+ Index++) {
 ZeroMem (&CommandPacket, sizeof(EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET));
 ZeroMem (&Command, sizeof(EFI_NVM_EXPRESS_COMMAND));
 ZeroMem (&Completion, sizeof(EFI_NVM_EXPRESS_COMPLETION));
@@ -740,7 +740,7 @@ NvmeCreateIoSubmissionQueue (
   NVME_ADMIN_CRIOSQCrIoSq;
   UINT32   Index;
 
-  for (Index = 1; Index < NVME_MAX_QUEUES; Index++) {
+  for (Index = 1, Status = EFI_SUCCESS; Index < NVME_MAX_QUEUES; 
+ Index++) {
 ZeroMem (&CommandPacket, sizeof(EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET));
 ZeroMem (&Command, sizeof(EFI_NVM_EXPRESS_COMMAND));
 ZeroMem (&Completion, sizeof(EFI_NVM_EXPRESS_COMPLETION));
--
1.9.5.msysgit.0

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

Re: [edk2] edk2-staging/HTTPS-TLS

[Wu, Jiaxin]

Finished sync the branch from EDK2 master.

Thanks.
Jiaxin


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of El-
> Haj-Mahmoud, Samer
> Sent: Thursday, May 19, 2016 6:10 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Subject: [edk2] edk2-staging/HTTPS-TLS
> 
> Jiaxin,
> 
> The HTTPs-TLS branch is behind EDK2 master, and they are quite a few
> conflicts to try to keep up with both. Can you please sync the branch from
> EDK2 master?
> 
> Thanks,
> --Samer
> 
> ___
> 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] MdeModulePkg: Fix incorrect status check for SockProcessRcvToken

[Jiaxin Wu]

This patch is used to remove the status check for SockProcessRcvToken.
It's not return EFI_STATUS.

Cc: Fu Siyuan 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 MdeModulePkg/Universal/Network/Tcp4Dxe/SockInterface.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Tcp4Dxe/SockInterface.c 
b/MdeModulePkg/Universal/Network/Tcp4Dxe/SockInterface.c
index feed86c..c14fcd7 100644
--- a/MdeModulePkg/Universal/Network/Tcp4Dxe/SockInterface.c
+++ b/MdeModulePkg/Universal/Network/Tcp4Dxe/SockInterface.c
@@ -1,9 +1,9 @@
 /** @file
   Interface function of the Socket.
 
-Copyright (c) 2005 - 2012, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 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
 
@@ -695,15 +695,11 @@ SockRcv (
 Status = EFI_CONNECTION_FIN;
 goto Exit;
   }
 
   if (RcvdBytes != 0) {
-Status = SockProcessRcvToken (Sock, RcvToken);
-
-if (EFI_ERROR (Status)) {
-  goto Exit;
-}
+SockProcessRcvToken (Sock, RcvToken);
 
 Status = Sock->ProtoHandler (Sock, SOCK_CONSUMED, NULL);
   } else {
 
 if (NULL == SockBufferToken (Sock, &Sock->RcvTokenList, RcvToken, 0)) {
-- 
1.9.5.msysgit.1

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

Re: [edk2] [Patch] MdeModulePkg: Fix incorrect status check for SockProcessRcvToken

[Fu, Siyuan]

Reviewed-by: Fu Siyuan 

> -Original Message-
> From: Wu, Jiaxin
> Sent: Wednesday, May 25, 2016 11:57 AM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Ye, Ting 
> Subject: [Patch] MdeModulePkg: Fix incorrect status check for
> SockProcessRcvToken
> 
> This patch is used to remove the status check for SockProcessRcvToken.
> It's not return EFI_STATUS.
> 
> Cc: Fu Siyuan 
> Cc: Ye Ting 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu 
> ---
>  MdeModulePkg/Universal/Network/Tcp4Dxe/SockInterface.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/Tcp4Dxe/SockInterface.c
> b/MdeModulePkg/Universal/Network/Tcp4Dxe/SockInterface.c
> index feed86c..c14fcd7 100644
> --- a/MdeModulePkg/Universal/Network/Tcp4Dxe/SockInterface.c
> +++ b/MdeModulePkg/Universal/Network/Tcp4Dxe/SockInterface.c
> @@ -1,9 +1,9 @@
>  /** @file
>Interface function of the Socket.
> 
> -Copyright (c) 2005 - 2012, Intel Corporation. All rights reserved.
> +Copyright (c) 2005 - 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
> 
> @@ -695,15 +695,11 @@ SockRcv (
>  Status = EFI_CONNECTION_FIN;
>  goto Exit;
>}
> 
>if (RcvdBytes != 0) {
> -Status = SockProcessRcvToken (Sock, RcvToken);
> -
> -if (EFI_ERROR (Status)) {
> -  goto Exit;
> -}
> +SockProcessRcvToken (Sock, RcvToken);
> 
>  Status = Sock->ProtoHandler (Sock, SOCK_CONSUMED, NULL);
>} else {
> 
>  if (NULL == SockBufferToken (Sock, &Sock->RcvTokenList, RcvToken, 0)) {
> --
> 1.9.5.msysgit.1

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

[edk2] [Patch 4/9] UefiCpuPkg/ExceptionLib: Update UpdateIdtTable()

[Jeff Fan]

Add parameter CpuExceptionData for UpdateIdtTable().

Cc: Michael Kinney 
Cc: Jiewen Yao 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  9 ---
 .../Library/CpuExceptionHandlerLib/DxeException.c  | 23 +++--
 .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c | 29 +-
 3 files changed, 37 insertions(+), 24 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index 812469b..99be61f 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -174,16 +174,17 @@ RegisterCpuInterruptHandlerWorker (
 /**
   Internal worker function to update IDT entries accordling to vector 
attributes.
 
-  @param[in] IdtTable   Pointer to IDT table.
-  @param[in] TemplateMapPointer to a buffer where the address map is 
returned.
-  @param[in] IdtEntryCount  IDT entries number to be updated.
+  @param[in] IdtTable  Pointer to IDT table.
+  @param[in] TemplateMap   Pointer to a buffer where the address map is
+   returned.
+  @param[in] ExceptionHandlerData  Pointer to exception handler data.
 
 **/
 VOID
 UpdateIdtTable (
   IN IA32_IDT_GATE_DESCRIPTOR*IdtTable,
   IN EXCEPTION_HANDLER_TEMPLATE_MAP  *TemplateMap,
-  IN UINTN   IdtEntryCount
+  IN EXCEPTION_HANDLER_DATA  *ExceptionHandlerData
   );
 
 /**
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
index 92de04c..cffb13a 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
@@ -83,20 +83,22 @@ InitializeCpuInterruptHandlers (
   UINTN  Index;
   UINTN  InterruptEntry;
   UINT8  *InterruptEntryCode;
+  RESERVED_VECTORS_DATA  *ReservedVectors;
+  EFI_CPU_INTERRUPT_HANDLER  *ExternalInterruptHandler;
 
-  mReservedVectors = AllocatePool (sizeof (RESERVED_VECTORS_DATA) * 
CPU_INTERRUPT_NUM);
-  ASSERT (mReservedVectors != NULL);
-  SetMem ((VOID *) mReservedVectors, sizeof (RESERVED_VECTORS_DATA) * 
CPU_INTERRUPT_NUM, 0xff);
+  ReservedVectors = AllocatePool (sizeof (RESERVED_VECTORS_DATA) * 
CPU_INTERRUPT_NUM);
+  ASSERT (ReservedVectors != NULL);
+  SetMem ((VOID *) ReservedVectors, sizeof (RESERVED_VECTORS_DATA) * 
CPU_INTERRUPT_NUM, 0xff);
   if (VectorInfo != NULL) {
-Status = ReadAndVerifyVectorInfo (VectorInfo, mReservedVectors, 
CPU_INTERRUPT_NUM);
+Status = ReadAndVerifyVectorInfo (VectorInfo, ReservedVectors, 
CPU_INTERRUPT_NUM);
 if (EFI_ERROR (Status)) {
-  FreePool (mReservedVectors);
+  FreePool (ReservedVectors);
   return EFI_INVALID_PARAMETER;
 }
   }
   InitializeSpinLock (&mDisplayMessageSpinLock);
-  mExternalInterruptHandler = AllocateZeroPool (sizeof 
(EFI_CPU_INTERRUPT_HANDLER) * CPU_INTERRUPT_NUM);
-  ASSERT (mExternalInterruptHandler != NULL);
+  ExternalInterruptHandler = AllocateZeroPool (sizeof 
(EFI_CPU_INTERRUPT_HANDLER) * CPU_INTERRUPT_NUM);
+  ASSERT (ExternalInterruptHandler != NULL);
 
   //
   // Read IDT descriptor and calculate IDT size
@@ -130,7 +132,12 @@ InitializeCpuInterruptHandlers (
   }
 
   TemplateMap.ExceptionStart = (UINTN) InterruptEntryCode;
-  UpdateIdtTable (IdtTable, &TemplateMap, CPU_INTERRUPT_NUM);
+  mExceptionHandlerData.IdtEntryCount= CPU_INTERRUPT_NUM;
+  mExceptionHandlerData.ReservedVectors  = ReservedVectors;
+  mExceptionHandlerData.ExternalInterruptHandler = ExternalInterruptHandler;
+  InitializeSpinLock (&mExceptionHandlerData.DisplayMessageSpinLock);
+
+  UpdateIdtTable (IdtTable, &TemplateMap, &mExceptionHandlerData);
 
   //
   // Load Interrupt Descriptor Table
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
index 1f77f64..25eba6b 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
@@ -127,47 +127,50 @@ CommonExceptionHandler (
 /**
   Internal worker function to update IDT entries accordling to vector 
attributes.
 
-  @param[in] IdtTable   Pointer to IDT table.
-  @param[in] TemplateMapPointer to a buffer where the address map is 
returned.
-  @param[in] IdtEntryCount  IDT entries number to be updated.
+  @param[in] IdtTable  Pointer to IDT table.
+  @param[in] TemplateMap   Pointer to a buffer where the address map is
+   returned.
+  @param[in] ExceptionHandlerData  Pointer to exception handler data.
 
 **/
 VOID
 Update

[edk2] [Patch 2/9] UefiCpuPkg/ExceptionLib: Add EXCEPTION_HANDLER_DATA definition

[Jeff Fan]

Cc: Michael Kinney 
Cc: Jiewen Yao 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h | 9 -
 UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c   | 3 ++-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c   | 3 ++-
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index b28e9c5..0757aef 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -1,7 +1,7 @@
 /** @file
   Common header file for CPU Exception Handler Library.
 
-  Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2012 - 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
@@ -40,6 +40,13 @@ typedef struct {
   UINTN HookAfterStubHeaderStart;
 } EXCEPTION_HANDLER_TEMPLATE_MAP;
 
+typedef struct {
+  UINTN   IdtEntryCount;
+  SPIN_LOCK   DisplayMessageSpinLock;
+  RESERVED_VECTORS_DATA   *ReservedVectors;
+  EFI_CPU_INTERRUPT_HANDLER   *ExternalInterruptHandler;
+} EXCEPTION_HANDLER_DATA;
+
 extern CONST UINT32mErrorCodeFlag;
 extern CONST UINTN mImageAlignSize;
 extern CONST UINTN mDoFarReturnFlag;
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
index 6739a2c..6d16336 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
@@ -1,7 +1,7 @@
 /** @file
   CPU exception handler library implemenation for DXE modules.
 
-  Copyright (c) 2013, Intel Corporation. All rights reserved.
+  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
@@ -21,6 +21,7 @@ CONST UINTNmDoFarReturnFlag  = 0;
 
 extern SPIN_LOCK   mDisplayMessageSpinLock;
 extern EFI_CPU_INTERRUPT_HANDLER   *mExternalInterruptHandler;
+EXCEPTION_HANDLER_DATA  mExceptionHandlerData;
 
 /**
   Initializes all CPU exceptions entries and provides the default exception 
handlers.
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c
index 40f1250..3f9d001 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c
@@ -1,7 +1,7 @@
 /** @file
   CPU exception handler library implemenation for SMM modules.
 
-  Copyright (c) 2013, Intel Corporation. All rights reserved.
+  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
@@ -17,6 +17,7 @@
 
 CONST UINTN   mDoFarReturnFlag   = 1; 
 
+EXCEPTION_HANDLER_DATA  mExceptionHandlerData;
 /**
   Initializes all CPU exceptions entries and provides the default exception 
handlers.
   
-- 
2.7.4.windows.1

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

[edk2] [Patch 5/9] UefiCpuPkg/ExceptionLib: Update RegisterCpuInterruptHandlerWorker()

[Jeff Fan]

Add parameter CpuExceptionData for RegisterCpuInterruptHandlerWorker().

Cc: Michael Kinney 
Cc: Jiewen Yao 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 .../CpuExceptionHandlerLib/CpuExceptionCommon.h| 12 +
 .../Library/CpuExceptionHandlerLib/DxeException.c  |  2 +-
 .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c | 30 ++
 .../Library/CpuExceptionHandlerLib/SmmException.c  |  2 +-
 4 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index 99be61f..f2c44f0 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -152,10 +152,11 @@ InitializeCpuExceptionHandlersWorker (
 /**
   Registers a function to be called from the processor interrupt handler.
 
-  @param[in]  InterruptType Defines which interrupt or exception to hook.
-  @param[in]  InterruptHandler  A pointer to a function of type 
EFI_CPU_INTERRUPT_HANDLER that is called
-when a processor interrupt occurs. If this 
parameter is NULL, then the handler
-will be uninstalled.
+  @param[in]  InterruptTypeDefines which interrupt or exception to 
hook.
+  @param[in]  InterruptHandler A pointer to a function of type 
EFI_CPU_INTERRUPT_HANDLER that is called
+   when a processor interrupt occurs. If this 
parameter is NULL, then the handler
+   will be uninstalled
+  @param[in] ExceptionHandlerData  Pointer to exception handler data.
 
   @retval EFI_SUCCESS   The handler for the processor interrupt was 
successfully installed or uninstalled.
   @retval EFI_ALREADY_STARTED   InterruptHandler is not NULL, and a handler 
for InterruptType was
@@ -168,7 +169,8 @@ InitializeCpuExceptionHandlersWorker (
 EFI_STATUS
 RegisterCpuInterruptHandlerWorker (
   IN EFI_EXCEPTION_TYPEInterruptType,
-  IN EFI_CPU_INTERRUPT_HANDLER InterruptHandler
+  IN EFI_CPU_INTERRUPT_HANDLER InterruptHandler,
+  IN EXCEPTION_HANDLER_DATA*ExceptionHandlerData
   );
 
 /**
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
index cffb13a..5c4ee2a 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
@@ -179,5 +179,5 @@ RegisterCpuInterruptHandler (
   IN EFI_CPU_INTERRUPT_HANDLER InterruptHandler
   )
 {
-  return RegisterCpuInterruptHandlerWorker (InterruptType, InterruptHandler);
+  return RegisterCpuInterruptHandlerWorker (InterruptType, InterruptHandler, 
&mExceptionHandlerData);
 }
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
index 25eba6b..536c2a4 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
@@ -262,10 +262,11 @@ InitializeCpuExceptionHandlersWorker (
 /**
   Registers a function to be called from the processor interrupt handler.
 
-  @param[in]  InterruptType Defines which interrupt or exception to hook.
-  @param[in]  InterruptHandler  A pointer to a function of type 
EFI_CPU_INTERRUPT_HANDLER that is called
-when a processor interrupt occurs. If this 
parameter is NULL, then the handler
-will be uninstalled.
+  @param[in]  InterruptTypeDefines which interrupt or exception to 
hook.
+  @param[in]  InterruptHandler A pointer to a function of type 
EFI_CPU_INTERRUPT_HANDLER that is called
+   when a processor interrupt occurs. If this 
parameter is NULL, then the handler
+   will be uninstalled
+  @param[in] ExceptionHandlerData  Pointer to exception handler data.
 
   @retval EFI_SUCCESS   The handler for the processor interrupt was 
successfully installed or uninstalled.
   @retval EFI_ALREADY_STARTED   InterruptHandler is not NULL, and a handler 
for InterruptType was
@@ -278,23 +279,32 @@ InitializeCpuExceptionHandlersWorker (
 EFI_STATUS
 RegisterCpuInterruptHandlerWorker (
   IN EFI_EXCEPTION_TYPEInterruptType,
-  IN EFI_CPU_INTERRUPT_HANDLER InterruptHandler
+  IN EFI_CPU_INTERRUPT_HANDLER InterruptHandler,
+  IN EXCEPTION_HANDLER_DATA*ExceptionHandlerData
   )
 {
-  if (InterruptType < 0 || InterruptType >= 
(EFI_EXCEPTION_TYPE)mEnabledInterruptNum ||
-  mReservedVectors[InterruptType].Attribute == 
EFI_VECTOR_HANDOFF_DO_NOT_HOOK) {
+  UINTN  EnabledInterruptNum;
+  RESERVED_VECTORS_DATA  *ReservedVectors

[edk2] [Patch 1/9] UefiCpuPkg/ExceptionLib: Rename DxeSmmCpuException.c

[Jeff Fan]

Rename DxeSmmCpuException.c to PeiDxeSmmCpuException.c that will be used by
PeiCpuExceptionHandlerLib.

Cc: Michael Kinney 
Cc: Jiewen Yao 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 .../DxeCpuExceptionHandlerLib.inf  |   4 +-
 .../CpuExceptionHandlerLib/DxeSmmCpuException.c| 292 -
 .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c | 292 +
 .../SmmCpuExceptionHandlerLib.inf  |   4 +-
 4 files changed, 296 insertions(+), 296 deletions(-)
 delete mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeSmmCpuException.c
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c

diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
index 316ed55..2d32149 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
@@ -1,7 +1,7 @@
 ## @file
 #  CPU Exception Handler library instance for DXE modules.
 #
-#  Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.
+#  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
@@ -42,7 +42,7 @@
 [Sources.common]
   CpuExceptionCommon.h
   CpuExceptionCommon.c
-  DxeSmmCpuException.c
+  PeiDxeSmmCpuException.c
   DxeException.c
 
 [Packages]
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeSmmCpuException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeSmmCpuException.c
deleted file mode 100644
index d1291aa..000
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeSmmCpuException.c
+++ /dev/null
@@ -1,292 +0,0 @@
-/** @file
-  CPU Exception Library provides DXE/SMM CPU common exception handler.
-
-Copyright (c) 2012 - 2013, 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 that 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.
-
-**/
-
-#include "CpuExceptionCommon.h"
-#include 
-
-//
-// Spinlock for CPU information display
-//
-SPIN_LOCKmDisplayMessageSpinLock;
-
-//
-// Image align size for DXE/SMM
-//
-CONST UINTN  mImageAlignSize = SIZE_4KB;
-
-RESERVED_VECTORS_DATA   mReservedVectorsData[CPU_EXCEPTION_NUM];
-EFI_CPU_INTERRUPT_HANDLER   mExternalInterruptHandlerTable[CPU_EXCEPTION_NUM];
-EFI_CPU_INTERRUPT_HANDLER   *mExternalInterruptHandler = NULL;
-UINTN   mEnabledInterruptNum = 0;
-
-/**
-  Common exception handler.
-
-  @param ExceptionType  Exception type.
-  @param SystemContext  Pointer to EFI_SYSTEM_CONTEXT.
-**/
-VOID
-EFIAPI
-CommonExceptionHandler (
-  IN EFI_EXCEPTION_TYPE  ExceptionType, 
-  IN EFI_SYSTEM_CONTEXT  SystemContext
-  )
-{
-  EXCEPTION_HANDLER_CONTEXT  *ExceptionHandlerContext;
-
-  ExceptionHandlerContext = (EXCEPTION_HANDLER_CONTEXT *) (UINTN) 
(SystemContext.SystemContextIa32);
-
-  switch (mReservedVectors[ExceptionType].Attribute) {
-  case EFI_VECTOR_HANDOFF_HOOK_BEFORE:
-//
-// Need to jmp to old IDT handler after this exception handler
-//
-ExceptionHandlerContext->ExceptionDataFlag = (mErrorCodeFlag & (1 << 
ExceptionType)) ? TRUE : FALSE;
-ExceptionHandlerContext->OldIdtHandler = 
mReservedVectors[ExceptionType].ExceptonHandler;
-break;
-  case EFI_VECTOR_HANDOFF_HOOK_AFTER:
-while (TRUE) {
-  //
-  // If if anyone has gotten SPIN_LOCK for owner running hook after
-  //
-  if (AcquireSpinLockOrFail (&mReservedVectors[ExceptionType].SpinLock)) {
-//
-// Need to execute old IDT handler before running this exception 
handler
-//
-mReservedVectors[ExceptionType].ApicId = GetApicId ();
-ArchSaveExceptionContext (ExceptionType, SystemContext);
-ExceptionHandlerContext->ExceptionDataFlag = (mErrorCodeFlag & (1 << 
ExceptionType)) ? TRUE : FALSE;
-ExceptionHandlerContext->OldIdtHandler = 
mReservedVectors[ExceptionType].ExceptonHandler;
-return;
-  }
-  //
-  // If failed to acquire SPIN_LOCK, check if it was locked by processor 
itself
-  //
-  if (mReservedVectors[ExceptionType].ApicId == GetApicId ()) {
-//
-// Old IDT handler has been executed, then retore CPU exception 
content to
-// run new exception handler.
-//
-ArchRestoreExceptionContex

[edk2] [Patch 3/9] UefiCpuPkg/ExceptionLib: Update InitializeCpuExceptionHandlersWorker

[Jeff Fan]

Add parameter CpuExceptionData for InitializeCpuExceptionHandlersWorker().

Cc: Michael Kinney 
Cc: Jiewen Yao 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 .../Library/CpuExceptionHandlerLib/CpuExceptionCommon.h   |  6 --
 UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c  |  7 ++-
 .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c| 15 +--
 UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c  |  7 ++-
 4 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index 0757aef..812469b 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -134,7 +134,8 @@ DumpCpuContent (
 /**
   Internal worker function to initialize exception handler.
 
-  @param[in]  VectorInfoPointer to reserved vector list.
+  @param[in]  VectorInfoPointer to reserved vector list.
+  @param[in, out] ExceptionHandlerData  Pointer to exception handler data.
   
   @retval EFI_SUCCESS   CPU Exception Entries have been successfully 
initialized 
 with default exception handlers.
@@ -144,7 +145,8 @@ DumpCpuContent (
 **/
 EFI_STATUS
 InitializeCpuExceptionHandlersWorker (
-  IN EFI_VECTOR_HANDOFF_INFO   *VectorInfo OPTIONAL
+  IN EFI_VECTOR_HANDOFF_INFO   *VectorInfo OPTIONAL,
+  IN OUT EXCEPTION_HANDLER_DATA*ExceptionHandlerData
   );
 
 /**
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
index 6d16336..92de04c 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
@@ -21,6 +21,8 @@ CONST UINTNmDoFarReturnFlag  = 0;
 
 extern SPIN_LOCK   mDisplayMessageSpinLock;
 extern EFI_CPU_INTERRUPT_HANDLER   *mExternalInterruptHandler;
+extern RESERVED_VECTORS_DATA   mReservedVectorsData[CPU_EXCEPTION_NUM];
+extern EFI_CPU_INTERRUPT_HANDLER   
mExternalInterruptHandlerTable[CPU_EXCEPTION_NUM];
 EXCEPTION_HANDLER_DATA  mExceptionHandlerData;
 
 /**
@@ -45,7 +47,10 @@ InitializeCpuExceptionHandlers (
   IN EFI_VECTOR_HANDOFF_INFO   *VectorInfo OPTIONAL
   )
 {
-  return InitializeCpuExceptionHandlersWorker (VectorInfo);
+  mExceptionHandlerData.ReservedVectors  = mReservedVectorsData;
+  mExceptionHandlerData.ExternalInterruptHandler = 
mExternalInterruptHandlerTable;
+  InitializeSpinLock (&mExceptionHandlerData.DisplayMessageSpinLock);
+  return InitializeCpuExceptionHandlersWorker (VectorInfo, 
&mExceptionHandlerData);
 }
 
 /**
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
index d1291aa..1f77f64 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
@@ -1,7 +1,7 @@
 /** @file
   CPU Exception Library provides DXE/SMM CPU common exception handler.
 
-Copyright (c) 2012 - 2013, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 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 that accompanies this distribution.
 The full text of the license may be found at
@@ -201,7 +201,8 @@ UpdateIdtTable (
 /**
   Internal worker function to initialize exception handler.
 
-  @param[in]  VectorInfoPointer to reserved vector list.
+  @param[in]  VectorInfoPointer to reserved vector list.
+  @param[in, out] ExceptionHandlerData  Pointer to exception handler data.
   
   @retval EFI_SUCCESS   CPU Exception Entries have been successfully 
initialized 
 with default exception handlers.
@@ -211,7 +212,8 @@ UpdateIdtTable (
 **/
 EFI_STATUS
 InitializeCpuExceptionHandlersWorker (
-  IN EFI_VECTOR_HANDOFF_INFO   *VectorInfo OPTIONAL
+  IN EFI_VECTOR_HANDOFF_INFO   *VectorInfo OPTIONAL,
+  IN OUT EXCEPTION_HANDLER_DATA*ExceptionHandlerData
   )
 {
   EFI_STATUS   Status;
@@ -219,11 +221,12 @@ InitializeCpuExceptionHandlersWorker (
   UINTNIdtEntryCount;
   EXCEPTION_HANDLER_TEMPLATE_MAP   TemplateMap;
   IA32_IDT_GATE_DESCRIPTOR *IdtTable;
+  RESERVED_VECTORS_DATA*ReservedVectors;
 
-  mReservedVectors = mReservedVectorsData;
-  SetMem ((VOID *) mReservedVectors, sizeof (RESERVED_VECTORS_DATA) * 
CPU_EXCEPTION_NUM, 0xff);
+  ReservedVectors = ExceptionHandlerData->ReservedVectors;
+  SetMem ((VOID *) ReservedVectors, sizeof (RESERVED_VECTORS_DATA) * 
CPU_EXCEPTION_NUM, 0xff);
   if (VectorInfo != NULL) {
-Status =

[edk2] [Patch 0/9] UefiCpuPkg/PeiCpuExceptionHandlerLib

[Jeff Fan]

Add one new PeiCpuExceptionHandlerLib. It is used to be linked by CpuMpPei
module to register CPU exception handler. It could handle reserved vector list
and use spin lock to prevent dump message corrupted when BSP/APs encounter the
exception simultaneously.

Jeff Fan (9):
  UefiCpuPkg/ExceptionLib: Rename DxeSmmCpuException.c
  UefiCpuPkg/ExceptionLib: Add EXCEPTION_HANDLER_DATA definition
  UefiCpuPkg/ExceptionLib: Update InitializeCpuExceptionHandlersWorker
  UefiCpuPkg/ExceptionLib: Update UpdateIdtTable()
  UefiCpuPkg/ExceptionLib: Update RegisterCpuInterruptHandlerWorker()
  UefiCpuPkg/ExceptionLib: Add CommonExceptionHandlerWorker()
  UefiCpuPkg/ExceptionLib: Move global variable location
  UefiCpuPkg/ExceptionLib: Import PeiCpuExceptionHandlerLib module
  UefiCpuPkg/CpuMpPei: Consume CpuExceptionHandlerLib

 UefiCpuPkg/CpuMpPei/CpuMpPei.c |  21 +-
 UefiCpuPkg/CpuMpPei/CpuMpPei.h |   4 +-
 UefiCpuPkg/CpuMpPei/CpuMpPei.inf   |   5 +-
 .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++-
 .../DxeCpuExceptionHandlerLib.inf  |   4 +-
 .../Library/CpuExceptionHandlerLib/DxeException.c  |  62 -
 .../CpuExceptionHandlerLib/DxeSmmCpuException.c| 292 
 .../CpuExceptionHandlerLib/PeiCpuException.c   | 188 +
 .../PeiCpuExceptionHandlerLib.inf  |  61 +
 .../PeiCpuExceptionHandlerLib.uni  |  22 ++
 .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c | 294 +
 .../SmmCpuExceptionHandlerLib.inf  |   4 +-
 .../Library/CpuExceptionHandlerLib/SmmException.c  |  38 ++-
 UefiCpuPkg/UefiCpuPkg.dsc  |   2 +
 14 files changed, 718 insertions(+), 329 deletions(-)
 delete mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeSmmCpuException.c
 create mode 100644 UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.uni
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c

-- 
2.7.4.windows.1

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

[edk2] [Patch 9/9] UefiCpuPkg/CpuMpPei: Consume CpuExceptionHandlerLib

[Jeff Fan]

Cc: Michael Kinney 
Cc: Jiewen Yao 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/CpuMpPei/CpuMpPei.c   | 21 +++--
 UefiCpuPkg/CpuMpPei/CpuMpPei.h   |  4 +++-
 UefiCpuPkg/CpuMpPei/CpuMpPei.inf |  5 -
 3 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
index ef1c281..4ed1da9 100644
--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
+++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
@@ -852,14 +852,31 @@ CpuMpPeimInit (
   IN CONST EFI_PEI_SERVICES **PeiServices
   )
 {
-  EFI_STATUS   Status;
-  PEI_CPU_MP_DATA  *PeiCpuMpData;
+  EFI_STATUS   Status;
+  PEI_CPU_MP_DATA *PeiCpuMpData;
+  EFI_VECTOR_HANDOFF_INFO *VectorInfo;
+  EFI_PEI_VECTOR_HANDOFF_INFO_PPI *VectorHandoffInfoPpi;
 
   //
   // Load new GDT table on BSP
   //
   AsmInitializeGdt (&mGdt);
   //
+  // Get Vector Hand-off Info PPI
+  //
+  VectorInfo = NULL;
+  Status = PeiServicesLocatePpi (
+ &gEfiVectorHandoffInfoPpiGuid,
+ 0,
+ NULL,
+ (VOID **)&VectorHandoffInfoPpi
+ );
+  if (Status == EFI_SUCCESS) {
+VectorInfo = VectorHandoffInfoPpi->Info;
+  }
+  Status = InitializeCpuExceptionHandlers (VectorInfo);
+  ASSERT_EFI_ERROR (Status);
+  //
   // Get wakeup buffer and copy AP reset code in it
   //
   PeiCpuMpData = PrepareAPStartupVector ();
diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.h b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
index 7c8a218..afbcb6e 100644
--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.h
+++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
@@ -1,7 +1,7 @@
 /** @file
   Definitions to install Multiple Processor PPI.
 
-  Copyright (c) 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2015 - 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
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -39,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "Microcode.h"
 
diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.inf b/UefiCpuPkg/CpuMpPei/CpuMpPei.inf
index 70b272e..445caf9 100644
--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.inf
+++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.inf
@@ -1,7 +1,7 @@
 ## @file
 #  CPU driver installs CPU PI Multi-processor PPI.
 #
-#  Copyright (c) 2015, Intel Corporation. All rights reserved.
+#  Copyright (c) 2015 - 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
@@ -50,6 +50,7 @@
 
 [Packages]
   MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
 
 [LibraryClasses]
@@ -67,6 +68,7 @@
   TimerLib
   UefiCpuLib
   CpuLib
+  CpuExceptionHandlerLib
 
 [Ppis]
   gEfiPeiMpServicesPpiGuid  ## PRODUCES
@@ -75,6 +77,7 @@
   ## SOMETIMES_CONSUMES
   ## SOMETIMES_PRODUCES
   gEfiSecPlatformInformation2PpiGuid
+  gEfiVectorHandoffInfoPpiGuid  ## SOMETIMES_CONSUMES
 
 [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber## CONSUMES
-- 
2.7.4.windows.1

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

[edk2] [Patch 6/9] UefiCpuPkg/ExceptionLib: Add CommonExceptionHandlerWorker()

[Jeff Fan]

Add internal worker function RegisterCpuInterruptHandlerWorker().

Cc: Michael Kinney 
Cc: Jiewen Yao 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 .../CpuExceptionHandlerLib/CpuExceptionCommon.h| 14 +++
 .../Library/CpuExceptionHandlerLib/DxeException.c  | 19 -
 .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c | 49 +++---
 .../Library/CpuExceptionHandlerLib/SmmException.c  | 16 +++
 4 files changed, 72 insertions(+), 26 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index f2c44f0..bbf8004 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -261,5 +261,19 @@ GetExceptionNameStr (
   IN EFI_EXCEPTION_TYPE  ExceptionType
   );
 
+/**
+  Internal worker function for common exception handler.
+
+  @param ExceptionType Exception type.
+  @param SystemContext Pointer to EFI_SYSTEM_CONTEXT.
+  @param ExceptionHandlerData  Pointer to exception handler data.
+**/
+VOID
+CommonExceptionHandlerWorker (
+  IN EFI_EXCEPTION_TYPE  ExceptionType, 
+  IN EFI_SYSTEM_CONTEXT  SystemContext,
+  IN EXCEPTION_HANDLER_DATA  *ExceptionHandlerData
+  );
+
 #endif
 
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
index 5c4ee2a..3320066 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
@@ -19,13 +19,28 @@
 
 CONST UINTNmDoFarReturnFlag  = 0;
 
-extern SPIN_LOCK   mDisplayMessageSpinLock;
 extern EFI_CPU_INTERRUPT_HANDLER   *mExternalInterruptHandler;
 extern RESERVED_VECTORS_DATA   mReservedVectorsData[CPU_EXCEPTION_NUM];
 extern EFI_CPU_INTERRUPT_HANDLER   
mExternalInterruptHandlerTable[CPU_EXCEPTION_NUM];
 EXCEPTION_HANDLER_DATA  mExceptionHandlerData;
 
 /**
+  Common exception handler.
+
+  @param ExceptionType  Exception type.
+  @param SystemContext  Pointer to EFI_SYSTEM_CONTEXT.
+**/
+VOID
+EFIAPI
+CommonExceptionHandler (
+  IN EFI_EXCEPTION_TYPE  ExceptionType, 
+  IN EFI_SYSTEM_CONTEXT  SystemContext
+  )
+{
+  CommonExceptionHandlerWorker (ExceptionType, SystemContext, 
&mExceptionHandlerData);
+}
+
+/**
   Initializes all CPU exceptions entries and provides the default exception 
handlers.
   
   Caller should try to get an array of interrupt and/or exception vectors that 
are in use and need to
@@ -96,7 +111,7 @@ InitializeCpuInterruptHandlers (
   return EFI_INVALID_PARAMETER;
 }
   }
-  InitializeSpinLock (&mDisplayMessageSpinLock);
+
   ExternalInterruptHandler = AllocateZeroPool (sizeof 
(EFI_CPU_INTERRUPT_HANDLER) * CPU_INTERRUPT_NUM);
   ASSERT (ExternalInterruptHandler != NULL);
 
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
index 536c2a4..59a5b45 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
@@ -15,10 +15,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include "CpuExceptionCommon.h"
 #include 
 
-//
-// Spinlock for CPU information display
-//
-SPIN_LOCKmDisplayMessageSpinLock;
 
 //
 // Image align size for DXE/SMM
@@ -31,49 +27,54 @@ EFI_CPU_INTERRUPT_HANDLER   *mExternalInterruptHandler = 
NULL;
 UINTN   mEnabledInterruptNum = 0;
 
 /**
-  Common exception handler.
+  Internal worker function for common exception handler.
 
-  @param ExceptionType  Exception type.
-  @param SystemContext  Pointer to EFI_SYSTEM_CONTEXT.
+  @param ExceptionType Exception type.
+  @param SystemContext Pointer to EFI_SYSTEM_CONTEXT.
+  @param ExceptionHandlerData  Pointer to exception handler data.
 **/
 VOID
-EFIAPI
-CommonExceptionHandler (
+CommonExceptionHandlerWorker (
   IN EFI_EXCEPTION_TYPE  ExceptionType, 
-  IN EFI_SYSTEM_CONTEXT  SystemContext
+  IN EFI_SYSTEM_CONTEXT  SystemContext,
+  IN EXCEPTION_HANDLER_DATA  *ExceptionHandlerData
   )
 {
   EXCEPTION_HANDLER_CONTEXT  *ExceptionHandlerContext;
+  RESERVED_VECTORS_DATA  *ReservedVectors;
+  EFI_CPU_INTERRUPT_HANDLER  *ExternalInterruptHandler;
 
-  ExceptionHandlerContext = (EXCEPTION_HANDLER_CONTEXT *) (UINTN) 
(SystemContext.SystemContextIa32);
+  ExceptionHandlerContext  = (EXCEPTION_HANDLER_CONTEXT *) (UINTN) 
(SystemContext.SystemContextIa32);
+  ReservedVectors  = ExceptionHandlerData->ReservedVectors;
+  ExternalInterruptHandler = ExceptionHandlerData->ExternalInterruptHandler;
 
-  switch (mReservedVectors[ExceptionType].Attribute) {
+  switch (ReservedVectors[ExceptionT

[edk2] [Patch 8/9] UefiCpuPkg/ExceptionLib: Import PeiCpuExceptionHandlerLib module

[Jeff Fan]

This module could be linked by CpuMpPei driver to handle reserved vector list
and provide spin lock for BSP/APs to prevent dump message corrupted.

Cc: Michael Kinney 
Cc: Jiewen Yao 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 .../CpuExceptionHandlerLib/PeiCpuException.c   | 188 +
 .../PeiCpuExceptionHandlerLib.inf  |  61 +++
 .../PeiCpuExceptionHandlerLib.uni  |  22 +++
 UefiCpuPkg/UefiCpuPkg.dsc  |   2 +
 4 files changed, 273 insertions(+)
 create mode 100644 UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.uni

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c
new file mode 100644
index 000..a45cffa
--- /dev/null
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c
@@ -0,0 +1,188 @@
+/** @file
+  CPU exception handler library implementation for PEIM module.
+
+Copyright (c) 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 that 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.
+
+**/
+
+#include 
+#include "CpuExceptionCommon.h"
+#include 
+#include 
+#include 
+
+//
+// Image Alignment size for PEI phase
+//
+CONST UINTNmImageAlignSize   = 4;
+CONST UINTNmDoFarReturnFlag  = 0;
+
+#define CPU_EXCEPTION_HANDLER_LIB_HOB_GUID \
+  { \
+0xb21d9148, 0x9211, 0x4d8f, { 0xad, 0xd3, 0x66, 0xb1, 0x89, 0xc9, 0x2c, 
0x83 } \
+  }
+EFI_GUID mCpuExceptrionHandlerLibHobGuid = CPU_EXCEPTION_HANDLER_LIB_HOB_GUID;
+
+/**
+  Get exception handler data pointer from GUIDed HOb.
+
+  @return  pointer to exception handler data. 
+**/
+EXCEPTION_HANDLER_DATA *
+GetExceptionHandlerData (
+  VOID
+  )
+{
+  EFI_HOB_GUID_TYPE   *GuidHob;
+  VOID*DataInHob;
+  EXCEPTION_HANDLER_DATA  *ExceptionHandlerData;
+
+  ExceptionHandlerData = NULL;
+  GuidHob = GetFirstGuidHob (&mCpuExceptrionHandlerLibHobGuid);
+  if (GuidHob != NULL) {
+DataInHob = GET_GUID_HOB_DATA (GuidHob);
+ExceptionHandlerData = (EXCEPTION_HANDLER_DATA *)(*(UINTN *)DataInHob);
+  }
+  ASSERT (ExceptionHandlerData != NULL);
+  return ExceptionHandlerData;
+}
+
+/**
+  Common exception handler.
+
+  @param ExceptionType  Exception type.
+  @param SystemContext  Pointer to EFI_SYSTEM_CONTEXT.
+**/
+VOID
+EFIAPI
+CommonExceptionHandler (
+  IN EFI_EXCEPTION_TYPE   ExceptionType, 
+  IN EFI_SYSTEM_CONTEXT   SystemContext
+  )
+{
+  EXCEPTION_HANDLER_DATA  *ExceptionHandlerData;
+
+  ExceptionHandlerData = GetExceptionHandlerData ();
+  CommonExceptionHandlerWorker (ExceptionType, SystemContext, 
ExceptionHandlerData);
+}
+
+/**
+  Initializes all CPU exceptions entries and provides the default exception 
handlers.
+  
+  Caller should try to get an array of interrupt and/or exception vectors that 
are in use and need to
+  persist by EFI_VECTOR_HANDOFF_INFO defined in PI 1.3 specification.
+  If caller cannot get reserved vector list or it does not exists, set 
VectorInfo to NULL. 
+  If VectorInfo is not NULL, the exception vectors will be initialized per 
vector attribute accordingly.
+  Note: Before invoking this API, caller must allocate memory for IDT table 
and load 
+IDTR by AsmWriteIdtr().
+
+  @param[in]  VectorInfoPointer to reserved vector list.
+  
+  @retval EFI_SUCCESS   CPU Exception Entries have been successfully 
initialized 
+with default exception handlers.
+  @retval EFI_INVALID_PARAMETER VectorInfo includes the invalid content if 
VectorInfo is not NULL.
+  @retval EFI_UNSUPPORTED   This function is not supported.
+
+**/
+EFI_STATUS
+EFIAPI
+InitializeCpuExceptionHandlers (
+  IN EFI_VECTOR_HANDOFF_INFO   *VectorInfo OPTIONAL
+  )
+{
+  EFI_STATUS   Status;
+  EXCEPTION_HANDLER_DATA   *ExceptionHandlerData;
+  RESERVED_VECTORS_DATA*ReservedVectors;
+
+  ReservedVectors = AllocatePool (sizeof (RESERVED_VECTORS_DATA) * 
CPU_EXCEPTION_NUM);
+  ASSERT (ReservedVectors != NULL);
+
+  ExceptionHandlerData = AllocatePool (sizeof (EXCEPTION_HANDLER_DATA));
+  ASSERT (ExceptionHandlerData != NULL);
+  ExceptionHandlerData->ReservedVectors  = ReservedVectors;
+  ExceptionHandlerData->ExternalInterruptHandler = NULL;
+  InitializeSpinLock (&ExceptionHandlerData->DisplayMessageSpinLock);
+
+  Status = InitializeCpuExceptionHandlersWorker

[edk2] [Patch 7/9] UefiCpuPkg/ExceptionLib: Move global variable location

[Jeff Fan]

Move some global variables location from PeiDxeSmmCpuException.c to
DxeCpuException.c and SmmCpuException.c. And remove some un-used global
vairables.

Cc: Michael Kinney 
Cc: Jiewen Yao 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 .../Library/CpuExceptionHandlerLib/DxeException.c | 12 +---
 .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c| 19 +--
 .../Library/CpuExceptionHandlerLib/SmmException.c | 14 --
 3 files changed, 22 insertions(+), 23 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
index 3320066..a61a52b 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
@@ -19,9 +19,15 @@
 
 CONST UINTNmDoFarReturnFlag  = 0;
 
-extern EFI_CPU_INTERRUPT_HANDLER   *mExternalInterruptHandler;
-extern RESERVED_VECTORS_DATA   mReservedVectorsData[CPU_EXCEPTION_NUM];
-extern EFI_CPU_INTERRUPT_HANDLER   
mExternalInterruptHandlerTable[CPU_EXCEPTION_NUM];
+//
+// Image align size for DXE/SMM
+//
+CONST UINTN  mImageAlignSize = SIZE_4KB;
+
+RESERVED_VECTORS_DATA   mReservedVectorsData[CPU_EXCEPTION_NUM];
+EFI_CPU_INTERRUPT_HANDLER   mExternalInterruptHandlerTable[CPU_EXCEPTION_NUM];
+UINTN   mEnabledInterruptNum = 0;
+
 EXCEPTION_HANDLER_DATA  mExceptionHandlerData;
 
 /**
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
index 59a5b45..60f3fdb 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c
@@ -15,17 +15,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include "CpuExceptionCommon.h"
 #include 
 
-
-//
-// Image align size for DXE/SMM
-//
-CONST UINTN  mImageAlignSize = SIZE_4KB;
-
-RESERVED_VECTORS_DATA   mReservedVectorsData[CPU_EXCEPTION_NUM];
-EFI_CPU_INTERRUPT_HANDLER   mExternalInterruptHandlerTable[CPU_EXCEPTION_NUM];
-EFI_CPU_INTERRUPT_HANDLER   *mExternalInterruptHandler = NULL;
-UINTN   mEnabledInterruptNum = 0;
-
 /**
   Internal worker function for common exception handler.
 
@@ -196,11 +185,6 @@ UpdateIdtTable (
   break;
 }
   }
- 
-  //
-  // Save Interrupt number to global variable used for 
RegisterCpuInterruptHandler ()
-  //
-  mEnabledInterruptNum = ExceptionHandlerData->IdtEntryCount;
 }
 
 /**
@@ -237,7 +221,6 @@ InitializeCpuExceptionHandlersWorker (
 }
   }
 
-  mExternalInterruptHandler = mExternalInterruptHandlerTable;
   //
   // Read IDT descriptor and calculate IDT size
   //
@@ -256,7 +239,7 @@ InitializeCpuExceptionHandlersWorker (
 
   ExceptionHandlerData->IdtEntryCount = IdtEntryCount;
   UpdateIdtTable (IdtTable, &TemplateMap, ExceptionHandlerData);
-  mEnabledInterruptNum = IdtEntryCount;
+
   return EFI_SUCCESS;
 }
 
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c
index 3528c8c..7ad228c 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c
@@ -17,8 +17,18 @@
 
 CONST UINTN   mDoFarReturnFlag   = 1; 
 
-extern RESERVED_VECTORS_DATA   mReservedVectorsData[CPU_EXCEPTION_NUM];
-extern EFI_CPU_INTERRUPT_HANDLER   
mExternalInterruptHandlerTable[CPU_EXCEPTION_NUM];
+//
+// Spin lock for CPU information display
+//
+SPIN_LOCKmDisplayMessageSpinLock;
+
+//
+// Image align size for DXE/SMM
+//
+CONST UINTN  mImageAlignSize = SIZE_4KB;
+
+RESERVED_VECTORS_DATA   mReservedVectorsData[CPU_EXCEPTION_NUM];
+EFI_CPU_INTERRUPT_HANDLER   mExternalInterruptHandlerTable[CPU_EXCEPTION_NUM];
 EXCEPTION_HANDLER_DATA  mExceptionHandlerData;
 /**
   Common exception handler.
-- 
2.7.4.windows.1

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

Re: [edk2] [PATCH v2] MdeModulePkg RamDiskDxe: VALID_ARCH cleanup to list supported options

[Tian, Feng]

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Wu, Hao A 
Sent: Tuesday, May 24, 2016 11:26 AM
To: edk2-devel@lists.01.org; Tian, Feng 
Cc: Wu, Hao A 
Subject: [PATCH v2] MdeModulePkg RamDiskDxe: VALID_ARCH cleanup to list 
supported options

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/MdeModulePkg.dsc | 2 +-
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc 
index 936f46d..abce62d 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -330,7 +330,6 @@
   MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
   MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
   MdeModulePkg/Universal/Disk/CdExpressPei/CdExpressPei.inf
-  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
   MdeModulePkg/Universal/DriverSampleDxe/DriverSampleDxe.inf
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   
MdeModulePkg/Universal/MemoryTest/GenericMemoryTestDxe/GenericMemoryTestDxe.inf
@@ -449,6 +448,7 @@
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmDxe.inf
   MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
   
MdeModulePkg/Universal/SmmCommunicationBufferDxe/SmmCommunicationBufferDxe.inf
+  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 
 [Components.X64]
   MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf
diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
index d1eb429..cdd2da6 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
@@ -26,7 +26,7 @@
 #
 # The following information is for reference only and not required by the 
build tools.
 #
-#  VALID_ARCHITECTURES  = IA32 X64 IPF EBC
+#  VALID_ARCHITECTURES  = IA32 X64 ARM AARCH64
 #
 
 [Sources]
--
1.9.5.msysgit.0

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

Re: [edk2] [PATCH] MdeModulePkg NvmExpressDxe: Fix VS2010 build error

[Tian, Feng]

Suggest you move the Status assignment before the for loop.

If you do this, you can get my reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Wu, Hao A 
Sent: Wednesday, May 25, 2016 10:16 AM
To: edk2-devel@lists.01.org; Tian, Feng ; Qiu, Shumin 

Cc: Wu, Hao A 
Subject: [PATCH] MdeModulePkg NvmExpressDxe: Fix VS2010 build error

Potentially uninitialized 'Status' might be returned in functions
NvmeCreateIoCompletionQueue() and NvmeCreateIoSubmissionQueue() in file 
NvmExpressHci.c.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
index dcfe1e8..09e8263 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
@@ -684,7 +684,7 @@ NvmeCreateIoCompletionQueue (
   NVME_ADMIN_CRIOCQCrIoCq;
   UINT32   Index;
 
-  for (Index = 1; Index < NVME_MAX_QUEUES; Index++) {
+  for (Index = 1, Status = EFI_SUCCESS; Index < NVME_MAX_QUEUES; 
+ Index++) {
 ZeroMem (&CommandPacket, sizeof(EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET));
 ZeroMem (&Command, sizeof(EFI_NVM_EXPRESS_COMMAND));
 ZeroMem (&Completion, sizeof(EFI_NVM_EXPRESS_COMPLETION));
@@ -740,7 +740,7 @@ NvmeCreateIoSubmissionQueue (
   NVME_ADMIN_CRIOSQCrIoSq;
   UINT32   Index;
 
-  for (Index = 1; Index < NVME_MAX_QUEUES; Index++) {
+  for (Index = 1, Status = EFI_SUCCESS; Index < NVME_MAX_QUEUES; 
+ Index++) {
 ZeroMem (&CommandPacket, sizeof(EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET));
 ZeroMem (&Command, sizeof(EFI_NVM_EXPRESS_COMMAND));
 ZeroMem (&Completion, sizeof(EFI_NVM_EXPRESS_COMPLETION));
--
1.9.5.msysgit.0

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