[edk2] Unable to boot OVMF on qemu-x86_64

[Prakhya, Sai Praneeth]

Hi All,

I am facing an issue booting OVMF on qemu, could you please help me?
I have cloned EDKII, and built OVMF for X64 using GCC5. I have followed the 
steps given at https://wiki.ubuntu.com/UEFI/EDK2. Then I have used 
qemu-system-x86_64 to boot OVMF, but it fails, I don't see anything on tty0 of 
qemu. When I tried the same by changing to IA32 it seems working. So, could 
anyone please let me know what I am missing or maybe someone give it a try and 
see it it's reproducible or not...
I am using Ubuntu 15.04 as my build system.

Regards,
Sai

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

Re: [edk2] [edk2-BuildSpecification PATCH] Clarify alignment requirements for VPD VOID* PCDs

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Tuesday, April 18, 2017 12:41 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-BuildSpecification PATCH] Clarify alignment requirements for VPD 
VOID* PCDs

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

Clarify when error or warning messages are generated for VOID* PCDs when VPD 
offset is not aligned.
Unicode string VPD PCDs must be 2-byte aligned.
Byte array {} VPD PCDs should be 8-byte aligned, but is only a warning message 
if they are not 8-byte aligned. All other data types only require 
byte-alignment.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 7_build_environment/73_guided_tools.md | 16 ++--
 README.md  |  1 +
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/7_build_environment/73_guided_tools.md 
b/7_build_environment/73_guided_tools.md
index 878ae33..a8881d3 100644
--- a/7_build_environment/73_guided_tools.md
+++ b/7_build_environment/73_guided_tools.md
@@ -123,8 +123,20 @@ file required by the build system is provided in the 
appendix, VPD Tool.
 
   * ASCII strings, "string", will be byte aligned.
   * Unicode strings, L"string" will be two-byte aligned.
-  * Byte arrays, {0x00, 0x01} will be 8-byte aligned. If the developer assigns
-offset values in the DSC file, the developer must follow the same rules.
+  * Byte arrays, {0x00, 0x01} will be 8-byte aligned.
+
+  If the developer manually assigns offset values in the DSC file, the 
+ developer  must follow the same rules.
+
+  **
+  **Note:** If a developer manually sets the offset of a `VOID*` PCD 
+ with  Unicode string, L"string", style to a value that is not 2-byte 
+ aligned, then  an error is generated and the build halts.
+  **
+  **Note:** If a developer manually sets the offset of a `VOID*` PCD 
+ with byte  array {} style to a value that is not 8-byte aligned, then 
+ a warning is  generated, but the build will continue.
+  **
 
 2. Modify the FDF file:
 
diff --git a/README.md b/README.md
index 71c4511..8542434 100644
--- a/README.md
+++ b/README.md
@@ -203,3 +203,4 @@ Copyright (c) 2008-2017, Intel Corporation. All rights 
reserved.
 | 1.27   | Convert to Gitbook  



