Re: [edk2] UEFI App embedded on another uefi app

[Ni, Ruiyu]

Your requirement doesn't need any PCD knowledge.
I think all you need to do:
1. Study to know how to embedded a binary to your PE image
a). Either by converting that binary to a big C array
b). Or by creating a new resource section, including that binary
2. In your entrypoint of the wrapper PE image,
a). either decompressing that C array to a bigger buffer containing PE image
b). or extracting the binary from PE section, decompressing it.

3. In your entrypoint of the wrapper PE image,
Use BS.LoadImage/StartImage to execute that  PE image.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Rafael Machado
> Sent: Thursday, December 21, 2017 1:32 AM
> To: Ni, Ruiyu <ruiyu...@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] UEFI App embedded on another uefi app
> 
> Hi Ruiyu
> 
> Thanks for the answer.
> The case is similar. The only difference is that we are not allowed to use
> some external code besides the UDK references and modules.
> 
> This is why we're trying to find a way to embed a binary on another one.
> 
> I did some tests here but I have a question.
> 
> Is it possible to create a PCD that points to an embedded binary?
> For example. At the MdeModulePkg/Application/HelloWorld/HelloWorld.c
> we have some example of how to access a string that is declared at the .dec
> and and filled at the .uni:
> 
> Print ((CHAR16*)PcdGetPtr (PcdHelloWorldPrintString));
> 
> I was able to compile this application adding the Logo.bmp to the
> HelloWorld.inf file, just to check how this would work.
> 
> So the question is. How could I create a PCD that points to a binary that is
> added to a .efi?
> 
> Based on the code I believe the only what to do that is creating a .fdf and
> setting the PCD to point to the binary, on the same way it's done with the:
> 
> MdeModulePkg\Logo\Logo.inf
> CorebootPayloadPkg\CorebootPayloadPkg.fdf
> 
> The problem is that at our case, we need to have a single .efi that has an
> embedded binary.
> 
> Any idea on how to do that? (Not sure if this is to intrusive for the PE 
> format.
> Still learning this)
> 
> Thanks and Regards
> Rafael R. Machado
> 
> Em seg, 18 de dez de 2017 às 03:13, Ni, Ruiyu <ruiyu...@intel.com> escreveu:
> 
> > On 12/15/2017 7:45 PM, Rafael Machado wrote:
> > > Hi Everyone.
> > >
> > > I have a limited space problem at a project.
> > > To solve this we had an idea, but would like to ask to you before
> > expending
> > > time on trying to do it, due to some tight schedule. (We know that
> > > the
> > best
> > > is to try before ask, but we do not have time for that now. Sorry
> > > for
> > that.)
> > >
> > > The idea is to create a kind of DecompressorApp.efi, that uses
> > > EFI_DECOMPRESS_PROTOCOL
> > >
> > > During the compilation process of the application the tasks would be:
> > >
> > > - Compile App.efi
> > > - Compress App.efi, generating the App.efi.compressed (using
> > > tianoCompress.exe)
> > > - Compile the Decompressor.efi app (with the App.efi.compressed
> embedded)
> > > - The idea to do this is to add the compressed app as a
> > > Binary at the DecompressorApp.efi .inf file using the [Binaries] tag
> > >
> > >
> > > So during the entrypoint of the Decompressor.efi app, the
> > > application
> > will
> > > need to copy the compressed part of the app (App.efi.compressed), to
> > > a buffer, and after that this buffer will be decompressed using the
> > > EFI_DECOMPRESS_PROTOCOL. Finally the execution control is passed to
> > > the App.efi decompressed (not sure how to do that yet).
> > >
> > > So the questions we have for know are:
> > >
> > > - How to detect the App.efi.compressed insyde the loaded app, so we
> > > can have an address to decompress
> > Is your usage case similar to the upx?
> >
> > If the App.efi is compressed and embedded as binary in the
> > application, the application itself should know that the binary should
> > be decompressed and executed.
> >
> >
> > > - How to pass the application executions control to another app,
> > > that is
> > in
> > > a buffer (not sure if this can be done with the EFI Boot Service
> > > LoadImage(), since this buffer does not have a valid file device
> > > path)
> > Yes you could use LoadImage(). The API also accepts a PE buffer to load.
> > Then you could use StartImage() to execute the PE buff

Re: [edk2] [Patch] ShellPkg: Fix a build error in Ping6 shell command.

[Ni, Ruiyu]

On 12/18/2017 5:29 PM, fanwang2 wrote:

From: Wang Fan <fan.w...@intel.com>

Last check in involved a build error, this patch is to
fix this issue.

Cc: Ruiyu Ni <ruiyu...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wang Fan <fan.w...@intel.com>
---
  ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c 
b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
index fa27c82..2cdf484 100644
--- a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
+++ b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
@@ -764,11 +764,11 @@ Ping6CreateIpInstance (
EFI_IPv6_ADDRESS *Addr;
UINTNAddrIndex;
  
HandleBuffer  = NULL;

UnspecifiedSrc= FALSE;
-  MediaStatus   = EFI_SUCCESS
+  MediaStatus   = EFI_SUCCESS;
Ip6Sb = NULL;
IfInfo= NULL;
IfInfoSize= 0;
  
//



Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

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

Re: [edk2] UEFI App embedded on another uefi app

[Ni, Ruiyu]

On 12/15/2017 7:45 PM, Rafael Machado wrote:

Hi Everyone.

I have a limited space problem at a project.
To solve this we had an idea, but would like to ask to you before expending
time on trying to do it, due to some tight schedule. (We know that the best
is to try before ask, but we do not have time for that now. Sorry for that.)

The idea is to create a kind of DecompressorApp.efi, that
uses  EFI_DECOMPRESS_PROTOCOL

During the compilation process of the application the tasks would be:

- Compile App.efi
- Compress App.efi, generating the App.efi.compressed (using
tianoCompress.exe)
- Compile the Decompressor.efi app (with the App.efi.compressed embedded)
- The idea to do this is to add the compressed app as a Binary at
the DecompressorApp.efi .inf file using the [Binaries] tag


So during the entrypoint of the Decompressor.efi app, the application will
need to copy the compressed part of the app (App.efi.compressed), to a
buffer, and after that this buffer will be decompressed using the
EFI_DECOMPRESS_PROTOCOL. Finally the execution control is passed to the
App.efi decompressed (not sure how to do that yet).

So the questions we have for know are:

- How to detect the App.efi.compressed insyde the loaded app, so we can
have an address to decompress

Is your usage case similar to the upx?

If the App.efi is compressed and embedded as binary in the application,
the application itself should know that the binary should be
decompressed and executed.



- How to pass the application executions control to another app, that is in
a buffer (not sure if this can be done with the EFI Boot Service
LoadImage(), since this buffer does not have a valid file device path)

Yes you could use LoadImage(). The API also accepts a PE buffer to load.
Then you could use StartImage() to execute the PE buffer.
Make sure you use the correct entrypoint prototype for the PE buffer.
typedef
EFI_STATUS
(EFIAPI *EFI_IMAGE_ENTRY_POINT)(
  IN  EFI_HANDLE   ImageHandle,
  IN  EFI_SYSTEM_TABLE *SystemTable
  );



Could you help us on understanding if this is possible?

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel




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

Re: [edk2] [PATCH] UefiCpuPkg: Keep library class header file definition independent

[Ni, Ruiyu]

On 12/14/2017 4:31 PM, Song, BinX wrote:

Keep library class header file definition independent

Cc: Eric Dong 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bell Song 
---
  UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h| 7 +++
  UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c | 7 ++-
  2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h 
b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
index fc3ccda..9582ad8 100644
--- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
+++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
@@ -71,12 +71,11 @@
  #define CPU_FEATURE_APIC_TPR_UPDATE_MESSAGE (32+9)
  #define CPU_FEATURE_ENERGY_PERFORMANCE_BIAS (32+10)
  #define CPU_FEATURE_PPIN(32+11)
+#define CPU_FEATURE_PROC_TRACE  (32+12)
  //
-// Currently, CPU_FEATURE_PROC_TRACE is the MAX feature we support.
-// If you define a feature bigger than it, please also replace it
-// in RegisterCpuFeatureLibIsFeatureValid function.
+// Please keep CPU_FEATURE_MAX as the max CPU feature
  //
-#define CPU_FEATURE_PROC_TRACE  (32+12)
+#define CPU_FEATURE_MAX (32+12)

I think we need to define this CPU_FEATURE_MAX in
RegisterCpuFeaturesLib.c.

Thinking about another instance of RegisterCpuFeatureLib
that only supports features up to (32+9).
The MAX will be 32+9 for that instance.
The library class header only defines the features and
corresponding ID (32+xx).
Library instance chooses which features to support.

  
  #define CPU_FEATURE_BEFORE_ALL  BIT27

  #define CPU_FEATURE_AFTER_ALL   BIT28
diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
index 6ec26e1..911f4d0 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
@@ -97,11 +97,8 @@ RegisterCpuFeatureLibIsFeatureValid (
  
Data = Feature;

Data &= ~(CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER | CPU_FEATURE_BEFORE_ALL | 
CPU_FEATURE_AFTER_ALL);
-  //
-  // Currently, CPU_FEATURE_PROC_TRACE is the MAX feature we support.
-  // If you define a feature bigger than it, please replace it at below.
-  //
-  if (Data > CPU_FEATURE_PROC_TRACE) {
+
+  if (Data > CPU_FEATURE_MAX) {
  DEBUG ((DEBUG_ERROR, "Invalid CPU feature: 0x%x ", Feature));
  return FALSE;
}




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

Re: [edk2] [PATCH] PerformancePkg: Remove it

[Ni, Ruiyu]

On 12/14/2017 9:46 AM, Zeng, Star wrote:

Ruiyu,

Do you need to update Maintainers.txt accordingly at the same time?


Yes I will do that after the PerformancePkg is deleted.
Just would like to split the big changes into two steps:)




Thanks,
Star

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

Re: [edk2] [PATCH 1/3] MdePkg: break #defines out of Uefi/UefiMultiPhase.h

[Ni, Ruiyu]

On 12/13/2017 8:26 PM, Leif Lindholm wrote:

Turns out all .vfr files in the tree interacting with DynamicPcds
manually copy the same set of EFI_VARIABLE_* definitions, since the rest
of UefiMultiPhase.h is incompatible with VfrCompile.

Split these out into a separate header file UefiMultiPhaseDefinitions.h
in order to make it possible to include just that portion into .vfr
files. Then include that from UefiMultiPhase.h.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm 
---
  MdePkg/Include/Uefi/UefiMultiPhase.h| 23 +---
  MdePkg/Include/Uefi/UefiMultiPhaseDefinitions.h | 39 
  2 files changed, 41 insertions(+), 21 deletions(-)

diff --git a/MdePkg/Include/Uefi/UefiMultiPhase.h 
b/MdePkg/Include/Uefi/UefiMultiPhase.h
index 0dcbb1b9ee..b360c9513b 100644
--- a/MdePkg/Include/Uefi/UefiMultiPhase.h
+++ b/MdePkg/Include/Uefi/UefiMultiPhase.h
@@ -15,6 +15,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
  #ifndef __UEFI_MULTIPHASE_H__
  #define __UEFI_MULTIPHASE_H__
  
+#include "UefiMultiPhaseDefinitions.h"

+
  #include 
  ///
  /// Enumeration of memory types introduced in UEFI.
@@ -156,27 +158,6 @@ typedef struct {
  } EFI_TABLE_HEADER;
  
  ///

-/// Attributes of variable.
-///
-#define EFI_VARIABLE_NON_VOLATILE0x0001
-#define EFI_VARIABLE_BOOTSERVICE_ACCESS  0x0002
-#define EFI_VARIABLE_RUNTIME_ACCESS  0x0004
-///
-/// This attribute is identified by the mnemonic 'HR'
-/// elsewhere in this specification.
-///
-#define EFI_VARIABLE_HARDWARE_ERROR_RECORD   0x0008
-///
-/// Attributes of Authenticated Variable
-///
-#define EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS   0x0020
-#define EFI_VARIABLE_APPEND_WRITE0x0040
-///
-/// NOTE: EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS is deprecated and should be 
considered reserved.
-///
-#define EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS  0x0010
-
-///
  /// AuthInfo is a WIN_CERTIFICATE using the wCertificateType
  /// WIN_CERTIFICATE_UEFI_GUID and the CertType
  /// EFI_CERT_TYPE_RSA2048_SHA256_GUID. If the attribute specifies
diff --git a/MdePkg/Include/Uefi/UefiMultiPhaseDefinitions.h 
b/MdePkg/Include/Uefi/UefiMultiPhaseDefinitions.h
new file mode 100644
index 00..df55a92dfa
--- /dev/null
+++ b/MdePkg/Include/Uefi/UefiMultiPhaseDefinitions.h
@@ -0,0 +1,39 @@
+/** @file
+  This includes some definitions introduced in UEFI that will be used in both 
PEI and DXE phases.
+
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
+This program and the accompanying materials are licensed and made available 
under
+the terms and conditions of the BSD License that accompanies this distribution.
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __UEFI_MULTIPHASE_DEFS_H__
+#define __UEFI_MULTIPHASE_DEFS_H__
+
+///
+/// Attributes of variable.
+///
+#define EFI_VARIABLE_NON_VOLATILE0x0001
+#define EFI_VARIABLE_BOOTSERVICE_ACCESS  0x0002
+#define EFI_VARIABLE_RUNTIME_ACCESS  0x0004
+///
+/// This attribute is identified by the mnemonic 'HR'
+/// elsewhere in this specification.
+///
+#define EFI_VARIABLE_HARDWARE_ERROR_RECORD   0x0008
+///
+/// Attributes of Authenticated Variable
+///
+#define EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS   0x0020
+#define EFI_VARIABLE_APPEND_WRITE0x0040
+///
+/// NOTE: EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS is deprecated and should be 
considered reserved.
+///
+#define EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS  0x0010
+
+#endif


Can we just move the definitions to UefiBaseTypes.h?
Even vfrcompiler still complains, the syntax enhancement to
vfrcompiler should be simple.

I personally do not like creating more and more files.

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

Re: [edk2] [PATCH V2] UefiCpuPkg: Check invalid RegisterCpuFeature parameter

[Ni, Ruiyu]

On 12/13/2017 4:44 PM, Laszlo Ersek wrote:

On 12/13/17 03:35, Song, BinX wrote:

V2:
Update function name, add more detail description.
V1:
Check and assert invalid RegisterCpuFeature function parameter

Cc: Eric Dong 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bell Song 
---
  .../Include/Library/RegisterCpuFeaturesLib.h   |  5 
  .../RegisterCpuFeaturesLib.c   | 29 ++
  2 files changed, 34 insertions(+)

diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h 
b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
index 9331e49..fc3ccda 100644
--- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
+++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
@@ -71,6 +71,11 @@
  #define CPU_FEATURE_APIC_TPR_UPDATE_MESSAGE (32+9)
  #define CPU_FEATURE_ENERGY_PERFORMANCE_BIAS (32+10)
  #define CPU_FEATURE_PPIN(32+11)
+//
+// Currently, CPU_FEATURE_PROC_TRACE is the MAX feature we support.
+// If you define a feature bigger than it, please also replace it
+// in RegisterCpuFeatureLibIsFeatureValid function.
+//
  #define CPU_FEATURE_PROC_TRACE  (32+12)
  
  #define CPU_FEATURE_BEFORE_ALL  BIT27

diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
index dd6a82b..6ec26e1 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
@@ -81,6 +81,34 @@ DumpCpuFeature (
  }
  
  /**

+  Determines if the CPU feature is valid.
+
+  @param[in]  FeaturePointer to CPU feature
+
+  @retval TRUE  The CPU feature is valid.
+  @retval FALSE The CPU feature is invalid.
+**/
+BOOLEAN
+RegisterCpuFeatureLibIsFeatureValid (
+  IN UINT32Feature
+  )
+{
+  UINT32  Data;
+
+  Data = Feature;
+  Data &= ~(CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER | CPU_FEATURE_BEFORE_ALL | 
CPU_FEATURE_AFTER_ALL);
+  //
+  // Currently, CPU_FEATURE_PROC_TRACE is the MAX feature we support.
+  // If you define a feature bigger than it, please replace it at below.
+  //
+  if (Data > CPU_FEATURE_PROC_TRACE) {
+DEBUG ((DEBUG_ERROR, "Invalid CPU feature: 0x%x ", Feature));
+return FALSE;
+  }
+  return TRUE;
+}
+
+/**
Determines if the feature bit mask is in dependent CPU feature bit mask 
buffer.
  
@param[in]  FeatureMaskPointer to CPU feature bit mask

@@ -444,6 +472,7 @@ RegisterCpuFeature (
  
VA_START (Marker, InitializeFunc);

Feature = VA_ARG (Marker, UINT32);
+  ASSERT (RegisterCpuFeatureLibIsFeatureValid(Feature));
while (Feature != CPU_FEATURE_END) {
  ASSERT ((Feature & (CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER))
  != (CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER));



The consensus thus far seems to be that we should not add a separate
_MAX macro for this purpose. I don't understand why -- in my opinion it
would be easier to update the macro in one place only.

Now, I realize we have a library class header file here, and a library
instance. Those things are separate; it is conceivable that another
library instance is developed independently, and thus we should not tie
the MAX feature of *all* library instances to the same central class header.

However, this separation is already being violated in this patch: the
RegisterCpuFeatureLibIsFeatureValid() function is an implementation
detail of the (currently only one) library instance. Thus, the lib class
header should not refer to it, even in a comment.

So, I don't understand why we can't just add a _MAX macro. The central
library instance could use _MAX; all other (out of tree) instances would
not use _MAX.



I do not understand either:)
But if the change doesn't expose more interfaces (_MAX in this case), I
feel safe because we can change much freely in future.


Anyway, this doesn't mean the patch is not correct.

Acked-by: Laszlo Ersek 

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




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

Re: [edk2] [PATCH V2] UefiCpuPkg: Check invalid RegisterCpuFeature parameter

[Ni, Ruiyu]

On 12/13/2017 10:35 AM, Song, BinX wrote:

V2:
Update function name, add more detail description.
V1:
Check and assert invalid RegisterCpuFeature function parameter

Cc: Eric Dong <eric.d...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bell Song <binx.s...@intel.com>
---
  .../Include/Library/RegisterCpuFeaturesLib.h   |  5 
  .../RegisterCpuFeaturesLib.c   | 29 ++
  2 files changed, 34 insertions(+)

diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h 
b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
index 9331e49..fc3ccda 100644
--- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
+++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
@@ -71,6 +71,11 @@
  #define CPU_FEATURE_APIC_TPR_UPDATE_MESSAGE (32+9)
  #define CPU_FEATURE_ENERGY_PERFORMANCE_BIAS (32+10)
  #define CPU_FEATURE_PPIN(32+11)
+//
+// Currently, CPU_FEATURE_PROC_TRACE is the MAX feature we support.
+// If you define a feature bigger than it, please also replace it
+// in RegisterCpuFeatureLibIsFeatureValid function.
+//
  #define CPU_FEATURE_PROC_TRACE  (32+12)
  
  #define CPU_FEATURE_BEFORE_ALL  BIT27

diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
index dd6a82b..6ec26e1 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
@@ -81,6 +81,34 @@ DumpCpuFeature (
  }
  
  /**

+  Determines if the CPU feature is valid.
+
+  @param[in]  FeaturePointer to CPU feature
+
+  @retval TRUE  The CPU feature is valid.
+  @retval FALSE The CPU feature is invalid.
+**/
+BOOLEAN
+RegisterCpuFeatureLibIsFeatureValid (
+  IN UINT32Feature
+  )
+{
+  UINT32  Data;
+
+  Data = Feature;
+  Data &= ~(CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER | CPU_FEATURE_BEFORE_ALL | 
CPU_FEATURE_AFTER_ALL);
+  //
+  // Currently, CPU_FEATURE_PROC_TRACE is the MAX feature we support.
+  // If you define a feature bigger than it, please replace it at below.
+  //
+  if (Data > CPU_FEATURE_PROC_TRACE) {
+DEBUG ((DEBUG_ERROR, "Invalid CPU feature: 0x%x ", Feature));
+return FALSE;
+  }
+  return TRUE;
+}
+
+/**
Determines if the feature bit mask is in dependent CPU feature bit mask 
buffer.
  
@param[in]  FeatureMaskPointer to CPU feature bit mask

@@ -444,6 +472,7 @@ RegisterCpuFeature (
  
VA_START (Marker, InitializeFunc);

Feature = VA_ARG (Marker, UINT32);
+  ASSERT (RegisterCpuFeatureLibIsFeatureValid(Feature));
while (Feature != CPU_FEATURE_END) {
  ASSERT ((Feature & (CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER))
  != (CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER));


Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

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

Re: [edk2] [PATCH] UefiCpuPkg: Check invalid RegisterCpuFeature parameter

[Ni, Ruiyu]

> -Original Message-
> From: Song, BinX
> Sent: Monday, December 11, 2017 6:00 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Cc: ler...@redhat.com; Dong, Eric <eric.d...@intel.com>
> Subject: RE: [edk2] [PATCH] UefiCpuPkg: Check invalid RegisterCpuFeature
> parameter
> 
> Hi Ray,
> 
> Below is my opinions for your 2 questions:
> 1. Can we rename this function name to
> "RegisterCpuFeatureLibIsFeatureValid"?
> [Bell]: In content of RegisterCpuFeaturesLib.c, there is a function named
> IsBitMaskMatchCheck(), it's my function's base, they have similar function - a
> small valid/invalid check, So I think it is better to keep them align.
The original function name IsCheck() is not good. Please do not follow the
same naming style. 

> 2. Can we just say "CPU_FEATURE_PROC_TRACE" is the MAX feature we
> support?
> [Bell]: Discussed with Eric before, we should not define this as a MAX feature
> for future extension purpose.
I didn't mean to define a new MAX macro.
You just need to update the comments. 
> 
> Best Regards,
> Bell Song
> 
> 
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Monday, December 11, 2017 5:40 PM
> > To: Song, BinX <binx.s...@intel.com>; edk2-devel@lists.01.org
> > Cc: ler...@redhat.com; Dong, Eric <eric.d...@intel.com>
> > Subject: Re: [edk2] [PATCH] UefiCpuPkg: Check invalid
> > RegisterCpuFeature parameter
> >
> > On 12/11/2017 4:16 PM, Song, BinX wrote:
> > > Check and assert invalid RegisterCpuFeature function parameter
> > >
> > > Cc: Eric Dong <eric.d...@intel.com>
> > > Cc: Laszlo Ersek <ler...@redhat.com>
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Bell Song <binx.s...@intel.com>
> > > ---
> > >   .../Include/Library/RegisterCpuFeaturesLib.h   |  4 
> > >   .../RegisterCpuFeaturesLib.c   | 28
> ++
> > >   2 files changed, 32 insertions(+)
> > >
> > > diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > > index 9331e49..54244cd 100644
> > > --- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > > +++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > > @@ -72,6 +72,10 @@
> > >   #define CPU_FEATURE_ENERGY_PERFORMANCE_BIAS (32+10)
> > >   #define CPU_FEATURE_PPIN(32+11)
> > > +//
> > > +// When you add new CPU features, please also replace the minor CPU
> > feature
> > > +// with the max CPU feature in the IsFeatureValidCheck() function.
> > > +//
> > >   #define CPU_FEATURE_PROC_TRACE  (32+12)
> > >
> > >   #define CPU_FEATURE_BEFORE_ALL  BIT27
> > >   #define CPU_FEATURE_AFTER_ALL   BIT28
> > > diff --git
> > a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> > b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> > > index dd6a82b..f75d900 100644
> > > ---
> > a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> > > +++
> > b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> > > @@ -81,6 +81,33 @@ DumpCpuFeature (
> > >   }
> > >
> > >   /**
> > > +  Determines if the CPU feature is valid.
> > > +
> > > +  @param[in]  FeaturePointer to CPU feature
> > > +
> > > +  @retval TRUE  The CPU feature is valid.
> > > +  @retval FALSE The CPU feature is invalid.
> > > +**/
> > > +BOOLEAN
> > > +IsFeatureValidCheck (
> > Can we rename this function name to
> > "RegisterCpuFeatureLibIsFeatureValid"?
> >
> >
> > > +  IN UINT32Feature
> > > +  )
> > > +{
> > > +  UINT32  Data;
> > > +
> > > +  Data = Feature;
> > > +  Data &= ~(CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER |
> > CPU_FEATURE_BEFORE_ALL | CPU_FEATURE_AFTER_ALL);
> > > +  //
> > > +  // Please replace CPU feature below with the MAX one if have.
> > Can we just say "CPU_FEATURE_PROC_TRACE" is the MAX feature we
> > support?
> >
> >
> > > +  //
> > > +  if (Data > CPU_FEATURE_PROC_TRACE) {
> > > +DEBUG ((DEBUG_ERROR, "Invalid CPU feature: 0x%x ", Feature));
> > > +return FALSE;
> > > +  }
> > > +  return TRUE;
> > > +}
> > > +
> > > +/**
> > > Determines if the feature bit mask is in dependent CPU feature
> > > bit mask
> > buffer.
> > >
> > > @param[in]  FeatureMaskPointer to CPU feature bit mask
> > > @@ -444,6 +471,7 @@ RegisterCpuFeature (
> > >
> > > VA_START (Marker, InitializeFunc);
> > > Feature = VA_ARG (Marker, UINT32);
> > > +  ASSERT (IsFeatureValidCheck(Feature));
> > > while (Feature != CPU_FEATURE_END) {
> > >   ASSERT ((Feature & (CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER))
> > >   != (CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER));
> > >
> >
> >
> > --
> > Thanks,
> > Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg: Check invalid RegisterCpuFeature parameter

[Ni, Ruiyu]

On 12/11/2017 4:16 PM, Song, BinX wrote:

Check and assert invalid RegisterCpuFeature function parameter

Cc: Eric Dong 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bell Song 
---
  .../Include/Library/RegisterCpuFeaturesLib.h   |  4 
  .../RegisterCpuFeaturesLib.c   | 28 ++
  2 files changed, 32 insertions(+)

diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h 
b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
index 9331e49..54244cd 100644
--- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
+++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
@@ -72,6 +72,10 @@
  #define CPU_FEATURE_ENERGY_PERFORMANCE_BIAS (32+10)
  #define CPU_FEATURE_PPIN(32+11)
+//
+// When you add new CPU features, please also replace the minor CPU feature
+// with the max CPU feature in the IsFeatureValidCheck() function.
+//
  #define CPU_FEATURE_PROC_TRACE  (32+12)

  #define CPU_FEATURE_BEFORE_ALL  BIT27
  #define CPU_FEATURE_AFTER_ALL   BIT28
diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
index dd6a82b..f75d900 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
@@ -81,6 +81,33 @@ DumpCpuFeature (
  }
  
  /**

+  Determines if the CPU feature is valid.
+
+  @param[in]  FeaturePointer to CPU feature
+
+  @retval TRUE  The CPU feature is valid.
+  @retval FALSE The CPU feature is invalid.
+**/
+BOOLEAN
+IsFeatureValidCheck (

Can we rename this function name to
"RegisterCpuFeatureLibIsFeatureValid"?



+  IN UINT32Feature
+  )
+{
+  UINT32  Data;
+
+  Data = Feature;
+  Data &= ~(CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER | CPU_FEATURE_BEFORE_ALL | 
CPU_FEATURE_AFTER_ALL);
+  //
+  // Please replace CPU feature below with the MAX one if have.

Can we just say "CPU_FEATURE_PROC_TRACE" is the MAX feature we support?



+  //
+  if (Data > CPU_FEATURE_PROC_TRACE) {
+DEBUG ((DEBUG_ERROR, "Invalid CPU feature: 0x%x ", Feature));
+return FALSE;
+  }
+  return TRUE;
+}
+
+/**
Determines if the feature bit mask is in dependent CPU feature bit mask 
buffer.
  
@param[in]  FeatureMaskPointer to CPU feature bit mask

@@ -444,6 +471,7 @@ RegisterCpuFeature (
  
VA_START (Marker, InitializeFunc);

Feature = VA_ARG (Marker, UINT32);
+  ASSERT (IsFeatureValidCheck(Feature));
while (Feature != CPU_FEATURE_END) {
  ASSERT ((Feature & (CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER))
  != (CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER));




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

Re: [edk2] [PATCH 0/3] Correct function description for ALLOCATE_BUFFER

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Zeng, Star
> Sent: Monday, December 11, 2017 2:54 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Yao, Jiewen <jiewen@intel.com>;
> Ni, Ruiyu <ruiyu...@intel.com>; Gao, Liming <liming@intel.com>; Kinney,
> Michael D <michael.d.kin...@intel.com>
> Subject: [PATCH 0/3] Correct function description for ALLOCATE_BUFFER
> 
> According to UEFI spec, DUAL_ADDRESS_CYCLE is missing in the
> EFI_UNSUPPORTED return status description for ALLOCATE_BUFFER
> interface.
> Same issue is also in IOMMU interface.
> 
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Cc: Michael D Kinney <michael.d.kin...@intel.com>
> 
> Star Zeng (3):
>   MdePkg PciIo.h: Correct function description for ALLOCATE_BUFFER
>   MdeModulePkg: Correct function description for AllocateBuffer
>   IntelSilicon: Correct function description for AllocateBuffer
> 
>  IntelSiliconPkg/Feature/VTd/IntelVTdDxe/BmDma.c | 2 +-
>  IntelSiliconPkg/Feature/VTd/IntelVTdDxe/IntelVTdDxe.c   | 2 +-
>  IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.c | 2 +-
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c  | 4 ++--
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.h  | 4 ++--
>  MdeModulePkg/Include/Ppi/IoMmu.h| 2 +-
>  MdeModulePkg/Include/Protocol/IoMmu.h   | 2 +-
>  MdePkg/Include/Protocol/PciIo.h | 4 ++--
>  8 files changed, 11 insertions(+), 11 deletions(-)
> 
> --
> 2.7.0.windows.1

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

Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate symbol

[Ni, Ruiyu]

On 12/7/2017 3:48 PM, Liming Gao wrote:

From: Michael Kinney <michael.d.kin...@intel.com>

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

The same issue is reported again by GCC. Resend this patch again.
This patch renames the duplicated function name to fix it.

The SecPeiDebugAgentLib uses the global variable
mMemoryDiscoveredNotifyList for a PPI notification on
the Memory Discovered PPI.  This same variable name is
used in the DxeIplPeim for the same PPI notification.

The XCODE5 tool chain detects this duplicate symbol
when the OVMF platform is built with the flag
-D SOURCE_DEBUG_ENABLE.

The fix is to rename this global variable in the
SecPeiDebugAgentLib library.

Cc: Andrew Fish <af...@apple.com>
Cc: Jeff Fan <jeff@intel.com>
Cc: Hao Wu <hao.a...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney <michael.d.kin...@intel.com>
Reviewed-by: Jeff Fan <jeff@intel.com>
---
  .../Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c 
b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
index b717e33..9f5223a 100644
--- 
a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
+++ 
b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
@@ -32,7 +32,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_PPI_DESCRIPTOR  
 mVectorHandoffInf
}
  };
  
-GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR mMemoryDiscoveredNotifyList[1] = {

+GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR 
mDebugAgentMemoryDiscoveredNotifyList[1] = {
{
  (EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK | 
EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
  ,
@@ -554,7 +554,7 @@ InitializeDebugAgent (
  // Register for a callback once memory has been initialized.
  // If memery has been ready, the callback funtion will be invoked 
immediately
  //
-Status = PeiServicesNotifyPpi ([0]);
+Status = PeiServicesNotifyPpi ([0]);
  if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "DebugAgent: Failed to register memory discovered 
callback function!\n"));
    CpuDeadLoop ();


Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

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

Re: [edk2] [PATCH v2 3/3] IntelFrameworkModulePkg/KeyboardDxe: Use macro to enable/disable page 0

[Ni, Ruiyu]

On 12/7/2017 1:40 PM, Jian J Wang wrote:

v2:
a. Remove unnecessary braces enclosing code passed to ACCESS_PAGE0_CODE


Current implementation uses following two methods

 EnableNullDetection()
 DisableNullDetection()

to enable/disable page 0. These two methods will check PCD
PcdNullPointerDetectionPropertyMask to know if the page 0 is disabled or not.
This is due to the fact that old GCD service doesn't provide paging related
attributes of memory block. Since this issue has been fixed, GCD services
can be used to determine the paging status of page 0. This is also make it
possible to just use a new macro

 ACCESS_PAGE0_CODE(
   
 );

to replace above methods to do the same job, which also makes code more
readability.

Cc: Liming Gao <liming@intel.com>
Cc: Michael D Kinney <michael.d.kin...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
---
  .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c   | 118 ++---
  .../Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf  |   1 -
  2 files changed, 10 insertions(+), 109 deletions(-)

diff --git a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c 
b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
index ebf03d30c1..ec525891dc 100644
--- a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
+++ b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
@@ -1732,98 +1732,6 @@ CheckKeyboardConnect (
}
  }
  
-/**

-  Disable NULL pointer detection.
-**/
-VOID
-DisableNullDetection (
-  VOID
-  )
-{
-  EFI_STATUSStatus;
-  EFI_GCD_MEMORY_SPACE_DESCRIPTOR   Desc;
-
-  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) == 0) {
-return;
-  }
-
-  //
-  // Check current capabilities and attributes
-  //
-  Status = gDS->GetMemorySpaceDescriptor (0, );
-  ASSERT_EFI_ERROR (Status);
-
-  //
-  // Try to add EFI_MEMORY_RP support if necessary
-  //
-  if ((Desc.Capabilities & EFI_MEMORY_RP) == 0) {
-Desc.Capabilities |= EFI_MEMORY_RP;
-Status = gDS->SetMemorySpaceCapabilities (0, EFI_PAGES_TO_SIZE(1),
-  Desc.Capabilities);
-ASSERT_EFI_ERROR (Status);
-if (EFI_ERROR (Status)) {
-  return;
-}
-  }
-
-  //
-  // Don't bother if EFI_MEMORY_RP is already cleared.
-  //
-  if ((Desc.Attributes & EFI_MEMORY_RP) != 0) {
-Desc.Attributes &= ~EFI_MEMORY_RP;
-Status = gDS->SetMemorySpaceAttributes (0, EFI_PAGES_TO_SIZE(1),
-Desc.Attributes);
-ASSERT_EFI_ERROR (Status);
-  } else {
-DEBUG ((DEBUG_WARN, "!!! Page 0 is supposed to be disabled !!!\r\n"));
-  }
-}
-
-/**
-   Enable NULL pointer detection.
-**/
-VOID
-EnableNullDetection (
-  VOID
-  )
-{
-  EFI_STATUSStatus;
-  EFI_GCD_MEMORY_SPACE_DESCRIPTOR   Desc;
-
-  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) == 0) {
-return;
-  }
-
-  //
-  // Check current capabilities and attributes
-  //
-  Status = gDS->GetMemorySpaceDescriptor (0, );
-  ASSERT_EFI_ERROR (Status);
-
-  //
-  // Try to add EFI_MEMORY_RP support if necessary
-  //
-  if ((Desc.Capabilities & EFI_MEMORY_RP) == 0) {
-Desc.Capabilities |= EFI_MEMORY_RP;
-Status = gDS->SetMemorySpaceCapabilities (0, EFI_PAGES_TO_SIZE(1),
-  Desc.Capabilities);
-ASSERT_EFI_ERROR (Status);
-if (EFI_ERROR (Status)) {
-  return;
-}
-  }
-
-  //
-  // Don't bother if EFI_MEMORY_RP is already set.
-  //
-  if ((Desc.Attributes & EFI_MEMORY_RP) == 0) {
-Desc.Attributes |= EFI_MEMORY_RP;
-Status = gDS->SetMemorySpaceAttributes (0, EFI_PAGES_TO_SIZE(1),
-Desc.Attributes);
-ASSERT_EFI_ERROR (Status);
-  }
-}
-
  /**
Timer event handler: read a series of key stroke from 8042
and put them into memory key buffer.
@@ -1931,16 +1839,13 @@ BiosKeyboardTimerHandler (
//   0 Right Shift pressed
  
  
-  //

-  // Disable NULL pointer detection temporarily
-  //
-  DisableNullDetection ();
-
//
// Clear the CTRL and ALT BDA flag
//
-  KbFlag1 = *((UINT8 *) (UINTN) 0x417);  // read the STATUS FLAGS 1
-  KbFlag2 = *((UINT8 *) (UINTN) 0x418); // read STATUS FLAGS 2
+  ACCESS_PAGE0_CODE (
+KbFlag1 = *((UINT8 *) (UINTN) 0x417); // read the STATUS FLAGS 1
+KbFlag2 = *((UINT8 *) (UINTN) 0x418); // read STATUS FLAGS 2
+  );
  
DEBUG_CODE (

  {
@@ -2008,15 +1913,12 @@ BiosKeyboardTimerHandler (
//
// Clear left alt and left ctrl BDA flag
//
-  KbFlag2 &= ~(KB_LEFT_ALT_PRESSED | KB_LEFT_CTRL_PRESSED);
-  *((UINT8 *) (UINTN) 0x418) = KbFlag2;
-  KbFlag1 &= ~0x0C;
-  *((UINT8 *) (UINTN) 0x417) = KbFlag1;
-
-  //
-  // Restore NUL

Re: [edk2] [PATCH v2 2/3] IntelFrameworkModulePkg/LegacyBiosDxe: Use macro to enable/disable page 0

[Ni, Ruiyu]

On 12/7/2017 1:40 PM, Jian J Wang wrote:

v2:
a. Remove unnecessary braces enclosing code passed to ACCESS_PAGE0_CODE


 EnableNullDetection()
 DisableNullDetection()

to enable/disable page 0. These two methods will check PCD
PcdNullPointerDetectionPropertyMask to know if the page 0 is disabled or not.
This is due to the fact that old GCD service doesn't provide paging related
attributes of memory block. Since this issue has been fixed, GCD services
can be used to determine the paging status of page 0. This is also make it
possible to just use a new macro

 ACCESS_PAGE0_CODE(
   
 );

to replace above methods to do the same job, which also makes code more
readability.

Cc: Liming Gao <liming@intel.com>
Cc: Michael D Kinney <michael.d.kin...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
---
  .../Csm/LegacyBiosDxe/LegacyBda.c  |  53 
  .../Csm/LegacyBiosDxe/LegacyBios.c | 135 ++---
  .../Csm/LegacyBiosDxe/LegacyBiosDxe.inf|   1 -
  .../Csm/LegacyBiosDxe/LegacyBiosInterface.h|  16 ---
  .../Csm/LegacyBiosDxe/LegacyBootSupport.c  |  80 ++--
  .../Csm/LegacyBiosDxe/LegacyPci.c  |  72 ++-
  IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c  |  51 
  7 files changed, 135 insertions(+), 273 deletions(-)

diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c 
b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c
index c6670febee..a94cba435c 100644
--- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c
+++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c
@@ -34,37 +34,36 @@ LegacyBiosInitBda (
BDA_STRUC *Bda;
UINT8 *Ebda;
  
-  DisableNullDetection ();

-
Bda   = (BDA_STRUC *) ((UINTN) 0x400);
Ebda  = (UINT8 *) ((UINTN) 0x9fc00);
  
-  ZeroMem (Bda, 0x100);

+  ACCESS_PAGE0_CODE (
+ZeroMem (Bda, 0x100);
+//
+// 640k-1k for EBDA
+//
+Bda->MemSize= 0x27f;
+Bda->KeyHead= 0x1e;
+Bda->KeyTail= 0x1e;
+Bda->FloppyData = 0x00;
+Bda->FloppyTimeout  = 0xff;
+
+Bda->KeyStart   = 0x001E;
+Bda->KeyEnd = 0x003E;
+Bda->KeyboardStatus = 0x10;
+Bda->Ebda   = 0x9fc0;
+
+//
+// Move LPT time out here and zero out LPT4 since some SCSI OPROMS
+// use this as scratch pad (LPT4 is Reserved)
+//
+Bda->Lpt1_2Timeout  = 0x1414;
+Bda->Lpt3_4Timeout  = 0x1400;
+
+  );
+
ZeroMem (Ebda, 0x400);
-  //
-  // 640k-1k for EBDA
-  //
-  Bda->MemSize= 0x27f;
-  Bda->KeyHead= 0x1e;
-  Bda->KeyTail= 0x1e;
-  Bda->FloppyData = 0x00;
-  Bda->FloppyTimeout  = 0xff;
-
-  Bda->KeyStart   = 0x001E;
-  Bda->KeyEnd = 0x003E;
-  Bda->KeyboardStatus = 0x10;
-  Bda->Ebda   = 0x9fc0;
-
-  //
-  // Move LPT time out here and zero out LPT4 since some SCSI OPROMS
-  // use this as scratch pad (LPT4 is Reserved)
-  //
-  Bda->Lpt1_2Timeout  = 0x1414;
-  Bda->Lpt3_4Timeout  = 0x1400;
-
-  *Ebda   = 0x01;
-
-  EnableNullDetection ();
+  *Ebda = 0x01;
  
return EFI_SUCCESS;

  }
diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c 
b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
index c6461f5547..fca08a8fa2 100644
--- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
+++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
@@ -786,115 +786,6 @@ ToggleEndOfDxeStatus (
return;
  }
  
-//

-// Legacy BIOS needs to access memory between 0-4095, which will cause page
-// fault exception if NULL pointer detection mechanism is enabled. Following
-// functions can be used to disable/enable NULL pointer detection before/after
-// accessing those memory.
-//
-
-/**
-   Enable NULL pointer detection.
-**/
-VOID
-EnableNullDetection (
-  VOID
-  )
-{
-  EFI_STATUSStatus;
-  EFI_GCD_MEMORY_SPACE_DESCRIPTOR   Desc;
-
-  if (((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) == 0)
-  ||
-  ((mEndOfDxe)  &&
-   ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT7|BIT0))
-== (BIT7|BIT0)))
- ) {
-return;
-  }
-
-  //
-  // Check current capabilities and attributes
-  //
-  Status = gDS->GetMemorySpaceDescriptor (0, );
-  ASSERT_EFI_ERROR (Status);
-
-  //
-  // Try to add EFI_MEMORY_RP support if necessary
-  //
-  if ((Desc.Capabilities & EFI_MEMORY_RP) == 0) {
-Desc.Capabilities |= EFI_MEMORY_RP;
-Status = gDS->SetMemorySpaceCapabilities (0, EFI_PAGES_TO_SIZE(1),
-  Desc.Capabilities);
-ASSERT_EFI_ERROR (Status);
-if (EFI_ERROR (Status)) {
-  return;
-}
-  }
-
-  //
-  // Don't bother if EFI_MEMORY_RP is already 

Re: [edk2] [PATCH v2 1/3] IntelFrameworkPkg/LegacyBios.h: Add a macro to guarantee page 0 access

[Ni, Ruiyu]

On 12/7/2017 1:40 PM, Jian J Wang wrote:

v2:
a. Fix a typo in expression in the macro ACCESS_PAGE0_CODE
b. Fix GCC49 build error


ue to the introduction of NULL pointer detection feature, page 0 will be
disabled if the feature is enabled, which will cause legacy code failed to
update legacy data in page 0. This macro is introduced to make sure the
page 0 is enabled before those code and restore the original status of it
afterwards.

Another reason to introduce this macro is to eliminate the dependency on
the PcdNullPointerDetectionPropertyMask. Because this is a new PCD, it
could cause some backward compatibility issue for some old packages.

This macro will simply check if the page 0 is disabled or not. If it's
disabled, it will enable it before code updating page 0 and disable it
afterwards. Otherwise, this macro will do nothing to page 0.

The usage of the macro will be look like (similar to DEBUG_CODE macro):

 ACCESS_PAGE0_CODE(
   
 );

Cc: Liming Gao <liming@intel.com>
Cc: Michael D Kinney <michael.d.kin...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
---
  IntelFrameworkPkg/Include/Protocol/LegacyBios.h | 34 +
  1 file changed, 34 insertions(+)

diff --git a/IntelFrameworkPkg/Include/Protocol/LegacyBios.h 
b/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
index 641f101bce..6a5f5464e7 100644
--- a/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
+++ b/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
@@ -1518,6 +1518,40 @@ struct _EFI_LEGACY_BIOS_PROTOCOL {
EFI_LEGACY_BIOS_BOOT_UNCONVENTIONAL_DEVICE  BootUnconventionalDevice;
  };
  
+//

+// Legacy BIOS needs to access memory in page 0 (0-4095), which is disabled if
+// NULL pointer detection feature is enabled. Following macro can be used to
+// enable/disable page 0 before/after accessing it.
+//
+#define ACCESS_PAGE0_CODE(statements)   \
+  do {  \
+EFI_STATUSStatus_;  \
+EFI_GCD_MEMORY_SPACE_DESCRIPTOR   Desc_;\
+\
+Desc_.Attributes = 0;   \
+Status_ = gDS->GetMemorySpaceDescriptor (0, _);\
+ASSERT_EFI_ERROR (Status_); \
+if ((Desc_.Attributes & EFI_MEMORY_RP) != 0) {  \
+  Status_ = gDS->SetMemorySpaceAttributes ( \
+  0,\
+  EFI_PAGES_TO_SIZE(1), \
+  Desc_.Attributes & ~(UINT64)EFI_MEMORY_RP \
+  );\
+  ASSERT_EFI_ERROR (Status_);   \
+}   \
+\
+statements; \


It's better to surrounded statements with {}.
So that when statements contains variable declaration, C compiler
doesn't complain.


+\
+if ((Desc_.Attributes & EFI_MEMORY_RP) != 0) {  \
+  Status_ = gDS->SetMemorySpaceAttributes ( \
+  0,\
+  EFI_PAGES_TO_SIZE(1), \
+  Desc_.Attributes  \
+  );\
+  ASSERT_EFI_ERROR (Status_);   \
+}   \
+  } while (FALSE)
+
  extern EFI_GUID gEfiLegacyBiosProtocolGuid;
  
  #endif




With the above suggested changes,
  Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

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

Re: [edk2] [PATCH v3 1/2] MdeModulePkg/DxeIpl: Mark page table as read-only

[Ni, Ruiyu]

On 12/5/2017 4:16 PM, Jian J Wang wrote:

v3:
Remove the public definition of PAGE_TABLE_POOL_HEADER but keep similar
concept locally. CpuDxe has its own page table pool.



v2:
Introduce page table pool to ease the page table memory allocation and
protection, which replaces the direct calling of AllocatePages().


This patch will set the memory pages used for page table as read-only
memory after the paging is setup. CR0.WP must set to let it take into
effect.

A simple page table memory management mechanism, page table pool concept,
is introduced to simplify the page table memory allocation and protection.
It will also help to reduce the potential recursive "split" action during
updating memory paging attributes.

The basic idea is to allocate a bunch of continuous pages of memory in
advance as one or more page table pools, and all future page tables
consumption will happen in those pool instead of system memory. If the page
pool is reserved at the boundary of 2MB page and with same size of 2MB page,
there's no page granularity "split" operation will be needed, because the
memory of new page tables (if needed) will be usually in the same page as
target page table you're working on.

And since we have centralized page tables (a few 2MB pages), it's easier
to protect them by changing their attributes to be read-only once and for
all. There's no need to apply the protection for new page tables any more
as long as the pool has free pages available.

Once current page table pool has been used up, one can allocate another 2MB
memory pool and just set this new 2MB memory block to be read-only instead of
setting the new page tables one page by one page.

Two new PCDs PcdPageTablePoolUnitSize and PcdPageTablePoolAlignment are used
to specify the size and alignment for page table pool. For IA32 processor
0x20 (2MB) is the only choice for both of them to meet the requirement of
page table pool.

Cc: Jiewen Yao <jiewen@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
---
  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h|  34 +++
  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |   8 +-
  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 301 ++-
  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h |  26 ++
  4 files changed, 365 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
index f3aabdb7e0..9dc80b1508 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
@@ -265,4 +265,38 @@ IsNullDetectionEnabled (
VOID
);
  
+/**

+  Prevent the memory pages used for page table from been overwritten.
+
+  @param[in] PageTableBaseBase address of page table (CR3).
+
+**/
+VOID
+EnablePageTableProtection (
+  IN  UINTN PageTableBase,
+  IN  BOOLEAN   Level4Paging
+  );
+
+/**
+  This API provides a way to allocate memory for page table.
+
+  This API can be called more than once to allocate memory for page tables.
+
+  Allocates the number of 4KB pages and returns a pointer to the allocated
+  buffer. The buffer returned is aligned on a 4KB boundary.
+
+  If Pages is 0, then NULL is returned.
+  If there is not enough memory remaining to satisfy the request, then NULL is
+  returned.
+
+  @param  Pages The number of 4 KB pages to allocate.
+
+  @return A pointer to the allocated buffer or NULL if allocation fails.
+
+**/
+VOID *
+AllocatePageTableMemory (
+  IN UINTN   Pages
+  );
+
  #endif
diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c 
b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
index 5649265367..13fff28e93 100644
--- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
+++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
@@ -99,7 +99,7 @@ Create4GPageTablesIa32Pae (
NumberOfPdpEntriesNeeded = (UINT32) LShiftU64 (1, (PhysicalAddressBits - 
30));
  
TotalPagesNum = NumberOfPdpEntriesNeeded + 1;

-  PageAddress = (UINTN) AllocatePages (TotalPagesNum);
+  PageAddress = (UINTN) AllocatePageTableMemory (TotalPagesNum);
ASSERT (PageAddress != 0);
  
PageMap = (VOID *) PageAddress;

@@ -149,6 +149,12 @@ Create4GPageTablesIa32Pae (
);
}
  
+  //

+  // Protect the page table by marking the memory used for page table to be
+  // read-only.
+  //
+  EnablePageTableProtection ((UINTN)PageMap, FALSE);
+
return (UINTN) PageMap;
  }
  
diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c

index 29b6205e88..4ef3521224 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -31,6 +31,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EX

Re: [edk2] [PATCH 2/3] IntelFrameworkModulePkg/LegacyBiosDxe: Use macro to enable/disable page 0

[Ni, Ruiyu]

On 12/6/2017 3:31 PM, Jian J Wang wrote:

Current implementation uses following two methods

 EnableNullDetection()
 DisableNullDetection()

to enable/disable page 0. These two methods will check PCD
PcdNullPointerDetectionPropertyMask to know if the page 0 is disabled or not.
This is due to the fact that old GCD service doesn't provide paging related
attributes of memory block. Since this issue has been fixed, GCD services
can be used to determine the paging status of page 0. This is also make it
possible to just use a new macro

 ACCESS_PAGE0_CODE(
   {
   
   }
 );

to replace above methods to do the same job, which also makes code more
readability.

Cc: Liming Gao 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
  .../Csm/LegacyBiosDxe/LegacyBda.c  |  53 
  .../Csm/LegacyBiosDxe/LegacyBios.c | 135 ++---
  .../Csm/LegacyBiosDxe/LegacyBiosDxe.inf|   1 -
  .../Csm/LegacyBiosDxe/LegacyBiosInterface.h|  16 ---
  .../Csm/LegacyBiosDxe/LegacyBootSupport.c  |  80 ++--
  .../Csm/LegacyBiosDxe/LegacyPci.c  |  72 ++-
  IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c  |  51 
  7 files changed, 135 insertions(+), 273 deletions(-)

diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c 
b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c
index c6670febee..9667dc2a0f 100644
--- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c
+++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c
@@ -34,37 +34,36 @@ LegacyBiosInitBda (
BDA_STRUC *Bda;
UINT8 *Ebda;
  
-  DisableNullDetection ();

-
Bda   = (BDA_STRUC *) ((UINTN) 0x400);
Ebda  = (UINT8 *) ((UINTN) 0x9fc00);
  
-  ZeroMem (Bda, 0x100);

+  ACCESS_PAGE0_CODE ({
+ZeroMem (Bda, 0x100);
+//
+// 640k-1k for EBDA
+//
+Bda->MemSize= 0x27f;
+Bda->KeyHead= 0x1e;
+Bda->KeyTail= 0x1e;
+Bda->FloppyData = 0x00;
+Bda->FloppyTimeout  = 0xff;
+
+Bda->KeyStart   = 0x001E;
+Bda->KeyEnd = 0x003E;
+Bda->KeyboardStatus = 0x10;
+Bda->Ebda   = 0x9fc0;
+
+//
+// Move LPT time out here and zero out LPT4 since some SCSI OPROMS
+// use this as scratch pad (LPT4 is Reserved)
+//
+Bda->Lpt1_2Timeout  = 0x1414;
+Bda->Lpt3_4Timeout  = 0x1400;
+
+  });
+
ZeroMem (Ebda, 0x400);
-  //
-  // 640k-1k for EBDA
-  //
-  Bda->MemSize= 0x27f;
-  Bda->KeyHead= 0x1e;
-  Bda->KeyTail= 0x1e;
-  Bda->FloppyData = 0x00;
-  Bda->FloppyTimeout  = 0xff;
-
-  Bda->KeyStart   = 0x001E;
-  Bda->KeyEnd = 0x003E;
-  Bda->KeyboardStatus = 0x10;
-  Bda->Ebda   = 0x9fc0;
-
-  //
-  // Move LPT time out here and zero out LPT4 since some SCSI OPROMS
-  // use this as scratch pad (LPT4 is Reserved)
-  //
-  Bda->Lpt1_2Timeout  = 0x1414;
-  Bda->Lpt3_4Timeout  = 0x1400;
-
-  *Ebda   = 0x01;
-
-  EnableNullDetection ();
+  *Ebda = 0x01;
  
return EFI_SUCCESS;

  }
diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c 
b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
index c6461f5547..d50c15eacb 100644
--- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
+++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
@@ -786,115 +786,6 @@ ToggleEndOfDxeStatus (
return;
  }
  
-//

-// Legacy BIOS needs to access memory between 0-4095, which will cause page
-// fault exception if NULL pointer detection mechanism is enabled. Following
-// functions can be used to disable/enable NULL pointer detection before/after
-// accessing those memory.
-//
-
-/**
-   Enable NULL pointer detection.
-**/
-VOID
-EnableNullDetection (
-  VOID
-  )
-{
-  EFI_STATUSStatus;
-  EFI_GCD_MEMORY_SPACE_DESCRIPTOR   Desc;
-
-  if (((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) == 0)
-  ||
-  ((mEndOfDxe)  &&
-   ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT7|BIT0))
-== (BIT7|BIT0)))
- ) {
-return;
-  }
-
-  //
-  // Check current capabilities and attributes
-  //
-  Status = gDS->GetMemorySpaceDescriptor (0, );
-  ASSERT_EFI_ERROR (Status);
-
-  //
-  // Try to add EFI_MEMORY_RP support if necessary
-  //
-  if ((Desc.Capabilities & EFI_MEMORY_RP) == 0) {
-Desc.Capabilities |= EFI_MEMORY_RP;
-Status = gDS->SetMemorySpaceCapabilities (0, EFI_PAGES_TO_SIZE(1),
-  Desc.Capabilities);
-ASSERT_EFI_ERROR (Status);
-if (EFI_ERROR (Status)) {
-  return;
-}
-  }
-
-  //
-  // Don't bother if EFI_MEMORY_RP is already set.
-  //
-  if ((Desc.Attributes & EFI_MEMORY_RP) == 0) {
-Desc.Attributes |= EFI_MEMORY_RP;
-Status = gDS->SetMemorySpaceAttributes (0, 

Re: [edk2] [PATCH 1/3] IntelFrameworkPkg/LegacyBios.h: Add a macro to guarantee page 0 access

[Ni, Ruiyu]

On 12/6/2017 3:31 PM, Jian J Wang wrote:

Due to the introduction of NULL pointer detection feature, page 0 will be
disabled if the feature is enabled, which will cause legacy code failed to
update legacy data in page 0. This macro is introduced to make sure the
page 0 is enabled before those code and restore the original status of it
afterwards.

Another reason to introduce this macro is to eliminate the dependency on
the PcdNullPointerDetectionPropertyMask. Because this is a new PCD, it
could cause some backward compatibility issue for some old packages.

This macro will simply check if the page 0 is disabled or not. If it's
disabled, it will enable it before code updating page 0 and disable it
afterwards. Otherwise, this macro will do nothing to page 0.

The usage of the macro will be look like (similar to DEBUG_CODE macro):

 ACCESS_PAGE0_CODE(
   {
   
   }
 );

Cc: Liming Gao 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
  IntelFrameworkPkg/Include/Protocol/LegacyBios.h | 34 +
  1 file changed, 34 insertions(+)

diff --git a/IntelFrameworkPkg/Include/Protocol/LegacyBios.h 
b/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
index 641f101bce..f77c92ba21 100644
--- a/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
+++ b/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
@@ -1518,6 +1518,40 @@ struct _EFI_LEGACY_BIOS_PROTOCOL {
EFI_LEGACY_BIOS_BOOT_UNCONVENTIONAL_DEVICE  BootUnconventionalDevice;
  };
  
+//

+// Legacy BIOS needs to access memory in page 0 (0-4095), which is disabled if
+// NULL pointer detection feature is enabled. Following macro can be used to
+// enable/disable page 0 before/after accessing it.
+//
+#define ACCESS_PAGE0_CODE(statements)   \
+  do {  \
+EFI_STATUSStatus_;  \
+EFI_GCD_MEMORY_SPACE_DESCRIPTOR   Desc_;\
+\
+Status_ = gDS->GetMemorySpaceDescriptor (0, _);\
+if (!EFI_ERROR (Status_)) { \
+  if ((Desc_.Attributes & EFI_MEMORY_RP) != 0) {\
+Status_ = gDS->SetMemorySpaceAttributes (   \
+0,  \
+EFI_PAGES_TO_SIZE(1),   \
+Desc_.Attributes &= ~EFI_MEMORY_RP  \


&= is used here so Desc_.Attributes is updated to have RP cleared.
Then the below if will be always FALSE.


+);  \
+ASSERT_EFI_ERROR (Status_); \
+  } \
+\
+  statements;   \
+\
+  if ((Desc_.Attributes & EFI_MEMORY_RP) != 0) {\
+Status_ = gDS->SetMemorySpaceAttributes (   \
+0,  \
+EFI_PAGES_TO_SIZE(1),   \
+Desc_.Attributes\
+);  \
+ASSERT_EFI_ERROR (Status_); \
+  } \
+}   \
+  } while (FALSE)
+
  extern EFI_GUID gEfiLegacyBiosProtocolGuid;
  
  #endif





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

Re: [edk2] [PATCH v3 1/2] MdeModulePkg: introduce SD/MMC override protocol

[Ni, Ruiyu]

On 12/6/2017 11:25 AM, Zeng, Star wrote:

It should be not needed for Capability, but may be needed for NotifyPhase.
Hao can explain more.


When the SdMmcPassthru protocol is installed by gBS->InstallProtocol(),
that's the indication of readiness of this protocol.

Before that, it's not guaranteed that every interface of SdMmcPassthru
is safe to call, e.g.: GetNextSlot or ResetDevice may not work because
the device enumeration depends on the SdMmcOverride.

Even for PassThru interface, is might be possible that some private
data needed by PassThru to work hasn't been initialized, or
future implementation might choose to defer some private data
initialization to just before protocol installation.

I think after Hao's evaluation, if PassThru is only needed and
must-use interface for some usage case, we could just pass the PassThru
function pointer to SdMmcOverride.




Thanks,
Star
-Original Message-
From: Ni, Ruiyu
Sent: Wednesday, December 6, 2017 11:22 AM
To: Ard Biesheuvel <ard.biesheu...@linaro.org>; edk2-devel@lists.01.org
Cc: leif.lindh...@linaro.org; Kinney, Michael D <michael.d.kin...@intel.com>; Zeng, Star 
<star.z...@intel.com>; Tian, Feng <feng.t...@intel.com>; Wu, Hao A 
<hao.a...@intel.com>
Subject: Re: [PATCH v3 1/2] MdeModulePkg: introduce SD/MMC override protocol

On 12/6/2017 2:01 AM, Ard Biesheuvel wrote:

Many ARM based SoCs have integrated SDHCI controllers, and often,
these implementations deviate in subtle ways from the pertinent
specifications. On the one hand, these deviations are quite easy to
work around, but on the other hand, having a collection of SoC
specific workarounds in the generic driver stack is undesirable.

So let's introduce an optional SD/MMC override protocol that we can
invoke at the appropriate moments in the device initialization.
That way, the workaround itself remains platform specific, but we can
still use the generic driver stack on such platforms.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
   MdeModulePkg/Include/Protocol/SdMmcOverride.h | 103 
   MdeModulePkg/MdeModulePkg.dec |   3 +
   2 files changed, 106 insertions(+)

diff --git a/MdeModulePkg/Include/Protocol/SdMmcOverride.h
b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
new file mode 100644
index ..af57988f5625
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
@@ -0,0 +1,103 @@
+/** @file
+  Protocol to describe overrides required to support non-standard
+SDHCI
+  implementations
+
+  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials  are licensed and made
+ available under the terms and conditions of the BSD License  which
+ accompanies this distribution.  The full text of the license may be
+ found at  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
+ BASIS,  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+
+**/
+
+#ifndef __SD_MMC_OVERRIDE_H__
+#define __SD_MMC_OVERRIDE_H__
+
+#include 
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_GUID \
+  { 0xeaf9e3c1, 0xc9cd, 0x46db, { 0xa5, 0xe5, 0x5a, 0x12, 0x4c, 0x83,
+0x23, 0x23 } }
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_VERSION0x1
+
+typedef struct _EDKII_SD_MMC_OVERRIDE EDKII_SD_MMC_OVERRIDE;
+
+typedef enum {
+  EdkiiSdMmcResetPre,
+  EdkiiSdMmcResetPost,
+  EdkiiSdMmcInitHostPre,
+  EdkiiSdMmcInitHostPost,
+} EDKII_SD_MMC_PHASE_TYPE;
+
+/**
+
+  Override function for SDHCI capability bits
+
+  @param[in]  PassThru  A pointer to the
+EFI_SD_MMC_PASS_THRU_PROTOCOL instance.
+  @param[in]  ControllerHandle  The EFI_HANDLE of the controller.
+  @param[in]  Slot  The 0 based slot index.
+  @param[in,out]  SdMmcHcSlotCapability The SDHCI capability structure.
+
+  @retval EFI_SUCCESS   The override function completed successfully.
+  @retval EFI_NOT_FOUND The specified controller or slot does not 
exist.
+  @retval EFI_INVALID_PARAMETER SdMmcHcSlotCapability is NULL
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * EDKII_SD_MMC_CAPABILITY) (
+  IN  EFI_SD_MMC_PASS_THRU_PROTOCOL   *PassThru,

By looking a bit deeper, I get confused about this parameter.
SdMmcOverride protocol is supposed to be used by SdMmcHostController driver to 
produce SdMmcPassthru protocol.
But how does SdMmcOverride uses the not-yet-produced SdMmcPassthru protocol? 
It's like a chicken-egg problem.


+  IN  EFI_HANDLE  ControllerHandle,
+  IN  UINT8   Slot,
+  IN  OUT UINT64  *SdMmcHcSlotCapability
+  );
+
+/**
+
+  Override function for SDHCI controller operations
+
+  @param[in]  PassThru  A pointer to the
+

Re: [edk2] [PATCH v3 2/2] MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden

[Ni, Ruiyu]

Ard,
I should have provided some of them in the last version.
Sorry about that.

We just found an internal/private SdMmcPciHc implementation
developed by other teams. We are evaluating whether your
proposed SdMmcOverride can be used to retire that private
implementation.


On 12/6/2017 2:01 AM, Ard Biesheuvel wrote:

Invoke the newly introduced SD/MMC override protocol to override
the capabilities register after reading it from the device registers,
and to call the pre/post host init and reset hooks at the appropriate
times.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c   | 134 
+++-
  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h   |   1 +
  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf |   2 +
  3 files changed, 133 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c 
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
index 0be8828abfcc..f1ea78de809e 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
@@ -17,6 +17,8 @@
  
  #include "SdMmcPciHcDxe.h"
  
+STATIC EDKII_SD_MMC_OVERRIDE   *mOverride;

+
  //
  // Driver Global Variables
  //
@@ -214,6 +216,104 @@ Done:
  }
  
  /**

+  Execute a SD/MMC host controller reset
+
+  @param[in] Private  A pointer to the SD_MMC_HC_PRIVATE_DATA instance.
+  @param[in] Slot The slot number of the host controller to reset.
+**/
+STATIC
+EFI_STATUS
+SdMmcPciHcResetHost (
+  IN  SD_MMC_HC_PRIVATE_DATA  *Private,
+  IN  UINT8   Slot
+  )

I checked the implementation of SdMmcHcReset(). It's quite simple.
So how about we do not introduce this new function SdMmcPciHcResetHost,
but just put the two NotifyPhase call inside SdMmcHcReset().

Because the names of the two functions (SdMmcPciHcResetHost and
SdMmcHcReset) are quite similar. After not a long period, maintainer
may get confused about which is which.

I agree parameters of SdMmcHcReset need to change.


+{
+  EFI_STATUSStatus;
+
+  if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
+Status = mOverride->NotifyPhase (
+  >PassThru,
+  Private->ControllerHandle,
+  Slot,
+  EdkiiSdMmcResetPre);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_WARN,
+"%a: SD/MMC pre reset notifier callback failed - %r\n",
+__FUNCTION__, Status));
+  return Status;
+}
+  }
+
+  Status = SdMmcHcReset (Private->PciIo, Slot);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
+Status = mOverride->NotifyPhase (
+  >PassThru,
+  Private->ControllerHandle,
+  Slot,
+  EdkiiSdMmcResetPost);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_WARN,
+"%a: SD/MMC post reset notifier callback failed - %r\n",
+__FUNCTION__, Status));
+}
+  }
+  return Status;
+}
+
+/**
+  Initialize a SD/MMC host controller
+
+  @param[in] Private  A pointer to the SD_MMC_HC_PRIVATE_DATA instance.
+  @param[in] Slot The slot number of the host controller to initialize.
+**/
+STATIC
+EFI_STATUS
+SdMmcPciHcInitHost (
+  IN  SD_MMC_HC_PRIVATE_DATA  *Private,
+  IN  UINT8   Slot
+  )
+{
+  EFI_STATUSStatus;
+
+  if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
+Status = mOverride->NotifyPhase (
+  >PassThru,
+  Private->ControllerHandle,
+  Slot,
+  EdkiiSdMmcInitHostPre);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_WARN,
+"%a: SD/MMC pre init notifier callback failed - %r\n",
+__FUNCTION__, Status));
+  return Status;
+}
+  }
+
+  Status = SdMmcHcInitHost (Private->PciIo, Slot, Private->Capability[Slot]);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
+Status = mOverride->NotifyPhase (
+  >PassThru,
+  Private->ControllerHandle,
+  Slot,
+  EdkiiSdMmcInitHostPost);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_WARN,
+"%a: SD/MMC post init notifier callback failed - %r\n",
+__FUNCTION__, Status));
+}
+  }
+  return Status;
+}
+
+/**
Sd removable device enumeration callback function when the timer event is 
signaled.
  
@param[in]  Event The Event this notify function registered to.

@@ -281,14 +381,14 @@ SdMmcPciHcEnumerateDevice (
  //
  // Reset the specified slot of the SD/MMC Pci Host Controller
  //
-Status 

Re: [edk2] [PATCH v3 1/2] MdeModulePkg: introduce SD/MMC override protocol

[Ni, Ruiyu]

On 12/6/2017 2:01 AM, Ard Biesheuvel wrote:

Many ARM based SoCs have integrated SDHCI controllers, and often,
these implementations deviate in subtle ways from the pertinent
specifications. On the one hand, these deviations are quite easy
to work around, but on the other hand, having a collection of SoC
specific workarounds in the generic driver stack is undesirable.

So let's introduce an optional SD/MMC override protocol that we
can invoke at the appropriate moments in the device initialization.
That way, the workaround itself remains platform specific, but we
can still use the generic driver stack on such platforms.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
  MdeModulePkg/Include/Protocol/SdMmcOverride.h | 103 
  MdeModulePkg/MdeModulePkg.dec |   3 +
  2 files changed, 106 insertions(+)

diff --git a/MdeModulePkg/Include/Protocol/SdMmcOverride.h 
b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
new file mode 100644
index ..af57988f5625
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
@@ -0,0 +1,103 @@
+/** @file
+  Protocol to describe overrides required to support non-standard SDHCI
+  implementations
+
+  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __SD_MMC_OVERRIDE_H__
+#define __SD_MMC_OVERRIDE_H__
+
+#include 
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_GUID \
+  { 0xeaf9e3c1, 0xc9cd, 0x46db, { 0xa5, 0xe5, 0x5a, 0x12, 0x4c, 0x83, 0x23, 
0x23 } }
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_VERSION0x1
+
+typedef struct _EDKII_SD_MMC_OVERRIDE EDKII_SD_MMC_OVERRIDE;
+
+typedef enum {
+  EdkiiSdMmcResetPre,
+  EdkiiSdMmcResetPost,
+  EdkiiSdMmcInitHostPre,
+  EdkiiSdMmcInitHostPost,
+} EDKII_SD_MMC_PHASE_TYPE;
+
+/**
+
+  Override function for SDHCI capability bits
+
+  @param[in]  PassThru  A pointer to the
+EFI_SD_MMC_PASS_THRU_PROTOCOL instance.
+  @param[in]  ControllerHandle  The EFI_HANDLE of the controller.
+  @param[in]  Slot  The 0 based slot index.
+  @param[in,out]  SdMmcHcSlotCapability The SDHCI capability structure.
+
+  @retval EFI_SUCCESS   The override function completed successfully.
+  @retval EFI_NOT_FOUND The specified controller or slot does not 
exist.
+  @retval EFI_INVALID_PARAMETER SdMmcHcSlotCapability is NULL
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * EDKII_SD_MMC_CAPABILITY) (
+  IN  EFI_SD_MMC_PASS_THRU_PROTOCOL   *PassThru,

By looking a bit deeper, I get confused about this parameter.
SdMmcOverride protocol is supposed to be used by SdMmcHostController
driver to produce SdMmcPassthru protocol.
But how does SdMmcOverride uses the not-yet-produced SdMmcPassthru 
protocol? It's like a chicken-egg problem.



+  IN  EFI_HANDLE  ControllerHandle,
+  IN  UINT8   Slot,
+  IN  OUT UINT64  *SdMmcHcSlotCapability
+  );
+
+/**
+
+  Override function for SDHCI controller operations
+
+  @param[in]  PassThru  A pointer to the
+EFI_SD_MMC_PASS_THRU_PROTOCOL instance.
+  @param[in]  ControllerHandle  The EFI_HANDLE of the controller.
+  @param[in]  Slot  The 0 based slot index.
+  @param[in,out]  PhaseType The type of operation and whether the
+hook is invoked right before (pre) or
+right after (post)
+
+  @retval EFI_SUCCESS   The override function completed successfully.
+  @retval EFI_NOT_FOUND The specified controller or slot does not 
exist.
+  @retval EFI_INVALID_PARAMETER HookType is invalid
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * EDKII_SD_MMC_NOTIFY_PHASE) (
+  IN  EFI_SD_MMC_PASS_THRU_PROTOCOL   *PassThru,
+  IN  EFI_HANDLE  ControllerHandle,
+  IN  UINT8   Slot,
+  IN  EDKII_SD_MMC_PHASE_TYPE PhaseType
+  );
+
+struct _EDKII_SD_MMC_OVERRIDE {
+  //
+  // Protocol version of this implementation
+  //
+  UINTN Version;
+  //
+  // Callback to override SD/MMC host controller capability bits
+  //
+  EDKII_SD_MMC_CAPABILITY   Capability;
+  //
+  // Callback to invoke SD/MMC override hooks
+  //
+  EDKII_SD_MMC_NOTIFY_PHASE NotifyPhase;
+};
+
+extern EFI_GUID gEdkiiSdMmcOverrideProtocolGuid;
+
+#endif
diff --git 

Re: [edk2] [PATCH v2 1/2] MdeModulePkg: introduce SD/MMC override protocol

[Ni, Ruiyu]

On 12/5/2017 6:24 PM, Ard Biesheuvel wrote:

On 5 December 2017 at 10:12, Ni, Ruiyu <ruiyu...@intel.com> wrote:

Some comments re the detailed interfaces embedded in below.

On 11/30/2017 6:11 PM, Ard Biesheuvel wrote:


Many ARM based SoCs have integrated SDHCI controllers, and often,
these implementations deviate in subtle ways from the pertinent
specifications. On the one hand, these deviations are quite easy
to work around, but on the other hand, having a collection of SoC
specific workarounds in the generic driver stack is undesirable.

So let's introduce an optional SD/MMC override protocol that we
can invoke at the appropriate moments in the device initialization.
That way, the workaround itself remains platform specific, but we
can still use the generic driver stack on such platforms.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
   MdeModulePkg/Include/Protocol/SdMmcOverride.h | 103 
   MdeModulePkg/MdeModulePkg.dec |   3 +
   2 files changed, 106 insertions(+)

diff --git a/MdeModulePkg/Include/Protocol/SdMmcOverride.h
b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
new file mode 100644
index ..5a5c393896f4
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
@@ -0,0 +1,103 @@
+/** @file
+  Protocol to describe overrides required to support non-standard SDHCI
+  implementations

>>> ...

+  IN  EFI_SD_MMC_PASS_THRU_PROTOCOL   *PassThru,
+  IN  EFI_HANDLE  ControllerHandle,
+  IN  UINT8   Slot,
+  IN  OUT UINT64  *SdMmcHcSlotCapability
+  );



Is this API too specific?
Besides SlotCapability, is there any other attributes that may need
override as well?



The capability structure is the root data structure that describes the
SD/MMC host controller. Which other data structures did you have in
mind?



I do not know either.
Hao, any comments?

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

Re: [edk2] [PATCH v2 1/2] MdeModulePkg: introduce SD/MMC override protocol

[Ni, Ruiyu]

Some comments re the detailed interfaces embedded in below.

On 11/30/2017 6:11 PM, Ard Biesheuvel wrote:

Many ARM based SoCs have integrated SDHCI controllers, and often,
these implementations deviate in subtle ways from the pertinent
specifications. On the one hand, these deviations are quite easy
to work around, but on the other hand, having a collection of SoC
specific workarounds in the generic driver stack is undesirable.

So let's introduce an optional SD/MMC override protocol that we
can invoke at the appropriate moments in the device initialization.
That way, the workaround itself remains platform specific, but we
can still use the generic driver stack on such platforms.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
  MdeModulePkg/Include/Protocol/SdMmcOverride.h | 103 
  MdeModulePkg/MdeModulePkg.dec |   3 +
  2 files changed, 106 insertions(+)

diff --git a/MdeModulePkg/Include/Protocol/SdMmcOverride.h 
b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
new file mode 100644
index ..5a5c393896f4
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
@@ -0,0 +1,103 @@
+/** @file
+  Protocol to describe overrides required to support non-standard SDHCI
+  implementations
+
+  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __SD_MMC_OVERRIDE_H__
+#define __SD_MMC_OVERRIDE_H__
+
+#include 
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_GUID \
+  { 0xeaf9e3c1, 0xc9cd, 0x46db, { 0xa5, 0xe5, 0x5a, 0x12, 0x4c, 0x83, 0x23, 
0x23 } }
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_VERSION0x1
+
+typedef struct _SD_MMC_OVERRIDE SD_MMC_OVERRIDE;
+
+typedef enum {
+  SD_MMC_OVERRIDE_RESET_PRE_HOOK,
+  SD_MMC_OVERRIDE_RESET_POST_HOOK,
+  SD_MMC_OVERRIDE_INIT_HOST_PRE_HOOK,
+  SD_MMC_OVERRIDE_INIT_HOST_POST_HOOK,


How about using name like "SdMmcResetPre"?
Do "ResetPre"/"ResetPost" / "InitHostPre" / "InitHostPost" cover
all potential check points?


+} SD_MMC_OVERRIDE_HOOK;

How about use "SD_MMC_PHASE_TYPE"?



+
+/**
+
+  Override function for SDHCI capability bits
+
+  @param[in]  PassThru  A pointer to the
+EFI_SD_MMC_PASS_THRU_PROTOCOL instance.
+  @param[in]  ControllerHandle  The EFI_HANDLE of the controller.
+  @param[in]  Slot  The 0 based slot index.
+  @param[in,out]  SdMmcHcSlotCapability The SDHCI capability structure.
+
+  @retval EFI_SUCCESS   The override function completed successfully.
+  @retval EFI_NOT_FOUND The specified controller or slot does not 
exist.
+  @retval EFI_INVALID_PARAMETER SdMmcHcSlotCapability is NULL
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * SD_MMC_OVERRIDE_CAPABILITY) (


How about "SD_MMC_CAPABILITY"?


+  IN  EFI_SD_MMC_PASS_THRU_PROTOCOL   *PassThru,
+  IN  EFI_HANDLE  ControllerHandle,
+  IN  UINT8   Slot,
+  IN  OUT UINT64  *SdMmcHcSlotCapability
+  );


Is this API too specific?
Besides SlotCapability, is there any other attributes that may need
override as well?


+
+/**
+
+  Override function for SDHCI controller operations
+
+  @param[in]  PassThru  A pointer to the
+EFI_SD_MMC_PASS_THRU_PROTOCOL instance.
+  @param[in]  ControllerHandle  The EFI_HANDLE of the controller.
+  @param[in]  Slot  The 0 based slot index.
+  @param[in,out]  HookType  The type of operation and whether the
+hook is invoked right before (pre) or
+right after (post)
+
+  @retval EFI_SUCCESS   The override function completed successfully.
+  @retval EFI_NOT_FOUND The specified controller or slot does not 
exist.
+  @retval EFI_INVALID_PARAMETER HookType is invalid
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * SD_MMC_OVERRIDE_INVOKE_HOOK) (


How about "SD_MMC_NOTIFY_PHASE"?


+  IN  EFI_SD_MMC_PASS_THRU_PROTOCOL   *PassThru,
+  IN  EFI_HANDLE  ControllerHandle,
+  IN  UINT8   Slot,
+  IN  SD_MMC_OVERRIDE_HOOKHookType
+  );
+
+struct _SD_MMC_OVERRIDE {
+  //
+  // Protocol version of this implementation
+  //
+  UINTN   Version;
+  //
+  // Callback to override SD/MMC host controller capability bits
+  //
+  SD_MMC_OVERRIDE_CAPABILITY  OverrideCapability;How about 

Re: [edk2] [PATCH v2 1/2] MdeModulePkg: introduce SD/MMC override protocol

[Ni, Ruiyu]

On 12/5/2017 3:20 PM, Zeng, Star wrote:

If making this protocol a platform level singleton instance, is it so hard to 
define the interfaces and parameters since different controllers may need 
different hook points and parameters?

Thanks,
Star
-Original Message-
From: Ni, Ruiyu
Sent: Tuesday, December 5, 2017 3:09 PM
To: Ard Biesheuvel <ard.biesheu...@linaro.org>; edk2-devel@lists.01.org
Cc: "hao.a...@intel.com; Kinney.d.michael"@intel.com; Tian, Feng 
<feng.t...@intel.com>; Zeng, Star <star.z...@intel.com>; leif.lindh...@linaro.org
Subject: Re: [edk2] [PATCH v2 1/2] MdeModulePkg: introduce SD/MMC override 
protocol

On 11/30/2017 6:11 PM, Ard Biesheuvel wrote:

Many ARM based SoCs have integrated SDHCI controllers, and often,
these implementations deviate in subtle ways from the pertinent
specifications. On the one hand, these deviations are quite easy to
work around, but on the other hand, having a collection of SoC
specific workarounds in the generic driver stack is undesirable.

So let's introduce an optional SD/MMC override protocol that we can
invoke at the appropriate moments in the device initialization.
That way, the workaround itself remains platform specific, but we can
still use the generic driver stack on such platforms.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
   MdeModulePkg/Include/Protocol/SdMmcOverride.h | 103 
   MdeModulePkg/MdeModulePkg.dec |   3 +
   2 files changed, 106 insertions(+)

diff --git a/MdeModulePkg/Include/Protocol/SdMmcOverride.h
b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
new file mode 100644
index ..5a5c393896f4
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
@@ -0,0 +1,103 @@
+/** @file
+  Protocol to describe overrides required to support non-standard
+SDHCI
+  implementations
+
+  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials  are licensed and made
+ available under the terms and conditions of the BSD License  which
+ accompanies this distribution.  The full text of the license may be
+ found at  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
+ BASIS,  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+
+**/
+
+#ifndef __SD_MMC_OVERRIDE_H__
+#define __SD_MMC_OVERRIDE_H__
+
+#include 
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_GUID \
+  { 0xeaf9e3c1, 0xc9cd, 0x46db, { 0xa5, 0xe5, 0x5a, 0x12, 0x4c, 0x83,
+0x23, 0x23 } }
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_VERSION0x1
+
+typedef struct _SD_MMC_OVERRIDE SD_MMC_OVERRIDE;
+
+typedef enum {
+  SD_MMC_OVERRIDE_RESET_PRE_HOOK,
+  SD_MMC_OVERRIDE_RESET_POST_HOOK,
+  SD_MMC_OVERRIDE_INIT_HOST_PRE_HOOK,
+  SD_MMC_OVERRIDE_INIT_HOST_POST_HOOK,
+} SD_MMC_OVERRIDE_HOOK;
+
+/**
+
+  Override function for SDHCI capability bits
+
+  @param[in]  PassThru  A pointer to the
+EFI_SD_MMC_PASS_THRU_PROTOCOL instance.
+  @param[in]  ControllerHandle  The EFI_HANDLE of the controller.
+  @param[in]  Slot  The 0 based slot index.
+  @param[in,out]  SdMmcHcSlotCapability The SDHCI capability structure.
+
+  @retval EFI_SUCCESS   The override function completed successfully.
+  @retval EFI_NOT_FOUND The specified controller or slot does not 
exist.
+  @retval EFI_INVALID_PARAMETER SdMmcHcSlotCapability is NULL
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * SD_MMC_OVERRIDE_CAPABILITY) (
+  IN  EFI_SD_MMC_PASS_THRU_PROTOCOL   *PassThru,
+  IN  EFI_HANDLE  ControllerHandle,
+  IN  UINT8   Slot,
+  IN  OUT UINT64  *SdMmcHcSlotCapability
+  );
+
+/**
+
+  Override function for SDHCI controller operations
+
+  @param[in]  PassThru  A pointer to the
+EFI_SD_MMC_PASS_THRU_PROTOCOL instance.
+  @param[in]  ControllerHandle  The EFI_HANDLE of the controller.
+  @param[in]  Slot  The 0 based slot index.
+  @param[in,out]  HookType  The type of operation and whether the
+hook is invoked right before (pre) or
+right after (post)
+
+  @retval EFI_SUCCESS   The override function completed successfully.
+  @retval EFI_NOT_FOUND The specified controller or slot does not 
exist.
+  @retval EFI_INVALID_PARAMETER HookType is invalid
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * SD_MMC_OVERRIDE_INVOKE_HOOK) (
+  IN  EFI_SD_MMC_PASS_THRU_PROTOCOL   *PassThru,
+  IN  EFI_HANDLE  ControllerHandle,
+  IN  UINT8   Slot,
+  IN  SD_MMC_OVERRIDE_HOOKHookType
+  );
+
+struct _SD

Re: [edk2] [PATCH v2 1/2] MdeModulePkg: introduce SD/MMC override protocol

[Ni, Ruiyu]

On 11/30/2017 6:11 PM, Ard Biesheuvel wrote:

Many ARM based SoCs have integrated SDHCI controllers, and often,
these implementations deviate in subtle ways from the pertinent
specifications. On the one hand, these deviations are quite easy
to work around, but on the other hand, having a collection of SoC
specific workarounds in the generic driver stack is undesirable.

So let's introduce an optional SD/MMC override protocol that we
can invoke at the appropriate moments in the device initialization.
That way, the workaround itself remains platform specific, but we
can still use the generic driver stack on such platforms.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
  MdeModulePkg/Include/Protocol/SdMmcOverride.h | 103 
  MdeModulePkg/MdeModulePkg.dec |   3 +
  2 files changed, 106 insertions(+)

diff --git a/MdeModulePkg/Include/Protocol/SdMmcOverride.h 
b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
new file mode 100644
index ..5a5c393896f4
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
@@ -0,0 +1,103 @@
+/** @file
+  Protocol to describe overrides required to support non-standard SDHCI
+  implementations
+
+  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __SD_MMC_OVERRIDE_H__
+#define __SD_MMC_OVERRIDE_H__
+
+#include 
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_GUID \
+  { 0xeaf9e3c1, 0xc9cd, 0x46db, { 0xa5, 0xe5, 0x5a, 0x12, 0x4c, 0x83, 0x23, 
0x23 } }
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_VERSION0x1
+
+typedef struct _SD_MMC_OVERRIDE SD_MMC_OVERRIDE;
+
+typedef enum {
+  SD_MMC_OVERRIDE_RESET_PRE_HOOK,
+  SD_MMC_OVERRIDE_RESET_POST_HOOK,
+  SD_MMC_OVERRIDE_INIT_HOST_PRE_HOOK,
+  SD_MMC_OVERRIDE_INIT_HOST_POST_HOOK,
+} SD_MMC_OVERRIDE_HOOK;
+
+/**
+
+  Override function for SDHCI capability bits
+
+  @param[in]  PassThru  A pointer to the
+EFI_SD_MMC_PASS_THRU_PROTOCOL instance.
+  @param[in]  ControllerHandle  The EFI_HANDLE of the controller.
+  @param[in]  Slot  The 0 based slot index.
+  @param[in,out]  SdMmcHcSlotCapability The SDHCI capability structure.
+
+  @retval EFI_SUCCESS   The override function completed successfully.
+  @retval EFI_NOT_FOUND The specified controller or slot does not 
exist.
+  @retval EFI_INVALID_PARAMETER SdMmcHcSlotCapability is NULL
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * SD_MMC_OVERRIDE_CAPABILITY) (
+  IN  EFI_SD_MMC_PASS_THRU_PROTOCOL   *PassThru,
+  IN  EFI_HANDLE  ControllerHandle,
+  IN  UINT8   Slot,
+  IN  OUT UINT64  *SdMmcHcSlotCapability
+  );
+
+/**
+
+  Override function for SDHCI controller operations
+
+  @param[in]  PassThru  A pointer to the
+EFI_SD_MMC_PASS_THRU_PROTOCOL instance.
+  @param[in]  ControllerHandle  The EFI_HANDLE of the controller.
+  @param[in]  Slot  The 0 based slot index.
+  @param[in,out]  HookType  The type of operation and whether the
+hook is invoked right before (pre) or
+right after (post)
+
+  @retval EFI_SUCCESS   The override function completed successfully.
+  @retval EFI_NOT_FOUND The specified controller or slot does not 
exist.
+  @retval EFI_INVALID_PARAMETER HookType is invalid
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * SD_MMC_OVERRIDE_INVOKE_HOOK) (
+  IN  EFI_SD_MMC_PASS_THRU_PROTOCOL   *PassThru,
+  IN  EFI_HANDLE  ControllerHandle,
+  IN  UINT8   Slot,
+  IN  SD_MMC_OVERRIDE_HOOKHookType
+  );
+
+struct _SD_MMC_OVERRIDE {
+  //
+  // Protocol version of this implementation
+  //
+  UINTN   Version;
+  //
+  // Callback to override SD/MMC host controller capability bits
+  //
+  SD_MMC_OVERRIDE_CAPABILITY  OverrideCapability;
+  //
+  // Callback to invoke SD/MMC override hooks
+  //
+  SD_MMC_OVERRIDE_INVOKE_HOOK InvokeHook;
+};
+
+extern EFI_GUID gEdkiiSdMmcOverrideProtocolGuid;
+
+#endif
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 856d67aceb21..64ceea029f94 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -562,6 +562,9 @@ [Protocols]
## Include/Protocol/SmmMemoryAttribute.h

Re: [edk2] [PATCH] ShellPkg/ShellPkg.dec: Change comments for PcdShellLibAutoInitialize

[Ni, Ruiyu]

That's fine. Faster than me in the review response.

> -Original Message-
> From: Carsey, Jaben
> Sent: Saturday, December 2, 2017 1:00 AM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Subject: RE: [PATCH] ShellPkg/ShellPkg.dec: Change comments for
> PcdShellLibAutoInitialize
> 
> Apologies for delay.  I missed the email on first pass.
> 
> Reviewed-by: Jaben Carsey <jaben.car...@intel.com>
> 
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Wednesday, November 29, 2017 12:22 AM
> > To: edk2-devel@lists.01.org
> > Cc: Carsey, Jaben <jaben.car...@intel.com>
> > Subject: [PATCH] ShellPkg/ShellPkg.dec: Change comments for
> > PcdShellLibAutoInitialize
> > Importance: High
> >
> > When Dynamic command drivers links to ShellLib, the ShellLib
> > constructor shouldn't be called because the Shell and ShellParameters
> > protocols don't exist when the driver starts.
> > So it's required to set PcdShellLibAutoInitialize to FALSE for dynamic
> > command drivers.
> > Update the comments in DEC file to describe such requirement for this
> > PCD.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Jaben Carsey <jaben.car...@intel.com>
> > ---
> >  ShellPkg/ShellPkg.dec | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/ShellPkg/ShellPkg.dec b/ShellPkg/ShellPkg.dec index
> > 5859c49033..48d50b87b3 100644
> > --- a/ShellPkg/ShellPkg.dec
> > +++ b/ShellPkg/ShellPkg.dec
> > @@ -81,6 +81,7 @@ [PcdsFeatureFlag]
> >  [PcdsFixedAtBuild]
> >## This flag is used to control initialization of the shell library
> >#  This should be FALSE for compiling the shell application itself only.
> > +  #  This should be FALSE for compiling the dynamic command drivers.
> >
> > gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|TRUE|BOOLEAN|0x00
> > 05
> >
> >## This is the max buffer for ShellLib and internal Shell printings.
> > --
> > 2.15.0.gvfs.1.preview.4

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

Re: [edk2] [PATCH 2/2] QuarkPlatformPkg: Use DpDynamicCommand to replace PerformancePkg/dp

[Ni, Ruiyu]

Kelly,
I pushed the commit, following your below recommendation.

> -Original Message-
> From: Steele, Kelly
> Sent: Saturday, December 2, 2017 1:18 AM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: RE: [PATCH 2/2] QuarkPlatformPkg: Use DpDynamicCommand to
> replace PerformancePkg/dp
> 
> Reviewed-by: Steele, Kelly <kelly.ste...@intel.com>
> 
> My only comment is the fix in Quark.fdf, line #575:
> # File System Modules
> #
> -!if $(PERFORMANCE_ENABLE)
> -INF
> MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
> -!else
> +!if not $(PERFORMANCE_ENABLE)
>  INF  MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
>  INF  MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
>  INF  FatPkg/EnhancedFatDxe/Fat.inf
>  !endif
> 
> I would suggest going with the following to keep with the style present in the
> rest of the file:
> # File System Modules
> #
> !if $(PERFORMANCE_ENABLE)
> -INF
> MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
> !else
>  INF  MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
>  INF  MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
>  INF  FatPkg/EnhancedFatDxe/Fat.inf
>  !endif
> 
> Thanks,
> Kelly
> 
> -Original Message-
> From: Ni, Ruiyu
> Sent: November 29, 2017 00:15
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Steele, Kelly
> <kelly.ste...@intel.com>
> Subject: [PATCH 2/2] QuarkPlatformPkg: Use DpDynamicCommand to replace
> PerformancePkg/dp
> 
> Remove FvSimpleFileSystemDxe from Quark.dsc/fdf because it's not needed by
> using DpDynamicCommand driver.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Michael D Kinney <michael.d.kin...@intel.com>
> Cc: Kelly Steele <kelly.ste...@intel.com>
> ---
>  QuarkPlatformPkg/Quark.dsc| 15 +++
>  QuarkPlatformPkg/Quark.fdf| 16 +---
>  QuarkPlatformPkg/QuarkMin.dsc | 13 -
> QuarkPlatformPkg/QuarkMin.fdf | 12 
>  4 files changed, 32 insertions(+), 24 deletions(-)
> 
> diff --git a/QuarkPlatformPkg/Quark.dsc b/QuarkPlatformPkg/Quark.dsc index
> 025653eee5..5624451e12 100644
> --- a/QuarkPlatformPkg/Quark.dsc
> +++ b/QuarkPlatformPkg/Quark.dsc
> @@ -163,6 +163,9 @@ [LibraryClasses]
> 
> PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLib
> Null.inf
>  !endif
> 
> +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> +
>OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
>IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> @@ -864,9 +867,6 @@ [Components.IA32]
>MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
>MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
>FatPkg/EnhancedFatDxe/Fat.inf
> -!if $(PERFORMANCE_ENABLE)
> -  MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
> -!endif
> 
>#
># Capsule update
> @@ -887,10 +887,11 @@ [Components.IA32]
># Performance Application
>#
>  !if $(PERFORMANCE_ENABLE)
> -  PerformancePkg/Dp_App/Dp.inf {
> +  ShellPkg/DynamicCommand/DpDynamicCommand/DpDynamicCommand.inf {
> +
> +  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
>  
> -  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> -  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> +
> +
> PerformanceLib|MdeModulePkg/Library/DxeSmmPerformanceLib/DxeSmmPerf
> orm
> + anceLib.inf
>}
>  !endif
> 
> @@ -910,8 +911,6 @@ [Components.IA32]
> 
> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1Comman
> dsLib.inf
> 
> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Co
> mmandsLib.inf
> 
> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.i
> nf
> -  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> -  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> 
> BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCo
> mmandLib.inf
> 
> diff --git a/QuarkPlatformPkg/Quark.fdf b/QuarkPlatformPkg/Quark.fdf index
> 19533b2281..5abe3b6f31 100644
> --- a/QuarkPlatformPkg/Quark.fdf
> +++ b/QuarkPlatformPkg/Quark.fdf
> @@ -2,7 +2,7 @@
>  # FDF file of Clanton

Re: [edk2] edk2 interface deprecation policy

[Ni, Ruiyu]

I prefer to remove all deprecated items because I like clean:)
But then lots of customer complains may come.

So just provide my thoughts:
Deprecated items can be separated into:

1. Definitions: E.g.: UgaDraw protocol, DriverConfiguration2 protocol
Keep:
But harm the newbie developers because they don't know which interfaces 
should depend on.
Remove:
A pure world.
But easy to cause build break. Yet easy to fix by downloading the 
definitions from old revision.
Proposal:
Move all deprecated definitions to a DeprecatePkg/OldPkg. 

2. Modules. E.g.: IntelFrameworkModulePkg/Universal/BdsDxe, 
IntelFrameworkModulePkg/Bus/Isa/*
 Keep:
 Increase feature owner's maintain effort.
 Cause confusing because new features won't be enabled in deprecated 
modules.
 Remove:
  A pure world.
  But easy to cause build break. Yet easy to fix by downloading the 
definitions from old revision.
Proposal:
 Keep it if in IntelFramework[Module]Pkg because in future the two pkgs 
will be deprecated.
 Move it to DeprecatePkg/OldPkg if in Mde[Module]Pkg

3. Libraries: E.g.: 
IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode
  Same as #2.

So how about we create another GIT repo and store the DeprecatePkg/OldPkg.
Old consumers can download old stuffs from the other GIT repo.
Eventually the IntelFramework[Module]Pkg can be moved to that repo as well.


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
> Liming
> Sent: Friday, December 1, 2017 9:51 AM
> To: Felix Poludov ; af...@apple.com
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] edk2 interface deprecation policy
> 
> Felix:
>   I agree to define the tag to specify the deprecated definition, library and 
> drivers.
> If so, user can easily know which one is not used any more. But, I think we 
> can
> still keep them in edk2 project, because they have no negative impact.
> 
> Thanks
> Liming
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >Felix Poludov
> >Sent: Friday, December 01, 2017 6:12 AM
> >To: af...@apple.com
> >Cc: edk2-devel@lists.01.org
> >Subject: Re: [edk2] edk2 interface deprecation policy
> >
> >I agree. It would be beneficial to have a mailing list discussion on
> >how to deal with the deprecated item.
> >In some cases it would make sense to tag an interface as deprecated,
> >but keep in the code base for a while (6 month?) before actually deleting it.
> >
> >-Original Message-
> >From: af...@apple.com [mailto:af...@apple.com]
> >Sent: Thursday, November 30, 2017 11:57 AM
> >To: Felix Poludov
> >Cc: edk2-devel@lists.01.org
> >Subject: Re: [edk2] edk2 interface deprecation policy
> >
> >Felix,
> >
> >I don't think we have one
> >
> >Adding new interfaces does not impact the downstream projects, but
> >depreciating interface can break stuff. Seems like it might at least be
> >a good idea to have a depreciation discussion on the mailing  list. I'm
> >open to other suggestions
> >
> >Thanks,
> >
> >Andrew Fish
> >
> >> On Nov 30, 2017, at 6:00 AM, Felix Poludov  wrote:
> >>
> >> Does edk2 have a policy regarding deprecation of interface definition
> >headers?
> >> I can see that definition of the UgaDraw protocol that was deprecated
> >> years
> >ago (I believe in UEFI 2.0) is still part of the code base; yet,
> >definition of the SMM Communication ACPI Table that was deprecated this
> >year in UEFI 2.6B has already been removed.
> >>
> >> Please consider the environment before printing this email.
> >>
> >> The information contained in this message may be confidential and
> >proprietary to American Megatrends, Inc.  This communication is
> >intended to be read only by the individual or entity to whom it is
> >addressed or by their designee. If the reader of this message is not
> >the intended recipient, you are on notice that any distribution of this
> >message, in any form, is strictly prohibited.  Please promptly notify
> >the sender by reply e-mail or by telephone at 770-246-8600, and then delete 
> >or
> destroy all copies of the transmission.
> >> ___
> >> edk2-devel mailing list
> >> edk2-devel@lists.01.org
> >> https://lists.01.org/mailman/listinfo/edk2-devel
> >
> >
> >Please consider the environment before printing this email.
> >
> >The information contained in this message may be confidential and
> >proprietary to American Megatrends, Inc.  This communication is
> >intended to be read only by the individual or entity to whom it is
> >addressed or by their designee. If the reader of this message is not
> >the intended recipient, you are on notice that any distribution of this
> >message, in any form, is strictly prohibited.  Please promptly notify
> >the sender by reply e-mail or by telephone at 770-246-8600, and then delete 
> >or

Re: [edk2] [PATCH v4 2/3] ArmVirtPkg: Fix build failure due to Tftp library removal

[Ni, Ruiyu]

Laszlo,
Thank you very much for that! I will try to become a talkaholic
when writing commit messages next time.


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, November 30, 2017 9:16 PM
> To: Laszlo Ersek <ler...@redhat.com>
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH v4 2/3] ArmVirtPkg: Fix build failure due to Tftp
> library removal
> 
> On 30 November 2017 at 12:22, Laszlo Ersek <ler...@redhat.com> wrote:
> > On 11/29/17 14:53, Laszlo Ersek wrote:
> >> Ray,
> >>
> >> On 11/29/17 11:14, Ruiyu Ni wrote:
> >>> The TFTP command was converted from a NULL class library instance to
> >>> a dynamic shell command in commit 0961002352e9.
> >>>
> >>> Contributed-under: TianoCore Contribution Agreement 1.1
> >>> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> >>> Reviewed-by: Laszlo Ersek <ler...@redhat.com>
> >>> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> >>> Cc: Julien Grall <julien.gr...@linaro.org>
> >>> ---
> >>>  ArmVirtPkg/ArmVirt.dsc.inc   | 11 +++
> >>>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc |  3 ++-
> >>>  ArmVirtPkg/ArmVirtXen.fdf|  3 ++-
> >>>  3 files changed, 11 insertions(+), 6 deletions(-)
> >>
> >> Can you please incorporate points (2) and (3) as well, from my v3 review?
> >>
> >>   https://lists.01.org/pipermail/edk2-devel/2017-November/018191.html
> >
> > I fixed up the commit message as described above.
> >
> > I also test-built the ArmVirtQemu, ArmVirtQemuKernel and ArmVirtXen
> > platforms, with the patch applied, for ARM and AARCH64.
> >
> > [ler...@redhat.com: extend commit message]
> > Reviewed-by: Laszlo Ersek <ler...@redhat.com>
> > Build-tested-by: Laszlo Ersek <ler...@redhat.com>
> >
> > Commit 59fcf0706bf4.
> >
> 
> Thanks for taking care of this. The build had been broken long enough
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 6/6] OvmfPkg: Add tftp dynamic command

[Ni, Ruiyu]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, November 29, 2017 6:54 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Cc: Anthony Perard <anthony.per...@citrix.com>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Ard Biesheuvel <ard.biesheu...@linaro.org>;
> Carsey, Jaben <jaben.car...@intel.com>
> Subject: Re: [edk2] [PATCH v3 6/6] OvmfPkg: Add tftp dynamic command
> 
> Hi Ray,
> 
> On 11/29/17 01:59, Ruiyu Ni wrote:
> > The TFTP command was converted from a NULL class library instance
> > to a dynamic shell command in commit 0961002352e9.
> > This patch complements commit f9bc2f876326, which only removed the
> > old library, but didn't add the new dynamic command。
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Jordan Justen <jordan.l.jus...@intel.com>
> > Reviewed-by: Laszlo Ersek <ler...@redhat.com>
> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> > Cc: Anthony Perard <anthony.per...@citrix.com>
> > Cc: Julien Grall <julien.gr...@linaro.org>
> > ---
> >  OvmfPkg/OvmfPkgIa32.dsc| 7 +--
> >  OvmfPkg/OvmfPkgIa32.fdf| 3 ++-
> >  OvmfPkg/OvmfPkgIa32X64.dsc | 7 +--
> >  OvmfPkg/OvmfPkgIa32X64.fdf | 3 ++-
> >  OvmfPkg/OvmfPkgX64.dsc | 7 +--
> >  OvmfPkg/OvmfPkgX64.fdf | 3 ++-
> >  6 files changed, 21 insertions(+), 9 deletions(-)
> 
> after v1 I asked for some changes, and gave my R-b conditional on those
> changes:
> 
> http://mid.mail-archive.com/fe382f8c-0c1a-f66c-cbba-
> a18a7ed37...@redhat.com
> 
> The v2 and v3 versions of the same patch contain code that were (a) not
> present in v1 and (b) not requested by me after v1. So, I could not have
> seen that code or commented on it. I don't think my R-b from v1 should
> have been carried forward to v3, and then used as the basis for pushing
> the v3 patch as 984ba6a46747.
> 
> The commit message doesn't say anything about PcdShellLibAutoInitialize,
> and about the removal of the FileHandleLib resolution.
> 
> The removal of the FileHandleLib resolution under Shell.inf was
> justified, of course (because it was a duplicate / unnecessary
> resolution), but it should have been broken out to a separate patch, or
> at least mentioned in the commit message.
> 
> Also I can find PcdShellLibAutoInitialize in "ShellPkg.dec",
> 
>   ## This flag is used to control initialization of the shell library
>   #  This should be FALSE for compiling the shell application itself only.
> 
> but quoting it in the commit message is helpful. The general idea is to
> spend a bit more time on patch creation so that review is faster/easier
> (there could be multiple reviewers, and in the future the commit could
> be consulted several times).

It's late because I already pushed the patch.:(

> 
> In fact, given how "PcdShellLibAutoInitialize" is now used in the OVMF
> DSC files, I would say that the description in "ShellPkg.dec" is now out
> of date. The documentation should say that the PCD should be FALSE for
> the shell application itself, *plus* DXE_DRIVER modules that implement
> dynamic shell commands.

You are correct. I had another patch to modify the comments in ShellPkg.dec.

> 
> 
> I'm doing my best to be responsive; please give me a chance to comment
> on OvmfPkg changes that I've never seen or requested.

Ok.

> 
> Thanks
> Laszlo
> 
> > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> > index 19fa0b4c8d..9d23f8c162 100644
> > --- a/OvmfPkg/OvmfPkgIa32.dsc
> > +++ b/OvmfPkg/OvmfPkgIa32.dsc
> > @@ -193,6 +193,7 @@ [LibraryClasses]
> >TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf
> >  !endif
> >
> > +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> >
> S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScript
> Lib.inf
> >SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
> >
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/
> BaseOrderedCollectionRedBlackTreeLib.inf
> > @@ -783,6 +784,10 @@ [Components]
> >  !endif
> >
> >  !ifndef $(USE_OLD_SHELL)
> > +
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> {
> > +
> > +  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > +  }
> >ShellPkg/Application/Shell/Shell.inf {
> >  
> >
> ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLi
> b.inf
> > @@ -797,8 

Re: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to Tftp library removal

[Ni, Ruiyu]

I see. Thanks.
I will revise the commit message and send out in V4.

BTW, which mail client are you using?
All mails from lists.01.org are flatly shown in my Outlook, which is very hard
to track.

Thanks/Ray

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, November 29, 2017 5:59 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>
> Cc: edk2-devel@lists.01.org; Laszlo Ersek <ler...@redhat.com>
> Subject: Re: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to Tftp
> library removal
> 
> On 29 November 2017 at 09:57, Ni, Ruiyu <ruiyu...@intel.com> wrote:
> > I didn't see Laszlo provided any comments for this patch.
> 
> https://lists.01.org/pipermail/edk2-devel/2017-November/018124.html
> 
> > Did you mean the below comments from him for OvmfPkg's change?
> >
> > (1) Please add the following to the commit message:
> > "The TFTP command was converted from a NULL class library instance to a
> dynamic shell command in commit 0961002352e9. This patch complements
> commit f9bc2f876326, which only removed the old library, but didn't add the
> new dynamic command."
> >
> > Thanks/Ray
> >
> >> -Original Message-----
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: Wednesday, November 29, 2017 5:45 PM
> >> To: Ni, Ruiyu <ruiyu...@intel.com>
> >> Cc: edk2-devel@lists.01.org; Laszlo Ersek <ler...@redhat.com>
> >> Subject: Re: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to
> Tftp
> >> library removal
> >>
> >> On 29 November 2017 at 09:36, Ni, Ruiyu <ruiyu...@intel.com> wrote:
> >> > Ard,
> >> > Would you mind to give a r-b for this patch?
> >> >
> >>
> >> Hi Ray,
> >>
> >> Could you please incorporate the feedback you received from Laszlo first?
> >> Thanks.
> >>
> >>
> >> >
> >> >> -Original Message-
> >> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> >> Of Ruiyu Ni
> >> >> Sent: Wednesday, November 29, 2017 9:00 AM
> >> >> To: edk2-devel@lists.01.org
> >> >> Cc: Laszlo Ersek <ler...@redhat.com>; Ard Biesheuvel
> >> >> <ard.biesheu...@linaro.org>
> >> >> Subject: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to
> >> >> Tftp library removal
> >> >>
> >> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> >> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> >> >> Cc: Laszlo Ersek <ler...@redhat.com>
> >> >> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> >> >> Cc: Julien Grall <julien.gr...@linaro.org>
> >> >> ---
> >> >>  ArmVirtPkg/ArmVirt.dsc.inc   | 11 +++
> >> >>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc |  3 ++-
> >> >>  ArmVirtPkg/ArmVirtXen.fdf|  3 ++-
> >> >>  3 files changed, 11 insertions(+), 6 deletions(-)
> >> >>
> >> >> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> >> >> index 5d7edff104..9874637a3d 100644
> >> >> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> >> >> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> >> >> @@ -1,7 +1,7 @@
> >> >>  #
> >> >>  #  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
> >> >>  #  Copyright (c) 2014, Linaro Limited. All rights reserved.
> >> >> -#  Copyright (c) 2015, Intel Corporation. All rights reserved.
> >> >> +#  Copyright (c) 2015 - 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 @@
> >> >> -55,6 +55,8 @@ [LibraryClasses.common]
> >> >>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
> >> >>
> >> >>
> UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiSer
> >> >> UefiHiiServicesLib|vice
> >> >> sLib.inf
> >> >>SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
> >> >> +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> >> >> +
> >> >> +
> FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.in
> >> >> + f
> >> >>
> >>

Re: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to Tftp library removal

[Ni, Ruiyu]

I didn't see Laszlo provided any comments for this patch.
Did you mean the below comments from him for OvmfPkg's change?

(1) Please add the following to the commit message:
"The TFTP command was converted from a NULL class library instance to a dynamic 
shell command in commit 0961002352e9. This patch complements commit 
f9bc2f876326, which only removed the old library, but didn't add the new 
dynamic command."

Thanks/Ray

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, November 29, 2017 5:45 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>
> Cc: edk2-devel@lists.01.org; Laszlo Ersek <ler...@redhat.com>
> Subject: Re: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to Tftp
> library removal
> 
> On 29 November 2017 at 09:36, Ni, Ruiyu <ruiyu...@intel.com> wrote:
> > Ard,
> > Would you mind to give a r-b for this patch?
> >
> 
> Hi Ray,
> 
> Could you please incorporate the feedback you received from Laszlo first?
> Thanks.
> 
> 
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Ruiyu Ni
> >> Sent: Wednesday, November 29, 2017 9:00 AM
> >> To: edk2-devel@lists.01.org
> >> Cc: Laszlo Ersek <ler...@redhat.com>; Ard Biesheuvel
> >> <ard.biesheu...@linaro.org>
> >> Subject: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to
> >> Tftp library removal
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> >> Cc: Laszlo Ersek <ler...@redhat.com>
> >> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> >> Cc: Julien Grall <julien.gr...@linaro.org>
> >> ---
> >>  ArmVirtPkg/ArmVirt.dsc.inc   | 11 +++
> >>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc |  3 ++-
> >>  ArmVirtPkg/ArmVirtXen.fdf|  3 ++-
> >>  3 files changed, 11 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> >> index 5d7edff104..9874637a3d 100644
> >> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> >> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> >> @@ -1,7 +1,7 @@
> >>  #
> >>  #  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
> >>  #  Copyright (c) 2014, Linaro Limited. All rights reserved.
> >> -#  Copyright (c) 2015, Intel Corporation. All rights reserved.
> >> +#  Copyright (c) 2015 - 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 @@
> >> -55,6 +55,8 @@ [LibraryClasses.common]
> >>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
> >>
> >> UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiSer
> >> UefiHiiServicesLib|vice
> >> sLib.inf
> >>SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
> >> +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> >> +
> >> + FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.in
> >> + f
> >>
> >>UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
> >>
> >>
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTree
> >> OrderedCollectionLib|L
> >> ib/BaseOrderedCollectionRedBlackTreeLib.inf
> >> @@ -217,8 +219,6 @@ [LibraryClasses.common.UEFI_APPLICATION]
> >>
> >>
> PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerforma
> >> nceLib.inf
> >>
> >>
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemo
> >> ryAllocationLib.inf
> >>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
> >> -  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> >> -
> >> FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> >>
> >>  [LibraryClasses.common.UEFI_DRIVER]
> >>
> >>
> UefiDecompressLib|IntelFrameworkModulePkg/Library/BaseUefiTianoCusto
> >> mDecompressLib/BaseUefiTianoCustomDecompressLib.inf
> >> @@ -383,6 +383,10 @@ [Components.common]
> >>#
> >># UEFI application (Shell Embedded Boot Loader)
> >>#
> >> +
> >>
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.
> >> inf {
> >> +
> >> +  gEfiShellPkgTokenSpac

Re: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to Tftp library removal

[Ni, Ruiyu]

Ard,
Would you mind to give a r-b for this patch?

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ruiyu Ni
> Sent: Wednesday, November 29, 2017 9:00 AM
> To: edk2-devel@lists.01.org
> Cc: Laszlo Ersek <ler...@redhat.com>; Ard Biesheuvel
> <ard.biesheu...@linaro.org>
> Subject: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to Tftp
> library removal
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: Julien Grall <julien.gr...@linaro.org>
> ---
>  ArmVirtPkg/ArmVirt.dsc.inc   | 11 +++
>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc |  3 ++-
>  ArmVirtPkg/ArmVirtXen.fdf|  3 ++-
>  3 files changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index
> 5d7edff104..9874637a3d 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -1,7 +1,7 @@
>  #
>  #  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
>  #  Copyright (c) 2014, Linaro Limited. All rights reserved.
> -#  Copyright (c) 2015, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2015 - 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 @@ -55,6 +55,8
> @@ [LibraryClasses.common]
>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
> 
> UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiService
> sLib.inf
>SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
> +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> 
>UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
> 
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeL
> ib/BaseOrderedCollectionRedBlackTreeLib.inf
> @@ -217,8 +219,6 @@ [LibraryClasses.common.UEFI_APPLICATION]
> 
> PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerforma
> nceLib.inf
> 
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemo
> ryAllocationLib.inf
>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
> -  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> -  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> 
>  [LibraryClasses.common.UEFI_DRIVER]
> 
> UefiDecompressLib|IntelFrameworkModulePkg/Library/BaseUefiTianoCusto
> mDecompressLib/BaseUefiTianoCustomDecompressLib.inf
> @@ -383,6 +383,10 @@ [Components.common]
>#
># UEFI application (Shell Embedded Boot Loader)
>#
> +
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.
> inf {
> +
> +  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> +  }
>ShellPkg/Application/Shell/Shell.inf {
>  
> 
> ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellComma
> ndLib.inf
> @@ -393,7 +397,6 @@ [Components.common]
> 
> NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Com
> mandsLib.inf
> 
> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1Com
> mandsLib.inf
> 
> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1
> CommandsLib.inf
> -
> NULL|ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib
> .inf
> 
> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingL
> ib.inf
>PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> 
> BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfg
> CommandLib.inf
> diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> index 744006d13c..89f95b2d99 100644
> --- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> +++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> @@ -1,7 +1,7 @@
>  #
>  #  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
>  #  Copyright (c) 2014-2016, Linaro Limited. All rights reserved.
> -#  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2015 - 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 @@ -103,6
> +103,7 @@ [FV.FvMain]
># UEFI application (Shell Embedded Boot Loader)
>#
>INF ShellPkg/Application/Shell/Shell.inf
> +  INF
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynami

Re: [edk2] [PATCH v3 4/6] BeagleBoardPkg: Fix build failure due to Tftp library removal

[Ni, Ruiyu]

Ard,
PcdShellLibAutoInitialize is specially set to FALSE in old code for Shell.efi 
build.
But in old code line 507, it is set FALSE for Shell.efi build.
So the global setting of this PCD can be removed.

Thanks/Ray

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, November 29, 2017 3:57 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>
> Cc: edk2-devel@lists.01.org; Leif Lindholm <leif.lindh...@linaro.org>
> Subject: Re: [PATCH v3 4/6] BeagleBoardPkg: Fix build failure due to Tftp
> library removal
> 
> On 29 November 2017 at 00:59, Ruiyu Ni <ruiyu...@intel.com> wrote:
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Leif Lindholm <leif.lindh...@linaro.org>
> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> > ---
> >  BeagleBoardPkg/BeagleBoardPkg.dsc | 16 +---
> >  BeagleBoardPkg/BeagleBoardPkg.fdf |  3 ++-
> >  2 files changed, 11 insertions(+), 8 deletions(-)
> >
> > diff --git a/BeagleBoardPkg/BeagleBoardPkg.dsc
> b/BeagleBoardPkg/BeagleBoardPkg.dsc
> > index 4f7c0bd645..d67ccf377e 100644
> > --- a/BeagleBoardPkg/BeagleBoardPkg.dsc
> > +++ b/BeagleBoardPkg/BeagleBoardPkg.dsc
> > @@ -2,7 +2,7 @@
> >  # Beagle board package.
> >  #
> >  # Copyright (c) 2009 - 2010, Apple Inc. All rights reserved.
> > -# Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
> > +# Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
> >  # Copyright (c) 2016, Linaro Ltd. All rights reserved.
> >  #
> >  #This program and the accompanying materials
> > @@ -355,11 +355,6 @@ [PcdsFixedAtBuild.common]
> ># OMAP Interrupt Controller
> >gEmbeddedTokenSpaceGuid.PcdInterruptBaseAddress|0x4820
> >
> > -  # We want to use the Shell Libraries but don't want it to initialise
> > -  # automatically. We initialise the libraries when the command is called 
> > by
> the
> > -  # Shell.
> > -  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > -
> 
> Why are you moving this? The TFTP shell library is not the only user
> of this PCD.
> 
> >gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|10
> >
> ># GUID of the UEFI Shell
> > @@ -487,6 +482,14 @@ [Components.common]
> >
> NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
> >
> NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMainte
> nanceManagerUiLib.inf
> >}
> > +
> > +  #
> > +  # Shell
> > +  #
> > +
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.
> inf {
> > +
> > +  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > +  }
> >ShellPkg/Application/Shell/Shell.inf {
> >  
> >
> ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellComma
> ndLib.inf
> > @@ -497,7 +500,6 @@ [Components.common]
> >
> NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Com
> mandsLib.inf
> >
> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1Com
> mandsLib.inf
> >
> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1
> CommandsLib.inf
> > -
> NULL|ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib
> .inf
> >
> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingL
> ib.inf
> >PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> >
> BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfg
> CommandLib.inf
> > diff --git a/BeagleBoardPkg/BeagleBoardPkg.fdf
> b/BeagleBoardPkg/BeagleBoardPkg.fdf
> > index c9c6afd714..71249c7eb3 100644
> > --- a/BeagleBoardPkg/BeagleBoardPkg.fdf
> > +++ b/BeagleBoardPkg/BeagleBoardPkg.fdf
> > @@ -1,7 +1,7 @@
> >  # FLASH layout file for Beagle board.
> >  #
> >  # Copyright (c) 2009, Apple Inc. All rights reserved.
> > -# Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
> > +# Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
> >  # Copyright (c) 2016, Linaro, Ltd. All rights reserved.
> >  #
> >  #This program and the accompanying materials
> > @@ -178,6 +178,7 @@ [FV.FvMain]
> ># UEFI application (Shell Embedded Boot Loader)
> >#
> >INF ShellPkg/Application/Shell/Shell.inf
> > +  INF
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.
> inf
> >
> >#
> ># Bds
> > --
> > 2.15.0.gvfs.1.preview.4
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Add Ruiyu as MdeModulePkg reviewer

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, November 28, 2017 6:02 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [PATCH] Add Ruiyu as MdeModulePkg reviewer
> 
> Add Ruiyu as MdeModulePkg reviewer,
> especially for some Domains.
> 
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng <star.z...@intel.com>
> ---
>  Maintainers.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt index
> ffb69c17fe2e..fbfc74e183ba 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -168,6 +168,9 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
>  M: Star Zeng <star.z...@intel.com>
>  M: Eric Dong <eric.d...@intel.com>
>  M: NetworkPkg maintainers (Universal/Network)
> +R: Ruiyu Ni <ruiyu...@intel.com>
> +  (especially for Bus, Universal/Console, Universal/Disk,
> +   Universal/BdsDxe and related libraries, header files)
> 
>  MdePkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/MdePkg
> --
> 2.7.0.windows.1

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

Re: [edk2] [PATCH v2 2/3] ShellPkg/tftp: Convert from NULL class library to Dynamic Command

[Ni, Ruiyu]

I just realized OVMF platform is referencing the INF.
I will search in all edkII code.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Tuesday, November 28, 2017 3:35 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH v2 2/3] ShellPkg/tftp: Convert from NULL class
> library to Dynamic Command
> 
> On 27 November 2017 at 05:55, Ruiyu Ni <ruiyu...@intel.com> wrote:
> > UEFI Shell spec defines Shell Dynamic Command protocol which is just
> > for the purpose to extend internal command.
> > So tftp command is changed from NULL class library to be a driver
> > producing DynamicCommand protocol.
> >
> > The guideline is:
> > 1. Only use NULL class library for Shell spec defined commands.
> > 2. New commands can be provided as not only a standalone application
> >but also a dynamic command. So it can be used either as an
> >internal command, but also as a standalone application.
> >
> > TftpApp.inf is to provide a standalone application.
> > TftpDynamicCommand.inf is to provide a standalone driver producing
> > Dynamic Command protocol.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Jaben Carsey <jaben.car...@intel.com>
> > Cc: Michael D Kinney <michael.d.kin...@intel.com>
> > ---
> >  .../TftpDynamicCommand}/Tftp.c |  92 +++
> >  .../TftpDynamicCommand/Tftp.h} |  40 +--
> >  .../TftpDynamicCommand/Tftp.uni}   |   0
> >  .../DynamicCommand/TftpDynamicCommand/TftpApp.c|  54
> +
> >  .../TftpDynamicCommand/TftpApp.inf}|  34 +++---
> >  .../TftpDynamicCommand/TftpDynamicCommand.c| 131
> +
> >  .../TftpDynamicCommand/TftpDynamicCommand.inf} |  39 +++---
> >  .../UefiShellTftpCommandLib.c  |  97 ---
> >  ShellPkg/ShellPkg.dsc  |  11 +-
> >  9 files changed, 325 insertions(+), 173 deletions(-)
> 
> Please make sure that you fix platforms that use .inf files when renaming
> them.
> The ArmVirtQemu build is currently broken due to this patch.
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] MdeModulePkg/AtaAtapiPassThru: Revert patch to disable PCI attributes

[Ni, Ruiyu]

Laszlo,
The Windows resume issue is urgent to fix.
I'd like to check-in the patches first.
If I didn't know the change may cause combability issue, I'd be very fine
to change it to AhciReset() then submit the patch, then after got a R-b,
I'd be very happy to check in that patch.
But since now I know there might be some combability issue, I don't
want to switch to AhciReset() solution without thoroughly testing.
And frankly I don't know what a thoroughly testing would be like.
There are many OSes and many PCI storage cards! ☹

Thanks/Ray

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, November 27, 2017 10:10 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>
> Cc: edk2-devel@lists.01.org; Paolo Bonzini <pbonz...@redhat.com>; Yao,
> Jiewen <jiewen@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH 0/2] MdeModulePkg/AtaAtapiPassThru: Revert
> patch to disable PCI attributes
> 
> Hello Ray,
> 
> On 11/27/17 02:19, Ruiyu Ni wrote:
> > The patches caused Windows 10 S4 resume failure.
> > Considering the similar changes are reverted from PciBus driver,
> > revert the patches from AtaAtapiPassThru as well.
> >
> > Ruiyu Ni (2):
> >   MdeModulePkg/AtaAtapiPassThru: Revert patch to disable Bus Master
> >   MdeModulePkg/AtaAtapiPassThru: Revert patch to disable PCI
> > attributes
> >
> >  .../Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c| 58 
> > +
> -
> >  .../Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h|  5 --
> >  2 files changed, 1 insertion(+), 62 deletions(-)
> >
> 
> it looks like these patches have not been committed yet, which is a good
> thing, because apparently there's a better solution than a full revert.
> Namely, in the other sub-thread at
> <http://mid.mail-archive.com/0236afa2-e365-af7a-9374-
> 7fd1ad742...@redhat.com>
> (alternative link:
> <https://lists.01.org/pipermail/edk2-devel/2017-November/018046.html>),
> Jiewen and Star seem to accept AhciReset() as a better way to abort pending
> DMA.
> 
> This means that we need not revert the EBS-handler altogether, only change
> what it does. Could you give that a try please?
> 
> (If the Windows regression is very urgent to fix, then I don't mind if the Bus
> Master disabling is removed separately, before AhciReset() is added; but in
> that case, a full revert looks unjustified, since the EBS handler will have 
> to be
> re-added for AhciReset() anyway.)
> 
> Thanks,
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] PcAtChipsetPkg: Add description for new added PCD in commit e78aab9d2

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Bi, Dandan
> Sent: Tuesday, November 28, 2017 11:51 AM
> To: edk2-devel@lists.01.org
> Cc: Leo Duran <leo.du...@amd.com>; Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [patch] PcAtChipsetPkg: Add description for new added PCD in
> commit e78aab9d2
> 
> Cc: Leo Duran <leo.du...@amd.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  PcAtChipsetPkg/PcAtChipsetPkg.uni | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/PcAtChipsetPkg/PcAtChipsetPkg.uni
> b/PcAtChipsetPkg/PcAtChipsetPkg.uni
> index 530e9ae..00169ce 100644
> --- a/PcAtChipsetPkg/PcAtChipsetPkg.uni
> +++ b/PcAtChipsetPkg/PcAtChipsetPkg.uni
> @@ -154,5 +154,14 @@
>  "Reset Control Register value for cold reset"
> 
>  #string
> STR_gPcAtChipsetPkgTokenSpaceGuid_PcdResetControlValueColdReset_HE
> LP
>  #language en-US
>  "8bit Reset Control Register value for cold reset."
> +
> +#string
> STR_gPcAtChipsetPkgTokenSpaceGuid_PcdInitialValueRtcRegisterA_PROMP
> T  #language en-US "Initial value for Register_A in RTC."
> +#string
> STR_gPcAtChipsetPkgTokenSpaceGuid_PcdInitialValueRtcRegisterA_HELP
> #language en-US "Specifies the initial value for Register_A in RTC."
> +
> +#string
> STR_gPcAtChipsetPkgTokenSpaceGuid_PcdInitialValueRtcRegisterB_PROMP
> T  #language en-US "Initial value for Register_B in RTC."
> +#string
> STR_gPcAtChipsetPkgTokenSpaceGuid_PcdInitialValueRtcRegisterB_HELP
> #language en-US "Specifies the initial value for Register_B in RTC."
> +
> +#string
> STR_gPcAtChipsetPkgTokenSpaceGuid_PcdInitialValueRtcRegisterD_PROMP
> T  #language en-US "Initial value for Register_D in RTC."
> +#string
> STR_gPcAtChipsetPkgTokenSpaceGuid_PcdInitialValueRtcRegisterD_HELP
> #language en-US "Specifies the initial value for Register_D in RTC."
> --
> 1.9.5.msysgit.1

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

Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at ExitBootServices()

[Ni, Ruiyu]

Maybe win10 does some optimization in S4 path.

Sent from a small-screen device

在 2017年11月24日，上午8:01，Paolo Bonzini 
<pbonz...@redhat.com<mailto:pbonz...@redhat.com>> 写道：

On 23/11/2017 14:08, Laszlo Ersek wrote:
On 11/23/17 03:20, Ni, Ruiyu wrote:
I cannot explain precisely why the S4 resume fails.
I can just guess: Windows might have some assumptions on the BM bit.
Can we make this configurable on the platform level somehow?

On one hand, I certainly don't want to break Windows 10, even in case
this issue ultimately turns out to be a Windows 10 bug.

On the other hand, OVMF does not support S4, and disabling BMDMA at
ExitBootServices() in PCI drivers is specifically what the Driver
Writers' Guide recommends. Otherwise pending DMA could corrupt OS memory.

S4 can be done by the OS even if firmware says it doesn't support it.

Once hibernation is done, it is merely a "courtesy" for the OSPM to turn
off the computer using the _S4 ACPI object rather than _S5.

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

Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at ExitBootServices()

[Ni, Ruiyu]

Sent from a small-screen device

在 2017年11月24日，上午1:19，Laszlo Ersek <ler...@redhat.com<mailto:ler...@redhat.com>> 
写道：

On 11/23/17 15:58, Ni, Ruiyu wrote:
Laszlo,
A S3 flag PCD was added to optimize boot flow. Let's say,
setting the flag to false is to remove some unnecessary code.
setting to true is also fine.

But in this case, setting S4 flag to false is to add some incompatible code.
It's a bit different.

If you check the two patches to revert the PciBus change, Microsoft gave
their Signed-off.

Of course they did: Windows 10 is a Microsoft OS; they obviously will
not want to break their own OS with firmware changes. :)

Anyway, joking aside, as I said, I *do* want to keep Windows 10 in
working shape. I'm just saying that this should be a platform choice. On
some platforms, the AtaAtapiPassThru EBS handler does not tickle the bug
in Windows 10, so on those platforms, it makes sense to do what the DWG
recommends (and keep the code).

If you strongly disagree with allowing customization for this code, then:

(1) Can you please submit a two part series that reverts the following
patches (in this order):

(a) revert 76fd5a660d704538a1b14a58d03a4eef9682b01c
(b) revert 6fb8ddd36bde45614b0a069528cdc97077835a74

This will keep a good git history, and I'll ACK these reverts.

Thanks for your understanding. I do need to revert the EBS handler, because it 
causes a critical S4 resume failure. I will revert them in your suggested way.

Hopefully, the changes in PciBus could be back in future when the OS code is 
changed.


(2) I'll file a down-stream (Red Hat) Bugzilla to make sure we keep the
EBS handler as it is now (at 8284b1791ea9) when we next rebase to
upstream edk2 (as long as we don't support S4).

Thanks,
Laszlo


/Ray

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Thursday, November 23, 2017 9:08 PM
To: Ni, Ruiyu <ruiyu...@intel.com<mailto:ruiyu...@intel.com>>; Zeng, Star 
<star.z...@intel.com<mailto:star.z...@intel.com>>; edk2-
devel-01 <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Ard Biesheuvel 
<ard.biesheu...@linaro.org<mailto:ard.biesheu...@linaro.org>>; Dong, Eric
<eric.d...@intel.com<mailto:eric.d...@intel.com>>; Dann Frazier 
<da...@ubuntu.com<mailto:da...@ubuntu.com>>
Subject: Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-
DMA at ExitBootServices()

On 11/23/17 03:20, Ni, Ruiyu wrote:
I cannot explain precisely why the S4 resume fails.
I can just guess: Windows might have some assumptions on the BM bit.

Can we make this configurable on the platform level somehow?

On one hand, I certainly don't want to break Windows 10, even in case this issue
ultimately turns out to be a Windows 10 bug.

On the other hand, OVMF does not support S4, and disabling BMDMA at
ExitBootServices() in PCI drivers is specifically what the Driver Writers' Guide
recommends. Otherwise pending DMA could corrupt OS memory.

So, for OVMF at least, I'd like to keep the present behavior, but for other
platforms, I don't insist on disabling BMDMA, of course.

We already have a PCD called "PcdAcpiS3Enable" in "MdeModulePkg.dec";
maybe we can introduce "PcdAcpiS4Enable" too.

BTW, has anyone reported this S4 issue to Microsoft? (Personally I'm totally
unable to talk to Microsoft -- no working communication channels seem to be
accessible to me. I hope Intel might fare better.) I wonder what their opinion
would be on the issue.

Thanks,
Laszlo

-Original Message-
From: Zeng, Star
Sent: Wednesday, November 22, 2017 6:26 PM
To: Ni, Ruiyu <ruiyu...@intel.com<mailto:ruiyu...@intel.com>>; Laszlo Ersek 
<ler...@redhat.com<mailto:ler...@redhat.com>>;
edk2-devel-01 <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Ard Biesheuvel 
<ard.biesheu...@linaro.org<mailto:ard.biesheu...@linaro.org>>; Dong, Eric
<eric.d...@intel.com<mailto:eric.d...@intel.com>>; Dann Frazier 
<da...@ubuntu.com<mailto:da...@ubuntu.com>>; Zeng, Star
<star.z...@intel.com<mailto:star.z...@intel.com>>
Subject: RE: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable
only BM-DMA at ExitBootServices()

Ray,

You may explain more why Win10 S4 resume fails with only BM disabled,
then Laszlo can know the issue well.


Thanks,
Star
-Original Message-
From: Ni, Ruiyu
Sent: Wednesday, November 22, 2017 6:06 PM
To: Laszlo Ersek <ler...@redhat.com<mailto:ler...@redhat.com>>; edk2-devel-01 
mailto:de...@lists.01.org>>
Cc: Ard Biesheuvel 
<ard.biesheu...@linaro.org<mailto:ard.biesheu...@linaro.org>>; Dong, Eric
<eric.d...@intel.com<mailto:eric.d...@intel.com>>; Zeng, Star 
<star.z...@intel.com<mailto:star.z...@intel.com>>; Dann Frazier
<da...@ubuntu.com<mailto:da...@ubuntu.com>>
Subject: RE: [edk2] [PATCH] MdeModulePkg/Ata

Re: [edk2] [PATCH 3/5] MdeModulePkg/UefiBootManagerLib: report EDKII_OS_LOADER_DETAIL status code

[Ni, Ruiyu]

Sent from a small-screen device

在 2017年11月24日，上午1:08，Laszlo Ersek <ler...@redhat.com<mailto:ler...@redhat.com>> 
写道：

On 11/23/17 15:53, Ni, Ruiyu wrote:
Comments below.

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Thursday, November 23, 2017 10:03 PM
To: Ni, Ruiyu <ruiyu...@intel.com<mailto:ruiyu...@intel.com>>; edk2-devel-01 
<edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Ard Biesheuvel 
<ard.biesheu...@linaro.org<mailto:ard.biesheu...@linaro.org>>; Justen, Jordan L
<jordan.l.jus...@intel.com<mailto:jordan.l.jus...@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>; Zeng, Star
<star.z...@intel.com<mailto:star.z...@intel.com>>; Doran, Mark 
<mark.do...@intel.com<mailto:mark.do...@intel.com>>
Subject: Re: [PATCH 3/5] MdeModulePkg/UefiBootManagerLib: report
EDKII_OS_LOADER_DETAIL status code

Hello Ray,

(CC Mark Doran for the last part of my email)

On 11/23/17 06:21, Ni, Ruiyu wrote:
Laszlo,
When booting a boot option, UefiBootManagerBoot() sets a Boot
variable and saves  to BootCurrent variable.
So all the details (except the EDKII_OS_LOADER_DETAIL.Status) can be
retrieved from reading Boot variable.

I have two counter-arguments:

(1) I would like to minimize the number of accesses to non-volatile UEFI
variables. Dependent on the virtualization platform and the (virtual) flash chip
structure (for example, flash block size), flash access can be very slow.

I'm not 100% sure whether this performance problem affects flash *reads* as
well, or if it affects flash writes only. (It definitely affects flash writes.)

NV *read* should have no performance impact since EDKII variable driver's
implementation caches the flash in memory. I am not sure about that
in OVMF.

Yeah it should work the same. Thanks!

But I think a good implementation of variable driver should
consider such *read* optimization.
Performance needs to be considered, but simpler/easy-maintain
code takes higher priority.



(2) The delivery of status codes to registered handlers is asynchronous, not
synchronous. Handlers are registered at various task priority levels, and if the
reporting occurs at the same or higher TPL, then the delivery will be delayed.
(According to the PI spec, it is even possible to report several status codes
before the first will be delivered -- basically the codes are queued until the 
TPL is
reduced sufficiently.) This is why all data has to be embedded in the status 
code
structure itself.

Like in any other notify function's case, it is prudent to register status code
handlers at the least strict TPL that can work for the actual processing. (The
internals of the handler function can even put an upper limit on the TPL; for
example using Simple Text Output prevents us from going higher than
TPL_NOTIFY.) For this reason I chose TPL_CALLBACK for the OVMF status code
handler.

Now, if we can *guarantee* that these status codes are only reported at the
TPL_APPLICATION level, then a TPL_CALLBACK status code handler will be
synchronous in effect, and then the status code structure can carry references
to other (external) things in the system too, such as UEFI variables.

Can we guarantee that EfiBootManagerBoot() is never invoked above
TPL_APPLICATION?
Yes. It should be. Because gBS->LoadImage()/StartImage() per UEFI spec TPL
restriction rule, should be run at TPL_APPLICATION.
And if there is no special reason (handler runs too slow), the status handler
is registered at TPL_HIGH so that the handler is called synchronously.

OK, the TPL_APPLICATION promise will work for me. I missed the LoadImage
/ StartImage implications; good point!

(I can't register the handler at TPL_HIGH, because the handler calls
AsciiPrint, which internally uses gST->ConOut, and that (i.e.,
SimpleTextOut) cannot be used above TPL_NOTIFY. But the TPL_CALLBACK
handler will work fine with the TPL_APPLICATION report.)

TPL_HIGH is just an indicator to tell status router to call the handler in 
blocking or synchronized way. So handler actually works in the status code 
reporter’s TPL, which is TPL_APPLICATION.






4 more comments below.

[snip]

+  BmReportOsLoaderDetail (
+OsLoaderDetail,
+OsLoaderDetailSize,
+EDKII_OS_LOADER_DETAIL_TYPE_LOAD,
+0 // DetailStatus -- unused here
+);
+

1. With the BootCurrent, this change is not necessary because others
can hook PcdProgressCodeOsLoaderLoad to get the current loading boot
option.

As long as we can clear my points (1) and (2) above, I'd be fine with this
approach.


  Status = gBS->LoadImage (
  TRUE,
  gImageHandle,
  FilePath,
  FileBuffer,
  FileSize,
  
  );
}
if (File

Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at ExitBootServices()

[Ni, Ruiyu]

Laszlo,
A S3 flag PCD was added to optimize boot flow. Let's say,
setting the flag to false is to remove some unnecessary code.
setting to true is also fine.

But in this case, setting S4 flag to false is to add some incompatible code.
It's a bit different.

If you check the two patches to revert the PciBus change, Microsoft gave
their Signed-off.

/Ray 

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, November 23, 2017 9:08 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>; edk2-
> devel-01 <edk2-devel@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Dong, Eric
> <eric.d...@intel.com>; Dann Frazier <da...@ubuntu.com>
> Subject: Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-
> DMA at ExitBootServices()
> 
> On 11/23/17 03:20, Ni, Ruiyu wrote:
> > I cannot explain precisely why the S4 resume fails.
> > I can just guess: Windows might have some assumptions on the BM bit.
> 
> Can we make this configurable on the platform level somehow?
> 
> On one hand, I certainly don't want to break Windows 10, even in case this 
> issue
> ultimately turns out to be a Windows 10 bug.
> 
> On the other hand, OVMF does not support S4, and disabling BMDMA at
> ExitBootServices() in PCI drivers is specifically what the Driver Writers' 
> Guide
> recommends. Otherwise pending DMA could corrupt OS memory.
> 
> So, for OVMF at least, I'd like to keep the present behavior, but for other
> platforms, I don't insist on disabling BMDMA, of course.
> 
> We already have a PCD called "PcdAcpiS3Enable" in "MdeModulePkg.dec";
> maybe we can introduce "PcdAcpiS4Enable" too.
> 
> BTW, has anyone reported this S4 issue to Microsoft? (Personally I'm totally
> unable to talk to Microsoft -- no working communication channels seem to be
> accessible to me. I hope Intel might fare better.) I wonder what their opinion
> would be on the issue.
> 
> Thanks,
> Laszlo
> 
> >> -Original Message-
> >> From: Zeng, Star
> >> Sent: Wednesday, November 22, 2017 6:26 PM
> >> To: Ni, Ruiyu <ruiyu...@intel.com>; Laszlo Ersek <ler...@redhat.com>;
> >> edk2-devel-01 <edk2-devel@lists.01.org>
> >> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Dong, Eric
> >> <eric.d...@intel.com>; Dann Frazier <da...@ubuntu.com>; Zeng, Star
> >> <star.z...@intel.com>
> >> Subject: RE: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable
> >> only BM-DMA at ExitBootServices()
> >>
> >> Ray,
> >>
> >> You may explain more why Win10 S4 resume fails with only BM disabled,
> >> then Laszlo can know the issue well.
> >>
> >>
> >> Thanks,
> >> Star
> >> -Original Message-
> >> From: Ni, Ruiyu
> >> Sent: Wednesday, November 22, 2017 6:06 PM
> >> To: Laszlo Ersek <ler...@redhat.com>; edk2-devel-01  >> de...@lists.01.org>
> >> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Dong, Eric
> >> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>; Dann Frazier
> >> <da...@ubuntu.com>
> >> Subject: RE: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable
> >> only BM-DMA at ExitBootServices()
> >>
> >> Laszlo,
> >> Our QA found Win10 S4 resume fails due to your change.
> >> As you might notice that I just rolled back the BM disabling patches
> >> in PciBus module, I am thinking about maybe you need to rollback the
> >> whole ExitBootServices callback as well to fix the compatibility issue.
> >>
> >> Thanks/Ray
> >>
> >>> -Original Message-
> >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >>> Of Laszlo Ersek
> >>> Sent: Saturday, October 28, 2017 12:10 AM
> >>> To: edk2-devel-01 <edk2-devel@lists.01.org>
> >>> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Dong, Eric
> >>> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>; Dann
> >>> Frazier <da...@ubuntu.com>
> >>> Subject: Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable
> >>> only BM-DMA at ExitBootServices()
> >>>
> >>> On 10/26/17 17:48, Laszlo Ersek wrote:
> >>>> Clearing I/O port decoding in the PCI command register at
> >>>> ExitBootServices() breaks IDE boot in Windows, on QEMU's "pc"
> >>>> (i440fx) machine type. (AHCI boot on "q35&qu

Re: [edk2] [PATCH 3/5] MdeModulePkg/UefiBootManagerLib: report EDKII_OS_LOADER_DETAIL status code

[Ni, Ruiyu]

Laszlo,
When booting a boot option, UefiBootManagerBoot() sets a Boot variable
and saves  to BootCurrent variable.
So all the details (except the EDKII_OS_LOADER_DETAIL.Status) can be retrieved
from reading Boot variable.

4 more comments below.


Thanks/Ray

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, November 23, 2017 7:59 AM
> To: edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: [PATCH 3/5] MdeModulePkg/UefiBootManagerLib: report
> EDKII_OS_LOADER_DETAIL status code
> 
> The EfiBootManagerBoot() function reports progress codes about
> LoadImage() preparation and failure, and StartImage() preparation and
> failure. These codes are flat (scalar) constants.
> 
> Extend this by "broadcasting" the Boot option number, description,
> device path, and -- on load / start failure -- the error result at the same
> locations, through EFI_DEBUG_CODE reporting. Use the
> PcdDebugCodeOsLoaderDetail status code value and the
> EDKII_OS_LOADER_DETAIL status code structure introduced earlier in this
> series.
> 
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Star Zeng <star.z...@intel.com>
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
> ---
>  MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf |   2
> +
>  MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h   |  84
> ++
>  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |  51 +-
>  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c   | 166
> 
>  4 files changed, 301 insertions(+), 2 deletions(-)
> 
> diff --git
> a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
> b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
> index ad4901db5713..633906fc6ca4 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
> +++
> b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
> @@ -79,24 +79,25 @@ [Guids]
> 
>## SOMETIMES_PRODUCES ## Variable:L"BootCurrent" (The boot option of
> current boot)
>## SOMETIMES_CONSUMES ## Variable:L"BootXX" (Boot option variable)
>## SOMETIMES_CONSUMES ## Variable:L"BootOrder" (The boot option
> array)
>## SOMETIMES_CONSUMES ## Variable:L"DriverOrder" (The driver order
> list)
>## SOMETIMES_CONSUMES ## Variable:L"ConIn" (The device path of
> console in device)
>## SOMETIMES_CONSUMES ## Variable:L"ConOut" (The device path of
> console out device)
>## SOMETIMES_CONSUMES ## Variable:L"ErrOut" (The device path of
> error out device)
>gEfiGlobalVariableGuid
> 
>gPerformanceProtocolGuid  ## SOMETIMES_CONSUMES ##
> Variable:L"PerfDataMemAddr" (The ACPI address of performance data)
>gEdkiiStatusCodeDataTypeVariableGuid  ## SOMETIMES_CONSUMES
> ## GUID
> +  gEdkiiStatusCodeDataTypeOsLoaderDetailGuid##
> SOMETIMES_CONSUMES ## GUID
>gEfiDiskInfoAhciInterfaceGuid ## SOMETIMES_CONSUMES ##
> GUID
>gEfiDiskInfoIdeInterfaceGuid  ## SOMETIMES_CONSUMES ## GUID
>gEfiDiskInfoScsiInterfaceGuid ## SOMETIMES_CONSUMES ## GUID
>gEfiDiskInfoSdMmcInterfaceGuid## SOMETIMES_CONSUMES ##
> GUID
> 
>  [Protocols]
>gEfiPciRootBridgeIoProtocolGuid   ## CONSUMES
>gEfiSimpleFileSystemProtocolGuid  ## SOMETIMES_CONSUMES
>gEfiLoadFileProtocolGuid  ## SOMETIMES_CONSUMES
>gEfiSimpleTextOutProtocolGuid ## SOMETIMES_CONSUMES
>gEfiPciIoProtocolGuid ## SOMETIMES_CONSUMES
>gEfiLoadedImageProtocolGuid   ## CONSUMES
> @@ -112,16 +113,17 @@ [Protocols]
>gEfiUsbIoProtocolGuid ## SOMETIMES_CONSUMES
>gEfiNvmExpressPassThruProtocolGuid## SOMETIMES_CONSUMES
>gEfiDiskInfoProtocolGuid  ## SOMETIMES_CONSUMES
>gEfiDriverHealthProtocolGuid  ## SOMETIMES_CONSUMES
>gEfiFormBrowser2ProtocolGuid  ## SOMETIMES_CONSUMES
>g

Re: [edk2] [PATCH 1/5] MdeModulePkg/BdsDxe: fall back to a Boot Manager Menu loop before hanging

[Ni, Ruiyu]

Thanks for the patch. It follows the idea described in:
https://lists.01.org/pipermail/edk2-devel/2017-April/010294.html.

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, November 23, 2017 7:59 AM
> To: edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: [PATCH 1/5] MdeModulePkg/BdsDxe: fall back to a Boot Manager
> Menu loop before hanging
> 
> Under the following scenario:
> 
> - no UEFI bootable application available anywhere in the system,
> - ... not even for the default platform recovery option,
> - no shell is built into the firmware image,
> - but UiApp is available in the firmware image,
> 
> we should preferably not just hang in BdsEntry() with:
> 
>DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
>CpuDeadLoop ();
> 
> while the user sits at the TianoCore logo page, wondering what's going on.
> Print an informative message to the console, wait for a keypress, and then
> return to the Boot Manager Menu forever.
> 
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Star Zeng <star.z...@intel.com>
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=513
> Suggested-by: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
> ---
>  MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 60 ++-
> -
>  1 file changed, 56 insertions(+), 4 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> index dccc49090219..2b24755ac368 100644
> --- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> +++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> @@ -676,24 +676,73 @@ BdsAllocateMemoryForPerformanceData (
>  //
>  // Mark L"PerfDataMemAddr" variable to read-only if the Variable Lock
> protocol exists
>  // Still lock it even the variable cannot be saved to prevent it's set 
> by 3rd
> party code.
>  //
>  Status = gBS->LocateProtocol (, NULL,
> (VOID **) );
>  if (!EFI_ERROR (Status)) {
>Status = VariableLock->RequestToLock (VariableLock,
> L"PerfDataMemAddr", );
>ASSERT_EFI_ERROR (Status);
>  }
>}
>  }
> 
> +/**
> +  Enter an infinite loop of calling the Boot Manager Menu.
> +
> +  This is a last resort alternative to BdsEntry() giving up for good.
> + This  function never returns.
> +
> +  @param[in] BootManagerMenu  The
> EFI_BOOT_MANAGER_LOAD_OPTION located and/or
> +  created by the 
> EfiBootManagerGetBootManagerMenu()
> +  call in BdsEntry().
> +**/
> +VOID
> +BdsBootManagerMenuLoop (
> +  IN EFI_BOOT_MANAGER_LOAD_OPTION *BootManagerMenu
> +  )
> +{
> +  EFI_INPUT_KEY Key;
> +
> +  //
> +  // Normally BdsDxe does not print anything to the system console, but
> + this is  // a last resort -- the end-user will likely not see any
> + DEBUG messages  // logged in this situation.
> +  //
> +  // AsciiPrint() will NULL-check gST->ConOut internally. We check
> + gST->ConIn  // here to see if it makes sense to request and wait for a
> keypress.
> +  //
> +  if (gST->ConIn != NULL) {
> +AsciiPrint (
> +  "%a: No bootable option or device was found.\n"
> +  "%a: Press any key to enter the Boot Manager Menu.\n",
> +  gEfiCallerBaseName,
> +  gEfiCallerBaseName
> +  );
> +BdsWaitForSingleEvent (gST->ConIn->WaitForKey, 0);
> +
> +//
> +// Drain any queued keys.
> +//
> +while (!EFI_ERROR (gST->ConIn->ReadKeyStroke (gST->ConIn, ))) {
> +  //
> +  // just throw away Key
> +  //
> +}
> +  }
> +
> +  for (;;) {
> +EfiBootManagerBoot (BootManagerMenu);
> +  }
> +}
> +
>  /**
> 
>Service routine for BdsInstance->Entry(). Devices are connected, the
>consoles are initialized, and the boot options are tried.
> 
>@param This Protocol Instance structure.
> 
>  **/
>  VOID
>  EFIAPI
>  BdsEntry (
>IN EFI_BDS_ARCH_PROTOCOL  *This
> @@ -1079,34 +1128,37 @

Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at ExitBootServices()

[Ni, Ruiyu]

I cannot explain precisely why the S4 resume fails.
I can just guess: Windows might have some assumptions on the BM bit.

Thanks/Ray

> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, November 22, 2017 6:26 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; Laszlo Ersek <ler...@redhat.com>;
> edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Dong, Eric
> <eric.d...@intel.com>; Dann Frazier <da...@ubuntu.com>; Zeng, Star
> <star.z...@intel.com>
> Subject: RE: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only
> BM-DMA at ExitBootServices()
> 
> Ray,
> 
> You may explain more why Win10 S4 resume fails with only BM disabled,
> then Laszlo can know the issue well.
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, November 22, 2017 6:06 PM
> To: Laszlo Ersek <ler...@redhat.com>; edk2-devel-01  de...@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Dong, Eric
> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>; Dann Frazier
> <da...@ubuntu.com>
> Subject: RE: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only
> BM-DMA at ExitBootServices()
> 
> Laszlo,
> Our QA found Win10 S4 resume fails due to your change.
> As you might notice that I just rolled back the BM disabling patches in PciBus
> module, I am thinking about maybe you need to rollback the whole
> ExitBootServices callback as well to fix the compatibility issue.
> 
> Thanks/Ray
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Laszlo Ersek
> > Sent: Saturday, October 28, 2017 12:10 AM
> > To: edk2-devel-01 <edk2-devel@lists.01.org>
> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Dong, Eric
> > <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>; Dann Frazier
> > <da...@ubuntu.com>
> > Subject: Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable
> > only BM-DMA at ExitBootServices()
> >
> > On 10/26/17 17:48, Laszlo Ersek wrote:
> > > Clearing I/O port decoding in the PCI command register at
> > > ExitBootServices() breaks IDE boot in Windows, on QEMU's "pc"
> > > (i440fx) machine type. (AHCI boot on "q35" is unaffected.) Windows
> > > seems repeatedly stuck, apparently waiting for a timeout of sorts.
> > >
> > > This is arguably a Windows bug; a native OS driver should not expect
> > > the firmware to leave the PCI command register in any particular state.
> > >
> > > Strictly speaking, we only need to disable BM-DMA at
> > > ExitBootServices(), in order to abort pending transfers to/from RAM,
> > > which is soon to be owned by the OS. BM-DMA is also the only bit
> > > that's explicitly named by the UEFI Driver Writers' Guide, for
> > > clearing at
> > ExitBootServices().
> > >
> > > I've verified that clearing only BM-DMA fixes the isse (boot time)
> > > on i440fx, and does not regress q35/AHCI.
> > >
> > > Cc: Aleksei Kovura <alex3...@zoho.com>
> > > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> > > Cc: Dann Frazier <da...@ubuntu.com>
> > > Cc: Eric Dong <eric.d...@intel.com>
> > > Cc: Star Zeng <star.z...@intel.com>
> > > Reported-by: Aleksei Kovura <alex3...@zoho.com>
> > > Reported-by: Dann Frazier <da...@ubuntu.com>
> > > Reported-by: https://launchpad.net/~cjkrupp
> > > Bisected-by: Dann Frazier <da...@ubuntu.com>
> > > Bisected-by: https://launchpad.net/~cjkrupp
> > > Suggested-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> > > Suggested-by: Star Zeng <star.z...@intel.com>
> > > Ref: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1725560
> > > Fixes: 6fb8ddd36bde45614b0a069528cdc97077835a74
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Laszlo Ersek <ler...@redhat.com>
> > > ---
> > >
> > > Notes:
> > > Repo:   https://github.com/lersek/edk2.git
> > > Branch: ata_disable_only_bmdma
> > >
> > >  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h | 3 +--
> > > MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c | 5 ++---
> > >  2 files changed, 3 insertions(+), 5 deletions(-)
> > >
> > > diff --git
> > > a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > > b/MdeModulePkg/Bus/Ata/AtaAtapiP

Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at ExitBootServices()

[Ni, Ruiyu]

Laszlo,
Our QA found Win10 S4 resume fails due to your change.
As you might notice that I just rolled back the BM disabling patches in PciBus 
module,
I am thinking about maybe you need to rollback the whole ExitBootServices 
callback
as well to fix the compatibility issue.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Saturday, October 28, 2017 12:10 AM
> To: edk2-devel-01 
> Cc: Ard Biesheuvel ; Dong, Eric
> ; Zeng, Star ; Dann Frazier
> 
> Subject: Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only
> BM-DMA at ExitBootServices()
> 
> On 10/26/17 17:48, Laszlo Ersek wrote:
> > Clearing I/O port decoding in the PCI command register at
> > ExitBootServices() breaks IDE boot in Windows, on QEMU's "pc" (i440fx)
> > machine type. (AHCI boot on "q35" is unaffected.) Windows seems
> > repeatedly stuck, apparently waiting for a timeout of sorts.
> >
> > This is arguably a Windows bug; a native OS driver should not expect
> > the firmware to leave the PCI command register in any particular state.
> >
> > Strictly speaking, we only need to disable BM-DMA at
> > ExitBootServices(), in order to abort pending transfers to/from RAM,
> > which is soon to be owned by the OS. BM-DMA is also the only bit
> > that's explicitly named by the UEFI Driver Writers' Guide, for clearing at
> ExitBootServices().
> >
> > I've verified that clearing only BM-DMA fixes the isse (boot time) on
> > i440fx, and does not regress q35/AHCI.
> >
> > Cc: Aleksei Kovura 
> > Cc: Ard Biesheuvel 
> > Cc: Dann Frazier 
> > Cc: Eric Dong 
> > Cc: Star Zeng 
> > Reported-by: Aleksei Kovura 
> > Reported-by: Dann Frazier 
> > Reported-by: https://launchpad.net/~cjkrupp
> > Bisected-by: Dann Frazier 
> > Bisected-by: https://launchpad.net/~cjkrupp
> > Suggested-by: Ard Biesheuvel 
> > Suggested-by: Star Zeng 
> > Ref: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1725560
> > Fixes: 6fb8ddd36bde45614b0a069528cdc97077835a74
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Laszlo Ersek 
> > ---
> >
> > Notes:
> > Repo:   https://github.com/lersek/edk2.git
> > Branch: ata_disable_only_bmdma
> >
> >  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h | 3 +--
> > MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c | 5 ++---
> >  2 files changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > index 8d6eac706c0b..92c5bf2001cd 100644
> > --- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > +++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > @@ -123,8 +123,7 @@ typedef struct {
> >LIST_ENTRYNonBlockingTaskList;
> >
> >//
> > -  // For disabling the device (especially Bus Master DMA) at
> > -  // ExitBootServices().
> > +  // For disabling Bus Master DMA on the device at ExitBootServices().
> >//
> >EFI_EVENT ExitBootEvent;
> >  } ATA_ATAPI_PASS_THRU_INSTANCE;
> > diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > index 09064dda18b7..e10e0d4e65f6 100644
> > --- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > +++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > @@ -480,8 +480,7 @@ InitializeAtaAtapiPassThru (  }
> >
> >  /**
> > -  Disable the device (especially Bus Master DMA) when exiting the
> > boot
> > -  services.
> > +  Disable Bus Master DMA on the device when exiting the boot services.
> >
> >@param[in] EventEvent for which this notification function is being
> >called.
> > @@ -506,7 +505,7 @@ AtaPassThruExitBootServices (
> >PciIo->Attributes (
> > PciIo,
> > EfiPciIoAttributeOperationDisable,
> > -   Instance->EnabledPciAttributes,
> > +   Instance->EnabledPciAttributes &
> > + EFI_PCI_IO_ATTRIBUTE_BUS_MASTER,
> > NULL
> > );
> >  }
> >
> 
> Thanks Everyone for the feedback; I fixed the typo pointed out by Star and
> pushed the patch as commit 76fd5a660d70.
> 
> Cheers
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] PcAtChipsetPkg/IsaAcpiDxe: Fix VS2012 build failure

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

> -Original Message-
> From: Bi, Dandan
> Sent: Wednesday, November 22, 2017 10:02 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [patch] PcAtChipsetPkg/IsaAcpiDxe: Fix VS2012 build failure
> 
> Done:
> if (EFI_ERROR (Status)) {
>   if (PciIo != NULL && Enabled) {
> PciIo->Attributes (
>  PciIo,
>  EfiPciIoAttributeOperationSet,
>  OriginalAttributes,
>  NULL
>  );
>   }
> }
> In above codes, VS2012/VS2010 will report that "OriginalAttributes"
> will be used without initialization. But in fact, when the if expression is 
> true(if
> (PciIo != NULL && Enabled)), the "OriginalAttributes" must be initialized. In 
> order
> to fix this false positive issue, we initialize the "OriginalAttributes" after
> declaration.
> 
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c
> b/PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c
> index d82e2c4..c7ea559 100644
> --- a/PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c
> +++ b/PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c
> @@ -176,10 +176,11 @@ PcatIsaAcpiDriverBindingStart (
>BOOLEAN  Enabled;
> 
>Enabled = FALSE;
>Supports = 0;
>PcatIsaAcpiDev = NULL;
> +  OriginalAttributes = 0;
>//
>// Open the PCI I/O Protocol Interface
>//
>PciIo = NULL;
>Status = gBS->OpenProtocol (
> --
> 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/Shell: Check the OpenVolume result in OpenRootByHandle()

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Wu, Hao A
> Sent: Tuesday, November 14, 2017 4:41 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>
> Subject: RE: [PATCH] ShellPkg/Shell: Check the OpenVolume result in
> OpenRootByHandle()
> 
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Tuesday, November 14, 2017 4:38 PM
> > To: Wu, Hao A; edk2-devel@lists.01.org
> > Cc: Carsey, Jaben
> > Subject: RE: [PATCH] ShellPkg/Shell: Check the OpenVolume result in
> > OpenRootByHandle()
> >
> > How about changing the function header comments from
> > > +  @retval EFI_MEDIA_CHANGED The device has a different medium in it
> > or the medium is no longer supported.
> >
> > To:
> > > +  @retval others  Error status returned from
> > EFI_SIMPLE_FILE_SYSTEM_PROTOCOL->OpenVolume().
> >
> > Because MEDIA_CHANGED is not the only error that could happen.
> 
> Yes, I will update the comments when I push the patch if there's no other
> comments.
> 
> 
> Best Regards,
> Hao Wu
> 
> >
> >
> > Thanks/Ray
> >
> > > -Original Message-
> > > From: Wu, Hao A
> > > Sent: Tuesday, November 14, 2017 3:54 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Wu, Hao A <hao.a...@intel.com>; Carsey, Jaben
> > > <jaben.car...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
> > > Subject: [PATCH] ShellPkg/Shell: Check the OpenVolume result in
> > > OpenRootByHandle()
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=779
> > >
> > > For the API EfiShellOpenRootByHandle():
> > >
> > > The return status of the call to SimpleFileSystem->OpenVolume should
> > > be checked.
> > >
> > > It is possible that there is a media change in the device (like CD/DVD 
> > > ROM).
> > In
> > > such case, the volume root opened and/or the device path opened
> > > previously (also within EfiShellOpenRootByHandle) may be invalid.
> > >
> > > This commit adds a check for the result of OpenVolume before
> > > subsequently calling functions like EfiShellGetMapFromDevicePath() &
> > > ConvertEfiFileProtocolToShellHandle().
> > >
> > > Cc: Jaben Carsey <jaben.car...@intel.com>
> > > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Hao Wu <hao.a...@intel.com>
> > > ---
> > >  ShellPkg/Application/Shell/ShellProtocol.c | 9 +++--
> > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/ShellPkg/Application/Shell/ShellProtocol.c
> > > b/ShellPkg/Application/Shell/ShellProtocol.c
> > > index 5e34b8dad1..0dee267353 100644
> > > --- a/ShellPkg/Application/Shell/ShellProtocol.c
> > > +++ b/ShellPkg/Application/Shell/ShellProtocol.c
> > > @@ -827,7 +827,8 @@ EfiShellGetDeviceName(
> > >@retval EFI_NOT_FOUND EFI_SIMPLE_FILE_SYSTEM could not be
> > found
> > > or the root directory
> > >  could not be opened.
> > >@retval EFI_VOLUME_CORRUPTED  The data structures in the volume
> > were
> > > corrupted.
> > > -  @retval EFI_DEVICE_ERROR  The device had an error
> > > +  @retval EFI_DEVICE_ERROR  The device had an error.
> > > +  @retval EFI_MEDIA_CHANGED The device has a different medium in it
> > or
> > > the medium is no longer supported.
> > >  **/
> > >  EFI_STATUS
> > >  EFIAPI
> > > @@ -867,8 +868,12 @@ EfiShellOpenRootByHandle(
> > >// Open the root volume now...
> > >//
> > >Status = SimpleFileSystem->OpenVolume(SimpleFileSystem,
> > );
> > > +  if (EFI_ERROR(Status)) {
> > > +return Status;
> > > +  }
> > > +
> > >*FileHandle = ConvertEfiFileProtocolToShellHandle(RealFileHandle,
> > > EfiShellGetMapFromDevicePath());
> > > -  return (Status);
> > > +  return (EFI_SUCCESS);
> > >  }
> > >
> > >  /**
> > > --
> > > 2.12.0.windows.1

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

Re: [edk2] [PATCH] ShellPkg/Shell: Check the OpenVolume result in OpenRootByHandle()

[Ni, Ruiyu]

How about changing the function header comments from
> +  @retval EFI_MEDIA_CHANGED The device has a different medium in it or 
> the medium is no longer supported.

To:
> +  @retval others  Error status returned from 
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL->OpenVolume().

Because MEDIA_CHANGED is not the only error that could happen.


Thanks/Ray

> -Original Message-
> From: Wu, Hao A
> Sent: Tuesday, November 14, 2017 3:54 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A <hao.a...@intel.com>; Carsey, Jaben
> <jaben.car...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [PATCH] ShellPkg/Shell: Check the OpenVolume result in
> OpenRootByHandle()
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=779
> 
> For the API EfiShellOpenRootByHandle():
> 
> The return status of the call to SimpleFileSystem->OpenVolume should be
> checked.
> 
> It is possible that there is a media change in the device (like CD/DVD ROM). 
> In
> such case, the volume root opened and/or the device path opened previously
> (also within EfiShellOpenRootByHandle) may be invalid.
> 
> This commit adds a check for the result of OpenVolume before subsequently
> calling functions like EfiShellGetMapFromDevicePath() &
> ConvertEfiFileProtocolToShellHandle().
> 
> Cc: Jaben Carsey <jaben.car...@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu <hao.a...@intel.com>
> ---
>  ShellPkg/Application/Shell/ShellProtocol.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/ShellPkg/Application/Shell/ShellProtocol.c
> b/ShellPkg/Application/Shell/ShellProtocol.c
> index 5e34b8dad1..0dee267353 100644
> --- a/ShellPkg/Application/Shell/ShellProtocol.c
> +++ b/ShellPkg/Application/Shell/ShellProtocol.c
> @@ -827,7 +827,8 @@ EfiShellGetDeviceName(
>@retval EFI_NOT_FOUND EFI_SIMPLE_FILE_SYSTEM could not be found
> or the root directory
>  could not be opened.
>@retval EFI_VOLUME_CORRUPTED  The data structures in the volume were
> corrupted.
> -  @retval EFI_DEVICE_ERROR  The device had an error
> +  @retval EFI_DEVICE_ERROR  The device had an error.
> +  @retval EFI_MEDIA_CHANGED The device has a different medium in it or
> the medium is no longer supported.
>  **/
>  EFI_STATUS
>  EFIAPI
> @@ -867,8 +868,12 @@ EfiShellOpenRootByHandle(
>// Open the root volume now...
>//
>Status = SimpleFileSystem->OpenVolume(SimpleFileSystem, );
> +  if (EFI_ERROR(Status)) {
> +return Status;
> +  }
> +
>*FileHandle = ConvertEfiFileProtocolToShellHandle(RealFileHandle,
> EfiShellGetMapFromDevicePath());
> -  return (Status);
> +  return (EFI_SUCCESS);
>  }
> 
>  /**
> --
> 2.12.0.windows.1

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

Re: [edk2] [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings

[Ni, Ruiyu]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, November 9, 2017 9:16 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Jeff Fan <vanjeff_...@hotmail.com>
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org;
> Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>; Ard
> Biesheuvel <ard.biesheu...@linaro.org>
> Subject: Re: [edk2] [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to
> calculate optimal settings
> 
> On 11/09/17 08:11, Ni, Ruiyu wrote:
> > The old version is not just slow.
> > It cannot work in certain cases. That's why the new version was developed.
> >
> > The new version adds a new API which allows caller to pass in the
> > scratch buffer instead of using the stack. If a platform has limited
> > stack, it can use that API.
> 
> (1) OK, so let me summarize:
> 
> (1a) Ray and Jeff confirmed that the AP stacks should be affected in
> *neither* PiSmmCpuDxeSmm *nor* the MpInitLib client modules (CpuMpPei,
> CpuDxe).
> 
> (1b) There is a new MtrrLib class API that allows the client module to pass 
> in a
> preallocated scratch buffer.
> 
> (1a) sounds great.
> 
> (1b) is an option we may or may not want to exercise in OVMF. I have the
> patches ready for enlarging the temp SEC/PEI RAM (and as part of that, the
> temp stack), which is one alternative. However, because OVMF's PEI phase runs
> from RAM (and not flash), the other alternative is just to add a sufficiently 
> large
> static UINT8 array to PlatformPei, and pass that as scratch space to MtrrLib.
> 
> 
> (2) However: I don't know *how* the new API --
> MtrrSetMemoryAttributesInMtrrSettings() -- is supposed to be used. In
> OvmfPkg/PlatformPei, we have the following MtrrLib calls:
> 
> * OvmfPkg/PlatformPei/Xen.c:
> 
> - MtrrSetMemoryAttribute()
> 
> (in a loop, basically)
> 
> * OvmfPkg/PlatformPei/MemDetect.c:
> 
> - IsMtrrSupported()
> - MtrrGetAllMtrrs()
> - MtrrSetAllMtrrs()
> - MtrrSetMemoryAttribute()
> 
> Is my understanding correct that MtrrSetMemoryAttribute() is the only function
> that is affected?

1. yes. Only MtrrSetMemoryAttribute() call in OVMF is affected.

> 
> 
> (3) Is my understanding correct that
> MtrrSetMemoryAttributesInMtrrSettings() should be used like this:
> 
> (3a) start with MtrrGetAllMtrrs()
> 
> (3b) collect all *foreseeable* MtrrSetMemoryAttribute() calls into an
>  array of MTRR_MEMORY_RANGE elements
> 
> (3c) Perform a batch update on the output of (3a) by calling
>  MtrrSetMemoryAttributesInMtrrSettings(). For this, the array from
>  (3b), plus a caller-allocated scratch space, have to be passed in,.
> 
> (3d) Finally, call MtrrSetAllMtrrs().
> 
> Is this correct?

2. yes. In summary, there are three ways to call this new API. The first way is 
what
you described. The second way is a bit change to (3a), ZeroMem() is called 
instead of MtrrGetAllMtrrs() to initialize the MTRR. The third way is to 
call
this new API using NULL MtrrSetting, which cause the API itself to retrieve
the current MTRR settings from CPU, apply the new setting, write to CPU.
But the third way doesn't support batch setting.

> 
> I think we could use this. Jordan, which alternative do you prefer; larger 
> stack
> and unchanged code in PlatformPei, or same stack and updated code in
> PlatformPei?
> 
> 
> (4) Ray: would it be possible to expose SCRATCH_BUFFER_SIZE (with a new
> name MTRR_SCRATCH_BUFFER_SIZE) in the library class header? I see the new
> RETURN_BUFFER_TOO_SMALL status codes, and I don't really want to deal with
> them. The library class header should provide clients with a size macro that
> *guarantees* that RETURN_BUFFER_TOO_SMALL will not occur.
> 
> Practically speaking, I would use MTRR_SCRATCH_BUFFER_SIZE in the definition
> of the static UINT8 array in PlatformPei. (If Jordan prefers this alternative 
> to the
> larger temp stack.)

3. Not quite correct. Because even when pass in the scratch buffer whose size 
equal
to MTRR_SCRATCH_BUFFER_SIZE, the BUFFER_TOO_SMALL could be returned.
That's why the BUFFER_TOO_SMALL status is invented. It requires caller to 
re-supply
the enough scratch buffer for calculation.
As such, I do not think exposing SCRATCH_BUFFER_SIZE helps.
When implementing the code, I tried to find out the maximum scratch buffer 
size but
found that the maximum could be up to 256KB. I cannot use such large stack 
because
as Jordan said, MSVC will inject some code results in unresolved symbol in 
EDKII code.
And DxeIpl only allocates 128KB stack for whole DXE phase.


> 

Re: [edk2] [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings

[Ni, Ruiyu]

The old version is not just slow.
It cannot work in certain cases. That's why the new version was developed.

The new version adds a new API which allows caller to pass in the scratch
buffer instead of using the stack. If a platform has limited stack, it can use
that API.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jordan Justen
> Sent: Thursday, November 9, 2017 2:56 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; Laszlo Ersek <ler...@redhat.com>
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-
> de...@lists.01.org; Yao, Jiewen <jiewen@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Ard Biesheuvel <ard.biesheu...@linaro.org>
> Subject: Re: [edk2] [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to
> calculate optimal settings
> 
> On 2017-11-08 19:04:35, Ni, Ruiyu wrote:
> > Jordan, Laszlo,
> >
> > I didn't realize that a platform may have less than 4-page stack
> > before memory is ready. If I was aware of that, I would change the
> > default scratch buffer size to 2 page, which should be enough too.
> 
> This does not sound much better. I'm saying that the BASE library should only
> use at most a few hundred bytes of stack.
> 
> Apparently the old algorithm did not use much memory, but perhaps was
> slow? Can we put it back in place for the BASE version of the library?
> Then, we can add a DXE specific version that uses a large buffer which it can
> allocate, and potentially free.
> 
> -Jordan
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings

[Ni, Ruiyu]

Jordan, Laszlo,

I didn't realize that a platform may have less than 4-page stack before memory 
is ready.
If I was aware of that, I would change the default scratch buffer size to 2 
page, which
should be enough too.

But I do not think we may need to change the scratch buffer size.
Let me clarify about the MtrrLib API usage:
  Though the library is a BASE type, and it's MP-safe, it's not recommended to 
call
  MtrrSetMemoryAttribute...() in AP. Per IA32 SDM, all processors should use the
  same MTRR settings. In UEFI practice, we always just call the 
MtrrSetMemoryAttribute...()
  in BSP side, and then use MtrrGetAllMtrrs()/MtrrSetAllMtrrs() to sync the 
changes to
  all other Aps.


Thanks/Ray

> -Original Message-
> From: Justen, Jordan L
> Sent: Thursday, November 9, 2017 9:54 AM
> To: Laszlo Ersek <ler...@redhat.com>; Ni, Ruiyu <ruiyu...@intel.com>
> Cc: Dong, Eric <eric.d...@intel.com>; Ard Biesheuvel
> <ard.biesheu...@linaro.org>; edk2-devel@lists.01.org; Yao, Jiewen
> <jiewen@intel.com>; Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: Re: [edk2] [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to
> calculate optimal settings
> 
> On 2017-11-08 17:36:01, Laszlo Ersek wrote:
> > Hi Ray,
> >
> > On 10/12/17 10:48, Ruiyu Ni wrote:
> > > The new algorithm converts the problem calculating optimal MTRR
> > > settings (using least MTRR registers) to the problem finding the
> > > shortest path in a graph.
> > > The memory required in extreme but rare case can be up to 256KB, so
> > > using local stack buffer is impossible considering current DxeIpl
> > > only allocates 128KB stack.
> > >
> > > The patch changes existing MtrrSetMemoryAttributeInMtrrSettings()
> > > and
> > > MtrrSetMemoryAttribute() to use the 4-page stack buffer for
> > > calculation. The two APIs return BUFFER_TOO_SMALL when the buffer is
> > > too small for calculation.
> >
> > [snip]
> >
> > > +#define SCRATCH_BUFFER_SIZE   (4 * SIZE_4KB)
> >
> > [snip]
> >
> > >  RETURN_STATUS
> > >  EFIAPI
> > > -MtrrSetMemoryAttribute (
> > > +MtrrSetMemoryAttributeInMtrrSettings (
> > > +  IN OUT MTRR_SETTINGS   *MtrrSetting,
> > >IN PHYSICAL_ADDRESSBaseAddress,
> > >IN UINT64  Length,
> > >IN MTRR_MEMORY_CACHE_TYPE  Attribute
> > >)
> > >  {
> > >RETURN_STATUS  Status;
> > > +  UINT8  Scratch[SCRATCH_BUFFER_SIZE];
> >
> > [snip]
> >
> > (This patch is now commit 2bbd7e2fbd4b.)
> >
> > Today I managed to spend time on
> >
> >   https://bugzilla.tianocore.org/show_bug.cgi?id=747
> >
> > (which is in turn based on the earlier mailing list thread
> >
> >   [edk2] dynamic PCD impact on temporary PEI memory
> >   https://lists.01.org/pipermail/edk2-devel/2017-October/016213.html
> > ).
> >
> > While writing the patches, I found the root cause of BZ#747:
> > "OvmfPkg/PlatformPei" calls MtrrLib APIs, and due to the above 16KB
> > stack allocation, MtrrLib overflow's OVMF's 16KB (total) temp SEC/PEI
> > stack.
> 
> I thought it was considered bad form to use a significant portion of the 
> stack (>
> ~100 bytes) via local variables. This used to occasionally break MSVC builds 
> as
> MS would insert a stack check call if the locals size exceeded some threshold.
> 
> For a BASE library, I think this should go beyond "bad form" and into not
> allowed.
> 
> -Jordan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] MdeModulePkg/TerminalDxe: Fix PCANSI mapping for TRIANGLE and ARROW

[Ni, Ruiyu]

Thanks for the explanation.
Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, November 9, 2017 12:29 AM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org; Kinney, Michael
> D <michael.d.kin...@intel.com>
> Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [edk2] [Patch] MdeModulePkg/TerminalDxe: Fix PCANSI
> mapping for TRIANGLE and ARROW
> 
> When DOS uses CodePage 437, 18 is an up arrow glyph.
> 
> A PC ANSI terminal interprets 18 as a control character.
> 
> Mike
> 
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Tuesday, November 7, 2017 11:47 PM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>;
> > edk2-devel@lists.01.org
> > Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> > Subject: RE: [edk2] [Patch] MdeModulePkg/TerminalDxe:
> > Fix PCANSI mapping for TRIANGLE and ARROW
> >
> > Mike,
> > I am a bit confused about mapping 0x18 to upper arrow.
> > I remembered that in old days, pressing ALT+18 in DOS window can
> > generate upper arrow.
> >
> > Thanks/Ray
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-
> > boun...@lists.01.org] On Behalf Of
> > > Michael D Kinney
> > > Sent: Wednesday, November 8, 2017 12:24 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star
> > <star.z...@intel.com>
> > > Subject: [edk2] [Patch] MdeModulePkg/TerminalDxe: Fix
> > PCANSI mapping
> > > for TRIANGLE and ARROW
> > >
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=761
> > >
> > > When a TerminalType is set to PCANSI, characters in
> > the range 0x00 to 0x1F
> > > are control characters.  The mapping table for PCANSI
> > maps TRIANGLE glyphs,
> > > ARROW_UP glyph, and ARROW_DOWN glyph into this
> > control character
> > > range and that causes no characters to be displayed
> > by PCANSI compatible
> > > terminal emulators.
> > >
> > > The mappings are updated so these glyphs are mapped
> > to ANSI characters in
> > > the range 0x20 to 0x7E.
> > >
> > > GEOMETRICSHAPE_UP_TRIANGLE '^'
> > > GEOMETRICSHAPE_RIGHT_TRIANGLE  '>'
> > > GEOMETRICSHAPE_DOWN_TRIANGLE   'v'
> > > GEOMETRICSHAPE_LEFT_TRIANGLE   '<'
> > > ARROW_UP   '^'
> > > ARROW_DOWN 'v'
> > >
> > > Cc: Star Zeng <star.z...@intel.com>
> > > Cc: Eric Dong <eric.d...@intel.com>
> > > Contributed-under: TianoCore Contribution Agreement
> > 1.1
> > > Signed-off-by: Michael D Kinney
> > <michael.d.kin...@intel.com>
> > > ---
> > >  .../Universal/Console/TerminalDxe/TerminalConOut.c
> > | 18 +
> > > -
> > >  1 file changed, 9 insertions(+), 9 deletions(-)
> > >
> > > diff --git
> > >
> > a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalCo
> > nOut.c
> > >
> > b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalCo
> > nOut.c
> > > index e677a76e6b..5a8343162f 100644
> > > ---
> > a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalCo
> > nOut.c
> > > +++
> > b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalCo
> > nOut.c
> > > @@ -66,15 +66,15 @@ UNICODE_TO_CHAR
> > UnicodeToPcAnsiOrAscii[] = {
> > >{ BLOCKELEMENT_FULL_BLOCK,0xdb, L'*'
> > },
> > >{ BLOCKELEMENT_LIGHT_SHADE,   0xb0, L'+'
> > },
> > >
> > > -  { GEOMETRICSHAPE_UP_TRIANGLE, 0x1e, L'^'
> > },
> > > -  { GEOMETRICSHAPE_RIGHT_TRIANGLE,  0x10, L'>'
> > },
> > > -  { GEOMETRICSHAPE_DOWN_TRIANGLE,   0x1f, L'v'
> > },
> > > -  { GEOMETRICSHAPE_LEFT_TRIANGLE,   0x11, L'<'
> > },
> > > -
> > > -  { ARROW_LEFT, 0x3c, L'<'
> > },
> > > -  { ARROW_UP,   0x18, L'^'
> > },
> > > -  { ARROW_RIGHT,0x3e, L'>'
> > },
> > > -  { ARROW_DOWN, 0x19, L'v'
> > },
> > > +  { GEOMETRICSHAPE_UP_TRIANGLE, '^', L'^' },
> > > +  { GEOMETRICSHAPE_RIGHT_TRIANGLE,  '>', L'>' },
> > > +  { GEOMETRICSHAPE_DOWN_TRIANGLE,   'v', L'v' },
> > > +  { GEOMETRICSHAPE_LEFT_TRIANGLE,   '<', L'<' },
> > > +
> > > +  { ARROW_LEFT, '<', L'<' },
> > > +  { ARROW_UP,   '^', L'^' },
> > > +  { ARROW_RIGHT,'>', L'>' },
> > > +  { ARROW_DOWN, 'v', L'v' },
> > >
> > >{ 0x, 0x00, L'\0'
> > }
> > >  };
> > > --
> > > 2.14.2.windows.3
> > >
> > > ___
> > > 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] [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed?

[Ni, Ruiyu]

Yes. 2 seconds is for some other terminal tools, that cannot do the F10 
translation.

Thanks/Ray

> -Original Message-
> From: Heyi Guo [mailto:heyi@linaro.org]
> Sent: Wednesday, November 8, 2017 4:45 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>; edk2-
> de...@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>
> Subject: Re: [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC
> being pressed?
> 
> 
> 
> 在 11/8/2017 4:34 PM, Ni, Ruiyu 写道:
> > No.
> > Even a terminal tool can recognize F10, it still needs to translate it into 
> > "ESC
> [ V"
> > and send the three bytes to firmware.
> Got it. But the 2 seconds timeout is not for this situation, right? If 
> terminal
> tool could translate and send the key sequence, I think it can complete 3
> bytes transfer in a very short time, isn't it? E.g. 9600 baud / 8 = 1200 
> Bytes/s
> (ignore control bits).
> 
> So 2 seconds timeout is still for user to enter the sequence "ESC [ V"
> manually?
> 
> Thanks,
> 
> Heyi
> 
> >
> > Thanks/Ray
> >
> >> -Original Message-
> >> From: Heyi Guo [mailto:heyi@linaro.org]
> >> Sent: Wednesday, November 8, 2017 4:31 PM
> >> To: Ni, Ruiyu <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>;
> >> edk2- de...@lists.01.org
> >> Cc: Dong, Eric <eric.d...@intel.com>
> >> Subject: Re: [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC
> >> being pressed?
> >>
> >>
> >>
> >> 在 11/8/2017 3:55 PM, Ni, Ruiyu 写道:
> >>> Heyi,
> >>>
> >>> If you check the comments below in TerminalConIn.c:
> >>>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal
> >> /C
> >>> onsole/TerminalDxe/TerminalConIn.c#L1319
> >>>
> >>> TerminalDxe driver needs to determine whether user wants to press
> >>> ESC alone, or press "ESC [ V" for F10 (PCANSI terminal).
> >> Do you mean F10 is not directly supported on some terminal tools so
> >> that we need to press 3 keys "ESC [ V" quickly and continuously to
> emulate F10?
> >>
> >> Thanks,
> >>
> >> Heyi
> >>> So a 2 second timeout is added to wait additional keys.
> >>>
> >>> Thanks/Ray
> >>>
> >>>> -Original Message-
> >>>> From: Zeng, Star
> >>>> Sent: Wednesday, November 8, 2017 3:25 PM
> >>>> To: Heyi Guo <heyi@linaro.org>; edk2-devel@lists.01.org
> >>>> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric
> >>>> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> >>>> Subject: RE: [MdeModulePkg/TerminalDxe] Why do we delay 2s for
> ESC
> >>>> being pressed?
> >>>>
> >>>> Cc Terminal expert Ray to see if any comments on this.
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Star
> >>>> -Original Message-
> >>>> From: Heyi Guo [mailto:heyi@linaro.org]
> >>>> Sent: Wednesday, November 8, 2017 3:04 PM
> >>>> To: edk2-devel@lists.01.org
> >>>> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric
> >>>> <eric.d...@intel.com>
> >>>> Subject: [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC
> >> being
> >>>> pressed?
> >>>>
> >>>> Hi folks,
> >>>>
> >>>> We found ESC key responded fairly slow on serial port terminal, and
> >>>> we think it might be caused by the code in UnicodeToEfiKey in
> >> TerminalConIn.c:
> >>>>    if (UnicodeChar == ESC) {
> >>>>  TerminalDevice->InputState = INPUT_STATE_ESC;
> >>>>    }
> >>>>
> >>>>    if (UnicodeChar == CSI) {
> >>>>  TerminalDevice->InputState = INPUT_STATE_CSI;
> >>>>    }
> >>>>
> >>>>    if (TerminalDevice->InputState != INPUT_STATE_DEFAULT) {
> >>>>  Status = gBS->SetTimer(
> >>>>  TerminalDevice->TwoSecondTimeOut,
> >>>>  TimerRelative,
> >>>>  (UINT64)2000
> >>>>  );
> >>>>  ASSERT_EFI_ERROR (Status);
> >>>>  continue;
> >>>>    }
> >>>>
> >>>> It seems we intentionally add 2 seconds delay for ESC key press.
> >>>> This provides not so good user experience when we press ESC to exit
> >>>> or cancel some operation.
> >>>>
> >>>> We tried reducing this timeout value to 1 second, then the
> >>>> experience improved much and we didn't find any issue introduced.
> >>>>
> >>>> What's the reason for this timeout value and is there any improvement?
> >>>>
> >>>> Thanks and regards,
> >>>>
> >>>> Heyi

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

Re: [edk2] [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed?

[Ni, Ruiyu]

No.
Even a terminal tool can recognize F10, it still needs to translate it into 
"ESC [ V"
and send the three bytes to firmware.

Thanks/Ray

> -Original Message-
> From: Heyi Guo [mailto:heyi@linaro.org]
> Sent: Wednesday, November 8, 2017 4:31 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>; edk2-
> de...@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>
> Subject: Re: [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC
> being pressed?
> 
> 
> 
> 在 11/8/2017 3:55 PM, Ni, Ruiyu 写道:
> > Heyi,
> >
> > If you check the comments below in TerminalConIn.c:
> >
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal
> /C
> > onsole/TerminalDxe/TerminalConIn.c#L1319
> >
> > TerminalDxe driver needs to determine whether user wants to press ESC
> > alone, or press "ESC [ V" for F10 (PCANSI terminal).
> Do you mean F10 is not directly supported on some terminal tools so that we
> need to press 3 keys "ESC [ V" quickly and continuously to emulate F10?
> 
> Thanks,
> 
> Heyi
> >
> > So a 2 second timeout is added to wait additional keys.
> >
> > Thanks/Ray
> >
> >> -Original Message-
> >> From: Zeng, Star
> >> Sent: Wednesday, November 8, 2017 3:25 PM
> >> To: Heyi Guo <heyi@linaro.org>; edk2-devel@lists.01.org
> >> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric <eric.d...@intel.com>;
> >> Zeng, Star <star.z...@intel.com>
> >> Subject: RE: [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC
> >> being pressed?
> >>
> >> Cc Terminal expert Ray to see if any comments on this.
> >>
> >>
> >> Thanks,
> >> Star
> >> -Original Message-
> >> From: Heyi Guo [mailto:heyi@linaro.org]
> >> Sent: Wednesday, November 8, 2017 3:04 PM
> >> To: edk2-devel@lists.01.org
> >> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric
> >> <eric.d...@intel.com>
> >> Subject: [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC
> being
> >> pressed?
> >>
> >> Hi folks,
> >>
> >> We found ESC key responded fairly slow on serial port terminal, and
> >> we think it might be caused by the code in UnicodeToEfiKey in
> TerminalConIn.c:
> >>
> >>       if (UnicodeChar == ESC) {
> >>     TerminalDevice->InputState = INPUT_STATE_ESC;
> >>       }
> >>
> >>       if (UnicodeChar == CSI) {
> >>     TerminalDevice->InputState = INPUT_STATE_CSI;
> >>       }
> >>
> >>       if (TerminalDevice->InputState != INPUT_STATE_DEFAULT) {
> >>     Status = gBS->SetTimer(
> >>     TerminalDevice->TwoSecondTimeOut,
> >>     TimerRelative,
> >>     (UINT64)2000
> >>     );
> >>     ASSERT_EFI_ERROR (Status);
> >>     continue;
> >>       }
> >>
> >> It seems we intentionally add 2 seconds delay for ESC key press. This
> >> provides not so good user experience when we press ESC to exit or
> >> cancel some operation.
> >>
> >> We tried reducing this timeout value to 1 second, then the experience
> >> improved much and we didn't find any issue introduced.
> >>
> >> What's the reason for this timeout value and is there any improvement?
> >>
> >> Thanks and regards,
> >>
> >> Heyi

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

Re: [edk2] [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed?

[Ni, Ruiyu]

Heyi,

If you check the comments below in TerminalConIn.c:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c#L1319

TerminalDxe driver needs to determine whether user wants to press ESC alone,
or press "ESC [ V" for F10 (PCANSI terminal).

So a 2 second timeout is added to wait additional keys.

Thanks/Ray

> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, November 8, 2017 3:25 PM
> To: Heyi Guo <heyi@linaro.org>; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric <eric.d...@intel.com>; Zeng,
> Star <star.z...@intel.com>
> Subject: RE: [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC
> being pressed?
> 
> Cc Terminal expert Ray to see if any comments on this.
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Heyi Guo [mailto:heyi@linaro.org]
> Sent: Wednesday, November 8, 2017 3:04 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being
> pressed?
> 
> Hi folks,
> 
> We found ESC key responded fairly slow on serial port terminal, and we think
> it might be caused by the code in UnicodeToEfiKey in TerminalConIn.c:
> 
>      if (UnicodeChar == ESC) {
>    TerminalDevice->InputState = INPUT_STATE_ESC;
>      }
> 
>      if (UnicodeChar == CSI) {
>    TerminalDevice->InputState = INPUT_STATE_CSI;
>      }
> 
>      if (TerminalDevice->InputState != INPUT_STATE_DEFAULT) {
>    Status = gBS->SetTimer(
>    TerminalDevice->TwoSecondTimeOut,
>    TimerRelative,
>    (UINT64)2000
>    );
>    ASSERT_EFI_ERROR (Status);
>    continue;
>      }
> 
> It seems we intentionally add 2 seconds delay for ESC key press. This
> provides not so good user experience when we press ESC to exit or cancel
> some operation.
> 
> We tried reducing this timeout value to 1 second, then the experience
> improved much and we didn't find any issue introduced.
> 
> What's the reason for this timeout value and is there any improvement?
> 
> Thanks and regards,
> 
> Heyi

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

Re: [edk2] [Patch] MdeModulePkg/TerminalDxe: Fix PCANSI mapping for TRIANGLE and ARROW

[Ni, Ruiyu]

Mike,
I am a bit confused about mapping 0x18 to upper arrow.
I remembered that in old days, pressing ALT+18 in DOS window can generate upper 
arrow.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Michael D Kinney
> Sent: Wednesday, November 8, 2017 12:24 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric ; Zeng, Star 
> Subject: [edk2] [Patch] MdeModulePkg/TerminalDxe: Fix PCANSI mapping
> for TRIANGLE and ARROW
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=761
> 
> When a TerminalType is set to PCANSI, characters in the range 0x00 to 0x1F
> are control characters.  The mapping table for PCANSI maps TRIANGLE glyphs,
> ARROW_UP glyph, and ARROW_DOWN glyph into this control character
> range and that causes no characters to be displayed by PCANSI compatible
> terminal emulators.
> 
> The mappings are updated so these glyphs are mapped to ANSI characters in
> the range 0x20 to 0x7E.
> 
> GEOMETRICSHAPE_UP_TRIANGLE '^'
> GEOMETRICSHAPE_RIGHT_TRIANGLE  '>'
> GEOMETRICSHAPE_DOWN_TRIANGLE   'v'
> GEOMETRICSHAPE_LEFT_TRIANGLE   '<'
> ARROW_UP   '^'
> ARROW_DOWN 'v'
> 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Michael D Kinney 
> ---
>  .../Universal/Console/TerminalDxe/TerminalConOut.c | 18 +
> -
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git
> a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c
> b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c
> index e677a76e6b..5a8343162f 100644
> --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c
> +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c
> @@ -66,15 +66,15 @@ UNICODE_TO_CHAR  UnicodeToPcAnsiOrAscii[] = {
>{ BLOCKELEMENT_FULL_BLOCK,0xdb, L'*' },
>{ BLOCKELEMENT_LIGHT_SHADE,   0xb0, L'+' },
> 
> -  { GEOMETRICSHAPE_UP_TRIANGLE, 0x1e, L'^' },
> -  { GEOMETRICSHAPE_RIGHT_TRIANGLE,  0x10, L'>' },
> -  { GEOMETRICSHAPE_DOWN_TRIANGLE,   0x1f, L'v' },
> -  { GEOMETRICSHAPE_LEFT_TRIANGLE,   0x11, L'<' },
> -
> -  { ARROW_LEFT, 0x3c, L'<' },
> -  { ARROW_UP,   0x18, L'^' },
> -  { ARROW_RIGHT,0x3e, L'>' },
> -  { ARROW_DOWN, 0x19, L'v' },
> +  { GEOMETRICSHAPE_UP_TRIANGLE, '^', L'^' },
> +  { GEOMETRICSHAPE_RIGHT_TRIANGLE,  '>', L'>' },
> +  { GEOMETRICSHAPE_DOWN_TRIANGLE,   'v', L'v' },
> +  { GEOMETRICSHAPE_LEFT_TRIANGLE,   '<', L'<' },
> +
> +  { ARROW_LEFT, '<', L'<' },
> +  { ARROW_UP,   '^', L'^' },
> +  { ARROW_RIGHT,'>', L'>' },
> +  { ARROW_DOWN, 'v', L'v' },
> 
>{ 0x, 0x00, L'\0' }
>  };
> --
> 2.14.2.windows.3
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/2] PcAtChipsetPkg: Define FixePCD's for RTC register values

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Leo Duran [mailto:leo.du...@amd.com]
> Sent: Wednesday, November 1, 2017 1:55 AM
> To: edk2-devel@lists.01.org
> Cc: Leo Duran <leo.du...@amd.com>; Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [PATCH 1/2] PcAtChipsetPkg: Define FixePCD's for RTC register
> values
> 
> Define FixedPCD's to replace macros in RTC driver, to allow for platform-
> specific configurations.
> 
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leo Duran <leo.du...@amd.com>
> ---
>  PcAtChipsetPkg/PcAtChipsetPkg.dec | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/PcAtChipsetPkg/PcAtChipsetPkg.dec
> b/PcAtChipsetPkg/PcAtChipsetPkg.dec
> index b0b2b62..f11d204 100644
> --- a/PcAtChipsetPkg/PcAtChipsetPkg.dec
> +++ b/PcAtChipsetPkg/PcAtChipsetPkg.dec
> @@ -5,6 +5,7 @@
>  # PcAt defacto standard.
>  #
>  # Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
> +# Copyright (c) 2017, AMD Inc. All rights reserved.
>  #
>  # This program and the accompanying materials  # are licensed and made
> available under the terms and conditions of the BSD License @@ -181,5
> +182,17 @@
># @Prompt Reset Control Register value for cold reset
> 
> gPcAtChipsetPkgTokenSpaceGuid.PcdResetControlValueColdReset|0xFE|UI
> NT8|0x001A
> 
> +  ## Specifies the initial value for Register_A in RTC.
> +  # @Prompt Initial value for Register_A in RTC.
> +
> +
> gPcAtChipsetPkgTokenSpaceGuid.PcdInitialValueRtcRegisterA|0x26|UINT8|
> 0
> + x001B
> +
> +  ## Specifies the initial value for Register_B in RTC.
> +  # @Prompt Initial value for Register_B in RTC.
> +
> +
> gPcAtChipsetPkgTokenSpaceGuid.PcdInitialValueRtcRegisterB|0x02|UINT8|
> 0
> + x001C
> +
> +  ## Specifies the initial value for Register_D in RTC.
> +  # @Prompt Initial value for Register_D in RTC.
> +
> +
> gPcAtChipsetPkgTokenSpaceGuid.PcdInitialValueRtcRegisterD|0x00|UINT8|
> 0
> + x001D
> +
>  [UserExtensions.TianoCore."ExtraFiles"]
>PcAtChipsetPkgExtra.uni
> --
> 2.7.4

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

Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Ni, Ruiyu]

Jian,
Can you add more comments to explain why changing the capabilities of GCD entry?

The background is clear by checking the Bugzilla. But it would be great to know 
the issue
by just reading the code.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jian J Wang
> Sent: Friday, November 3, 2017 8:57 AM
> To: edk2-devel@lists.01.org
> Cc: Laszlo Ersek ; Yao, Jiewen ;
> Dong, Eric 
> Subject: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of
> RT_CODE in memory map
> 
> > v2
> > a. Fix an issue which will cause setting capability failure if size is 
> > smaller
> >than a page.
> 
> More than one entry of RT_CODE memory might cause boot problem for
> some old OSs. This patch will fix this issue to keep OS compatibility as much 
> as
> possible.
> 
> More detailed information, please refer to
> https://bugzilla.tianocore.org/show_bug.cgi?id=753
> 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> index d312eb66f8..4a7827ebc9 100644
> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> @@ -809,7 +809,9 @@ RefreshGcdMemoryAttributesFromPaging (
>PageLength= 0;
> 
>for (Index = 0; Index < NumberOfDescriptors; Index++) {
> -if (MemorySpaceMap[Index].GcdMemoryType ==
> EfiGcdMemoryTypeNonExistent) {
> +if (MemorySpaceMap[Index].GcdMemoryType ==
> EfiGcdMemoryTypeNonExistent
> +|| (MemorySpaceMap[Index].BaseAddress & EFI_PAGE_MASK) != 0
> +|| (MemorySpaceMap[Index].Length & EFI_PAGE_MASK) != 0) {
>continue;
>  }
> 
> @@ -829,6 +831,15 @@ RefreshGcdMemoryAttributesFromPaging (
>  // Sync real page attributes to GCD
>  BaseAddress   = MemorySpaceMap[Index].BaseAddress;
>  MemorySpaceLength = MemorySpaceMap[Index].Length;
> +Capabilities  = MemorySpaceMap[Index].Capabilities |
> +EFI_MEMORY_PAGETYPE_MASK;


> +Status = gDS->SetMemorySpaceCapabilities (
> +BaseAddress,
> +MemorySpaceLength,
> +Capabilities
> +);
> +ASSERT_EFI_ERROR (Status);
> +
>  while (MemorySpaceLength > 0) {
>if (PageLength == 0) {
>  PageEntry = GetPageTableEntry (, BaseAddress,
> ); @@ -846,7 +857,6 @@
> RefreshGcdMemoryAttributesFromPaging (
>  if (Attributes != (MemorySpaceMap[Index].Attributes &
> EFI_MEMORY_PAGETYPE_MASK)) {
>DoUpdate = TRUE;
>Attributes |= (MemorySpaceMap[Index].Attributes &
> ~EFI_MEMORY_PAGETYPE_MASK);
> -  Capabilities = Attributes | MemorySpaceMap[Index].Capabilities;
>  } else {
>DoUpdate = FALSE;
>  }
> @@ -854,8 +864,8 @@ RefreshGcdMemoryAttributesFromPaging (
> 
>Length = MIN (PageLength, MemorySpaceLength);
>if (DoUpdate) {
> -gDS->SetMemorySpaceCapabilities (BaseAddress, Length, Capabilities);
> -gDS->SetMemorySpaceAttributes (BaseAddress, Length, Attributes);
> +Status = gDS->SetMemorySpaceAttributes (BaseAddress, Length,
> Attributes);
> +ASSERT_EFI_ERROR (Status);
>  DEBUG ((DEBUG_INFO, "Update memory space attribute:
> [%02d] %016lx - %016lx (%08lx -> %08lx)\r\n",
>   Index, BaseAddress, BaseAddress + Length - 1,
>   MemorySpaceMap[Index].Attributes, Attributes));
> --
> 2.14.1.windows.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] [PATCH] PcAtChipsetPkg/IsaAcpiDxe: Restore PCI attributes correctly

[Ni, Ruiyu]

Laszlo,
Sure I will add the Bugzilla url in the commit message.

Steven,
Could you please check whether this patch can fix your "reconnect -r" hang?

Thanks/Ray

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, November 7, 2017 7:23 AM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Shi, Steven <steven@intel.com>
> Subject: Re: [PATCH] PcAtChipsetPkg/IsaAcpiDxe: Restore PCI attributes
> correctly
> 
> Hi Ray,
> 
> On 11/03/17 09:28, Ruiyu Ni wrote:
> > The original code enables some BITs in PCI attributes in Start(), but
> > wrongly to disable these BITs in Stop().
> >
> > The correct behavior is to save the original PCI attributes before
> > enables some BITs in Start(), and restore to original value in Stop().
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>
> > ---
> >  PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c | 44
> > +
> > PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.h |  3 ++-
> >  2 files changed, 25 insertions(+), 22 deletions(-)
> 
> Is this for <https://bugzilla.tianocore.org/show_bug.cgi?id=405>?
> 
> If so, can you please add the reference to the commit message?
> 
> Also, I think we should ask Steven to test the patch. (CC'd.)
> 
> I'll try to comment more later.
> 
> Thanks
> Laszlo
> 
> 
> >
> > diff --git a/PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c
> > b/PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c
> > index 32381b112d..60d2fb5a5b 100644
> > --- a/PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c
> > +++ b/PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c
> > @@ -172,6 +172,7 @@ PcatIsaAcpiDriverBindingStart (
> >EFI_PCI_IO_PROTOCOL  *PciIo;
> >PCAT_ISA_ACPI_DEV*PcatIsaAcpiDev;
> >UINT64   Supports;
> > +  UINT64   OriginalAttributes;
> >BOOLEAN  Enabled;
> >
> >Enabled = FALSE;
> > @@ -210,9 +211,18 @@ PcatIsaAcpiDriverBindingStart (
> >if (Supports == 0 || Supports == (EFI_PCI_IO_ATTRIBUTE_ISA_IO |
> EFI_PCI_IO_ATTRIBUTE_ISA_IO_16)) {
> >  Status = EFI_UNSUPPORTED;
> >  goto Done;
> > -  }
> > +  }
> > +
> > +  Status = PciIo->Attributes (
> > +PciIo,
> > +EfiPciIoAttributeOperationGet,
> > +0,
> > +
> > +);
> > +  if (EFI_ERROR (Status)) {
> > +goto Done;
> > +  }
> >
> > -  Enabled = TRUE;
> >Status = PciIo->Attributes (
> >  PciIo,
> >  EfiPciIoAttributeOperationEnable, @@ -222,7
> > +232,8 @@ PcatIsaAcpiDriverBindingStart (
> >if (EFI_ERROR (Status)) {
> >  goto Done;
> >}
> > -
> > +
> > +  Enabled = TRUE;
> >//
> >// Allocate memory for the PCAT ISA ACPI Device structure
> >//
> > @@ -239,9 +250,10 @@ PcatIsaAcpiDriverBindingStart (
> >//
> >// Initialize the PCAT ISA ACPI Device structure
> >//
> > -  PcatIsaAcpiDev->Signature = PCAT_ISA_ACPI_DEV_SIGNATURE;
> > -  PcatIsaAcpiDev->Handle= Controller;
> > -  PcatIsaAcpiDev->PciIo = PciIo;
> > +  PcatIsaAcpiDev->Signature = PCAT_ISA_ACPI_DEV_SIGNATURE;
> > +  PcatIsaAcpiDev->Handle= Controller;
> > +  PcatIsaAcpiDev->PciIo = PciIo;
> > +  PcatIsaAcpiDev->OriginalAttribute = OriginalAttributes;
> >
> >//
> >// Initialize PcatIsaAcpiDeviceList @@ -274,8 +286,8 @@ Done:
> >  if (PciIo != NULL && Enabled) {
> >PciIo->Attributes (
> > PciIo,
> > -   EfiPciIoAttributeOperationDisable,
> > -   EFI_PCI_DEVICE_ENABLE | Supports |
> EFI_PCI_IO_ATTRIBUTE_ISA_MOTHERBOARD_IO,
> > +   EfiPciIoAttributeOperationSet,
> > +   OriginalAttributes,
> > NULL
> > );
> >  }
> > @@ -321,7 +333,6 @@ PcatIsaAcpiDriverBindingStop (
> >EFI_STATUS Status;
> >EFI_ISA_ACPI_PROTOCOL  *IsaAcpi;
> >PCAT_ISA_ACPI_DEV  *PcatIsaAcpiDev;
> > -  UINT64 Supports;
> >
> >//
> >// Get the ISA ACPI Protocol Interface @@ -348,23 +359,14 @@
>

Re: [edk2] [PATCH v2 2/3] ShellPkg: Fix misuses of AllocateCopyPool

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Wang, Jian J
> Sent: Tuesday, November 7, 2017 1:11 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>;
> Bi, Dandan <dandan...@intel.com>
> Subject: [PATCH v2 2/3] ShellPkg: Fix misuses of AllocateCopyPool
> 
> > v2:
> > a. Use ReallocatePool instead of allocating then copying wherever
> applicable
> 
> AllocateCopyPool(AllocationSize, *Buffer) will copy "AllocationSize" bytes of
> memory from old "Buffer" to new allocated one. If "AllocationSize" is bigger
> than size of "Buffer", heap memory overflow occurs during copy.
> 
> One solution is to allocate pool first then copy the necessary bytes to new
> memory. Another is using ReallocatePool instead if old buffer will be freed
> on spot.
> 
> Cc: Jaben Carsey <jaben.car...@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Bi Dandan <dandan...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> ---
>  ShellPkg/Application/Shell/Shell.c | 4 +++-
>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 7
> +--
>  2 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/ShellPkg/Application/Shell/Shell.c
> b/ShellPkg/Application/Shell/Shell.c
> index 5471930ba1..656206fdce 100644
> --- a/ShellPkg/Application/Shell/Shell.c
> +++ b/ShellPkg/Application/Shell/Shell.c
> @@ -1646,7 +1646,7 @@ ShellConvertVariables (
>//
>// now do the replacements...
>//
> -  NewCommandLine1 = AllocateCopyPool(NewSize, OriginalCommandLine);
> +  NewCommandLine1 = AllocateZeroPool (NewSize);
>NewCommandLine2 = AllocateZeroPool(NewSize);
>ItemTemp= AllocateZeroPool(ItemSize+(2*sizeof(CHAR16)));
>if (NewCommandLine1 == NULL || NewCommandLine2 == NULL ||
> ItemTemp == NULL) {
> @@ -1655,6 +1655,8 @@ ShellConvertVariables (
>  SHELL_FREE_NON_NULL(ItemTemp);
>  return (NULL);
>}
> +  CopyMem (NewCommandLine1, OriginalCommandLine, StrSize
> (OriginalCommandLine));
> +
>for (MasterEnvList = EfiShellGetEnv(NULL)
>  ;  MasterEnvList != NULL && *MasterEnvList != CHAR_NULL
>  ;  MasterEnvList += StrLen(MasterEnvList) + 1
> diff --git
> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> index 1122c89b8b..ee3db63358 100644
> ---
> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> +++
> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> @@ -143,10 +143,11 @@ UpdateOptionalData(
>  OriginalOptionDataSize += (*(UINT16*)(OriginalData + sizeof(UINT32)));
>  OriginalOptionDataSize -= OriginalSize;
>  NewSize = OriginalSize - OriginalOptionDataSize + DataSize;
> -NewData = AllocateCopyPool(NewSize, OriginalData);
> +NewData = AllocatePool(NewSize);
>  if (NewData == NULL) {
>Status = EFI_OUT_OF_RESOURCES;
>  } else {
> +  CopyMem (NewData, OriginalData, OriginalSize - OriginalOptionDataSize);
>CopyMem(NewData + OriginalSize - OriginalOptionDataSize, Data,
> DataSize);
>  }
>}
> @@ -1120,11 +1121,13 @@ BcfgAddOpt(
>  // Now we know how many EFI_INPUT_KEY structs we need to attach to
> the end of the EFI_KEY_OPTION struct.
>  // Re-allocate with the added information.
>  //
> -KeyOptionBuffer = AllocateCopyPool(sizeof(EFI_KEY_OPTION) +
> (sizeof(EFI_INPUT_KEY) * NewKeyOption.KeyData.Options.InputKeyCount),
> );
> +KeyOptionBuffer = AllocatePool (sizeof(EFI_KEY_OPTION) +
> (sizeof(EFI_INPUT_KEY) * NewKeyOption.KeyData.Options.InputKeyCount));
>  if (KeyOptionBuffer == NULL) {
>ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_NO_MEM),
> gShellBcfgHiiHandle, L"bcfg");
>ShellStatus = SHELL_OUT_OF_RESOURCES;
> +  return ShellStatus;
>  }
> +CopyMem (KeyOptionBuffer, ,
> sizeof(EFI_KEY_OPTION));
>}
>for (LoopCounter = 0 ; ShellStatus == SHELL_SUCCESS && LoopCounter <
> NewKeyOption.KeyData.Options.InputKeyCount; LoopCounter++) {
>  //
> --
> 2.14.1.windows.1

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

Re: [edk2] [PATCH v2] MdeModulePkg/PciBus: Disable BME of all devices when entering RT

[Ni, Ruiyu]

Jiewen,
Any comments?

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ruiyu Ni
> Sent: Wednesday, November 1, 2017 12:49 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Michael Turner
> <michael.tur...@microsoft.com>; Yao, Jiewen <jiewen@intel.com>
> Subject: [edk2] [PATCH v2] MdeModulePkg/PciBus: Disable BME of all
> devices when entering RT
> 
> The patch ensures all DMA transactions are blocked after ExitBootService.
> If a platform enables IOMMU before and needs disable IOMMU after
> ExitBootService, the IOMMU should be disabled after PCI bus driver disables
> BME.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Michael Turner <michael.tur...@microsoft.com>
> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Michael D Kinney <michael.d.kin...@intel.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Jeff Fan <vanjeff_...@hotmail.com>
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h   |  2 +
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |  3 +
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 86
> +++
>  3 files changed, 91 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> index 55eb3a5a80..79b5b71082 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> @@ -18,6 +18,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
> 
>  #include 
> 
> +#include 
> +
>  #include 
>  #include 
>  #include 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
> index 97608bfcf2..d5b8fab3ca 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
> @@ -80,6 +80,9 @@ [LibraryClasses]
>DebugLib
>PeCoffLib
> 
> +[Guids]
> +  gEfiEventExitBootServicesGuid   ## SOMETIMES_CONSUMES ##
> Event
> +
>  [Protocols]
>gEfiPciHotPlugRequestProtocolGuid   ## SOMETIMES_PRODUCES
>gEfiPciIoProtocolGuid   ## BY_START
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> index 97bb971a59..004f2a3b5b 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> @@ -21,6 +21,72 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  LIST_ENTRY  mPciDevicePool;
> 
>  /**
> + Disable Bus Master Enable bit in all devices in the list.
> +
> + @param Devices  A device list.
> +**/
> +VOID
> +DisableBmeOnTree (
> +  IN LIST_ENTRY  *Devices
> +  )
> +{
> +  LIST_ENTRY  *Link;
> +  PCI_IO_DEVICE   *PciIoDevice;
> +  UINT16   Command;
> +
> +  for ( Link = GetFirstNode (Devices)
> +  ; !IsNull (Devices, Link)
> +  ; Link = GetNextNode (Devices, Link)
> +  ) {
> +PciIoDevice = PCI_IO_DEVICE_FROM_LINK (Link);
> +//
> +// Turn off all children's Bus Master, if any
> +//
> +DisableBmeOnTree (>ChildList);
> +
> +//
> +// If this is a device that supports BME, disable BME on this device.
> +//
> +if ((PciIoDevice->Supports & EFI_PCI_IO_ATTRIBUTE_BUS_MASTER) != 0)
> {
> +  PCI_READ_COMMAND_REGISTER(PciIoDevice, );
> +  if ((Command & EFI_PCI_COMMAND_BUS_MASTER) != 0) {
> +Command &= ~EFI_PCI_COMMAND_BUS_MASTER;
> +PCI_SET_COMMAND_REGISTER (PciIoDevice, Command);
> +DEBUG ((
> +  DEBUG_INFO,"  %02x   %02x  %02x %04x\n",
> +  PciIoDevice->BusNumber, PciIoDevice->DeviceNumber, PciIoDevice-
> >FunctionNumber,
> +  Command
> +  ));
> +  }
> +}
> +  }
> +}
> +
> +/**
> +  Exit Boot Services Event notification handler.
> +
> +  Disable Bus Master on any that were enabled during BDS.
> +
> +  @param[in]  Event Event whose notification function is being invoked.
> +  @param[in]  Context   Pointer to the notification function's context.
> +
> +**/
> +VOID
> +EFIAPI
> +OnExitBootServices (
> +  IN  EFI_EVENT Event,
> +  IN  VOID  *Context
> +  )
> +{
> +  DEBUG ((
> +DEBUG_INFO,
> +"PciBus: Disable Bus Master of all devices...\n"
> +"  Bus# Device# Function#  NewCommand\n"
> +));
> +  Disabl

Re: [edk2] [PATCH 2/3] ShellPkg: Fix misuses of AllocateCopyPool

[Ni, Ruiyu]

2 comments below.

-Original Message-
From: Wang, Jian J 
Sent: Friday, November 3, 2017 12:58 PM
To: edk2-devel@lists.01.org
Cc: Carsey, Jaben <jaben.car...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>; Bi, 
Dandan <dandan...@intel.com>
Subject: [PATCH 2/3] ShellPkg: Fix misuses of AllocateCopyPool

AllocateCopyPool(AllocationSize, *Buffer) will copy "AllocationSize" bytes of
memory from old "Buffer" to new allocated one. If "AllocationSize" is bigger
than size of "Buffer", heap memory overflow occurs during copy.

The solution is to allocate pool first then copy the necessary bytes to new
memory. This can avoid copying extra bytes from unknown memory range.

Cc: Jaben Carsey <jaben.car...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Cc: Bi Dandan <dandan...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
---
 ShellPkg/Application/Shell/Shell.c | 4 +++-
 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 6 --
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Application/Shell/Shell.c 
b/ShellPkg/Application/Shell/Shell.c
index 5471930ba1..24a04ca323 100644
--- a/ShellPkg/Application/Shell/Shell.c
+++ b/ShellPkg/Application/Shell/Shell.c
@@ -1646,7 +1646,9 @@ ShellConvertVariables (
   //
   // now do the replacements...
   //
-  NewCommandLine1 = AllocateCopyPool(NewSize, OriginalCommandLine);
+  NewCommandLine1 = AllocatePool(NewSize);
+  ASSERT (NewCommandLine1 != NULL);
[Ray] 1. Please do not use assertion because there is NULL check in the below 
if-statement.
The rule in ShellPkg is avoid using assertion.

+  CopyMem (NewCommandLine1, OriginalCommandLine, StrSize 
(OriginalCommandLine));
   NewCommandLine2 = AllocateZeroPool(NewSize);
   ItemTemp= AllocateZeroPool(ItemSize+(2*sizeof(CHAR16)));
   if (NewCommandLine1 == NULL || NewCommandLine2 == NULL || ItemTemp == NULL) {
diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index 1122c89b8b..5de62219b3 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -143,10 +143,11 @@ UpdateOptionalData(
 OriginalOptionDataSize += (*(UINT16*)(OriginalData + sizeof(UINT32)));
 OriginalOptionDataSize -= OriginalSize;
 NewSize = OriginalSize - OriginalOptionDataSize + DataSize;
-NewData = AllocateCopyPool(NewSize, OriginalData);
+NewData = AllocatePool(NewSize);
 if (NewData == NULL) {
   Status = EFI_OUT_OF_RESOURCES;
 } else {
+  CopyMem (NewData, OriginalData, OriginalSize - OriginalOptionDataSize);
   CopyMem(NewData + OriginalSize - OriginalOptionDataSize, Data, DataSize);
 }
   }
@@ -1120,11 +1121,12 @@ BcfgAddOpt(
 // Now we know how many EFI_INPUT_KEY structs we need to attach to the 
end of the EFI_KEY_OPTION struct.  
 // Re-allocate with the added information.
 //
-KeyOptionBuffer = AllocateCopyPool(sizeof(EFI_KEY_OPTION) + 
(sizeof(EFI_INPUT_KEY) * NewKeyOption.KeyData.Options.InputKeyCount), 
);
+KeyOptionBuffer = AllocatePool (sizeof(EFI_KEY_OPTION) + 
(sizeof(EFI_INPUT_KEY) * NewKeyOption.KeyData.Options.InputKeyCount));
 if (KeyOptionBuffer == NULL) {
   ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_NO_MEM), 
gShellBcfgHiiHandle, L"bcfg");  
   ShellStatus = SHELL_OUT_OF_RESOURCES;
 }
[Ray] 2. Should the above NULL check return?
+CopyMem (KeyOptionBuffer, , sizeof(EFI_KEY_OPTION));
   }
   for (LoopCounter = 0 ; ShellStatus == SHELL_SUCCESS && LoopCounter < 
NewKeyOption.KeyData.Options.InputKeyCount; LoopCounter++) {
 //
-- 
2.14.1.windows.1

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

Re: [edk2] [PATCH] MdeModulePkg/PciBus: Disable BME of all devices when entering RT

[Ni, Ruiyu]

Jeff,
Thanks you for your comments!

How are you in Guiyang?

Thanks/Ray

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Wednesday, November 1, 2017 10:43 AM
To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Michael Turner 
<michael.tur...@microsoft.com>; Yao, Jiewen <jiewen@intel.com>
Subject: 答复: [edk2] [PATCH] MdeModulePkg/PciBus: Disable BME of all devices 
when entering RT

Minimal comment: To use DEBUG_INFO instead of EFI_D_INFO for consistence in 
this patch.
+DEBUG ((
+  EFI_D_INFO,"  %02x   %02x  %02x %04x\n",
+  PciIoDevice->BusNumber, PciIoDevice->DeviceNumber, 
PciIoDevice->FunctionNumber,
+  Command
+  ));
发件人: Ruiyu Ni<mailto:ruiyu...@intel.com>
发送时间: 2017年10月31日 15:54
收件人: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
抄送: Michael D Kinney<mailto:michael.d.kin...@intel.com>; Michael 
Turner<mailto:michael.tur...@microsoft.com>; Jiewen 
Yao<mailto:jiewen@intel.com>
主题: [edk2] [PATCH] MdeModulePkg/PciBus: Disable BME of all devices when 
entering RT

The patch assumes IOMMU protections are disabled after PciBus
disables the BMT bit in Command register.
It ensures all DMA transactions are protected by IOMMU.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Turner 
<michael.tur...@microsoft.com<mailto:michael.tur...@microsoft.com>>
Signed-off-by: Ruiyu Ni <ruiyu...@intel.com<mailto:ruiyu...@intel.com>>
Cc: Michael D Kinney 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
Cc: Jiewen Yao <jiewen@intel.com<mailto:jiewen@intel.com>>
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h   |  2 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |  3 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 86 +++
 3 files changed, 91 insertions(+)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
index 55eb3a5a80..79b5b71082 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
@@ -18,6 +18,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.

 #include 

+#include 
+
 #include 
 #include 
 #include 
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
index 97608bfcf2..d5b8fab3ca 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
@@ -80,6 +80,9 @@ [LibraryClasses]
   DebugLib
   PeCoffLib

+[Guids]
+  gEfiEventExitBootServicesGuid   ## SOMETIMES_CONSUMES ## 
Event
+
 [Protocols]
   gEfiPciHotPlugRequestProtocolGuid   ## SOMETIMES_PRODUCES
   gEfiPciIoProtocolGuid   ## BY_START
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
index 97bb971a59..b5530a13d1 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
@@ -21,6 +21,72 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 LIST_ENTRY  mPciDevicePool;

 /**
+ Disable Bus Master Enable bit in all devices in the list.
+
+ @param Devices  A device list.
+**/
+VOID
+DisableBmeOnTree (
+  IN LIST_ENTRY  *Devices
+  )
+{
+  LIST_ENTRY  *Link;
+  PCI_IO_DEVICE   *PciIoDevice;
+  UINT16   Command;
+
+  for ( Link = GetFirstNode (Devices)
+  ; !IsNull (Devices, Link)
+  ; Link = GetNextNode (Devices, Link)
+  ) {
+PciIoDevice = PCI_IO_DEVICE_FROM_LINK (Link);
+//
+// Turn off all children's Bus Master, if any
+//
+DisableBmeOnTree (>ChildList);
+
+//
+// If this is a device that supports BME, disable BME on this device.
+//
+if ((PciIoDevice->Supports & EFI_PCI_IO_ATTRIBUTE_BUS_MASTER) != 0) {
+  PCI_READ_COMMAND_REGISTER(PciIoDevice, );
+  if ((Command & EFI_PCI_COMMAND_BUS_MASTER) != 0) {
+Command &= ~EFI_PCI_COMMAND_BUS_MASTER;
+PCI_SET_COMMAND_REGISTER (PciIoDevice, Command);
+DEBUG ((
+  EFI_D_INFO,"  %02x   %02x  %02x %04x\n",
+  PciIoDevice->BusNumber, PciIoDevice->DeviceNumber, 
PciIoDevice->FunctionNumber,
+  Command
+  ));
+  }
+}
+  }
+}
+
+/**
+  Exit Boot Services Event notification handler.
+
+  Disable Bus Master on any that were enabled during BDS.
+
+  @param[in]  Event Event whose notification function is being invoked.
+  @param[in]  Context   Pointer to the notification function's context.
+
+**/
+VOID
+EFIAPI
+OnExitBootServices (
+  IN  EFI_EVENT Event,
+  IN  VOID  *Context
+  )
+{
+  DEBUG ((
+DEBUG_INFO,
+"PciBus:

Re: [edk2] [PATCH] MdeModulePkg/NonDiscoverable: fix memory override bug

[Ni, Ruiyu]

I will wait for Ard's feedback. It's an ARM specific module.

Thanks/Ray

> -Original Message-
> From: Zeng, Star
> Sent: Monday, October 30, 2017 6:07 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; Heyi Guo <heyi@linaro.org>; linaro-
> u...@lists.linaro.org; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Ard Biesheuvel
> <ard.biesheu...@linaro.org>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [edk2][PATCH] MdeModulePkg/NonDiscoverable: fix memory
> override bug
> 
> Ray,
> Please help take a review to this patch.
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Heyi Guo [mailto:heyi@linaro.org]
> Sent: Monday, October 30, 2017 1:48 PM
> To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org
> Cc: Heyi Guo <heyi@linaro.org>; Zeng, Star <star.z...@intel.com>;
> Dong, Eric <eric.d...@intel.com>; Ard Biesheuvel
> <ard.biesheu...@linaro.org>; Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [edk2][PATCH] MdeModulePkg/NonDiscoverable: fix memory
> override bug
> 
> For PciIoPciRead interface, memory prior to Buffer would be written with
> zeros if Offset was larger than sizeof (Dev->ConfigSpace), which would cause
> serious system exception.
> 
> So we add a pre-check branch to avoid memory override.
> 
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Heyi Guo <heyi@linaro.org>
> ---
>  .../Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c | 5
> +
>  1 file changed, 5 insertions(+)
> 
> diff --git
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
> PciDeviceIo.c
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
> PciDeviceIo.c
> index c836ad6..0e42ae4 100644
> ---
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
> PciDeviceIo.c
> +++
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
> Pc
> +++ iDeviceIo.c
> @@ -465,6 +465,11 @@ PciIoPciRead (
>Address = (UINT8 *)>ConfigSpace + Offset;
>Length = Count << ((UINTN)Width & 0x3);
> 
> +  if (Offset >= sizeof (Dev->ConfigSpace)) {
> +ZeroMem (Buffer, Length);
> +return EFI_SUCCESS;
> +  }
> +
>if (Offset + Length > sizeof (Dev->ConfigSpace)) {
>  //
>  // Read all zeroes for config space accesses beyond the first
> --
> 1.9.1

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

Re: [edk2] [PATCH] ShellPkg: Fix type mismatch with GCC

[Ni, Ruiyu]

I have a pending task to remove the dependency of InternalCharToUpper().
Below two bugs require the same fix.
664   [Shell] UnicodeCollation->StriColl() should be used to replace StrinCmp 
in UefiShellLevel2CommandsLib  
294   Strnicmp() should use UNICODE_COLLATION.StrUpr() instead of converting 
char to upper case inself  

I think fixing them two is the right solution to go.


Thanks/Ray

> -Original Message-
> From: Gao, Liming
> Sent: Monday, October 30, 2017 1:18 PM
> To: Alcantara, Paulo <pa...@hp.com>; Carsey, Jaben
> <jaben.car...@intel.com>; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>
> Subject: RE: [PATCH] ShellPkg: Fix type mismatch with GCC
> 
> I suggest to rename it and add its implementation in ShellPkg. We don't
> expect to use the internal function from another library or driver.
> 
> Another way is to propose adding StrniCmp() API into BaseLib.
> 
> Thanks
> Liming
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >Alcantara, Paulo
> >Sent: Saturday, October 28, 2017 2:51 AM
> >To: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel@lists.01.org
> >Cc: Ni, Ruiyu <ruiyu...@intel.com>
> >Subject: Re: [edk2] [PATCH] ShellPkg: Fix type mismatch with GCC
> >
> >Hi Jaben,
> >
> >No, we can't. InternalCharToUpper() is declared internally in BaseLib
> >and unexported.
> >
> >The comment above the declaration in UefiShellLevel2CommandsLib.c
> >explains it:
> >
> >/**
> >  Be lazy and borrow from baselib.
> >
> >  @param[in] Char   The character to convert to upper case.
> >
> >  @return Char as an upper case character.
> >**/
> >
> >Thanks,
> >Paulo
> >
> >
> >From: Carsey, Jaben <jaben.car...@intel.com>
> >Sent: Friday, October 27, 2017 4:33 PM
> >To: Alcantara, Paulo; edk2-devel@lists.01.org
> >Cc: Ni, Ruiyu
> >Subject: RE: [PATCH] ShellPkg: Fix type mismatch with GCC
> >
> >Are we redefining a function from BaseLib?  Why not remove the
> >redundant definition instead of making it match?
> >
> >-Jaben
> >
> >> -Original Message-
> >> From: Paulo Alcantara [mailto:pa...@hp.com]
> >> Sent: Friday, October 27, 2017 9:24 AM
> >> To: edk2-devel@lists.01.org
> >> Cc: Paulo Alcantara <pa...@hp.com>; Carsey, Jaben
> >> <jaben.car...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
> >> Subject: [PATCH] ShellPkg: Fix type mismatch with GCC
> >> Importance: High
> >>
> >> This patch fixes the following warning reported by GCC 6.3:
> >>
> >>
> >/home/pcacjr/src/edk2.git/ShellPkg/Library/UefiShellLevel2CommandsLib/
> U
> >> efiShellLevel2CommandsLib.c:271:1:
> >> warning: type of 'InternalCharToUpper' does not match original decl
> >> aration [-Wlto-type-mismatch]  InternalCharToUpper (  ^
> >> /home/pcacjr/src/edk2.git/MdePkg/Library/BaseLib/String.c:555:1: note:
> >> 'InternalCharToUpper' was previously declared here
> >> InternalCharToUpper (  ^
> >>
> >> Cc: Jaben Carsey <jaben.car...@intel.com>
> >> Cc: Ruiyu Ni <ruiyu...@intel.com>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Paulo Alcantara <pa...@hp.com>
> >> ---
> >>
> >>
> >ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLi
> b
> >> .c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git
> >>
> >a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Command
> s
> >> Lib.c
> >>
> >b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Command
> s
> >> Lib.c
> >> index 7948e53cfc..bab6631e15 100644
> >> ---
> >>
> >a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Command
> s
> >> Lib.c
> >> +++
> >>
> >b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Command
> s
> >> Lib.c
> >> @@ -268,6 +268,7 @@ VerifyIntermediateDirectories (
> >>@return Char as an upper case character.
> >>  **/
> >>  CHAR16
> >> +EFIAPI
> >>  InternalCharToUpper (
> >>IN CONST CHAR16Char
> >>);
> >> --
> >> 2.11.0
> >
> >___
> >edk2-devel mailing list
> >edk2-devel@lists.01.org
> >https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to CALLBACK.

[Ni, Ruiyu]

I also doubt such device driver exists.

Thanks/Ray

> -Original Message-
> From: Yao, Jiewen
> Sent: Friday, October 27, 2017 9:47 AM
> To: Ni, Ruiyu <ruiyu...@intel.com>; Laszlo Ersek <ler...@redhat.com>; Zeng,
> Star <star.z...@intel.com>; edk2-devel@lists.01.org
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Kinney, Michael D
> <michael.d.kin...@intel.com>
> Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to
> CALLBACK.
> 
> I think the error might be PCI device specific.
> 
> BTW: We already have bugzillar on that
> https://bugzilla.tianocore.org/show_bug.cgi?id=739
> 
> It has been validated by Microsoft. We can validate more device cards to see
> if there is any issue.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Friday, October 27, 2017 8:54 AM
> > To: Yao, Jiewen <jiewen@intel.com>; Laszlo Ersek
> > <ler...@redhat.com>; Zeng, Star <star.z...@intel.com>;
> > edk2-devel@lists.01.org
> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Kinney, Michael D
> > <michael.d.kin...@intel.com>
> > Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event
> > TPL to CALLBACK.
> >
> > Jiewen,
> > If the BME bit is cleared in Command register, but a device driver
> > uses DMA to transfer data, what kind of error will be seen by SW?
> >
> > -Original Message-
> > From: Yao, Jiewen
> > Sent: Friday, October 27, 2017 8:34 AM
> > To: Laszlo Ersek <ler...@redhat.com>; Zeng, Star
> > <star.z...@intel.com>; edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu <ruiyu...@intel.com>; Ard Biesheuvel
> > <ard.biesheu...@linaro.org>; Kinney, Michael D
> > <michael.d.kin...@intel.com>
> > Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event
> > TPL to CALLBACK.
> >
> > Good Info. I think a correct implementation should not use busy wait.
> >
> > It should add error handling to check if there is hardware error during 
> > that.
> >
> > > - busy wait (poll) unil the transfer is complete,
> >
> > The process of busy wait should be something like below:
> >   while(TRUE) {
> > if (error) {
> >   break;
> > }
> > GetData
> >     if (complete) {
> >   Break
> > }
> >   }
> >
> > BME clear will trigger error break.
> >
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > > Sent: Thursday, October 26, 2017 11:07 PM
> > > To: Yao, Jiewen <jiewen@intel.com>; Zeng, Star
> > > <star.z...@intel.com>; edk2-devel@lists.01.org
> > > Cc: Ni, Ruiyu <ruiyu...@intel.com>; Ard Biesheuvel
> > > <ard.biesheu...@linaro.org>; Kinney, Michael D
> > > <michael.d.kin...@intel.com>
> > > Subject: Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event
> > > TPL to CALLBACK.
> > >
> > > On 10/26/17 15:36, Yao, Jiewen wrote:
> > > > Hi Laszlo
> > > > I have discussed this with Mike Kinney offline and some Microsoft
> engineers.
> > > >
> > > > We believe the impact of BME disable is different with the impact of
> SEV.
> > > >
> > > > For SEV, if a DMA buffer is in transition when SEV bit change, the
> > > > DMA will still
> > > be active, but the content is different. It will bring wrong data
> > > from device perspective.
> > > >
> > > > For BME, if a DMA buffer is in transition when BME is clear, the
> > > > DMA will be
> > > stopped immediately. The device only sees the DMA transition is abort.
> > > But there is no wrong data transmitted.
> > >
> > > I agree with the above analysis.
> > >
> > > > Because of above reason, we think it is OK to let PCI bus driver
> > > > to clear BME bit
> > > even there is active DMA transaction.
> > >
> > > The reason why I believe that the PciBusDxe driver should not clear
> > > the BME bit is different. It is unrelated to SEV.
> > >
> > > Imagine a PCI device that requires a special DMA transfer before it
> > > can be quiesced at ExitBootServices(). The vendor of this device
> > > will implement an EBS notification function like this:
> > >
> > > - check the private data structure to see if the device needs the
> > > speci

Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to CALLBACK.

[Ni, Ruiyu]

Jiewen,
If the BME bit is cleared in Command register, but a device driver
uses DMA to transfer data, what kind of error will be seen by SW?

-Original Message-
From: Yao, Jiewen 
Sent: Friday, October 27, 2017 8:34 AM
To: Laszlo Ersek <ler...@redhat.com>; Zeng, Star <star.z...@intel.com>; 
edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Ard Biesheuvel <ard.biesheu...@linaro.org>; 
Kinney, Michael D <michael.d.kin...@intel.com>
Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to 
CALLBACK.

Good Info. I think a correct implementation should not use busy wait.

It should add error handling to check if there is hardware error during that.

> - busy wait (poll) unil the transfer is complete,

The process of busy wait should be something like below:
  while(TRUE) {
if (error) {
  break;
}
GetData
if (complete) {
  Break
}
  }

BME clear will trigger error break.

Thank you
Yao Jiewen

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, October 26, 2017 11:07 PM
> To: Yao, Jiewen <jiewen@intel.com>; Zeng, Star 
> <star.z...@intel.com>; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Ard Biesheuvel 
> <ard.biesheu...@linaro.org>; Kinney, Michael D 
> <michael.d.kin...@intel.com>
> Subject: Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event 
> TPL to CALLBACK.
> 
> On 10/26/17 15:36, Yao, Jiewen wrote:
> > Hi Laszlo
> > I have discussed this with Mike Kinney offline and some Microsoft engineers.
> >
> > We believe the impact of BME disable is different with the impact of SEV.
> >
> > For SEV, if a DMA buffer is in transition when SEV bit change, the 
> > DMA will still
> be active, but the content is different. It will bring wrong data from 
> device perspective.
> >
> > For BME, if a DMA buffer is in transition when BME is clear, the DMA 
> > will be
> stopped immediately. The device only sees the DMA transition is abort. 
> But there is no wrong data transmitted.
> 
> I agree with the above analysis.
> 
> > Because of above reason, we think it is OK to let PCI bus driver to 
> > clear BME bit
> even there is active DMA transaction.
> 
> The reason why I believe that the PciBusDxe driver should not clear 
> the BME bit is different. It is unrelated to SEV.
> 
> Imagine a PCI device that requires a special DMA transfer before it 
> can be quiesced at ExitBootServices(). The vendor of this device will 
> implement an EBS notification function like this:
> 
> - check the private data structure to see if the device needs the 
> special DMA transfer
> 
> - initiate the special DMA transfer -- write some data to a preallocated
>   and pre-programmed memory buffer, and then push the doorbell in MMIO
>   or config space,
> 
> - busy wait (poll) unil the transfer is complete,
> 
> - clear BME (as required by the DWG / spec)
> 
> - done
> 
> Now, if PciBusDxe introduces its own EBS notification function, which 
> iterates over all the PciIo instances, and clears the BME bit in each 
> command register, then this notification function may, or may not, be 
> queued before the other one that I described above.
> 
> If the PciBusDxe function is queued "after", then everything is fine. 
> If it is queued "before", then the driver's own notification function 
> will break. (It may even hang, if the busy wait never completes.)
> 
> 
> UEFI drivers for PCI devices are currently not forbidden from doing a 
> quick CommonBuffer DMA transfer in their EBS callbacks (as long as 
> they don't allocate or release memory -- but the memory buffer and the 
> corresponding CommonBuffer mapping are not hard to set up in advance, 
> for example in DriverBindingStart()).
> 
> This means that any automated IOMMU deactivation, and/or BME clearing 
> in PciBusDxe, should occur only after the individual driver callbacks 
> have returned. If PciBusDxe can guarantee this, then I have no 
> objections :)
> 
> Thanks!
> Laszlo
> 
> >
> > Thank you
> > Yao Jiewen
> >
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Thursday, October 26, 2017 9:07 PM
> >> To: Zeng, Star <star.z...@intel.com>; Yao, Jiewen 
> >> <jiewen@intel.com>; edk2-devel@lists.01.org
> >> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Ard Biesheuvel
> <ard.biesheu...@linaro.org>
> >> Subject: Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS 
> >> Event TPL to CALLBACK.
> >>
> >> On 10/26/17 10:10, Zeng, Star

Re: [edk2] [PATCH] ShellPkg/UefiShellDebug1CommandsLib: Remove EFIAPI from Compress()

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Gary Lin
> Sent: Thursday, October 26, 2017 2:53 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [edk2] [PATCH] ShellPkg/UefiShellDebug1CommandsLib: Remove
> EFIAPI from Compress()
> 
> > ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.h:32:1: warning:
> > type of ‘Compress’ does not match original declaration
> > [-Wlto-type-mismatch]  Compress (  ^
> > ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c:1319:1: note:
> > ‘Compress’ was previously declared here  Compress (  ^
> 
> Gcc complains the mismatch of the declaration of Compress(). Since EFIAPI
> was removed from Compress() on purpose(*), remove EFIAPI from
> Compress() in the header to match the declaration.
> 
> * c4e74e9b814cfb4b51cf832f3bb218cd2aba348b
>   ShellPkg/UefiShellDebug1CommandsLib: Remove unnecessary EFIAPI
> 
> Cc: Jaben Carsey <jaben.car...@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Gary Lin <g...@suse.com>
> ---
>  ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.h
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.h
> index 39a997178f..7fe844e212 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.h
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.h
> @@ -28,7 +28,6 @@
>@retval EFI_BUFFER_TOO_SMALL  The buffer was too small.  DstSize is
> required.
>  **/
>  EFI_STATUS
> -EFIAPI
>  Compress (
>IN  VOID*SrcBuffer,
>IN  UINT64  SrcSize,
> --
> 2.14.2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 5/6] UefiCpuPkg/PiSmmCpuDxeSmm: Disable page table protection

[Ni, Ruiyu]

Jian,
1. For protocol not defined in Spec, please use EDKII prefix, instead of EFI 
prefix.
2. Could you please add more comments for BIT3 and BIT2 check?
3. Better to separate the protocol definition to a single commit.

Thanks/Ray

> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, October 26, 2017 2:20 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Laszlo Ersek <ler...@redhat.com>; Ni, Ruiyu <ruiyu...@intel.com>
> Subject: RE: [edk2] [PATCH v3 5/6] UefiCpuPkg/PiSmmCpuDxeSmm: Disable
> page table protection
> 
> Laszlo and Ruiyu,
> 
> Could you please take a look at this part? There's a new protocol introduced.
> 
> Thanks,
> Jian
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Jian J Wang
> > Sent: Monday, October 23, 2017 8:51 AM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric
> > <eric.d...@intel.com>
> > Subject: [edk2] [PATCH v3 5/6] UefiCpuPkg/PiSmmCpuDxeSmm: Disable
> page
> > table protection
> >
> > > v3
> > > According to Jiewen's feedback, implement new protocol
> > > gEdkiiSmmMemoryAttributeProtocolGuid
> > > to change memory attributes.
> >
> > > v2
> > > According to Eric's feedback:
> > > a. Enclose bit-or with parentheses
> > > b. Add code in 32-bit code to bypass setting page table to read-only
> >
> > Heap guard feature will update page attributes frequently. The page
> > table should not set to be read-only if heap guard feature is enabled
> > for SMM mode. Otherwise this feature cannot work.
> >
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Suggested-by: Ayellet Wolman <ayellet.wol...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |   7 +
> >  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c |  20 +++
> >  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  98
> > +
> >  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |   2 +
> >  UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 163
> > +
> >  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c|   3 +-
> >  6 files changed, 292 insertions(+), 1 deletion(-)
> >
> > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> > b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> > index f295c2ebf2..27c11f1b8d 100644
> > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> > @@ -184,6 +184,13 @@ SetPageTableAttributes (
> >BOOLEAN   IsSplitted;
> >BOOLEAN   PageTableSplitted;
> >
> > +  //
> > +  // Don't mark page table as read-only if heap guard is enabled.
> > +  //
> > +  if ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
> > +return ;
> > +  }
> > +
> >DEBUG ((DEBUG_INFO, "SetPageTableAttributes\n"));
> >
> >//
> > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> > b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> > index 282d2e6981..8635f2d2c8 100755
> > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> > @@ -76,6 +76,15 @@ EFI_SMM_CPU_PROTOCOL  mSmmCpu  = {
> >SmmWriteSaveState
> >  };
> >
> > +///
> > +/// SMM Memory Attribute Protocol instance ///
> > +EFI_SMM_MEMORY_ATTRIBUTE_PROTOCOL  mSmmMemoryAttribute  =
> {
> > +  EdkiiSmmGetMemoryAttributes,
> > +  EdkiiSmmSetMemoryAttributes,
> > +  EdkiiSmmClearMemoryAttributes
> > +};
> > +
> >  EFI_CPU_INTERRUPT_HANDLER
> > mExternalVectorTable[EXCEPTION_VECTOR_NUMBER];
> >
> >  //
> > @@ -893,6 +902,17 @@ PiCpuSmmEntry (
> >  );
> >ASSERT_EFI_ERROR (Status);
> >
> > +  //
> > +  // Install the SMM Memory Attribute Protocol into SMM protocol
> > + database  //  Status = gSmst->SmmInstallProtocolInterface (
> > +,
> > +,
> > +EFI_NATIVE_INTERFACE,
> > +
> > +);
> > +  ASSERT_EFI_ERROR (Status);
> > +
> >//
> >// Expose address of CPU Hot Plug Data structure if CPU hot 

Re: [edk2] [Patch] UefiCpuPkg/CpuFeatures: Export HOB if CPU initialized in PEI.

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

-Original Message-
From: Dong, Eric 
Sent: Wednesday, October 25, 2017 3:59 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Laszlo Ersek <ler...@redhat.com>
Subject: [Patch] UefiCpuPkg/CpuFeatures: Export HOB if CPU initialized in PEI.

In current implementation, CPU initialized can be done in PEI or DXE phase. PEI 
uses CpuFeaturesPie and Dxe uses CpuFeaturesDxe.
If CPU initialized in PEI phase, CpuFeaturesDxe driver will not be used. This 
driver will install gEdkiiCpuFeaturesInitDoneGuid protocol after it initializes 
the CPU.

Some drivers depend on this protocol to dispatch themselves. If CpuFeaturesDxe 
not been used, these drivers will not be dispatched.

This patch fix the above issue. If Cpu initialized in PEI phase, it also report 
a guid HOB for CpuFeaturesDxe.
CpuFeaturesDxe will check this HOB first. If it found this HOB, it just install 
gEdkiiCpuFeaturesInitDoneGuid protocol, else it will also do the CPU 
initialization.

Cc: Ruiyu Ni <ruiyu...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.d...@intel.com>
---
 UefiCpuPkg/CpuFeatures/CpuFeaturesDxe.c   | 19 +++
 UefiCpuPkg/CpuFeatures/CpuFeaturesDxe.inf |  1 +
 UefiCpuPkg/CpuFeatures/CpuFeaturesPei.c   |  6 ++
 UefiCpuPkg/CpuFeatures/CpuFeaturesPei.inf |  1 +
 4 files changed, 27 insertions(+)

diff --git a/UefiCpuPkg/CpuFeatures/CpuFeaturesDxe.c 
b/UefiCpuPkg/CpuFeatures/CpuFeaturesDxe.c
index b0b186d..6c0ae9d 100644
--- a/UefiCpuPkg/CpuFeatures/CpuFeaturesDxe.c
+++ b/UefiCpuPkg/CpuFeatures/CpuFeaturesDxe.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -101,6 +102,24 @@ CpuFeaturesDxeInitialize (
   )
 {
   VOID*Registration;
+  EFI_STATUS  Status;
+  EFI_HANDLE  Handle;
+
+  if (GetFirstGuidHob () != NULL) {
+//
+// Try to find HOB first. This HOB exist means CPU features have 
+// been initialized by CpuFeaturesPei driver, just install 
gEdkiiCpuFeaturesInitDoneGuid.
+//
+Handle = NULL;
+Status = gBS->InstallProtocolInterface (
+,
+,
+EFI_NATIVE_INTERFACE,
+NULL
+);
+ASSERT_EFI_ERROR (Status);
+return EFI_SUCCESS;
+  }
 
   if (PcdGetBool (PcdCpuFeaturesInitAfterSmmRelocation)) {
 //
diff --git a/UefiCpuPkg/CpuFeatures/CpuFeaturesDxe.inf 
b/UefiCpuPkg/CpuFeatures/CpuFeaturesDxe.inf
index 175e8a9..b1733be 100644
--- a/UefiCpuPkg/CpuFeatures/CpuFeaturesDxe.inf
+++ b/UefiCpuPkg/CpuFeatures/CpuFeaturesDxe.inf
@@ -33,6 +33,7 @@
   UefiDriverEntryPoint
   UefiBootServicesTableLib
   RegisterCpuFeaturesLib
+  HobLib
 
 [Sources]
   CpuFeaturesDxe.c
diff --git a/UefiCpuPkg/CpuFeatures/CpuFeaturesPei.c 
b/UefiCpuPkg/CpuFeatures/CpuFeaturesPei.c
index b052d55..72ee19b 100644
--- a/UefiCpuPkg/CpuFeatures/CpuFeaturesPei.c
+++ b/UefiCpuPkg/CpuFeatures/CpuFeaturesPei.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -70,6 +71,11 @@ CpuFeaturesPeimInitialize (
   Status = PeiServicesInstallPpi();
   ASSERT_EFI_ERROR (Status);
 
+  //
+  // Build HOB to let CpuFeatureDxe driver skip the initialization process.
+  //
+  BuildGuidHob (, 0);
+
   return EFI_SUCCESS;
 }
 
diff --git a/UefiCpuPkg/CpuFeatures/CpuFeaturesPei.inf 
b/UefiCpuPkg/CpuFeatures/CpuFeaturesPei.inf
index dd4b388..e617c5b 100644
--- a/UefiCpuPkg/CpuFeatures/CpuFeaturesPei.inf
+++ b/UefiCpuPkg/CpuFeatures/CpuFeaturesPei.inf
@@ -32,6 +32,7 @@
   PeimEntryPoint
   PeiServicesLib
   RegisterCpuFeaturesLib
+  HobLib
 
 [Sources]
   CpuFeaturesPei.c
--
2.7.0.windows.1

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

Re: [edk2] [Patch 2/2] UefiCpuPkg/MpInitLib: Enhance waiting for AP initialization logic.

[Ni, Ruiyu]

Jeff,

I see. Thanks for mentioning that
Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Do you mind to also give a r-b?


Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Fan Jeff
> Sent: Tuesday, October 24, 2017 2:27 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric <eric.d...@intel.com>; edk2-
> de...@lists.01.org
> Subject: [edk2] 答复: [Patch 2/2] UefiCpuPkg/MpInitLib: Enhance waiting for
> AP initialization logic.
> 
> Ray,
> 
> MpCpuExchangeInfo was declared as volatile type. It may not be necessary
> to add volatile for NumApsExecuting.
> 
> Jeff
> 
> 发件人: Ni, Ruiyu<mailto:ruiyu...@intel.com>
> 发送时间: 2017年10月24日 14:03
> 收件人: Dong, Eric<mailto:eric.d...@intel.com>; edk2-
> de...@lists.01.org<mailto:edk2-devel@lists.01.org>
> 主题: Re: [edk2] [Patch 2/2] UefiCpuPkg/MpInitLib: Enhance waiting for AP
> initialization logic.
> 
> You need to have "volatile" for "UINTN  NumApsExecuting;".
> Otherwise, compiler may optimize the code to cause below code wait
> forever:
>   while (CpuMpData->MpCpuExchangeInfo->NumApsExecuting != 0) {
> CpuPause();
>   }
> 
> 
> Thanks/Ray
> 
> > -Original Message-
> > From: Dong, Eric
> > Sent: Monday, October 23, 2017 3:23 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu <ruiyu...@intel.com>
> > Subject: [Patch 2/2] UefiCpuPkg/MpInitLib: Enhance waiting for AP
> > initialization logic.
> >
> > Current logic always waiting for a specific value to collect all APs
> > count. This logic may caused some platforms cost too much time to wait for
> time out.
> > This patch add new logic to collect APs count. It adds new variable
> > NumApsExecuting to detect whether all APs have finished initialization.
> > Each AP let NumApsExecuting++ when begin to initialize itself and let
> > NumApsExecuting-- when it finish the initialization. BSP base on
> > whether NumApsExecuting == 0  to finished the collect AP process.
> >
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Eric Dong <eric.d...@intel.com>
> > ---
> >  UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc|  1 +
> >  UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm |  6 ++
> >  UefiCpuPkg/Library/MpInitLib/MpLib.c   | 20 ++--
> >  UefiCpuPkg/Library/MpInitLib/MpLib.h   |  1 +
> >  UefiCpuPkg/Library/MpInitLib/X64/MpEqu.inc |  3 ++-
> >  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm  |  6 ++
> >  6 files changed, 30 insertions(+), 7 deletions(-)
> >
> > diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc
> > b/UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc
> > index 976af1f..bdfe0d3 100644
> > --- a/UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc
> > +++ b/UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc
> > @@ -40,4 +40,5 @@ EnableExecuteDisableLocation  equLockLocation +
> > 30h
> >  Cr3Location   equLockLocation + 34h
> >  InitFlagLocation  equLockLocation + 38h
> >  CpuInfoLocation   equLockLocation + 3Ch
> > +NumApsExecutingLocation   equLockLocation + 40h
> >
> > diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> > b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> > index 1b9c6a6..2b6c27d 100644
> > --- a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> > +++ b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> > @@ -86,6 +86,12 @@ Flat32Start:   ; 
> > protected mode entry
> > point
> >
> >  movesi, ebx
> >
> > +; Increment the number of APs executing here as early as possible
> > +; This is decremented in C code when AP is finished executing
> > +movedi, esi
> > +addedi, NumApsExecutingLocation
> > +lock inc   dword [edi]
> > +
> >  mov edi, esi
> >  add edi, EnableExecuteDisableLocation
> >  cmp byte [edi], 0
> > diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > index db923c9..48f930b 100644
> > --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > @@ -662,6 +662,7 @@ ApWakeupFunction (
> >  // AP finished executing C code
> >  //
> >  InterlockedIncrement ((UINT32 *) >FinishedCount);
> > +InterlockedDecrement ((UINT32

Re: [edk2] [Patch 2/2] UefiCpuPkg/MpInitLib: Enhance waiting for AP initialization logic.

[Ni, Ruiyu]

You need to have "volatile" for "UINTN  NumApsExecuting;".
Otherwise, compiler may optimize the code to cause below code wait forever:
  while (CpuMpData->MpCpuExchangeInfo->NumApsExecuting != 0) {
CpuPause();
  }


Thanks/Ray

> -Original Message-
> From: Dong, Eric
> Sent: Monday, October 23, 2017 3:23 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [Patch 2/2] UefiCpuPkg/MpInitLib: Enhance waiting for AP
> initialization logic.
> 
> Current logic always waiting for a specific value to collect all APs count. 
> This
> logic may caused some platforms cost too much time to wait for time out.
> This patch add new logic to collect APs count. It adds new variable
> NumApsExecuting to detect whether all APs have finished initialization.
> Each AP let NumApsExecuting++ when begin to initialize itself and let
> NumApsExecuting-- when it finish the initialization. BSP base on whether
> NumApsExecuting == 0  to finished the collect AP process.
> 
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong <eric.d...@intel.com>
> ---
>  UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc|  1 +
>  UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm |  6 ++
>  UefiCpuPkg/Library/MpInitLib/MpLib.c   | 20 ++--
>  UefiCpuPkg/Library/MpInitLib/MpLib.h   |  1 +
>  UefiCpuPkg/Library/MpInitLib/X64/MpEqu.inc |  3 ++-
>  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm  |  6 ++
>  6 files changed, 30 insertions(+), 7 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc
> b/UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc
> index 976af1f..bdfe0d3 100644
> --- a/UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc
> +++ b/UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc
> @@ -40,4 +40,5 @@ EnableExecuteDisableLocation  equLockLocation +
> 30h
>  Cr3Location   equLockLocation + 34h
>  InitFlagLocation  equLockLocation + 38h
>  CpuInfoLocation   equLockLocation + 3Ch
> +NumApsExecutingLocation   equLockLocation + 40h
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> index 1b9c6a6..2b6c27d 100644
> --- a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> +++ b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> @@ -86,6 +86,12 @@ Flat32Start:   ; protected 
> mode entry
> point
> 
>  movesi, ebx
> 
> +; Increment the number of APs executing here as early as possible
> +; This is decremented in C code when AP is finished executing
> +movedi, esi
> +addedi, NumApsExecutingLocation
> +lock inc   dword [edi]
> +
>  mov edi, esi
>  add edi, EnableExecuteDisableLocation
>  cmp byte [edi], 0
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index db923c9..48f930b 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -662,6 +662,7 @@ ApWakeupFunction (
>  // AP finished executing C code
>  //
>  InterlockedIncrement ((UINT32 *) >FinishedCount);
> +InterlockedDecrement ((UINT32 *)
> + >MpCpuExchangeInfo->NumApsExecuting);
> 
>  //
>  // Place AP is specified loop mode
> @@ -765,6 +766,7 @@ FillExchangeInfoData (
> 
>ExchangeInfo->CFunction   = (UINTN) ApWakeupFunction;
>ExchangeInfo->ApIndex = 0;
> +  ExchangeInfo->NumApsExecuting = 0;
>ExchangeInfo->InitFlag= (UINTN) CpuMpData->InitFlag;
>ExchangeInfo->CpuInfo = (CPU_INFO_IN_HOB *) (UINTN) CpuMpData-
> >CpuInfoInHob;
>ExchangeInfo->CpuMpData   = CpuMpData;
> @@ -934,13 +936,19 @@ WakeUpAP (
>  }
>  if (CpuMpData->InitFlag == ApInitConfig) {
>//
> -  // Wait for all potential APs waken up in one specified period
> +  // Wait for one potential AP waken up in one specified period
>//
> -  TimedWaitForApFinish (
> -CpuMpData,
> -PcdGet32 (PcdCpuMaxLogicalProcessorNumber) - 1,
> -PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds)
> -);
> +  if (CpuMpData->CpuCount == 0) {
> +TimedWaitForApFinish (
> +  CpuMpData,
> +  PcdGet32 (PcdCpuMaxLogicalProcessorNumber) - 1,
> +  PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds)
> +  );
> +  }
> +
> +  while (CpuMpData->MpCpuExchangeInfo->NumApsExecuting != 0) {

Re: [edk2] [Patch 1/2] UefiCpuPkg/MpInitLib: Change AP Index variable name.

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Dong, Eric
> Sent: Monday, October 23, 2017 3:23 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [Patch 1/2] UefiCpuPkg/MpInitLib: Change AP Index variable name.
> 
> Original AP index variable name not well express the meaning of the variable.
> Also this name is better used in later patch.
> So change the variable name for better understanding.
> 
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong <eric.d...@intel.com>
> ---
>  UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc| 2 +-
>  UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm | 4 ++--
>  UefiCpuPkg/Library/MpInitLib/MpLib.c   | 6 +++---
>  UefiCpuPkg/Library/MpInitLib/MpLib.h   | 2 +-
>  UefiCpuPkg/Library/MpInitLib/X64/MpEqu.inc | 2 +-
>  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm  | 4 ++--
>  6 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc
> b/UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc
> index 6276230..976af1f 100644
> --- a/UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc
> +++ b/UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc
> @@ -33,7 +33,7 @@ GdtrLocation  equLockLocation + 10h
>  IdtrLocation  equLockLocation + 16h
>  BufferStartLocation   equLockLocation + 1Ch
>  ModeOffsetLocationequLockLocation + 20h
> -NumApsExecutingLocation   equLockLocation + 24h
> +ApIndexLocation   equLockLocation + 24h
>  CodeSegmentLocation   equLockLocation + 28h
>  DataSegmentLocation   equLockLocation + 2Ch
>  EnableExecuteDisableLocation  equLockLocation + 30h
> diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> index 52363e6..1b9c6a6 100644
> --- a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> +++ b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
> @@ -130,7 +130,7 @@ TestLock:
>  jz TestLock
> 
>  movecx, esi
> -addecx, NumApsExecutingLocation
> +addecx, ApIndexLocation
>  incdword [ecx]
>  movebx, [ecx]
> 
> @@ -200,7 +200,7 @@ CProcedureInvoke:
>  moveax, ASM_PFX(InitializeFloatingPointUnits)
>  call   eax   ; Call assembly function to initialize FPU 
> per UEFI spec
> 
> -push   ebx   ; Push NumApsExecuting
> +push   ebx   ; Push ApIndex
>  moveax, esi
>  addeax, LockLocation
>  push   eax   ; push address of exchange info data buffer
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index f3ee6d4..db923c9 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -542,7 +542,7 @@ VOID
>  EFIAPI
>  ApWakeupFunction (
>IN MP_CPU_EXCHANGE_INFO  *ExchangeInfo,
> -  IN UINTN NumApsExecuting
> +  IN UINTN ApIndex
>)
>  {
>CPU_MP_DATA*CpuMpData;
> @@ -574,7 +574,7 @@ ApWakeupFunction (
>// Add CPU number
>//
>InterlockedIncrement ((UINT32 *) >CpuCount);
> -  ProcessorNumber = NumApsExecuting;
> +  ProcessorNumber = ApIndex;
>//
>// This is first time AP wakeup, get BIST information from AP stack
>//
> @@ -764,7 +764,7 @@ FillExchangeInfoData (
>ExchangeInfo->Cr3 = AsmReadCr3 ();
> 
>ExchangeInfo->CFunction   = (UINTN) ApWakeupFunction;
> -  ExchangeInfo->NumApsExecuting = 0;
> +  ExchangeInfo->ApIndex = 0;
>ExchangeInfo->InitFlag= (UINTN) CpuMpData->InitFlag;
>ExchangeInfo->CpuInfo = (CPU_INFO_IN_HOB *) (UINTN) CpuMpData-
> >CpuInfoInHob;
>ExchangeInfo->CpuMpData   = CpuMpData;
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> index 84ae24f..e41d2db 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> @@ -169,7 +169,7 @@ typedef struct {
>IA32_DESCRIPTOR   IdtrProfile;
>UINTN BufferStart;
>UINTN ModeOffset;
> -  UINTN NumApsExecuting;
> +  UINTN ApIndex;
>UINTN CodeSegment;
>UINTN DataSegment;
>UINTN

Re: [edk2] [patch 4/4] UefiCpuPkg/MtrrLib: Make comments align with function

[Ni, Ruiyu]

Dandan,
Thanks for fixing that.

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

-Original Message-
From: Bi, Dandan 
Sent: Friday, October 20, 2017 9:00 AM
To: edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
Subject: [patch 4/4] UefiCpuPkg/MtrrLib: Make comments align with function

Cc: Eric Dong <eric.d...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan...@intel.com>
---
 UefiCpuPkg/Include/Library/MtrrLib.h | 2 +-  
UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/Include/Library/MtrrLib.h 
b/UefiCpuPkg/Include/Library/MtrrLib.h
index d05d839..0bf7d8e 100644
--- a/UefiCpuPkg/Include/Library/MtrrLib.h
+++ b/UefiCpuPkg/Include/Library/MtrrLib.h
@@ -373,11 +373,11 @@ MtrrSetMemoryAttributeInMtrrSettings (
 needs more scratch buffer.
   @param[in]   Ranges   Pointer to an array of MTRR_MEMORY_RANGE.
 When range overlap happens, the last one takes 
higher priority.
 When the function returns, either all the 
attributes are set successfully,
 or none of them is set.
-  @param[in]Count of MTRR_MEMORY_RANGE.
+  @param[in]  RangeCountCount of MTRR_MEMORY_RANGE.
 
   @retval RETURN_SUCCESSThe attributes were set for all the memory 
ranges.
   @retval RETURN_INVALID_PARAMETER  Length in any range is zero.
   @retval RETURN_UNSUPPORTEDThe processor does not support one or more 
bytes of the
 memory resource range specified by 
BaseAddress and Length in any range.
diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index cb22558..579af27 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -2146,11 +2146,11 @@ MtrrLibSetBelow1MBMemoryAttribute (
 needs more scratch buffer.
   @param[in]   Ranges   Pointer to an array of MTRR_MEMORY_RANGE.
 When range overlap happens, the last one takes 
higher priority.
 When the function returns, either all the 
attributes are set successfully,
 or none of them is set.
-  @param[in]Count of MTRR_MEMORY_RANGE.
+  @param[in]   RangeCount   Count of MTRR_MEMORY_RANGE.
 
   @retval RETURN_SUCCESSThe attributes were set for all the memory 
ranges.
   @retval RETURN_INVALID_PARAMETER  Length in any range is zero.
   @retval RETURN_UNSUPPORTEDThe processor does not support one or more 
bytes of the
 memory resource range specified by 
BaseAddress and Length in any range.
--
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] UefiCpuPkg/MpInitLib: Avoid call PcdGe* in Ap & Bsp.

[Ni, Ruiyu]

With the subject change suggested by Laszlo, Reviewed-by: Ruiyu Ni 
<ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, October 19, 2017 4:08 PM
> To: Dong, Eric <eric.d...@intel.com>; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Crystal Lee <crystal...@ami.com.tw>
> Subject: Re: [edk2] [Patch] UefiCpuPkg/MpInitLib: Avoid call PcdGe* in Ap &
> Bsp.
> 
> On 10/19/17 04:42, Eric Dong wrote:
> > MicrocodeDetect function will run by every threads, and it will use
> > PcdGet to get PcdCpuMicrocodePatchAddress and
> > PcdCpuMicrocodePatchRegionSize, if change both PCD default to dynamic,
> > system will in non-deterministic behavior.
> >
> > By design, UEFI/PI services are single threaded and not re-entrant so
> > Multi processor code should not use UEFI/PI services. Here, Pcd
> > protocol/PPI is used to access dynamic PCDs so it would result in
> > non-deterministic behavior.
> >
> > This code get PCD value in BSP and save them in CPU_MP_DATA for Ap.
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=726
> >
> > Cc: Crystal Lee <crystal...@ami.com.tw>
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Eric Dong <eric.d...@intel.com>
> > ---
> >  UefiCpuPkg/Library/MpInitLib/Microcode.c | 10 +++---
> >  UefiCpuPkg/Library/MpInitLib/MpLib.c |  2 ++
> >  UefiCpuPkg/Library/MpInitLib/MpLib.h |  2 ++
> >  3 files changed, 7 insertions(+), 7 deletions(-)
> 
> Eric, can you please fix up the subject line after you get an R-b and are 
> about
> to push the patch?
> 
> -UefiCpuPkg/MpInitLib: Avoid call PcdGe* in Ap & Bsp.
> +UefiCpuPkg/MpInitLib: Avoid call PcdGet* in Ap & Bsp.
> 
> Thanks!
> Laszlo
> 
> 
> > diff --git a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> > b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> > index 982995b..35f66f7 100644
> > --- a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> > +++ b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> > @@ -42,8 +42,6 @@ MicrocodeDetect (
> >IN CPU_MP_DATA *CpuMpData
> >)
> >  {
> > -  UINT64  MicrocodePatchAddress;
> > -  UINT64  MicrocodePatchRegionSize;
> >UINT32  ExtendedTableLength;
> >UINT32  ExtendedTableCount;
> >CPU_MICROCODE_EXTENDED_TABLE*ExtendedTable;
> > @@ -61,9 +59,7 @@ MicrocodeDetect (
> >VOID*MicrocodeData;
> >MSR_IA32_PLATFORM_ID_REGISTER   PlatformIdMsr;
> >
> > -  MicrocodePatchAddress= PcdGet64 (PcdCpuMicrocodePatchAddress);
> > -  MicrocodePatchRegionSize = PcdGet64
> > (PcdCpuMicrocodePatchRegionSize);
> > -  if (MicrocodePatchRegionSize == 0) {
> > +  if (CpuMpData->MicrocodePatchRegionSize == 0) {
> >  //
> >  // There is no microcode patches
> >  //
> > @@ -93,8 +89,8 @@ MicrocodeDetect (
> >
> >LatestRevision = 0;
> >MicrocodeData  = NULL;
> > -  MicrocodeEnd = (UINTN) (MicrocodePatchAddress +
> > MicrocodePatchRegionSize);
> > -  MicrocodeEntryPoint = (CPU_MICROCODE_HEADER *) (UINTN)
> > MicrocodePatchAddress;
> > +  MicrocodeEnd = (UINTN) (CpuMpData->MicrocodePatchAddress +
> > + CpuMpData->MicrocodePatchRegionSize);
> > +  MicrocodeEntryPoint = (CPU_MICROCODE_HEADER *) (UINTN)
> > + CpuMpData->MicrocodePatchAddress;
> >do {
> >  //
> >  // Check if the microcode is for the Cpu and the version is newer
> > diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > index 924b909..f3ee6d4 100644
> > --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > @@ -1458,6 +1458,8 @@ MpInitLibInitialize (
> >CpuMpData->SwitchBspFlag= FALSE;
> >CpuMpData->CpuData  = (CPU_AP_DATA *) (CpuMpData + 1);
> >CpuMpData->CpuInfoInHob = (UINT64) (UINTN) (CpuMpData-
> >CpuData + MaxLogicalProcessorNumber);
> > +  CpuMpData->MicrocodePatchAddress= PcdGet64
> (PcdCpuMicrocodePatchAddress);
> > +  CpuMpData->MicrocodePatchRegionSize = PcdGet64
> > + (PcdCpuMicrocodePatchRegionSize);
> >InitializeSpinLock(>MpLock);
> >//
> >// Save BSP's Control registers to APs diff --git
> > a/UefiCpuPkg/Library

Re: [edk2] [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green color

[Ni, Ruiyu]

All,
Check the latest colors. The text should be easier to read.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Tim Lewis
> Sent: Tuesday, October 17, 2017 5:15 AM
> To: Jarlstrom, Laurie <laurie.jarlst...@intel.com>; Carsey, Jaben
> <jaben.car...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] [PATCH] ShellPkg/UefiShellLib: Use a more bright
> blue/green color
> 
> And we always turn off the multiple colors. Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jarlstrom, Laurie
> Sent: Monday, October 16, 2017 12:47 PM
> To: Carsey, Jaben <jaben.car...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>;
> edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] ShellPkg/UefiShellLib: Use a more bright
> blue/green color
> 
> The Idea of PCDs would be great.  I always change the UefiShellLib EFI_BLUE
> to EFI_CYAN to get a brighter blue.
> 
> thanks,
> Laurie
> 
> laurie.jarlst...@intel.com
> 
> Intel SSG/STO/EBP
> (503) 712-9395
> 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Carsey, Jaben
> Sent: Monday, October 16, 2017 9:32 AM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] ShellPkg/UefiShellLib: Use a more bright
> blue/green color
> 
> Reviewed-by: Jaben Carsey <jaben.car...@intel.com>
> 
> We could also use some PCDs if different people really want different colors
> in the future...
> 
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Monday, October 16, 2017 12:31 AM
> > To: edk2-devel@lists.01.org
> > Cc: Carsey, Jaben <jaben.car...@intel.com>
> > Subject: [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green
> > color
> > Importance: High
> >
> > Some developers/QAs complain the color of directory or executable
> > files is hard to see and suggest to use a more bright color.
> > I agree with this suggestion so make this patch.
> > The look and feel is much better now.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Jaben Carsey <jaben.car...@intel.com>
> > ---
> >  ShellPkg/Library/UefiShellLib/UefiShellLib.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> > b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> > index 64565f81d8..25d3e33533 100644
> > --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> > +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> > @@ -2849,10 +2849,10 @@ InternalShellPrintWorker(
> >  gST->ConOut->SetAttribute(gST->ConOut,
> > EFI_TEXT_ATTR(EFI_WHITE, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
> >  break;
> >case (L'B'):
> > -gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_BLUE,
> > ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
> > +gST->ConOut->SetAttribute(gST->ConOut,
> > EFI_TEXT_ATTR(EFI_LIGHTBLUE,
> ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
> >  break;
> >case (L'V'):
> > -gST->ConOut->SetAttribute(gST->ConOut,
> > EFI_TEXT_ATTR(EFI_GREEN, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
> > +gST->ConOut->SetAttribute(gST->ConOut,
> > EFI_TEXT_ATTR(EFI_LIGHTGREEN,
> > ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
> >  break;
> >default:
> >  //
> > --
> > 2.12.2.windows.2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/SerialDxe: Do not fail reset when SetAttributes is not supported

[Ni, Ruiyu]

Laszlo,
I agree with your status mapping.
It will make the implementation more clear and easier to maintain.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Wednesday, October 18, 2017 8:12 PM
> To: Julien Grall ; Zeng, Star ;
> Dong, Eric ; pankaj.ban...@nxp.com;
> leif.lindh...@linaro.org
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] MdeModulePkg/SerialDxe: Do not fail reset
> when SetAttributes is not supported
> 
> On 10/18/17 12:19, Julien Grall wrote:
> > After commit 91cc526b15 "MdeModulePkg/SerialDxe: Fix not able to
> > change serial attributes", serial is initialized using the reset
> > method that will call SetAttributes.
> >
> > However, SetAttributes may not be supported by the driver and will
> > return an error (i.e RETURN_UNSUPPORTED) that will be propagate and
> > lead to UEFI failing to get the console setup.
> >
> > For instance, this is the case when using the Xen console driver.
> >
> > Fix it by instropecting the result and return RETURN_SUCCESS when the
> > driver report it is not supported (i.e RETURN_UNSUPPORTED).
> >
> > Contributed-under: Tianocore Contribution Agreement 1.1
> > Signed-off-by: Julien Grall 
> > ---
> >  MdeModulePkg/Universal/SerialDxe/SerialIo.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
> > b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
> > index ebcd927263..4253e0b8ea 100644
> > --- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
> > +++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
> > @@ -238,6 +238,12 @@ SerialReset (
> > (UINT8) This->Mode->DataBits,
> > (EFI_STOP_BITS_TYPE) This->Mode->StopBits
> > );
> > +  //
> > +  // The serial device may not support SetAttributes.
> > +  // Set the status to RETURN_SUCCESS to prevent later failure.
> > +  //
> > +  if ( Status == RETURN_UNSUPPORTED )
> 
> The extra spaces within the parens are Xen coding style, not edk2 coding
> style; please remove them.
> 
> > +  return RETURN_SUCCESS;
> 
> The edk2 coding style requires braces.
> 
> The edk2 coding style requires two spaces as indentation, in this context.
> 
> >
> >return Status;
> >  }
> >
> 
> The UEFI spec (v2.7) describes the following return values for
> EFI_SERIAL_IO_PROTOCOL.Reset():
> 
> - EFI_SUCCESS: The serial device was reset.
> - EFI_DEVICE_ERROR: The serial device could not be reset.
> 
> For the EFI_SERIAL_IO_PROTOCOL.SetAttributes() member function:
> 
> - EFI_SUCCESS: The new attributes were set on the serial device.
> - EFI_INVALID_PARAMETER: One or more of the attributes has an
>  unsupported value.
> - EFI_DEVICE_ERROR: The serial device is not functioning correctly.
> 
> In MdeModulePkg/Universal/SerialDxe, the SetAttributes() member
> function is implemented by SerialSetAttributes(), and it delegates the
> operation to the SerialPortSetAttributes() API from the following library 
> class:
> 
>   MdePkg/Include/Library/SerialPortLib.h
> 
> The API defines the following return codes:
> 
>   @retval RETURN_SUCCESSThe new attributes were set on the
> serial device.
>   @retval RETURN_UNSUPPORTEDThe serial device does not support
> this operation.
>   @retval RETURN_INVALID_PARAMETER  One or more of the attributes has
> an
> unsupported value.
>   @retval RETURN_DEVICE_ERROR   The serial device is not functioning
> correctly.
> 
> Therefore I think the following should be done:
> 
> (1) The SerialPortSetAttributes() implementation in
> "OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c" is
> correct; returning RETURN_UNSUPPORTED is valid, according to the lib class
> header.
> 
> (2) The direct propagation of the return value in SerialSetAttributes()
> [MdeModulePkg/Universal/SerialDxe/SerialIo.c] does not look correct. It
> should implement the following mapping:
> 
> RETURN_SUCCESS   -> EFI_SUCCESS
> RETURN_UNSUPPORTED   -> EFI_INVALID_PARAMETER
> RETURN_INVALID_PARAMETER -> EFI_INVALID_PARAMETER
> everything else  -> EFI_DEVICE_ERROR
> 
> (That is, the outer interface requires us to map
> 
>   "The serial device does not support this operation."
> 
> to
> 
>   "One or more of the attributes has an unsupported value."
> 
> ... As long as we want to adhere to the UEFI-2.7 spec.)
> 
> (3) The SerialReset() function in
> "MdeModulePkg/Universal/SerialDxe/SerialIo.c" transparently propagates
> the return value of the internally called SerialSetAttributes() function. This
> looks incorrect as well; it should do the following mapping:
> 
> EFI_SUCCESS   -> EFI_SUCCESS
> EFI_INVALID_PARAMETER 

Re: [edk2] [Patch 1/4] MdePkg: Disable VS warning 4701 & 4703 for VS2017

[Ni, Ruiyu]

Liming,
How many build failures are there if 4701 and 4703 are enabled for VS2017?
I am asking this because we sometimes met VS2008 build failures due to 4701 and 
4703 are enabled for VS2008.
But the two warnings are disabled for VS2013 and later.
Can we have a consistent policy for the two warnings? Just disabling them for 
all VS versions is also OK I think.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Liming Gao
> Sent: Wednesday, October 18, 2017 6:49 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch 1/4] MdePkg: Disable VS warning 4701 & 4703 for
> VS2017
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> ---
>  MdePkg/Include/Ia32/ProcessorBind.h | 4 ++--
> MdePkg/Include/X64/ProcessorBind.h  | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/MdePkg/Include/Ia32/ProcessorBind.h
> b/MdePkg/Include/Ia32/ProcessorBind.h
> index 8ba2348..aeecf3f 100644
> --- a/MdePkg/Include/Ia32/ProcessorBind.h
> +++ b/MdePkg/Include/Ia32/ProcessorBind.h
> @@ -1,7 +1,7 @@
>  /** @file
>Processor or Compiler specific defines and types for IA-32 architecture.
> 
> -Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
>  This program and the accompanying materials are licensed and made
> available under  the terms and conditions of the BSD License that
> accompanies this distribution.
>  The full text of the license may be found at @@ -93,7 +93,7 @@ WITHOUT
> WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
>  //
>  #pragma warning ( disable : 4206 )
> 
> -#if _MSC_VER == 1800 || _MSC_VER == 1900
> +#if _MSC_VER == 1800 || _MSC_VER == 1900 || _MSC_VER >= 1910
> 
>  //
>  // Disable these warnings for VS2013.
> diff --git a/MdePkg/Include/X64/ProcessorBind.h
> b/MdePkg/Include/X64/ProcessorBind.h
> index 72cc851..e637d86 100644
> --- a/MdePkg/Include/X64/ProcessorBind.h
> +++ b/MdePkg/Include/X64/ProcessorBind.h
> @@ -1,7 +1,7 @@
>  /** @file
>Processor or Compiler specific defines and types x64 (Intel 64, AMD64).
> 
> -  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 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
> @@ -107,7 +107,7 @@
>  //
>  #pragma warning ( disable : 4206 )
> 
> -#if _MSC_VER == 1800 || _MSC_VER == 1900
> +#if _MSC_VER == 1800 || _MSC_VER == 1900 || _MSC_VER >= 1910
> 
>  //
>  // Disable these warnings for VS2013.
> --
> 2.8.0.windows.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] [PATCH] UefiCpuPkg/MtrrLib: Fix MtrrDebugPrintAllMtrrsWorker to avoid hang

[Ni, Ruiyu]

Laszlo,
I think the function name confused you.
MtrrLibApplyVariableMtrrs() is not to apply the MTRR setting to CPU/HW.
It's to apply the setting read from CPU/HW to the range array stored in memory.
It doesn't have side effect.

The basic idea of MtrrDebugPrintAllMtrrsWorker() is to read the setting from 
HW/CPU,
Convert that setting to range array. Then dump the range array.

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Tuesday, October 17, 2017 3:56 PM
To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] UefiCpuPkg/MtrrLib: Fix 
MtrrDebugPrintAllMtrrsWorker to avoid hang

On 10/17/17 03:46, Ruiyu Ni wrote:
> ARRAY_SIZE(Mtrrs->Variables.Mtrr) was used in
> MtrrDebugPrintAllMtrrsWorker() to parse the MTRR registers.
> Instead, the actual variable MTRR count should be used.
> Otherwise, the uninitialized random data in MtrrSetting may cause
> MtrrLibSetMemoryType() hang.
> 
> Steven Shi found this bug in QEMU when using Q35 chip.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Steven Shi <steven@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> ---
>  UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
> b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> index 2fd1d0153e..cb22558103 100644
> --- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> +++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> @@ -2776,6 +2776,7 @@ MtrrDebugPrintAllMtrrsWorker (
>  UINTN RangeCount;
>  UINT64MtrrValidBitsMask;
>  UINT64MtrrValidAddressMask;
> +UINT32VariableMtrrCount;
>  MTRR_MEMORY_RANGE Ranges[
>ARRAY_SIZE (mMtrrLibFixedMtrrTable) * sizeof (UINT64) + 2 * ARRAY_SIZE 
> (Mtrrs->Variables.Mtrr) + 1
>];
> @@ -2785,6 +2786,8 @@ MtrrDebugPrintAllMtrrsWorker (
>return;
>  }
>  
> +VariableMtrrCount = GetVariableMtrrCountWorker ();
> +
>  if (MtrrSetting != NULL) {
>Mtrrs = MtrrSetting;
>  } else {
> @@ -2802,7 +2805,7 @@ MtrrDebugPrintAllMtrrsWorker (
>DEBUG((DEBUG_CACHE, "Fixed MTRR[%02d]   : %016lx\n", Index, 
> Mtrrs->Fixed.Mtrr[Index]));
>  }
>  
> -for (Index = 0; Index < ARRAY_SIZE (Mtrrs->Variables.Mtrr); Index++) {
> +for (Index = 0; Index < VariableMtrrCount; Index++) {
>if (((MSR_IA32_MTRR_PHYSMASK_REGISTER 
> *)>Variables.Mtrr[Index].Mask)->Bits.V == 0) {
>  //
>  // If mask is not valid, then do not display range @@ 
> -2829,11 +2832,11 @@ MtrrDebugPrintAllMtrrsWorker (
>  RangeCount = 1;
>  
>  MtrrLibGetRawVariableRanges (
> -  >Variables, ARRAY_SIZE (Mtrrs->Variables.Mtrr),
> +  >Variables, VariableMtrrCount,
>MtrrValidBitsMask, MtrrValidAddressMask, RawVariableRanges
>);
>  MtrrLibApplyVariableMtrrs (
> -  RawVariableRanges, ARRAY_SIZE (RawVariableRanges),
> +  RawVariableRanges, VariableMtrrCount,
>Ranges, ARRAY_SIZE (Ranges), 
>);
>  
> 

Assuming this patch is not committed yet:

Reviewed-by: Laszlo Ersek <ler...@redhat.com>


I have another (independent) comment:

This function is currently named "MtrrDebugPrintAllMtrrsWorker", and its 
leading comment says "Worker function prints all MTRRs for debugging."

Because of this name and the documentation, I didn't understand initially how 
the problem could cause a hang, given that none of the printing loops would 
actually access anything out-of-bounds. Some of the information printed would 
be garbage, but it should not cause a hang.

That's when I noticed that the function actually *applies* MTRR settings, by 
calling MtrrLibApplyVariableMtrrs(). Even worse, the
MtrrLibApplyVariableMtrrs() and MtrrLibApplyFixedMtrrs() function calls are 
wrapped by DEBUG_CODE(). This means that in a DEBUG/NOOPT build, the function 
will apply MTRR settings, and in a RELEASE build, it won't.

I think this is wrong and should be fixed. A debug function (esp. one that 
behaves differently in DEBUG/NOOPT vs. RELEASE) should have no side effects.

The current situation is similar to:

  ASSERT (FunctionWithSideEffects () == EXPECTED_RETURN_VALUE);

which we all know is wrong.

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

Re: [edk2] [PATCH] UefiCpuPkg/MtrrLib: Fix MtrrDebugPrintAllMtrrsWorker to avoid hang

[Ni, Ruiyu]

Thanks Steven.

All,
I will check in this patch ASAP.
Because it's just a bug fix in a corner of implementation and it may cause all 
system hang.


-Original Message-
From: Shi, Steven 
Sent: Tuesday, October 17, 2017 10:04 AM
To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
Cc: Laszlo Ersek <ler...@redhat.com>
Subject: RE: [PATCH] UefiCpuPkg/MtrrLib: Fix MtrrDebugPrintAllMtrrsWorker to 
avoid hang

Reviewed-by: Steven Shi <steven@intel.com>


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522


> -Original Message-----
> From: Ni, Ruiyu
> Sent: Tuesday, October 17, 2017 9:47 AM
> To: edk2-devel@lists.01.org
> Cc: Shi, Steven <steven@intel.com>; Laszlo Ersek 
> <ler...@redhat.com>
> Subject: [PATCH] UefiCpuPkg/MtrrLib: Fix MtrrDebugPrintAllMtrrsWorker 
> to avoid hang
> 
> ARRAY_SIZE(Mtrrs->Variables.Mtrr) was used in
> MtrrDebugPrintAllMtrrsWorker() to parse the MTRR registers.
> Instead, the actual variable MTRR count should be used.
> Otherwise, the uninitialized random data in MtrrSetting may cause
> MtrrLibSetMemoryType() hang.
> 
> Steven Shi found this bug in QEMU when using Q35 chip.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Steven Shi <steven@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> ---
>  UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> index 2fd1d0153e..cb22558103 100644
> --- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> +++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> @@ -2776,6 +2776,7 @@ MtrrDebugPrintAllMtrrsWorker (
>  UINTN RangeCount;
>  UINT64MtrrValidBitsMask;
>  UINT64MtrrValidAddressMask;
> +UINT32VariableMtrrCount;
>  MTRR_MEMORY_RANGE Ranges[
>ARRAY_SIZE (mMtrrLibFixedMtrrTable) * sizeof (UINT64) + 2 * 
> ARRAY_SIZE (Mtrrs->Variables.Mtrr) + 1
>];
> @@ -2785,6 +2786,8 @@ MtrrDebugPrintAllMtrrsWorker (
>return;
>  }
> 
> +VariableMtrrCount = GetVariableMtrrCountWorker ();
> +
>  if (MtrrSetting != NULL) {
>Mtrrs = MtrrSetting;
>  } else {
> @@ -2802,7 +2805,7 @@ MtrrDebugPrintAllMtrrsWorker (
>DEBUG((DEBUG_CACHE, "Fixed MTRR[%02d]   : %016lx\n", Index, Mtrrs-
> >Fixed.Mtrr[Index]));
>  }
> 
> -for (Index = 0; Index < ARRAY_SIZE (Mtrrs->Variables.Mtrr); Index++) {
> +for (Index = 0; Index < VariableMtrrCount; Index++) {
>if (((MSR_IA32_MTRR_PHYSMASK_REGISTER *)
> >Variables.Mtrr[Index].Mask)->Bits.V == 0) {
>  //
>  // If mask is not valid, then do not display range @@ 
> -2829,11 +2832,11 @@ MtrrDebugPrintAllMtrrsWorker (
>  RangeCount = 1;
> 
>  MtrrLibGetRawVariableRanges (
> -  >Variables, ARRAY_SIZE (Mtrrs->Variables.Mtrr),
> +  >Variables, VariableMtrrCount,
>MtrrValidBitsMask, MtrrValidAddressMask, RawVariableRanges
>);
>  MtrrLibApplyVariableMtrrs (
> -  RawVariableRanges, ARRAY_SIZE (RawVariableRanges),
> +  RawVariableRanges, VariableMtrrCount,
>Ranges, ARRAY_SIZE (Ranges), 
>);
> 
> --
> 2.12.2.windows.2

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

Re: [edk2] [PATCH 0/4] Update MTRR algorithm to calculate optimal settings

[Ni, Ruiyu]

I have tested to boot OVMF 32PEI+64DXE.
I have tested using random memory settings:
  1. Generate random memory settings and tried to convert the settings to MTRRs.
  2. Read back the MTRRs and verify the settings match to the desired memory 
settings.



Thanks/Ray

> -Original Message-
> From: Yao, Jiewen
> Sent: Monday, October 16, 2017 11:03 AM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH 0/4] Update MTRR algorithm to calculate optimal
> settings
> 
> Thanks.
> 
> Would you mind to share to all of us on which platform has been tested and
> which unit test has been done?
> As such people can have more confidence.
> 
> With the test description message added, reviewed-by:
> jiewen@intel.com
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Ni, Ruiyu
> > Sent: Thursday, October 12, 2017 4:48 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] [PATCH 0/4] Update MTRR algorithm to calculate optimal
> > settings
> >
> > Ruiyu Ni (4):
> >   UefiCpuPkg/MtrrLib: refine MtrrLibProgramFixedMtrr()
> >   UefiCpuPkg/MtrrLib: Optimize MtrrLibLeastAlignment()
> >   UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings
> >   UefiCpuPkg/MtrrLib: Skip Base MSR access when the pair is invalid
> >
> >  UefiCpuPkg/Include/Library/MtrrLib.h |   45 +-
> >  UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 2605
> > --
> >  2 files changed, 1550 insertions(+), 1100 deletions(-)
> >
> > --
> > 2.12.2.windows.2
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] SourceLevelDebugPkg: Update SmmDebugAgentLib to restore APIC timer

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Gao, Liming
> Sent: Tuesday, October 10, 2017 6:04 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [Patch] SourceLevelDebugPkg: Update SmmDebugAgentLib to
> restore APIC timer
> 
> In enter SMI, APIC timer may be initialized. After exit SMI, APIC timer will 
> be
> restore.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao <liming@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> ---
>  .../DebugAgent/SmmDebugAgent/SmmDebugAgentLib.c | 21
> -
>  1 file changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git
> a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgent/SmmDebug
> AgentLib.c
> b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgent/SmmDebu
> gAgentLib.c
> index 11afd32..6be8c54 100644
> ---
> a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgent/SmmDebug
> AgentLib.c
> +++
> b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgent/SmmDebu
> gAgent
> +++ Lib.c
> @@ -20,6 +20,11 @@ UINTN   mSavedDebugRegisters[6];
>  IA32_IDT_GATE_DESCRIPTORmIdtEntryTable[33];
>  BOOLEAN mSkipBreakpoint = FALSE;
>  BOOLEAN mSmmDebugIdtInitFlag = FALSE;
> +BOOLEAN mApicTimerRestore = FALSE;
> +BOOLEAN mPeriodicMode;
> +UINT32  mTimerCycle;
> +UINTN   mApicTimerDivisor;
> +UINT8   mVector;
> 
>  CHAR8 mWarningMsgIgnoreSmmEntryBreak[] = "Ignore smmentrybreak
> setting for SMI issued during DXE debugging!\r\n";
> 
> @@ -191,8 +196,6 @@ InitializeDebugAgent (
>DEBUG_AGENT_MAILBOX   *Mailbox;
>UINT64*MailboxLocation;
>UINT32DebugTimerFrequency;
> -  BOOLEAN   PeriodicMode;
> -  UINTN TimerCycle;
> 
>switch (InitFlag) {
>case DEBUG_AGENT_INIT_SMM:
> @@ -289,9 +292,10 @@ InitializeDebugAgent (
>  // Check if CPU APIC Timer is working, otherwise initialize it.
>  //
>  InitializeLocalApicSoftwareEnable (TRUE);
> -GetApicTimerState (NULL, , NULL);
> -TimerCycle = GetApicTimerInitCount ();
> -if (!PeriodicMode || TimerCycle == 0) {
> +GetApicTimerState (, , );
> +mTimerCycle = GetApicTimerInitCount ();
> +if (!mPeriodicMode || mTimerCycle == 0) {
> +  mApicTimerRestore = TRUE;
>InitializeDebugTimer (NULL, FALSE);
>  }
>  Mailbox = GetMailboxPointer ();
> @@ -327,6 +331,13 @@ InitializeDebugAgent (
>  //
>  mSkipBreakpoint = FALSE;
>  RestoreDebugRegister ();
> +//
> +// Restore APIC Timer
> +//
> +if (mApicTimerRestore) {
> +  InitializeApicTimer (mApicTimerDivisor, mTimerCycle, mPeriodicMode,
> mVector);
> +  mApicTimerRestore = FALSE;
> +}
>  break;
> 
>case DEBUG_AGENT_INIT_THUNK_PEI_IA32TOX64:
> --
> 2.8.0.windows.1

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

Re: [edk2] [Patch v2 0/3] Add SmmEndOfS3Resume event.

[Ni, Ruiyu]

Please don't forget to change the structure name as proposed by Jiewen.
Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Dong, Eric
> Sent: Wednesday, October 11, 2017 1:32 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Yao, Jiewen <jiewen@intel.com>
> Subject: [Patch v2 0/3] Add SmmEndOfS3Resume event.
> 
> This patch series add new SmmEndOfS3Resume event which required by
> some SMM drivers.
> It will implmented by SmmCore to install the
> gEdkiiSmmEndOfS3ResumeProtocolGuid
> Protocol. Smm drivers can install this protocol's notification functions to 
> hoot
> this envet.
> It will be trigged right after the EndOfPei event in S3 resume phase.
> 
> V2 Changes: Only change patch 2/3
> 1. Change structures name to avoid they start with EFI_.
> 2. Base on DXE phase bits to provide communication buffer, current
> implement check both PEI and DXE phase.
> 
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong <eric.d...@intel.com>
> 
> Eric Dong (3):
>   MdeModulePkg/SmmEndOfS3Resume.h: Add new protocol definition.
>   UefiCpuPkg/S3Resume2Pei: Send S3 resume finished event to SmmCore.
>   MdeModulePkg/PiSmmCore: Install Protocol when S3 resume finished.
> 
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.c| 55 --
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.h| 24 ++
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf  |  1 +
>  MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h   | 31 
>  MdeModulePkg/MdeModulePkg.dec  |  3 +
>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c  | 85
> ++
>  .../Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf   |  4 +
>  7 files changed, 196 insertions(+), 7 deletions(-)  create mode 100644
> MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h
> 
> --
> 2.7.0.windows.1

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

Re: [edk2] [Patch 2/3] UefiCpuPkg/S3Resume2Pei: Send S3 resume finished event to SmmCore.

[Ni, Ruiyu]

Eric,
We may have 4 combinations for PEI DXE CPU architecture:
1. 32bit PEI + 32bit DXE: sizeof (UINTN) == sizeof (UINT32) && NOT 
PcdDxeIplSwitchToLongMode
2. 32bit PEI + 64bit DXE: sizeof (UINTN) == sizeof (UINT32) && 
PcdDxeIplSwitchToLongMode
3. 64bit PEI + 32bit DXE: NA!!!
4. 64bit PEI + 64bit DXE: sizeof (UINTN) != sizeof (UINT32) && NOT 
PcdDxeIplSwitchToLongMode

For #4, your code treats MessageLength as 4-byte, but actually it should be 
8-byte.
So how about we just check PcdDxeIplSwitchToLongMode, when it's FALSE, sizeof 
(MessageLength) equals to sizeof (UINTN).
Otherwise, sizeof (MessageLength) equals to 8.

So you only need to define:
> +typedef struct {
> +  EFI_GUID  HeaderGuid;
> +  UINT64MessageLength;
> +  UINT8 Data[1];
> +} EFI_SMM_COMMUNICATE_HEADER_IA64;

And I recommend to change the structure name to X64_EFI_SMM_COMMUNICATE_HEADER 
or
IA64_EFI_SMM_COMMUNICATE_HEADER. I am neutral using X64 or IA64, but don't want 
to have EFI_ in the beginning.

Thanks/Ray

> -Original Message-
> From: Dong, Eric
> Sent: Wednesday, October 11, 2017 10:23 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Yao, Jiewen <jiewen@intel.com>
> Subject: [Patch 2/3] UefiCpuPkg/S3Resume2Pei: Send S3 resume finished
> event to SmmCore.
> 
> Driver will send S3 resume finished event to SmmCore through communicate
> buffer after it signals EndOfPei event.
> 
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong <eric.d...@intel.com>
> ---
>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c  | 85
> ++
>  .../Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf   |  4 +
>  2 files changed, 89 insertions(+)
> 
> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> index e53ed21..8350eb9 100644
> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> @@ -28,6 +28,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +#include 
> 
>  #include 
>  #include 
> @@ -151,6 +154,23 @@ typedef union {
>UINT64Uint64;
>  } PAGE_TABLE_1G_ENTRY;
> 
> +//
> +// Define two type of smm communicate headers.
> +// One for 32 bits  PEI + 64 bits DXE, the other for 32 bits PEI + 32 bits 
> DXE
> case.
> +//
> +typedef struct {
> +
> +  EFI_GUID  HeaderGuid;
> +  UINT32MessageLength;
> +  UINT8 Data[1];
> +} EFI_SMM_COMMUNICATE_HEADER_IA32;
> +
> +typedef struct {
> +  EFI_GUID  HeaderGuid;
> +  UINT64MessageLength;
> +  UINT8 Data[1];
> +} EFI_SMM_COMMUNICATE_HEADER_IA64;
> +
>  #pragma pack()
> 
>  //
> @@ -430,6 +450,65 @@ IsLongModeWakingVector (  }
> 
>  /**
> +  Send EndOfS3Resume event to SmmCore through communication buffer
> way.
> +
> +  @retval  EFI_SUCCESS Return send the event success.
> +**/
> +EFI_STATUS
> +SignalEndOfS3Resume (
> +  VOID
> +  )
> +{
> +  EFI_STATUS Status;
> +  EFI_PEI_SMM_COMMUNICATION_PPI  *SmmCommunicationPpi;
> +  UINTN  CommSize;
> +  EFI_SMM_COMMUNICATE_HEADER_IA32Header32;
> +  EFI_SMM_COMMUNICATE_HEADER_IA64Header64;
> +  VOID   *CommBuffer;
> +
> +  DEBUG ((EFI_D_INFO, "SignalEndOfS3Resume - Enter\n"));
> +
> +  //
> +  // Detect whether current is 32 bits PEI + 64 bits DXE case.
> +  //
> +  if ((sizeof(UINTN) == sizeof(UINT32)) && (FeaturePcdGet
> (PcdDxeIplSwitchToLongMode))) {
> +CommBuffer = 
> +Header64.MessageLength = 0;
> +CommSize = sizeof (EFI_SMM_COMMUNICATE_HEADER_IA64);
> +  } else {
> +CommBuffer = 
> +Header32.MessageLength = 0;
> +CommSize = sizeof (EFI_SMM_COMMUNICATE_HEADER_IA32);
> +  }
> +  CopyGuid (CommBuffer, );
> +
> +  //
> +  // Get needed resource
> +  //
> +  Status = PeiServicesLocatePpi (
> + ,
> + 0,
> + NULL,
> + (VOID **)
> + );
> +  ASSERT_EFI_ERROR (Status);
> +
> +  //
> +  // Send command
> +  //
> +  Status = SmmCommunicationPpi->Communicate (
> +  SmmCommunicationPpi,
> +  (VOID *)CommBuffer,
> +  
> +  );
> +  ASSERT_EFI_ERROR (Status);
> +
> +  DEBUG ((EFI_D_INFO, "SignalEndOfS3Resume - Exit (%r)\n", Status));
> +
> +  return Status;
> +}
> +
> +/**
> 

Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: don't ASSERT on 'BootNext' varname

[Ni, Ruiyu]

All,
I just sent out two patches. One to remove the assertion, the other to fix a 
bug in EfiBootManagerIsValidLoadOptionVariableName.

Thanks/Ray

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, October 5, 2017 5:08 PM
> To: Laszlo Ersek <ler...@redhat.com>
> Cc: Zeng, Star <star.z...@intel.com>; Ard Biesheuvel
> <ard.biesheu...@linaro.org>; Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric
> <eric.d...@intel.com>; edk2-devel@lists.01.org; leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: don't ASSERT
> on 'BootNext' varname
> 
> Thank you star.
> 
> I ack this update.
> 
> I recall we did a review for bds on variable usage and assert usage and fixed 
> such
> issue. If this is a regression, we probable need review again.
> 
> thank you!
> Yao, Jiewen
> 
> 
> > 在 2017年10月5日，下午3:59，Laszlo Ersek <ler...@redhat.com> 写道：
> >
> >> On 10/05/17 09:31, Zeng, Star wrote:
> >> I got your point.
> >> From literal meaning of the API, I agree the ASSERT should be removed.
> >> If the input parameter is assumed to be valid always, the API could be not
> called at all.
> >> If the input parameter is not assumed to be valid always, the API should 
> >> not
> assert.
> >>
> >> I just tried an experiment and can easily reproduce the assert.
> >> 1. Boot NT32 to shell.
> >> 2. Create L"BootNext" variable with shell command: setvar BootNext -NV -RT
> -BS =.
> >> 3. Reboot and then ASSERT.
> >> ASSERT!: [BdsDxe]
> >> i:\git\edk2git\edk2\MdeModulePkg\Library\UefiBootManagerLib\BmMisc.c
> >> (423): ((BOOLEAN)(0==1))
> >>
> >> The calling stack is:
> >> BdsEntry(BdsEntry.c L844) ->
> >>  EfiBootManagerGetLoadOptions(BdsLoadOption.c L1092) ->
> >>BmCollectLoadOptions() with L"BootNext" from the loop in
> BmForEachVariable() ->
> >>  EfiBootManagerIsValidLoadOptionVariableName() ->
> >>BmCharToUint() ->
> >>  ASSERT(FALSE)
> >>
> >> The assert seems new caused by
> 0e6584e38650cef9a6b4579553679c0f12d897bc as L"BootNext" was deleted
> before calling EfiBootManagerGetLoadOptions() when no this commit.
> >
> > Ah, good point!
> >
> > OK, so let's wait until Ray acks the removal of the assert.
> >
> > Thanks!
> > Laszlo
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Wednesday, October 4, 2017 11:06 PM
> >> To: Zeng, Star <star.z...@intel.com>; Ard Biesheuvel
> >> <ard.biesheu...@linaro.org>
> >> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric <eric.d...@intel.com>;
> >> edk2-devel@lists.01.org; leif.lindh...@linaro.org; Yao, Jiewen
> >> <jiewen@intel.com>
> >> Subject: Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: don't
> >> ASSERT on 'BootNext' varname
> >>
> >> Star,
> >>
> >>> On 10/04/17 16:09, Zeng, Star wrote:
> >>> Thanks for confirming the urgency.
> >>>
> >>> I have no strong motivation to keep/remove the ASSERT, I would like Ruiyu
> to argue and make the decision.
> >>> I mainly want the issue (the code ends up calling this
> function(EfiBootManagerIsValidLoadOptionVariableName) on L"BootNext")
> could be root caused.
> >>
> >> it might be interesting to find out about the exact call stack.
> >> However, I'd like to point out that the exact purpose of the
> >> EfiBootManagerIsValidLoadOptionVariableName() function is to check
> >> *whether* the variable name is a valid boot option name or not. If
> >> not
> >> -- for whatever reason -- then it shouldn't ASSERT(); it should just return
> FALSE.
> >>
> >> Perhaps it's relevant: the function was made public in commit 
> >> 3dc5c1ae5c757.
> >>
> >> Thanks
> >> Laszlo
> >>
> >>> -Original Message-
> >>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >>> Sent: Wednesday, October 4, 2017 9:54 PM
> >>> To: Zeng, Star <star.z...@intel.com>
> >>> Cc: Yao, Jiewen <jiewen@intel.com>; Ni, Ruiyu
> >>> <ruiyu...@intel.com>; edk2-devel@lists.01.org; Dong, Eric
> >>> <eric.d...@intel.com>; leif.lindh...@linaro.org
> >>> Subject: Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: don't
> >>> ASSERT on 'BootNext' 

Re: [edk2] [PATCH v2] TFTP : tftp fix for full volume case

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Carsey, Jaben
> Sent: Monday, October 9, 2017 10:13 PM
> To: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>; Fu, Siyuan
> <siyuan...@intel.com>; edk2-devel@lists.01.org; Ni, Ruiyu
> <ruiyu...@intel.com>; Ye, Ting <ting...@intel.com>
> Subject: RE: [PATCH v2] TFTP : tftp fix for full volume case
> 
> I am fine. Ray?
> 
> Reviewed-by: Jaben Carsey <jaben.car...@intel.com>
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Meenakshi Aggarwal
> > Sent: Sunday, October 08, 2017 11:28 PM
> > To: Fu, Siyuan <siyuan...@intel.com>; edk2-devel@lists.01.org; Ni,
> > Ruiyu <ruiyu...@intel.com>; Carsey, Jaben <jaben.car...@intel.com>;
> > Ye, Ting <ting...@intel.com>
> > Subject: Re: [edk2] [PATCH v2] TFTP : tftp fix for full volume case
> > Importance: High
> >
> > Hi Team,
> >
> >
> > Any further comments on this patch?
> >
> > Or is it ready to merge in edk2?
> >
> >
> > Thanks,
> > Meenakshi
> >
> > > -Original Message-
> > > From: Meenakshi Aggarwal
> > > Sent: Wednesday, September 27, 2017 9:01 AM
> > > To: 'Fu, Siyuan' <siyuan...@intel.com>; edk2-devel@lists.01.org; Ni,
> > > Ruiyu <ruiyu...@intel.com>; Carsey, Jaben <jaben.car...@intel.com>;
> > > Ye, Ting <ting...@intel.com>
> > > Cc: Udit Kumar <udit.ku...@nxp.com>; Vabhav Sharma
> > > <vabhav.sha...@nxp.com>
> > > Subject: RE: [PATCH v2] TFTP : tftp fix for full volume case
> > >
> > > Hi,
> > >
> > > Thanks for the review Siyuan.
> > >
> > >
> > > Ting,
> > >
> > > Any comment from your side?
> > >
> > > Thanks,
> > > Meenakshi
> > >
> > > > -Original Message-
> > > > From: Fu, Siyuan [mailto:siyuan...@intel.com]
> > > > Sent: Tuesday, September 26, 2017 6:12 AM
> > > > To: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>; edk2-
> > > > de...@lists.01.org; Ni, Ruiyu <ruiyu...@intel.com>; Carsey, Jaben
> > > > <jaben.car...@intel.com>
> > > > Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Ye, Ting
> > > > <ting...@intel.com>; Udit Kumar <udit.ku...@nxp.com>; Vabhav
> > Sharma
> > > > <vabhav.sha...@nxp.com>
> > > > Subject: RE: [PATCH v2] TFTP : tftp fix for full volume case
> > > >
> > > > Reviewed-by: Fu Siyuan <siyuan...@intel.com>
> > > >
> > > > -Original Message-
> > > > From: Meenakshi Aggarwal [mailto:meenakshi.aggar...@nxp.com]
> > > > Sent: Monday, September 25, 2017 11:06 PM
> > > > To: edk2-devel@lists.01.org; Ni, Ruiyu <ruiyu...@intel.com>;
> > > > Carsey, Jaben <jaben.car...@intel.com>
> > > > Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Fu,
> > > > Siyuan <siyuan...@intel.com>; Ye, Ting <ting...@intel.com>;
> > > > Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>; Udit Kumar
> > > > <udit.ku...@nxp.com>; Vabhav Sharma <vabhav.sha...@nxp.com>
> > > > Subject: [PATCH v2] TFTP : tftp fix for full volume case
> > > >
> > > > Issue :
> > > > When storage media is full, tftp was resulting in ASSERT
> > > > MdeModulePkg/Core/Dxe/Mem/Page.c, because number of pages was
> > > zero.
> > > >
> > > > Reason:
> > > > While doing tftp, function call ShellWriteFile was modifying
> > > > FileSize
> > variable.
> > > > In case of full disk it was coming out to be Zero.
> > > >
> > > > Fix:
> > > > Storage the original filesize in local variable, and use this
> > > > variable while freeing the pages.
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Udit Kumar <udit.ku...@nxp.com>
> > > > Signed-off-by: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>
> > > > Signed-off-by: Vabhav Sharma <vabhav.sha...@nxp.com>
> > > > Signed-off-by: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>
> > > > ---
> > > >  ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c | 5 -
> > > >  1 file changed, 4 insertions(+), 1 deletion(-

Re: [edk2] [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA Map/Umap bounce buffer

[Ni, Ruiyu]

The "read"/"write" is from the Bus Master's point of view.


Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Daniil
> Egranov
> Sent: Monday, October 9, 2017 9:16 AM
> To: edk2-devel@lists.01.org
> Cc: leif.lindh...@linaro.org; Zeng, Star ;
> ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA
> Map/Umap bounce buffer
> 
> The patch corrects the logic of transferring data between a bounce buffer and 
> a
> real buffer above 4GB:
> 1. In the case of mapping a bounce buffer for the write operation, data from a
> real buffer should be copied into a bounce buffer.
> 2.In the case of unmapping a bounce buffer for the read operation, data should
> be copied from a bounce buffer into a real buffer.
> 
> The patch resolves a Juno board issue with the the grub and SATA drives.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Daniil Egranov 
> ---
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> index dc06c16dc0..877fa2fd13 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> @@ -1153,12 +1153,12 @@ RootBridgeIoMap (
>  }
> 
>  //
> -// If this is a read operation from the Bus Master's point of view,
> +// If this is a write operation from the Bus Master's point of
> + view,
>  // then copy the contents of the real buffer into the mapped buffer
>  // so the Bus Master can read the contents of the real buffer.
>  //
> -if (Operation == EfiPciOperationBusMasterRead ||
> -Operation == EfiPciOperationBusMasterRead64) {
> +if (Operation == EfiPciOperationBusMasterWrite ||
> +Operation == EfiPciOperationBusMasterWrite64) {
>CopyMem (
>  (VOID *) (UINTN) MapInfo->MappedHostAddress,
>  (VOID *) (UINTN) MapInfo->HostAddress, @@ -1256,12 +1256,12 @@
> RootBridgeIoUnmap (
>RemoveEntryList (>Link);
> 
>//
> -  // If this is a write operation from the Bus Master's point of view,
> +  // If this is a read operation from the Bus Master's point of view,
>// then copy the contents of the mapped buffer into the real buffer
>// so the processor can read the contents of the real buffer.
>//
> -  if (MapInfo->Operation == EfiPciOperationBusMasterWrite ||
> -  MapInfo->Operation == EfiPciOperationBusMasterWrite64) {
> +  if (MapInfo->Operation == EfiPciOperationBusMasterRead ||
> +  MapInfo->Operation == EfiPciOperationBusMasterRead64) {
>  CopyMem (
>(VOID *) (UINTN) MapInfo->HostAddress,
>(VOID *) (UINTN) MapInfo->MappedHostAddress,
> --
> 2.11.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add check to void use null pointer.

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Eric
> Dong
> Sent: Monday, October 9, 2017 11:18 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add check to void use
> null pointer.
> 
> Current code logic not check the pointer before use it. This may has potential
> issue, this patch add code to check it.
> 
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong <eric.d...@intel.com>
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> index ef72b9b..2c1dc82 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> @@ -226,12 +226,17 @@ SetProcessorRegister (
>CPU_REGISTER_TABLE*RegisterTable;
> 
>InitApicId = GetInitialApicId ();
> +  RegisterTable = NULL;
>for (Index = 0; Index < RegisterTableCount; Index++) {
>  if (RegisterTables[Index].InitialApicId == InitApicId) {
>RegisterTable =  [Index];
>break;
>  }
>}
> +  ASSERT (RegisterTable != NULL);
> +  if (RegisterTable == NULL) {
> +return;
> +  }
> 
>//
>// Traverse Register Table of this logical processor
> --
> 2.7.0.windows.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] [PATCH v3] Ifconfig : Fixed False information about Media State.

[Ni, Ruiyu]

Do you need to put all the hard-code string in UNI file for localization?

Thanks/Ray

> -Original Message-
> From: Wu, Jiaxin
> Sent: Monday, October 9, 2017 9:29 AM
> To: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>; Carsey, Jaben
> <jaben.car...@intel.com>; edk2-devel@lists.01.org; Ni, Ruiyu
> <ruiyu...@intel.com>
> Subject: RE: [PATCH v3] Ifconfig : Fixed False information about Media State.
> 
> I agree with Jaben. If NetLibDetectMedia return error status, we can output as
> below:
> 
>   ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> (STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle, L"Media state
> unknown");
> 
> Thanks,
> Jiaxin
> 
> > -Original Message-
> > From: Meenakshi Aggarwal [mailto:meenakshi.aggar...@nxp.com]
> > Sent: Sunday, October 8, 2017 4:49 PM
> > To: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel@lists.01.org;
> > Wu, Jiaxin <jiaxin...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
> > Subject: RE: [PATCH v3] Ifconfig : Fixed False information about Media 
> > State.
> >
> > It is hard to say when can an API fail because its dependent on
> > implementation.
> >
> >
> > > -Original Message-
> > > From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> > > Sent: Friday, October 06, 2017 7:32 PM
> > > To: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>; edk2-
> > > de...@lists.01.org; Wu, Jiaxin <jiaxin...@intel.com>; Ni, Ruiyu
> > > <ruiyu...@intel.com>
> > > Subject: RE: [PATCH v3] Ifconfig : Fixed False information about
> > > Media
> > State.
> > >
> > > Reviewed-by: Jaben Carsey <jaben.car...@intel.com> Do you know under
> > > what conditions the API will fail? Is it worth saying something like
> > > media
> > stats
> > > unknown when the function fails?
> > >
> > > Ray,
> > >
> > > What do you think?
> > >
> > >
> > > > -Original Message-
> > > > From: Meenakshi Aggarwal [mailto:meenakshi.aggar...@nxp.com]
> > > > Sent: Thursday, October 05, 2017 9:48 PM
> > > > To: edk2-devel@lists.01.org; Wu, Jiaxin <jiaxin...@intel.com>;
> > > > Carsey, Jaben <jaben.car...@intel.com>; Ni, Ruiyu
> > > > <ruiyu...@intel.com>
> > > > Cc: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>
> > > > Subject: [PATCH v3] Ifconfig : Fixed False information about Media 
> > > > State.
> > > > Importance: High
> > > >
> > > > Issue : We were setting MediaPresent as TRUE (default) and not
> > > > checking return status of NetLibDetectMedia().
> > > > NetLibDetectMedia() sets MediaPresent FLAG in case of success only
> > > > and dont change flag on error.
> > > > So, Media State will display as 'Media Present', in case of error
> > > > also.
> > > >
> > > > Fix : Check return value of NetLibDetectMedia()
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > >
> > > > Signed-off-by: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>
> > > > ---
> > > >  ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c | 11
> > > > +++--
> > > > --
> > > >  1 file changed, 7 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git
> > > > a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> > > > b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> > > > index 4db07b2..90ca724 100644
> > > > --- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> > > > +++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> > > > @@ -576,11 +576,14 @@ IfConfigShowInterfaceInfo (
> > > >  //
> > > >  // Get Media State.
> > > >  //
> > > > -NetLibDetectMedia (IfCb->NicHandle, );
> > > > -if (!MediaPresent) {
> > > > -  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> > > > (STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle,
> > L"Media
> > > > disconnected");
> > > > +if (EFI_SUCCESS == NetLibDetectMedia (IfCb->NicHandle,
> > > > )) {
> > > > +  if (!MediaPresent) {
> > > > +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> > > > (STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle,
> > L"Media
> > > > disconnected");
> > > > +  } else {
> > > > +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> > > > (STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle,
> > L"Media
> > > > present");
> > > > +  }
> > > >  } else {
> > > > -  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> > > > (STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle,
> > L"Media
> > > > present");
> > > > +  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> > > > (STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle,
> > L"Media
> > > > disconnected");
> > > >  }
> > > >
> > > >  //
> > > > --
> > > > 2.7.4

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

Re: [edk2] [Patch V2] Build spec: add description for build with binary cache

[Ni, Ruiyu]

If use both flags is same as --hash.
Can we just get rid of --hash and just use the existing two flags?
In this way, we can hide the internal implementation of how to check 
modification.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
> Liming
> Sent: Saturday, September 30, 2017 1:03 PM
> To: Laszlo Ersek ; Zhu, Yonghong
> ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Shaw, Kevin W
> 
> Subject: Re: [edk2] [Patch V2] Build spec: add description for build with 
> binary
> cache
> 
> Laszlo:
>   --binary-destination is to cache the generated binary in this directory, 
> --binary-
> source is to fetch the cached binary from this directory. If they are used
> together, the behavior will be same that --hash option only and Build output
> directory. We don't think it is the necessary usage model. So, we don't add 
> this
> support. If you have the real case that depends on their combination, we can
> plan to add it.
> 
> Thanks
> Liming
> >-Original Message-
> >From: Laszlo Ersek [mailto:ler...@redhat.com]
> >Sent: Thursday, September 28, 2017 8:14 PM
> >To: Zhu, Yonghong ; edk2-devel@lists.01.org
> >Cc: Kinney, Michael D ; Shaw, Kevin W
> >; Gao, Liming 
> >Subject: Re: [edk2] [Patch V2] Build spec: add description for build
> >with binary cache
> >
> >On 09/28/17 14:06, Laszlo Ersek wrote:
> >
> >> So, how can I invalidate all the cached values? Is it enough to
> >> delete the *.hash files?
> >
> >... I'm asking because I tried the --binary-destination option as well,
> >and in the bin cache directory, *.depex and *.inf files were stored as
> >well, not just *.hash values.
> >
> >So I figure, whatever gets stored in the binary cache directory, should
> >be deleted when I'd like to invalidate the cache.
> >
> >Now, removing this separate cache directory altogether would solve my
> >question; but that would require me to use "--binary-destination" and
> >"--binary-source" together. The idea is that "--hash" would fetch the
> >hash values from that separate directory, and it would also write the
> >new hash values back to that directory. In addition this directory
> >would be very easy to remove, so "--hash" would know whenever the hash
> >was empty.
> >
> >However, it looks like "--binary-destination" and "--binary-source"
> >cannot be used together. Why is that?
> >
> >Thanks,
> >Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/PciBus: Count multiple hotplug resource paddings

[Ni, Ruiyu]

Laszlo,
Please check whether this patch can resolve the hang issue you reported.
I don't use your suggestion to use the MAX resource paddings.
Instead, I count all the resource paddings.

If it can work, I will submit another patch to clean up the code in 
CalculateApertureIo16().
That function could be similar to the CalculateAperture().

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu
> Ni
> Sent: Saturday, September 30, 2017 1:11 PM
> To: edk2-devel@lists.01.org
> Cc: Laszlo Ersek <ler...@redhat.com>
> Subject: [edk2] [PATCH] MdeModulePkg/PciBus: Count multiple hotplug
> resource paddings
> 
> The current implementation assumes there is only one hotplug resource padding
> for each resource type. It's not true considering
> DegradeResource(): MEM64 resource could be degraded to MEM32 resource.
> 
> The patch treat the resource paddings using the same logic as treating
> typical/actual resources and the total resource of a bridge is set to the MAX 
> of
> typical/actual resources and resource paddings.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> ---
>  .../Bus/Pci/PciBusDxe/PciResourceSupport.c | 67 
> +++---
>  1 file changed, 21 insertions(+), 46 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> index e93134613b..f086b1732d 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> @@ -343,14 +343,9 @@ CalculateResourceAperture (
>IN PCI_RESOURCE_NODE*Bridge
>)
>  {
> -  UINT64Aperture;
> +  UINT64Aperture[2];
>LIST_ENTRY*CurrentLink;
>PCI_RESOURCE_NODE *Node;
> -  UINT64PaddingAperture;
> -  UINT64Offset;
> -
> -  Aperture= 0;
> -  PaddingAperture = 0;
> 
>if (Bridge == NULL) {
>  return ;
> @@ -362,6 +357,8 @@ CalculateResourceAperture (
>  return ;
>}
> 
> +  Aperture[PciResUsageTypical] = 0;
> +  Aperture[PciResUsagePadding] = 0;
>//
>// Assume the bridge is aligned
>//
> @@ -369,58 +366,30 @@ CalculateResourceAperture (
>; !IsNull (>ChildList, CurrentLink)
>; CurrentLink = GetNextNode (>ChildList, CurrentLink)
>) {
> -
>  Node = RESOURCE_NODE_FROM_LINK (CurrentLink);
> -if (Node->ResourceUsage == PciResUsagePadding) {
> -  ASSERT (PaddingAperture == 0);
> -  PaddingAperture = Node->Length;
> -  continue;
> -}
> 
>  //
> -// Apply padding resource if available
> +// It's possible for a bridge to contain multiple padding resource
> +// nodes due to DegradeResource().
>  //
> -Offset = Aperture & (Node->Alignment);
> -
> -if (Offset != 0) {
> -
> -  Aperture = Aperture + (Node->Alignment + 1) - Offset;
> -
> -}
> -
> +ASSERT ((Node->ResourceUsage == PciResUsageTypical) ||
> +(Node->ResourceUsage == PciResUsagePadding));
> +ASSERT (Node->ResourceUsage < ARRAY_SIZE (Aperture));
>  //
>  // Recode current aperture as a offset
> -// this offset will be used in future real allocation
> +// Apply padding resource to meet alignment requirement
> +// Node offset will be used in future real allocation
>  //
> -Node->Offset = Aperture;
> +Node->Offset = ALIGN_VALUE (Aperture[Node->ResourceUsage],
> + Node->Alignment + 1);
> 
>  //
> -// Increment aperture by the length of node
> +// Record the total aperture.
>  //
> -Aperture += Node->Length;
> -  }
> -
> -  //
> -  // At last, adjust the aperture with the bridge's
> -  // alignment
> -  //
> -  Offset = Aperture & (Bridge->Alignment);
> -  if (Offset != 0) {
> -Aperture = Aperture + (Bridge->Alignment + 1) - Offset;
> +Aperture[Node->ResourceUsage] = Node->Offset + Node->Length;
>}
> 
>//
> -  // If the bridge has already padded the resource and the
> -  // amount of padded resource is larger, then keep the
> -  // padded resource
> -  //
> -  if (Bridge->Length < Aperture) {
> -Bridge->Length = Aperture;
> -  }
> -
> -  //
> -  // Adjust the bridge's alignment to the first child's alignment
> -  // if the bridge has at least one child
> +  // Adjust the bridge's alignment to the MAX (first) alignment of all 
> children.
>//
>CurrentLink = Bridge

Re: [edk2] [Patch v2 1/2] UefiCpuPkg/PiSmmCpuDxeSmm: Combine INIT-SIPI-SIPI.

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

-Original Message-
From: Dong, Eric 
Sent: Friday, September 29, 2017 8:27 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen <jiewen@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
Subject: [Patch v2 1/2] UefiCpuPkg/PiSmmCpuDxeSmm: Combine INIT-SIPI-SIPI.

In S3 resume path, current implementation do 2 separate INIT-SIPI-SIPI, this is 
not necessary. This change combine these 2 INIT-SIPI-SIPI to 1 and add CpuPause 
between them.

Cc: Jiewen Yao <jiewen@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.d...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 51 ---
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
index 9404501..ae4b516 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
@@ -39,6 +39,11 @@ typedef struct {
 //
 SPIN_LOCK*mMemoryMappedLock = NULL;
 
+//
+// Signal that SMM BASE relocation is complete.
+//
+volatile BOOLEAN mInitApsAfterSmmBaseReloc;
+
 /**
   Get starting address and size of the rendezvous entry for APs.
   Information for fixing a jump instruction in the code is also returned.
@@ -342,17 +347,21 @@ SetProcessorRegister (
   }
 }
 
+
+
 /**
-  AP initialization before SMBASE relocation in the S3 boot path.
+  AP initialization before then after SMBASE relocation in the S3 boot path.
 **/
 VOID
-EarlyMPRendezvousProcedure (
+MPRendezvousProcedure (
   VOID
   )
 {
   CPU_REGISTER_TABLE *RegisterTableList;
   UINT32 InitApicId;
   UINTN  Index;
+  UINTN  TopOfStack;
+  UINT8  Stack[128];
 
   LoadMtrrData (mAcpiCpuData.MtrrTable);
 
@@ -368,25 +377,18 @@ EarlyMPRendezvousProcedure (
 }
   }
 
+
   //
   // Count down the number with lock mechanism.
   //
   InterlockedDecrement (); -}
 
-/**
-  AP initialization after SMBASE relocation in the S3 boot path.
-**/
-VOID
-MPRendezvousProcedure (
-  VOID
-  )
-{
-  CPU_REGISTER_TABLE *RegisterTableList;
-  UINT32 InitApicId;
-  UINTN  Index;
-  UINTN  TopOfStack;
-  UINT8  Stack[128];
+  //
+  // Wait for BSP to signal SMM Base relocation done.
+  //
+  while (!mInitApsAfterSmmBaseReloc) {
+CpuPause ();
+  }
 
   ProgramVirtualWireMode ();
   DisableLvtInterrupts ();
@@ -500,7 +502,12 @@ EarlyInitializeCpu (
   PrepareApStartupVector (mAcpiCpuData.StartupVector);
 
   mNumberToFinish = mAcpiCpuData.NumberOfCpus - 1;
-  mExchangeInfo->ApFunction  = (VOID *) (UINTN) EarlyMPRendezvousProcedure;
+  mExchangeInfo->ApFunction  = (VOID *) (UINTN) MPRendezvousProcedure;
+
+  //
+  // Execute code for before SmmBaseReloc. Note: This flag is maintained 
across S3 boots.
+  //
+  mInitApsAfterSmmBaseReloc = FALSE;
 
   //
   // Send INIT IPI - SIPI to all APs
@@ -538,17 +545,11 @@ InitializeCpu (
   }
 
   mNumberToFinish = mAcpiCpuData.NumberOfCpus - 1;
-  //
-  // StackStart was updated when APs were waken up in EarlyInitializeCpu.
-  // Re-initialize StackAddress to original beginning address.
-  //
-  mExchangeInfo->StackStart  = (VOID *) (UINTN) mAcpiCpuData.StackAddress;
-  mExchangeInfo->ApFunction  = (VOID *) (UINTN) MPRendezvousProcedure;
 
   //
-  // Send INIT IPI - SIPI to all APs
+  // Signal that SMM base relocation is complete and to continue 
initialization.
   //
-  SendInitSipiSipiAllExcludingSelf ((UINT32)mAcpiCpuData.StartupVector);
+  mInitApsAfterSmmBaseReloc = TRUE;
 
   while (mNumberToFinish > 0) {
 CpuPause ();
--
2.7.0.windows.1

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

Re: [edk2] [Patch v2 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Refine code to avoid duplicated code.

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

-Original Message-
From: Dong, Eric 
Sent: Friday, September 29, 2017 8:27 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen <jiewen@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
Subject: [Patch v2 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Refine code to avoid 
duplicated code.

V2:
  Change function parameter to avoid touch global info in function.
  Enhance function name, make it more user friendly

V1:
  Refine code to avoid duplicate code to set processor register.

Cc: Jiewen Yao <jiewen@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.d...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 84 +++
 1 file changed, 24 insertions(+), 60 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
index ae4b516..ef72b9b 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
@@ -208,18 +208,30 @@ Returns:
 
   This function programs registers for the calling processor.
 
-  @param  RegisterTable Pointer to register table of the running processor.
+  @param  RegisterTablesPointer to register table of the running 
processor.
+  @param  RegisterTableCountRegister table count.
 
 **/
 VOID
 SetProcessorRegister (
-  IN CPU_REGISTER_TABLE*RegisterTable
+  IN CPU_REGISTER_TABLE*RegisterTables,
+  IN UINTN RegisterTableCount
   )
 {
   CPU_REGISTER_TABLE_ENTRY  *RegisterTableEntry;
   UINTN Index;
   UINTN Value;
   SPIN_LOCK *MsrSpinLock;
+  UINT32InitApicId;
+  CPU_REGISTER_TABLE*RegisterTable;
+
+  InitApicId = GetInitialApicId ();
+  for (Index = 0; Index < RegisterTableCount; Index++) {
+if (RegisterTables[Index].InitialApicId == InitApicId) {
+  RegisterTable =  [Index];
+  break;
+}
+  }
 
   //
   // Traverse Register Table of this logical processor @@ -347,36 +359,20 @@ 
SetProcessorRegister (
   }
 }
 
-
-
 /**
   AP initialization before then after SMBASE relocation in the S3 boot path.
 **/
 VOID
-MPRendezvousProcedure (
+InitializeAp (
   VOID
   )
 {
-  CPU_REGISTER_TABLE *RegisterTableList;
-  UINT32 InitApicId;
-  UINTN  Index;
   UINTN  TopOfStack;
   UINT8  Stack[128];
 
   LoadMtrrData (mAcpiCpuData.MtrrTable);
 
-  //
-  // Find processor number for this CPU.
-  //
-  RegisterTableList = (CPU_REGISTER_TABLE *) (UINTN) 
mAcpiCpuData.PreSmmInitRegisterTable;
-  InitApicId = GetInitialApicId ();
-  for (Index = 0; Index < mAcpiCpuData.NumberOfCpus; Index++) {
-if (RegisterTableList[Index].InitialApicId == InitApicId) {
-  SetProcessorRegister ([Index]);
-  break;
-}
-  }
-
+  SetProcessorRegister ((CPU_REGISTER_TABLE *) (UINTN) 
+ mAcpiCpuData.PreSmmInitRegisterTable, mAcpiCpuData.NumberOfCpus);
 
   //
   // Count down the number with lock mechanism.
@@ -393,14 +389,7 @@ MPRendezvousProcedure (
   ProgramVirtualWireMode ();
   DisableLvtInterrupts ();
 
-  RegisterTableList = (CPU_REGISTER_TABLE *) (UINTN) 
mAcpiCpuData.RegisterTable;
-  InitApicId = GetInitialApicId ();
-  for (Index = 0; Index < mAcpiCpuData.NumberOfCpus; Index++) {
-if (RegisterTableList[Index].InitialApicId == InitApicId) {
-  SetProcessorRegister ([Index]);
-  break;
-}
-  }
+  SetProcessorRegister ((CPU_REGISTER_TABLE *) (UINTN) 
+ mAcpiCpuData.RegisterTable, mAcpiCpuData.NumberOfCpus);
 
   //
   // Place AP into the safe code, count down the number with lock mechanism in 
the safe code.
@@ -475,34 +464,20 @@ PrepareApStartupVector (
 
 **/
 VOID
-EarlyInitializeCpu (
+InitializeCpuBeforeRebase (
   VOID
   )
 {
-  CPU_REGISTER_TABLE *RegisterTableList;
-  UINT32 InitApicId;
-  UINTN  Index;
-
   LoadMtrrData (mAcpiCpuData.MtrrTable);
 
-  //
-  // Find processor number for this CPU.
-  //
-  RegisterTableList = (CPU_REGISTER_TABLE *) (UINTN) 
mAcpiCpuData.PreSmmInitRegisterTable;
-  InitApicId = GetInitialApicId ();
-  for (Index = 0; Index < mAcpiCpuData.NumberOfCpus; Index++) {
-if (RegisterTableList[Index].InitialApicId == InitApicId) {
-  SetProcessorRegister ([Index]);
-  break;
-}
-  }
+  SetProcessorRegister ((CPU_REGISTER_TABLE *) (UINTN) 
+ mAcpiCpuData.PreSmmInitRegisterTable, mAcpiCpuData.NumberOfCpus);
 
   ProgramVirtualWireMode ();
 
   PrepareApStartupVector (mAcpiCpuData.StartupVector);
 
   mNumberToFinish = mAcpiCpuData.NumberOfCpus - 1;
-  mExchangeInfo->ApFunction  = (VOID *) (UINTN) MPRendezvousProcedure;
+  mExchangeInfo->ApFunction  = (VOID *) (UINTN) InitializeAp;
 
   //
   // Execute code for before SmmBaseReloc. Note: This flag is maintained 
across S3 boots.
@@ -527,22 +502,

Re: [edk2] [PATCH 1/2] ShellPkg/dh: Correct typo in help

[Ni, Ruiyu]

Yes I think so.

Thanks/Ray

> -Original Message-
> From: Carsey, Jaben
> Sent: Friday, September 29, 2017 2:30 AM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Subject: RE: [PATCH 1/2] ShellPkg/dh: Correct typo in help
> 
> Ray,
> 
> This text is taken directly from the shell spec.  Do we need to fix that also?
> 
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Thursday, September 28, 2017 10:21 AM
> > To: edk2-devel@lists.01.org
> > Cc: Carsey, Jaben <jaben.car...@intel.com>
> > Subject: [PATCH 1/2] ShellPkg/dh: Correct typo in help
> > Importance: High
> >
> > Help message of "dh" gives an example to display all handles with
> > "Image" protocol but actually "LoadedImage" protocol should be used.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Jaben Carsey <jaben.car...@intel.com>
> > ---
> >  .../UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.uni   | 4
> > ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git
> > a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Command
> > sLib.uni
> > b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Comman
> > dsLib.uni
> > index e4bff68838..3804fa7d28 100644
> > ---
> > a/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Command
> > sLib.uni
> > +++
> > b/ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Comman
> > dsLib.uni
> > @@ -401,9 +401,9 @@
> >  "  * To display all handles with 'diskio' protocol:\r\n"
> >  "Shell> dh -p diskio\r\n"
> >  " \r\n"
> > -"  * To display all handles with 'Image' protocol and break when the
> > screen is\r\n"
> > +"  * To display all handles with 'LoadedImage' protocol and break
> > +when the
> > screen is\r\n"
> >  "full:\r\n"
> > -"Shell> dh -p Image -b\r\n"
> > +"Shell> dh -p LoadedImage -b\r\n"
> >  ".SH RETURNVALUES\r\n"
> >  " \r\n"
> >  "RETURN VALUES:\r\n"
> > --
> > 2.12.2.windows.2

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

Re: [edk2] [Patch 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Refine code to avoid duplicated code.

[Ni, Ruiyu]

1. We could either use BOOLEAN flag to tell SetProcessorRegister() which 
register table to use.
Or, pass both RegisterTableList and CpuNum into SetProcessorRegister().
I prefer the latter one.
VOID
SetProcessorRegister (
  IN CPU_REGISTER_TABLE*RegisterTables，
  IN UINTN RegisterTableCount
  );


2. How about change MPRendezvousProcedure to InitializeAp?

Thanks/Ray

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, September 28, 2017 5:31 PM
> To: Dong, Eric <eric.d...@intel.com>; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Zeng,
> Star <star.z...@intel.com>
> Subject: RE: [edk2] [Patch 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Refine code to
> avoid duplicated code.
> 
> Just FYI, another idea is to declare SetProcessorRegister() like below, then 
> the
> caller of SetProcessorRegister() has no need to touch mAcpiCpuData.
> 
> VOID
> SetProcessorRegister (
>   IN BOOLEAN PreSmmFlag
>   )
> {
>   CPU_REGISTER_TABLE*RegisterTableList;
> ...
>   if (PreSmmFlag) {
> RegisterTableList = (CPU_REGISTER_TABLE *) (UINTN)
> mAcpiCpuData.PreSmmInitRegisterTable;
>   } else {
> RegisterTableList = (CPU_REGISTER_TABLE *) (UINTN)
> mAcpiCpuData.RegisterTable;
>   }
> ...
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Eric
> Dong
> Sent: Thursday, September 28, 2017 5:15 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Yao, Jiewen <jiewen@intel.com>
> Subject: [edk2] [Patch 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Refine code to
> avoid duplicated code.
> 
> Refine code to avoid duplicate code to set processor register.
> 
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong <eric.d...@intel.com>
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 78 ++--
> ---
>  1 file changed, 20 insertions(+), 58 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> index ae4b516..500a0e2 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> @@ -208,18 +208,28 @@ Returns:
> 
>This function programs registers for the calling processor.
> 
> -  @param  RegisterTable Pointer to register table of the running processor.
> +  @param  RegisterTableList Pointer to register table of the running
> processor.
> 
>  **/
>  VOID
>  SetProcessorRegister (
> -  IN CPU_REGISTER_TABLE*RegisterTable
> +  IN CPU_REGISTER_TABLE*RegisterTableList
>)
>  {
>CPU_REGISTER_TABLE_ENTRY  *RegisterTableEntry;
>UINTN Index;
>UINTN Value;
>SPIN_LOCK *MsrSpinLock;
> +  UINT32InitApicId;
> +  CPU_REGISTER_TABLE*RegisterTable;
> +
> +  InitApicId = GetInitialApicId ();
> +  for (Index = 0; Index < mAcpiCpuData.NumberOfCpus; Index++) {
> +if (RegisterTableList[Index].InitialApicId == InitApicId) {
> +  RegisterTable =  [Index];
> +  break;
> +}
> +  }
> 
>//
>// Traverse Register Table of this logical processor @@ -347,8 +357,6 @@
> SetProcessorRegister (
>}
>  }
> 
> -
> -
>  /**
>AP initialization before then after SMBASE relocation in the S3 boot path.
>  **/
> @@ -357,26 +365,12 @@ MPRendezvousProcedure (
>VOID
>)
>  {
> -  CPU_REGISTER_TABLE *RegisterTableList;
> -  UINT32 InitApicId;
> -  UINTN  Index;
>UINTN  TopOfStack;
>UINT8  Stack[128];
> 
>LoadMtrrData (mAcpiCpuData.MtrrTable);
> 
> -  //
> -  // Find processor number for this CPU.
> -  //
> -  RegisterTableList = (CPU_REGISTER_TABLE *) (UINTN)
> mAcpiCpuData.PreSmmInitRegisterTable;
> -  InitApicId = GetInitialApicId ();
> -  for (Index = 0; Index < mAcpiCpuData.NumberOfCpus; Index++) {
> -if (RegisterTableList[Index].InitialApicId == InitApicId) {
> -  SetProcessorRegister ([Index]);
> -  break;
> -}
> -  }
> -
> +  SetProcessorRegister ((CPU_REGISTER_TABLE *) (UINTN)
> + mAcpiCpuData.PreSmmInitRegisterTable);
> 
>//
>// Count down the number with lock mechanism.
> @@ -393,14 +387,7 @@ MPRendezvousProcedure (
>ProgramVirtualWireMode ();
>DisableLvtInterrupts ();
> 
> -  RegisterTableList = (CPU_REGISTER_TABLE *) (UINTN)

Re: [edk2] [PATCH v2] ShellPkg/dh: Add the 'dh' dump support for Partition Info protocol

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, September 28, 2017 4:33 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A <hao.a...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>; Carsey,
> Jaben <jaben.car...@intel.com>
> Subject: [PATCH v2] ShellPkg/dh: Add the 'dh' dump support for Partition Info
> protocol
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=655
> 
> V2 change:
> Put some strings into the UNI file for localization.
> 
> The dump information will include:
> a. The type of the partition (Mbr, Gpt or Other); b. Whether the partition is 
> an
> EFI System Partition.
> 
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Jaben Carsey <jaben.car...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu <hao.a...@intel.com>
> ---
>  .../UefiHandleParsingLib/UefiHandleParsingLib.c| 86
> ++
>  .../UefiHandleParsingLib/UefiHandleParsingLib.h|  1 +
>  .../UefiHandleParsingLib/UefiHandleParsingLib.inf  |  1
> +  .../UefiHandleParsingLib/UefiHandleParsingLib.uni  |  9 +++
>  4 files changed, 97 insertions(+)
> 
> diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> index d12466c7b0..a228226623 100644
> --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> @@ -1933,6 +1933,87 @@ ERROR_EXIT:
>return NULL;
>  }
> 
> +/**
> +  Function to dump information about Partition Information protocol.
> +
> +  This will allocate the return buffer from boot services pool.
> +
> +  @param[in] TheHandle  The handle that has the protocol installed.
> +  @param[in] VerboseTRUE for additional information, FALSE otherwise.
> +
> +  @retval A pointer to a string containing the information.
> +**/
> +CHAR16*
> +EFIAPI
> +PartitionInfoProtocolDumpInformation (
> +  IN CONST EFI_HANDLE TheHandle,
> +  IN CONST BOOLEANVerbose
> +  )
> +{
> +  EFI_STATUS  Status;
> +  EFI_PARTITION_INFO_PROTOCOL *PartitionInfo;
> +  CHAR16  *PartitionType;
> +  CHAR16  *EfiSystemPartition;
> +  CHAR16  *RetVal;
> +
> +  if (!Verbose) {
> +return NULL;
> +  }
> +
> +  Status = gBS->OpenProtocol (
> +TheHandle,
> +,
> +(VOID**),
> +gImageHandle,
> +NULL,
> +EFI_OPEN_PROTOCOL_GET_PROTOCOL
> +);
> +  if (EFI_ERROR (Status)) {
> +return NULL;
> +  }
> +
> +  HandleParsingHiiInit ();
> +
> +  switch (PartitionInfo->Type) {
> +  case PARTITION_TYPE_OTHER:
> +PartitionType = HiiGetString (mHandleParsingHiiHandle,
> STRING_TOKEN(STR_PARTINFO_DUMP_TYPE_OTHER), NULL);
> +break;
> +  case PARTITION_TYPE_MBR:
> +PartitionType = HiiGetString (mHandleParsingHiiHandle,
> STRING_TOKEN(STR_PARTINFO_DUMP_TYPE_MBR), NULL);
> +break;
> +  case PARTITION_TYPE_GPT:
> +PartitionType = HiiGetString (mHandleParsingHiiHandle,
> STRING_TOKEN(STR_PARTINFO_DUMP_TYPE_GPT), NULL);
> +break;
> +  default:
> +PartitionType = NULL;
> +break;
> +  }
> +  if (PartitionType == NULL) {
> +return NULL;
> +  }
> +
> +  if (PartitionInfo->System == 1) {
> +EfiSystemPartition = HiiGetString (mHandleParsingHiiHandle,
> + STRING_TOKEN(STR_PARTINFO_DUMP_EFI_SYS_PART), NULL);  } else {
> +EfiSystemPartition = HiiGetString (mHandleParsingHiiHandle,
> + STRING_TOKEN(STR_PARTINFO_DUMP_NOT_EFI_SYS_PART), NULL);  }  if
> + (EfiSystemPartition == NULL) {
> +SHELL_FREE_NON_NULL (PartitionType);
> +return NULL;
> +  }
> +
> +  RetVal = CatSPrint (
> + NULL,
> + L"%s\r\n%s",
> + PartitionType,
> + EfiSystemPartition
> + );
> +
> +  SHELL_FREE_NON_NULL (EfiSystemPartition);
> +  SHELL_FREE_NON_NULL (PartitionType);
> +  return RetVal;
> +}
> +
>  //
>  // Put the information on the NT32 protocol GUIDs here so we are not
> dependant on the Nt32Pkg  // @@ -2147,6 +2228,11 @@ STATIC CONST
> GUID_INFO_BLOCK mGuidStringList[] = {
>{STRING_TOKEN(STR_ADAPTER_INFO),
> ,
> AdapterInformationDumpInformation},
> 
>  //
> +// UEFI 2.7
> +//
> +  {STRING_TOKEN(STR_PARTITION_INFO),,
> PartitionInfoProtocolDumpInformation},
> +
> +//
>  // PI Spec ones
>  //
>{STRING_TOKEN(STR_IDE

Re: [edk2] [PATCH] MdeModulePkg/BdsDxe: Don't delete "BootNext" until booting it

[Ni, Ruiyu]

I didn't change the position of code to cache "BootNext", because:
This could avoid the "BootNext" (set by PlatformBootManagerLib) be consumed in 
*this* boot.

Maybe this time it's more clear.

Thanks/Ray

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, September 28, 2017 2:13 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH] MdeModulePkg/BdsDxe: Don't delete "BootNext" until
> booting it
> 
> The commit log is saying the "BootNext" *DELETED* (before
> PlatformBootManagerLib) may be *LOST* if there is reset during
> PlatformBootManagerLib. I realized it.
> 
> The comment is saying to avoid the "BootNext" "SET" by
> PlatformBootManagerLib. Sorry I am not getting the point.
> 
> Thanks,
> Star
> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, September 28, 2017 2:02 PM
> To: Zeng, Star <star.z...@intel.com>; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>
> Subject: RE: [PATCH] MdeModulePkg/BdsDxe: Don't delete "BootNext" until
> booting it
> 
> This could avoid the "BootNext" set by PlatformBootManagerLib be consumed
> in *this* boot.
> 
> If I add "*" around "this", is it more clear?
> 
> Thanks/Ray
> 
> > -Original Message-
> > From: Zeng, Star
> > Sent: Thursday, September 28, 2017 2:00 PM
> > To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> > Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> > Subject: RE: [PATCH] MdeModulePkg/BdsDxe: Don't delete "BootNext"
> > until booting it
> >
> > I am ok with the code logic change, but a little confused by the new
> > comment. It seems not match with the commit log.
> >
> > " This could avoid the "BootNext" set by PlatformBootManagerLib be
> > consumed in this boot. "
> >
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Thursday, September 28, 2017 1:50 PM
> > To: edk2-devel@lists.01.org
> > Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> > Subject: [PATCH] MdeModulePkg/BdsDxe: Don't delete "BootNext" until
> > booting it
> >
> > Current implementation deletes the "BootNext" before calling any
> > PlatformBootManagerLib APIs, but if system resets in
> > PlatformBootManagerLib APIs, "BootNext" is not consumed but lost.
> >
> > The patch defers the deletion of "BootNext" to before booting it.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Star Zeng <star.z...@intel.com>
> > ---
> >  MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 35
> > ++
> > --
> >  1 file changed, 20 insertions(+), 15 deletions(-)
> >
> > diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> > b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> > index ac5f9088dd..a6fe617b56 100644
> > --- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> > +++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> > @@ -808,7 +808,8 @@ BdsEntry (
> >ASSERT_EFI_ERROR (Status);
> >
> >//
> > -  // Cache and remove the "BootNext" NV variable.
> > +  // Cache the "BootNext" NV variable before calling any
> > + PlatformBootManagerLib APIs  // This could avoid the "BootNext" set
> > + by
> > PlatformBootManagerLib be consumed in this boot.
> >//
> >GetEfiGlobalVariable2 (EFI_BOOT_NEXT_VARIABLE_NAME, (VOID **)
> > , );
> >if (DataSize != sizeof (UINT16)) {
> > @@ -817,17 +818,6 @@ BdsEntry (
> >  }
> >  BootNext = NULL;
> >}
> > -  Status = gRT->SetVariable (
> > -  EFI_BOOT_NEXT_VARIABLE_NAME,
> > -  ,
> > -  0,
> > -  0,
> > -  NULL
> > -  );
> > -  //
> > -  // Deleting NV variable shouldn't fail unless it doesn't exist.
> > -  //
> > -  ASSERT (Status == EFI_SUCCESS || Status == EFI_NOT_FOUND);
> >
> >//
> >// Initialize the platform language variables @@ -1052,10 +1042,25
> > @@ BdsEntry (
> >
> >  EfiBootManagerHotkeyBoot ();
> >
> &g

Re: [edk2] [PATCH] MdeModulePkg/BdsDxe: Don't delete "BootNext" until booting it

[Ni, Ruiyu]

This could avoid the "BootNext" set by PlatformBootManagerLib be consumed in 
*this* boot.

If I add "*" around "this", is it more clear?

Thanks/Ray

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, September 28, 2017 2:00 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH] MdeModulePkg/BdsDxe: Don't delete "BootNext" until
> booting it
> 
> I am ok with the code logic change, but a little confused by the new comment. 
> It
> seems not match with the commit log.
> 
> " This could avoid the "BootNext" set by PlatformBootManagerLib be consumed
> in this boot. "
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, September 28, 2017 1:50 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: [PATCH] MdeModulePkg/BdsDxe: Don't delete "BootNext" until booting
> it
> 
> Current implementation deletes the "BootNext" before calling any
> PlatformBootManagerLib APIs, but if system resets in PlatformBootManagerLib
> APIs, "BootNext" is not consumed but lost.
> 
> The patch defers the deletion of "BootNext" to before booting it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Star Zeng <star.z...@intel.com>
> ---
>  MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 35 ++
> --
>  1 file changed, 20 insertions(+), 15 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> index ac5f9088dd..a6fe617b56 100644
> --- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> +++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> @@ -808,7 +808,8 @@ BdsEntry (
>ASSERT_EFI_ERROR (Status);
> 
>//
> -  // Cache and remove the "BootNext" NV variable.
> +  // Cache the "BootNext" NV variable before calling any
> + PlatformBootManagerLib APIs  // This could avoid the "BootNext" set by
> PlatformBootManagerLib be consumed in this boot.
>//
>GetEfiGlobalVariable2 (EFI_BOOT_NEXT_VARIABLE_NAME, (VOID **)
> , );
>if (DataSize != sizeof (UINT16)) {
> @@ -817,17 +818,6 @@ BdsEntry (
>  }
>  BootNext = NULL;
>}
> -  Status = gRT->SetVariable (
> -  EFI_BOOT_NEXT_VARIABLE_NAME,
> -  ,
> -  0,
> -  0,
> -  NULL
> -  );
> -  //
> -  // Deleting NV variable shouldn't fail unless it doesn't exist.
> -  //
> -  ASSERT (Status == EFI_SUCCESS || Status == EFI_NOT_FOUND);
> 
>//
>// Initialize the platform language variables @@ -1052,10 +1042,25 @@
> BdsEntry (
> 
>  EfiBootManagerHotkeyBoot ();
> 
> -//
> -// Boot to "BootNext"
> -//
>  if (BootNext != NULL) {
> +  //
> +  // Delete "BootNext" NV variable before transferring control to it to
> prevent loops.
> +  //
> +  Status = gRT->SetVariable (
> +  EFI_BOOT_NEXT_VARIABLE_NAME,
> +  ,
> +  0,
> +  0,
> +  NULL
> +  );
> +  //
> +  // Deleting NV variable shouldn't fail unless it doesn't exist.
> +  //
> +  ASSERT (Status == EFI_SUCCESS || Status == EFI_NOT_FOUND);
> +
> +  //
> +  // Boot to "BootNext"
> +  //
>UnicodeSPrint (BootNextVariableName, sizeof (BootNextVariableName),
> L"Boot%04x", *BootNext);
>Status = EfiBootManagerVariableToLoadOption (BootNextVariableName,
> );
>if (!EFI_ERROR (Status)) {
> --
> 2.12.2.windows.2

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

Re: [edk2] [patch] ShellPkg/Dh: Refine variable naming style

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>

Thanks/Ray

> -Original Message-
> From: Bi, Dandan
> Sent: Thursday, September 28, 2017 10:45 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Carsey, Jaben <jaben.car...@intel.com>
> Subject: [patch] ShellPkg/Dh: Refine variable naming style
> 
> Avoid using only lower-case characters for variable name.
> 
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Jaben Carsey <jaben.car...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  ShellPkg/Library/UefiShellDriver1CommandsLib/Dh.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Dh.c
> b/ShellPkg/Library/UefiShellDriver1CommandsLib/Dh.c
> index 7d06163..a7bd251 100644
> --- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Dh.c
> +++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Dh.c
> @@ -284,11 +284,11 @@ GetProtocolInfoString(
>EFI_STATUSStatus;
>CHAR16*RetVal;
>UINTN Size;
>CHAR16*Temp;
>CHAR16GuidStr[40];
> -  VOID  *instance;
> +  VOID  *Instance;
>CHAR16InstanceStr[17];
> 
>ProtocolGuidArray = NULL;
>RetVal= NULL;
>Size  = 0;
> @@ -314,14 +314,14 @@ GetProtocolInfoString(
>  FreePool(Temp);
>}
>StrnCatGrow(, , L"%N", 0);
> 
>if(Verbose) {
> -Status = gBS->HandleProtocol (TheHandle,
> ProtocolGuidArray[ProtocolIndex], );
> +Status = gBS->HandleProtocol (TheHandle,
> ProtocolGuidArray[ProtocolIndex], );
>  if (!EFI_ERROR (Status)) {
>StrnCatGrow (, , L"(%H", 0);
> -  UnicodeSPrint (InstanceStr, sizeof (InstanceStr), L"%x", instance);
> +  UnicodeSPrint (InstanceStr, sizeof (InstanceStr), L"%x", Instance);
>StrnCatGrow (, , InstanceStr, 0);
>StrnCatGrow (, , L"%N)", 0);
>  }
>}
> 
> --
> 1.9.5.msysgit.1

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