[edk2] [PATCH] ShellPkg: Update the help information for 'setvar' command to follow Shell behavior.

[Qiu Shumin]

Cc: Jaben Carsey 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 
---
 .../UefiShellDebug1CommandsLib.uni | Bin 140668 -> 140676 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni
index 
167cacc70dc5fe582a8c3b4d47ed042f7994879c..e16175a6174fbd08275d14d88eaa385e42ae4781
 100644
GIT binary patch
delta 40
tcmex!ilgN;N5d9IpSg^2)4k_1N&~6Xxs2UF>it|sNyfPC?DH5)+W|?A4;BCb

delta 51
zcmZoU&GF|HN5d9IpSjch<}yl6&zj5FC9cE}%HYfp%wWWz%TUZv!cfGJ$&km8zMX#_
HV`)18$NLY3

-- 
1.9.5.msysgit.1

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

[edk2] [Patch 0/4] Optimize HTTP to speed up the download process

[Fu Siyuan]

These patches update the HttpDxe and HttpBootDxe driver to speed the download.
See the comments in each patch file for details.

Fu Siyuan (4):
  NetworkPkg: Enlarge receive block size of HTTP boot driver.
  NetworkPkg: Update cache management in HTTP boot driver.
  NetworkPkg: Update Http driver to use DPC mechanism.
  NetworkPkg: Avoid memory allocation for each HTTP message exchange.

 NetworkPkg/HttpBootDxe/HttpBootClient.c | 63 +--
 NetworkPkg/HttpBootDxe/HttpBootClient.h |  2 +-
 NetworkPkg/HttpDxe/HttpDriver.h |  2 +-
 NetworkPkg/HttpDxe/HttpDxe.inf  |  1 +
 NetworkPkg/HttpDxe/HttpImpl.c   | 28 +-
 NetworkPkg/HttpDxe/HttpProto.c  | 66 +
 NetworkPkg/HttpDxe/HttpProto.h  |  4 ++
 7 files changed, 118 insertions(+), 48 deletions(-)

-- 
2.5.0.windows.1

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

[edk2] [Patch 2/4] NetworkPkg: Update cache management in HTTP boot driver.

[Fu Siyuan]

The original HTTP boot driver always save the received message body in its 
cache,
it bring a large of memory allocation during HTTP download. This patch updates
the HTTP boot driver to only cache data when caller doesn't provide a buffer for
download (which is usually used when caller want to get the required buffer 
size).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpBootDxe/HttpBootClient.c | 63 ++---
 1 file changed, 35 insertions(+), 28 deletions(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.c 
b/NetworkPkg/HttpBootDxe/HttpBootClient.c
index 3b4afc3..5669c5f 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootClient.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootClient.c
@@ -458,22 +458,6 @@ HttpBootGetBootFileCallback (
   }
 
   CallbackData = (HTTP_BOOT_CALLBACK_DATA *) Context;
-
-  //
-  // Save the data into cache list.
-  //
-  NewEntityData = AllocatePool (sizeof (HTTP_BOOT_ENTITY_DATA));
-  if (NewEntityData == NULL) {
-return EFI_OUT_OF_RESOURCES;
-  }
-  if (CallbackData->NewBlock) {
-NewEntityData->Block = CallbackData->Block;
-CallbackData->Block = NULL;
-  }
-  NewEntityData->DataLength = Length;
-  NewEntityData->DataStart  = (UINT8*) Data;
-  InsertTailList (&CallbackData->Cache->EntityDataList, &NewEntityData->Link);
-
   //
   // Copy data if caller has provided a buffer.
   //
@@ -486,6 +470,22 @@ HttpBootGetBootFileCallback (
 CallbackData->CopyedSize += MIN (Length, CallbackData->BufferSize - 
CallbackData->CopyedSize);
   }
 
+  //
+  // The caller doesn't provide a buffer, save the block into cache list.
+  //
+  if (CallbackData->Cache != NULL) {
+NewEntityData = AllocatePool (sizeof (HTTP_BOOT_ENTITY_DATA));
+if (NewEntityData == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
+if (CallbackData->NewBlock) {
+  NewEntityData->Block = CallbackData->Block;
+  CallbackData->Block = NULL;
+}
+NewEntityData->DataLength = Length;
+NewEntityData->DataStart  = (UINT8*) Data;
+InsertTailList (&CallbackData->Cache->EntityDataList, 
&NewEntityData->Link);
+  }
   return EFI_SUCCESS;
 }
 
@@ -566,10 +566,10 @@ HttpBootGetBootFile (
   //
 
   //
-  // 1. Create a temp cache item for the requested URI.
+  // 1. Create a temp cache item for the requested URI if caller doesn't 
provide buffer.
   //
   Cache = NULL;
-  if (!HeaderOnly) {
+  if ((!HeaderOnly) && (*BufferSize == 0)) {
 Cache = AllocateZeroPool (sizeof (HTTP_BOOT_CACHE_CONTENT));
 if (Cache == NULL) {
   Status = EFI_OUT_OF_RESOURCES;
@@ -659,7 +659,7 @@ HttpBootGetBootFile (
   //
   // 2.3 Record the request info in a temp cache item.
   //
-  if (!HeaderOnly) {
+  if (Cache != NULL) {
 Cache->RequestData = RequestData;
   }
 
@@ -703,7 +703,7 @@ HttpBootGetBootFile (
   //
   // 3.2 Cache the response header.
   //
-  if (!HeaderOnly) {
+  if (Cache != NULL) {
 Cache->ResponseData = ResponseData;
   }
   
@@ -733,17 +733,26 @@ HttpBootGetBootFile (
   //
   // 3.4 Continue to receive and parse message-body if needed.
   //
+  Block = NULL;
   if (!HeaderOnly) {
 ZeroMem (&ResponseBody, sizeof (HTTP_IO_RESOPNSE_DATA));
 while (!HttpIsMessageComplete (Parser)) {
   //
-  // Allocate a new block to hold the message-body.
+  // Allocate a block to hold the message-body, if caller doesn't provide
+  // a buffer, the block will be cached and we will allocate a new one 
here.
   //
-  Block = AllocatePool (HTTP_BOOT_BLOCK_SIZE);
-  if (Block == NULL) {
-Status = EFI_OUT_OF_RESOURCES;
-goto ERROR_6;
+  if (Block == NULL || Context.BufferSize == 0) {
+Block = AllocatePool (HTTP_BOOT_BLOCK_SIZE);
+if (Block == NULL) {
+  Status = EFI_OUT_OF_RESOURCES;
+  goto ERROR_6;
+}
+Context.NewBlock = TRUE;
+Context.Block = Block;
+  } else {
+Context.NewBlock = FALSE;
   }
+
   ResponseBody.Body   = (CHAR8*) Block;
   ResponseBody.BodyLength = HTTP_BOOT_BLOCK_SIZE;
   Status = HttpIoRecvResponse (
@@ -758,8 +767,6 @@ HttpBootGetBootFile (
   //
   // Parse the new received block of the message-body, the block will be 
saved in cache.
   //
-  Context.NewBlock = TRUE;
-  Context.Block= Block;
   Status = HttpParseMessageBody (
  Parser,
  ResponseBody.BodyLength,
@@ -787,7 +794,7 @@ HttpBootGetBootFile (
   //
   // 4. Save the cache item to driver's cache list and return.
   //
-  if (!HeaderOnly) {
+  if (Cache != NULL) {
 Cache->EntityLength = ContentLength;
 InsertTailList (&Private->CacheList, &Cache->Link);
   }
-- 
2.5.0.windows.1

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

[edk2] [Patch 4/4] NetworkPkg: Avoid memory allocation for each HTTP message exchange.

[Fu Siyuan]

This patch updates the HTTP driver to use a shared buffer for URL parsing to
avoid memory allocation for each HTTP request.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpDxe/HttpImpl.c  | 19 ++-
 NetworkPkg/HttpDxe/HttpProto.c | 11 +++
 NetworkPkg/HttpDxe/HttpProto.h |  4 
 3 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index c176a65..2b62dc5 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -224,6 +224,7 @@ EfiHttpRequest (
   BOOLEAN   ReConfigure;
   CHAR8 *RequestStr;
   CHAR8 *Url;
+  UINTN UrlLen;
   CHAR16*HostNameStr;
   HTTP_TOKEN_WRAP   *Wrap;
   HTTP_TCP_TOKEN_WRAP   *TcpWrap;
@@ -283,10 +284,15 @@ EfiHttpRequest (
   //
   // Parse the URI of the remote host.
   //
-  Url = AllocatePool (StrLen (Request->Url) + 1);
-  if (Url == NULL) {
-return EFI_OUT_OF_RESOURCES;
-  }
+  UrlLen = StrLen (Request->Url) + 1;
+  if (UrlLen > HTTP_URL_BUFFER_LEN) {
+Url = AllocateZeroPool (UrlLen);
+if (Url == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
+FreePool (HttpInstance->Url);
+HttpInstance->Url = Url;
+  }  
 
   UnicodeStrToAsciiStr (Request->Url, Url);
   UrlParser = NULL;
@@ -347,7 +353,6 @@ EfiHttpRequest (
 
 Wrap->TcpWrap.Method = Request->Method;
 
-FreePool (Url);
 FreePool (HostName);
 
 //
@@ -480,7 +485,6 @@ EfiHttpRequest (
 goto Error4;
   }
 
-  FreePool (Url);
   if (HostName != NULL) {
 FreePool (HostName);
   }
@@ -522,9 +526,6 @@ Error2:
   }
 
 Error1:
-  if (Url != NULL) {
-FreePool (Url);
-  }
   if (HostName != NULL) {
 FreePool (HostName);
   }
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c
index 06a41b7..8fbd454 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -470,6 +470,12 @@ HttpInitProtocol (
 goto ON_ERROR;
   }
 
+  HttpInstance->Url = AllocateZeroPool (HTTP_URL_BUFFER_LEN);
+  if (HttpInstance->Url == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+goto ON_ERROR;
+  }
+
   NetMapInit (&HttpInstance->TxTokens);
   NetMapInit (&HttpInstance->RxTokens);
 
@@ -535,6 +541,11 @@ HttpCleanProtocol (
 HttpInstance->MsgParser = NULL;
   }
 
+  if (HttpInstance->Url != NULL) {
+FreePool (HttpInstance->Url);
+HttpInstance->Url = NULL;
+  }
+
   NetMapClean (&HttpInstance->TxTokens);
   NetMapClean (&HttpInstance->RxTokens);
 
diff --git a/NetworkPkg/HttpDxe/HttpProto.h b/NetworkPkg/HttpDxe/HttpProto.h
index ca4b7b6..c37b80c 100644
--- a/NetworkPkg/HttpDxe/HttpProto.h
+++ b/NetworkPkg/HttpDxe/HttpProto.h
@@ -51,6 +51,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define HTTP_KEEP_ALIVE_TIME 7200
 #define HTTP_KEEP_ALIVE_INTERVAL 30
 
+#define HTTP_URL_BUFFER_LEN  4096
+
 typedef struct _HTTP_SERVICE {
   UINT32Signature;
   EFI_SERVICE_BINDING_PROTOCOL  ServiceBinding;
@@ -120,6 +122,8 @@ typedef struct _HTTP_PROTOCOL {
 
   NET_MAP   TxTokens;
   NET_MAP   RxTokens;
+
+  CHAR8 *Url;
 } HTTP_PROTOCOL;
 
 typedef struct {
-- 
2.5.0.windows.1

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

[edk2] [Patch 1/4] NetworkPkg: Enlarge receive block size of HTTP boot driver.

[Fu Siyuan]

HTTP boot driver uses block size of 1024 when receiving HTTP message body,
but typically the MTU of Ethernet is 1500 bytes so it makes 1 TCP segment data
split into 2 Http.Response call. This patch enlarges the block size to avoid
this issue.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpBootDxe/HttpBootClient.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.h 
b/NetworkPkg/HttpBootDxe/HttpBootClient.h
index 2dfafab..06b9109 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootClient.h
+++ b/NetworkPkg/HttpBootDxe/HttpBootClient.h
@@ -16,7 +16,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define __EFI_HTTP_BOOT_HTTP_H__
 
 #define HTTP_BOOT_REQUEST_TIMEOUT5000  // 5 seconds in uints 
of millisecond.
-#define HTTP_BOOT_BLOCK_SIZE 1024
+#define HTTP_BOOT_BLOCK_SIZE 1500
 
 #define HTTP_FIELD_NAME_USER_AGENT   "User-Agent"
 #define HTTP_FIELD_NAME_HOST "Host"
-- 
2.5.0.windows.1

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

[edk2] [Patch 3/4] NetworkPkg: Update Http driver to use DPC mechanism.

[Fu Siyuan]

This patch updates the HttpDxe driver to use the DPC mechanism to avoid long
time delay when single event.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpDxe/HttpDriver.h |  2 +-
 NetworkPkg/HttpDxe/HttpDxe.inf  |  1 +
 NetworkPkg/HttpDxe/HttpImpl.c   |  9 ++-
 NetworkPkg/HttpDxe/HttpProto.c  | 55 +++--
 4 files changed, 57 insertions(+), 10 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpDriver.h b/NetworkPkg/HttpDxe/HttpDriver.h
index d95b05b..eea8d51 100644
--- a/NetworkPkg/HttpDxe/HttpDriver.h
+++ b/NetworkPkg/HttpDxe/HttpDriver.h
@@ -28,7 +28,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 //
 // UEFI Driver Model Protocols
diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf b/NetworkPkg/HttpDxe/HttpDxe.inf
index e811700..0d3bd00 100644
--- a/NetworkPkg/HttpDxe/HttpDxe.inf
+++ b/NetworkPkg/HttpDxe/HttpDxe.inf
@@ -48,6 +48,7 @@
   DebugLib
   NetLib
   HttpLib
+  DpcLib
 
 [Protocols]
   gEfiHttpServiceBindingProtocolGuid   ## BY_START
diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index dc06b98..c176a65 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -498,6 +498,8 @@ EfiHttpRequest (
 goto Error5;
   }
 
+  DispatchDpc ();
+
   return EFI_SUCCESS;
 
 Error5:
@@ -1329,6 +1331,7 @@ EfiHttpPoll (
   )
 {
   HTTP_PROTOCOL *HttpInstance;
+  EFI_STATUSStatus;
 
   if (This == NULL) {
 return EFI_INVALID_PARAMETER;
@@ -1345,5 +1348,9 @@ EfiHttpPoll (
 return EFI_NOT_STARTED;
   }
 
-  return HttpInstance->Tcp4->Poll (HttpInstance->Tcp4);
+  Status = HttpInstance->Tcp4->Poll (HttpInstance->Tcp4);
+
+  DispatchDpc ();
+
+  return Status;
 }
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c
index e8ce987..06a41b7 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -38,20 +38,18 @@ HttpCommonNotify (
 /**
   The notify function associated with TxToken for Tcp4->Transmit().
 
-  @param[in]  Event   The event signaled.
   @param[in]  Context The context.
 
 **/
 VOID
 EFIAPI
-HttpTcpTransmitNotify (
-  IN EFI_EVENT  Event,
+HttpTcpTransmitNotifyDpc (
   IN VOID   *Context
   )
 {
   HTTP_TOKEN_WRAP  *Wrap;
 
-  if ((Event == NULL) || (Context == NULL)) {
+  if (Context == NULL) {
 return ;
   }
 
@@ -80,16 +78,35 @@ HttpTcpTransmitNotify (
 }
 
 /**
+  Request HttpTcpTransmitNotifyDpc as a DPC at TPL_CALLBACK.
+
+  @param  Event The receive event delivered to TCP for 
transmit.
+  @param  Context   Context for the callback.
+
+**/
+VOID
+EFIAPI
+HttpTcpTransmitNotify (
+  IN EFI_EVENTEvent,
+  IN VOID *Context
+  )
+{
+  //
+  // Request HttpTcpTransmitNotifyDpc as a DPC at TPL_CALLBACK
+  //
+  QueueDpc (TPL_CALLBACK, HttpTcpTransmitNotifyDpc, Context);
+}
+
+
+/**
   The notify function associated with RxToken for Tcp4->Receive ().
 
-  @param[in]  Event   The event signaled.
   @param[in]  Context The context.
 
 **/
 VOID
 EFIAPI
-HttpTcpReceiveNotify (
-  IN EFI_EVENT  Event,
+HttpTcpReceiveNotifyDpc (
   IN VOID   *Context
   )
 {
@@ -99,11 +116,12 @@ HttpTcpReceiveNotify (
   EFI_STATUS   Status;
   HTTP_PROTOCOL*HttpInstance;
 
-  if ((Event == NULL) || (Context == NULL)) {
+  if (Context == NULL) {
 return ;
   }
 
   Wrap = (HTTP_TOKEN_WRAP *) Context;
+  gBS->CloseEvent (Wrap->TcpWrap.RxToken.CompletionToken.Event);
   if (EFI_ERROR (Wrap->TcpWrap.RxToken.CompletionToken.Status)) {
 return ;
   }
@@ -173,6 +191,27 @@ HttpTcpReceiveNotify (
 }
 
 /**
+  Request HttpTcpReceiveNotifyDpc as a DPC at TPL_CALLBACK.
+
+  @param  Event The receive event delivered to TCP for receive.
+  @param  Context   Context for the callback.
+
+**/
+VOID
+EFIAPI
+HttpTcpReceiveNotify (
+  IN EFI_EVENTEvent,
+  IN VOID *Context
+  )
+{
+  //
+  // Request HttpTcpTransmitNotifyDpc as a DPC at TPL_CALLBACK
+  //
+  QueueDpc (TPL_CALLBACK, HttpTcpReceiveNotifyDpc, Context);
+}
+
+
+/**
   Create events for the TCP4 connection token and TCP4 close token.
 
   @param[in]  HttpInstance   Pointer to HTTP_PROTOCOL structure.
-- 
2.5.0.windows.1

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

Re: [edk2] [PATCH] ShellPkg: Update the help information for 'setvar' command to follow Shell behavior.

[Qiu, Shumin]

Since Shell will remove the quotes in parameters, setvar cannot receive the 
quotes from ="ascii" or =L"unicode".  User should add ^ to escape quotes in 
setvar data.
Attach changed files.

-Shumin
-Original Message-
From: Qiu, Shumin 
Sent: Monday, September 14, 2015 3:59 PM
To: edk2-devel@lists.01.org
Cc: Qiu, Shumin; Carsey, Jaben; Ni, Ruiyu
Subject: [PATCH] ShellPkg: Update the help information for 'setvar' command to 
follow Shell behavior.

Cc: Jaben Carsey 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 
---
 .../UefiShellDebug1CommandsLib.uni | Bin 140668 -> 140676 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni
index 
167cacc70dc5fe582a8c3b4d47ed042f7994879c..e16175a6174fbd08275d14d88eaa385e42ae4781
 100644 GIT binary patch delta 40 
tcmex!ilgN;N5d9IpSg^2)4k_1N&~6Xxs2UF>it|sNyfPC?DH5)+W|?A4;BCb

delta 51
zcmZoU&GF|HN5d9IpSjch<}yl6&zj5FC9cE}%HYfp%wWWz%TUZv!cfGJ$&km8zMX#_
HV`)18$NLY3

--
1.9.5.msysgit.1

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

Re: [edk2] [Patch 3/4] NetworkPkg: Update Http driver to use DPC mechanism.

[Fu, Siyuan]

This patch also contains a bug fix in HTTP driver that the RxToken is not 
closed, this is one of the main reasons which lower the download speed.

   Wrap = (HTTP_TOKEN_WRAP *) Context;
+  gBS->CloseEvent (Wrap->TcpWrap.RxToken.CompletionToken.Event);
   if (EFI_ERROR (Wrap->TcpWrap.RxToken.CompletionToken.Status)) {
 return ;
   }

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu Siyuan
Sent: Monday, September 14, 2015 4:24 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Wu, Jiaxin 
Subject: [edk2] [Patch 3/4] NetworkPkg: Update Http driver to use DPC mechanism.

This patch updates the HttpDxe driver to use the DPC mechanism to avoid long 
time delay when single event.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpDxe/HttpDriver.h |  2 +-  NetworkPkg/HttpDxe/HttpDxe.inf  |  1 +
 NetworkPkg/HttpDxe/HttpImpl.c   |  9 ++-
 NetworkPkg/HttpDxe/HttpProto.c  | 55 +++--
 4 files changed, 57 insertions(+), 10 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpDriver.h b/NetworkPkg/HttpDxe/HttpDriver.h 
index d95b05b..eea8d51 100644
--- a/NetworkPkg/HttpDxe/HttpDriver.h
+++ b/NetworkPkg/HttpDxe/HttpDriver.h
@@ -28,7 +28,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 //
 // UEFI Driver Model Protocols
diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf b/NetworkPkg/HttpDxe/HttpDxe.inf 
index e811700..0d3bd00 100644
--- a/NetworkPkg/HttpDxe/HttpDxe.inf
+++ b/NetworkPkg/HttpDxe/HttpDxe.inf
@@ -48,6 +48,7 @@
   DebugLib
   NetLib
   HttpLib
+  DpcLib
 
 [Protocols]
   gEfiHttpServiceBindingProtocolGuid   ## BY_START
diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c 
index dc06b98..c176a65 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -498,6 +498,8 @@ EfiHttpRequest (
 goto Error5;
   }
 