| April 2017|
 || [#471](https://bugzilla.tianocore.org/show_bug.cgi?id=471) 
Build spec: only copy the "TianoCore" Userextension section into "As Built" INF 


 |   |
 || [#472](https://bugzilla.tianocore.org/show_bug.cgi?id=472) 
[Build Spec] Extend macro usage in the !include statements for DSC/FDF files


 |   |
+|| [#490](https://bugzilla.tianocore.org/show_bug.cgi?id=490) 
Build Spec: specify the alignment requirements for VOID* PCDs stored in a PCD 
section 

   |   |
--
2.6.3.windows.1

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

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3] Fix setup assert issue

[Guo, Mang]

Debug BIOS will assert if change setup and save.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Guo Mang 
---
 .../PlatformSettings/PlatformSetupDxe/SetupInfoRecords.c  | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/SetupInfoRecords.c
 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/SetupInfoRecords.c
index d504995..768893e 100644
--- 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/SetupInfoRecords.c
+++ 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/SetupInfoRecords.c
@@ -1808,7 +1808,6 @@ CheckSystemConfigSave (
   SEC_INFOMATION  SeCInfo;
   UINT8   SecureBootCfg;
   UINTN   DataSize;
-  BOOLEAN SecureBootNotFound;
 
   Status = gBS->LocateProtocol (
   ,
@@ -1831,7 +1830,6 @@ CheckSystemConfigSave (
   // Secure Boot configuration changes
   //
   DataSize = sizeof (SecureBootCfg);
-  SecureBootNotFound = FALSE;
   Status = gRT->GetVariable (
   EFI_SECURE_BOOT_ENABLE_NAME,
   ,
@@ -1841,18 +1839,7 @@ CheckSystemConfigSave (
   );
 
   if (EFI_ERROR (Status)) {
-SecureBootNotFound = TRUE;
-  }
-
-  if (SecureBootNotFound) {
-Status = gRT->GetVariable (
-EFI_SECURE_BOOT_ENABLE_NAME,
-,
-NULL,
-,
-
-);
-ASSERT_EFI_ERROR (Status);
+SecureBootCfg = 0;
   }
 
   if ((SecureBootCfg) != SystemConfigPtr->SecureBoot) {
-- 
2.10.1.windows.1

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

Re: [edk2] [patch] MdeModulePkg/BMMUiLib: Update codes of initializing ConsoleXXXCheck array

[Dong, Eric]

Reviewed-by: Eric Dong 

-Original Message-
From: Bi, Dandan 
Sent: Tuesday, April 18, 2017 11:50 AM
To: edk2-devel@lists.01.org
Cc: Dong, Eric
Subject: [patch] MdeModulePkg/BMMUiLib: Update codes of initializing 
ConsoleXXXCheck array

When initializing ConsoleOutCheck/ConsoleInCheck/ConsoleErrCheck array in 
BMM_FAKE_NV_DATA structure, also need to consider whether the terminal device 
is ConOut/ConIn/ConErr or not.

Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 .../BootMaintenanceManagerUiLib/ConsoleOption.c| 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/ConsoleOption.c 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/ConsoleOption.c
index a145a77..b25c7a6 100644
--- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/ConsoleOption.c
+++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/ConsoleOption.c
@@ -1029,20 +1029,28 @@ GetConsoleInCheck (  {
   UINT16  Index;
   BM_MENU_ENTRY   *NewMenuEntry; 
   UINT8   *ConInCheck;
   BM_CONSOLE_CONTEXT  *NewConsoleContext;
+  BM_TERMINAL_CONTEXT *NewTerminalContext;
 
   ASSERT (CallbackData != NULL);
 
   ConInCheck = >BmmFakeNvData.ConsoleInCheck[0];
   for (Index = 0; ((Index < ConsoleInpMenu.MenuNumber) && \
(Index < MAX_MENU_NUMBER)) ; Index++) {  
 NewMenuEntry  = BOpt_GetMenuEntry (, Index);
 NewConsoleContext = (BM_CONSOLE_CONTEXT *) NewMenuEntry->VariableContext;  
 ConInCheck[Index] = NewConsoleContext->IsActive;
   }
+
+  for (Index = 0; Index < TerminalMenu.MenuNumber; Index++) {
+NewMenuEntry= BOpt_GetMenuEntry (, Index);
+NewTerminalContext  = (BM_TERMINAL_CONTEXT *) 
NewMenuEntry->VariableContext;
+ASSERT (Index + ConsoleInpMenu.MenuNumber < MAX_MENU_NUMBER);
+ConInCheck[Index + ConsoleInpMenu.MenuNumber] = 
+ NewTerminalContext->IsConIn;  }
 }
 
 /**
 
   Initialize console output device check box to 
ConsoleOutCheck[MAX_MENU_NUMBER] @@ -1058,19 +1066,27 @@ GetConsoleOutCheck (  {
   UINT16  Index;
   BM_MENU_ENTRY   *NewMenuEntry; 
   UINT8   *ConOutCheck;
   BM_CONSOLE_CONTEXT  *NewConsoleContext;
-  
+  BM_TERMINAL_CONTEXT *NewTerminalContext;
+
   ASSERT (CallbackData != NULL);
   ConOutCheck = >BmmFakeNvData.ConsoleOutCheck[0];
   for (Index = 0; ((Index < ConsoleOutMenu.MenuNumber) && \
(Index < MAX_MENU_NUMBER)) ; Index++) {  
 NewMenuEntry  = BOpt_GetMenuEntry (, Index);
 NewConsoleContext = (BM_CONSOLE_CONTEXT *) NewMenuEntry->VariableContext;  
 ConOutCheck[Index] = NewConsoleContext->IsActive;
   }
+
+  for (Index = 0; Index < TerminalMenu.MenuNumber; Index++) {
+NewMenuEntry= BOpt_GetMenuEntry (, Index);
+NewTerminalContext  = (BM_TERMINAL_CONTEXT *) 
NewMenuEntry->VariableContext;
+ASSERT (Index + ConsoleOutMenu.MenuNumber < MAX_MENU_NUMBER);
+ConOutCheck[Index + ConsoleOutMenu.MenuNumber] = 
+ NewTerminalContext->IsConOut;  }
 }
 
 /**
 
   Initialize standard error output device check box to 
ConsoleErrCheck[MAX_MENU_NUMBER] @@ -1086,19 +1102,27 @@ GetConsoleErrCheck (  {
   UINT16  Index;
   BM_MENU_ENTRY   *NewMenuEntry; 
   UINT8   *ConErrCheck;
   BM_CONSOLE_CONTEXT  *NewConsoleContext;
+  BM_TERMINAL_CONTEXT *NewTerminalContext;
 
   ASSERT (CallbackData != NULL);
   ConErrCheck = >BmmFakeNvData.ConsoleErrCheck[0];
   for (Index = 0; ((Index < ConsoleErrMenu.MenuNumber) && \
(Index < MAX_MENU_NUMBER)) ; Index++) {  
 NewMenuEntry  = BOpt_GetMenuEntry (, Index);
 NewConsoleContext = (BM_CONSOLE_CONTEXT *) NewMenuEntry->VariableContext;  
 ConErrCheck[Index] = NewConsoleContext->IsActive;
   }
+
+  for (Index = 0; Index < TerminalMenu.MenuNumber; Index++) {
+NewMenuEntry= BOpt_GetMenuEntry (, Index);
+NewTerminalContext  = (BM_TERMINAL_CONTEXT *) 
NewMenuEntry->VariableContext;
+ASSERT (Index + ConsoleErrMenu.MenuNumber < MAX_MENU_NUMBER);
+ConErrCheck[Index + ConsoleErrMenu.MenuNumber] = 
+ NewTerminalContext->IsStdErr;  }
 }
 
 /**
 
   Initialize terminal attributes (baudrate, data rate, stop bits, parity and 
terminal type)
--
1.9.5.msysgit.1

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

[edk2] [edk2-BuildSpecification PATCH] Clarify alignment requirements for VPD VOID* PCDs

[Michael Kinney]

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

GitHub branch for review:

  
https://github.com/mdkinney/edk2-BuildSpecification/tree/Bugzilla_490_ClarifyVpdPcdAlignment

GitHub branch compare against latest DRAFT for review:

  
https://github.com/tianocore-docs/edk2-BuildSpecification/compare/master...mdkinney:Bugzilla_490_ClarifyVpdPcdAlignment?w=1

Clarify when error or warning messages are generated
for VOID* PCDs when VPD offset is not aligned.
Unicode string VPD PCDs must be 2-byte aligned.
Byte array {} VPD PCDs should be 8-byte aligned,
but is only a warning message if they are not 8-byte
aligned. All other data types only require
byte-alignment.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

Michael Kinney (1):
  Clarify alignment requirements for VPD VOID* PCDs

 7_build_environment/73_guided_tools.md | 16 ++--
 README.md  |  1 +
 2 files changed, 15 insertions(+), 2 deletions(-)

-- 
2.6.3.windows.1

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

[edk2] [edk2-BuildSpecification PATCH] Clarify alignment requirements for VPD VOID* PCDs

[Michael Kinney]

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

Clarify when error or warning messages are generated
for VOID* PCDs when VPD offset is not aligned.
Unicode string VPD PCDs must be 2-byte aligned.
Byte array {} VPD PCDs should be 8-byte aligned,
but is only a warning message if they are not 8-byte
aligned. All other data types only require
byte-alignment.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 7_build_environment/73_guided_tools.md | 16 ++--
 README.md  |  1 +
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/7_build_environment/73_guided_tools.md 
b/7_build_environment/73_guided_tools.md
index 878ae33..a8881d3 100644
--- a/7_build_environment/73_guided_tools.md
+++ b/7_build_environment/73_guided_tools.md
@@ -123,8 +123,20 @@ file required by the build system is provided in the 
appendix, VPD Tool.
 
   * ASCII strings, "string", will be byte aligned.
   * Unicode strings, L"string" will be two-byte aligned.
-  * Byte arrays, {0x00, 0x01} will be 8-byte aligned. If the developer assigns
-offset values in the DSC file, the developer must follow the same rules.
+  * Byte arrays, {0x00, 0x01} will be 8-byte aligned.
+
+  If the developer manually assigns offset values in the DSC file, the 
developer
+  must follow the same rules.
+
+  **
+  **Note:** If a developer manually sets the offset of a `VOID*` PCD with
+  Unicode string, L"string", style to a value that is not 2-byte aligned, then
+  an error is generated and the build halts.
+  **
+  **Note:** If a developer manually sets the offset of a `VOID*` PCD with byte
+  array {} style to a value that is not 8-byte aligned, then a warning is
+  generated, but the build will continue.
+  **
 
 2. Modify the FDF file:
 
diff --git a/README.md b/README.md
index 71c4511..8542434 100644
--- a/README.md
+++ b/README.md
@@ -203,3 +203,4 @@ Copyright (c) 2008-2017, Intel Corporation. All rights 
reserved.
 | 1.27   | Convert to Gitbook  



| April 2017|
 || [#471](https://bugzilla.tianocore.org/show_bug.cgi?id=471) 
Build spec: only copy the "TianoCore" Userextension section into "As Built" INF 


 |   |
 || [#472](https://bugzilla.tianocore.org/show_bug.cgi?id=472) 
[Build Spec] Extend macro usage in the !include statements for DSC/FDF files


 |   |
+|| [#490](https://bugzilla.tianocore.org/show_bug.cgi?id=490) 
Build Spec: specify the alignment requirements for VOID* PCDs stored in a PCD 
section 

   |   |
-- 
2.6.3.windows.1

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

Re: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Fix unconditional window shrinking

[Fu, Siyuan]

Hi, Andrey

Thanks for provide the log file. I think your point is right, that the server 
is not really reduce the window size, since it could still ACK the whole data 
to 199866. I searched the IETF and finally found the RFC7323, it’s an updated 
version of TCP window scale option, and discussed this problem in section 2.4 
as “Window Retraction”. We will evaluate this RFC and provide a patch to fix 
the problem. Once I have a patch I will let you know and maybe you can help to 
test it.
Thanks again for helping to address the problem.

Best Regards,
Siyuan

From: ate...@kraftway.ru [mailto:ate...@kraftway.ru]
Sent: 2017年4月17日 22:41
To: Fu, Siyuan ; edk2-devel@lists.01.org
Cc: Ye, Ting ; Tian, Feng ; Wu, Jiaxin 

Subject: Re: [PATCH 2/2] NetworkPkg/TcpDxe: Fix unconditional window shrinking


Hello, Siyuan



Sorry for providing incomplete log. I think missing packets is not the case 
here since all packets reached client. I made another log and I am attaching it 
to this email (full wireshark log from start of transmission). I am also 
attaching log from TcpDxe driver (added debug prints in TcpInput function as 
input and TcpTransmitSegment as output).

This log actually contains two cases: (1) in frame 145 (line 450 in TcpDxe log) 
advertised window reaches zero size, but after window update in frame 152 
transmission continues without deadlocks; (2) in frame 221 (line 698 in TcpDxe 
log) advertised window reaches zero again, but after window update we have a 
deadlock starting from frame 241.

Please notice how packets actually processed by TcpDxe driver. According to 
TcpDxe log server starts to shrink window in line 615  (frame 198). This seems 
to be shrinking, so i was wrong, thinking there was no shrinking at all, server 
indeed moves its Right edge to the left. TcpDxe driver catches this and prints 
message in line 615, though, no actual data shrinking happens here since Right 
> SndNxt. Same goes for next incoming packets (lines 616 - 627). At this point 
client have stopped sending data (line 611, frame 197) at SEQ 198418 (did he 
wait until he can send full MSS segment? which is 1448). In next packets (lines 
629 - 636) server opens its window again (moves Right edge to the right) and we 
have Right=199866 here. After receiving Right=199866 from server client can now 
send 1448 bytes of payload and he does (frame 208, line 638).

Starting from line 641 we have only input packets from server. Next packet 
forces client to move SndNxt to the left since client have just sent 
Seq:198418, End:199866 packet and server advertised Ack:156426, Wnd:43264, 
Right:199690. This packets ACKs old segment and advertises quite big window. 
Should client use values from this packet to reduce its SndNxt? Anyway, server 
shrinks Right to the value of 199642 but then it opens Right to the value of 
199866 in line 700 with ACK=199866. Does this mean that in general Right didn't 
move (yes, technically it moved left but then it restored to the original 
right)? Server without doubt accepted all data.

So maybe the bug here is to use 'intermediate' values from server to adjust 
SndNxt? Maybe we should calculate usable window right before sending data in 
TcpOutput?



Regards,

Andrey


On 17.04.2017 05:41, Fu, Siyuan wrote:
Hi, Andrey

For the question 1, that why client send out seq 590994, I don’t think it’s 
client side problem. We can see the server is moving the right edge if its 
receive window start from the beginning: the frame 4490, right edge is 590954, 
then it comes to 590946 (farme 4491), 590770 (frame 4492), 590754(frame 
4492)... Please note that these packets have not been received by the client 
side. I think why client send out frame 4496 with seq number to 590994, is 
because the server did advise a receive window for 590994 before frame 4490, 
and not shown in your dump log. Later the client send out frame 4500, which seq 
number is 590754, this is actually the right edge advised by the server’s frame 
4494. This means the client just received the frame  4494 after it send out the 
frame 4496, and this is the frame which really shrink the receive and make a 
negative useable in client side.
[cid:image002.png@01D2B839.0DE0F920]
I have check the new dump file, this time the server has never advise a right 
window edge on left of client’s SndNxt, that’s why the client won’t meet the 
“negative useable window” this time, not because your patch fixed the problem.

Best Regards,
Siyuan

From: ate...@kraftway.ru [mailto:ate...@kraftway.ru]
Sent: 2017年4月14日 21:32
To: Fu, Siyuan ; 
edk2-devel@lists.01.org
Cc: Ye, Ting ; Tian, Feng 
; Wu, Jiaxin 

Subject: Re: [PATCH 2/2] 

[edk2] [patch] MdeModulePkg/BMMUiLib: Update codes of initializing ConsoleXXXCheck array

[Dandan Bi]

When initializing ConsoleOutCheck/ConsoleInCheck/ConsoleErrCheck array in
BMM_FAKE_NV_DATA structure, also need to consider whether the terminal
device is ConOut/ConIn/ConErr or not.

Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 .../BootMaintenanceManagerUiLib/ConsoleOption.c| 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/ConsoleOption.c 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/ConsoleOption.c
index a145a77..b25c7a6 100644
--- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/ConsoleOption.c
+++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/ConsoleOption.c
@@ -1029,20 +1029,28 @@ GetConsoleInCheck (
 {
   UINT16  Index;
   BM_MENU_ENTRY   *NewMenuEntry; 
   UINT8   *ConInCheck;
   BM_CONSOLE_CONTEXT  *NewConsoleContext;
+  BM_TERMINAL_CONTEXT *NewTerminalContext;
 
   ASSERT (CallbackData != NULL);
 
   ConInCheck = >BmmFakeNvData.ConsoleInCheck[0];
   for (Index = 0; ((Index < ConsoleInpMenu.MenuNumber) && \
(Index < MAX_MENU_NUMBER)) ; Index++) {  
 NewMenuEntry  = BOpt_GetMenuEntry (, Index);
 NewConsoleContext = (BM_CONSOLE_CONTEXT *) NewMenuEntry->VariableContext;  
 ConInCheck[Index] = NewConsoleContext->IsActive;
   }
+
+  for (Index = 0; Index < TerminalMenu.MenuNumber; Index++) {
+NewMenuEntry= BOpt_GetMenuEntry (, Index);
+NewTerminalContext  = (BM_TERMINAL_CONTEXT *) 
NewMenuEntry->VariableContext;
+ASSERT (Index + ConsoleInpMenu.MenuNumber < MAX_MENU_NUMBER);
+ConInCheck[Index + ConsoleInpMenu.MenuNumber] = 
NewTerminalContext->IsConIn;
+  }
 }
 
 /**
 
   Initialize console output device check box to 
ConsoleOutCheck[MAX_MENU_NUMBER]
@@ -1058,19 +1066,27 @@ GetConsoleOutCheck (
 {
   UINT16  Index;
   BM_MENU_ENTRY   *NewMenuEntry; 
   UINT8   *ConOutCheck;
   BM_CONSOLE_CONTEXT  *NewConsoleContext;
-  
+  BM_TERMINAL_CONTEXT *NewTerminalContext;
+
   ASSERT (CallbackData != NULL);
   ConOutCheck = >BmmFakeNvData.ConsoleOutCheck[0];
   for (Index = 0; ((Index < ConsoleOutMenu.MenuNumber) && \
(Index < MAX_MENU_NUMBER)) ; Index++) {  
 NewMenuEntry  = BOpt_GetMenuEntry (, Index);
 NewConsoleContext = (BM_CONSOLE_CONTEXT *) NewMenuEntry->VariableContext;  
 ConOutCheck[Index] = NewConsoleContext->IsActive;
   }
+
+  for (Index = 0; Index < TerminalMenu.MenuNumber; Index++) {
+NewMenuEntry= BOpt_GetMenuEntry (, Index);
+NewTerminalContext  = (BM_TERMINAL_CONTEXT *) 
NewMenuEntry->VariableContext;
+ASSERT (Index + ConsoleOutMenu.MenuNumber < MAX_MENU_NUMBER);
+ConOutCheck[Index + ConsoleOutMenu.MenuNumber] = 
NewTerminalContext->IsConOut;
+  }
 }
 
 /**
 
   Initialize standard error output device check box to 
ConsoleErrCheck[MAX_MENU_NUMBER]
@@ -1086,19 +1102,27 @@ GetConsoleErrCheck (
 {
   UINT16  Index;
   BM_MENU_ENTRY   *NewMenuEntry; 
   UINT8   *ConErrCheck;
   BM_CONSOLE_CONTEXT  *NewConsoleContext;
+  BM_TERMINAL_CONTEXT *NewTerminalContext;
 
   ASSERT (CallbackData != NULL);
   ConErrCheck = >BmmFakeNvData.ConsoleErrCheck[0];
   for (Index = 0; ((Index < ConsoleErrMenu.MenuNumber) && \
(Index < MAX_MENU_NUMBER)) ; Index++) {  
 NewMenuEntry  = BOpt_GetMenuEntry (, Index);
 NewConsoleContext = (BM_CONSOLE_CONTEXT *) NewMenuEntry->VariableContext;  
 ConErrCheck[Index] = NewConsoleContext->IsActive;
   }
+
+  for (Index = 0; Index < TerminalMenu.MenuNumber; Index++) {
+NewMenuEntry= BOpt_GetMenuEntry (, Index);
+NewTerminalContext  = (BM_TERMINAL_CONTEXT *) 
NewMenuEntry->VariableContext;
+ASSERT (Index + ConsoleErrMenu.MenuNumber < MAX_MENU_NUMBER);
+ConErrCheck[Index + ConsoleErrMenu.MenuNumber] = 
NewTerminalContext->IsStdErr;
+  }
 }
 
 /**
 
   Initialize terminal attributes (baudrate, data rate, stop bits, parity and 
terminal type)
-- 
1.9.5.msysgit.1

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

Re: [edk2] [RFC] [PATCH V3 3/3] MdeModulePkg/PciBus: Add IOMMU support.

[Yao, Jiewen]

Yes, I agree. It is a little complicated.

NeedAllocateNonExisting is TRUE when:

A. IoMMU is present  (AND)

B. We need remap a Buffer  below 4GiB, but we cannot find enough memory there.

Because CommonBuffer and Read/WriteBuffer is handled in different way, we have 
to separate #B to be 2 cases.

B.1 We need remap a CommBuffer, because no below 4GiB CommBuffer returned in 
AllocateBuffer API. (OR)

B.2 We need remap a Read/Write buffer below 4GiB, but we cannot find enough 
memory there.

As a result: NeedAllocateNonExisting means (A AND (B.1 OR B.2))

Thank you
Yao Jiewen


From: Duran, Leo [mailto:leo.du...@amd.com]
Sent: Tuesday, April 18, 2017 3:58 AM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Singh, Brijesh ; Ard 
Biesheuvel 
Subject: RE: [RFC] [PATCH V3 3/3] MdeModulePkg/PciBus: Add IOMMU support.

Hi Yao,

Regarding RootBridgeIoMap()

I'm wondering if may be possible to simplify the logic requiring flags 
"NeedMap" and "NeedAllocateNonExisting"?
For example, it seems like (NeedAllocateNonExisting==TRUE) implies 
(gIoMmuProtocol != NULL), but that did not seem obvious at a glance.

Leo.

> -Original Message-
> From: Jiewen Yao [mailto:jiewen@intel.com]
> Sent: Tuesday, April 04, 2017 2:06 AM
> To: edk2-devel@lists.01.org
> Cc: Ruiyu Ni >; Duran, Leo 
> >;
> Singh, Brijesh >; Ard 
> Biesheuvel
> >
> Subject: [RFC] [PATCH V3 3/3] MdeModulePkg/PciBus: Add IOMMU support.
>
> The responsibility of PciBus driver is to set IOMMU attribute, because only
> PciBus knows which device submits DMA access request.
>
> PciBus driver guarantee that the request to PciHostBridge is IOMMU page
> aligned memory, as such PciHostBridge can allocate non-existent memory for
> device memory, to satisfy remap requirement.
>
> PciBus driver does not assume device address is same as the mapped host
> address, because IOMMU may remap it.
>
> Cc: Ruiyu Ni >
> Cc: Leo Duran >
> Cc: Brijesh Singh >
> Cc: Ard Biesheuvel 
> >
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao >
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c  |  12 ++
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h  |  19 ++
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf |   1 +
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c   | 225
> +++-
>  4 files changed, 247 insertions(+), 10 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> index f3be47a..c9ee4de 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> @@ -42,6 +42,8 @@ UINT64gAllZero  
>= 0;
>
>  EFI_PCI_PLATFORM_PROTOCOL *gPciPlatformProtocol;
>  EFI_PCI_OVERRIDE_PROTOCOL *gPciOverrideProtocol;
> +EDKII_IOMMU_PROTOCOL  *gIoMmuProtocol;
> +UINTN mIoMmuPageSize = 1;
>
>
>  GLOBAL_REMOVE_IF_UNREFERENCED
> EFI_PCI_HOTPLUG_REQUEST_PROTOCOL mPciHotPlugRequest = { @@ -
> 256,6 +258,16 @@ PciBusDriverBindingStart (
>}
>
>gBS->LocateProtocol (
> +,
> +NULL,
> +(VOID **) 
> +);
> +  if (gIoMmuProtocol != NULL) {
> +gIoMmuProtocol->GetPageSize (gIoMmuProtocol, );
> +ASSERT ((mIoMmuPageSize & (mIoMmuPageSize - 1)) == 0);  }
> +
> +  gBS->LocateProtocol (
>   ,
>   NULL,
>   (VOID **)  diff --git
> a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> index 39ba8b9..185d89c 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> @@ -32,6 +32,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include  @@ -289,6 +290,8 @@ struct
> _PCI_IO_DEVICE {
>// This field is used to support this case.
>//
>UINT16BridgeIoAlignment;
> +
> +  LIST_ENTRYMaps;
>  };
>
>  #define PCI_IO_DEVICE_FROM_PCI_IO_THIS(a) \ @@ -304,6 +307,20 @@
> struct _PCI_IO_DEVICE {
>CR (a, PCI_IO_DEVICE, LoadFile2, PCI_IO_DEVICE_SIGNATURE)
>
>
> +#define PCI_IO_MAP_INFO_SIGNATURE  SIGNATURE_32 ('p', 'm', 'a', 'p')
> +typedef struct {
> +  UINT32Signature;
> +  LIST_ENTRY  

Re: [edk2] [RFC] [PATCH V3 2/3] MdeModulePkg/PciHostBridge: Add IOMMU support.

[Yao, Jiewen]

Thanks Leo.
Answer below:

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Duran, 
Leo
Sent: Tuesday, April 18, 2017 3:33 AM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Singh, Brijesh ; Ard 
Biesheuvel 
Subject: Re: [edk2] [RFC] [PATCH V3 2/3] MdeModulePkg/PciHostBridge: Add IOMMU 
support.

Hi Yao,

Just a couple of quick comments:

1) gIoMmuProtocol is declared (global) by PciHostBridge.c, but it is not 
initialized to NULL.
[Jiewen] Our PECOFF loader zero it. I do not believe it will bring any real 
impact.
But I agree with you that we can explicit assign to NULL to avoid confusing.


2) Would it be OK to do a one-time LocateProtocol() of gIoMmuProtocol  in 
InitializePciHostBridge()?
BTW, besides the global declaration, gIoMmuProtocol  is currently not used by 
PciHostBridge.c
[Jiewen] It is hard, because of dependency.
We are not able to guarantee IOMMU driver runs before PciHostBridge.
We cannot add dependency for PciHostBridge, because IOMMU is an optional 
feature.


Leo

> -Original Message-
> From: Jiewen Yao [mailto:jiewen@intel.com]
> Sent: Tuesday, April 04, 2017 2:06 AM
> To: edk2-devel@lists.01.org
> Cc: Ruiyu Ni >; Duran, Leo 
> >;
> Singh, Brijesh >; Ard 
> Biesheuvel
> >
> Subject: [RFC] [PATCH V3 2/3] MdeModulePkg/PciHostBridge: Add IOMMU
> support.
>
> The responsibility of PciHostBridge is to allocate IOMMU page aligned
> memory for Map and AllocateBuffer, because PciHostBridge driver already
> handles Map() request to allocate another buffer for DMA read/write.
>
> If the max address requirement can not be satisfied, PciHostBridge may also
> allocate any IOMMU page aligned memory and use IOMMU Remapping
> feature to map to lower address to satisfy device requirement.
>
> PciHostBridge does not set IOMMU attribute because it does not know
> which device request the DMA. This work is done by PciBus driver.
>
> Cc: Ruiyu Ni >
> Cc: Leo Duran >
> Cc: Brijesh Singh >
> Cc: Ard Biesheuvel 
> >
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao >
> ---
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c  |   3 +
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf |   1 +
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h  |   8 +
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c| 350
> ++--
>  4 files changed, 326 insertions(+), 36 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> index 9005dee..35233a7 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> @@ -28,6 +28,9 @@ GLOBAL_REMOVE_IF_UNREFERENCED CHAR16
> *mPciResourceTypeStr[] = {
>L"I/O", L"Mem", L"PMem", L"Mem64", L"PMem64", L"Bus"
>  };
>
> +EDKII_IOMMU_PROTOCOL*gIoMmuProtocol;
> +UINTN   mIoMmuPageSize = 1;
> +
>  /**
>Ensure the compatibility of an IO space descriptor with the IO aperture.
>
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
> index d8b0439..2d3c8c9 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
> @@ -49,6 +49,7 @@
>gEfiDevicePathProtocolGuid  ## BY_START
>gEfiPciRootBridgeIoProtocolGuid ## BY_START
>gEfiPciHostBridgeResourceAllocationProtocolGuid ## BY_START
> +  gEdkiiIoMmuProtocolGuid ## CONSUMES
>
>  [Depex]
>gEfiCpuIo2ProtocolGuid AND
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h
> index 13185b4..77c3490 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h
> @@ -27,6 +27,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -50,8 +51,11 @@ typedef struct {
>EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_OPERATION Operation;
>UINTN NumberOfBytes;
>UINTN NumberOfPages;
> +  UINTN

[edk2] [PATCH v2 0/1] MdeModulePkg/PiSmmCore: Pad POOL_HEADER to be 8-byte aligned

[Hao Wu]

V2 changes:
Add comments for the purpose of the newly added 'Padding' field in
structure 'POOL_HEADER'.

Cc: Jiewen Yao 

Hao Wu (1):
  MdeModulePkg/PiSmmCore: Pad POOL_HEADER to be 8-byte aligned

 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 8 
 1 file changed, 8 insertions(+)

-- 
2.12.0.windows.1

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

[edk2] [PATCH v2 1/1] MdeModulePkg/PiSmmCore: Pad POOL_HEADER to be 8-byte aligned

[Hao Wu]

According to the PI spec (Vol 4, Section 3.2 SmmAllocatePool()):
The SmmAllocatePool() function ... All allocations are eight-byte aligned.

The commit adds a padding field in structure 'POOL_HEADER' to ensure the
above requirement is met.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
index c12805a2dd..0692661114 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
@@ -1200,6 +1200,14 @@ typedef struct {
   UINTN   Size;
   BOOLEAN Available;
   EFI_MEMORY_TYPE Type;
+  //
+  // According to the PI spec, buffers allocated by SmmAllocatePool should
+  // be 8-byte aligned. Here, the pad bytes make sure that the structure
+  // is 8-byte aligned:
+  // For IA32, sizeof (POOL_HEADER) is 16.
+  // For X64, sizeof (POOL_HEADER) is 24.
+  //
+  UINT32  Padding;
 } POOL_HEADER;
 
 typedef struct {
-- 
2.12.0.windows.1

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

Re: [edk2] [edk2-DscSpecification PATCH] Declare Pre/Post build scripts in [Defines] section

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Tuesday, April 18, 2017 9:08 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-DscSpecification PATCH] Declare Pre/Post build scripts in 
[Defines] section

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

Add support for PREBUILD and POSTBUILD defines in the [Defines] section of an 
DSC to declare scripts that are executed before and after normal DSC/FDF file 
processing.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_dsc_overview/23_[defines]_section_processing.md | 11 +++  
3_edk_ii_dsc_file_format/35_[defines]_section.md  |  2 ++
 README.md |  1 +
 3 files changed, 14 insertions(+)

diff --git a/2_dsc_overview/23_[defines]_section_processing.md 
b/2_dsc_overview/23_[defines]_section_processing.md
index 7f3c56d..f44ec57 100644
--- a/2_dsc_overview/23_[defines]_section_processing.md
+++ b/2_dsc_overview/23_[defines]_section_processing.md
@@ -53,6 +53,17 @@ The format for entries in this section is:
 
 `Name = Value`
 
+If the `PREBUILD` and/or `POSTBUILD` entries are specified, value must 
+be a tool that can be executed.  If the value contains space 
+characters, then the value must be a quoted string. The `build` tool 
+suspends processing of the DSC file if the `PREBUILD` entry is present, 
+calls the script, and either terminates or continues processing the DSC file 
depending on the exit code from the script.
+If the `POSTBUILD` entry is present, prior to the successful `build` 
+exit, the script is called. If the script fails (non-zero exit code 
+from the script) `build` terminates immediately using the exit code 
+returned from the script, otherwise, `build` terminates normally. The 
+author of the script is responsible for ensuring that the script terminates 
with a non-zero exit code when it fails.
+
 All defined elements of the DSC file's `[Defines]` section are valid when  
parsing the FDF file. The these elements must be treated as Macros when using  
them in other sections of the DSC and FDF file, as in $(PLATFORM_NAME).
diff --git a/3_edk_ii_dsc_file_format/35_[defines]_section.md 
b/3_edk_ii_dsc_file_format/35_[defines]_section.md
index 0785061..3ac6847 100644
--- a/3_edk_ii_dsc_file_format/35_[defines]_section.md
+++ b/3_edk_ii_dsc_file_format/35_[defines]_section.md
@@ -125,6 +125,8 @@ The `!include` statement may be used in a `[Defines]` 
section.
[ "VPD_TOOL_GUID"  
]
[ "PCD_VAR_CHECK_GENERATION"   ]
+   [ "PREBUILD"  {} {} 
]
+   [ "POSTBUILD"  {} 
+ {} ]
[ ]
*
*
diff --git a/README.md b/README.md
index 64bf2b7..31eebe4 100644
--- a/README.md
+++ b/README.md
@@ -178,3 +178,4 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || Added new system environment variables used by the build 
system. 

|   
 |
 | 1.27   | Convert to GitBooks 


 | April 2017 |
 || [#351](https://bugzilla.tianocore.org/show_bug.cgi?id=351) [DSC 
Spec] Extend macro usage in the !include statement  

 ||
+|| [#484](https://bugzilla.tianocore.org/show_bug.cgi?id=484) DSC 
spec: support Prebuild and Postbuild in the [Defines] section   

  ||
--
2.6.3.windows.1

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

Re: [edk2] [edk2-BuildSpecification PATCH] Declare Pre/Post build scripts in [Defines] section

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu 

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Tuesday, April 18, 2017 9:06 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-BuildSpecification PATCH] Declare Pre/Post build scripts in 
[Defines] section

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

Add support for PREBUILD and POSTBUILD defines in the [Defines] section of an 
DSC to declare scripts that are executed before and after normal DSC/FDF file 
processing.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 .../106_post_build_processing.md   | 61 ++
 .../82_auto-generation_process.md  | 33 
 README.md  |  1 +
 SUMMARY.md |  1 +
 4 files changed, 96 insertions(+)
 create mode 100644 
10_post-build_imagegen_stage_-_flash/106_post_build_processing.md

diff --git a/10_post-build_imagegen_stage_-_flash/106_post_build_processing.md 
b/10_post-build_imagegen_stage_-_flash/106_post_build_processing.md
new file mode 100644
index 000..6b48a4f
--- /dev/null
+++ b/10_post-build_imagegen_stage_-_flash/106_post_build_processing.md
@@ -0,0 +1,61 @@
+
+
+
+## 10.6 Post Build Processing
+
+If the `[Defines]` section of the DSC file contains a `POSTBUILD = 
+entry` statement, prior to exiting, the script specified in the 
+`POSTBUILD` statement is executed. If the script file is not found, the 
+**build** command exits with an appropriate error message. If the 
+script fails, it must terminate with a non-zero exit code and the 
+**build** command terminates with the exit value from the post-build 
+script. The script is required to generate error messages that provide the 
reason for the termination.
+
+All of the command line options passed into the **build** command are 
+also passed  into the script along with the command line options for 
+`TARGET`, `ARCH`, and `TOOL_CHAIN_TAG`. The values for `TARGET`, 
+`ARCH`, and `TOOL_CHAIN_TAG` are from the command line options passed 
+into the **build** command. If these values are not passed into the 
+**build** command, then they are retrieved from `target.txt`.
+
+If the script terminates successfully (exit value of 0), then the 
+**build** command terminates normally.
+
+**
+**Note:** This entry may be wrapped in a conditional directive. Unlike 
+the `PREBUILD` entry, there are no restrictions on the MACRO values 
+used in a conditional directive.
+**
+**Note:** Quotes are needed when the script's additional options are present.
+Quotes are also required if the path to the post-build command contains 
+space or special characters.
+**
diff --git a/8_pre-build_autogen_stage/82_auto-generation_process.md 
b/8_pre-build_autogen_stage/82_auto-generation_process.md
index deb1c47..4175552 100644
--- a/8_pre-build_autogen_stage/82_auto-generation_process.md
+++ b/8_pre-build_autogen_stage/82_auto-generation_process.md
@@ -958,6 +958,39 @@ If the `[Defines]` section has the 
`PCD_VAR_CHECK_GENERATION` entry set to  TRUE, then a binary file will be 
created in the FV directory for Dynamic and  DynamicEx PCD HII Variable 
checking.
 
+ 8.2.4.13 Pre Build Processing
+
+The DSC file is parsed after the tool meta-data files. If the 
+`[Defines]` section of the DSC file contains a `PREBUILD = entry` 
+statement, processing of the DSC file is suspended and the script 
+specified in the `PREBUILD` statement is executed. If the script file 
+is not found, the **build** command exits with an appropriate error 
+message. If the script fails, it must terminate with a non-zero exit 
+code and the **build** command terminates with the exit value from the 
+pre-build script. The script is required to generate error messages that 
provide the reason for the termination.
+
+All of the command line options passed into the **build** command are 
+also passed  into the script along with the command line options for 
+`TARGET`, `ARCH`, and `TOOL_CHAIN_TAG`. The values for `TARGET`, 
+`ARCH`, and `TOOL_CHAIN_TAG` are from the command line options passed 
+into the **build** command. If these values are not passed into the 
+**build** command, then they are retrieved from `target.txt`.
+
+If the script terminates successfully (exit value of 0), parsing of the 
+DSC file continues, and build tools may retrieve environment variables 
+that have been updated by the script.
+
+**
+**Note:** This entry may be wrapped in a conditional directive that 
+uses the value of the `TOOL_CHAIN_TAG` determined earlier. Using a 
+MACRO value other than `$(TOOL_CHAIN_TAG)` is 

[edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Lock should be acquired

[Jeff Fan]

SMM BSP's *busy* state should be acquired. We could use AcquireSpinLock()
instead of AcquireSpinLockOrFail().

Cc: Hao Wu 
Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index a1d16b4..e03f1e0 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -407,7 +407,7 @@ BSPHandler (
   //
   // The BUSY lock is initialized to Acquired state
   //
-  AcquireSpinLockOrFail (mSmmMpSyncData->CpuData[CpuIndex].Busy);
+  AcquireSpinLock (mSmmMpSyncData->CpuData[CpuIndex].Busy);
 
   //
   // Perform the pre tasks
-- 
2.9.3.windows.2

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

[edk2] [PATCH] MdeModulePkg/PiSmmCore: Pad POOL_HEADER to be 8-byte aligned

[Hao Wu]

According to the PI spec (Vol 4, Section 3.2 SmmAllocatePool()):
The SmmAllocatePool() function ... All allocations are eight-byte aligned.

The commit adds a padding field in structure 'POOL_HEADER' to ensure the
above requirement is met.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
index c12805a2dd..a8aa017add 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
@@ -1200,6 +1200,7 @@ typedef struct {
   UINTN   Size;
   BOOLEAN Available;
   EFI_MEMORY_TYPE Type;
+  UINT32  Padding;
 } POOL_HEADER;
 
 typedef struct {
-- 
2.12.0.windows.1

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

[edk2] [edk2-DscSpecification PATCH] Declare Pre/Post build scripts in [Defines] section

[Michael Kinney]

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

GitHub branch for review:

  
https://github.com/mdkinney/edk2-DscSpecification/tree/Bugzilla_484_PrePostBuild
  
GitHub branch compare against latest DRAFT for review:

  
https://github.com/tianocore-docs/edk2-DscSpecification/compare/master...mdkinney:Bugzilla_484_PrePostBuild?w=1

Add support for PREBUILD and POSTBUILD defines in
the [Defines] section of an DSC to declare scripts
that are executed before and after normal DSC/FDF
file processing.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

Michael Kinney (1):
  Declare Pre/Post build scripts in [Defines] section

 2_dsc_overview/23_[defines]_section_processing.md | 11 +++
 3_edk_ii_dsc_file_format/35_[defines]_section.md  |  2 ++
 README.md |  1 +
 3 files changed, 14 insertions(+)

-- 
2.6.3.windows.1

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

[edk2] [edk2-DscSpecification PATCH] Declare Pre/Post build scripts in [Defines] section

[Michael Kinney]

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

Add support for PREBUILD and POSTBUILD defines in
the [Defines] section of an DSC to declare scripts
that are executed before and after normal DSC/FDF
file processing.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_dsc_overview/23_[defines]_section_processing.md | 11 +++
 3_edk_ii_dsc_file_format/35_[defines]_section.md  |  2 ++
 README.md |  1 +
 3 files changed, 14 insertions(+)

diff --git a/2_dsc_overview/23_[defines]_section_processing.md 
b/2_dsc_overview/23_[defines]_section_processing.md
index 7f3c56d..f44ec57 100644
--- a/2_dsc_overview/23_[defines]_section_processing.md
+++ b/2_dsc_overview/23_[defines]_section_processing.md
@@ -53,6 +53,17 @@ The format for entries in this section is:
 
 `Name = Value`
 
+If the `PREBUILD` and/or `POSTBUILD` entries are specified, value must be a
+tool that can be executed.  If the value contains space characters, then the
+value must be a quoted string. The `build` tool suspends processing of the DSC
+file if the `PREBUILD` entry is present, calls the script, and either 
terminates
+or continues processing the DSC file depending on the exit code from the 
script.
+If the `POSTBUILD` entry is present, prior to the successful `build` exit, the
+script is called. If the script fails (non-zero exit code from the script)
+`build` terminates immediately using the exit code returned from the script,
+otherwise, `build` terminates normally. The author of the script is responsible
+for ensuring that the script terminates with a non-zero exit code when it 
fails.
+
 All defined elements of the DSC file's `[Defines]` section are valid when
 parsing the FDF file. The these elements must be treated as Macros when using
 them in other sections of the DSC and FDF file, as in $(PLATFORM_NAME).
diff --git a/3_edk_ii_dsc_file_format/35_[defines]_section.md 
b/3_edk_ii_dsc_file_format/35_[defines]_section.md
index 0785061..3ac6847 100644
--- a/3_edk_ii_dsc_file_format/35_[defines]_section.md
+++ b/3_edk_ii_dsc_file_format/35_[defines]_section.md
@@ -125,6 +125,8 @@ The `!include` statement may be used in a `[Defines]` 
section.
[ "VPD_TOOL_GUID"  
]
[ "PCD_VAR_CHECK_GENERATION"   ]
+   [ "PREBUILD"  {} {} 
]
+   [ "POSTBUILD"  {} {} 
]
[ ]
*
*
diff --git a/README.md b/README.md
index 64bf2b7..31eebe4 100644
--- a/README.md
+++ b/README.md
@@ -178,3 +178,4 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || Added new system environment variables used by the build 
system. 

|   
 |
 | 1.27   | Convert to GitBooks 


 | April 2017 |
 || [#351](https://bugzilla.tianocore.org/show_bug.cgi?id=351) [DSC 
Spec] Extend macro usage in the !include statement  

 ||
+|| [#484](https://bugzilla.tianocore.org/show_bug.cgi?id=484) DSC 
spec: support Prebuild and Postbuild in the [Defines] section   

  ||
-- 
2.6.3.windows.1

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

[edk2] [edk2-BuildSpecification PATCH] Declare Pre/Post build scripts in [Defines] section

[Michael Kinney]

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

GitHub branch for review:

  
https://github.com/mdkinney/edk2-BuildSpecification/tree/Bugzilla_483_PrePostBuild
  
GitHub branch compare against latest DRAFT for review:

  
https://github.com/tianocore-docs/edk2-BuildSpecification/compare/master...mdkinney:Bugzilla_483_PrePostBuild?w=1

Add support for PREBUILD and POSTBUILD defines in
the [Defines] section of an DSC to declare scripts
that are executed before and after normal DSC/FDF
file processing.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

Michael Kinney (1):
  Declare Pre/Post build scripts in [Defines] section

 .../106_post_build_processing.md   | 61 ++
 .../82_auto-generation_process.md  | 33 
 README.md  |  1 +
 SUMMARY.md |  1 +
 4 files changed, 96 insertions(+)
 create mode 100644 
10_post-build_imagegen_stage_-_flash/106_post_build_processing.md

-- 
2.6.3.windows.1

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

[edk2] [edk2-BuildSpecification PATCH] Declare Pre/Post build scripts in [Defines] section

[Michael Kinney]

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

Add support for PREBUILD and POSTBUILD defines in
the [Defines] section of an DSC to declare scripts
that are executed before and after normal DSC/FDF
file processing.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 .../106_post_build_processing.md   | 61 ++
 .../82_auto-generation_process.md  | 33 
 README.md  |  1 +
 SUMMARY.md |  1 +
 4 files changed, 96 insertions(+)
 create mode 100644 
10_post-build_imagegen_stage_-_flash/106_post_build_processing.md

diff --git a/10_post-build_imagegen_stage_-_flash/106_post_build_processing.md 
b/10_post-build_imagegen_stage_-_flash/106_post_build_processing.md
new file mode 100644
index 000..6b48a4f
--- /dev/null
+++ b/10_post-build_imagegen_stage_-_flash/106_post_build_processing.md
@@ -0,0 +1,61 @@
+
+
+
+## 10.6 Post Build Processing
+
+If the `[Defines]` section of the DSC file contains a `POSTBUILD = entry`
+statement, prior to exiting, the script specified in the `POSTBUILD` statement
+is executed. If the script file is not found, the **build** command exits with
+an appropriate error message. If the script fails, it must terminate with a
+non-zero exit code and the **build** command terminates with the exit value
+from the post-build script. The script is required to generate error messages
+that provide the reason for the termination.
+
+All of the command line options passed into the **build** command are also
+passed  into the script along with the command line options for `TARGET`,
+`ARCH`, and `TOOL_CHAIN_TAG`. The values for `TARGET`, `ARCH`, and
+`TOOL_CHAIN_TAG` are from the command line options passed into the **build**
+command. If these values are not passed into the **build** command, then they
+are retrieved from `target.txt`.
+
+If the script terminates successfully (exit value of 0), then the **build**
+command terminates normally.
+
+**
+**Note:** This entry may be wrapped in a conditional directive. Unlike the
+`PREBUILD` entry, there are no restrictions on the MACRO values used in a
+conditional directive.
+**
+**Note:** Quotes are needed when the script's additional options are present.
+Quotes are also required if the path to the post-build command contains space
+or special characters.
+**
diff --git a/8_pre-build_autogen_stage/82_auto-generation_process.md 
b/8_pre-build_autogen_stage/82_auto-generation_process.md
index deb1c47..4175552 100644
--- a/8_pre-build_autogen_stage/82_auto-generation_process.md
+++ b/8_pre-build_autogen_stage/82_auto-generation_process.md
@@ -958,6 +958,39 @@ If the `[Defines]` section has the 
`PCD_VAR_CHECK_GENERATION` entry set to
 TRUE, then a binary file will be created in the FV directory for Dynamic and
 DynamicEx PCD HII Variable checking.
 
+ 8.2.4.13 Pre Build Processing
+
+The DSC file is parsed after the tool meta-data files. If the `[Defines]`
+section of the DSC file contains a `PREBUILD = entry` statement, processing
+of the DSC file is suspended and the script specified in the `PREBUILD`
+statement is executed. If the script file is not found, the **build** command
+exits with an appropriate error message. If the script fails, it must terminate
+with a non-zero exit code and the **build** command terminates with the exit
+value from the pre-build script. The script is required to generate error
+messages that provide the reason for the termination.
+
+All of the command line options passed into the **build** command are also
+passed  into the script along with the command line options for `TARGET`,
+`ARCH`, and `TOOL_CHAIN_TAG`. The values for `TARGET`, `ARCH`, and
+`TOOL_CHAIN_TAG` are from the command line options passed into the **build**
+command. If these values are not passed into the **build** command, then they
+are retrieved from `target.txt`.
+
+If the script terminates successfully (exit value of 0), parsing of the DSC
+file continues, and build tools may retrieve environment variables that have
+been updated by the script.
+
+**
+**Note:** This entry may be wrapped in a conditional directive that uses the
+value of the `TOOL_CHAIN_TAG` determined earlier. Using a MACRO value other
+than `$(TOOL_CHAIN_TAG)` is prohibited, as the DSC file has not been processed
+at the time the ENTRY was found.
+**
+**Note:** Quotes are needed when the script's additional options are present.
+Quotes are also required if the path to the pre-build command contains space
+or special characters.
+**
+
 ### 8.2.5 Post processing
 
 Once all files are parsed, the build tools will do following work for each EDK
diff --git a/README.md b/README.md
index 

[edk2] NASM 2.13rc20 - hopefully final, please help test

[H. Peter Anvin]

After quite a number of iterations, we now have a NASM release with
Mach-O DWARF support and a number of other enhancements.  This is what I
fully expect to be the final release minus any bug fixes.

Although this is quite a jump in version numbers from the previously
announced rc20, a lot of the intervening rc's have been rather small
changes, sometimes only in the build infrastructure and/or documentation.

2.13rc20, as well as git tree and nightly build, is available from
http://www.nasm.us/ as usual.

Any feedback, good or bad, appreciated.  For problems, the preferred
method is to file a bug report at http://bugzilla.nasm.us/ to make sure
it doesn't get lost or forgotten.

Many thanks,

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

Re: [edk2] [RFC] [PATCH V3 3/3] MdeModulePkg/PciBus: Add IOMMU support.

[Duran, Leo]

Hi Yao,

Regarding RootBridgeIoMap()

I'm wondering if may be possible to simplify the logic requiring flags 
"NeedMap" and "NeedAllocateNonExisting"?
For example, it seems like (NeedAllocateNonExisting==TRUE) implies 
(gIoMmuProtocol != NULL), but that did not seem obvious at a glance.

Leo.

> -Original Message-
> From: Jiewen Yao [mailto:jiewen@intel.com]
> Sent: Tuesday, April 04, 2017 2:06 AM
> To: edk2-devel@lists.01.org
> Cc: Ruiyu Ni ; Duran, Leo ;
> Singh, Brijesh ; Ard Biesheuvel
> 
> Subject: [RFC] [PATCH V3 3/3] MdeModulePkg/PciBus: Add IOMMU support.
> 
> The responsibility of PciBus driver is to set IOMMU attribute, because only
> PciBus knows which device submits DMA access request.
> 
> PciBus driver guarantee that the request to PciHostBridge is IOMMU page
> aligned memory, as such PciHostBridge can allocate non-existent memory for
> device memory, to satisfy remap requirement.
> 
> PciBus driver does not assume device address is same as the mapped host
> address, because IOMMU may remap it.
> 
> Cc: Ruiyu Ni 
> Cc: Leo Duran 
> Cc: Brijesh Singh 
> Cc: Ard Biesheuvel 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c  |  12 ++
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h  |  19 ++
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf |   1 +
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c   | 225
> +++-
>  4 files changed, 247 insertions(+), 10 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> index f3be47a..c9ee4de 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> @@ -42,6 +42,8 @@ UINT64gAllZero  
>= 0;
> 
>  EFI_PCI_PLATFORM_PROTOCOL *gPciPlatformProtocol;
>  EFI_PCI_OVERRIDE_PROTOCOL *gPciOverrideProtocol;
> +EDKII_IOMMU_PROTOCOL  *gIoMmuProtocol;
> +UINTN mIoMmuPageSize = 1;
> 
> 
>  GLOBAL_REMOVE_IF_UNREFERENCED
> EFI_PCI_HOTPLUG_REQUEST_PROTOCOL mPciHotPlugRequest = { @@ -
> 256,6 +258,16 @@ PciBusDriverBindingStart (
>}
> 
>gBS->LocateProtocol (
> +,
> +NULL,
> +(VOID **) 
> +);
> +  if (gIoMmuProtocol != NULL) {
> +gIoMmuProtocol->GetPageSize (gIoMmuProtocol, );
> +ASSERT ((mIoMmuPageSize & (mIoMmuPageSize - 1)) == 0);  }
> +
> +  gBS->LocateProtocol (
>   ,
>   NULL,
>   (VOID **)  diff --git
> a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> index 39ba8b9..185d89c 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> @@ -32,6 +32,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include  @@ -289,6 +290,8 @@ struct
> _PCI_IO_DEVICE {
>// This field is used to support this case.
>//
>UINT16BridgeIoAlignment;
> +
> +  LIST_ENTRYMaps;
>  };
> 
>  #define PCI_IO_DEVICE_FROM_PCI_IO_THIS(a) \ @@ -304,6 +307,20 @@
> struct _PCI_IO_DEVICE {
>CR (a, PCI_IO_DEVICE, LoadFile2, PCI_IO_DEVICE_SIGNATURE)
> 
> 
> +#define PCI_IO_MAP_INFO_SIGNATURE  SIGNATURE_32 ('p', 'm', 'a', 'p')
> +typedef struct {
> +  UINT32Signature;
> +  LIST_ENTRYLink;
> +  EFI_PCI_IO_PROTOCOL_OPERATION Operation;
> +  VOID  *HostAddress;
> +  EFI_PHYSICAL_ADDRESS  DeviceAddress;
> +  UINTN NumberOfBytes;
> +  VOID  *AlignedHostAddress;
> +  UINTN AlignedNumberOfBytes;
> +  VOID  *MappedHostAddress;
> +  VOID  *PciRootBridgeIoMapping;
> +} PCI_IO_MAP_INFO;
> +#define PCI_IO_MAP_INFO_FROM_LINK(a) CR (a, PCI_IO_MAP_INFO,
> Link,
> +PCI_IO_MAP_INFO_SIGNATURE)
> 
>  //
>  // Global Variables
> @@ -321,6 +338,8 @@ extern EFI_PCI_PLATFORM_PROTOCOL
> *gPciPlatformProtocol;
>  extern EFI_PCI_OVERRIDE_PROTOCOL*gPciOverrideProtocol;
>  extern BOOLEAN  mReserveIsaAliases;
>  extern BOOLEAN  mReserveVgaAliases;
> +extern EDKII_IOMMU_PROTOCOL *gIoMmuProtocol;
> +extern UINTNmIoMmuPageSize;
> 
>  /**
>Macro that checks whether device is a 

Re: [edk2] [RFC] [PATCH V3 2/3] MdeModulePkg/PciHostBridge: Add IOMMU support.

[Duran, Leo]

Hi Yao,

Just a couple of quick comments:

1) gIoMmuProtocol is declared (global) by PciHostBridge.c, but it is not 
initialized to NULL.

2) Would it be OK to do a one-time LocateProtocol() of gIoMmuProtocol  in 
InitializePciHostBridge()?
BTW, besides the global declaration, gIoMmuProtocol  is currently not used by 
PciHostBridge.c 

Leo

> -Original Message-
> From: Jiewen Yao [mailto:jiewen@intel.com]
> Sent: Tuesday, April 04, 2017 2:06 AM
> To: edk2-devel@lists.01.org
> Cc: Ruiyu Ni ; Duran, Leo ;
> Singh, Brijesh ; Ard Biesheuvel
> 
> Subject: [RFC] [PATCH V3 2/3] MdeModulePkg/PciHostBridge: Add IOMMU
> support.
> 
> The responsibility of PciHostBridge is to allocate IOMMU page aligned
> memory for Map and AllocateBuffer, because PciHostBridge driver already
> handles Map() request to allocate another buffer for DMA read/write.
> 
> If the max address requirement can not be satisfied, PciHostBridge may also
> allocate any IOMMU page aligned memory and use IOMMU Remapping
> feature to map to lower address to satisfy device requirement.
> 
> PciHostBridge does not set IOMMU attribute because it does not know
> which device request the DMA. This work is done by PciBus driver.
> 
> Cc: Ruiyu Ni 
> Cc: Leo Duran 
> Cc: Brijesh Singh 
> Cc: Ard Biesheuvel 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c  |   3 +
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf |   1 +
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h  |   8 +
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c| 350
> ++--
>  4 files changed, 326 insertions(+), 36 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> index 9005dee..35233a7 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> @@ -28,6 +28,9 @@ GLOBAL_REMOVE_IF_UNREFERENCED CHAR16
> *mPciResourceTypeStr[] = {
>L"I/O", L"Mem", L"PMem", L"Mem64", L"PMem64", L"Bus"
>  };
> 
> +EDKII_IOMMU_PROTOCOL*gIoMmuProtocol;
> +UINTN   mIoMmuPageSize = 1;
> +
>  /**
>Ensure the compatibility of an IO space descriptor with the IO aperture.
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
> index d8b0439..2d3c8c9 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
> @@ -49,6 +49,7 @@
>gEfiDevicePathProtocolGuid  ## BY_START
>gEfiPciRootBridgeIoProtocolGuid ## BY_START
>gEfiPciHostBridgeResourceAllocationProtocolGuid ## BY_START
> +  gEdkiiIoMmuProtocolGuid ## CONSUMES
> 
>  [Depex]
>gEfiCpuIo2ProtocolGuid AND
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h
> index 13185b4..77c3490 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h
> @@ -27,6 +27,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -50,8 +51,11 @@ typedef struct {
>EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_OPERATION Operation;
>UINTN NumberOfBytes;
>UINTN NumberOfPages;
> +  UINTN MappedNumberOfBytes;
> +  UINTN MappedNumberOfPages;
>EFI_PHYSICAL_ADDRESS  HostAddress;
>EFI_PHYSICAL_ADDRESS  MappedHostAddress;
> +  BOOLEAN   RemapNonExisting;
>  } MAP_INFO;
>  #define MAP_INFO_FROM_LINK(a) CR (a, MAP_INFO, Link,
> MAP_INFO_SIGNATURE)
> 
> @@ -575,4 +579,8 @@ RootBridgeIoConfiguration (
> 
>  extern EFI_METRONOME_ARCH_PROTOCOL *mMetronome;
>  extern EFI_CPU_IO2_PROTOCOL *mCpuIo;
> +
> +extern EDKII_IOMMU_PROTOCOL*gIoMmuProtocol;
> +extern UINTN   mIoMmuPageSize;
> +
>  #endif
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> index 8af131b..2a17eb1 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> @@ -1022,6 +1022,121 @@ RootBridgeIoPciWrite (  }
> 
>  /**
> +  Allocates one or more 4KB pages of a certain 

Re: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Fix unconditional window shrinking

[ate...@kraftway.ru]

Hello, Siyuan


Sorry for providing incomplete log. I think missing packets is not the case 
here since all packets reached client. I made another log and I am attaching it 
to this email (full wireshark log from start of transmission). I am also 
attaching log from TcpDxe driver (added debug prints in TcpInput function as 
input and TcpTransmitSegment as output).

This log actually contains two cases: (1) in frame 145 (line 450 in TcpDxe log) 
advertised window reaches zero size, but after window update in frame 152 
transmission continues without deadlocks; (2) in frame 221 (line 698 in TcpDxe 
log) advertised window reaches zero again, but after window update we have a 
deadlock starting from frame 241.

Please notice how packets actually processed by TcpDxe driver. According to 
TcpDxe log server starts to shrink window in line 615  (frame 198). This seems 
to be shrinking, so i was wrong, thinking there was no shrinking at all, server 
indeed moves its Right edge to the left. TcpDxe driver catches this and prints 
message in line 615, though, no actual data shrinking happens here since Right 
> SndNxt. Same goes for next incoming packets (lines 616 - 627). At this point 
client have stopped sending data (line 611, frame 197) at SEQ 198418 (did he 
wait until he can send full MSS segment? which is 1448). In next packets (lines 
629 - 636) server opens its window again (moves Right edge to the right) and we 
have Right=199866 here. After receiving Right=199866 from server client can now 
send 1448 bytes of payload and he does (frame 208, line 638).

Starting from line 641 we have only input packets from server. Next packet 
forces client to move SndNxt to the left since client have just sent 
Seq:198418, End:199866 packet and server advertised Ack:156426, Wnd:43264, 
Right:199690. This packets ACKs old segment and advertises quite big window. 
Should client use values from this packet to reduce its SndNxt? Anyway, server 
shrinks Right to the value of 199642 but then it opens Right to the value of 
199866 in line 700 with ACK=199866. Does this mean that in general Right didn't 
move (yes, technically it moved left but then it restored to the original 
right)? Server without doubt accepted all data.

So maybe the bug here is to use 'intermediate' values from server to adjust 
SndNxt? Maybe we should calculate usable window right before sending data in 
TcpOutput?


Regards,
Andrey



On 17.04.2017 05:41, Fu, Siyuan wrote:
Hi, Andrey

For the question 1, that why client send out seq 590994, I don’t think it’s 
client side problem. We can see the server is moving the right edge if its 
receive window start from the beginning: the frame 4490, right edge is 590954, 
then it comes to 590946 (farme 4491), 590770 (frame 4492), 590754(frame 
4492)... Please note that these packets have not been received by the client 
side. I think why client send out frame 4496 with seq number to 590994, is 
because the server did advise a receive window for 590994 before frame 4490, 
and not shown in your dump log. Later the client send out frame 4500, which seq 
number is 590754, this is actually the right edge advised by the server’s frame 
4494. This means the client just received the frame  4494 after it send out the 
frame 4496, and this is the frame which really shrink the receive and make a 
negative useable in client side.
[cid:part1.D7FFAF65.7FC733FE@kraftway.ru]
I have check the new dump file, this time the server has never advise a right 
window edge on left of client’s SndNxt, that’s why the client won’t meet the 
“negative useable window” this time, not because your patch fixed the problem.

Best Regards,
Siyuan

From: ate...@kraftway.ru [mailto:ate...@kraftway.ru]
Sent: 2017年4月14日 21:32
To: Fu, Siyuan ; 
edk2-devel@lists.01.org
Cc: Ye, Ting ; Tian, Feng 
; Wu, Jiaxin 

Subject: Re: [PATCH 2/2] NetworkPkg/TcpDxe: Fix unconditional window shrinking


Hello, Siyuan,

Thank you for your reply. I created a bug#486 in bugzilla for this case. And 
answering your questions:

1. In frame 4496 client sends data starting from 589546 with len of 1448 and 
ending with 590994 seq number. Previously offered window from server was in 
frame 4495 Wnd=5632 ACK=585202 and the right window edge 585202+5632=590834. So 
the client should have sent 590834-589546=1288 bytes instead. So why the server 
accepted all 1448 bytes? I can only assume, that maybe during transmission of 
frame 4496 from client to server the application's process on server removed 
some data from server's receive buffer. But at this point it is clear that this 
situation was lead to by invalid behavior of the client.

2. While in most cases the deadlock occurs after recovering from ZeroWindow, in 
some rare cases it 

Re: [edk2] [RFC] [PATCH V3 1/3] MdeModulePkg/Include: Add IOMMU protocol definition.

[Yao, Jiewen]

Hi Ard
Thanks for the feedback.

Detailed comment below:


From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Monday, April 17, 2017 9:43 PM
To: Yao, Jiewen 
Cc: edk2-devel@lists.01.org; Ni, Ruiyu ; Leo Duran 
; Brijesh Singh 
Subject: Re: [RFC] [PATCH V3 1/3] MdeModulePkg/Include: Add IOMMU protocol 
definition.

On 4 April 2017 at 08:06, Jiewen Yao 
> wrote:
> This protocol is to abstract DMA access from IOMMU.
> 1) Intel "DMAR" ACPI table.
> 2) AMD "IVRS" ACPI table
> 3) ARM "IORT" ACPI table.
>
> There might be multiple IOMMU engines on one platform.
> For example, one for graphic and one for rest PCI devices
> (such as ATA/USB).
> All IOMMU engines are reported by one ACPI table.
>
> All IOMMU protocol provider should be based upon ACPI table.
> This single IOMMU protocol can handle multiple IOMMU engines on one system.
>
> This IOMMU protocol provider can use UEFI device path to distinguish
> if the device is graphic or ATA/USB, and find out corresponding
> IOMMU engine.
>
> The IOMMU protocol provides 2 capabilities:
> A) Set DMA access attribute - such as write/read control.
> B) Remap DMA memory - such as remap above 4GiB system memory address
> to below 4GiB device address.
>
> 4) AMD "SEV" feature.
> We can have an AMD SEV specific IOMMU driver to produce IOMMU protocol,
> and manage SEV bit in SetAttribute(), and return UNSUPPORTED
> for SetRemapAddress/GetRemapAddress().
>
> Cc: Ruiyu Ni >
> Cc: Leo Duran >
> Cc: Brijesh Singh >
> Cc: Ard Biesheuvel 
> >
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao >
> ---
>  MdeModulePkg/Include/Protocol/IoMmu.h | 196 
>  MdeModulePkg/MdeModulePkg.dec |   3 +
>  2 files changed, 199 insertions(+)
>
> diff --git a/MdeModulePkg/Include/Protocol/IoMmu.h 
> b/MdeModulePkg/Include/Protocol/IoMmu.h
> new file mode 100644
> index 000..766b918
> --- /dev/null
> +++ b/MdeModulePkg/Include/Protocol/IoMmu.h
> @@ -0,0 +1,196 @@
> +/** @file
> +  EFI IOMMU Protocol.
> +
> +Copyright (c) 2017, 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.
> +
> +**/
> +
> +
> +#ifndef __IOMMU_H__
> +#define __IOMMU_H__
> +
> +//
> +// IOMMU Protocol GUID value
> +//
> +#define EDKII_IOMMU_PROTOCOL_GUID \
> +{ \
> +  0x4e939de9, 0xd948, 0x4b0f, { 0x88, 0xed, 0xe6, 0xe1, 0xce, 0x51, 
> 0x7c, 0x1e } \
> +}
> +
> +//
> +// Forward reference for pure ANSI compatability
> +//
> +typedef struct _EDKII_IOMMU_PROTOCOL  EDKII_IOMMU_PROTOCOL;
> +
> +//
> +// Revision The revision to which the IOMMU interface adheres.
> +//  All future revisions must be backwards compatible.
> +//  If a future version is not back wards compatible it is not the 
> same GUID.
> +//
> +#define EDKII_IOMMU_PROTOCOL_REVISION 0x0001
> +
> +//
> +// IOMMU attribute.
> +// These types can be "ORed" together as needed.
> +// Any undefined bits are reserved and must be zero.
> +//
> +#define EDKII_IOMMU_ATTRIBUTE_READ   0x1
> +#define EDKII_IOMMU_ATTRIBUTE_WRITE  0x2
> +
> +/**
> +  Get IOMMU page size.
> +
> +  This is the minimal supported page size for a IOMMU.
> +  For example, if an IOMMU supports 4KiB, 2MiB and 1GiB,
> +  4KiB should be returned.
> +
> +  @param[in]  This  Protocol instance pointer.
> +  @param[out] PageSize  The minimal supported page size for a IOMMU.
> +
> +  @retval EFI_SUCCESSThe page size is returned.
> +  @retval EFI_INVALID_PARAMETER  PageSize is NULL.
> +
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI *EDKII_IOMMU_GET_PAGE_SIZE)(
> +  IN  EDKII_IOMMU_PROTOCOL  *This,
> +  OUT UINTN *PageSize
> +  );
> +

When do we expect to need this? Is it common on x86 to have IOMMUs
that don't support 4 KB page size?
[Jiewen] Yes. X86 IOMMU does support 4KB.
I am not knowledgeable enough to know all other architectures. So this is a 
generic design.
Of course, if we can confirm all arch support 4KB IOMMU, this API can be 
removed. ☺
Ard, can you help to double confirm for ARM/AArch64?


> +/**
> +  Set IOMMU attribute for a system memory.
> +
> +  If the IOMMU protocol exists, the system memory cannot be used
> +  for DMA by default.
> +

I suppose this is required for 

Re: [edk2] [PATCH] MdeModulePkg: ScsiDiskDxe: fix to support EFI_ERASE_BLOCK_PROTOCOL

[Haojian Zhuang]

Hi Hao,

I tried the discard operation on my UFS device. It just return 0.

And erase operation isn’t supported on my UFS device. If I don’t support 
discard operation, I can’t erase blocks at all.

Best Regards
Haojian

From: Wu, Hao A
Sent: 2017年4月17日 9:59
To: Haojian Zhuang
Cc: Tian, Feng; 
leif.lindh...@linaro.org; 
ard.biesheu...@linaro.org; 
edk2-devel@lists.01.org
Subject: RE: [PATCH] MdeModulePkg: ScsiDiskDxe: fix to support 
EFI_ERASE_BLOCK_PROTOCOL

Hi Haojian,

The reason for me to check both bits TPE and TPRZ being set when
determining whether the Erase Block Protocol should be produced is:

According to the Universal Flash Storage (UFS) Version 2.0 spec Section
12.2.3.2 Discard:
Since the TPRZ bit is set to zero if the discard functionality is enabled,
a READ command specifying a deallocated LBA may return any data.

And according to the UEFI 2.6 spec Section 12.12 in the 'Description' part
of the EFI_ERASE_BLOCK_PROTOCOL.EraseBlocks():
The EraseBlocks() function erases the requested number of device blocks.
Upon the successful execution of EraseBlocks() with an EFI_SUCCESS return
code, any subsequent reads of the same LBA range would return an
initialized/formatted value.

Since after the 'discard' operation, the device may return any data. My
concern is that the 'discard' operation does not match exactly with the
description of the behavior of the EraseBlocks() by the UEFI spec to
return an initialized/formatted value.

Best Regards,
Hao Wu


> -Original Message-
> From: Haojian Zhuang [mailto:haojian.zhu...@linaro.org]
> Sent: Saturday, April 15, 2017 9:45 PM
> To: Wu, Hao A; Tian, Feng; leif.lindh...@linaro.org; 
> ard.biesheu...@linaro.org;
> edk2-devel@lists.01.org
> Cc: Haojian Zhuang
> Subject: [PATCH] MdeModulePkg: ScsiDiskDxe: fix to support
> EFI_ERASE_BLOCK_PROTOCOL
>
> If bit TPZ and bit TPRZ are set, the erase feature is implemented.
> If bit TPZ is set and bit TPRZ is clear, the discard feature is
> implemented. And discard is a non-secure variant of the erase
> functionality.
>
> So the detecting operation of EFI_ERASE_BLOCK_PROTOCOL, we should
> consider to support both functionality. Since discard functionality is
> only supported in some UFS devices.
>
> And both of these two features are relied on UNMAP command.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Haojian Zhuang 
> ---
>  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> index b5eff25..6e12e4f 100644
> --- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> +++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> @@ -5400,11 +5400,11 @@ DetermineInstallEraseBlock (
>if (CommandStatus == EFI_SUCCESS) {
>  //
>  // Universal Flash Storage (UFS) Version 2.0
> -// Section 11.3.9.2
> +// Section 11.3.9.2 & Section 12.2.3
>  // Bits TPE and TPRZ should both be set to enable the erase feature on 
> UFS.
> +// Setting bit TPE and clearing bit TPRZ to enable the discard feature 
> on UFS.
>  //
> -if (((CapacityData16->LowestAlignLogic2 & BIT7) == 0) ||
> -((CapacityData16->LowestAlignLogic2 & BIT6) == 0)) {
> +if ((CapacityData16->LowestAlignLogic2 & BIT7) == 0) {
>DEBUG ((
>  EFI_D_VERBOSE,
>  "ScsiDisk EraseBlock: Either TPE or TPRZ is not set: 0x%x.\n",
> --
> 2.7.4

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

Re: [edk2] [RFC] [PATCH V3 1/3] MdeModulePkg/Include: Add IOMMU protocol definition.

[Ard Biesheuvel]

On 4 April 2017 at 08:06, Jiewen Yao  wrote:
> This protocol is to abstract DMA access from IOMMU.
> 1) Intel "DMAR" ACPI table.
> 2) AMD "IVRS" ACPI table
> 3) ARM "IORT" ACPI table.
>
> There might be multiple IOMMU engines on one platform.
> For example, one for graphic and one for rest PCI devices
> (such as ATA/USB).
> All IOMMU engines are reported by one ACPI table.
>
> All IOMMU protocol provider should be based upon ACPI table.
> This single IOMMU protocol can handle multiple IOMMU engines on one system.
>
> This IOMMU protocol provider can use UEFI device path to distinguish
> if the device is graphic or ATA/USB, and find out corresponding
> IOMMU engine.
>
> The IOMMU protocol provides 2 capabilities:
> A) Set DMA access attribute - such as write/read control.
> B) Remap DMA memory - such as remap above 4GiB system memory address
> to below 4GiB device address.
>
> 4) AMD "SEV" feature.
> We can have an AMD SEV specific IOMMU driver to produce IOMMU protocol,
> and manage SEV bit in SetAttribute(), and return UNSUPPORTED
> for SetRemapAddress/GetRemapAddress().
>
> Cc: Ruiyu Ni 
> Cc: Leo Duran 
> Cc: Brijesh Singh 
> Cc: Ard Biesheuvel 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  MdeModulePkg/Include/Protocol/IoMmu.h | 196 
>  MdeModulePkg/MdeModulePkg.dec |   3 +
>  2 files changed, 199 insertions(+)
>
> diff --git a/MdeModulePkg/Include/Protocol/IoMmu.h 
> b/MdeModulePkg/Include/Protocol/IoMmu.h
> new file mode 100644
> index 000..766b918
> --- /dev/null
> +++ b/MdeModulePkg/Include/Protocol/IoMmu.h
> @@ -0,0 +1,196 @@
> +/** @file
> +  EFI IOMMU Protocol.
> +
> +Copyright (c) 2017, 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.
> +
> +**/
> +
> +
> +#ifndef __IOMMU_H__
> +#define __IOMMU_H__
> +
> +//
> +// IOMMU Protocol GUID value
> +//
> +#define EDKII_IOMMU_PROTOCOL_GUID \
> +{ \
> +  0x4e939de9, 0xd948, 0x4b0f, { 0x88, 0xed, 0xe6, 0xe1, 0xce, 0x51, 
> 0x7c, 0x1e } \
> +}
> +
> +//
> +// Forward reference for pure ANSI compatability
> +//
> +typedef struct _EDKII_IOMMU_PROTOCOL  EDKII_IOMMU_PROTOCOL;
> +
> +//
> +// Revision The revision to which the IOMMU interface adheres.
> +//  All future revisions must be backwards compatible.
> +//  If a future version is not back wards compatible it is not the 
> same GUID.
> +//
> +#define EDKII_IOMMU_PROTOCOL_REVISION 0x0001
> +
> +//
> +// IOMMU attribute.
> +// These types can be "ORed" together as needed.
> +// Any undefined bits are reserved and must be zero.
> +//
> +#define EDKII_IOMMU_ATTRIBUTE_READ   0x1
> +#define EDKII_IOMMU_ATTRIBUTE_WRITE  0x2
> +
> +/**
> +  Get IOMMU page size.
> +
> +  This is the minimal supported page size for a IOMMU.
> +  For example, if an IOMMU supports 4KiB, 2MiB and 1GiB,
> +  4KiB should be returned.
> +
> +  @param[in]  This  Protocol instance pointer.
> +  @param[out] PageSize  The minimal supported page size for a IOMMU.
> +
> +  @retval EFI_SUCCESSThe page size is returned.
> +  @retval EFI_INVALID_PARAMETER  PageSize is NULL.
> +
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI *EDKII_IOMMU_GET_PAGE_SIZE)(
> +  IN  EDKII_IOMMU_PROTOCOL  *This,
> +  OUT UINTN *PageSize
> +  );
> +

When do we expect to need this? Is it common on x86 to have IOMMUs
that don't support 4 KB page size?

> +/**
> +  Set IOMMU attribute for a system memory.
> +
> +  If the IOMMU protocol exists, the system memory cannot be used
> +  for DMA by default.
> +

I suppose this is required for encryption support, but isn't it overly
restrictive in the general case?
On ARM systems, many drivers exist that are not PCI based but do
perform DMA. (i.e., DmaLib)

> +  When a device requests a DMA access for a system memory,
> +  the device driver need use SetAttribute() to update the IOMMU
> +  attribute to request DMA access (read and/or write).
> +
> +  The DeviceHandle is used to identify which device submits the request.
> +  The IOMMU implementation need translate the device path to an IOMMU device 
> ID,
> +  and set IOMMU hardware register accordingly.
> +  1) DeviceHandle can be a standard PCI device.
> + The memory for BusMasterRead need set EDKII_IOMMU_ATTRIBUTE_READ.
> + The memory for BusMasterWrite need set EDKII_IOMMU_ATTRIBUTE_WRITE.
> + The memory for BusMasterCommonBuffer need set 
> 

Re: [edk2] [PATCH] ShellPkg/ConsistMapping: Remove unneeded memory reallocation

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Ni, Ruiyu
> Sent: Sunday, April 16, 2017 11:29 PM
> To: edk2-devel@lists.01.org
> Cc: Michael Turner ; Carsey, Jaben
> 
> Subject: [PATCH] ShellPkg/ConsistMapping: Remove unneeded memory
> reallocation
> Importance: High
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Michael Turner 
> Cc: Jaben Carsey 
> ---
>  ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> index 09f2c56..3b13e62 100755
> --- a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> +++ b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> @@ -1,7 +1,7 @@
>  /** @file
>Main file for support of shell consist mapping.
> 
> -  Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2005 - 2017, 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 @@ -1610,7 +1610,6 @@ ShellCommandConsistMappingGenMappingName (
>DEVICE_CONSIST_MAPPING_INFO MappingInfo;
>EFI_DEVICE_PATH_PROTOCOL*HIDevicePath;
>UINTN   Index;
> -  CHAR16  *NewStr;
> 
>ASSERT(DevicePath != NULL);
>ASSERT(Table  != NULL);
> @@ -1667,13 +1666,7 @@ ShellCommandConsistMappingGenMappingName (
>  return NULL;
>}
> 
> -  NewStr = ReallocatePool (Str.Len * sizeof (CHAR16), (Str.Len + 1) * sizeof
> (CHAR16), Str.Str);
> -  if (NewStr == NULL) {
> -SHELL_FREE_NON_NULL (Str.Str);
> -return (NULL);
> -  }
> -  NewStr[Str.Len] = CHAR_NULL;
> -  return NewStr;
> +  return Str.Str;
>  }
> 
>  /**
> --
> 2.9.0.windows.1

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

Re: [edk2] [PATCH] ShellPkg/Pci: Always dump the extended config space for PCIE

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Ni, Ruiyu
> Sent: Sunday, April 16, 2017 8:13 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Jim Dailey 
> Subject: [PATCH] ShellPkg/Pci: Always dump the extended config space for PCIE
> Importance: High
> 
> It is to align to the original behavior before "-ec" option was added.
> 
> The patch also refines the code to make it more readable.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Jaben Carsey 
> Cc: Jim Dailey 
> ---
>  ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c | 318 +---
> --
>  1 file changed, 125 insertions(+), 193 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c
> index 37f15d6..99335f0 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c
> @@ -1905,16 +1905,12 @@ PciGetNextBusRange (
>@param[in] ConfigSpace Data in PCI configuration space.
>@param[in] Address Address used to access configuration space of 
> this
> PCI device.
>@param[in] IoDev   Handle used to access configuration space of PCI
> device.
> -  @param[in] EnhancedDumpThe print format for the dump data.
> -
> -  @retval EFI_SUCCESS The command completed successfully.
>  **/
> -EFI_STATUS
> -PciExplainData (
> +VOID
> +PciExplainPci (
>IN PCI_CONFIG_SPACE   *ConfigSpace,
>IN UINT64 Address,
> -  IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL*IoDev,
> -  IN CONST UINT16   EnhancedDump
> +  IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL*IoDev
>);
> 
>  /**
> @@ -2030,40 +2026,31 @@ PciExplainBridgeControl (
>);
> 
>  /**
> -  Print each capability structure.
> +  Locate capability register block per capability ID.
> 
> -  @param[in] IoDevThe pointer to the deivce.
> -  @param[in] Address  The address to start at.
> -  @param[in] CapPtr   The offset from the address.
> -  @param[in] EnhancedDump The print format for the dump data.
> +  @param[in] ConfigSpace   Data in PCI configuration space.
> +  @param[in] CapabilityId  The capability ID.
> 
> -  @retval EFI_SUCCESS The operation was successful.
> +  @return   The offset of the register block per capability ID.
>  **/
> -EFI_STATUS
> -PciExplainCapabilityStruct (
> -  IN  EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *IoDev,
> -  IN UINT64   Address,
> -  IN  UINT8   CapPtr,
> -  IN CONST UINT16EnhancedDump
> +UINT8
> +LocatePciCapability (
> +  IN PCI_CONFIG_SPACE   *ConfigSpace,
> +  IN UINT8  CapabilityId
>);
> 
>  /**
>Display Pcie device structure.
> 
> -  @param[in] IoDevThe pointer to the root pci protocol.
> -  @param[in] Address  The Address to start at.
> -  @param[in] CapabilityPtrThe offset from the address to start.
> -  @param[in] EnhancedDump The print format for the dump data.
> -
> -  @retval EFI_SUCCESS   The command completed successfully.
> -  @retval @retval EFI_SUCCESS   Pci express extend space IO is not suppoted.
> +  @param[in] PciExpressCap   PCI Express capability buffer.
> +  @param[in] ExtendedConfigSpace PCI Express extended configuration space.
> +  @param[in] ExtendedCapability  PCI Express extended capability ID to 
> explain.
>  **/
> -EFI_STATUS
> +VOID
>  PciExplainPciExpress (
> -  IN  EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *IoDev,
> -  IN  UINT64  Address,
> -  IN  UINT8   CapabilityPtr,
> -  IN CONST UINT16EnhancedDump
> +  IN  PCI_CAPABILITY_PCIEXP  *PciExpressCap,
> +  IN  UINT8  *ExtendedConfigSpace,
> +  IN CONST UINT16ExtendedCapability
>);
> 
>  /**
> @@ -2473,7 +2460,10 @@ ShellCommandRunPci (
>SHELL_STATUS  ShellStatus;
>CONST CHAR16  *Temp;
>UINT64RetVal;
> -  UINT16EnhancedDump;
> +  UINT16ExtendedCapability;
> +  UINT8 PcieCapabilityPtr;
> +  UINT8 *ExtendedConfigSpace;
> +  UINTN ExtendedConfigSize;
> 
>ShellStatus = SHELL_SUCCESS;
>Status  = EFI_SUCCESS;
> @@ -2726,7 +2716,7 @@ ShellCommandRunPci (
>  Bus   = 0;
>  Device= 0;
>  Func  = 0;
> -EnhancedDump  = 0x;
> +

Re: [edk2] NvmExpressDxe async application crash with UDK debugger

[Arka Sharma]

There is a mistake I had in my code. The NVMe command Packet is a
local variable to ReadSectors, whose address is being passed to
PassThru. So PassThru will return after pushing the command to async
submission queue  and create an AsyncRequest and insert it in
AsyncPassThruQueueand return. So the AsyncRequest->Packet is holding
an address of a stack variable of ReadSector. After getting return
from PassThru the ReadSector also return after that. This left the
address of Packet to be stale which is being access in
ProcessAsyncTaskList at
//
// Copy the Respose Queue entry for this command to the callers
// response buffer.
//
CopyMem (
  AsyncRequest->Packet->NvmeCompletion,
  Cq,
  sizeof(EFI_NVM_EXPRESS_COMPLETION)
  );
In this case AsyncRequest->Packet is a stale address. I allocated
Packet structure using AllocateZeroPool in ReadSectors and run the
application multiple times and have not yet observed crash. Thanks for
your effort and apologize for my mistake.

Regards,
Arka

On Thu, Apr 13, 2017 at 11:16 AM, Wu, Hao A  wrote:
> Hi Arka,
>
> I will help to look into this problem and will try to reproduce it first.
>
> Best Regards,
> Hao Wu
>
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Arka
>> Sharma
>> Sent: Wednesday, April 12, 2017 2:05 PM
>> To: Tian, Feng
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] NvmExpressDxe async application crash with UDK debugger
>>
>> Please find attached source. Also the variables to detect completion are
>> not volatile. I have checked in disassembly they are fetched from memory in
>> the completion loop.
>>
>> Regards,
>> Arka
>>
>> On 12 Apr 2017 10:37 a.m., "Tian, Feng"  wrote:
>>
>> > Arka,
>> >
>> > Could you please share us your test code?
>> >
>> > Thanks
>> > Feng
>> >
>> > -Original Message-
>> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> > Arka Sharma
>> > Sent: Wednesday, April 12, 2017 12:59 PM
>> > To: edk2-devel@lists.01.org
>> > Subject: [edk2] NvmExpressDxe async application crash with UDK debugger
>> >
>> > Hi,
>> >
>> > I am testing async io in NvmExpressDxe. The target system is Asrock
>> > Z97 which I have connected to host with serial port where UDK debugger is
>> > running. So my application does following
>> >
>> > 1. CreateEvent
>> > 2. Call Passthru
>> > 3. CmdSent++;
>> > 4. Repeat 1-3 until not ready from driver 5. while (CmdRecd < CmdSent); 4.
>> > Close all the events.
>> >
>> > CmdRecvd is incremented inside EventCallback. I am allocating both CmdSent
>> > and CmdRecvd and passing the address of CmdRecvd in CreateEvent. With
>> this
>> > I face WinDbg exception quite often and it says "Target encountered an
>> > exception: Vector = 6, Error Code = ".
>> > I can share the application code for more clarity. I am building with /Od
>> > and GenFw with --keepexceptiontable
>> >
>> > Regards,
>> > Arka
>> > ___
>> > edk2-devel mailing list
>> > edk2-devel@lists.01.org
>> > https://lists.01.org/mailman/listinfo/edk2-devel
>> >
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Update the Conf directory to use the absolute path

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: Zhu, Yonghong
>Sent: Monday, April 17, 2017 5:23 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming 
>Subject: [Patch] BaseTools: Update the Conf directory to use the absolute
>path
>
>Update the Conf directory to use the absolute path for build_rule.txt
>and tools_def.txt.
>
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/Python/AutoGen/AutoGen.py | 8 
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
>b/BaseTools/Source/Python/AutoGen/AutoGen.py
>index 3d3dfef..e1bdef0 100644
>--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
>+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
>@@ -60,14 +60,14 @@ gEfiVarStoreGuidPattern =
>re.compile("\s*guid\s*=\s*({.*?{.*?}\s*})")
> ## Mapping Makefile type
> gMakeTypeMap = {"MSFT":"nmake", "GCC":"gmake"}
>
>
> ## Build rule configuration file
>-gDefaultBuildRuleFile = 'Conf/build_rule.txt'
>+gDefaultBuildRuleFile = 'build_rule.txt'
>
> ## Tools definition configuration file
>-gDefaultToolsDefFile = 'Conf/tools_def.txt'
>+gDefaultToolsDefFile = 'tools_def.txt'
>
> ## Build rule default version
> AutoGenReqBuildRuleVerNum = "0.1"
>
> ## default file name for AutoGen
>@@ -724,12 +724,12 @@ class WorkspaceAutoGen(AutoGen):
> AllWorkSpaceMetaFiles.add(self.MetaFile.Path)
>
> #
> # add build_rule.txt & tools_def.txt
> #
>-AllWorkSpaceMetaFiles.add(gDefaultBuildRuleFile)
>-AllWorkSpaceMetaFiles.add(gDefaultToolsDefFile)
>+AllWorkSpaceMetaFiles.add(os.path.join(GlobalData.gConfDirectory,
>gDefaultBuildRuleFile))
>+AllWorkSpaceMetaFiles.add(os.path.join(GlobalData.gConfDirectory,
>gDefaultToolsDefFile))
>
> # add BuildOption metafile
> #
> AllWorkSpaceMetaFiles.add(os.path.join(self.BuildDir, 'BuildOptions'))
>
>--
>2.6.1.windows.1

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

[edk2] [Patch] BaseTools: Update the Conf directory to use the absolute path

[Yonghong Zhu]

Update the Conf directory to use the absolute path for build_rule.txt
and tools_def.txt.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 3d3dfef..e1bdef0 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -60,14 +60,14 @@ gEfiVarStoreGuidPattern = 
re.compile("\s*guid\s*=\s*({.*?{.*?}\s*})")
 ## Mapping Makefile type
 gMakeTypeMap = {"MSFT":"nmake", "GCC":"gmake"}
 
 
 ## Build rule configuration file
-gDefaultBuildRuleFile = 'Conf/build_rule.txt'
+gDefaultBuildRuleFile = 'build_rule.txt'
 
 ## Tools definition configuration file
-gDefaultToolsDefFile = 'Conf/tools_def.txt'
+gDefaultToolsDefFile = 'tools_def.txt'
 
 ## Build rule default version
 AutoGenReqBuildRuleVerNum = "0.1"
 
 ## default file name for AutoGen
@@ -724,12 +724,12 @@ class WorkspaceAutoGen(AutoGen):
 AllWorkSpaceMetaFiles.add(self.MetaFile.Path)
 
 #
 # add build_rule.txt & tools_def.txt
 #
-AllWorkSpaceMetaFiles.add(gDefaultBuildRuleFile)
-AllWorkSpaceMetaFiles.add(gDefaultToolsDefFile)
+AllWorkSpaceMetaFiles.add(os.path.join(GlobalData.gConfDirectory, 
gDefaultBuildRuleFile))
+AllWorkSpaceMetaFiles.add(os.path.join(GlobalData.gConfDirectory, 
gDefaultToolsDefFile))
 
 # add BuildOption metafile
 #
 AllWorkSpaceMetaFiles.add(os.path.join(self.BuildDir, 'BuildOptions'))
 
-- 
2.6.1.windows.1

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

Re: [edk2] [Patch] NetworkPkg: Correct the proxy DHCP offer handing

[Ye, Ting]

Reviewed-by: Ye Ting  

-Original Message-
From: Wu, Jiaxin 
Sent: Monday, April 17, 2017 11:40 AM
To: edk2-devel@lists.01.org
Cc: RickF ; Ye, Ting ; Fu, Siyuan 
; Zhang, Lubo ; Wu, Jiaxin 

Subject: [Patch] NetworkPkg: Correct the proxy DHCP offer handing

When PXE10/WFM11a offer received, we should only cache the first PXE10/WFM11a 
offer, and discard the others. But Current we discard all PXE10/WFM11a offer. 
This patch is to fix this issue.

Cc: RickF 
Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Zhang Lubo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c | 5 +++--  
NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c 
b/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c
index 5497390..97829e9 100644
--- a/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c
+++ b/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c
@@ -1,9 +1,9 @@
 /** @file
   Functions implementation related with DHCPv4 for UefiPxeBc Driver.
 
-  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2017, 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.
@@ -868,11 +868,12 @@ PxeBcCacheDhcp4Offer (
 //
 // Cache all proxy BINL offers.
 //
 Private->OfferIndex[OfferType][Private->OfferCount[OfferType]] = 
Private->OfferNum;
 Private->OfferCount[OfferType]++;
-  } else if (Private->OfferCount[OfferType] > 0) {
+  } else if ((OfferType == PxeOfferTypeProxyPxe10 || OfferType == 
PxeOfferTypeProxyWfm11a) && 
+ Private->OfferCount[OfferType] < 1) {
 //
 // Only cache the first PXE10/WFM11a offer, and discard the others.
 //
 Private->OfferIndex[OfferType][0] = Private->OfferNum;
 Private->OfferCount[OfferType]= 1;
diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c 
b/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c
index a295b82..4cd1770 100644
--- a/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c
+++ b/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c
@@ -1,10 +1,10 @@
 /** @file
   Functions implementation related with DHCPv6 for UefiPxeBc Driver.
 
   (C) Copyright 2014 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2017, 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.
@@ -1195,11 +1195,12 @@ PxeBcCacheDhcp6Offer (
   //
   // Cache all proxy BINL offers.
   //
   Private->OfferIndex[OfferType][Private->OfferCount[OfferType]] = 
Private->OfferNum;
   Private->OfferCount[OfferType]++;
-} else if (Private->OfferCount[OfferType] > 0) {
+} else if ((OfferType == PxeOfferTypeProxyPxe10 || OfferType == 
PxeOfferTypeProxyWfm11a) && 
+ Private->OfferCount[OfferType] < 1) {
   //
   // Only cache the first PXE10/WFM11a offer, and discard the others.
   //
   Private->OfferIndex[OfferType][0] = Private->OfferNum;
   Private->OfferCount[OfferType]= 1;
--
1.9.5.msysgit.1

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

[edk2] [Patch] MdeModulePkg/DeviceManagerUiLib: Fix the network device MAC display issue

[Jiaxin Wu]

Network device tile (STR_FORM_NETWORK_DEVICE_TITLE) is dynamic adjusted
according the different MAC value. So, the string value shouldn't be treated
as a constant string (Network Device). Otherwise, the display will be
incorrect.

Reproduce: Device Manager->Network Device List, select to enter MAC, then to
press ESC back to previous page, then re-enter, found each enter/ESC operation,
the MAC address display +1.

Cc: Eric Dong 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c 
b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
index 5098b70..8630ab0 100644
--- a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
+++ b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
@@ -538,17 +538,15 @@ CreateDeviceManagerForm(
 
   //
   // Update the network device form titile.
   //
   if (NextShowFormId == NETWORK_DEVICE_FORM_ID) {
-String = HiiGetString (HiiHandle, STRING_TOKEN 
(STR_FORM_NETWORK_DEVICE_TITLE), NULL);
 NewStringLen = StrLen(mSelectedMacAddrString) * 2;
-NewStringLen += (StrLen(String) + 2) * 2;
+NewStringLen += (StrLen (L"Network Device") + 2) * 2;
 NewStringTitle = AllocatePool (NewStringLen);
-UnicodeSPrint (NewStringTitle, NewStringLen, L"%s %s", String, 
mSelectedMacAddrString);
+UnicodeSPrint (NewStringTitle, NewStringLen, L"Network Device %s", 
mSelectedMacAddrString);
 HiiSetString (HiiHandle, STRING_TOKEN (STR_FORM_NETWORK_DEVICE_TITLE), 
NewStringTitle, NULL);
-FreePool (String);
 FreePool (NewStringTitle);
   }
 
   //
   // Allocate space for creation of UpdateData Buffer
-- 
1.9.5.msysgit.1

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

Re: [edk2] SUT hangs after performing a warm boot.

[Santhapur Naveen]

Jiaxin,

Filed a bug in the bugzilla 
https://bugzilla.tianocore.org/show_bug.cgi?id=489
Let me know if you may need any details.

Regards,
Naveen
-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
Sent: Monday, April 17, 2017 12:12 PM
To: Santhapur Naveen; edk2-devel@lists.01.org
Cc: Zhang, Lubo
Subject: RE: SUT hangs after performing a warm boot.

Naveen, 

Can you record the issue @ Bugzilla first? Then, we can update the process 
directly.

Thanks,
Jiaxin

> -Original Message-
> From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> Sent: Monday, April 17, 2017 2:36 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Zhang, Lubo 
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Thank you Jiaxin. I didn't have access to my mail for the last 3-4 
> days. Sorry for the delay.
> 
> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Monday, April 17, 2017 12:05 PM
> To: Santhapur Naveen; edk2-devel@lists.01.org
> Cc: Zhang, Lubo
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Thanks Naveen,  I will try reproduce it, then report to you.
> 
> 
> > -Original Message-
> > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > Sent: Monday, April 17, 2017 2:33 PM
> > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > Cc: Zhang, Lubo 
> > Subject: RE: SUT hangs after performing a warm boot.
> >
> > Hi Jiaxin,
> >
> > The latter is correct. Restart the windows and the hang happens.
> >
> > Thanks,
> > Naveen
> >
> > -Original Message-
> > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > Sent: Thursday, April 13, 2017 1:34 PM
> > To: Wu, Jiaxin; Santhapur Naveen; edk2-devel@lists.01.org
> > Cc: Zhang, Lubo
> > Subject: RE: SUT hangs after performing a warm boot.
> >
> > Or do you mean the issue should be reproduce at window warm boot 
> > with below steps?
> >
> > 1. Boot to windows
> > 2. restart the windows, then hang happen?
> >
> > Thanks,
> > Jiaxin
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On 
> > > Behalf Of Wu, Jiaxin
> > > Sent: Thursday, April 13, 2017 3:48 PM
> > > To: Santhapur Naveen ; 
> > > edk2-devel@lists.01.org
> > > Cc: Zhang, Lubo 
> > > Subject: Re: [edk2] SUT hangs after performing a warm boot.
> > >
> > > Naveen,
> > >
> > > Do you mean only the "reset -w" operation caused the hang? Need us 
> > > change the IPv6 policy?
> > >
> > > Thanks,
> > > Jiaxin
> > >
> > > > -Original Message-
> > > > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > > > Sent: Wednesday, April 12, 2017 8:12 PM
> > > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > > Cc: Zhang, Lubo 
> > > > Subject: RE: SUT hangs after performing a warm boot.
> > > >
> > > > Hi Jiaxin,
> > > >
> > > > The patch in your previous mail doesn't help. The issue still 
> > > > exists even after the patch.
> > > > After some debugging, it is found that it hangs in 
> > > > p6SendNeighborSolicit()->Ip6Output()call.
> > > >
> > > > //
> > > >   // Send the Neighbor Solicitation message with
> > > >   // Source - unspecified address, destination - 
> > > > solicited-node multicast address
> > > >   // Target - the address to be validated
> > > >   //
> > > >   Status = Ip6SendNeighborSolicit (
> > > >  IpSb,
> > > >  NULL,
> > > >  >Destination,
> > > >  >AddressInfo->Address,
> > > >  NULL
> > > >  );
> > > >
> > > > I shall update you more information soon.
> > > >
> > > > Thanks,
> > > > Naveen
> > > >
> > > > -Original Message-
> > > > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > > > Sent: Tuesday, April 11, 2017 8:55 AM
> > > > To: Santhapur Naveen; edk2-devel@lists.01.org
> > > > Cc: Zhang, Lubo
> > > > Subject: RE: SUT hangs after performing a warm boot.
> > > >
> > > > Ok, I didn't loop in another email discussion. I just reviewed 
> > > > the patch from Lubo, and I think it may be related to this issue 
> > > > since both of them are triggered  by Ip6NdFasterTimerTicking.
> > > >
> > > > Thanks,
> > > > Jiaxin
> > > >
> > > > > -Original Message-
> > > > > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > > > > Sent: Tuesday, April 11, 2017 10:20 AM
> > > > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > > > Subject: RE: SUT hangs after performing a warm boot.
> > > > >
> > > > > Hi Jiaxin,
> > > > >
> > > > >   I think this patch is for another fix which causes ASSERT. 
> > > > > But anyways I'll give it a try and update you.
> > > > >
> > > > > Thanks,
> > > > > Naveen
> > > > >
> > > > > -Original Message-
> > > 

Re: [edk2] SUT hangs after performing a warm boot.

[Wu, Jiaxin]

Naveen, 

Can you record the issue @ Bugzilla first? Then, we can update the process 
directly.

Thanks,
Jiaxin

> -Original Message-
> From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> Sent: Monday, April 17, 2017 2:36 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Zhang, Lubo 
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Thank you Jiaxin. I didn't have access to my mail for the last 3-4 days. Sorry
> for the delay.
> 
> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Monday, April 17, 2017 12:05 PM
> To: Santhapur Naveen; edk2-devel@lists.01.org
> Cc: Zhang, Lubo
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Thanks Naveen,  I will try reproduce it, then report to you.
> 
> 
> > -Original Message-
> > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > Sent: Monday, April 17, 2017 2:33 PM
> > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > Cc: Zhang, Lubo 
> > Subject: RE: SUT hangs after performing a warm boot.
> >
> > Hi Jiaxin,
> >
> > The latter is correct. Restart the windows and the hang happens.
> >
> > Thanks,
> > Naveen
> >
> > -Original Message-
> > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > Sent: Thursday, April 13, 2017 1:34 PM
> > To: Wu, Jiaxin; Santhapur Naveen; edk2-devel@lists.01.org
> > Cc: Zhang, Lubo
> > Subject: RE: SUT hangs after performing a warm boot.
> >
> > Or do you mean the issue should be reproduce at window warm boot with
> > below steps?
> >
> > 1. Boot to windows
> > 2. restart the windows, then hang happen?
> >
> > Thanks,
> > Jiaxin
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > Of Wu, Jiaxin
> > > Sent: Thursday, April 13, 2017 3:48 PM
> > > To: Santhapur Naveen ;
> > > edk2-devel@lists.01.org
> > > Cc: Zhang, Lubo 
> > > Subject: Re: [edk2] SUT hangs after performing a warm boot.
> > >
> > > Naveen,
> > >
> > > Do you mean only the "reset -w" operation caused the hang? Need us
> > > change the IPv6 policy?
> > >
> > > Thanks,
> > > Jiaxin
> > >
> > > > -Original Message-
> > > > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > > > Sent: Wednesday, April 12, 2017 8:12 PM
> > > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > > Cc: Zhang, Lubo 
> > > > Subject: RE: SUT hangs after performing a warm boot.
> > > >
> > > > Hi Jiaxin,
> > > >
> > > > The patch in your previous mail doesn't help. The issue still
> > > > exists even after the patch.
> > > > After some debugging, it is found that it hangs in
> > > > p6SendNeighborSolicit()->Ip6Output()call.
> > > >
> > > > //
> > > >   // Send the Neighbor Solicitation message with
> > > >   // Source - unspecified address, destination -
> > > > solicited-node multicast address
> > > >   // Target - the address to be validated
> > > >   //
> > > >   Status = Ip6SendNeighborSolicit (
> > > >  IpSb,
> > > >  NULL,
> > > >  >Destination,
> > > >  >AddressInfo->Address,
> > > >  NULL
> > > >  );
> > > >
> > > > I shall update you more information soon.
> > > >
> > > > Thanks,
> > > > Naveen
> > > >
> > > > -Original Message-
> > > > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > > > Sent: Tuesday, April 11, 2017 8:55 AM
> > > > To: Santhapur Naveen; edk2-devel@lists.01.org
> > > > Cc: Zhang, Lubo
> > > > Subject: RE: SUT hangs after performing a warm boot.
> > > >
> > > > Ok, I didn't loop in another email discussion. I just reviewed the
> > > > patch from Lubo, and I think it may be related to this issue since
> > > > both of them are triggered  by Ip6NdFasterTimerTicking.
> > > >
> > > > Thanks,
> > > > Jiaxin
> > > >
> > > > > -Original Message-
> > > > > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > > > > Sent: Tuesday, April 11, 2017 10:20 AM
> > > > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > > > Subject: RE: SUT hangs after performing a warm boot.
> > > > >
> > > > > Hi Jiaxin,
> > > > >
> > > > >   I think this patch is for another fix which causes ASSERT. But
> > > > > anyways I'll give it a try and update you.
> > > > >
> > > > > Thanks,
> > > > > Naveen
> > > > >
> > > > > -Original Message-
> > > > > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > > > > Sent: Tuesday, April 11, 2017 7:05 AM
> > > > > To: Santhapur Naveen; edk2-devel@lists.01.org
> > > > > Subject: RE: SUT hangs after performing a warm boot.
> > > > >
> > > > > Hi Naveen,
> > > > >
> > > > > Can you help to verify whether the attached patch can resolve
> > > > > your
> > issue?
> > > > >
> > > > > Thanks,
> > > > > Jiaxin
> 

Re: [edk2] SUT hangs after performing a warm boot.

[Santhapur Naveen]

Thank you Jiaxin. I didn't have access to my mail for the last 3-4 days. Sorry 
for the delay.

-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
Sent: Monday, April 17, 2017 12:05 PM
To: Santhapur Naveen; edk2-devel@lists.01.org
Cc: Zhang, Lubo
Subject: RE: SUT hangs after performing a warm boot.

Thanks Naveen,  I will try reproduce it, then report to you. 


> -Original Message-
> From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> Sent: Monday, April 17, 2017 2:33 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Zhang, Lubo 
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Hi Jiaxin,
> 
>   The latter is correct. Restart the windows and the hang happens.
> 
> Thanks,
> Naveen
> 
> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Thursday, April 13, 2017 1:34 PM
> To: Wu, Jiaxin; Santhapur Naveen; edk2-devel@lists.01.org
> Cc: Zhang, Lubo
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Or do you mean the issue should be reproduce at window warm boot with 
> below steps?
> 
> 1. Boot to windows
> 2. restart the windows, then hang happen?
> 
> Thanks,
> Jiaxin
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Wu, Jiaxin
> > Sent: Thursday, April 13, 2017 3:48 PM
> > To: Santhapur Naveen ; 
> > edk2-devel@lists.01.org
> > Cc: Zhang, Lubo 
> > Subject: Re: [edk2] SUT hangs after performing a warm boot.
> >
> > Naveen,
> >
> > Do you mean only the "reset -w" operation caused the hang? Need us 
> > change the IPv6 policy?
> >
> > Thanks,
> > Jiaxin
> >
> > > -Original Message-
> > > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > > Sent: Wednesday, April 12, 2017 8:12 PM
> > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > Cc: Zhang, Lubo 
> > > Subject: RE: SUT hangs after performing a warm boot.
> > >
> > > Hi Jiaxin,
> > >
> > >   The patch in your previous mail doesn't help. The issue still 
> > > exists even after the patch.
> > >   After some debugging, it is found that it hangs in 
> > > p6SendNeighborSolicit()->Ip6Output()call.
> > >
> > >   //
> > >   // Send the Neighbor Solicitation message with
> > >   // Source - unspecified address, destination - 
> > > solicited-node multicast address
> > >   // Target - the address to be validated
> > >   //
> > >   Status = Ip6SendNeighborSolicit (
> > >  IpSb,
> > >  NULL,
> > >  >Destination,
> > >  >AddressInfo->Address,
> > >  NULL
> > >  );
> > >
> > >   I shall update you more information soon.
> > >
> > > Thanks,
> > > Naveen
> > >
> > > -Original Message-
> > > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > > Sent: Tuesday, April 11, 2017 8:55 AM
> > > To: Santhapur Naveen; edk2-devel@lists.01.org
> > > Cc: Zhang, Lubo
> > > Subject: RE: SUT hangs after performing a warm boot.
> > >
> > > Ok, I didn't loop in another email discussion. I just reviewed the 
> > > patch from Lubo, and I think it may be related to this issue since 
> > > both of them are triggered  by Ip6NdFasterTimerTicking.
> > >
> > > Thanks,
> > > Jiaxin
> > >
> > > > -Original Message-
> > > > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > > > Sent: Tuesday, April 11, 2017 10:20 AM
> > > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > > Subject: RE: SUT hangs after performing a warm boot.
> > > >
> > > > Hi Jiaxin,
> > > >
> > > > I think this patch is for another fix which causes ASSERT. But 
> > > > anyways I'll give it a try and update you.
> > > >
> > > > Thanks,
> > > > Naveen
> > > >
> > > > -Original Message-
> > > > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > > > Sent: Tuesday, April 11, 2017 7:05 AM
> > > > To: Santhapur Naveen; edk2-devel@lists.01.org
> > > > Subject: RE: SUT hangs after performing a warm boot.
> > > >
> > > > Hi Naveen,
> > > >
> > > > Can you help to verify whether the attached patch can resolve 
> > > > your
> issue?
> > > >
> > > > Thanks,
> > > > Jiaxin
> > > >
> > > > > -Original Message-
> > > > > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > > > > Sent: Monday, April 10, 2017 7:31 PM
> > > > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > > > Subject: RE: SUT hangs after performing a warm boot.
> > > > >
> > > > > Hi Jiaxin,
> > > > >
> > > > >   Below are the simple reproduction steps:
> > > > >
> > > > >   BIOS UEFI Class3
> > > > >   (1)   Connect LAN cable (Realtek)
> > > > >   (2)   Do cold boot or warm boot stress (Windows 10)
> > > > >
> > > > >   Please let me know for any additional information you may need.
> > > > >
> > > > > Thanks,
> 

Re: [edk2] SUT hangs after performing a warm boot.

[Wu, Jiaxin]

Thanks Naveen,  I will try reproduce it, then report to you. 


> -Original Message-
> From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> Sent: Monday, April 17, 2017 2:33 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Zhang, Lubo 
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Hi Jiaxin,
> 
>   The latter is correct. Restart the windows and the hang happens.
> 
> Thanks,
> Naveen
> 
> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Thursday, April 13, 2017 1:34 PM
> To: Wu, Jiaxin; Santhapur Naveen; edk2-devel@lists.01.org
> Cc: Zhang, Lubo
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Or do you mean the issue should be reproduce at window warm boot with
> below steps?
> 
> 1. Boot to windows
> 2. restart the windows, then hang happen?
> 
> Thanks,
> Jiaxin
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Wu, Jiaxin
> > Sent: Thursday, April 13, 2017 3:48 PM
> > To: Santhapur Naveen ; edk2-devel@lists.01.org
> > Cc: Zhang, Lubo 
> > Subject: Re: [edk2] SUT hangs after performing a warm boot.
> >
> > Naveen,
> >
> > Do you mean only the "reset -w" operation caused the hang? Need us
> > change the IPv6 policy?
> >
> > Thanks,
> > Jiaxin
> >
> > > -Original Message-
> > > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > > Sent: Wednesday, April 12, 2017 8:12 PM
> > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > Cc: Zhang, Lubo 
> > > Subject: RE: SUT hangs after performing a warm boot.
> > >
> > > Hi Jiaxin,
> > >
> > >   The patch in your previous mail doesn't help. The issue still
> > > exists even after the patch.
> > >   After some debugging, it is found that it hangs in
> > > p6SendNeighborSolicit()->Ip6Output()call.
> > >
> > >   //
> > >   // Send the Neighbor Solicitation message with
> > >   // Source - unspecified address, destination -
> > > solicited-node multicast address
> > >   // Target - the address to be validated
> > >   //
> > >   Status = Ip6SendNeighborSolicit (
> > >  IpSb,
> > >  NULL,
> > >  >Destination,
> > >  >AddressInfo->Address,
> > >  NULL
> > >  );
> > >
> > >   I shall update you more information soon.
> > >
> > > Thanks,
> > > Naveen
> > >
> > > -Original Message-
> > > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > > Sent: Tuesday, April 11, 2017 8:55 AM
> > > To: Santhapur Naveen; edk2-devel@lists.01.org
> > > Cc: Zhang, Lubo
> > > Subject: RE: SUT hangs after performing a warm boot.
> > >
> > > Ok, I didn't loop in another email discussion. I just reviewed the
> > > patch from Lubo, and I think it may be related to this issue since
> > > both of them are triggered  by Ip6NdFasterTimerTicking.
> > >
> > > Thanks,
> > > Jiaxin
> > >
> > > > -Original Message-
> > > > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > > > Sent: Tuesday, April 11, 2017 10:20 AM
> > > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > > Subject: RE: SUT hangs after performing a warm boot.
> > > >
> > > > Hi Jiaxin,
> > > >
> > > > I think this patch is for another fix which causes ASSERT. But
> > > > anyways I'll give it a try and update you.
> > > >
> > > > Thanks,
> > > > Naveen
> > > >
> > > > -Original Message-
> > > > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > > > Sent: Tuesday, April 11, 2017 7:05 AM
> > > > To: Santhapur Naveen; edk2-devel@lists.01.org
> > > > Subject: RE: SUT hangs after performing a warm boot.
> > > >
> > > > Hi Naveen,
> > > >
> > > > Can you help to verify whether the attached patch can resolve your
> issue?
> > > >
> > > > Thanks,
> > > > Jiaxin
> > > >
> > > > > -Original Message-
> > > > > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > > > > Sent: Monday, April 10, 2017 7:31 PM
> > > > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > > > Subject: RE: SUT hangs after performing a warm boot.
> > > > >
> > > > > Hi Jiaxin,
> > > > >
> > > > >   Below are the simple reproduction steps:
> > > > >
> > > > >   BIOS UEFI Class3
> > > > >   (1)   Connect LAN cable (Realtek)
> > > > >   (2)   Do cold boot or warm boot stress (Windows 10)
> > > > >
> > > > >   Please let me know for any additional information you may need.
> > > > >
> > > > > Thanks,
> > > > > Naveen
> > > > >
> > > > > -Original Message-
> > > > > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > > > > Sent: Monday, April 10, 2017 6:00 AM
> > > > > To: Santhapur Naveen; edk2-devel@lists.01.org
> > > > > Subject: RE: SUT hangs after performing a warm boot.
> > > > >
> > > > > Hi Naveen,
> > > > >
> > > > > As the 

Re: [edk2] SUT hangs after performing a warm boot.

[Santhapur Naveen]

Hi Jiaxin,

The latter is correct. Restart the windows and the hang happens.

Thanks,
Naveen

-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
Sent: Thursday, April 13, 2017 1:34 PM
To: Wu, Jiaxin; Santhapur Naveen; edk2-devel@lists.01.org
Cc: Zhang, Lubo
Subject: RE: SUT hangs after performing a warm boot.

Or do you mean the issue should be reproduce at window warm boot with below 
steps?

1. Boot to windows
2. restart the windows, then hang happen?

Thanks,
Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Wu, Jiaxin
> Sent: Thursday, April 13, 2017 3:48 PM
> To: Santhapur Naveen ; edk2-devel@lists.01.org
> Cc: Zhang, Lubo 
> Subject: Re: [edk2] SUT hangs after performing a warm boot.
> 
> Naveen,
> 
> Do you mean only the "reset -w" operation caused the hang? Need us 
> change the IPv6 policy?
> 
> Thanks,
> Jiaxin
> 
> > -Original Message-
> > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > Sent: Wednesday, April 12, 2017 8:12 PM
> > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > Cc: Zhang, Lubo 
> > Subject: RE: SUT hangs after performing a warm boot.
> >
> > Hi Jiaxin,
> >
> > The patch in your previous mail doesn't help. The issue still 
> > exists even after the patch.
> > After some debugging, it is found that it hangs in 
> > p6SendNeighborSolicit()->Ip6Output()call.
> >
> > //
> >   // Send the Neighbor Solicitation message with
> >   // Source - unspecified address, destination - 
> > solicited-node multicast address
> >   // Target - the address to be validated
> >   //
> >   Status = Ip6SendNeighborSolicit (
> >  IpSb,
> >  NULL,
> >  >Destination,
> >  >AddressInfo->Address,
> >  NULL
> >  );
> >
> > I shall update you more information soon.
> >
> > Thanks,
> > Naveen
> >
> > -Original Message-
> > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > Sent: Tuesday, April 11, 2017 8:55 AM
> > To: Santhapur Naveen; edk2-devel@lists.01.org
> > Cc: Zhang, Lubo
> > Subject: RE: SUT hangs after performing a warm boot.
> >
> > Ok, I didn't loop in another email discussion. I just reviewed the 
> > patch from Lubo, and I think it may be related to this issue since 
> > both of them are triggered  by Ip6NdFasterTimerTicking.
> >
> > Thanks,
> > Jiaxin
> >
> > > -Original Message-
> > > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > > Sent: Tuesday, April 11, 2017 10:20 AM
> > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > Subject: RE: SUT hangs after performing a warm boot.
> > >
> > > Hi Jiaxin,
> > >
> > >   I think this patch is for another fix which causes ASSERT. But 
> > > anyways I'll give it a try and update you.
> > >
> > > Thanks,
> > > Naveen
> > >
> > > -Original Message-
> > > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > > Sent: Tuesday, April 11, 2017 7:05 AM
> > > To: Santhapur Naveen; edk2-devel@lists.01.org
> > > Subject: RE: SUT hangs after performing a warm boot.
> > >
> > > Hi Naveen,
> > >
> > > Can you help to verify whether the attached patch can resolve your issue?
> > >
> > > Thanks,
> > > Jiaxin
> > >
> > > > -Original Message-
> > > > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > > > Sent: Monday, April 10, 2017 7:31 PM
> > > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > > Subject: RE: SUT hangs after performing a warm boot.
> > > >
> > > > Hi Jiaxin,
> > > >
> > > > Below are the simple reproduction steps:
> > > >
> > > > BIOS UEFI Class3
> > > > (1)   Connect LAN cable (Realtek)
> > > > (2)   Do cold boot or warm boot stress (Windows 10)
> > > >
> > > > Please let me know for any additional information you may need.
> > > >
> > > > Thanks,
> > > > Naveen
> > > >
> > > > -Original Message-
> > > > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > > > Sent: Monday, April 10, 2017 6:00 AM
> > > > To: Santhapur Naveen; edk2-devel@lists.01.org
> > > > Subject: RE: SUT hangs after performing a warm boot.
> > > >
> > > > Hi Naveen,
> > > >
> > > > As the description of Ip6NdFasterTimerTicking(), it's the time 
> > > > routine of ND module for IPv6.
> > > >
> > > > Can you provide the detailed reproduce steps?
> > > >
> > > > Thanks,
> > > > Jiaxin
> > > >
> > > > > -Original Message-
> > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On 
> > > > > Behalf Of Santhapur Naveen
> > > > > Sent: Friday, April 7, 2017 8:20 PM
> > > > > To: edk2-devel@lists.01.org
> > > > > Subject: [edk2] SUT hangs after performing a warm boot.
> > > > >
> > > > > Hi all,
> > > > >
> > > > >   Under NetworkPkg, in Ip6Dxe driver, what purpose 
> > 

[edk2] [PATCH] ShellPkg/ConsistMapping: Remove unneeded memory reallocation

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Michael Turner 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c 
b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
index 09f2c56..3b13e62 100755
--- a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
+++ b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
@@ -1,7 +1,7 @@
 /** @file
   Main file for support of shell consist mapping.
 
-  Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2005 - 2017, 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
@@ -1610,7 +1610,6 @@ ShellCommandConsistMappingGenMappingName (
   DEVICE_CONSIST_MAPPING_INFO MappingInfo;
   EFI_DEVICE_PATH_PROTOCOL*HIDevicePath;
   UINTN   Index;
-  CHAR16  *NewStr;
 
   ASSERT(DevicePath != NULL);
   ASSERT(Table  != NULL);
@@ -1667,13 +1666,7 @@ ShellCommandConsistMappingGenMappingName (
 return NULL;
   }
 
-  NewStr = ReallocatePool (Str.Len * sizeof (CHAR16), (Str.Len + 1) * sizeof 
(CHAR16), Str.Str);
-  if (NewStr == NULL) {
-SHELL_FREE_NON_NULL (Str.Str);
-return (NULL);
-  }
-  NewStr[Str.Len] = CHAR_NULL;
-  return NewStr;
+  return Str.Str;
 }
 
 /**
-- 
2.9.0.windows.1

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