Re: [edk2] PciLib/PciExpressLib: 64-bit r/w functions

2017-08-06 Thread Laszlo Ersek 
On 08/05/17 23:38, Marvin H?user wrote:
> Dear developers,
> 
> While browsing the KabylakeSiPkg code, I noticed that 64-bit registers are 
> read directly via MmioRead64() as there is no PciRead64() function.
> Is there a specific reason there are no PciRead64() and PciExpressRead64() 
> functions or were they simply not needed previously?

Validity of 64-bit accesses to PCI config space is platform dependent
[*] and I guess the PciLib designers didn't want to deviate from the
common interface pattern that PciReadXX() always succeeds (as long as
the input parameter is valid), regardless of XX.

[*] The UEFI spec repeats the following paragraph in several places:

The I/O operations are carried out exactly as requested. The caller
is responsible satisfying any alignment and I/O width restrictions
that the PCI controller on a platform might require. For example on
some platforms, width requests of EfiPciIoWidthUint64 do not work.

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

[edk2] [PATCH 0/1] OvmfPkg/AcpiPlatformDxe: short-circuit the transfer of an empty S3_CONTEXT

2017-08-06 Thread Laszlo Ersek 
The commit message says it all; in the blurb I'm only mentioning the
fetch location and the fact that I regression-tested the bugfix with
VMGENID. Dhiru should please report back with a Tested-by if the patch
solves the symptom he sees.

Repo:   https://github.com/lersek/edk2.git
Branch: acpi_s3ctx_empty

Cc: Dhiru Kholia 
Cc: Jordan Justen 

Thanks
Laszlo

Laszlo Ersek (1):
  OvmfPkg/AcpiPlatformDxe: short-circuit the transfer of an empty
S3_CONTEXT

 OvmfPkg/AcpiPlatformDxe/BootScript.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

-- 
2.13.1.3.g8be5a757fa67

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

[edk2] [PATCH 1/1] OvmfPkg/AcpiPlatformDxe: short-circuit the transfer of an empty S3_CONTEXT