+  DispatchDpc ();
+
   return EFI_SUCCESS;
 
 Error5:
@@ -1329,6 +1331,7 @@ EfiHttpPoll (
   )
 {
   HTTP_PROTOCOL *HttpInstance;
+  EFI_STATUSStatus;
 
   if (This == NULL) {
 return EFI_INVALID_PARAMETER;
@@ -1345,5 +1348,9 @@ EfiHttpPoll (
 return EFI_NOT_STARTED;
   }
 
-  return HttpInstance->Tcp4->Poll (HttpInstance->Tcp4);
+  Status = HttpInstance->Tcp4->Poll (HttpInstance->Tcp4);
+
+  DispatchDpc ();
+
+  return Status;
 }
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c 
index e8ce987..06a41b7 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -38,20 +38,18 @@ HttpCommonNotify (
 /**
   The notify function associated with TxToken for Tcp4->Transmit().
 
-  @param[in]  Event   The event signaled.
   @param[in]  Context The context.
 
 **/
 VOID
 EFIAPI
-HttpTcpTransmitNotify (
-  IN EFI_EVENT  Event,
+HttpTcpTransmitNotifyDpc (
   IN VOID   *Context
   )
 {
   HTTP_TOKEN_WRAP  *Wrap;
 
-  if ((Event == NULL) || (Context == NULL)) {
+  if (Context == NULL) {
 return ;
   }
 
@@ -80,16 +78,35 @@ HttpTcpTransmitNotify (  }
 
 /**
+  Request HttpTcpTransmitNotifyDpc as a DPC at TPL_CALLBACK.
+
+  @param  Event The receive event delivered to TCP for 
transmit.
+  @param  Context   Context for the callback.
+
+**/
+VOID
+EFIAPI
+HttpTcpTransmitNotify (
+  IN EFI_EVENTEvent,
+  IN VOID *Context
+  )
+{
+  //
+  // Request HttpTcpTransmitNotifyDpc as a DPC at TPL_CALLBACK
+  //
+  QueueDpc (TPL_CALLBACK, HttpTcpTransmitNotifyDpc, Context); }
+
+
+/**
   The notify function associated with RxToken for Tcp4->Receive ().
 
-  @param[in]  Event   The event signaled.
   @param[in]  Context The context.
 
 **/
 VOID
 EFIAPI
-HttpTcpReceiveNotify (
-  IN EFI_EVENT  Event,
+HttpTcpReceiveNotifyDpc (
   IN VOID   *Context
   )
 {
@@ -99,11 +116,12 @@ HttpTcpReceiveNotify (
   EFI_STATUS   Status;
   HTTP_PROTOCOL*HttpInstance;
 
-  if ((Event == NULL) || (Context == NULL)) {
+  if (Context == NULL) {
 return ;
   }
 
   Wrap = (HTTP_TOKEN_WRAP *) Context;
+  gBS->CloseEvent (Wrap->TcpWrap.RxToken.CompletionToken.Event);
   if (EFI_ERROR (Wrap->TcpWrap.RxToken.CompletionToken.Status)) {
 return ;
   }
@@ -173,6 +191,27 @@ HttpTcpReceiveNotify (  }
 
 /**
+  Request HttpTcpReceiveNotifyDpc as a DPC at TPL_CALLBACK.
+
+  @param  Event The receive event delivered to TCP for receive.
+  @param  Context   Context for the callback.
+
+**/
+VOID
+EFIAPI
+HttpTcpReceiveNotify (
+  IN EFI_EVENTEvent,
+  IN VOID *Context
+  )
+{
+  //
+  // Request HttpTcpTransmitNotifyDpc as a DPC at TPL_CALLBACK
+  //
+  QueueDpc (TPL_CALLBACK, HttpTcpReceiveNotifyDpc, Context); }
+
+
+/**
   Create events for the TCP4 connection token and TCP4 close token.
 
   @param[in]  HttpInstance   Pointer to HTTP_PROTOCOL structure.
--
2.5.0.windows.1

__

Re: [edk2] [Patch 2/4] NetworkPkg: Update cache management in HTTP boot driver.

[Ye, Ting]

Reviewed-by: Ye Ting  

-Original Message-
From: Fu, Siyuan 
Sent: Monday, September 14, 2015 4:24 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Wu, Jiaxin
Subject: [Patch 2/4] NetworkPkg: Update cache management in HTTP boot driver.

The original HTTP boot driver always save the received message body in its 
cache, it bring a large of memory allocation during HTTP download. This patch 
updates the HTTP boot driver to only cache data when caller doesn't provide a 
buffer for download (which is usually used when caller want to get the required 
buffer size).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpBootDxe/HttpBootClient.c | 63 ++---
 1 file changed, 35 insertions(+), 28 deletions(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.c 
b/NetworkPkg/HttpBootDxe/HttpBootClient.c
index 3b4afc3..5669c5f 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootClient.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootClient.c
@@ -458,22 +458,6 @@ HttpBootGetBootFileCallback (
   }
 
   CallbackData = (HTTP_BOOT_CALLBACK_DATA *) Context;
-
-  //
-  // Save the data into cache list.
-  //
-  NewEntityData = AllocatePool (sizeof (HTTP_BOOT_ENTITY_DATA));
-  if (NewEntityData == NULL) {
-return EFI_OUT_OF_RESOURCES;
-  }
-  if (CallbackData->NewBlock) {
-NewEntityData->Block = CallbackData->Block;
-CallbackData->Block = NULL;
-  }
-  NewEntityData->DataLength = Length;
-  NewEntityData->DataStart  = (UINT8*) Data;
-  InsertTailList (&CallbackData->Cache->EntityDataList, &NewEntityData->Link);
-
   //
   // Copy data if caller has provided a buffer.
   //
@@ -486,6 +470,22 @@ HttpBootGetBootFileCallback (
 CallbackData->CopyedSize += MIN (Length, CallbackData->BufferSize - 
CallbackData->CopyedSize);
   }
 
+  //
+  // The caller doesn't provide a buffer, save the block into cache list.
+  //
+  if (CallbackData->Cache != NULL) {
+NewEntityData = AllocatePool (sizeof (HTTP_BOOT_ENTITY_DATA));
+if (NewEntityData == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
+if (CallbackData->NewBlock) {
+  NewEntityData->Block = CallbackData->Block;
+  CallbackData->Block = NULL;
+}
+NewEntityData->DataLength = Length;
+NewEntityData->DataStart  = (UINT8*) Data;
+InsertTailList (&CallbackData->Cache->EntityDataList, 
+ &NewEntityData->Link);  }
   return EFI_SUCCESS;
 }
 
@@ -566,10 +566,10 @@ HttpBootGetBootFile (
   //
 
   //
-  // 1. Create a temp cache item for the requested URI.
+  // 1. Create a temp cache item for the requested URI if caller doesn't 
provide buffer.
   //
   Cache = NULL;
-  if (!HeaderOnly) {
+  if ((!HeaderOnly) && (*BufferSize == 0)) {
 Cache = AllocateZeroPool (sizeof (HTTP_BOOT_CACHE_CONTENT));
 if (Cache == NULL) {
   Status = EFI_OUT_OF_RESOURCES;
@@ -659,7 +659,7 @@ HttpBootGetBootFile (
   //
   // 2.3 Record the request info in a temp cache item.
   //
-  if (!HeaderOnly) {
+  if (Cache != NULL) {
 Cache->RequestData = RequestData;
   }
 
@@ -703,7 +703,7 @@ HttpBootGetBootFile (
   //
   // 3.2 Cache the response header.
   //
-  if (!HeaderOnly) {
+  if (Cache != NULL) {
 Cache->ResponseData = ResponseData;
   }
   
@@ -733,17 +733,26 @@ HttpBootGetBootFile (
   //
   // 3.4 Continue to receive and parse message-body if needed.
   //
+  Block = NULL;
   if (!HeaderOnly) {
 ZeroMem (&ResponseBody, sizeof (HTTP_IO_RESOPNSE_DATA));
 while (!HttpIsMessageComplete (Parser)) {
   //
-  // Allocate a new block to hold the message-body.
+  // Allocate a block to hold the message-body, if caller doesn't provide
+  // a buffer, the block will be cached and we will allocate a new one 
here.
   //
-  Block = AllocatePool (HTTP_BOOT_BLOCK_SIZE);
-  if (Block == NULL) {
-Status = EFI_OUT_OF_RESOURCES;
-goto ERROR_6;
+  if (Block == NULL || Context.BufferSize == 0) {
+Block = AllocatePool (HTTP_BOOT_BLOCK_SIZE);
+if (Block == NULL) {
+  Status = EFI_OUT_OF_RESOURCES;
+  goto ERROR_6;
+}
+Context.NewBlock = TRUE;
+Context.Block = Block;
+  } else {
+Context.NewBlock = FALSE;
   }
+
   ResponseBody.Body   = (CHAR8*) Block;
   ResponseBody.BodyLength = HTTP_BOOT_BLOCK_SIZE;
   Status = HttpIoRecvResponse (
@@ -758,8 +767,6 @@ HttpBootGetBootFile (
   //
   // Parse the new received block of the message-body, the block will be 
saved in cache.
   //
-  Context.NewBlock = TRUE;
-  Context.Block= Block;
   Status = HttpParseMessageBody (
  Parser,
  ResponseBody.BodyLength, @@ -787,7 +794,7 @@ 
HttpBootGetBootFile (
   //
   // 4. Save the cache item to driver's cache list and return.
   //
-  if (!HeaderOnly) {
+  if (Cache != NULL) {
 Cache->EntityLength = ContentLength;
 InsertTailList (&Private->CacheList, &Cache->Link);
   }
--
2.5.0.windows.1

_

Re: [edk2] [Patch 3/4] NetworkPkg: Update Http driver to use DPC mechanism.

[Ye, Ting]

Reviewed-by: Ye Ting  

-Original Message-
From: Fu, Siyuan 
Sent: Monday, September 14, 2015 4:24 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Wu, Jiaxin
Subject: [Patch 3/4] NetworkPkg: Update Http driver to use DPC mechanism.

This patch updates the HttpDxe driver to use the DPC mechanism to avoid long 
time delay when single event.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpDxe/HttpDriver.h |  2 +-  NetworkPkg/HttpDxe/HttpDxe.inf  |  1 +
 NetworkPkg/HttpDxe/HttpImpl.c   |  9 ++-
 NetworkPkg/HttpDxe/HttpProto.c  | 55 +++--
 4 files changed, 57 insertions(+), 10 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpDriver.h b/NetworkPkg/HttpDxe/HttpDriver.h 
index d95b05b..eea8d51 100644
--- a/NetworkPkg/HttpDxe/HttpDriver.h
+++ b/NetworkPkg/HttpDxe/HttpDriver.h
@@ -28,7 +28,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 //
 // UEFI Driver Model Protocols
diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf b/NetworkPkg/HttpDxe/HttpDxe.inf 
index e811700..0d3bd00 100644
--- a/NetworkPkg/HttpDxe/HttpDxe.inf
+++ b/NetworkPkg/HttpDxe/HttpDxe.inf
@@ -48,6 +48,7 @@
   DebugLib
   NetLib
   HttpLib
+  DpcLib
 
 [Protocols]
   gEfiHttpServiceBindingProtocolGuid   ## BY_START
diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c 
index dc06b98..c176a65 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -498,6 +498,8 @@ EfiHttpRequest (
 goto Error5;
   }
 
+  DispatchDpc ();
+
   return EFI_SUCCESS;
 
 Error5:
@@ -1329,6 +1331,7 @@ EfiHttpPoll (
   )
 {
   HTTP_PROTOCOL *HttpInstance;
+  EFI_STATUSStatus;
 
   if (This == NULL) {
 return EFI_INVALID_PARAMETER;
@@ -1345,5 +1348,9 @@ EfiHttpPoll (
 return EFI_NOT_STARTED;
   }
 
-  return HttpInstance->Tcp4->Poll (HttpInstance->Tcp4);
+  Status = HttpInstance->Tcp4->Poll (HttpInstance->Tcp4);
+
+  DispatchDpc ();
+
+  return Status;
 }
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c 
index e8ce987..06a41b7 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -38,20 +38,18 @@ HttpCommonNotify (
 /**
   The notify function associated with TxToken for Tcp4->Transmit().
 
-  @param[in]  Event   The event signaled.
   @param[in]  Context The context.
 
 **/
 VOID
 EFIAPI
-HttpTcpTransmitNotify (
-  IN EFI_EVENT  Event,
+HttpTcpTransmitNotifyDpc (
   IN VOID   *Context
   )
 {
   HTTP_TOKEN_WRAP  *Wrap;
 
-  if ((Event == NULL) || (Context == NULL)) {
+  if (Context == NULL) {
 return ;
   }
 
@@ -80,16 +78,35 @@ HttpTcpTransmitNotify (  }
 
 /**
+  Request HttpTcpTransmitNotifyDpc as a DPC at TPL_CALLBACK.
+
+  @param  Event The receive event delivered to TCP for 
transmit.
+  @param  Context   Context for the callback.
+
+**/
+VOID
+EFIAPI
+HttpTcpTransmitNotify (
+  IN EFI_EVENTEvent,
+  IN VOID *Context
+  )
+{
+  //
+  // Request HttpTcpTransmitNotifyDpc as a DPC at TPL_CALLBACK
+  //
+  QueueDpc (TPL_CALLBACK, HttpTcpTransmitNotifyDpc, Context); }
+
+
+/**
   The notify function associated with RxToken for Tcp4->Receive ().
 
-  @param[in]  Event   The event signaled.
   @param[in]  Context The context.
 
 **/
 VOID
 EFIAPI
-HttpTcpReceiveNotify (
-  IN EFI_EVENT  Event,
+HttpTcpReceiveNotifyDpc (
   IN VOID   *Context
   )
 {
@@ -99,11 +116,12 @@ HttpTcpReceiveNotify (
   EFI_STATUS   Status;
   HTTP_PROTOCOL*HttpInstance;
 
-  if ((Event == NULL) || (Context == NULL)) {
+  if (Context == NULL) {
 return ;
   }
 
   Wrap = (HTTP_TOKEN_WRAP *) Context;
+  gBS->CloseEvent (Wrap->TcpWrap.RxToken.CompletionToken.Event);
   if (EFI_ERROR (Wrap->TcpWrap.RxToken.CompletionToken.Status)) {
 return ;
   }
@@ -173,6 +191,27 @@ HttpTcpReceiveNotify (  }
 
 /**
+  Request HttpTcpReceiveNotifyDpc as a DPC at TPL_CALLBACK.
+
+  @param  Event The receive event delivered to TCP for receive.
+  @param  Context   Context for the callback.
+
+**/
+VOID
+EFIAPI
+HttpTcpReceiveNotify (
+  IN EFI_EVENTEvent,
+  IN VOID *Context
+  )
+{
+  //
+  // Request HttpTcpTransmitNotifyDpc as a DPC at TPL_CALLBACK
+  //
+  QueueDpc (TPL_CALLBACK, HttpTcpReceiveNotifyDpc, Context); }
+
+
+/**
   Create events for the TCP4 connection token and TCP4 close token.
 
   @param[in]  HttpInstance   Pointer to HTTP_PROTOCOL structure.
--
2.5.0.windows.1

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

Re: [edk2] [Patch 1/4] NetworkPkg: Enlarge receive block size of HTTP boot driver.

[Ye, Ting]

Reviewed-by: Ye Ting  

-Original Message-
From: Fu, Siyuan 
Sent: Monday, September 14, 2015 4:24 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Wu, Jiaxin
Subject: [Patch 1/4] NetworkPkg: Enlarge receive block size of HTTP boot driver.

HTTP boot driver uses block size of 1024 when receiving HTTP message body, but 
typically the MTU of Ethernet is 1500 bytes so it makes 1 TCP segment data 
split into 2 Http.Response call. This patch enlarges the block size to avoid 
this issue.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpBootDxe/HttpBootClient.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.h 
b/NetworkPkg/HttpBootDxe/HttpBootClient.h
index 2dfafab..06b9109 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootClient.h
+++ b/NetworkPkg/HttpBootDxe/HttpBootClient.h
@@ -16,7 +16,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define __EFI_HTTP_BOOT_HTTP_H__
 
 #define HTTP_BOOT_REQUEST_TIMEOUT5000  // 5 seconds in uints 
of millisecond.
-#define HTTP_BOOT_BLOCK_SIZE 1024
+#define HTTP_BOOT_BLOCK_SIZE 1500
 
 #define HTTP_FIELD_NAME_USER_AGENT   "User-Agent"
 #define HTTP_FIELD_NAME_HOST "Host"
--
2.5.0.windows.1

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

Re: [edk2] [Patch 4/4] NetworkPkg: Avoid memory allocation for each HTTP message exchange.

[Ye, Ting]

Reviewed-by: Ye Ting  

-Original Message-
From: Fu, Siyuan 
Sent: Monday, September 14, 2015 4:24 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Wu, Jiaxin
Subject: [Patch 4/4] NetworkPkg: Avoid memory allocation for each HTTP message 
exchange.

This patch updates the HTTP driver to use a shared buffer for URL parsing to 
avoid memory allocation for each HTTP request.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpDxe/HttpImpl.c  | 19 ++-  
NetworkPkg/HttpDxe/HttpProto.c | 11 +++  NetworkPkg/HttpDxe/HttpProto.h 
|  4 
 3 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c 
index c176a65..2b62dc5 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -224,6 +224,7 @@ EfiHttpRequest (
   BOOLEAN   ReConfigure;
   CHAR8 *RequestStr;
   CHAR8 *Url;
+  UINTN UrlLen;
   CHAR16*HostNameStr;
   HTTP_TOKEN_WRAP   *Wrap;
   HTTP_TCP_TOKEN_WRAP   *TcpWrap;
@@ -283,10 +284,15 @@ EfiHttpRequest (
   //
   // Parse the URI of the remote host.
   //
-  Url = AllocatePool (StrLen (Request->Url) + 1);
-  if (Url == NULL) {
-return EFI_OUT_OF_RESOURCES;
-  }
+  UrlLen = StrLen (Request->Url) + 1;
+  if (UrlLen > HTTP_URL_BUFFER_LEN) {
+Url = AllocateZeroPool (UrlLen);
+if (Url == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
+FreePool (HttpInstance->Url);
+HttpInstance->Url = Url;
+  }
 
   UnicodeStrToAsciiStr (Request->Url, Url);
   UrlParser = NULL;
@@ -347,7 +353,6 @@ EfiHttpRequest (
 
 Wrap->TcpWrap.Method = Request->Method;
 
-FreePool (Url);
 FreePool (HostName);
 
 //
@@ -480,7 +485,6 @@ EfiHttpRequest (
 goto Error4;
   }
 
-  FreePool (Url);
   if (HostName != NULL) {
 FreePool (HostName);
   }
@@ -522,9 +526,6 @@ Error2:
   }
 
 Error1:
-  if (Url != NULL) {
-FreePool (Url);
-  }
   if (HostName != NULL) {
 FreePool (HostName);
   }
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c 
index 06a41b7..8fbd454 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -470,6 +470,12 @@ HttpInitProtocol (
 goto ON_ERROR;
   }
 
+  HttpInstance->Url = AllocateZeroPool (HTTP_URL_BUFFER_LEN);  if 
+ (HttpInstance->Url == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+goto ON_ERROR;
+  }
+
   NetMapInit (&HttpInstance->TxTokens);
   NetMapInit (&HttpInstance->RxTokens);
 
@@ -535,6 +541,11 @@ HttpCleanProtocol (
 HttpInstance->MsgParser = NULL;
   }
 
+  if (HttpInstance->Url != NULL) {
+FreePool (HttpInstance->Url);
+HttpInstance->Url = NULL;
+  }
+
   NetMapClean (&HttpInstance->TxTokens);
   NetMapClean (&HttpInstance->RxTokens);
 
diff --git a/NetworkPkg/HttpDxe/HttpProto.h b/NetworkPkg/HttpDxe/HttpProto.h 
index ca4b7b6..c37b80c 100644
--- a/NetworkPkg/HttpDxe/HttpProto.h
+++ b/NetworkPkg/HttpDxe/HttpProto.h
@@ -51,6 +51,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define HTTP_KEEP_ALIVE_TIME 7200
 #define HTTP_KEEP_ALIVE_INTERVAL 30
 
+#define HTTP_URL_BUFFER_LEN  4096
+
 typedef struct _HTTP_SERVICE {
   UINT32Signature;
   EFI_SERVICE_BINDING_PROTOCOL  ServiceBinding; @@ -120,6 +122,8 @@ typedef 
struct _HTTP_PROTOCOL {
 
   NET_MAP   TxTokens;
   NET_MAP   RxTokens;
+
+  CHAR8 *Url;
 } HTTP_PROTOCOL;
 
 typedef struct {
--
2.5.0.windows.1

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

Re: [edk2] [Qemu-devel] Windows does not support DataTableRegion at all [was: docs: describe QEMU's VMGenID design]

[Laszlo Ersek]

On 09/14/15 10:24, Igor Mammedov wrote:
> On Sun, 13 Sep 2015 15:34:51 +0300
> "Michael S. Tsirkin"  wrote:
> 
>> On Sun, Sep 13, 2015 at 01:56:44PM +0200, Laszlo Ersek wrote:
>>> As the subject suggests, I have terrible news.
>>>
>>> I'll preserve the full context here, so that it's easy to scroll back to
>>> the ASL for reference.
>>>
>>> I'm also CC'ing edk2-devel, because a number of BIOS developers should
>>> be congregating there.
>>
>> Wow, bravo! It does look like we need to go back to
>> the drawing board.
> I suggest we go back to the last Gal's series
> which is though not universal but a simple and
> straightforward solution.
> That series with comments addressed probably
> is what we need in the end.

I agree (I commented the same on the RHBZ too). The only one requirement
we might not satisfy with that is that the page containing the
generation ID must always be mapped as cacheable. In practice it doesn't
seem to cause issues.

We tried to play nice, but given that (a) the vmgenid doc doesn't
mention a real requirement about the _CRS -- ie. no IO descriptors are
allowed to be in it --, (b) Windows doesn't support DataTableRegion(), I
doubt we could cover our bases 100% anyway. There can be any number of
further hidden requirements, and hidden gaps in ACPI support too, so
it's just business as usual with Windows: whatever works, works, don't
ask why.

Just my opinion of course.

Laszlo

>> The only crazy thing you didn't try is to use
>> an XSDT instead of the DSDT.
>> I find it unlikely that this will help ...
>>
> 

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

Re: [edk2] [PATCH 4/4] ArmVirtPkg/ArmVirtQemu: enable non-exec DXE stack for AARCH64

[Laszlo Ersek]

On 09/14/15 08:37, Ard Biesheuvel wrote:
> Enable the non-exec DXE stack feature when building for AARCH64.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirtQemu.dsc | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index f1af96827fde..d382f82fb0df 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -162,6 +162,9 @@ [PcdsFixedAtBuild.common]
>#
>gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16
>  
> +[PcdsFixedAtBuild.AARCH64]
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
> +
>  [PcdsDynamicDefault.common]
>## If TRUE, OvmfPkg/AcpiPlatformDxe will not wait for PCI
>#  enumeration to complete before installing ACPI tables.
> 

I can "review" this patch, but I'll take a pass on the first three... :)

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

[edk2] ShellPkg: Build errors with ARM64-GCC

[Sharma Bhupesh]

Hi Experts,

I am trying to build the latest ShellPkg using the edk2/master, but keep 
getting the following relocation related errors:

Build Environment Details:
--

Build environment: Linux-3.8.0-29-generic-i686-with-Ubuntu-12.04-precise
Architecture(s)  = AARCH64
Build target = DEBUG
Toolchain= GCC48

Toolchain used:
---
gcc-linaro-aarch64-linux-gnu-4.8-2014.04_linux

Error Logs:
---

  WriteRelocations64(): 
/../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll 
unsupported ELF EM_AARCH64 relocation R_AARCH64_ADD_ABS_LO12_NC.
GenFw: ERROR 3000: Invalid
  WriteRelocations64(): 
/../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll 
unsupported ELF EM_AARCH64 relocation R_AARCH64_ADR_PREL_PG_HI21.
GenFw: ERROR 3000: Invalid

build.py...
 : error 7000: Failed to execute command
make tbuild [/../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell]


build.py...
 : error F002: Failed to build module
/../ShellPkg/Application/Shell/Shell.inf [AARCH64, GCC48, DEBUG]

Shell.inf invocation in .dsc file:
--

ShellPkg/Application/Shell/Shell.inf {

  
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
  
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
  
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
  
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
  
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
  
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
  
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
  
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
  
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf

  } 

Any other platform (like OVMF) hitting the same issue?

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

Re: [edk2] [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/12/15 01:06, Josh Triplett wrote:
> On Fri, Sep 11, 2015 at 11:27:32PM +0200, Laszlo Ersek wrote:
>> On 09/11/15 21:30, Josh Triplett wrote:
>>> On Fri, Sep 11, 2015 at 05:28:06PM +0200, Laszlo Ersek wrote:
 Breaking Debian Wheezy's and BITS's GRUB is also bad, but the former is
 very old (and has a clear upgrade path), while the latter is mainly used
 by developers (who can learn about the -fw_cfg switch by googling or
 asking on the least without huge trouble). In this case I'm leaning
 towards OVMF being "bleeding edge" by default. But, I could be convinced
 otherwise.
>>>
>>> I certainly think it makes sense for OVMF to adopt the feature sooner
>>> than normal, and I agree that OVMF serves as a test case.  But going
>>> directly from "not possible to turn on" to "turned on by default",
>>> without any period of "off by default but possible to turn on", seems a
>>> bit unfortunate.
>>>
>>> That said, we could certainly fix BITS to use newer GRUB2, and use
>>> (and document) -fw_cfg in the meantime.  So I won't push *too* hard for
>>> changing the default, just mildly.
>>
>> Okay. If I'll need to send a v2 for any reason, I'll incorporate this.
>> If not, then I can post a followup patch later (stating that it's due to
>> community feedback).
> 
> Thanks!
> 
>>> On a vaguely related note, what's the canonical place to report bugs in
>>> OVMF?
>>
>> (Bugs? What bugs? :))
>>
>> It's this list, .
> 
> There isn't a tracker of some kind?  That's unfortunate.

I won't disagree with you, but I'll note three things:

(1) There isn't much use to a bug tracker if there aren't enough human
resources to actually monitor that tracker, and work hard on the bugs. I
can offer to monitor this list and work on bugs reported here the best I
can. Bug fixing is hard and taxing; for *official* long-term bug
tracking, some form of legal relationship is usually necessary. I do
take my RHBZs very seriously.

(2) OvmfPkg is one platform in edk2. I don't think OVMF / OvmfPkg should
have its own separate tracker. And regarding a tracker for the entirety
of edk2, there used to be one (still on sf.net), and nobody (no
contributor or maintainer) cared. Goto (1).

(3) I've seen first hand how Fedora bug tracker entries, Debian bug
tracker entries, and upstream QEMU bug tracker entries are handled. Goto
(1). As I said, I try to do my best with bugs reported on the list, both
in tracking them and in fixing them, as my load allows.

> But thanks; I'll send mail to the list when we discover an issue while
> experimenting with BITS.

Yes, please do that. And thank you. In my experience, other package
maintainers (not just us in OvmfPkg) are pretty responsive if you report
bugs for their packages on the list, especially if you can narrow it
down (bisection, good reproducer etc).

> 
> (Also, if you don't intend to use github's issue tracker, you might want
> to turn it off so people don't file things there and expect a response.)

That's a very good point. Jordan, can you please disable the issue
tracker on github?

Thanks
Laszlo

> 
> - Josh Triplett
> 

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

Re: [edk2] [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/14/15 11:22, Ian Campbell wrote:
> On Fri, 2015-09-11 at 17:28 +0200, Laszlo Ersek wrote:
>>
> [...]
>> For me that's not so clear-cut. OVMF is frequently used as a UEFI
>> development environment (it's better to brick a virtual machine than
>> your physical dev platform...)
> 
> One flip side to this is that people often virtualize in order to continue
> running their older platforms and applications, because upgrading them
> would be difficult for whatever reason.
> 
> There's an obvious tension between that and the desire to use OVMF as a
> development platform, but it seems to me that the developers are the ones
> who can more readily be expected to mess with the defaults.

Good points!

>> , so upstream should embrace new UEFI
>> features reasonably early, unless there are *grave* regressions.
>>
>> One example I named was the properties table feature (new in UEFI-2.5).
>> It would break Windows 7. Given the large number of users running
>> Windows 7 on OVMF (mainly for GPU passthrough), such a regression would
>> be serious.
>>
>> Breaking Debian Wheezy's and BITS's GRUB is also bad, but the former is
>> very old (and has a clear upgrade path)
> 
> Debian Wheezy is not very old, it's only a year older than RHEL7 (May 2013
> vs June 2014) and only a bit older than two years in absolute terms. It is
> also the subject of an LTS effort, which extends its lifetime to 2018.

(*)

> For comparison Windows 7 (which you argue regressing would be serious) was
> released in 2009 and there have been two major Windows releases since then.

(**)

> Given that and with consideration between the desire to run older platforms
> vs. a development environment it seems to me that Debian Wheezy has not yet
> reached the threshold for being ignored or for saying to users "you must
> now upgrade".

I believe I could argue against both (*) and (**), but it would not be
productive. :)

Instead, what matters is the (now) clear, significant user demand for
turning off PcdSetNxForStack by default. I'll send a followup patch for
my series to that end.

And, sorry about the inconvenience the regression may have caused, of
course ;)

Thanks!
Laszlo

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

[edk2] [PATCH 5/4] OvmfPkg: disable no-exec DXE stack by default

[Laszlo Ersek]

(PcdSetNxForStack == TRUE) breaks a number of GRUB versions that, it turns
out, are still widely in use. Disable PcdSetNxForStack by default for now.
QEMU users can enable it dynamically using the micro-feature added in the
previous patch.

Reported-by: Anthony Perard 
Cc: Jan Beulich 
Cc: Ian Campbell 
Cc: Jordan Justen 
Cc: Josh Triplett 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc | 2 +-
 OvmfPkg/OvmfPkgX64.dsc | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index eb6851c..ca74b56 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -396,7 +396,7 @@ [PcdsDynamicDefault]
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuSmbiosValidated|FALSE
 
   # Noexec settings for DXE.
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
 
 

diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index ae42d0d..d6f5d3f 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -402,7 +402,7 @@ [PcdsDynamicDefault]
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuSmbiosValidated|FALSE
 
   # Noexec settings for DXE.
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
 
 

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 8f364a4..7d87904 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -401,7 +401,7 @@ [PcdsDynamicDefault]
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuSmbiosValidated|FALSE
 
   # Noexec settings for DXE.
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
 
 

-- 
1.8.3.1

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

[edk2] Internal 'tftp' command in ShellPkg

[Mang Chia Ho]

Dear Sirs,

By testing the internal command 'tftp' from lastest source on svn server.
But i encounter some error when executing this command for downloading
files from a tftp server.

I use PXE boot to enter a shell environment. And set its ip address with
dhcp protocol.
When i start download the file with a callback function of
EFI_MTFTP4_CHECK_PACKET which defined in tftp command.
But the EFI_MTFTP4_PACKET opcode is alway EFI_MTFTP4_OPCODE_OACK.
So i just can get the file information, but can't start to download file.

And i also monitor my tftp server by wireshark, i found the server send
OACK command continuously
but client didn't response the ACK command. And that why continue the
download flow.

Does this code miss EFI_MTFTP4_OPCODE_ACK packet to inform server for
sending data?
Or the mtftp protocol not work normally in my shell enviroment?

(By the way, my tftp server is based on windows, and it success to download
files from a windows based tftp client.
And use the same code from svn server, but just fix some initialization
warning.)

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

Re: [edk2] ShellPkg: Build errors with ARM64-GCC

[Ard Biesheuvel]

On 14 September 2015 at 12:52, Sharma Bhupesh
 wrote:
> Hi Experts,
>
> I am trying to build the latest ShellPkg using the edk2/master, but keep 
> getting the following relocation related errors:
>

Are you using the latest BaseTools?

> Build Environment Details:
> --
>
> Build environment: Linux-3.8.0-29-generic-i686-with-Ubuntu-12.04-precise
> Architecture(s)  = AARCH64
> Build target = DEBUG
> Toolchain= GCC48
>
> Toolchain used:
> ---
> gcc-linaro-aarch64-linux-gnu-4.8-2014.04_linux
>
> Error Logs:
> ---
>
>   WriteRelocations64(): 
> /../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll 
> unsupported ELF EM_AARCH64 relocation R_AARCH64_ADD_ABS_LO12_NC.
> GenFw: ERROR 3000: Invalid
>   WriteRelocations64(): 
> /../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll 
> unsupported ELF EM_AARCH64 relocation R_AARCH64_ADR_PREL_PG_HI21.
> GenFw: ERROR 3000: Invalid
>
> build.py...
>  : error 7000: Failed to execute command
> make tbuild [/../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell]
>
>
> build.py...
>  : error F002: Failed to build module
> /../ShellPkg/Application/Shell/Shell.inf [AARCH64, GCC48, DEBUG]
>
> Shell.inf invocation in .dsc file:
> --
>
> ShellPkg/Application/Shell/Shell.inf {
> 
>   
> ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
>   
> NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
>   
> NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
>   
> NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
>   
> NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
>   
> NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
>   
> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
>   
> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
>   
> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
>   FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>   ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>   SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>
>   }
>
> Any other platform (like OVMF) hitting the same issue?
>
> Regards,
> Bhupesh
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg PiDxeS3BootScriptLib: Remove a hidden assumption.

[Star Zeng]

What to do:
1. Remove a hidden assumption "No SMM driver writes BootScript between
SmmReadyToLock and S3SleepEntryCallback".
 1.1. Use SmmExitBootServices and SmmLegacyBoot notification to record
  AtRuntime flag.
 1.2. Use mBootScriptDataBootTimeGuid LockBox to save boot time boot
  script data to handle potential INSERT boot script at runtime in SMM.
2. Do not depend on OS to help restore ACPINvs data and use
EfiReservedMemoryType instead of EfiACPIMemoryNVS.
 2.1. Use mBootScriptSmmPrivateDataGuid LockBox to save boot script
  SMM private data with BackFromS3 = TRUE at runtime. S3 resume
  will help restore it to tell the Library the system is back
  from S3.

Why to do:
1. The hidden assumption "No SMM driver writes BootScript between
SmmReadyToLock and S3SleepEntryCallback" will cause confusion to
the library's consumer and block the usage of "SMM driver writes
BootScript after SmmReadyToLock". So Remove the assumption.
2. In original code, there might be a corner case that malicious
code patch ACPINvs boot TableLength field same as SMM boot script.
So that it can skip the table restore. The impact is that BootScript
in SMM may be overridden by malicious code.

CopyMem ((VOID*)&TableHeader, (VOID*)mS3BootScriptTablePtr->TableBase, 
sizeof(EFI_BOOT_SCRIPT_TABLE_HEADER));
if (mS3BootScriptTablePtr->TableLength + sizeof(EFI_BOOT_SCRIPT_TERMINATE) 
!= TableHeader.TableLength) { // TableLength is in NVS
  ..
  //
  // NOTE: We should NOT use TableHeader.TableLength, because it is already 
updated to be whole length.
  //
  mS3BootScriptTablePtr->TableLength = (UINT32)(mLockBoxLength - 
sizeof(EFI_BOOT_SCRIPT_TERMINATE)); ? This line can be skipped.

So use EfiReservedMemoryType instead of EfiACPIMemoryNVS as the code
has been updated to not depend on OS to help restore ACPINvs data.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
---
 .../Library/PiDxeS3BootScriptLib/BootScriptSave.c  | 477 ++---
 .../PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf|   4 +-
 .../PiDxeS3BootScriptLib/InternalBootScriptLib.h   |  17 +-
 MdeModulePkg/MdeModulePkg.dec  |   8 +-
 MdeModulePkg/MdeModulePkg.uni  | Bin 183916 -> 184014 bytes
 5 files changed, 345 insertions(+), 161 deletions(-)

diff --git a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c 
b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
index 586a205..24c6798 100644
--- a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
+++ b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
@@ -19,45 +19,111 @@
 
   Data structure usage:
 
-  +--+<-- PcdS3BootScriptTablePrivateDataPtr
+  +--+<--- PcdS3BootScriptTablePrivateDataPtr
+  | SCRIPT_TABLE_PRIVATE_DATA|  (mS3BootScriptTablePtr, Before 
SmmReadyToLock)
+  |TableBase |---  
PcdS3BootScriptTablePrivateSmmDataPtr
+  |TableLength   |--|-- (mS3BootScriptTablePtr = 
mS3BootScriptTableSmmPtr, After SmmReadyToLock InSmm)
+  |TableMemoryPageNumber |--|-|
+  |AtRuntime |  | |   |
+  |InSmm |  | |   |
+  |BootTimeScriptLength  |--|-|---|---
+  |SmmLocked |  | |   |  |
+  |BackFromS3|  | |   |  |
+  +--+  | |   |  |
+| |   |  |
+  +--+<-- |   |  |
+  | EFI_BOOT_SCRIPT_TABLE_HEADER ||   |  |
+  |TableLength   ||-- |  |
+  +--+| | |  |
+  | ..   || | |  |
+  +--+< | |  |
+  | EFI_BOOT_SCRIPT_TERMINATE|  | |  |
+  +--+<-- |  |
+  |  |
+  |  |
+  mBootScriptDataBootTimeGuid LockBox:|  |
+   Used to restore data after back from S3|  |
+   to handle potential INSERT boot script |  |
+   at runtime.|  |
+  +--+|  |
+  | Boot Time Boot Script||  |
+  | Before SmmReadyToLock||  |
+  |  ||  |
+  |  ||  |
+  +--+|  |
+  | Boot Time Boot Script||  |
+  | After SmmReadyToLock InSmm   ||  |
+  |  ||  |
+  +--+<---|--|
+  |  |
+  |  |
+  mBootScriptDataGuid LockBox: (IN_PLACE) |  |
+   Used to restore data at S3 resume. |  |
+  +--+|  |
+  | Boot Time Bo

Re: [edk2] [PATCH 1/4] MdeModulePkg: PcdSetNxForStack: enable dynamism

[Zeng, Star]

On 2015/9/11 23:15, Laszlo Ersek wrote:

Allow platforms to instantiate this PCD as PcdsDynamic and PcdsDynamicEx
too, not just PcdsFixedAtBuild and PcdsPatchableInModule.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
  MdeModulePkg/MdeModulePkg.dec | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)


Reviewed-by: Star Zeng 

Thanks for the effort.
Star


diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 5c1d29a..42980a5 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -969,15 +969,6 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
# @Prompt Serial Port Register Stride in Bytes
gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|1|UINT32|0x0001006d

-  ## Indicates if to set NX for stack.
-  #  For the DxeIpl and the DxeCore are both X64, set NX for stack feature also 
require PcdDxeIplBuildPageTables be TRUE.
-  #  For the DxeIpl and the DxeCore are both IA32 (PcdDxeIplSwitchToLongMode 
is FALSE), set NX for stack feature also require
-  #  IA32 PAE is supported and Execute Disable Bit is available.
-  #   TRUE  - to set NX for stack.
-  #   FALSE - Not to set NX for stack.
-  # @Prompt Set NX for stack.
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE|BOOLEAN|0x0001006f
-
## This PCD to include the driver guid of VFR drivers for VarCheckHiiBin 
generation.
# Default is gZeroGuid that means no VFR driver will be parsed for VarCheckHiiBin 
generation.
# If it is set to an all FFs GUID, it means all modules in all FVs will be parsed 
for VarCheckHiiBin generation.
@@ -1373,6 +1364,15 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
PcdsDynamicEx]
# @Prompt Default Creator Revision for ACPI table creation.

gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorRevision|0x0113|UINT32|0x30001038

+  ## Indicates if to set NX for stack.
+  #  For the DxeIpl and the DxeCore are both X64, set NX for stack feature also 
require PcdDxeIplBuildPageTables be TRUE.
+  #  For the DxeIpl and the DxeCore are both IA32 (PcdDxeIplSwitchToLongMode 
is FALSE), set NX for stack feature also require
+  #  IA32 PAE is supported and Execute Disable Bit is available.
+  #   TRUE  - to set NX for stack.
+  #   FALSE - Not to set NX for stack.
+  # @Prompt Set NX for stack.
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE|BOOLEAN|0x0001006f
+
  [PcdsPatchableInModule]
## Specify memory size with page number for PEI code when
#  Loading Module at Fixed Address feature is enabled.



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

Re: [edk2] [PATCH] ShellPkg: Update the help information for 'setvar' command to follow Shell behavior.

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Qiu, Shumin
> Sent: Monday, September 14, 2015 1:28 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Ni, Ruiyu 
> Subject: RE: [PATCH] ShellPkg: Update the help information for 'setvar'
> command to follow Shell behavior.
> Importance: High
> 
> Since Shell will remove the quotes in parameters, setvar cannot receive the
> quotes from ="ascii" or =L"unicode".  User should add ^ to escape quotes in
> setvar data.
> Attach changed files.
> 
> -Shumin
> -Original Message-
> From: Qiu, Shumin
> Sent: Monday, September 14, 2015 3:59 PM
> To: edk2-devel@lists.01.org
> Cc: Qiu, Shumin; Carsey, Jaben; Ni, Ruiyu
> Subject: [PATCH] ShellPkg: Update the help information for 'setvar'
> command to follow Shell behavior.
> 
> Cc: Jaben Carsey 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qiu Shumin 
> ---
>  .../UefiShellDebug1CommandsLib.uni | Bin 140668 -> 140676 
> bytes
>  1 file changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> dsLib.uni
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> dsLib.uni
> index
> 167cacc70dc5fe582a8c3b4d47ed042f7994879c..e16175a6174fbd08275d14d88e
> aa385e42ae4781 100644 GIT binary patch delta 40
> tcmex!ilgN;N5d9IpSg^2)4k_1N&~6Xxs2UF>it|sNyfPC?DH5)+W|?A4;BCb
> 
> delta 51
> zcmZoU&GF|HN5d9IpSjch<}yl6&zj5FC9cE}%HYfp%wWWz%TUZv!cfGJ$&km8
> zMX#_
> HV`)18$NLY3
> 
> --
> 1.9.5.msysgit.1

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

Re: [edk2] [PATCH] ShellPkg: Rename some functions in Dp to avoid build errors

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Samer El-Haj-Mahmoud [mailto:samer.el-haj-mahm...@hpe.com]
> Sent: Friday, September 11, 2015 4:53 PM
> To: edk2-devel@lists.01.org
> Cc: Samer El-Haj-Mahmoud ; Carsey,
> Jaben 
> Subject: [PATCH] ShellPkg: Rename some functions in Dp to avoid build
> errors
> Importance: High
> 
> There are other libraries with similarly named functions that could be linked
> with the Shell
> 
> Signed-off-by: Samer El-Haj-Mahmoud 
> Cc: Jaben Carsey 
> ---
>  ShellPkg/Library/UefiDpLib/DpInternal.h  | 5 +++--
>  ShellPkg/Library/UefiDpLib/DpTrace.c | 5 +++--
>  ShellPkg/Library/UefiDpLib/DpUtilities.c | 7 ---
>  3 files changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiDpLib/DpInternal.h
> b/ShellPkg/Library/UefiDpLib/DpInternal.h
> index c7d9a59..22dc4f9 100644
> --- a/ShellPkg/Library/UefiDpLib/DpInternal.h
> +++ b/ShellPkg/Library/UefiDpLib/DpInternal.h
> @@ -7,6 +7,7 @@
>DpUtilities.c, DpTrace.c, and DpProfile.c are included here.
> 
>Copyright (c) 2009 - 2013, Intel Corporation. All rights reserved.
> +  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
>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
> @@ -96,7 +97,7 @@ IsPhase(
> 
>  **/
>  VOID
> -GetShortPdbFileName (
> +DpGetShortPdbFileName (
>IN  CHAR8 *PdbFileName,
>OUT CHAR16*UnicodeBuffer
>);
> @@ -118,7 +119,7 @@ GetShortPdbFileName (
> 
>  **/
>  VOID
> -GetNameFromHandle (
> +DpGetNameFromHandle (
>IN EFI_HANDLE Handle
>);
> 
> diff --git a/ShellPkg/Library/UefiDpLib/DpTrace.c
> b/ShellPkg/Library/UefiDpLib/DpTrace.c
> index de1d45a..542fcc8 100644
> --- a/ShellPkg/Library/UefiDpLib/DpTrace.c
> +++ b/ShellPkg/Library/UefiDpLib/DpTrace.c
> @@ -2,6 +2,7 @@
>Trace reporting for the Dp utility.
> 
>Copyright (c) 2009 - 2013, Intel Corporation. All rights reserved.
> +  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
>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
> @@ -216,7 +217,7 @@ DumpAllTrace(
>  // See if the Handle is in the HandleBuffer
>  for (TIndex = 0; TIndex < (Size / sizeof(HandleBuffer[0])); 
> TIndex++) {
>if (Measurement.Handle == HandleBuffer[TIndex]) {
> -GetNameFromHandle (HandleBuffer[TIndex]);
> +DpGetNameFromHandle (HandleBuffer[TIndex]);
>  break;
>}
>  }
> @@ -582,7 +583,7 @@ ProcessHandles(
>// See if the Handle is in the HandleBuffer
>for (Index = 0; Index < (Size / sizeof(HandleBuffer[0])); Index++) {
>  if (Measurement.Handle == HandleBuffer[Index]) {
> -  GetNameFromHandle (HandleBuffer[Index]); // Name is put into
> mGaugeString
> +  DpGetNameFromHandle (HandleBuffer[Index]); // Name is put into
> mGaugeString
>break;
>  }
>}
> diff --git a/ShellPkg/Library/UefiDpLib/DpUtilities.c
> b/ShellPkg/Library/UefiDpLib/DpUtilities.c
> index 063eb65..c464c2f 100644
> --- a/ShellPkg/Library/UefiDpLib/DpUtilities.c
> +++ b/ShellPkg/Library/UefiDpLib/DpUtilities.c
> @@ -2,6 +2,7 @@
>Utility functions used by the Dp application.
> 
>Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
> +  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
>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
> @@ -131,7 +132,7 @@ IsPhase(
> 
>  **/
>  VOID
> -GetShortPdbFileName (
> +DpGetShortPdbFileName (
>IN  CHAR8 *PdbFileName,
>OUT CHAR16*UnicodeBuffer
>)
> @@ -188,7 +189,7 @@ GetShortPdbFileName (
> 
>  **/
>  VOID
> -GetNameFromHandle (
> +DpGetNameFromHandle (
>IN EFI_HANDLE   Handle
>)
>  {
> @@ -236,7 +237,7 @@ GetNameFromHandle (
>  PdbFileName = PeCoffLoaderGetPdbPointer (Image->ImageBase);
> 
>  if (PdbFileName != NULL) {
> -  GetShortPdbFileName (PdbFileName, mGaugeString);
> +  DpGetShortPdbFileName (PdbFileName, mGaugeString);
>return;
>  }
>}
> --
> 1.9.5.msysgit.1

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

Re: [edk2] ShellPkg: Build errors with ARM64-GCC

[Sharma Bhupesh]

> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, September 14, 2015 7:01 PM
> On 14 September 2015 at 12:52, Sharma Bhupesh
>  wrote:
> > Hi Experts,
> >
> > I am trying to build the latest ShellPkg using the edk2/master, but
> keep getting the following relocation related errors:
> >
> 
> Are you using the latest BaseTools?

Same issue with latest Basetools/master: 
http://sourceforge.net/p/tianocore/edk2-BaseTools/ci/master/tree/

> 
> > Build Environment Details:
> > --
> >
> > Build environment:
> > Linux-3.8.0-29-generic-i686-with-Ubuntu-12.04-precise
> > Architecture(s)  = AARCH64
> > Build target = DEBUG
> > Toolchain= GCC48
> >
> > Toolchain used:
> > ---
> > gcc-linaro-aarch64-linux-gnu-4.8-2014.04_linux
> >
> > Error Logs:
> > ---
> >
> >   WriteRelocations64():
> /../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll
> unsupported ELF EM_AARCH64 relocation R_AARCH64_ADD_ABS_LO12_NC.
> > GenFw: ERROR 3000: Invalid
> >   WriteRelocations64():
> /../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll
> unsupported ELF EM_AARCH64 relocation R_AARCH64_ADR_PREL_PG_HI21.
> > GenFw: ERROR 3000: Invalid
> >
> > build.py...
> >  : error 7000: Failed to execute command
> > make tbuild
> > [/../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell]
> >
> >
> > build.py...
> >  : error F002: Failed to build module
> > /../ShellPkg/Application/Shell/Shell.inf [AARCH64, GCC48,
> > DEBUG]
> >
> > Shell.inf invocation in .dsc file:
> > --
> >
> > ShellPkg/Application/Shell/Shell.inf {
> > 
> >
> ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.
> inf
> >
> NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsL
> ib.inf
> >
> NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsL
> ib.inf
> >
> NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsL
> ib.inf
> >
> NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Command
> sLib.inf
> >
> NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsL
> ib.inf
> >
> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1Comma
> ndsLib.inf
> >
> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Comma
> ndsLib.inf
> >
> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingL
> ib.inf
> >
> FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> >   ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> >   SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
> >   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> >
> >   }
> >
> > Any other platform (like OVMF) hitting the same issue?
> >
> > Regards,
> > Bhupesh
> > ___
> > 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] ShellPkg: Build errors with ARM64-GCC

[Sharma Bhupesh]

The error message changes to:

WriteSections64(): 
/../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll 
AARCH64 small code model requires 4 KB section alignment.
GenFw: ERROR 3000: Invalid

Regards,
Bhupesh


> -Original Message-
> From: Sharma Bhupesh-B45370
> Sent: Monday, September 14, 2015 8:38 PM
> To: 'Ard Biesheuvel'
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] ShellPkg: Build errors with ARM64-GCC
> 
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Monday, September 14, 2015 7:01 PM On 14 September 2015 at
> > 12:52, Sharma Bhupesh  wrote:
> > > Hi Experts,
> > >
> > > I am trying to build the latest ShellPkg using the edk2/master, but
> > keep getting the following relocation related errors:
> > >
> >
> > Are you using the latest BaseTools?
> 
> Same issue with latest Basetools/master:
> http://sourceforge.net/p/tianocore/edk2-BaseTools/ci/master/tree/
> 
> >
> > > Build Environment Details:
> > > --
> > >
> > > Build environment:
> > > Linux-3.8.0-29-generic-i686-with-Ubuntu-12.04-precise
> > > Architecture(s)  = AARCH64
> > > Build target = DEBUG
> > > Toolchain= GCC48
> > >
> > > Toolchain used:
> > > ---
> > > gcc-linaro-aarch64-linux-gnu-4.8-2014.04_linux
> > >
> > > Error Logs:
> > > ---
> > >
> > >   WriteRelocations64():
> > /../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.d
> > ll unsupported ELF EM_AARCH64 relocation R_AARCH64_ADD_ABS_LO12_NC.
> > > GenFw: ERROR 3000: Invalid
> > >   WriteRelocations64():
> > /../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.d
> > ll unsupported ELF EM_AARCH64 relocation R_AARCH64_ADR_PREL_PG_HI21.
> > > GenFw: ERROR 3000: Invalid
> > >
> > > build.py...
> > >  : error 7000: Failed to execute command
> > > make tbuild
> > > [/../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell]
> > >
> > >
> > > build.py...
> > >  : error F002: Failed to build module
> > > /../ShellPkg/Application/Shell/Shell.inf [AARCH64, GCC48,
> > > DEBUG]
> > >
> > > Shell.inf invocation in .dsc file:
> > > --
> > >
> > > ShellPkg/Application/Shell/Shell.inf {
> > > 
> > >
> >
> ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.
> > inf
> > >
> > NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Comman
> > NULL|dsL
> > ib.inf
> > >
> > NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1Comman
> > NULL|dsL
> > ib.inf
> > >
> > NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3Comman
> > NULL|dsL
> > ib.inf
> > >
> > NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Comm
> > NULL|and
> > sLib.inf
> > >
> > NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> > NULL|dsL
> > ib.inf
> > >
> > NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1Co
> > NULL|mma
> > ndsLib.inf
> > >
> > NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Co
> > NULL|mma
> > ndsLib.inf
> > >
> > HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsi
> > HandleParsingLib|ngL
> > ib.inf
> > >
> > FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> > >   ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> > >   SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
> > >   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> > >
> > >   }
> > >
> > > Any other platform (like OVMF) hitting the same issue?
> > >
> > > Regards,
> > > Bhupesh
> > > ___
> > > 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] ShellPkg: Build errors with ARM64-GCC

[Ard Biesheuvel]

On 14 September 2015 at 17:08, Sharma Bhupesh
 wrote:
> The error message changes to:
>
> WriteSections64(): 
> /../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll 
> AARCH64 small code model requires 4 KB section alignment.
> GenFw: ERROR 3000: Invalid
>

OK, so that is /not/ the same issue.
You will also need to make sure that your Conf/tools_def.txt is up to
date. You can regenerate it by removing it and running edksetup.sh
again.

Could you also double check that you have SVN r18241 in your tree?
That changes relies on the use of GccBase.lds in Conf/tools_def.txt,
so please check if that file is referenced anywhere in your
tools_def.txt


>> -Original Message-
>> From: Sharma Bhupesh-B45370
>> Sent: Monday, September 14, 2015 8:38 PM
>> To: 'Ard Biesheuvel'
>> Cc: edk2-devel@lists.01.org
>> Subject: RE: [edk2] ShellPkg: Build errors with ARM64-GCC
>>
>> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> > Sent: Monday, September 14, 2015 7:01 PM On 14 September 2015 at
>> > 12:52, Sharma Bhupesh  wrote:
>> > > Hi Experts,
>> > >
>> > > I am trying to build the latest ShellPkg using the edk2/master, but
>> > keep getting the following relocation related errors:
>> > >
>> >
>> > Are you using the latest BaseTools?
>>
>> Same issue with latest Basetools/master:
>> http://sourceforge.net/p/tianocore/edk2-BaseTools/ci/master/tree/
>>
>> >
>> > > Build Environment Details:
>> > > --
>> > >
>> > > Build environment:
>> > > Linux-3.8.0-29-generic-i686-with-Ubuntu-12.04-precise
>> > > Architecture(s)  = AARCH64
>> > > Build target = DEBUG
>> > > Toolchain= GCC48
>> > >
>> > > Toolchain used:
>> > > ---
>> > > gcc-linaro-aarch64-linux-gnu-4.8-2014.04_linux
>> > >
>> > > Error Logs:
>> > > ---
>> > >
>> > >   WriteRelocations64():
>> > /../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.d
>> > ll unsupported ELF EM_AARCH64 relocation R_AARCH64_ADD_ABS_LO12_NC.
>> > > GenFw: ERROR 3000: Invalid
>> > >   WriteRelocations64():
>> > /../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.d
>> > ll unsupported ELF EM_AARCH64 relocation R_AARCH64_ADR_PREL_PG_HI21.
>> > > GenFw: ERROR 3000: Invalid
>> > >
>> > > build.py...
>> > >  : error 7000: Failed to execute command
>> > > make tbuild
>> > > [/../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell]
>> > >
>> > >
>> > > build.py...
>> > >  : error F002: Failed to build module
>> > > /../ShellPkg/Application/Shell/Shell.inf [AARCH64, GCC48,
>> > > DEBUG]
>> > >
>> > > Shell.inf invocation in .dsc file:
>> > > --
>> > >
>> > > ShellPkg/Application/Shell/Shell.inf {
>> > > 
>> > >
>> >
>> ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.
>> > inf
>> > >
>> > NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Comman
>> > NULL|dsL
>> > ib.inf
>> > >
>> > NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1Comman
>> > NULL|dsL
>> > ib.inf
>> > >
>> > NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3Comman
>> > NULL|dsL
>> > ib.inf
>> > >
>> > NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Comm
>> > NULL|and
>> > sLib.inf
>> > >
>> > NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
>> > NULL|dsL
>> > ib.inf
>> > >
>> > NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1Co
>> > NULL|mma
>> > ndsLib.inf
>> > >
>> > NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Co
>> > NULL|mma
>> > ndsLib.inf
>> > >
>> > HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsi
>> > HandleParsingLib|ngL
>> > ib.inf
>> > >
>> > FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>> > >   ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>> > >   SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>> > >   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>> > >
>> > >   }
>> > >
>> > > Any other platform (like OVMF) hitting the same issue?
>> > >
>> > > Regards,
>> > > Bhupesh
>> > > ___
>> > > 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] [Qemu-devel] Windows does not support DataTableRegion at all [was: docs: describe QEMU's VMGenID design]

[Bill Paul]

Of all the gin joints in all the towns in all the world, Laszlo Ersek had to 
walk into mine at 03:24:42 on Monday 14 September 2015 and say:

> On 09/14/15 10:24, Igor Mammedov wrote:
> > On Sun, 13 Sep 2015 15:34:51 +0300
> > 
> > "Michael S. Tsirkin"  wrote:
> >> On Sun, Sep 13, 2015 at 01:56:44PM +0200, Laszlo Ersek wrote:
> >>> As the subject suggests, I have terrible news.
> >>> 
> >>> I'll preserve the full context here, so that it's easy to scroll back
> >>> to the ASL for reference.
> >>> 
> >>> I'm also CC'ing edk2-devel, because a number of BIOS developers should
> >>> be congregating there.
> >> 
> >> Wow, bravo! It does look like we need to go back to
> >> the drawing board.

I read your original post on this with great interest, and I applaud your 
determination in tracking this down. Nice job. Sadly, it seems you too have 
fallen victim to the "If It Works With Windows, It Must Be Ok" syndrome.

Now, I realize that as far as this particular situation is concerned, even if 
Microsoft decided to add support for DataTableRegion() tomorrow, it wouldn't 
really help because there are too many different versions of Windows in the 
field and there's no way to retroactively patch them all. (Gee, that sounds 
familiar...)

Nevertheless, am I correct in saying that this is in fact a bug in Microsoft's 
ACPI implementation (both in their ASL compiler and in the AML parser)? Unless 
DataTableRegion() is specified to be optional in some way (I don't know if it 
is or not, but I doubt it), this sounds like an clear cut case of non-
compliance with the ACPI spec. And if that's true, isn't there any way to get 
Microsoft to fix it?

-Bill

> > I suggest we go back to the last Gal's series
> > which is though not universal but a simple and
> > straightforward solution.
> > That series with comments addressed probably
> > is what we need in the end.
> 
> I agree (I commented the same on the RHBZ too). The only one requirement
> we might not satisfy with that is that the page containing the
> generation ID must always be mapped as cacheable. In practice it doesn't
> seem to cause issues.
> 
> We tried to play nice, but given that (a) the vmgenid doc doesn't
> mention a real requirement about the _CRS -- ie. no IO descriptors are
> allowed to be in it --, (b) Windows doesn't support DataTableRegion(), I
> doubt we could cover our bases 100% anyway. There can be any number of
> further hidden requirements, and hidden gaps in ACPI support too, so
> it's just business as usual with Windows: whatever works, works, don't
> ask why.
> 
> Just my opinion of course.
> 
> Laszlo
> 
> >> The only crazy thing you didn't try is to use
> >> an XSDT instead of the DSDT.
> >> I find it unlikely that this will help ...
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

-- 
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Qemu-devel] Windows does not support DataTableRegion at all [was: docs: describe QEMU's VMGenID design]

[Laszlo Ersek]

On 09/14/15 18:53, Bill Paul wrote:
> Of all the gin joints in all the towns in all the world, Laszlo Ersek had to 
> walk into mine at 03:24:42 on Monday 14 September 2015 and say:
> 
>> On 09/14/15 10:24, Igor Mammedov wrote:
>>> On Sun, 13 Sep 2015 15:34:51 +0300
>>>
>>> "Michael S. Tsirkin"  wrote:
 On Sun, Sep 13, 2015 at 01:56:44PM +0200, Laszlo Ersek wrote:
> As the subject suggests, I have terrible news.
>
> I'll preserve the full context here, so that it's easy to scroll back
> to the ASL for reference.
>
> I'm also CC'ing edk2-devel, because a number of BIOS developers should
> be congregating there.

 Wow, bravo! It does look like we need to go back to
 the drawing board.
> 
> I read your original post on this with great interest, and I applaud your 
> determination in tracking this down. Nice job.

Thank you!

> Sadly, it seems you too have 
> fallen victim to the "If It Works With Windows, It Must Be Ok" syndrome.

Well, I'd put it like this: we've fallen victim to a publicly
undocumented feature gap / divergence from the ACPI spec in Windows'
ACPI.SYS.

> Now, I realize that as far as this particular situation is concerned, even if 
> Microsoft decided to add support for DataTableRegion() tomorrow, it wouldn't 
> really help because there are too many different versions of Windows in the 
> field and there's no way to retroactively patch them all. (Gee, that sounds 
> familiar...)

Correct.

> Nevertheless, am I correct in saying that this is in fact a bug in 
> Microsoft's 
> ACPI implementation (both in their ASL compiler and in the AML parser)?

Absolutely. You are absolutely right.

We implemented the VMGENID spec with some undeniable creativity, but it
broke down because the AML interpreter in Windows does not support an
ACPI 2.0 feature.

(That interpreter is supposed to be ACPI 4.0 compliant, minimally; at
least if we can judge it after the "matching" AML.exe's stated
compatibility level, which is ACPI 4.0 in the standalone download, and
5.0 if you get it as part of the WDK.)

> Unless 
> DataTableRegion() is specified to be optional in some way (I don't know if it 
> is or not, but I doubt it),

It's not, to the best of my knowledge.

> this sounds like an clear cut case of non-
> compliance with the ACPI spec.

Yes, it's precisely that.

> And if that's true, isn't there any way to get 
> Microsoft to fix it?

I don't know. Is there?

Microsoft continue to release updates (KB*) for Windows 7, Windows 8,
Windows 10, and I think rolling a fix out for those would cover our
needs quite okay.

But:
- This would force QEMU/KVM host users to upgrade their Windows guest.
  Maybe not such a big hurdle, but I reckon Windows sysadmins are
  really conservative about installing updates. Perhaps we could solve
  this issue but documentation.

- More importantly, how do I even *report* this bug? How do I convince
  Microsoft to implement a whole missing feature in their ACPI compiler
  and interpreter? Can I demonstrate business justification?

  I'm doubtful especially because DataTableRegion's usefulness is quite
  apparent to the ACPI developer in search for parametrization options.
  DataTableRegion was published as part of ACPI 2.0, on July 27, 2000
  (more than fifteen years ago). I simply cannot imagine that in all
  that time *no* physical platform's firmware developer tried to use
  DataTableRegion.

  Therefore I can't help but assume that some big BIOS developer
  company has already reported this to Microsoft, and the feature
  request has been rejected. So what chance would I have?

Thanks
Laszlo

> 
> -Bill
> 
>>> I suggest we go back to the last Gal's series
>>> which is though not universal but a simple and
>>> straightforward solution.
>>> That series with comments addressed probably
>>> is what we need in the end.
>>
>> I agree (I commented the same on the RHBZ too). The only one requirement
>> we might not satisfy with that is that the page containing the
>> generation ID must always be mapped as cacheable. In practice it doesn't
>> seem to cause issues.
>>
>> We tried to play nice, but given that (a) the vmgenid doc doesn't
>> mention a real requirement about the _CRS -- ie. no IO descriptors are
>> allowed to be in it --, (b) Windows doesn't support DataTableRegion(), I
>> doubt we could cover our bases 100% anyway. There can be any number of
>> further hidden requirements, and hidden gaps in ACPI support too, so
>> it's just business as usual with Windows: whatever works, works, don't
>> ask why.
>>
>> Just my opinion of course.
>>
>> Laszlo
>>
 The only crazy thing you didn't try is to use
 an XSDT instead of the DSDT.
 I find it unlikely that this will help ...
>>
>> ___
>> 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
ht

Re: [edk2] [Qemu-devel] Windows does not support DataTableRegion at all [was: docs: describe QEMU's VMGenID design]

[Laszlo Ersek]

On 09/14/15 19:23, Walz, Michael C wrote:
> Who are the Microsoft representatives in the ASWG? Shouldn't this 
> conversation be happening with them?

Red Hat is represented in the ASWG, as far as I know, so if you guys
think this is appropriate to bring up there (ie. a specific product's
compliance), I can try talking to my peers. :)

Thanks
Laszlo

> 
> -Original Message-
> From: Moore, Robert 
> Sent: September 14, 2015 10:14
> To: Bill Paul; edk2-de...@ml01.01.org
> Cc: Laszlo Ersek; Igor Mammedov; Michael S. Tsirkin; Josh Triplett; Gal 
> Hammer; edk2-devel-01; qemu-de...@nongnu.org; Paolo Bonzini; Gough, Robert; 
> Walz, Michael C
> Subject: RE: [edk2] [Qemu-devel] Windows does not support DataTableRegion at 
> all [was: docs: describe QEMU's VMGenID design]
> 
> The Windows ACPI implementation doesn't even fully support ACPI 2.0 AFAIK, 
> let alone other new things.
> 
> Rob Gough or Michael may know better than I do.
> 
> 
>> -Original Message-
>> From: Bill Paul [mailto:wp...@windriver.com]
>> Sent: Monday, September 14, 2015 9:53 AM
>> To: edk2-de...@ml01.01.org
>> Cc: Laszlo Ersek; Igor Mammedov; Michael S. Tsirkin; Josh Triplett; 
>> Gal Hammer; edk2-devel-01; Moore, Robert; qemu-de...@nongnu.org; Paolo 
>> Bonzini
>> Subject: Re: [edk2] [Qemu-devel] Windows does not support 
>> DataTableRegion at all [was: docs: describe QEMU's VMGenID design]
>>
>> Of all the gin joints in all the towns in all the world, Laszlo Ersek 
>> had to walk into mine at 03:24:42 on Monday 14 September 2015 and say:
>>
>>> On 09/14/15 10:24, Igor Mammedov wrote:
 On Sun, 13 Sep 2015 15:34:51 +0300

 "Michael S. Tsirkin"  wrote:
> On Sun, Sep 13, 2015 at 01:56:44PM +0200, Laszlo Ersek wrote:
>> As the subject suggests, I have terrible news.
>>
>> I'll preserve the full context here, so that it's easy to scroll 
>> back to the ASL for reference.
>>
>> I'm also CC'ing edk2-devel, because a number of BIOS developers 
>> should be congregating there.
>
> Wow, bravo! It does look like we need to go back to the drawing 
> board.
>>
>> I read your original post on this with great interest, and I applaud 
>> your determination in tracking this down. Nice job. Sadly, it seems 
>> you too have fallen victim to the "If It Works With Windows, It Must Be Ok"
>> syndrome.
>>
>> Now, I realize that as far as this particular situation is concerned, 
>> even if Microsoft decided to add support for DataTableRegion() 
>> tomorrow, it wouldn't really help because there are too many different 
>> versions of Windows in the field and there's no way to retroactively patch 
>> them all.
>> (Gee, that sounds
>> familiar...)
>>
>> Nevertheless, am I correct in saying that this is in fact a bug in 
>> Microsoft's ACPI implementation (both in their ASL compiler and in the 
>> AML parser)? Unless
>> DataTableRegion() is specified to be optional in some way (I don't 
>> know if it is or not, but I doubt it), this sounds like an clear cut 
>> case of non- compliance with the ACPI spec. And if that's true, isn't 
>> there any way to get Microsoft to fix it?
>>
>> -Bill
>>
 I suggest we go back to the last Gal's series which is though not 
 universal but a simple and straightforward solution.
 That series with comments addressed probably is what we need in 
 the end.
>>>
>>> I agree (I commented the same on the RHBZ too). The only one 
>>> requirement we might not satisfy with that is that the page 
>>> containing the generation ID must always be mapped as cacheable. In 
>>> practice it doesn't seem to cause issues.
>>>
>>> We tried to play nice, but given that (a) the vmgenid doc doesn't 
>>> mention a real requirement about the _CRS -- ie. no IO descriptors 
>>> are allowed to be in it --, (b) Windows doesn't support 
>>> DataTableRegion(), I doubt we could cover our bases 100% anyway. 
>>> There can be any number of further hidden requirements, and hidden 
>>> gaps in ACPI support too, so it's just business as usual with 
>>> Windows: whatever works, works, don't ask why.
>>>
>>> Just my opinion of course.
>>>
>>> Laszlo
>>>
> The only crazy thing you didn't try is to use an XSDT instead of 
> the DSDT.
> I find it unlikely that this will help ...
>>>
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>
>> --
>> ==
>> 
>> ===
>> -Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
>>  wp...@windriver.com | Master of Unix-Fu - Wind River 
>> Systems 
>> ==
>> 
>> ===
>>"I put a dollar in a change machine. Nothing changed." - George 
>> Carlin 
>> ==
>> 
>> ===

__

[edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Jordan Justen]

Forwarded message from Laszlo Ersek (2015-09-14 03:57:01):
> On 09/12/15 01:06, Josh Triplett wrote:
> > On Fri, Sep 11, 2015 at 11:27:32PM +0200, Laszlo Ersek wrote:
> >> On 09/11/15 21:30, Josh Triplett wrote:
> >>> On a vaguely related note, what's the canonical place to report bugs in
> >>> OVMF?
> >>
> >> (Bugs? What bugs? :))
> >>
> >> It's this list, .
> > 
> > There isn't a tracker of some kind?  That's unfortunate.
> 
> I won't disagree with you, but I'll note three things:
> 
> (1) There isn't much use to a bug tracker if there aren't enough human
> resources to actually monitor that tracker, and work hard on the bugs. I
> can offer to monitor this list and work on bugs reported here the best I
> can. Bug fixing is hard and taxing; for *official* long-term bug
> tracking, some form of legal relationship is usually necessary. I do
> take my RHBZs very seriously.
> 
> (2) OvmfPkg is one platform in edk2. I don't think OVMF / OvmfPkg should
> have its own separate tracker. And regarding a tracker for the entirety
> of edk2, there used to be one (still on sf.net), and nobody (no

I think the bug tracker on sf got shut down when sf stopped supporting
their 'hosted services'. (Ie, for example, when they shut down the
hosted mediawiki service.)

> contributor or maintainer) cared. Goto (1).
> 
> (3) I've seen first hand how Fedora bug tracker entries, Debian bug
> tracker entries, and upstream QEMU bug tracker entries are handled. Goto
> (1). As I said, I try to do my best with bugs reported on the list, both
> in tracking them and in fixing them, as my load allows.
> 
> > But thanks; I'll send mail to the list when we discover an issue while
> > experimenting with BITS.
> 
> Yes, please do that. And thank you. In my experience, other package
> maintainers (not just us in OvmfPkg) are pretty responsive if you report
> bugs for their packages on the list, especially if you can narrow it
> down (bisection, good reproducer etc).
> 
> > 
> > (Also, if you don't intend to use github's issue tracker, you might want
> > to turn it off so people don't file things there and expect a response.)
> 
> That's a very good point. Jordan, can you please disable the issue
> tracker on github?

Well, there has been discussion on this topic at Intel. It is a
mentioned goal:

http://www.tianocore.org/news/2015/05/01/UnderConst.html

Some want to try to somehow run a bugzilla server. Personally, I think
the path of least resistence is to just use github's issues system. It
seems to go along with moving the source tree to git on github, and I
think their system works reasonably.

I wish github had a better system for exporting the bug data. For
example, the wiki system is a clonable git tree, and it would be great
if the issues system worked the same way.

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

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Bruce Cran]

On 9/14/15 1:19 PM, Jordan Justen wrote:


I think the bug tracker on sf got shut down when sf stopped supporting
their 'hosted services'. (Ie, for example, when they shut down the
hosted mediawiki service.)


It got broken when SF changed their URLs. I asked about it back then but 
nobody seemed to care.



Well, there has been discussion on this topic at Intel. It is a
mentioned goal:

http://www.tianocore.org/news/2015/05/01/UnderConst.html


Then let's do it! I guess there must be internal discussions going on, 
but it's a little frustration to see no update for months at a time.



Some want to try to somehow run a bugzilla server. Personally, I think
the path of least resistence is to just use github's issues system. It
seems to go along with moving the source tree to git on github, and I
think their system works reasonably.


I think I'd prefer a dedicated system, personally. I'm already running 
Phabricator for the EDK2 repository browser at https://edk2.bluestop.org 
and enabling the bug/task tracker Maniphest module 
(http://phacility.com/phabricator/maniphest/) is just a few clicks.

But I'd have to have buy-in from the Intel folks etc. for it to be used.

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

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Laszlo Ersek]

On 09/14/15 21:19, Jordan Justen wrote:
> Forwarded message from Laszlo Ersek (2015-09-14 03:57:01):
>> On 09/12/15 01:06, Josh Triplett wrote:
>>> On Fri, Sep 11, 2015 at 11:27:32PM +0200, Laszlo Ersek wrote:
 On 09/11/15 21:30, Josh Triplett wrote:
> On a vaguely related note, what's the canonical place to report bugs in
> OVMF?

 (Bugs? What bugs? :))

 It's this list, .
>>>
>>> There isn't a tracker of some kind?  That's unfortunate.
>>
>> I won't disagree with you, but I'll note three things:
>>
>> (1) There isn't much use to a bug tracker if there aren't enough human
>> resources to actually monitor that tracker, and work hard on the bugs. I
>> can offer to monitor this list and work on bugs reported here the best I
>> can. Bug fixing is hard and taxing; for *official* long-term bug
>> tracking, some form of legal relationship is usually necessary. I do
>> take my RHBZs very seriously.
>>
>> (2) OvmfPkg is one platform in edk2. I don't think OVMF / OvmfPkg should
>> have its own separate tracker. And regarding a tracker for the entirety
>> of edk2, there used to be one (still on sf.net), and nobody (no
> 
> I think the bug tracker on sf got shut down when sf stopped supporting
> their 'hosted services'. (Ie, for example, when they shut down the
> hosted mediawiki service.)
> 
>> contributor or maintainer) cared. Goto (1).
>>
>> (3) I've seen first hand how Fedora bug tracker entries, Debian bug
>> tracker entries, and upstream QEMU bug tracker entries are handled. Goto
>> (1). As I said, I try to do my best with bugs reported on the list, both
>> in tracking them and in fixing them, as my load allows.
>>
>>> But thanks; I'll send mail to the list when we discover an issue while
>>> experimenting with BITS.
>>
>> Yes, please do that. And thank you. In my experience, other package
>> maintainers (not just us in OvmfPkg) are pretty responsive if you report
>> bugs for their packages on the list, especially if you can narrow it
>> down (bisection, good reproducer etc).
>>
>>>
>>> (Also, if you don't intend to use github's issue tracker, you might want
>>> to turn it off so people don't file things there and expect a response.)
>>
>> That's a very good point. Jordan, can you please disable the issue
>> tracker on github?
> 
> Well, there has been discussion on this topic at Intel. It is a
> mentioned goal:
> 
> http://www.tianocore.org/news/2015/05/01/UnderConst.html
> 
> Some want to try to somehow run a bugzilla server. Personally, I think
> the path of least resistence is to just use github's issues system. It
> seems to go along with moving the source tree to git on github, and I
> think their system works reasonably.

I never used the Issues pages (as anything other than a non-logged in
lurker). But, if it resembles their code view etc pages, I think I'll be
in trouble. Hotkeys in a browser... Brrr. It's just too heavy-weight for
a browser. Bugzilla has worked out for me quite okay; as long as I
remind myself to edit comments longer than five lines in a separate
editor, lest I lose half an hour's worth of writeup when Firefox decides
to crash on me or I fat-finger some link on the page.

> I wish github had a better system for exporting the bug data.

A valid concern.

> For
> example, the wiki system is a clonable git tree, and it would be great
> if the issues system worked the same way.

In any case, can we disable it for now, on
? For one, I don't even get
email when a user makes an entry. Clearly, I don't *wish* to get more
bug email, of course (see my whole tirade above about human resources);
but this way users are left hanging in the wind and they think "these
developers are non-responsive", or worse.

Can it be shut down for now with "please post issues to
"?

... Separate question (because the above makes me recall that edk2-devel
doesn't allow non-subscribers to post); did you get any notifications
about non-subscribers trying to post? I think I can count at least five
people whose emails have directly reached my inbox in the last few days,
but not edk2-devel. (In random order: Josh, Jan, Ian, Michael, Igor.)

If approving such originator addresses one by one is too much work (for
whoever is doing that now), I think I'd be willing to try myself at it.

Thanks
Laszlo

> 
> -Jordan
> 

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

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Bruce Cran]

On 9/14/15 1:39 PM, Laszlo Ersek wrote:


I never used the Issues pages (as anything other than a non-logged in
lurker). But, if it resembles their code view etc pages, I think I'll be
in trouble. Hotkeys in a browser... Brrr. It's just too heavy-weight for
a browser.


I can't say I'm much of a fan of Github's interface, and for us suspect 
the Issues feature would be too simple. I don't see the problem with 
hotkeys in a browser though - surely being able to press '/' to search, 
'esc' to close a dialog or '?' to get help is better than having to move 
the mouse to click buttons?


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

[edk2] [PATCH] MdeModulePkg: PciBusDxe: Properly exit PCI function loops early if the device is not a multifunction device.

[Samer El-Haj-Mahmoud]

From: "Shifflett, Joseph" 

When looping through all PCI functions, code should not look for functions 1-7 
if function 0 is not present or if function 0 indicates the device is not 
multifunction. Prior to this fix, the code would use stale data in a buffer to 
determine if a device is multifunction even if function 0 is not present.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c | 10 --
 .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c   | 38 ++
 MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c| 11 ++-
 3 files changed, 42 insertions(+), 17 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c
index 7329143..e638014 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c
@@ -2,6 +2,7 @@
   PCI eunmeration implementation on entire PCI bus system for PCI Bus module.
 
 Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 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
@@ -382,6 +383,7 @@ PciAssignBusNumber (
   UINT16  Register;
   UINT8   Register8;
   EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciRootBridgeIo;
+  BOOLEAN MultiFunctionDevice;
 
   PciRootBridgeIo = Bridge->PciRootBridgeIo;
 
@@ -394,6 +396,7 @@ PciAssignBusNumber (
   // First check to see whether the parent is ppb
   //
   for (Device = 0; Device <= PCI_MAX_DEVICE; Device++) {
+MultiFunctionDevice = FALSE;
 for (Func = 0; Func <= PCI_MAX_FUNC; Func++) {
 
   //
@@ -406,7 +409,9 @@ PciAssignBusNumber (
 Device,
 Func
 );
-
+  if (Func == 0) {
+MultiFunctionDevice = !EFI_ERROR (Status) && IS_PCI_MULTI_FUNC (&Pci);
+  }
   if (!EFI_ERROR (Status)   &&
   (IS_PCI_BRIDGE (&Pci) || IS_CARDBUS_BRIDGE (&Pci))) {
 
@@ -482,7 +487,8 @@ PciAssignBusNumber (
 
   }
 
-  if (Func == 0 && !IS_PCI_MULTI_FUNC (&Pci)) {
+  if (Func == 0 && !MultiFunctionDevice) {
+
 
 //
 // Skip sub functions, this is not a multi function device
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
index f46025e..7b57374 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
@@ -2,6 +2,7 @@
   PCI emumeration support functions implementation for PCI Bus module.
 
 Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 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
@@ -101,12 +102,13 @@ PciPciDeviceInfoCollector (
   UINT8   SecBus;
   PCI_IO_DEVICE   *PciIoDevice;
   EFI_PCI_IO_PROTOCOL *PciIo;
+  BOOLEAN MultiFunctionDevice;
 
   Status  = EFI_SUCCESS;
   SecBus  = 0;
 
   for (Device = 0; Device <= PCI_MAX_DEVICE; Device++) {
-
+MultiFunctionDevice = FALSE;
 for (Func = 0; Func <= PCI_MAX_FUNC; Func++) {
 
   //
@@ -119,6 +121,9 @@ PciPciDeviceInfoCollector (
  (UINT8) Device,
  (UINT8) Func
  );
+  if (Func == 0) {
+MultiFunctionDevice = !EFI_ERROR (Status) && IS_PCI_MULTI_FUNC (&Pci);
+  }
   if (!EFI_ERROR (Status)) {
 
 //
@@ -169,17 +174,17 @@ PciPciDeviceInfoCollector (
  );
 
 }
-
-if (Func == 0 && !IS_PCI_MULTI_FUNC (&Pci)) {
-
-  //
-  // Skip sub functions, this is not a multi function device
-  //
-  Func = PCI_MAX_FUNC;
-}
   }
+ 
+  if (Func == 0 && !MultiFunctionDevice) {
 
+//
+// Skip sub functions, this is not a multi function device
+//
+Func = PCI_MAX_FUNC;
+  }
 }
+
   }
 
   return EFI_SUCCESS;
@@ -334,9 +339,9 @@ DumpPciBars (
 
 DEBUG ((
   EFI_D_INFO,
-  "   BAR[%d]: Type = %s; Alignment = 0x%lx;\tLength = 0x%lx;\tOffset = 
0x%02x\n",
+  "   BAR[%d]: Type = %s; Alignment = 0x%lx;\tLength = 0x%lx;\tOffset = 
0x%02x;\tValue = 0x%lx\n",
   Index, mBarTypeStr[MIN (PciIoDevice->PciBar[Index].BarType, 
PciBarTypeMaxType)],
-  PciIoDevice->PciBar[Index].Alignment, PciIoDevice->PciBar[Index].Length, 
PciIoDevice->PciBar[Index].Offset
+  PciIoDevice->PciBar[Index].Alignment, PciIoDevice->PciBar[Index].Length, 
PciIoDevice->PciBar[Index].Of

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Laszlo Ersek]

On 09/14/15 21:53, Bruce Cran wrote:
> On 9/14/15 1:39 PM, Laszlo Ersek wrote:
> 
>> I never used the Issues pages (as anything other than a non-logged in
>> lurker). But, if it resembles their code view etc pages, I think I'll be
>> in trouble. Hotkeys in a browser... Brrr. It's just too heavy-weight for
>> a browser.
> 
> I can't say I'm much of a fan of Github's interface, and for us suspect
> the Issues feature would be too simple. I don't see the problem with
> hotkeys in a browser though - surely being able to press '/' to search,
> 'esc' to close a dialog or '?' to get help is better than having to move
> the mouse to click buttons?

Personally, I disagree. I like to use the "Search in Page" browser
function, locate the (*aptly named*) link, hit ESC to exit the search,
then hit Enter to follow the link (or open it in a new windows with
Middle-Click or the key combos that do the same from the local menu).

Websites shouldn't be sold as interactive desktop apps, beacuse they
aren't. All those attempts trying to claim otherwise have without
exception failed for me. For some extreme offenders, I even have
GreaseMonkey scripts that disable this key-grabbing mis-feature.

The "Search in Page" browser function is supposed to work identically on
all websites. Pressing "/" on GitHub (possibly inadvertently) triggers
their own search function, while on another key-grabbing website it
might cause daemons to fly out of one's nose. Stop that madness already.
I know my desktop apps' key combos because there are only a handful of
them, and I use them all day. I don't know every random website's combos
because there are uncountably many of them.

... As I said, personal opinion :)

Thanks
Laszlo

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

[edk2] [PATCH] MdePkg: Http.h - Add HttpMethodMax to EFI_HTTP_METHOD

[Samer El-Haj-Mahmoud]

Add HttpMethodMax enum value to EFI_HTTP_METHOD to make it easier to iterate 
through the HTTP methods using a loop

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 MdePkg/Include/Protocol/Http.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Protocol/Http.h b/MdePkg/Include/Protocol/Http.h
index b1f8c51..c7a89b4 100644
--- a/MdePkg/Include/Protocol/Http.h
+++ b/MdePkg/Include/Protocol/Http.h
@@ -5,6 +5,7 @@
   HTTP Protocol (HTTP)
 
   Copyright (c) 2015, Intel Corporation. All rights reserved.
+  (C) Copyright 2015 Hewlett Packard Enterprise Development LP  
   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
@@ -54,7 +55,8 @@ typedef enum {
   HttpMethodHead,
   HttpMethodPut,
   HttpMethodDelete,
-  HttpMethodTrace
+  HttpMethodTrace,
+  HttpMethodMax
 } EFI_HTTP_METHOD;
 
 ///
-- 
1.9.5.msysgit.1

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

[edk2] [PATCH] NetworkPkg: Fix typos in some EFI_HTTP_STATUS_CODE definitions

[Samer El-Haj-Mahmoud]

Fix spelling typos in EFI_HTTP_STATUS_CODE definitions for error 415 and 501

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 MdePkg/Include/Protocol/Http.h | 4 ++--
 NetworkPkg/HttpDxe/HttpProto.c | 5 +++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Include/Protocol/Http.h b/MdePkg/Include/Protocol/Http.h
index c7a89b4..5588e4c 100644
--- a/MdePkg/Include/Protocol/Http.h
+++ b/MdePkg/Include/Protocol/Http.h
@@ -95,11 +95,11 @@ typedef enum {
   HTTP_STATUS_412_PRECONDITION_FAILED,
   HTTP_STATUS_413_REQUEST_ENTITY_TOO_LARGE,
   HTTP_STATUS_414_REQUEST_URI_TOO_LARGE,
-  HTTP_STATUS_415_UNSUPPORETD_MEDIA_TYPE,
+  HTTP_STATUS_415_UNSUPPORTED_MEDIA_TYPE,
   HTTP_STATUS_416_REQUESTED_RANGE_NOT_SATISFIED,
   HTTP_STATUS_417_EXPECTATION_FAILED,
   HTTP_STATUS_500_INTERNAL_SERVER_ERROR,
-  HTTP_STATUS_501_NOT_IMIPLEMENTED,
+  HTTP_STATUS_501_NOT_IMPLEMENTED,
   HTTP_STATUS_502_BAD_GATEWAY,
   HTTP_STATUS_503_SERVICE_UNAVAILABLE,
   HTTP_STATUS_504_GATEWAY_TIME_OUT,
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c
index e8ce987..eca4a58 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -2,6 +2,7 @@
   Miscellaneous routines for HttpDxe driver.
 
 Copyright (c) 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 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
@@ -843,7 +844,7 @@ HttpMappingToStatusCode (
   case 414:
 return HTTP_STATUS_414_REQUEST_URI_TOO_LARGE;
   case 415:
-return HTTP_STATUS_415_UNSUPPORETD_MEDIA_TYPE;
+return HTTP_STATUS_415_UNSUPPORTED_MEDIA_TYPE;
   case 416:
 return HTTP_STATUS_416_REQUESTED_RANGE_NOT_SATISFIED;
   case 417:
@@ -851,7 +852,7 @@ HttpMappingToStatusCode (
   case 500:
 return HTTP_STATUS_500_INTERNAL_SERVER_ERROR;
   case 501:
-return HTTP_STATUS_501_NOT_IMIPLEMENTED;
+return HTTP_STATUS_501_NOT_IMPLEMENTED;
   case 502:
 return HTTP_STATUS_502_BAD_GATEWAY;
   case 503:
-- 
1.9.5.msysgit.1

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

[edk2] [PATCH] SecurityPkg: Reduce verbosity of TPM DEBUG messages

[Samer El-Haj-Mahmoud]

Some of the TPM/TPM2 DEBUG messages are at EFI_D_INFO level, even though they 
are simply tracing functions that run on every boot even if there is no TPM 
installed. Changed verbosity to EFI_D_VERBOSE.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 .../DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c  |  3 ++-
 SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c  | 13 ++--
 SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c  | 23 +++---
 SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Tis.c| 23 +++---
 4 files changed, 33 insertions(+), 29 deletions(-)

diff --git a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c 
b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
index 26bf6fb..1f2574e 100644
--- a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
+++ b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
@@ -16,6 +16,7 @@
   partition data carefully.
 
 Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 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 
@@ -447,7 +448,7 @@ DxeTpm2MeasureBootHandler (
 // Tcg2 protocol is not installed. So, TPM2 is not present.
 // Don't do any measurement, and directly return EFI_SUCCESS.
 //
-DEBUG ((EFI_D_INFO, "DxeTpm2MeasureBootHandler - Tcg2 - %r\n", Status));
+DEBUG ((EFI_D_VERBOSE, "DxeTpm2MeasureBootHandler - Tcg2 - %r\n", Status));
 return EFI_SUCCESS;
   }
 
diff --git a/SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c 
b/SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c
index 379f2f7..075db4a 100644
--- a/SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c
+++ b/SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c
@@ -2,6 +2,7 @@
   Ihis library uses TPM2 device to calculation hash.
 
 Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved. 
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 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
@@ -242,7 +243,7 @@ HashAndExtend (
   TPM2B_EVENTEventData;
   TPM2B_DIGEST   Result;
 
-  DEBUG((EFI_D_INFO, "\n HashAndExtend Entry \n"));
+  DEBUG((EFI_D_VERBOSE, "\n HashAndExtend Entry \n"));
 
   SequenceHandle = 0x; // Know bad value
 
@@ -262,7 +263,7 @@ HashAndExtend (
   if (EFI_ERROR(Status)) {
 return EFI_DEVICE_ERROR;
   }
-  DEBUG((EFI_D_INFO, "\n Tpm2HashSequenceStart Success \n"));
+  DEBUG((EFI_D_VERBOSE, "\n Tpm2HashSequenceStart Success \n"));
 
   Buffer = (UINT8 *)(UINTN)DataToHash;
   for (HashLen = DataToHashLen; HashLen > sizeof(HashBuffer.buffer); HashLen 
-= sizeof(HashBuffer.buffer)) {
@@ -276,7 +277,7 @@ HashAndExtend (
   return EFI_DEVICE_ERROR;
 }
   }
-  DEBUG((EFI_D_INFO, "\n Tpm2SequenceUpdate Success \n"));
+  DEBUG((EFI_D_VERBOSE, "\n Tpm2SequenceUpdate Success \n"));
 
   HashBuffer.size = (UINT16)HashLen;
   CopyMem(HashBuffer.buffer, Buffer, (UINTN)HashLen);
@@ -294,7 +295,7 @@ HashAndExtend (
 if (EFI_ERROR(Status)) {
   return EFI_DEVICE_ERROR;
 }
-DEBUG((EFI_D_INFO, "\n Tpm2EventSequenceComplete Success \n"));
+DEBUG((EFI_D_VERBOSE, "\n Tpm2EventSequenceComplete Success \n"));
   } else {
 Status = Tpm2SequenceComplete (
SequenceHandle,
@@ -304,7 +305,7 @@ HashAndExtend (
 if (EFI_ERROR(Status)) {
   return EFI_DEVICE_ERROR;
 }
-DEBUG((EFI_D_INFO, "\n Tpm2SequenceComplete Success \n"));
+DEBUG((EFI_D_VERBOSE, "\n Tpm2SequenceComplete Success \n"));
 
 DigestList->count = 1;
 DigestList->digests[0].hashAlg = AlgoId;
@@ -316,7 +317,7 @@ HashAndExtend (
 if (EFI_ERROR(Status)) {
   return EFI_DEVICE_ERROR;
 }
-DEBUG((EFI_D_INFO, "\n Tpm2PcrExtend Success \n"));
+DEBUG((EFI_D_VERBOSE, "\n Tpm2PcrExtend Success \n"));
   }
 
   return EFI_SUCCESS;
diff --git a/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c 
b/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
index 2fb360f..b8d13aa 100644
--- a/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
+++ b/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
@@ -2,6 +2,7 @@
   TIS (TPM Interface Specification) functions used by TPM1.2.
   
 Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 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 
@@ -381,22 +382,22 @@ Tpm12TisTpmCommand (
   DEBUG_CODE (
 UINTN  Debug

Re: [edk2] [Qemu-devel] Windows does not support DataTableRegion at all [was: docs: describe QEMU's VMGenID design]

[Bill Paul]

Of all the gin joints in all the towns in all the world, Laszlo Ersek had to 
walk into mine at 11:20:28 on Monday 14 September 2015 and say:

> On 09/14/15 18:53, Bill Paul wrote:
> > Of all the gin joints in all the towns in all the world, Laszlo Ersek had
> > to
> > 
> > walk into mine at 03:24:42 on Monday 14 September 2015 and say:
> >> On 09/14/15 10:24, Igor Mammedov wrote:
> >>> On Sun, 13 Sep 2015 15:34:51 +0300
> >>> 
> >>> "Michael S. Tsirkin"  wrote:
>  On Sun, Sep 13, 2015 at 01:56:44PM +0200, Laszlo Ersek wrote:
> > As the subject suggests, I have terrible news.
> > 
> > I'll preserve the full context here, so that it's easy to scroll back
> > to the ASL for reference.
> > 
> > I'm also CC'ing edk2-devel, because a number of BIOS developers
> > should be congregating there.
>  
>  Wow, bravo! It does look like we need to go back to
>  the drawing board.
> > 
> > I read your original post on this with great interest, and I applaud your
> > determination in tracking this down. Nice job.
> 
> Thank you!
> 
> > Sadly, it seems you too have
> > fallen victim to the "If It Works With Windows, It Must Be Ok" syndrome.
> 
> Well, I'd put it like this: we've fallen victim to a publicly
> undocumented feature gap / divergence from the ACPI spec in Windows'
> ACPI.SYS.
> 
> > Now, I realize that as far as this particular situation is concerned,
> > even if Microsoft decided to add support for DataTableRegion() tomorrow,
> > it wouldn't really help because there are too many different versions of
> > Windows in the field and there's no way to retroactively patch them all.
> > (Gee, that sounds familiar...)
> 
> Correct.
> 
> > Nevertheless, am I correct in saying that this is in fact a bug in
> > Microsoft's ACPI implementation (both in their ASL compiler and in the
> > AML parser)?
> 
> Absolutely. You are absolutely right.
> 
> We implemented the VMGENID spec with some undeniable creativity, but it
> broke down because the AML interpreter in Windows does not support an
> ACPI 2.0 feature.
> 
> (That interpreter is supposed to be ACPI 4.0 compliant, minimally; at
> least if we can judge it after the "matching" AML.exe's stated
> compatibility level, which is ACPI 4.0 in the standalone download, and
> 5.0 if you get it as part of the WDK.)
> 
> > Unless
> > DataTableRegion() is specified to be optional in some way (I don't know
> > if it is or not, but I doubt it),
> 
> It's not, to the best of my knowledge.
> 
> > this sounds like an clear cut case of non-
> > compliance with the ACPI spec.
> 
> Yes, it's precisely that.
> 
> > And if that's true, isn't there any way to get
> > Microsoft to fix it?
> 
> I don't know. Is there?

You would think that someone at Intel would know someone at Microsoft that 
could put some wheels in motion. (All this technology and still we have 
trouble communicating. :P )
 
> Microsoft continue to release updates (KB*) for Windows 7, Windows 8,
> Windows 10, and I think rolling a fix out for those would cover our
> needs quite okay.
> 
> But:
> - This would force QEMU/KVM host users to upgrade their Windows guest.
>   Maybe not such a big hurdle, but I reckon Windows sysadmins are
>   really conservative about installing updates. Perhaps we could solve
>   this issue but documentation.

I agree with you that it's a hassle, but so is patching any other Windows bug. 
And while this particular use of DataTableRegion() affects VMs, it has bearing 
on bare metal installations too.
 
> - More importantly, how do I even *report* this bug? How do I convince
>   Microsoft to implement a whole missing feature in their ACPI compiler
>   and interpreter? Can I demonstrate business justification?
>
>   I'm doubtful especially because DataTableRegion's usefulness is quite
>   apparent to the ACPI developer in search for parametrization options.
>   DataTableRegion was published as part of ACPI 2.0, on July 27, 2000
>   (more than fifteen years ago). I simply cannot imagine that in all
>   that time *no* physical platform's firmware developer tried to use
>   DataTableRegion.
> 
>   Therefore I can't help but assume that some big BIOS developer
>   company has already reported this to Microsoft, and the feature
>   request has been rejected. So what chance would I have?

I understand what you're saying. But, there has to be some way to deal with 
these sorts of things. If everyone thinks and acts that way, then that's 
effectively letting Microsoft control the ACPI standard by "embracing and 
extending" it. (Or in this case I guess it's embracing and constricting it.)

I think a major part of the problem is that the only standard with which the 
big BIOS developers feel they must comply is the Windows Logo program. The x86 
market is still dominated by Windows users, and getting that Windows badge 
onto the machines is still top priority. If there was a UEFI Forum Logo 
program to which they had to adhere instead, things might be different. But 

[edk2] [PATCH] ShellPkg: Fix a command line unicode string type

[Samer El-Haj-Mahmoud]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 ShellPkg/Library/UefiShellDriver1CommandsLib/Reconnect.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Reconnect.c 
b/ShellPkg/Library/UefiShellDriver1CommandsLib/Reconnect.c
index 092e2c9..d2ae8e8 100644
--- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Reconnect.c
+++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Reconnect.c
@@ -1,8 +1,9 @@
 /** @file
   Main file for Reconnect shell Driver1 function.
 
-  (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
   Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.
+  (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
+  (C) Copyright 2015 Hewlett Packard Enterprise Development LP  
   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
@@ -75,7 +76,7 @@ ShellCommandRunReconnect (
   Status = ShellCommandLineParse (ParamList, &Package, &ProblemParam, TRUE);
   if (EFI_ERROR(Status)) {
 if (Status == EFI_VOLUME_CORRUPTED && ProblemParam != NULL) {
-  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_PROBLEM), 
gShellDriver1HiiHandle, "reconnect", ProblemParam);
+  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_PROBLEM), 
gShellDriver1HiiHandle, L"reconnect", ProblemParam);
   FreePool(ProblemParam);
   ShellStatus = SHELL_INVALID_PARAMETER;
 } else {
-- 
1.9.5.msysgit.1

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

Re: [edk2] [PATCH] ShellPkg: Fix a command line unicode string type

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Samer El-Haj-Mahmoud
> Sent: Monday, September 14, 2015 2:13 PM
> To: edk2-devel@lists.01.org
> Cc: Qiu, Shumin ; Samer El-Haj-Mahmoud
> ; Samer El-Haj-Mahmoud  mahm...@hpe.com>
> Subject: [edk2] [PATCH] ShellPkg: Fix a command line unicode string type
> Importance: High
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Samer El-Haj-Mahmoud 
> ---
>  ShellPkg/Library/UefiShellDriver1CommandsLib/Reconnect.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Reconnect.c
> b/ShellPkg/Library/UefiShellDriver1CommandsLib/Reconnect.c
> index 092e2c9..d2ae8e8 100644
> --- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Reconnect.c
> +++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Reconnect.c
> @@ -1,8 +1,9 @@
>  /** @file
>Main file for Reconnect shell Driver1 function.
> 
> -  (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
>Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.
> +  (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
> +  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
>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
> @@ -75,7 +76,7 @@ ShellCommandRunReconnect (
>Status = ShellCommandLineParse (ParamList, &Package, &ProblemParam,
> TRUE);
>if (EFI_ERROR(Status)) {
>  if (Status == EFI_VOLUME_CORRUPTED && ProblemParam != NULL) {
> -  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_PROBLEM),
> gShellDriver1HiiHandle, "reconnect", ProblemParam);
> +  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_PROBLEM),
> gShellDriver1HiiHandle, L"reconnect", ProblemParam);
>FreePool(ProblemParam);
>ShellStatus = SHELL_INVALID_PARAMETER;
>  } else {
> --
> 1.9.5.msysgit.1
> 
> ___
> 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] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[josh]

On Mon, Sep 14, 2015 at 12:19:53PM -0700, Jordan Justen wrote:
> Forwarded message from Laszlo Ersek (2015-09-14 03:57:01):
> > On 09/12/15 01:06, Josh Triplett wrote:
> > > On Fri, Sep 11, 2015 at 11:27:32PM +0200, Laszlo Ersek wrote:
> > >> On 09/11/15 21:30, Josh Triplett wrote:
> > >>> On a vaguely related note, what's the canonical place to report bugs in
> > >>> OVMF?
> > >>
> > >> (Bugs? What bugs? :))
> > >>
> > >> It's this list, .
> > > 
> > > There isn't a tracker of some kind?  That's unfortunate.
> > 
> > I won't disagree with you, but I'll note three things:
> > 
> > (1) There isn't much use to a bug tracker if there aren't enough human
> > resources to actually monitor that tracker, and work hard on the bugs. I
> > can offer to monitor this list and work on bugs reported here the best I
> > can. Bug fixing is hard and taxing; for *official* long-term bug
> > tracking, some form of legal relationship is usually necessary. I do
> > take my RHBZs very seriously.
> > 
> > (2) OvmfPkg is one platform in edk2. I don't think OVMF / OvmfPkg should
> > have its own separate tracker. And regarding a tracker for the entirety
> > of edk2, there used to be one (still on sf.net), and nobody (no
> 
> I think the bug tracker on sf got shut down when sf stopped supporting
> their 'hosted services'. (Ie, for example, when they shut down the
> hosted mediawiki service.)
> 
> > contributor or maintainer) cared. Goto (1).
> > 
> > (3) I've seen first hand how Fedora bug tracker entries, Debian bug
> > tracker entries, and upstream QEMU bug tracker entries are handled. Goto
> > (1). As I said, I try to do my best with bugs reported on the list, both
> > in tracking them and in fixing them, as my load allows.
> > 
> > > But thanks; I'll send mail to the list when we discover an issue while
> > > experimenting with BITS.
> > 
> > Yes, please do that. And thank you. In my experience, other package
> > maintainers (not just us in OvmfPkg) are pretty responsive if you report
> > bugs for their packages on the list, especially if you can narrow it
> > down (bisection, good reproducer etc).
> > 
> > > 
> > > (Also, if you don't intend to use github's issue tracker, you might want
> > > to turn it off so people don't file things there and expect a response.)
> > 
> > That's a very good point. Jordan, can you please disable the issue
> > tracker on github?
> 
> Well, there has been discussion on this topic at Intel. It is a
> mentioned goal:
> 
> http://www.tianocore.org/news/2015/05/01/UnderConst.html
> 
> Some want to try to somehow run a bugzilla server. Personally, I think
> the path of least resistence is to just use github's issues system. It
> seems to go along with moving the source tree to git on github, and I
> think their system works reasonably.
> 
> I wish github had a better system for exporting the bug data. For
> example, the wiki system is a clonable git tree, and it would be great
> if the issues system worked the same way.

There are a few tools for extracting and continuously archiving the
issue data.  For instance, see https://github.com/joeyh/github-backup .
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Jordan Justen]

On 2015-09-14 12:31:45, Bruce Cran wrote:
> On 9/14/15 1:19 PM, Jordan Justen wrote:
> 
> > I think the bug tracker on sf got shut down when sf stopped supporting
> > their 'hosted services'. (Ie, for example, when they shut down the
> > hosted mediawiki service.)
> 
> It got broken when SF changed their URLs. I asked about it back then but 
> nobody seemed to care.
> 
> > Well, there has been discussion on this topic at Intel. It is a
> > mentioned goal:
> >
> > http://www.tianocore.org/news/2015/05/01/UnderConst.html
> 
> Then let's do it! I guess there must be internal discussions going on, 
> but it's a little frustration to see no update for months at a time.
> 
> > Some want to try to somehow run a bugzilla server. Personally, I think
> > the path of least resistence is to just use github's issues system. It
> > seems to go along with moving the source tree to git on github, and I
> > think their system works reasonably.
> 
> I think I'd prefer a dedicated system, personally. I'm already running 
> Phabricator for the EDK2 repository browser at https://edk2.bluestop.org 
> and enabling the bug/task tracker Maniphest module 
> (http://phacility.com/phabricator/maniphest/) is just a few clicks.
> But I'd have to have buy-in from the Intel folks etc. for it to be used.

If we wanted to run a dedicated server, it seems like bugzilla has a
longer track record.

But, personally, running a server for bugzilla seems like a hassle.
Let's assume we figure out a long term plan to pay for it. We still
have to handle all the admin issues of backing it up, dealing with
crashes, dealing with people trying to crack or crash the server,
etc...

The folks at github are hosting a *a lot* of projects, and they seem
to be handling the administrative junk pretty well.

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

Re: [edk2] [PATCH] SecurityPkg: Reduce verbosity of TPM DEBUG messages

[Yao, Jiewen]

Looks good.
Reviewed by: jiewen@intel.com


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Samer 
El-Haj-Mahmoud
Sent: Tuesday, September 15, 2015 4:40 AM
To: edk2-devel@lists.01.org
Cc: Samer El-Haj-Mahmoud; Zhang, Chao B; Samer El-Haj-Mahmoud
Subject: [edk2] [PATCH] SecurityPkg: Reduce verbosity of TPM DEBUG messages

Some of the TPM/TPM2 DEBUG messages are at EFI_D_INFO level, even though they 
are simply tracing functions that run on every boot even if there is no TPM 
installed. Changed verbosity to EFI_D_VERBOSE.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 .../DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c  |  3 ++-
 SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c  | 13 ++--
 SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c  | 23 +++---
 SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Tis.c| 23 +++---
 4 files changed, 33 insertions(+), 29 deletions(-)

diff --git a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c 
b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
index 26bf6fb..1f2574e 100644
--- a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
+++ b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
@@ -16,6 +16,7 @@
   partition data carefully.
 
 Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 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 @@ -447,7 +448,7 @@ 
DxeTpm2MeasureBootHandler (
 // Tcg2 protocol is not installed. So, TPM2 is not present.
 // Don't do any measurement, and directly return EFI_SUCCESS.
 //
-DEBUG ((EFI_D_INFO, "DxeTpm2MeasureBootHandler - Tcg2 - %r\n", Status));
+DEBUG ((EFI_D_VERBOSE, "DxeTpm2MeasureBootHandler - Tcg2 - %r\n", 
+ Status));
 return EFI_SUCCESS;
   }
 
diff --git a/SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c 
b/SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c
index 379f2f7..075db4a 100644
--- a/SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c
+++ b/SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c
@@ -2,6 +2,7 @@
   Ihis library uses TPM2 device to calculation hash.
 
 Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved. 
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 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 @@ -242,7 +243,7 @@ 
HashAndExtend (
   TPM2B_EVENTEventData;
   TPM2B_DIGEST   Result;
 
-  DEBUG((EFI_D_INFO, "\n HashAndExtend Entry \n"));
+  DEBUG((EFI_D_VERBOSE, "\n HashAndExtend Entry \n"));
 
   SequenceHandle = 0x; // Know bad value
 
@@ -262,7 +263,7 @@ HashAndExtend (
   if (EFI_ERROR(Status)) {
 return EFI_DEVICE_ERROR;
   }
-  DEBUG((EFI_D_INFO, "\n Tpm2HashSequenceStart Success \n"));
+  DEBUG((EFI_D_VERBOSE, "\n Tpm2HashSequenceStart Success \n"));
 
   Buffer = (UINT8 *)(UINTN)DataToHash;
   for (HashLen = DataToHashLen; HashLen > sizeof(HashBuffer.buffer); HashLen 
-= sizeof(HashBuffer.buffer)) { @@ -276,7 +277,7 @@ HashAndExtend (
   return EFI_DEVICE_ERROR;
 }
   }
-  DEBUG((EFI_D_INFO, "\n Tpm2SequenceUpdate Success \n"));
+  DEBUG((EFI_D_VERBOSE, "\n Tpm2SequenceUpdate Success \n"));
 
   HashBuffer.size = (UINT16)HashLen;
   CopyMem(HashBuffer.buffer, Buffer, (UINTN)HashLen); @@ -294,7 +295,7 @@ 
HashAndExtend (
 if (EFI_ERROR(Status)) {
   return EFI_DEVICE_ERROR;
 }
-DEBUG((EFI_D_INFO, "\n Tpm2EventSequenceComplete Success \n"));
+DEBUG((EFI_D_VERBOSE, "\n Tpm2EventSequenceComplete Success \n"));
   } else {
 Status = Tpm2SequenceComplete (
SequenceHandle,
@@ -304,7 +305,7 @@ HashAndExtend (
 if (EFI_ERROR(Status)) {
   return EFI_DEVICE_ERROR;
 }
-DEBUG((EFI_D_INFO, "\n Tpm2SequenceComplete Success \n"));
+DEBUG((EFI_D_VERBOSE, "\n Tpm2SequenceComplete Success \n"));
 
 DigestList->count = 1;
 DigestList->digests[0].hashAlg = AlgoId; @@ -316,7 +317,7 @@ HashAndExtend 
(
 if (EFI_ERROR(Status)) {
   return EFI_DEVICE_ERROR;
 }
-DEBUG((EFI_D_INFO, "\n Tpm2PcrExtend Success \n"));
+DEBUG((EFI_D_VERBOSE, "\n Tpm2PcrExtend Success \n"));
   }
 
   return EFI_SUCCESS;
diff --git a/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c 
b/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
index 2fb360f..b8d13aa 100644
--- a/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
+++ b/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
@@ -2,6 +2,7 @@
   TIS (TPM Interface Specification) functions used by TPM1.2.
   
 Copyright (c) 2013 - 2015, Intel Corporat

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Bruce Cran]

On 9/14/15 4:20 PM, Jordan Justen wrote:


If we wanted to run a dedicated server, it seems like bugzilla has a
longer track record.


Well volunteered!


But, personally, running a server for bugzilla seems like a hassle.
Let's assume we figure out a long term plan to pay for it. We still
have to handle all the admin issues of backing it up, dealing with
crashes, dealing with people trying to crack or crash the server,
etc...


Heh, to me it's just another service to run. I already deal with running 
a mail server (with all the stuff like greylisting, DKIM, SPF, spam 
filtering etc.) with secure submission, IMAP server, Jenkins and a 
standard web server. So, in comparison Phabricator/Bugzilla etc. seems 
fairly simple!


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

Re: [edk2] [PATCH 4/4] OvmfPkg: PlatformPei: take no-exec DXE settings from the QEMU command line

[Jordan Justen]

On 2015-09-11 08:15:53, Laszlo Ersek wrote:
> Control them with:
> 
>   -fw_cfg name=opt/ovmf/PcdPropertiesTableEnable,file=no.txt \
>   -fw_cfg name=opt/ovmf/PcdSetNxForStack,file=yes.txt

It seems like a -fw_cfg name=foo,content=string form could be useful
in these cases. Is this 'opt/*' method used by other fw_cfg code?

For all 5 patches:

Reviewed-by: Jordan Justen 

> where the contents of the text files can be
> 
>   [0nN1yY](\n|\r\n)?
> 
> The macro trickery is not optimal, but it is caused by PcdSetBool(), which
> is itself a macro, and can only take open-coded PCD names (ie. no
> variables, like function parameters).
> 
> Cc: Jordan Justen 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/PlatformPei/PlatformPei.inf |  2 +
>  OvmfPkg/PlatformPei/Platform.c  | 65 +++-
>  2 files changed, 65 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index 81335a9..c2c7da9 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -83,6 +83,8 @@ [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
>gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
>gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
>gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
>  
>  [Ppis]
> diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
> index 6a7bc52..a6d9616 100644
> --- a/OvmfPkg/PlatformPei/Platform.c
> +++ b/OvmfPkg/PlatformPei/Platform.c
> @@ -242,6 +242,68 @@ MemMapInitialization (
>}
>  }
>  
> +EFI_STATUS
> +GetNamedFwCfgBoolean (
> +  IN  CHAR8   *FwCfgFileName,
> +  OUT BOOLEAN *Setting
> +  )
> +{
> +  EFI_STATUS   Status;
> +  FIRMWARE_CONFIG_ITEM FwCfgItem;
> +  UINTNFwCfgSize;
> +  UINT8Value[3];
> +
> +  Status = QemuFwCfgFindFile (FwCfgFileName, &FwCfgItem, &FwCfgSize);
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +  if (FwCfgSize > sizeof Value) {
> +return EFI_BAD_BUFFER_SIZE;
> +  }
> +  QemuFwCfgSelectItem (FwCfgItem);
> +  QemuFwCfgReadBytes (FwCfgSize, Value);
> +
> +  if ((FwCfgSize == 1) ||
> +  (FwCfgSize == 2 && Value[1] == '\n') ||
> +  (FwCfgSize == 3 && Value[1] == '\r' && Value[2] == '\n')) {
> +switch (Value[0]) {
> +  case '0':
> +  case 'n':
> +  case 'N':
> +*Setting = FALSE;
> +return EFI_SUCCESS;
> +
> +  case '1':
> +  case 'y':
> +  case 'Y':
> +*Setting = TRUE;
> +return EFI_SUCCESS;
> +
> +  default:
> +break;
> +}
> +  }
> +  return EFI_PROTOCOL_ERROR;
> +}
> +
> +#define UPDATE_BOOLEAN_PCD_FROM_FW_CFG(TokenName)   \
> +  do {  \
> +BOOLEAN Setting;\
> +\
> +if (!EFI_ERROR (GetNamedFwCfgBoolean (  \
> +  "opt/ovmf/" #TokenName, &Setting))) { \
> +  PcdSetBool (TokenName, Setting);  \
> +}   \
> +  } while (0)
> +
> +VOID
> +NoexecDxeInitialization (
> +  VOID
> +  )
> +{
> +  UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdPropertiesTableEnable);
> +  UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdSetNxForStack);
> +}
>  
>  VOID
>  MiscInitialization (
> @@ -438,10 +500,9 @@ InitializePlatform (
>  
>if (mBootMode != BOOT_ON_S3_RESUME) {
>  ReserveEmuVariableNvStore ();
> -
>  PeiFvInitialization ();
> -
>  MemMapInitialization ();
> +NoexecDxeInitialization ();
>}
>  
>MiscInitialization ();
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 0/4] Optimize HTTP to speed up the download process

[Wu, Jiaxin]

Series Reviewed-by: Jiaxin Wu 


-Original Message-
From: Fu, Siyuan 
Sent: Monday, September 14, 2015 4:24 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Wu, Jiaxin
Subject: [Patch 0/4] Optimize HTTP to speed up the download process

These patches update the HttpDxe and HttpBootDxe driver to speed the download.
See the comments in each patch file for details.

Fu Siyuan (4):
  NetworkPkg: Enlarge receive block size of HTTP boot driver.
  NetworkPkg: Update cache management in HTTP boot driver.
  NetworkPkg: Update Http driver to use DPC mechanism.
  NetworkPkg: Avoid memory allocation for each HTTP message exchange.

 NetworkPkg/HttpBootDxe/HttpBootClient.c | 63 +--  
NetworkPkg/HttpBootDxe/HttpBootClient.h |  2 +-
 NetworkPkg/HttpDxe/HttpDriver.h |  2 +-
 NetworkPkg/HttpDxe/HttpDxe.inf  |  1 +
 NetworkPkg/HttpDxe/HttpImpl.c   | 28 +-
 NetworkPkg/HttpDxe/HttpProto.c  | 66 +
 NetworkPkg/HttpDxe/HttpProto.h  |  4 ++
 7 files changed, 118 insertions(+), 48 deletions(-)

--
2.5.0.windows.1

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

Re: [edk2] [PATCH] SecurityPkg: Reduce verbosity of TPM DEBUG messages

[Zhang, Chao B]

Samer:
   To me, EFI_D_INFO is OK to send out these information. If you don't want to 
see them, you can
configure debug level message PCD special for TPM module.





Thanks & Best regards
Chao Zhang

-Original Message-
From: Samer El-Haj-Mahmoud [mailto:samer.el-haj-mahm...@hp.com] 
Sent: Tuesday, September 15, 2015 4:40 AM
To: edk2-devel@lists.01.org
Cc: Zhang, Chao B; Samer El-Haj-Mahmoud; Samer El-Haj-Mahmoud
Subject: [PATCH] SecurityPkg: Reduce verbosity of TPM DEBUG messages

Some of the TPM/TPM2 DEBUG messages are at EFI_D_INFO level, even though they 
are simply tracing functions that run on every boot even if there is no TPM 
installed. Changed verbosity to EFI_D_VERBOSE.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 .../DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c  |  3 ++-
 SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c  | 13 ++--
 SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c  | 23 +++---
 SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Tis.c| 23 +++---
 4 files changed, 33 insertions(+), 29 deletions(-)

diff --git a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c 
b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
index 26bf6fb..1f2574e 100644
--- a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
+++ b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
@@ -16,6 +16,7 @@
   partition data carefully.
 
 Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 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 @@ -447,7 +448,7 @@ 
DxeTpm2MeasureBootHandler (
 // Tcg2 protocol is not installed. So, TPM2 is not present.
 // Don't do any measurement, and directly return EFI_SUCCESS.
 //
-DEBUG ((EFI_D_INFO, "DxeTpm2MeasureBootHandler - Tcg2 - %r\n", Status));
+DEBUG ((EFI_D_VERBOSE, "DxeTpm2MeasureBootHandler - Tcg2 - %r\n", 
+ Status));
 return EFI_SUCCESS;
   }
 
diff --git a/SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c 
b/SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c
index 379f2f7..075db4a 100644
--- a/SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c
+++ b/SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c
@@ -2,6 +2,7 @@
   Ihis library uses TPM2 device to calculation hash.
 
 Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved. 
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 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 @@ -242,7 +243,7 @@ 
HashAndExtend (
   TPM2B_EVENTEventData;
   TPM2B_DIGEST   Result;
 
-  DEBUG((EFI_D_INFO, "\n HashAndExtend Entry \n"));
+  DEBUG((EFI_D_VERBOSE, "\n HashAndExtend Entry \n"));
 
   SequenceHandle = 0x; // Know bad value
 
@@ -262,7 +263,7 @@ HashAndExtend (
   if (EFI_ERROR(Status)) {
 return EFI_DEVICE_ERROR;
   }
-  DEBUG((EFI_D_INFO, "\n Tpm2HashSequenceStart Success \n"));
+  DEBUG((EFI_D_VERBOSE, "\n Tpm2HashSequenceStart Success \n"));
 
   Buffer = (UINT8 *)(UINTN)DataToHash;
   for (HashLen = DataToHashLen; HashLen > sizeof(HashBuffer.buffer); HashLen 
-= sizeof(HashBuffer.buffer)) { @@ -276,7 +277,7 @@ HashAndExtend (
   return EFI_DEVICE_ERROR;
 }
   }
-  DEBUG((EFI_D_INFO, "\n Tpm2SequenceUpdate Success \n"));
+  DEBUG((EFI_D_VERBOSE, "\n Tpm2SequenceUpdate Success \n"));
 
   HashBuffer.size = (UINT16)HashLen;
   CopyMem(HashBuffer.buffer, Buffer, (UINTN)HashLen); @@ -294,7 +295,7 @@ 
HashAndExtend (
 if (EFI_ERROR(Status)) {
   return EFI_DEVICE_ERROR;
 }
-DEBUG((EFI_D_INFO, "\n Tpm2EventSequenceComplete Success \n"));
+DEBUG((EFI_D_VERBOSE, "\n Tpm2EventSequenceComplete Success \n"));
   } else {
 Status = Tpm2SequenceComplete (
SequenceHandle,
@@ -304,7 +305,7 @@ HashAndExtend (
 if (EFI_ERROR(Status)) {
   return EFI_DEVICE_ERROR;
 }
-DEBUG((EFI_D_INFO, "\n Tpm2SequenceComplete Success \n"));
+DEBUG((EFI_D_VERBOSE, "\n Tpm2SequenceComplete Success \n"));
 
 DigestList->count = 1;
 DigestList->digests[0].hashAlg = AlgoId; @@ -316,7 +317,7 @@ HashAndExtend 
(
 if (EFI_ERROR(Status)) {
   return EFI_DEVICE_ERROR;
 }
-DEBUG((EFI_D_INFO, "\n Tpm2PcrExtend Success \n"));
+DEBUG((EFI_D_VERBOSE, "\n Tpm2PcrExtend Success \n"));
   }
 
   return EFI_SUCCESS;
diff --git a/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c 
b/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
index 2fb360f..b8d13aa 100644
--- a/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
+++ b/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
@@ -2,

Re: [edk2] [PATCH] ShellPkg: Rename some functions in Dp to avoid build errors

[Qiu, Shumin]

Reviewed-by: Qiu Shumin 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
Jaben
Sent: Monday, September 14, 2015 10:50 PM
To: Samer El-Haj-Mahmoud; edk2-devel@lists.01.org
Cc: Carsey, Jaben
Subject: Re: [edk2] [PATCH] ShellPkg: Rename some functions in Dp to avoid 
build errors

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Samer El-Haj-Mahmoud [mailto:samer.el-haj-mahm...@hpe.com]
> Sent: Friday, September 11, 2015 4:53 PM
> To: edk2-devel@lists.01.org
> Cc: Samer El-Haj-Mahmoud ; Carsey, Jaben 
> 
> Subject: [PATCH] ShellPkg: Rename some functions in Dp to avoid build 
> errors
> Importance: High
> 
> There are other libraries with similarly named functions that could be 
> linked with the Shell
> 
> Signed-off-by: Samer El-Haj-Mahmoud 
> Cc: Jaben Carsey 
> ---
>  ShellPkg/Library/UefiDpLib/DpInternal.h  | 5 +++--
>  ShellPkg/Library/UefiDpLib/DpTrace.c | 5 +++--
>  ShellPkg/Library/UefiDpLib/DpUtilities.c | 7 ---
>  3 files changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiDpLib/DpInternal.h
> b/ShellPkg/Library/UefiDpLib/DpInternal.h
> index c7d9a59..22dc4f9 100644
> --- a/ShellPkg/Library/UefiDpLib/DpInternal.h
> +++ b/ShellPkg/Library/UefiDpLib/DpInternal.h
> @@ -7,6 +7,7 @@
>DpUtilities.c, DpTrace.c, and DpProfile.c are included here.
> 
>Copyright (c) 2009 - 2013, Intel Corporation. All rights reserved.
> +  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
>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 @@ -96,7 +97,7 @@ IsPhase(
> 
>  **/
>  VOID
> -GetShortPdbFileName (
> +DpGetShortPdbFileName (
>IN  CHAR8 *PdbFileName,
>OUT CHAR16*UnicodeBuffer
>);
> @@ -118,7 +119,7 @@ GetShortPdbFileName (
> 
>  **/
>  VOID
> -GetNameFromHandle (
> +DpGetNameFromHandle (
>IN EFI_HANDLE Handle
>);
> 
> diff --git a/ShellPkg/Library/UefiDpLib/DpTrace.c
> b/ShellPkg/Library/UefiDpLib/DpTrace.c
> index de1d45a..542fcc8 100644
> --- a/ShellPkg/Library/UefiDpLib/DpTrace.c
> +++ b/ShellPkg/Library/UefiDpLib/DpTrace.c
> @@ -2,6 +2,7 @@
>Trace reporting for the Dp utility.
> 
>Copyright (c) 2009 - 2013, Intel Corporation. All rights reserved.
> +  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
>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 @@ -216,7 +217,7 @@ DumpAllTrace(
>  // See if the Handle is in the HandleBuffer
>  for (TIndex = 0; TIndex < (Size / sizeof(HandleBuffer[0])); 
> TIndex++) {
>if (Measurement.Handle == HandleBuffer[TIndex]) {
> -GetNameFromHandle (HandleBuffer[TIndex]);
> +DpGetNameFromHandle (HandleBuffer[TIndex]);
>  break;
>}
>  }
> @@ -582,7 +583,7 @@ ProcessHandles(
>// See if the Handle is in the HandleBuffer
>for (Index = 0; Index < (Size / sizeof(HandleBuffer[0])); Index++) {
>  if (Measurement.Handle == HandleBuffer[Index]) {
> -  GetNameFromHandle (HandleBuffer[Index]); // Name is put into
> mGaugeString
> +  DpGetNameFromHandle (HandleBuffer[Index]); // Name is put 
> + into
> mGaugeString
>break;
>  }
>}
> diff --git a/ShellPkg/Library/UefiDpLib/DpUtilities.c
> b/ShellPkg/Library/UefiDpLib/DpUtilities.c
> index 063eb65..c464c2f 100644
> --- a/ShellPkg/Library/UefiDpLib/DpUtilities.c
> +++ b/ShellPkg/Library/UefiDpLib/DpUtilities.c
> @@ -2,6 +2,7 @@
>Utility functions used by the Dp application.
> 
>Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
> +  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
>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 @@ -131,7 +132,7 @@ IsPhase(
> 
>  **/
>  VOID
> -GetShortPdbFileName (
> +DpGetShortPdbFileName (
>IN  CHAR8 *PdbFileName,
>OUT CHAR16*UnicodeBuffer
>)
> @@ -188,7 +189,7 @@ GetShortPdbFileName (
> 
>  **/
>  VOID
> -GetNameFromHandle (
> +DpGetNameFromHandle (
>IN EFI_HANDLE   Handle
>)
>  {
> @@ -236,7 +237,7 @@ GetNameFromHandle (
>  PdbFileName = PeCoffLoaderGetPdbPointer (Image->ImageBase);
> 
>  if (PdbFileName != NULL) {
> -  GetShortPdbFileName (PdbFileName, mGaugeString);
> +  DpGetShortPdbFileName (PdbFileName, mGaugeString);
>return;
>  }
>}
> --
> 1.9.5.msysgit.1

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

[edk2] Proposal to let standalone UEFI shell application carry help inside .EFI instead of in .MAN file

[Ni, Ruiyu]

All,
UEFI Shell scandalizes the help message in spec level so that a standalone UEFI 
shell application can never get "-?" switch, instead the Shell core 
(interpreter) detects the "-?" and finds .MAN file for that shell application 
in certain spec defined paths, then show the help extracted from that .MAN file.

But it means distributing a UEFI shell application not only means distributing 
a .EFI file but also distributing a .MAN file. If the text formatted .MAN file 
is corrupted (edited by user by mistake), or is missing (deleted by user by 
mistake), no help will be shown to user.

So I propose to embedded the help message inside the .EFI file in a PE resource 
section and the algorithm to find help for a standalone application is as 
following.

Search command.man file for valid help content
If command.man exists and help content is valid:
Display the help
Else:
Load the command.efi (do not start it)
Check whether the ImageHandle has EFI_HII_PACKAGE_LIST_PROTOCOL_GUID installed
Check all strings in the HII packages to find a string which follows spec 
defined help format
If the string exists:
Display the help
Else:
Show "no Help"

Any comments, concerns?


Regards,
Ray

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

[edk2] [Patch] NetworkPkg: TrafficDirection not saved in IPsecConfig.

[Fu Siyuan]

Fix a bug that the TrafficDirection field is not saved in IPsecConfig.SetData.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/IpSecDxe/IpSecConfigImpl.c | 14 --
 NetworkPkg/IpSecDxe/IpSecImpl.h   |  1 +
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/NetworkPkg/IpSecDxe/IpSecConfigImpl.c 
b/NetworkPkg/IpSecDxe/IpSecConfigImpl.c
index bd49245..6aa47aa 100644
--- a/NetworkPkg/IpSecDxe/IpSecConfigImpl.c
+++ b/NetworkPkg/IpSecDxe/IpSecConfigImpl.c
@@ -1167,9 +1167,10 @@ SetSpdEntry (
 SpdData->Name,
 sizeof (SpdData->Name)
 );
-  SpdEntry->Data->PackageFlag = SpdData->PackageFlag;
-  SpdEntry->Data->Action  = SpdData->Action;
-
+  SpdEntry->Data->PackageFlag  = SpdData->PackageFlag;
+  SpdEntry->Data->TrafficDirection = SpdData->TrafficDirection;
+  SpdEntry->Data->Action   = SpdData->Action;
+  
   //
   // Fix the address of ProcessingPolicy and copy it if need, which is 
continous
   // memory and close to the base structure of SAD data.
@@ -1690,9 +1691,10 @@ GetSpdEntry (
   //
   CopyMem (SpdData->Name, SpdEntry->Data->Name, sizeof (SpdData->Name));
 
-  SpdData->PackageFlag  = SpdEntry->Data->PackageFlag;
-  SpdData->Action   = SpdEntry->Data->Action;
-
+  SpdData->PackageFlag  = SpdEntry->Data->PackageFlag;
+  SpdData->TrafficDirection = SpdEntry->Data->TrafficDirection;
+  SpdData->Action   = SpdEntry->Data->Action;
+  
   if (SpdData->Action != EfiIPsecActionProtect) {
 SpdData->ProcessingPolicy = NULL;
   } else {
diff --git a/NetworkPkg/IpSecDxe/IpSecImpl.h b/NetworkPkg/IpSecDxe/IpSecImpl.h
index 8b63d24..89597bd 100644
--- a/NetworkPkg/IpSecDxe/IpSecImpl.h
+++ b/NetworkPkg/IpSecDxe/IpSecImpl.h
@@ -76,6 +76,7 @@ typedef struct _EFI_ESP_TAIL {
 struct _IPSEC_SPD_DATA {
   CHAR16Name[100];
   UINT32PackageFlag;
+  EFI_IPSEC_TRAFFIC_DIR TrafficDirection;
   EFI_IPSEC_ACTION  Action;
   EFI_IPSEC_PROCESS_POLICY  *ProcessingPolicy;
   LIST_ENTRYSas;
-- 
2.5.0.windows.1

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

Re: [edk2] [Patch] NetworkPkg: TrafficDirection not saved in IPsecConfig.

[Wu, Jiaxin]

Reviewed-by: Jiaxin Wu 

-Original Message-
From: Fu, Siyuan 
Sent: Tuesday, September 15, 2015 11:10 AM
To: edk2-devel@lists.01.org
Cc: Wu, Jiaxin; Ye, Ting
Subject: [Patch] NetworkPkg: TrafficDirection not saved in IPsecConfig.

Fix a bug that the TrafficDirection field is not saved in IPsecConfig.SetData.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/IpSecDxe/IpSecConfigImpl.c | 14 --
 NetworkPkg/IpSecDxe/IpSecImpl.h   |  1 +
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/NetworkPkg/IpSecDxe/IpSecConfigImpl.c 
b/NetworkPkg/IpSecDxe/IpSecConfigImpl.c
index bd49245..6aa47aa 100644
--- a/NetworkPkg/IpSecDxe/IpSecConfigImpl.c
+++ b/NetworkPkg/IpSecDxe/IpSecConfigImpl.c
@@ -1167,9 +1167,10 @@ SetSpdEntry (
 SpdData->Name,
 sizeof (SpdData->Name)
 );
-  SpdEntry->Data->PackageFlag = SpdData->PackageFlag;
-  SpdEntry->Data->Action  = SpdData->Action;
-
+  SpdEntry->Data->PackageFlag  = SpdData->PackageFlag;
+  SpdEntry->Data->TrafficDirection = SpdData->TrafficDirection;
+  SpdEntry->Data->Action   = SpdData->Action;
+  
   //
   // Fix the address of ProcessingPolicy and copy it if need, which is 
continous
   // memory and close to the base structure of SAD data.
@@ -1690,9 +1691,10 @@ GetSpdEntry (
   //
   CopyMem (SpdData->Name, SpdEntry->Data->Name, sizeof (SpdData->Name));
 
-  SpdData->PackageFlag  = SpdEntry->Data->PackageFlag;
-  SpdData->Action   = SpdEntry->Data->Action;
-
+  SpdData->PackageFlag  = SpdEntry->Data->PackageFlag;
+  SpdData->TrafficDirection = SpdEntry->Data->TrafficDirection;
+  SpdData->Action   = SpdEntry->Data->Action;
+  
   if (SpdData->Action != EfiIPsecActionProtect) {
 SpdData->ProcessingPolicy = NULL;
   } else {
diff --git a/NetworkPkg/IpSecDxe/IpSecImpl.h b/NetworkPkg/IpSecDxe/IpSecImpl.h 
index 8b63d24..89597bd 100644
--- a/NetworkPkg/IpSecDxe/IpSecImpl.h
+++ b/NetworkPkg/IpSecDxe/IpSecImpl.h
@@ -76,6 +76,7 @@ typedef struct _EFI_ESP_TAIL {  struct _IPSEC_SPD_DATA {
   CHAR16Name[100];
   UINT32PackageFlag;
+  EFI_IPSEC_TRAFFIC_DIR TrafficDirection;
   EFI_IPSEC_ACTION  Action;
   EFI_IPSEC_PROCESS_POLICY  *ProcessingPolicy;
   LIST_ENTRYSas;
--
2.5.0.windows.1

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

[edk2] [Patch V2] * ShellPkg: Add a simple case to test shell parameter parsing logic

[Ruiyu Ni]

TestArgv.nsh is a very simple shell script to test how the interpreter parses
the parameters. It uses ShellCTestApp.efi to dump the parameters passed from the
interpreter.

TestArgv.log is the desired output created using "TestArgv.nsh > TestArgv.log".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Application/ShellCTestApp/README.txt  |   5 ++
 ShellPkg/Application/ShellCTestApp/ShellCTestApp.c |  11 ++--
 ShellPkg/Application/ShellCTestApp/TestArgv.log| Bin 0 -> 3320 bytes
 ShellPkg/Application/ShellCTestApp/TestArgv.nsh|  64 +
 4 files changed, 75 insertions(+), 5 deletions(-)
 create mode 100644 ShellPkg/Application/ShellCTestApp/README.txt
 create mode 100644 ShellPkg/Application/ShellCTestApp/TestArgv.log
 create mode 100644 ShellPkg/Application/ShellCTestApp/TestArgv.nsh

diff --git a/ShellPkg/Application/ShellCTestApp/README.txt 
b/ShellPkg/Application/ShellCTestApp/README.txt
new file mode 100644
index 000..7814bb8
--- /dev/null
+++ b/ShellPkg/Application/ShellCTestApp/README.txt
@@ -0,0 +1,5 @@
+TestArgv.nsh is a very simple shell script to test how the interpreter parses
+the parameters. It uses ShellCTestApp.efi to dump the parameters passed from 
the
+intepreter.
+
+TestArgv.log is the desired output created using "TestArgv.nsh > TestArgv.log".
\ No newline at end of file
diff --git a/ShellPkg/Application/ShellCTestApp/ShellCTestApp.c 
b/ShellPkg/Application/ShellCTestApp/ShellCTestApp.c
index 8d3fa4c..08c830c 100644
--- a/ShellPkg/Application/ShellCTestApp/ShellCTestApp.c
+++ b/ShellPkg/Application/ShellCTestApp/ShellCTestApp.c
@@ -2,7 +2,7 @@
   This is a test application that demonstrates how to use the C-style entry 
point
   for a shell application.
 
-  Copyright (c) 2009 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -40,10 +40,11 @@ ShellAppMain (
   )
 {
   UINTN  Index;
-
-  Print(L"ShellCTestApp.c:ShellAppMain called with %d parameters\n", Argc);
-  for (Index = 0; Index < Argc; Index++) {
-Print(L"Argv[%d]: %s\n", Index, Argv[Index]);
+  if (Argc == 1) {
+Print (L"Argv[1] = NULL\n");
+  }
+  for (Index = 1; Index < Argc; Index++) {
+Print(L"Argv[%d]: \"%s\"\n", Index, Argv[Index]);
   }
 
   return 0;
diff --git a/ShellPkg/Application/ShellCTestApp/TestArgv.log 
b/ShellPkg/Application/ShellCTestApp/TestArgv.log
new file mode 100644
index 
..e76781ea0e4387cf97ad42d5ccbb8a72f99c8d61
GIT binary patch
literal 3320
zcmcha-EPxB5QWcmCEmeumCH&=6Q>ChNOt0IgFvXzn?fx_-5;r<5dp;01K+G=wZUFT
z4t8bPp6txdIXgS!+5Gvv(y4}eu8(@DK)Jr?M)ycZJiqFh4zz8t!R9;qGkw-KWlGU6
zxW|e#<(=u6YsOfniB5PQBgI;RVq;?^SS}e^XwK6tSG
z6wbzGjsFynkz~r3x3bglzc99*ns>FZui6^
z$5YB|TUqKjByMDk?-*&K5xNLzj@B?UxXl@z5|O#n4|!TFACSWa^b?g9C`41Yx6R&)JgoC}xQDkv=M_BguC@=X
z_VFub)Wt8{BYpw9>Dyh?wdWUj{k8Yy=e7?s%VdA_OxK=ax7AVIi9j!?v^V;o*Iex?
zci_HvU3V0JeYCINP<_-?Kz|&lkDlgVdws7rCUrUWuxkIe(mHWBeXox7|KwFjS1x)?
zS%r09qknC-&tLv^TVGjo`)hx_$9HL)bB_OC+-1c#^Us}awf4$0
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#**/
+echo -on
+set Var_EFCF356F_228C_47C2_AD0C_3B5DAC9A8CFA  ValueOfGuid
+set Sharp_E8528E46_A008_4221_8DE0_D5AB42A9C580^#
+set Quote_E95DEE8B_E3AA_4155_9ED5_6916394104FC^"
+set Var_ShellCTestApp_EE6E8BC6_71A6_44A5_BED3_D8F901105CDE 
ShellCTestApp_EE6E8BC6_71A6_44A5_BED3_D8F901105CDE
+alias ShellCTestApp_EE6E8BC6_71A6_44A5_BED3_D8F901105CDE   ShellCTestApp
+
+#
+# '^' should escape all special characters (including space)
+# but has no impact to non-special characters
+#
+ShellCTestApp ^^
+ShellCTestApp ^#
+ShellCTestApp ^%Var_EFCF356F_228C_47C2_AD0C_3B5DAC9A8CFA%
+ShellCTestApp ^"
+ShellCTestApp ^ 1
+ShellCTestApp ^ 
+ShellCTestApp ^1
+ShellCTestApp ^^^"
+ShellCTestApp ^^^
+
+#
+# '#' should be processed before %% replacement, and inside '"'
+#
+ShellCTestApp #%Var_EFCF356F_228C_47C2_AD0C_3B5DAC9A8CFA%
+#ShellCTestApp "#"
+ShellCTestApp %Sharp_E8528E46_A008_4221_8DE0_D5AB42A9C580%
+
+#
+# '%' should be processed before grouping parameters
+#
+ShellCTestApp "%Var_EFCF356F_228C_47C2_AD0C_3B5DAC9A8CFA% 
2%Quote_E95DEE8B_E3AA_4155_9ED5_6916394104FC%
+
+#
+# alias should be processed after %% replacement
+#
+%Var_ShellCTestApp_EE6E8BC6_71A6_44A5_BED3_D8F901105CDE%
+
+#
+# '"' should be stripped, space inside '"' sho

Re: [edk2] Proposal to let standalone UEFI shell application carry help inside .EFI instead of in .MAN file

[Andrew Fish]

> On Sep 14, 2015, at 7:53 PM, Ni, Ruiyu  wrote:
> 
> All,
> UEFI Shell scandalizes the help message in spec level so that a standalone 
> UEFI shell application can never get "-?" switch, instead the Shell core 
> (interpreter) detects the "-?" and finds .MAN file for that shell application 
> in certain spec defined paths, then show the help extracted from that .MAN 
> file.
> 
> But it means distributing a UEFI shell application not only means 
> distributing a .EFI file but also distributing a .MAN file. If the text 
> formatted .MAN file is corrupted (edited by user by mistake), or is missing 
> (deleted by user by mistake), no help will be shown to user.
> 
> So I propose to embedded the help message inside the .EFI file in a PE 
> resource section and the algorithm to find help for a standalone application 
> is as following.
> 
> Search command.man file for valid help content
> If command.man exists and help content is valid:
> Display the help
> Else:
> Load the command.efi (do not start it)
> Check whether the ImageHandle has EFI_HII_PACKAGE_LIST_PROTOCOL_GUID installed
> Check all strings in the HII packages to find a string which follows spec 
> defined help format
> If the string exists:
> Display the help
> Else:
> Show "no Help"
> 
> Any comments, concerns?
> 

Would this feature require updating the UEFI Shell Specification?

Thanks,

Andrew Fish

> 
> Regards,
> Ray
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=_cmkx_yAWDyToHJ6XXUyK8qnygDbR8JybrAy3GW0bxI&s=DtxkQsbqL8vqjctJhVdpTYa0msKsQtXDicdjNfXatNk&e=
>  

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

[edk2] [Patch] NetworkPkg: Fix connection issue after correct SPD and re-enable IPsec

[Jiaxin Wu]

This patch is used to fix connection failure issue after correct the SPD
and re-enable IPsec. The driver should not update the SadEntry's SpdSelector
when doing SpdEntry modification. SadEntry's SpdSelector may not equal to
this edited SpdEntry’s Selector.

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/IpSecDxe/IpSecConfigImpl.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/NetworkPkg/IpSecDxe/IpSecConfigImpl.c 
b/NetworkPkg/IpSecDxe/IpSecConfigImpl.c
index bd49245..405521d 100644
--- a/NetworkPkg/IpSecDxe/IpSecConfigImpl.c
+++ b/NetworkPkg/IpSecDxe/IpSecConfigImpl.c
@@ -1201,16 +1201,11 @@ SetSpdEntry (
 )) {
 if (SadEntry->Data->SpdEntry != NULL) {  
   RemoveEntryList (&SadEntry->BySpd);
 }
 InsertTailList (&SpdEntry->Data->Sas, &SadEntry->BySpd);
-SadEntry->Data->SpdEntry = SpdEntry;
-DuplicateSpdSelector (
-  (EFI_IPSEC_CONFIG_SELECTOR *)SadEntry->Data->SpdSelector,
-  (EFI_IPSEC_CONFIG_SELECTOR *)SpdEntry->Selector,
-  NULL
-  ); 
+SadEntry->Data->SpdEntry = SpdEntry; 
   }
 }
   }
   //
   // Insert the new SPD entry.
-- 
1.9.5.msysgit.1

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

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Josh Triplett]

On Mon, Sep 14, 2015 at 01:31:45PM -0600, Bruce Cran wrote:
> On 9/14/15 1:19 PM, Jordan Justen wrote:
> >I think the bug tracker on sf got shut down when sf stopped supporting
> >their 'hosted services'. (Ie, for example, when they shut down the
> >hosted mediawiki service.)
> 
> It got broken when SF changed their URLs. I asked about it back then but
> nobody seemed to care.

Considering recent developments on sourceforge, it seems as good a
reason as any to leave.

> >Well, there has been discussion on this topic at Intel. It is a
> >mentioned goal:
> >
> >http://www.tianocore.org/news/2015/05/01/UnderConst.html
> 
> Then let's do it! I guess there must be internal discussions going on, but
> it's a little frustration to see no update for months at a time.
> 
> >Some want to try to somehow run a bugzilla server. Personally, I think
> >the path of least resistence is to just use github's issues system. It
> >seems to go along with moving the source tree to git on github, and I
> >think their system works reasonably.
> 
> I think I'd prefer a dedicated system, personally. I'm already running
> Phabricator for the EDK2 repository browser at https://edk2.bluestop.org and
> enabling the bug/task tracker Maniphest module
> (http://phacility.com/phabricator/maniphest/) is just a few clicks.
> But I'd have to have buy-in from the Intel folks etc. for it to be used.

Whether running a standalone system or a hosted service, I don't think
it makes sense to use one completely separate from code hosting.  If
you're using github for code, it makes sense to use github for issues;
if you were using Phabricator for code review and maintenance, then
using it for issues makes sense.

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

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Bruce Cran]

On 9/14/15 11:13 PM, Josh Triplett wrote:


Whether running a standalone system or a hosted service, I don't think
it makes sense to use one completely separate from code hosting.  If
you're using github for code, it makes sense to use github for issues;
if you were using Phabricator for code review and maintenance, then
using it for issues makes sense.


Agreed. For me, the nice thing about Phabricator is that it can either 
host or mirror both Git and SVN repositories.


But if people would prefer to use Github then I'd be happy with that 
too, just as long as there's *some* way to track bugs that isn't an 
email archive!


--
Bruce

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

Re: [edk2] [PATCH] MdeModulePkg: PciBusDxe: Properly exit PCI function loops early if the device is not a multifunction device.

[Ni, Ruiyu]

On 2015/9/15 4:19, Samer El-Haj-Mahmoud wrote:

From: "Shifflett, Joseph" 

When looping through all PCI functions, code should not look for functions 1-7 
if function 0 is not present or if function 0 indicates the device is not 
multifunction. Prior to this fix, the code would use stale data in a buffer to 
determine if a device is multifunction even if function 0 is not present.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
  MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c | 10 --
  .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c   | 38 ++
  MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c| 11 ++-
  3 files changed, 42 insertions(+), 17 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c
index 7329143..e638014 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c
@@ -2,6 +2,7 @@
PCI eunmeration implementation on entire PCI bus system for PCI Bus module.

  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
  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
@@ -382,6 +383,7 @@ PciAssignBusNumber (
UINT16  Register;
UINT8   Register8;
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciRootBridgeIo;
+  BOOLEAN MultiFunctionDevice;

PciRootBridgeIo = Bridge->PciRootBridgeIo;

@@ -394,6 +396,7 @@ PciAssignBusNumber (
// First check to see whether the parent is ppb
//
for (Device = 0; Device <= PCI_MAX_DEVICE; Device++) {
+MultiFunctionDevice = FALSE;
  for (Func = 0; Func <= PCI_MAX_FUNC; Func++) {

//
@@ -406,7 +409,9 @@ PciAssignBusNumber (
  Device,
  Func
  );
-
+  if (Func == 0) {
+MultiFunctionDevice = !EFI_ERROR (Status) && IS_PCI_MULTI_FUNC (&Pci);
+  }
if (!EFI_ERROR (Status)   &&
(IS_PCI_BRIDGE (&Pci) || IS_CARDBUS_BRIDGE (&Pci))) {

@@ -482,7 +487,8 @@ PciAssignBusNumber (

}

-  if (Func == 0 && !IS_PCI_MULTI_FUNC (&Pci)) {
+  if (Func == 0 && !MultiFunctionDevice) {
+

  //
  // Skip sub functions, this is not a multi function device
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
index f46025e..7b57374 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
@@ -2,6 +2,7 @@
PCI emumeration support functions implementation for PCI Bus module.

  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
  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
@@ -101,12 +102,13 @@ PciPciDeviceInfoCollector (
UINT8   SecBus;
PCI_IO_DEVICE   *PciIoDevice;
EFI_PCI_IO_PROTOCOL *PciIo;
+  BOOLEAN MultiFunctionDevice;

Status  = EFI_SUCCESS;
SecBus  = 0;

for (Device = 0; Device <= PCI_MAX_DEVICE; Device++) {
-
+MultiFunctionDevice = FALSE;
  for (Func = 0; Func <= PCI_MAX_FUNC; Func++) {

//
@@ -119,6 +121,9 @@ PciPciDeviceInfoCollector (
   (UINT8) Device,
   (UINT8) Func
   );
+  if (Func == 0) {
+MultiFunctionDevice = !EFI_ERROR (Status) && IS_PCI_MULTI_FUNC (&Pci);
+  }
if (!EFI_ERROR (Status)) {

  //
@@ -169,17 +174,17 @@ PciPciDeviceInfoCollector (
   );

  }
-
-if (Func == 0 && !IS_PCI_MULTI_FUNC (&Pci)) {
-
-  //
-  // Skip sub functions, this is not a multi function device
-  //
-  Func = PCI_MAX_FUNC;
-}
}
+   
+  if (Func == 0 && !MultiFunctionDevice) {

+//
+// Skip sub functions, this is not a multi function device
+//
+Func = PCI_MAX_FUNC;
+  }
  }
+
}

return EFI_SUCCESS;
@@ -334,9 +339,9 @@ DumpPciBars (

  DEBUG ((
EFI_D_INFO,
-  "   BAR[%d]: Type = %s; Alignment = 0x%lx;\tLength = 0x%lx;\tOffset = 
0x%02x\n",
+  "   BAR[%d]: Type = %s; Alignment = 0x%lx;\tLength = 0x%lx;\tOffset = 
0x%02x;\tValue = 0x%lx\n",
Index, mBarTypeStr[MIN (PciIoDevice->PciBar[Index].BarType, 
PciBarTypeMaxType)],
-  PciIoDevice->PciBar[Index].Alignment, PciIoDevice->PciBar[Index].Length, 
PciIoDevice->PciBar[Index].Offset
+  PciIoDevice->PciBar[