2017-08-06 Thread Laszlo Ersek 
In commit 805762252733 ("OvmfPkg/AcpiPlatformDxe: save fw_cfg boot script
with QemuFwCfgS3Lib", 2017-02-23), we replaced the explicit S3 boot script
manipulation in TransferS3ContextToBootScript() with a call to
QemuFwCfgS3CallWhenBootScriptReady(). (Passing AppendFwCfgBootScript() as
callback.)

QemuFwCfgS3CallWhenBootScriptReady() checks for fw_cfg DMA up-front, and
bails with RETURN_NOT_FOUND if fw_cfg DMA is missing.

(This is justified as the goal of QemuFwCfgS3Lib is to "enable[] driver
modules [...] to produce fw_cfg DMA operations that are to be replayed at
S3 resume time".)

In turn, if QemuFwCfgS3CallWhenBootScriptReady() fails, then
OvmfPkg/AcpiPlatformDxe rolls back any earlier linker/loader script
processing, and falls back to the built-in ACPI tables.

(This is also justified because failure to save WRITE_POINTER commands for
replaying at S3 resume implies failure to process the linker/loader script
comprehensively.)

Calling QemuFwCfgS3CallWhenBootScriptReady() from
TransferS3ContextToBootScript() *unconditionally* is wrong however. For
the case when the linker/loader script contains no WRITE_POINTER commands,
the call perpetuated an earlier side effect, and introduced another one:

(1) On machine types that provide fw_cfg DMA (i.e., 2.5+),
QemuFwCfgS3CallWhenBootScriptReady() would succeed, and allocate
workspace for the boot script opcodes in reserved memory. However, no
opcodes would actually be produced in the AppendFwCfgBootScript()
callback, due to lack of any WRITE_POINTER commands.

This waste of reserved memory had been introduced in earlier commit
df73df138d9d ("OvmfPkg/AcpiPlatformDxe: replay
QEMU_LOADER_WRITE_POINTER commands at S3", 2017-02-09).

(2) On machine types that lack fw_cfg DMA (i.e., 2.4 and earlier),
TransferS3ContextToBootScript() would now fail the linker/loader
script for no reason.

(Note that QEMU itself prevents adding devices that depend on
WRITE_POINTER if the machine type lacks fw_cfg DMA:

$ qemu-system-x86_64 -M pc-q35-2.4 -device vmgenid

qemu-system-x86_64: -device vmgenid: vmgenid requires DMA write
support in fw_cfg, which this machine type does not provide)

Short-circuit an empty S3_CONTEXT in TransferS3ContextToBootScript() by
dropping S3_CONTEXT on the floor. This is compatible with the current
contract of the function as it constitutes a transfer of ownership.

Regression (2) was found and reported by Dhiru Kholia as an OSX guest boot
failure on the "pc-q35-2.4" machine type:

http://mid.mail-archive.com/CANO7a6x6EaWNZ8y=MvLU=w_ljrlxsero3nmsghvaye0aucc...@mail.gmail.com

Dhiru bisected the issue to commit 805762252733.

Cc: Dhiru Kholia 
Cc: Jordan Justen 
Fixes: df73df138d9d53f7f7570f4fe97a6cde941a2656
Fixes: 805762252733bb67bc5157f0137c64e010724c77
Reported-by: Dhiru Kholia 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/AcpiPlatformDxe/BootScript.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/AcpiPlatformDxe/BootScript.c 
b/OvmfPkg/AcpiPlatformDxe/BootScript.c
index a7d2f9e38f57..1a188bfd615c 100644
--- a/OvmfPkg/AcpiPlatformDxe/BootScript.c
+++ b/OvmfPkg/AcpiPlatformDxe/BootScript.c
@@ -249,7 +249,10 @@ FatalError:
 because the ownership of S3Context has been transfered.
 
   @retval EFI_SUCCESS The translation of S3Context to ACPI S3 Boot Script
-  opcodes has been successfully executed or queued.
+  opcodes has been successfully executed or queued. (This
+  includes the case when S3Context was empty on input and
+  no ACPI S3 Boot Script opcodes have been necessary to
+  produce.)
 
   @return Error codes from underlying functions.
 **/
@@ -260,6 +263,11 @@ TransferS3ContextToBootScript (
 {
   RETURN_STATUS Status;
 
+  if (S3Context->Used == 0) {
+ReleaseS3Context (S3Context);
+return EFI_SUCCESS;
+  }
+
   Status = QemuFwCfgS3CallWhenBootScriptReady (AppendFwCfgBootScript,
  S3Context, sizeof (SCRATCH_BUFFER));
   return (EFI_STATUS)Status;
-- 
2.13.1.3.g8be5a757fa67

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

Re: [edk2] PciLib/PciExpressLib: 64-bit r/w functions

2017-08-06 Thread Marvin Häuser 
Thank you for your reply!

Sorry, I was only thinking of MMIO access when I wrote the mail, should have 
limited it to PciExpressLib.
I did not hear of any platform supporting MMIO but not 64-bit register r/w, 
will research that.

Regards,
Marvin.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Sunday, August 6, 2017 1:35 PM
> To: Marvin Häuser 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] PciLib/PciExpressLib: 64-bit r/w functions
> 
> On 08/05/17 23:38, Marvin H?user wrote:
> > Dear developers,
> >
> > While browsing the KabylakeSiPkg code, I noticed that 64-bit registers are
> read directly via MmioRead64() as there is no PciRead64() function.
> > Is there a specific reason there are no PciRead64() and PciExpressRead64()
> functions or were they simply not needed previously?
> 
> Validity of 64-bit accesses to PCI config space is platform dependent [*] and 
> I
> guess the PciLib designers didn't want to deviate from the common interface
> pattern that PciReadXX() always succeeds (as long as the input parameter is
> valid), regardless of XX.
> 
> [*] The UEFI spec repeats the following paragraph in several places:
> 
> The I/O operations are carried out exactly as requested. The caller
> is responsible satisfying any alignment and I/O width restrictions
> that the PCI controller on a platform might require. For example on
> some platforms, width requests of EfiPciIoWidthUint64 do not work.
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/1] OvmfPkg/AcpiPlatformDxe: short-circuit the transfer of an empty S3_CONTEXT

2017-08-06 Thread Dhiru Kholia 
On Sun, Aug 06, 2017 at 02:16:22PM +0200, Laszlo Ersek wrote:
> In commit 805762252733 ("OvmfPkg/AcpiPlatformDxe: save fw_cfg boot script
> with QemuFwCfgS3Lib", 2017-02-23), we replaced the explicit S3 boot script
> manipulation in TransferS3ContextToBootScript() with a call to
> QemuFwCfgS3CallWhenBootScriptReady(). (Passing AppendFwCfgBootScript() as
> callback.)
> 
> QemuFwCfgS3CallWhenBootScriptReady() checks for fw_cfg DMA up-front, and
> bails with RETURN_NOT_FOUND if fw_cfg DMA is missing.
> 
> (This is justified as the goal of QemuFwCfgS3Lib is to "enable[] driver
> modules [...] to produce fw_cfg DMA operations that are to be replayed at
> S3 resume time".)
> 
> In turn, if QemuFwCfgS3CallWhenBootScriptReady() fails, then
> OvmfPkg/AcpiPlatformDxe rolls back any earlier linker/loader script
> processing, and falls back to the built-in ACPI tables.
> 
> (This is also justified because failure to save WRITE_POINTER commands for
> replaying at S3 resume implies failure to process the linker/loader script
> comprehensively.)
> 
> Calling QemuFwCfgS3CallWhenBootScriptReady() from
> TransferS3ContextToBootScript() *unconditionally* is wrong however. For
> the case when the linker/loader script contains no WRITE_POINTER commands,
> the call perpetuated an earlier side effect, and introduced another one:
> 
> (1) On machine types that provide fw_cfg DMA (i.e., 2.5+),
> QemuFwCfgS3CallWhenBootScriptReady() would succeed, and allocate
> workspace for the boot script opcodes in reserved memory. However, no
> opcodes would actually be produced in the AppendFwCfgBootScript()
> callback, due to lack of any WRITE_POINTER commands.
> 
> This waste of reserved memory had been introduced in earlier commit
> df73df138d9d ("OvmfPkg/AcpiPlatformDxe: replay
> QEMU_LOADER_WRITE_POINTER commands at S3", 2017-02-09).
> 
> (2) On machine types that lack fw_cfg DMA (i.e., 2.4 and earlier),
> TransferS3ContextToBootScript() would now fail the linker/loader
> script for no reason.
> 
> (Note that QEMU itself prevents adding devices that depend on
> WRITE_POINTER if the machine type lacks fw_cfg DMA:
> 
> $ qemu-system-x86_64 -M pc-q35-2.4 -device vmgenid
> 
> qemu-system-x86_64: -device vmgenid: vmgenid requires DMA write
> support in fw_cfg, which this machine type does not provide)
> 
> Short-circuit an empty S3_CONTEXT in TransferS3ContextToBootScript() by
> dropping S3_CONTEXT on the floor. This is compatible with the current
> contract of the function as it constitutes a transfer of ownership.
> 
> Regression (2) was found and reported by Dhiru Kholia as an OSX guest boot
> failure on the "pc-q35-2.4" machine type:
> 
> http://mid.mail-archive.com/CANO7a6x6EaWNZ8y=MvLU=w_ljrlxsero3nmsghvaye0aucc...@mail.gmail.com
> 
> Dhiru bisected the issue to commit 805762252733.
> 
> Cc: Dhiru Kholia 
> Cc: Jordan Justen 
> Fixes: df73df138d9d53f7f7570f4fe97a6cde941a2656
> Fixes: 805762252733bb67bc5157f0137c64e010724c77
> Reported-by: Dhiru Kholia 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/AcpiPlatformDxe/BootScript.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/AcpiPlatformDxe/BootScript.c 
> b/OvmfPkg/AcpiPlatformDxe/BootScript.c
> index a7d2f9e38f57..1a188bfd615c 100644
> --- a/OvmfPkg/AcpiPlatformDxe/BootScript.c
> +++ b/OvmfPkg/AcpiPlatformDxe/BootScript.c
> @@ -249,7 +249,10 @@ FatalError:
>  because the ownership of S3Context has been 
> transfered.
>  
>@retval EFI_SUCCESS The translation of S3Context to ACPI S3 Boot Script
> -  opcodes has been successfully executed or queued.
> +  opcodes has been successfully executed or queued. (This
> +  includes the case when S3Context was empty on input and
> +  no ACPI S3 Boot Script opcodes have been necessary to
> +  produce.)
>  
>@return Error codes from underlying functions.
>  **/
> @@ -260,6 +263,11 @@ TransferS3ContextToBootScript (
>  {
>RETURN_STATUS Status;
>  
> +  if (S3Context->Used == 0) {
> +ReleaseS3Context (S3Context);
> +return EFI_SUCCESS;
> +  }
> +
>Status = QemuFwCfgS3CallWhenBootScriptReady (AppendFwCfgBootScript,
>   S3Context, sizeof (SCRATCH_BUFFER));
>return (EFI_STATUS)Status;

Tested-by: Dhiru Kholia 

I can now successfully boot macOS 10.12.5 + Clover combination with
"pc-q35-2.4" machine type with this patch applied on top of commit
1fceaddb12.

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

Re: [edk2] Unable to locate EFI_HII_POPUP_PROTOCOL in latest edk2

2017-08-06 Thread Dong, Eric 
Hi Amit,

This protocol was added in 2.7 version. We are still updating code to implement 
it. When we ready, we will submit patch in this mail list for this protocol. 
You can check it later.

Thanks,
Eric
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Amit 
kumar
Sent: Friday, August 4, 2017 9:45 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Unable to locate EFI_HII_POPUP_PROTOCOL in latest edk2


Hi ,

I downloaded a fresh copy of ekd2 from git but i am unable to find HII Popup 
Protocol described in UEFI 2.7 34.7 HII Popup Protocol.

Can somebody point me the location of this protocol ?

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

[edk2] [Patch] BaseTools: Fix Segmentation fault: 11 when build AppPkg with XCODE5

2017-08-06 Thread Yonghong Zhu 
it is a bug in mtoc setting the size of the debug directory entry to
the size of the .debug section, not the size of the
EFI_IMAGE_DEBUG_DIRECTORY_ENTRY. It was causing a loop to iterate and
get bogus EFI_IMAGE_DEBUG_DIRECTORY_ENTRY data and pass that to
memset() and boom.

Cc: Liming Gao 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish 
---
 BaseTools/Source/C/GenFw/GenFw.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/C/GenFw/GenFw.c b/BaseTools/Source/C/GenFw/GenFw.c
index 246deb0..af60c92 100644
--- a/BaseTools/Source/C/GenFw/GenFw.c
+++ b/BaseTools/Source/C/GenFw/GenFw.c
@@ -2813,10 +2813,11 @@ Returns:
   //
   // Get Debug, Export and Resource EntryTable RVA address.
   // Resource Directory entry need to review.
   //
   Optional32Hdr = (EFI_IMAGE_OPTIONAL_HEADER32 *) ((UINT8*) FileHdr + sizeof 
(EFI_IMAGE_FILE_HEADER));
+  Optional64Hdr = (EFI_IMAGE_OPTIONAL_HEADER64 *) ((UINT8*) FileHdr + sizeof 
(EFI_IMAGE_FILE_HEADER));
   if (Optional32Hdr->Magic == EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC) {
 SectionHeader = (EFI_IMAGE_SECTION_HEADER *) ((UINT8 *) Optional32Hdr +  
FileHdr->SizeOfOptionalHeader);
 if (Optional32Hdr->NumberOfRvaAndSizes > EFI_IMAGE_DIRECTORY_ENTRY_EXPORT 
&& \
 Optional32Hdr->DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_EXPORT].Size != 
0) {
   ExportDirectoryEntryRva = 
Optional32Hdr->DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress;
@@ -2833,11 +2834,10 @@ Returns:
 Optional32Hdr->DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_DEBUG].Size = 0;
 
Optional32Hdr->DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_DEBUG].VirtualAddress = 
0;
   }
 }
   } else {
-Optional64Hdr = (EFI_IMAGE_OPTIONAL_HEADER64 *) ((UINT8*) FileHdr + sizeof 
(EFI_IMAGE_FILE_HEADER));
 SectionHeader = (EFI_IMAGE_SECTION_HEADER *) ((UINT8 *) Optional64Hdr +  
FileHdr->SizeOfOptionalHeader);
 if (Optional64Hdr->NumberOfRvaAndSizes > EFI_IMAGE_DIRECTORY_ENTRY_EXPORT 
&& \
 Optional64Hdr->DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_EXPORT].Size != 
0) {
   ExportDirectoryEntryRva = 
Optional64Hdr->DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress;
 }
@@ -2907,10 +2907,20 @@ Returns:
   RsdsEntry->Unknown  = 0;
   RsdsEntry->Unknown2 = 0;
   RsdsEntry->Unknown3 = 0;
   RsdsEntry->Unknown4 = 0;
   RsdsEntry->Unknown5 = 0;
+} else if (RsdsEntry->Signature == CODEVIEW_SIGNATURE_MTOC) {
+  // MTOC sets DebugDirectoryEntrySize to size of the .debug section, 
so fix it.
+  if (!ZeroDebugFlag) {
+if (Optional32Hdr->Magic == EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC) {
+  
Optional32Hdr->DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_DEBUG].Size = sizeof 
(EFI_IMAGE_DEBUG_DIRECTORY_ENTRY);
+} else {
+  
Optional64Hdr->DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_DEBUG].Size = sizeof 
(EFI_IMAGE_DEBUG_DIRECTORY_ENTRY);
+}
+  }
+  break;
 }
   }
 }
   }
 
-- 
2.6.1.windows.1

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

Re: [edk2] [PATCH 05/11] ShellPkg/UefiShellLevel2CommandsLib: Remove unnecessary EFIAPI

2017-08-06 Thread Ni, Ruiyu 
Because an internal function doesn't need to have EFIAPI prefix.
I think a proper fix is to change both BaseLib and UefiShellLevel2CommandsLib 
to add prefix to the function name.
e.g.: ShellLevel2CommandsLibCharToUpper, BaseLibCharToUpper.

And I am also surprised that BaseLib's version also has the EFIAPI prefix.
---BaseLib/String.c---
   CHAR16
   EFIAPI
   InternalCharToUpper (
 IN  CHAR16Char
 )

Copying Mike for comments.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Palmer, Thomas
> Sent: Friday, August 4, 2017 3:07 AM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 05/11] ShellPkg/UefiShellLevel2CommandsLib:
> Remove unnecessary EFIAPI
> 
> Ruiyu,
>   Sorry for replying to old patch, I was cleaning out some old
> sandboxes when I stumbled onto this issue.
> 
>   Why is EFIAPI removed from InternalCharToUpper in
> UefiShellLevel2CommandsLib.c?  It is present in both BaseLibInternals.h and
> String.c.   Without EFIAPI, GCC builds of this function can fail
> 
> 
> Regards,
> 
> Thomas Palmer
> 
> "I have only made this letter longer because I have not had the time to make
> it shorter" - Blaise Pascal
> 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ruiyu Ni
> Sent: Friday, September 30, 2016 3:18 AM
> To: edk2-devel@lists.01.org
> Cc: Ruiyu Ni ; Jaben Carsey ;
> Chen A Chen 
> Subject: [edk2] [PATCH 05/11] ShellPkg/UefiShellLevel2CommandsLib:
> Remove unnecessary EFIAPI
> 
> From: Ruiyu Ni 
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Chen A Chen 
> Cc: Jaben Carsey 
> Cc: Ruiyu Ni 
> ---
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c |  4 
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c   |  2 --
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c |  5 -
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Map.c| 12 
> 
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c |  7 ---
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Parse.c  |  3 ---
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c |  3 ---
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Set.c|  1 -
>  ShellPkg/Library/UefiShellLevel2CommandsLib/TimeDate.c   |  4 
>  .../UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c  |  5 -
>   .../UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h  |  6 --
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Vol.c|  1 -
>  12 files changed, 53 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c
> index eb1f3b6..b8f6d31 100644
> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c
> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c
> @@ -35,7 +35,6 @@
>@retval SHELL_OUT_OF_RESOURCESa memory allocation failed
>  **/
>  SHELL_STATUS
> -EFIAPI
>  ValidateAndCopyFiles(
>IN CONST EFI_SHELL_FILE_INFO  *FileList,
>IN CONST CHAR16   *DestDir,
> @@ -58,7 +57,6 @@ ValidateAndCopyFiles(
>@retval SHELL_SUCCESS   The source file was copied to the destination
>  **/
>  SHELL_STATUS
> -EFIAPI
>  CopySingleFile(
>IN CONST CHAR16 *Source,
>IN CONST CHAR16 *Dest,
> @@ -291,7 +289,6 @@ CopySingleFile(
>@retval SHELL_OUT_OF_RESOURCESa memory allocation failed
>  **/
>  SHELL_STATUS
> -EFIAPI
>  ValidateAndCopyFiles(
>IN CONST EFI_SHELL_FILE_INFO  *FileList,
>IN CONST CHAR16   *DestDir,
> @@ -576,7 +573,6 @@ ValidateAndCopyFiles(
>@retval SHELL_SUCCESS The operation was successful.
>  **/
>  SHELL_STATUS
> -EFIAPI
>  ProcessValidateAndCopyFiles(
>IN   EFI_SHELL_FILE_INFO  *FileList,
>IN CONST CHAR16   *DestDir,
> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
> index ff7c818..322d510 100644
> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
> @@ -28,7 +28,6 @@
> 
>  **/
>  EFI_STATUS
> -EFIAPI
>  ConnectAllEfi (
>VOID
>)
> @@ -74,7 +73,6 @@ ConnectAllEfi (
>@retval EFI_OUT_OF_RESOURCES  there was insufficient memory  **/
> EFI_STATUS -EFIAPI  LoadDriver(
>IN CONST CHAR16   *FileName,
>IN CONST BOOLEAN  Connect
> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> index 9b4c452..52ae18f 100644
> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> @@ -22,7 +22,6 @@
>@param[in] TheList   a list of

[edk2] [PATCH 2/2] MdeModulePkg/NvmExpressDxe: Notify NVME HW when system reset happens

2017-08-06 Thread Ruiyu Ni 
Per NVM Express Spec, software should notify NVME HW when shutdown
occurs.

The host should set the Shutdown Notification (CC.SHN) field to 01b
to indicate a normal shutdown operation. The controller indicates
when shutdown processing is completed by updating the Shutdown Status
(CSTS.SHST) field to 10b.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Hao A Wu 
---
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c|   7 +-
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h|  23 ++-
 .../Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf|   3 +-
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 181 -
 4 files changed, 210 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
index de5c2a05ea..571c2e1b78 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
@@ -2,7 +2,7 @@
   NvmExpressDxe driver is used to manage non-volatile memory subsystem which 
follows
   NVM Express specification.
 
-  Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2013 - 2017, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -1046,6 +1046,8 @@ NvmExpressDriverBindingStart (
 if (EFI_ERROR (Status)) {
   goto Exit;
 }
+
+NvmeRegisterShutdownNotification ();
   } else {
 Status = gBS->OpenProtocol (
 Controller,
@@ -1239,6 +1241,9 @@ NvmExpressDriverBindingStop (
   This->DriverBindingHandle,
   Controller
   );
+
+NvmeUnregisterShutdownNotification ();
+
 return EFI_SUCCESS;
   }
 
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
index fa4a34ab53..ad0d9b8966 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
@@ -3,7 +3,7 @@
   NVM Express specification.
 
   (C) Copyright 2016 Hewlett Packard Enterprise Development LP
-  Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2013 - 2017, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -721,4 +722,24 @@ NvmeDumpStatus (
   IN NVME_CQ *Cq
   );
 
+/**
+  Register the shutdown notification through the ResetNotification protocol.
+
+  Register the shutdown notification when mNvmeControllerNumber increased from 
0 to 1.
+**/
+VOID
+NvmeRegisterShutdownNotification (
+  VOID
+  );
+
+/**
+  Unregister the shutdown notification through the ResetNotification protocol.
+
+  Unregister the shutdown notification when mNvmeControllerNumber decreased 
from 1 to 0.
+**/
+VOID
+NvmeUnregisterShutdownNotification (
+  VOID
+  );
+
 #endif
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
index 3270042e02..4918696104 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
@@ -4,7 +4,7 @@
 #  NvmExpressDxe driver is used to manage non-volatile memory subsystem which 
follows
 #  NVM Express specification.
 #
-#  Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2013 - 2017, Intel Corporation. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -71,6 +71,7 @@ [Protocols]
   gEfiDiskInfoProtocolGuid## BY_START
   gEfiStorageSecurityCommandProtocolGuid  ## BY_START
   gEfiDriverSupportedEfiVersionProtocolGuid   ## PRODUCES
+  gEfiResetNotificationProtocolGuid   ## CONSUMES
 
 # [Event]
 # EVENT_TYPE_RELATIVE_TIMER ## SOMETIMES_CONSUMES
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
index ad6cdb15a5..ea48e78827 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
@@ -2,7 +2,7 @@
   NvmExpressDxe driver is used to manage non-volatile memory subsystem which 
follows
   NVM Express specification.
 
-  Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2013 - 2017, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and

[edk2] [PATCH 1/2] MdePkg/Nvme: Add NVME shutdown notification related macros

2017-08-06 Thread Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Hao A Wu 
---
 MdePkg/Include/IndustryStandard/Nvme.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/IndustryStandard/Nvme.h 
b/MdePkg/Include/IndustryStandard/Nvme.h
index 85649f0d3f..d0bd354139 100644
--- a/MdePkg/Include/IndustryStandard/Nvme.h
+++ b/MdePkg/Include/IndustryStandard/Nvme.h
@@ -2,6 +2,7 @@
   Definitions based on NVMe spec. version 1.1.
 
   (C) Copyright 2016 Hewlett Packard Enterprise Development LP
+  Copyright (c) 2017, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -86,6 +87,8 @@ typedef struct {
   UINT8  Iocqes:4;   // I/O Completion Queue Entry Size
   UINT8  Rsvd2;
 } NVME_CC;
+#define NVME_CC_SHN_NORMAL_SHUTDOWN1
+#define NVME_CC_SHN_ABRUPT_SHUTDOWN2
 
 //
 // 3.1.6 Offset 1Ch: CSTS - Controller Status
@@ -97,7 +100,8 @@ typedef struct {
   UINT32 Nssro:1;// NVM Subsystem Reset Occurred
   UINT32 Rsvd1:27;
 } NVME_CSTS;
-
+#define NVME_CSTS_SHST_SHUTDOWN_OCCURRING 1
+#define NVME_CSTS_SHST_SHUTDOWN_COMPLETED 2
 //
 // 3.1.8 Offset 24h: AQA - Admin Queue Attributes
 //
-- 
2.12.2.windows.2

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

[edk2] [PATCH 0/2] Notify NVME HW when system reset happens

2017-08-06 Thread Ruiyu Ni 
Per NVM Express Spec, software should notify NVME HW when shutdown
occurs.

The host should set the Shutdown Notification (CC.SHN) field to 01b
to indicate a normal shutdown operation. The controller indicates
when shutdown processing is completed by updating the Shutdown Status
(CSTS.SHST) field to 10b.

Ruiyu Ni (2):
  MdePkg/Nvme: Add NVME shutdown notification related macros
  MdeModulePkg/NvmExpressDxe: Notify NVME HW when system reset happens

 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c|   7 +-
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h|  23 ++-
 .../Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf|   3 +-
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 181 -
 MdePkg/Include/IndustryStandard/Nvme.h |   6 +-
 5 files changed, 215 insertions(+), 5 deletions(-)

-- 
2.12.2.windows.2

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