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

2017-12-14 Thread 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] MdeModulePkg/DxeIplPeim: fix incorrect page table split during protecting

2017-12-14 Thread Zeng, Star 
Reviewed-by: Star Zeng 

-Original Message-
From: Wang, Jian J 
Sent: Friday, December 15, 2017 10:39 AM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Zeng, Star ; Dong, 
Eric 
Subject: [PATCH] MdeModulePkg/DxeIplPeim: fix incorrect page table split during 
protecting

The root cause of this issue is that, during splitting page table, the page 
size should be the value of next level (smaller one) instead of current level.
The wrong page size will then cause wrong page table introduced, which will 
break the normal boot.

Validation works include booting to Windows 10 and Fedora 26 on real Intel 
platform and OVMF emulated platform in addition to manual checks on page table 
with JTAG tool.

Cc: Ruiyu Ni 
Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index 26116e420c..bbdfa2bb8e 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -472,6 +472,8 @@ SetPageTablePoolReadOnly (
   //
   // The smaller granularity of page must be needed.
   //
+  ASSERT (Level > 1);
+
   NewPageTable = AllocatePageTableMemory (1);
   ASSERT (NewPageTable != NULL);
 
@@ -481,10 +483,10 @@ SetPageTablePoolReadOnly (
 ++EntryIndex) {
 NewPageTable[EntryIndex] = PhysicalAddress  | AddressEncMask |
IA32_PG_P | IA32_PG_RW;
-if (Level > 1) {
+if (Level > 2) {
   NewPageTable[EntryIndex] |= IA32_PG_PS;
 }
-PhysicalAddress += LevelSize[Level];
+PhysicalAddress += LevelSize[Level - 1];
   }
 
   PageTable[Index] = (UINT64)(UINTN)NewPageTable | AddressEncMask |
--
2.14.1.windows.1

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

[edk2] [PATCH] MdeModulePkg/DxeIplPeim: fix incorrect page table split during protecting

2017-12-14 Thread Jian J Wang 
The root cause of this issue is that, during splitting page table, the page
size should be the value of next level (smaller one) instead of current level.
The wrong page size will then cause wrong page table introduced, which will
break the normal boot.

Validation works include booting to Windows 10 and Fedora 26 on real Intel
platform and OVMF emulated platform in addition to manual checks on page
table with JTAG tool.

Cc: Ruiyu Ni 
Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index 26116e420c..bbdfa2bb8e 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -472,6 +472,8 @@ SetPageTablePoolReadOnly (
   //
   // The smaller granularity of page must be needed.
   //
+  ASSERT (Level > 1);
+
   NewPageTable = AllocatePageTableMemory (1);
   ASSERT (NewPageTable != NULL);
 
@@ -481,10 +483,10 @@ SetPageTablePoolReadOnly (
 ++EntryIndex) {
 NewPageTable[EntryIndex] = PhysicalAddress  | AddressEncMask |
IA32_PG_P | IA32_PG_RW;
-if (Level > 1) {
+if (Level > 2) {
   NewPageTable[EntryIndex] |= IA32_PG_PS;
 }
-PhysicalAddress += LevelSize[Level];
+PhysicalAddress += LevelSize[Level - 1];
   }
 
   PageTable[Index] = (UINT64)(UINTN)NewPageTable | AddressEncMask |
-- 
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 1/3] MdePkg: break #defines out of Uefi/UefiMultiPhase.h

2017-12-14 Thread Gao, Liming 
Leif:
  Right. Current VfrCompiler supports the limited C syntax. Many C syntax are 
not recognized. So, you will meet with the below build error. 
  For this change, I agree to share the definition between C and VFR source 
files. The temp solution is to use #ifndef VFRCOMPILE around the definition. 
The long term solution is to enhance VfrCompiler tool to recognize more C 
syntax so that C and VFR can share more definitions. For long term solution, 
you can submit feature request in bugzillia to catch it first.

Thanks
Liming
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Friday, December 15, 2017 1:00 AM
> To: Ni, Ruiyu 
> Cc: edk2-devel@lists.01.org; Kinney, Michael D ; 
> Dong, Eric ; Zeng, Star
> ; Gao, Liming ; Ard Biesheuvel 
> 
> Subject: Re: [edk2] [PATCH 1/3] MdePkg: break #defines out of 
> Uefi/UefiMultiPhase.h
> 
> On Thu, Dec 14, 2017 at 12:03:56PM +, Leif Lindholm wrote:
> > On Thu, Dec 14, 2017 at 10:44:04AM +0800, Ni, Ruiyu wrote:
> > > Can we just move the definitions to UefiBaseTypes.h?
> >
> > There is nothing in UefiBaseTypes.h that is fundamentally easier to
> > deal with than what is in UefiMultiPhase.h to begin with.
> >
> > > Even vfrcompiler still complains, the syntax enhancement to
> > > vfrcompiler should be simple.
> >
> > It's (probably) not VfrCompile that would need to change.
> > The problem is that the build runs the C preprocessor on the .vfr
> > source files before passing them to VfrCompile. #defines that just
> > replace text work fine, but typedefs and struct definitions make no
> > sense in vfr source.
> >
> > It runs the preprocessor in C mode (for gpp, -x c) which means we
> > cannot use __ASSEMBLER__ to filter out typedefs and struct
> > definitions.
> >
> > We could perhaps switch to -x assembler-with-cpp (and filter
> > UefiMultiPhase.h on __ASSEMBLER__), like we do for DTC.
> > It _seems_ to work in my test, but I do not know what a corresponding
> > change for VS would be.
> 
> Well, this turns out to be unworkable anyway, since the affected
> .vfr source files depend on certain typedefs and struct definitions.
> I was under the misconception that only #defines were used in .vfr.
> 
> So, yes, the better solution would be to teach VfrCompile to
> understand enums and other things, but I wouldn't really know where to
> start (and I'm about to disappear for a month).
> 
> Symptoms when building MdeModulePkg DriverSampleDxe with
> UefiMultiPhase.h include
> 
> ERROR 12288: EFI_GUID
> : undefined
> ERROR 12288: enum
> : unexpected token
> 
> If I then add UefiBaseTypes.h, we insted have issues from the
> inclusion of ProcessorBind.h:
> 
> ERROR 12288: unsigned
> : unexpected token
> ERROR 12288: long
> : unexpected token
> 
> and so on.
> 
> An alternative less invasive solution, which would avoid adding new
> files, would be to add #ifndef VFRCOMPILE around everything other
> than the EFI_VARIABLE_* #defines in UefiMultiPhase.h.
> 
> Would you be happier with that as a temporary measure until someone
> gets around to looking at VfrCompile?
> 
> /
> Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg PiSmmCore: Use SxDispatch in SmmEndOfDxeHandler()

2017-12-14 Thread Yao, Jiewen 
Reviewed-by: jiewen@intel.com

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star
> Zeng
> Sent: Friday, December 15, 2017 9:40 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Zeng, Star 
> Subject: [edk2] [PATCH] MdeModulePkg PiSmmCore: Use SxDispatch in
> SmmEndOfDxeHandler()
> 
> As some implementation of SMM Child Dispatcher (including SxDispatch) may
> deny the handler registration after SmmReadyToLock, using SxDispatch in
> SmmReadyToBootHandler() will be too late.
> 
> This patch updates code to use SxDispatch in SmmEndOfDxeHandler() instead of
> SmmReadyToBootHandler().
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.c | 65
> +
>  1 file changed, 33 insertions(+), 32 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> index f136b5d5693b..d2f0207b5c83 100644
> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> @@ -296,9 +296,6 @@ SmmReadyToBootHandler (  {
>EFI_STATUSStatus;
>EFI_HANDLESmmHandle;
> -  EFI_SMM_SX_DISPATCH2_PROTOCOL *SxDispatch;
> -  EFI_SMM_SX_REGISTER_CONTEXT   EntryRegisterContext;
> -  EFI_HANDLES3EntryHandle;
> 
>//
>// Install SMM Ready To Boot protocol.
> @@ -313,31 +310,7 @@ SmmReadyToBootHandler (
> 
>SmiHandlerUnRegister (DispatchHandle);
> 
> -  //
> -  // Locate SmmSxDispatch2 protocol.
> -  //
> -  Status = SmmLocateProtocol (
> - ,
> - NULL,
> - (VOID **)
> - );
> -  if (!EFI_ERROR (Status) && (SxDispatch != NULL)) {
> -//
> -// Register a S3 entry callback function to
> -// determine if it will be during S3 resume.
> -//
> -EntryRegisterContext.Type  = SxS3;
> -EntryRegisterContext.Phase = SxEntry;
> -Status = SxDispatch->Register (
> -   SxDispatch,
> -   SmmS3EntryCallBack,
> -   ,
> -   
> -   );
> -ASSERT_EFI_ERROR (Status);
> -  }
> -
> -  return EFI_SUCCESS;
> +  return Status;
>  }
> 
>  /**
> @@ -452,10 +425,14 @@ SmmEndOfDxeHandler (
>IN OUT UINTN   *CommBufferSize  OPTIONAL
>)
>  {
> -  EFI_STATUS  Status;
> -  EFI_HANDLE  SmmHandle;
> +  EFI_STATUSStatus;
> +  EFI_HANDLESmmHandle;
> +  EFI_SMM_SX_DISPATCH2_PROTOCOL *SxDispatch;
> +  EFI_SMM_SX_REGISTER_CONTEXT   EntryRegisterContext;
> +  EFI_HANDLES3EntryHandle;
> 
>DEBUG ((EFI_D_INFO, "SmmEndOfDxeHandler\n"));
> +
>//
>// Install SMM EndOfDxe protocol
>//
> @@ -466,7 +443,32 @@ SmmEndOfDxeHandler (
>   EFI_NATIVE_INTERFACE,
>   NULL
>   );
> -  return Status;
> +
> +  //
> +  // Locate SmmSxDispatch2 protocol.
> +  //
> +  Status = SmmLocateProtocol (
> + ,
> + NULL,
> + (VOID **)
> + );
> +  if (!EFI_ERROR (Status) && (SxDispatch != NULL)) {
> +//
> +// Register a S3 entry callback function to
> +// determine if it will be during S3 resume.
> +//
> +EntryRegisterContext.Type  = SxS3;
> +EntryRegisterContext.Phase = SxEntry;
> +Status = SxDispatch->Register (
> +   SxDispatch,
> +   SmmS3EntryCallBack,
> +   ,
> +   
> +   );
> +ASSERT_EFI_ERROR (Status);
> +  }
> +
> +  return EFI_SUCCESS;
>  }
> 
>  /**
> @@ -526,7 +528,6 @@ SmmEndOfS3ResumeHandler (
>ASSERT_EFI_ERROR (Status);
> 
>mDuringS3Resume = FALSE;
> -
>return Status;
>  }
> 
> --
> 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] [staging/DynamicTables] What about edk2-platforms.

2017-12-14 Thread Kinney, Michael D 
Evan,

This is a good question.

Another staging repo is possible, but may not be required.

You could add the platform content to edk2-staging and get 
everything working using that content.  When edk2-staging 
is ready for truck, you need to create the patches for
the edk2 and edk2-platforms repos for review and commit.
I think you can use filter-branch to extract the patch
sets for each repo.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Evan Lloyd
> Sent: Thursday, December 14, 2017 10:38 AM
> To: edk2-devel (edk2-devel@lists.01.org)  de...@lists.01.org>; Leif Lindholm
> 
> Cc: Ard Biesheuvel 
> Subject: [edk2] [staging/DynamicTables] What about
> edk2-platforms.
> 
> We are about to submit a new (ACPI 6.2) version of
> Sami's Dynamic Tables module.
> As suggested in previous threads, the aim is to submit
> it to edk2-staging.
> To that end, following the instructions at
> https://github.com/tianocore/edk2-
> staging/blob/about/README
> (paragraph 4 a) "Maintainer sends patch email to edk2-
> devel", we need to generate a patch.
> 
> The problem is that the patch involves modules in both
> edk2 and edk2-platforms.
> What is the best strategy to use for that scenario?
> Is there any plan to have an edk2-platforms-staging?
> If not, we could roll the bits of platforms into edk2-
> staging, but that may engender problems later.
> Does anyone have any advice on how best to handle this,
> please?
> 
> Regards,
> Evan
> IMPORTANT NOTICE: The contents of this email and any
> attachments are confidential and may also be
> privileged. If you are not the intended recipient,
> please notify the sender immediately and do not
> disclose the contents to any other person, use it for
> any purpose, or store or copy the information in any
> medium. Thank you.
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg PiSmmCore: Use SxDispatch in SmmEndOfDxeHandler()

2017-12-14 Thread Star Zeng 
As some implementation of SMM Child Dispatcher (including SxDispatch)
may deny the handler registration after SmmReadyToLock, using
SxDispatch in SmmReadyToBootHandler() will be too late.

This patch updates code to use SxDispatch in SmmEndOfDxeHandler()
instead of SmmReadyToBootHandler().

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c | 65 +
 1 file changed, 33 insertions(+), 32 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
index f136b5d5693b..d2f0207b5c83 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
@@ -296,9 +296,6 @@ SmmReadyToBootHandler (
 {
   EFI_STATUSStatus;
   EFI_HANDLESmmHandle;
-  EFI_SMM_SX_DISPATCH2_PROTOCOL *SxDispatch;
-  EFI_SMM_SX_REGISTER_CONTEXT   EntryRegisterContext;
-  EFI_HANDLES3EntryHandle;
 
   //
   // Install SMM Ready To Boot protocol.
@@ -313,31 +310,7 @@ SmmReadyToBootHandler (
 
   SmiHandlerUnRegister (DispatchHandle);
 
-  //
-  // Locate SmmSxDispatch2 protocol.
-  //
-  Status = SmmLocateProtocol (
- ,
- NULL,
- (VOID **)
- );
-  if (!EFI_ERROR (Status) && (SxDispatch != NULL)) {
-//
-// Register a S3 entry callback function to
-// determine if it will be during S3 resume.
-//
-EntryRegisterContext.Type  = SxS3;
-EntryRegisterContext.Phase = SxEntry;
-Status = SxDispatch->Register (
-   SxDispatch,
-   SmmS3EntryCallBack,
-   ,
-   
-   );
-ASSERT_EFI_ERROR (Status);
-  }
-
-  return EFI_SUCCESS;
+  return Status;
 }
 
 /**
@@ -452,10 +425,14 @@ SmmEndOfDxeHandler (
   IN OUT UINTN   *CommBufferSize  OPTIONAL
   )
 {
-  EFI_STATUS  Status;
-  EFI_HANDLE  SmmHandle;
+  EFI_STATUSStatus;
+  EFI_HANDLESmmHandle;
+  EFI_SMM_SX_DISPATCH2_PROTOCOL *SxDispatch;
+  EFI_SMM_SX_REGISTER_CONTEXT   EntryRegisterContext;
+  EFI_HANDLES3EntryHandle;
 
   DEBUG ((EFI_D_INFO, "SmmEndOfDxeHandler\n"));
+
   //
   // Install SMM EndOfDxe protocol
   //
@@ -466,7 +443,32 @@ SmmEndOfDxeHandler (
  EFI_NATIVE_INTERFACE,
  NULL
  );
-  return Status;
+
+  //
+  // Locate SmmSxDispatch2 protocol.
+  //
+  Status = SmmLocateProtocol (
+ ,
+ NULL,
+ (VOID **)
+ );
+  if (!EFI_ERROR (Status) && (SxDispatch != NULL)) {
+//
+// Register a S3 entry callback function to
+// determine if it will be during S3 resume.
+//
+EntryRegisterContext.Type  = SxS3;
+EntryRegisterContext.Phase = SxEntry;
+Status = SxDispatch->Register (
+   SxDispatch,
+   SmmS3EntryCallBack,
+   ,
+   
+   );
+ASSERT_EFI_ERROR (Status);
+  }
+
+  return EFI_SUCCESS;
 }
 
 /**
@@ -526,7 +528,6 @@ SmmEndOfS3ResumeHandler (
   ASSERT_EFI_ERROR (Status);
 
   mDuringS3Resume = FALSE;
-
   return Status;
 }
 
-- 
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 1/3 V2] MdeModulePkg: Update Api from NetLibDetectMedia to NetLibDetectMediaWaitTimeout.

2017-12-14 Thread Fu, Siyuan 
Reviewed-by: Fu Siyuan 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> fanwang2
> Sent: Thursday, December 14, 2017 5:53 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wang, Fan ; Fu,
> Siyuan ; Wu, Jiaxin 
> Subject: [edk2] [Patch 1/3 V2] MdeModulePkg: Update Api from
> NetLibDetectMedia to NetLibDetectMediaWaitTimeout.
> 
> From: Wang Fan 
> 
> V2:
>*Define time period in a macro instead of hard code.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wang Fan 
> ---
>  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c | 8 
>  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.h | 1 +
>  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDhcp.c | 8 
>  MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.c| 8 
>  MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.h| 3 +++
>  MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c | 8 
>  MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.h | 1 +
>  7 files changed, 21 insertions(+), 16 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
> b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
> index 8780414..aad6674 100644
> --- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
> +++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
> @@ -778,13 +778,13 @@ EfiDhcp4Start (
>IN EFI_EVENT  CompletionEvent   OPTIONAL
>)
>  {
>DHCP_PROTOCOL *Instance;
>DHCP_SERVICE  *DhcpSb;
> -  BOOLEAN   MediaPresent;
>EFI_STATUSStatus;
>EFI_TPL   OldTpl;
> +  EFI_STATUSMediaStatus;
> 
>//
>// First validate the parameters
>//
>if (This == NULL) {
> @@ -811,13 +811,13 @@ EfiDhcp4Start (
>}
> 
>//
>// Check Media Satus.
>//
> -  MediaPresent = TRUE;
> -  NetLibDetectMedia (DhcpSb->Controller, );
> -  if (!MediaPresent) {
> +  MediaStatus = EFI_SUCCESS;
> +  NetLibDetectMediaWaitTimeout (DhcpSb->Controller,
> DHCP_CHECK_MEDIA_WAITING_TIME, );
> +  if (MediaStatus != EFI_SUCCESS) {
>  Status = EFI_NO_MEDIA;
>  goto ON_ERROR;
>}
> 
>DhcpSb->IoStatus = EFI_ALREADY_STARTED;
> diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.h
> b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.h
> index e546a08..2d66afe 100644
> --- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.h
> +++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.h
> @@ -41,10 +41,11 @@ typedef struct _DHCP_PROTOCOL DHCP_PROTOCOL;
>  #include "Dhcp4Io.h"
> 
>  #define DHCP_SERVICE_SIGNATURE   SIGNATURE_32 ('D', 'H', 'C', 'P')
>  #define DHCP_PROTOCOL_SIGNATURE  SIGNATURE_32 ('d', 'h', 'c', 'p')
> 
> +#define DHCP_CHECK_MEDIA_WAITING_TIMEEFI_TIMER_PERIOD_SECONDS(20)
> 
>  //
>  // The state of the DHCP service. It starts as UNCONFIGED. If
>  // and active child configures the service successfully, it
>  // goes to CONFIGED. If the active child configures NULL, it
> diff --git a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiDhcp.c
> b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiDhcp.c
> index 869a56a..976fe5d 100644
> --- a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiDhcp.c
> +++ b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiDhcp.c
> @@ -358,23 +358,23 @@ IScsiDoDhcp (
>EFI_HANDLE  Dhcp4Handle;
>EFI_DHCP4_PROTOCOL  *Dhcp4;
>EFI_STATUS  Status;
>EFI_DHCP4_PACKET_OPTION *ParaList;
>EFI_DHCP4_CONFIG_DATA   Dhcp4ConfigData;
> -  BOOLEAN MediaPresent;
> +  EFI_STATUS  MediaStatus;
>UINT8   *Data;
> 
>Dhcp4Handle = NULL;
>Dhcp4   = NULL;
>ParaList= NULL;
> 
>//
>// Check media status before do DHCP
>//
> -  MediaPresent = TRUE;
> -  NetLibDetectMedia (Controller, );
> -  if (!MediaPresent) {
> +  MediaStatus = EFI_SUCCESS;
> +  NetLibDetectMediaWaitTimeout (Controller,
> ISCSI_CHECK_MEDIA_GET_DHCP_WAITING_TIME, );
> +  if (MediaStatus != EFI_SUCCESS) {
>  return EFI_NO_MEDIA;
>}
> 
>//
>// Create a DHCP4 child instance and get the protocol.
> diff --git a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.c
> b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.c
> index 14f13f8..4317de2 100644
> --- a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.c
> +++ b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.c
> @@ -287,20 +287,20 @@ IScsiSessionLogin (
>  {
>EFI_STATUSStatus;
>ISCSI_SESSION *Session;
>ISCSI_CONNECTION  *Conn;
>EFI_TCP4_PROTOCOL *Tcp4;
> -  BOOLEAN   MediaPresent;
> +  EFI_STATUSMediaStatus;
> 
>

[edk2] [staging/DynamicTables] What about edk2-platforms.

2017-12-14 Thread Evan Lloyd 
We are about to submit a new (ACPI 6.2) version of Sami's Dynamic Tables module.
As suggested in previous threads, the aim is to submit it to edk2-staging.
To that end, following the instructions at 
https://github.com/tianocore/edk2-staging/blob/about/README
(paragraph 4 a) "Maintainer sends patch email to edk2-devel", we need to 
generate a patch.

The problem is that the patch involves modules in both edk2 and edk2-platforms.
What is the best strategy to use for that scenario?
Is there any plan to have an edk2-platforms-staging?
If not, we could roll the bits of platforms into edk2-staging, but that may 
engender problems later.
Does anyone have any advice on how best to handle this, please?

Regards,
Evan
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
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

2017-12-14 Thread Leif Lindholm 
On Thu, Dec 14, 2017 at 12:03:56PM +, Leif Lindholm wrote:
> On Thu, Dec 14, 2017 at 10:44:04AM +0800, Ni, Ruiyu wrote:
> > Can we just move the definitions to UefiBaseTypes.h?
> 
> There is nothing in UefiBaseTypes.h that is fundamentally easier to
> deal with than what is in UefiMultiPhase.h to begin with.
> 
> > Even vfrcompiler still complains, the syntax enhancement to
> > vfrcompiler should be simple.
> 
> It's (probably) not VfrCompile that would need to change.
> The problem is that the build runs the C preprocessor on the .vfr
> source files before passing them to VfrCompile. #defines that just
> replace text work fine, but typedefs and struct definitions make no
> sense in vfr source.
> 
> It runs the preprocessor in C mode (for gpp, -x c) which means we
> cannot use __ASSEMBLER__ to filter out typedefs and struct
> definitions.
> 
> We could perhaps switch to -x assembler-with-cpp (and filter
> UefiMultiPhase.h on __ASSEMBLER__), like we do for DTC.
> It _seems_ to work in my test, but I do not know what a corresponding
> change for VS would be.

Well, this turns out to be unworkable anyway, since the affected
.vfr source files depend on certain typedefs and struct definitions.
I was under the misconception that only #defines were used in .vfr.

So, yes, the better solution would be to teach VfrCompile to
understand enums and other things, but I wouldn't really know where to
start (and I'm about to disappear for a month).

Symptoms when building MdeModulePkg DriverSampleDxe with
UefiMultiPhase.h include

ERROR 12288: EFI_GUID
: undefined
ERROR 12288: enum
: unexpected token

If I then add UefiBaseTypes.h, we insted have issues from the
inclusion of ProcessorBind.h:

ERROR 12288: unsigned
: unexpected token
ERROR 12288: long
: unexpected token

and so on.

An alternative less invasive solution, which would avoid adding new
files, would be to add #ifndef VFRCOMPILE around everything other
than the EFI_VARIABLE_* #defines in UefiMultiPhase.h.

Would you be happier with that as a temporary measure until someone
gets around to looking at VfrCompile?

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

Re: [edk2] Documentation on "dh" shell command

2017-12-14 Thread Carsey, Jaben 
Thanks Andrew.  I had been confused by the "column" on the non-SFO output 
format.

Maybe we should add a better description for the generic output. Like:
 < ProtocolBasicInfo > [*]

Note that some protocols (like DevicePath in the example below) have additional 
dynamic content in their basic info, while most just have protocol name.

-Jaben

From: af...@apple.com [mailto:af...@apple.com]
Sent: Wednesday, December 13, 2017 9:29 PM
To: Udit Kumar 
Cc: Carsey, Jaben ; edk2-devel@lists.01.org
Subject: Re: [edk2] Documentation on "dh" shell command
Importance: High


On Dec 13, 2017, at 9:15 PM, Udit Kumar 
> wrote:

Hi Jaben

Dh says like
14C: IPv4
14D: SimpleFileSystem DiskIO BlockIO DevicePath(..R,0x7D5FDC4F,0x2,0xA001))


The 1st hex number is a handle number, basically a User Interface name for the 
handle. The names after the colon represent protocol instances on the handle.

You can get more info about the protocols by dumping the handle so: dh 14D

Thanks,

Andrew Fish

But documentation is not saying what is column 1, 2 and so on
What I am looking for description of output of dh command with various options

Thanks
Udit


-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Wednesday, December 13, 2017 10:54 PM
To: Udit Kumar >; 
edk2-devel@lists.01.org
Subject: RE: [edk2] Documentation on "dh" shell command

Udit,

There are some examples in the shell spec just before the table you found,
but no exact output requirement for dh. What handle information are you
looking for?  Maybe we can add that to the dynamic help for the command
(the stuff users can see from "dh =?").

-Jaben


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Udit Kumar
Sent: Wednesday, December 13, 2017 4:48 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Documentation on "dh" shell command
Importance: High

Hi,
Could you help me, where I can get documentation on output of dh shell
command.
UEFI_Shell_Spec_2_2.pdf , table 18 is giving details of sfo option
only for each column.

Thanks
Udit
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
ts.01.org%2Fmailman%2Flistinfo%2Fedk2-
devel=02%7C01%7Cudit.kumar%


40nxp.com%7C2626239c4c294e1f4bea08d5424e5da9%7C686ea1d3bc2b4c6fa
92cd99


c5c301635%7C0%7C0%7C636487826719107108=doxsRb2xej47877db0
h0z4uam

1mQh%2BKT2ryBpV4mJv4%3D=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] ArmPkg/ArmSmcPsciResetSystemLib: add support for warm reboot

2017-12-14 Thread Leif Lindholm 
On Fri, Oct 06, 2017 at 09:41:52PM +0100, Ard Biesheuvel wrote:
> PSCI SYSTEM_RESET is specified as a cold reboot, which does not
> preserve the contents of DRAM. In version 1.1, a new reset method
> was introduced that allows a warm reboot to be requested.
> 
> This is especially relevant for capsule update, given that it will
> invoke a warm reboot before processing the capsule, under the
> assumption that the capsule will still be in memory when the PEI
> phase is reentered.
> 
> So wire up the [rather inaccurately named] EnterS3WithImmediateWake()
> entry point that the capsule update runtime uses to the new PSCI 1.1
> warm reboot. Note that many PSCI implementations will not support this
> yet, so fall back to a cold reboot if warm reboot fails.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Well, I meant to refactor the SMC call macros as an improved
foundation for this, but that is clearly not happening before I leave
on sabbatical.

So:
Reviewed-by: Leif Lindholm 

And I'll look into refactoring this if and when I look into that once
I get back.

> ---
> 
> I don't actually need this code for Synquacer, but given that I had
> already wrote it, we may just as well merge it.
> 
>  ArmPkg/Include/IndustryStandard/ArmStdSmc.h| 10 
> +++---
>  ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c | 14 
> --
>  2 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h 
> b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> index 593a3ce729ce..41b086947eaa 100644
> --- a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> +++ b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> @@ -57,10 +57,12 @@
>  #define ARM_SMC_ID_PSCI_MIGRATE_AARCH320x8405
>  #define ARM_SMC_ID_PSCI_SYSTEM_OFF 0x8408
>  #define ARM_SMC_ID_PSCI_SYSTEM_RESET   0x8409
> +#define ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH64  0xc412
> +#define ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH32  0x8412
>  
> -/* The current PSCI version is:  0.2 */
> -#define ARM_SMC_PSCI_VERSION_MAJOR  0
> -#define ARM_SMC_PSCI_VERSION_MINOR  2
> +/* The current PSCI version is:  1.1 */
> +#define ARM_SMC_PSCI_VERSION_MAJOR  1
> +#define ARM_SMC_PSCI_VERSION_MINOR  1
>  #define ARM_SMC_PSCI_VERSION  \
>((ARM_SMC_PSCI_VERSION_MAJOR << 16) | ARM_SMC_PSCI_VERSION_MINOR)
>  
> @@ -93,4 +95,6 @@
>  #define ARM_SMC_ID_PSCI_AFFINITY_INFO_OFF 1
>  #define ARM_SMC_ID_PSCI_AFFINITY_INFO_ON_PENDING  2
>  
> +#define ARM_SMC_ID_PSCI_SYSTEM_RESET2_WARM  0
> +
>  #endif
> diff --git 
> a/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c 
> b/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c
> index d6d26bce5009..ffd726554c0f 100644
> --- a/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c
> +++ b/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c
> @@ -55,7 +55,17 @@ ResetWarm (
>VOID
>)
>  {
> -  // Map a warm reset into a cold reset
> +  ARM_SMC_ARGS ArmSmcArgs;
> +
> +#if defined(MDE_CPU_AARCH64)
> +  ArmSmcArgs.Arg0 = ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH64;
> +#else
> +  ArmSmcArgs.Arg0 = ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH32;
> +#endif
> +  ArmSmcArgs.Arg1 = ARM_SMC_ID_PSCI_SYSTEM_RESET2_WARM;
> +  ArmCallSmc ();
> +
> +  // Fall back to cold reset if unsupported
>ResetCold ();
>  }
>  
> @@ -89,7 +99,7 @@ EnterS3WithImmediateWake (
>VOID
>)
>  {
> -  // Not implemented
> +  ResetWarm ();
>  }
>  
>  /**
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] How to using PcdGetEx to change a PCD.

2017-12-14 Thread Gao, Liming 
PcdGet() is the recommended API to be used. It will be mapped to the matched 
PcdGet usage based on PCD type.

PcdGetEx() is only used when PCD is configured to DynamicEx type. Its first 
parameter is the pointer to the token space guid, the second parameter is the 
token number. The token number can be get by PcdToken() macro. So, the correct 
way is PcdGetEx16(, PcdToken 
(PcdPlatformBootTimeOut));. But PcdPlatformBootTimeOut is not configured to 
DynamicEx PCD in NT32 platform. This style can pass build, but can't work. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
> Fish
> Sent: Thursday, December 14, 2017 6:27 PM
> To: krishnaLee 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] How to using PcdGetEx to change a PCD.
> 
> 
> 
> > On Dec 14, 2017, at 12:59 AM, krishnaLee  wrote:
> >
> > Hello,
> > I am learning and writing a application to change the Nt32pkg-virtual 
> > machine's boot time.follow code is success.
> > but I think if I using PcdGetEx16 function, it will also work well,but 
> > failed when I compile it.
> > I had read some Specs about the difference between PcdGetEx and PcdGet,but 
> > I can't understand,maybe I need some practice,
> > So can anyone modify it to using PcdGetEx to implement the same function in 
> > the application?
> > //source-code--start
> 
> Did you add:
> 
> #include 
> 
> and list gEfiMdePkgTokenSpaceGuid in the [Guids] section of the INF.
> 
> In general it is hard to comment on compiler failures in fragments of code. 
> If you post the actual compiler error it is easier to explain.
> 
> 
> 
> The PCDs are a GUID + token number namespace for config. Since anyone can 
> define a GUID that does not conflict it allows arbitrary
> extension without conflict.
> 
> The Ex form of the API includes the GUID + token number. The non Ex form is a 
> size optimization that uses a build generated token
> space. So generally if everything is built together then you use the non Ex 
> form to save space. If different binaries that got compiled in
> different places need to work together then the Ex form is required.
> 
> Thanks,
> 
> Andrew Fish
> 
> > EFI_STATUS
> > EFIAPI
> > UefiMain (
> > IN EFI_HANDLE ImageHandle,
> > IN EFI_SYSTEM_TABLE *SystemTable
> > )
> > {
> > UINTN buffer=0;
> > UINTN index;
> > buffer=PcdGet16(PcdPlatformBootTimeOut);
> > //buffer=PcdGetEx16(,PcdPlatformBootTimeOut);//compile
> >  failed.
> > Print(L"buffer:%d\n",buffer);
> > PcdSet16(PcdPlatformBootTimeOut,5);
> > ...
> >
> >
> > //source-code-end.
> >
> >
> > attachment is the full source code.
> > edk2-vUDK2017's build command:
> > build -p Nt32Pkg\Nt32Pkg.dsc -m 
> > Nt32Pkg\Application\mytestpcd2\mytestpcd2.inf
> >
> >
> > thank you very much!
> >
> > ___
> > 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 v3 4/6] ArmPkg/Library/CompilerIntrinsicsLib: Enable VS2017/ARM builds

2017-12-14 Thread Ard Biesheuvel 
On 13 December 2017 at 14:56, Pete Batard  wrote:
> Hi Ard. Thanks for reviewing this.
>
> On 2017.12.12 19:59, Ard Biesheuvel wrote:
>>>
>>> +  EXPORT _fltused
>>> +  EXPORT __brkdiv0
>>> +
>>
>>
>> Why are these being exported? Are these part of the CRT ABI?
>
>
> Good point. I exported them because I was encountering undefined symbols for
> those when I started working on adding ARM support. But I now suspect they
> may have come from an export statement from VS headers (which we no longer
> include), as re-test shows that the exports seem to be superfluous.
>
> I will test further to confirm that this is the case, and remove the
> unneeded exports.
>
>>> +__brkdiv0
>>> +udf #249
>>> +
>>
>>
>> This will cause a crash when invoked, in a way that gives very little
>> to go on to figure out what happens.
>
>
> Yes. I mostly copied what ReactOS was doing here, since it should be similar
> to what Microsoft does internally.
>
>> Perhaps branch to a C function
>> here that calls ASSERT() and CpuDeadLoop ?
>
>
> I don't mind giving it a try, if we keep the separate .asm files for MSVC.
>
> On the other hand, if I am to try to reuse existing assembly, as you suggest
> below, then I don't think I want to introduce anything that will differ from
> how divisions by zero are currently handled there. As far as I can tell (for
> RVCT, which is the only assembly that might be suitable for reuse with MSFT)
> the current way of handling a zero divisor is to set result and remainder to
> 0 and return (as per uldiv.asm). For gcc, we also have the following comment
> in div.S:
>
>   "@ What to do about division by zero?  For now, just return."
>
> So, while I agree that calling ASSERT and CpuDeadLoop is probably the better
> approach, I'd rather have the introduction of this behaviour be the subject
> of a separate ARM harmonization patch, that applies to all the toolchains,
> rather than something that's specific to Visual Studio usage.
>

I agree. Reusing code is more important than having one flavour of
division that will spot div-by-0. But we really don't want the UDF,
because it will crash unconditionally without a hint of what happened.

>> There are many different division implementations already in the same
>> directory. Do we really need a new one?
>
>
> I'll look into that. My goal with this series was to make sure that the
> changes being introduced would not break existing toolchains, which is why I
> saw it preferable to keep the MSVC intrinsics separate.
>
> Now, gcc assembly is not something that can be reused easily with the MS
> toolchain, so the only possibility are the RVCT .asm files.
>
> There's a fair bit of work involved into trying to figure out if and how we
> can reuse that code, but I'll see what I can do. It'll probably be a few
> weeks before I get back to this list on that however.
>

I'm prepared to be pragmatic here. I would prefer to have all
platforms run the same low level division code, but I understand that
it is tightly coupled to the compiler, given that they are intrinsics.

So yes, please try to reuse the RVCT code if feasible without a ton of
rework, but it seems like we will need to live with some MSFT specific
hooks anyway (if I understand the prototypes correctly)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] OvmfPkg/VirtioScsiDxe: Allocate all required vrings at VirtioScsiInit

2017-12-14 Thread zhengxiang (A) 


On 2017/12/14 17:06, Paolo Bonzini wrote:
> On 14/12/2017 07:55, zhengxiang (A) wrote:
>> Hello Laszlo and Paolo,
>>
>> Thanks for your review!
>>
>> On 2017/12/13 19:16, Laszlo Ersek wrote:
>>> On 12/13/17 10:29, Paolo Bonzini wrote:
 On 13/12/2017 09:35, Laszlo Ersek wrote:
> Perhaps you can update vhost-scsi similarly to the last patch of
> Maxime's v4 series, even without "VIRTIO_SCSI_F_MQ" -- in the
> SET_FEATURES request handler, just destroy the unused virtqueues that
> have not been configured by the guest driver until that time?
 Yes, this is the right solution.  We can assume that if the descriptor
 address is equal to zero, the queue is not in use.  This is not in the
 spec as far as I can see, but it is QEMU's assumption.  I will send a
 patch to the virtio specification.
>>
>> I would try this solution! However, is there any possibility that the 
>> allocated
>> descriptor address is exactly equal to zero and the queue is in use?
> 
> That would break QEMU's virtio implementation, so it's pretty unlikely.
> 
> Paolo
> 

So could I judge the not-in-use queues by adding the below sentence in order
to skip calling vhost_virtqueue_start?

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index e4290ce..05c3322 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -1532,6 +1532,7 @@ int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice 
*vdev)
 goto fail_mem;
 }
 for (i = 0; i < hdev->nvqs; ++i) {
+if (virtio_queue_get_desc_addr(vdev, i) == 0) continue;
 r = vhost_virtqueue_start(hdev,
   vdev,
   hdev->vqs + i,


Thanks,
Xiang

___
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

2017-12-14 Thread Leif Lindholm 
On Thu, Dec 14, 2017 at 10:44:04AM +0800, Ni, Ruiyu wrote:
> 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?

There is nothing in UefiBaseTypes.h that is fundamentally easier to
deal with than what is in UefiMultiPhase.h to begin with.

> Even vfrcompiler still complains, the syntax

Re: [edk2] How to using PcdGetEx to change a PCD.

2017-12-14 Thread Andrew Fish 


> On Dec 14, 2017, at 12:59 AM, krishnaLee  wrote:
> 
> Hello,
> I am learning and writing a application to change the Nt32pkg-virtual 
> machine's boot time.follow code is success.
> but I think if I using PcdGetEx16 function, it will also work well,but failed 
> when I compile it.
> I had read some Specs about the difference between PcdGetEx and PcdGet,but I 
> can't understand,maybe I need some practice,
> So can anyone modify it to using PcdGetEx to implement the same function in 
> the application?
> //source-code--start

Did you add:

#include 

and list gEfiMdePkgTokenSpaceGuid in the [Guids] section of the INF. 

In general it is hard to comment on compiler failures in fragments of code. If 
you post the actual compiler error it is easier to explain. 



The PCDs are a GUID + token number namespace for config. Since anyone can 
define a GUID that does not conflict it allows arbitrary extension without 
conflict. 

The Ex form of the API includes the GUID + token number. The non Ex form is a 
size optimization that uses a build generated token space. So generally if 
everything is built together then you use the non Ex form to save space. If 
different binaries that got compiled in different places need to work together 
then the Ex form is required. 

Thanks,

Andrew Fish

> EFI_STATUS
> EFIAPI
> UefiMain (
> IN EFI_HANDLE ImageHandle,
> IN EFI_SYSTEM_TABLE *SystemTable
> )
> {
> UINTN buffer=0;
> UINTN index;
> buffer=PcdGet16(PcdPlatformBootTimeOut);
> //buffer=PcdGetEx16(,PcdPlatformBootTimeOut);//compile
>  failed.
> Print(L"buffer:%d\n",buffer);
> PcdSet16(PcdPlatformBootTimeOut,5);
> ...
> 
> 
> //source-code-end.
> 
> 
> attachment is the full source code.
> edk2-vUDK2017's build command:
> build -p Nt32Pkg\Nt32Pkg.dsc -m Nt32Pkg\Application\mytestpcd2\mytestpcd2.inf
> 
> 
> thank you very much!
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org 
> https://lists.01.org/mailman/listinfo/edk2-devel 
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 0/3 V2] Update Api from NetLibDetectMedia to NetLibDetectMediaWaitTimeout.

2017-12-14 Thread fanwang2 
From: Wang Fan 

V2: *Define time period in a macro instead of hard code.

Wang Fan (3):
  MdeModulePkg: Update Api from NetLibDetectMedia to
NetLibDetectMediaWaitTimeout.
  NetworkPkg: Update Api from NetLibDetectMedia to
NetLibDetectMediaWaitTimeout.
  ShellPkg: Update Api from NetLibDetectMedia to
NetLibDetectMediaWaitTimeout.

 MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c  |  8 
 MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.h  |  1 +
 MdeModulePkg/Universal/Network/IScsiDxe/IScsiDhcp.c  |  8 
 MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.c |  8 
 MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.h |  3 +++
 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c  |  8 
 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.h  |  1 +
 NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c  |  8 
 NetworkPkg/Dhcp6Dxe/Dhcp6Impl.h  |  2 ++
 NetworkPkg/DnsDxe/DnsDhcp.c  | 16 
 NetworkPkg/DnsDxe/DnsDhcp.h  |  2 ++
 NetworkPkg/HttpBootDxe/HttpBootImpl.c|  8 
 NetworkPkg/HttpBootDxe/HttpBootImpl.h|  2 ++
 NetworkPkg/IScsiDxe/IScsiDhcp.c  |  9 +
 NetworkPkg/IScsiDxe/IScsiDhcp6.c |  9 +
 NetworkPkg/IScsiDxe/IScsiProto.c |  8 
 NetworkPkg/IScsiDxe/IScsiProto.h |  3 +++
 NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c  |  8 
 NetworkPkg/UefiPxeBcDxe/PxeBcImpl.h  |  2 ++
 ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c |  8 
 ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c |  8 
 ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c|  8 
 22 files changed, 78 insertions(+), 60 deletions(-)

-- 
1.9.5.msysgit.1

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

[edk2] [Patch 1/3 V2] MdeModulePkg: Update Api from NetLibDetectMedia to NetLibDetectMediaWaitTimeout.

2017-12-14 Thread fanwang2 
From: Wang Fan 

V2:
   *Define time period in a macro instead of hard code.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wang Fan 
---
 MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c | 8 
 MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.h | 1 +
 MdeModulePkg/Universal/Network/IScsiDxe/IScsiDhcp.c | 8 
 MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.c| 8 
 MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.h| 3 +++
 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c | 8 
 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.h | 1 +
 7 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c 
b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
index 8780414..aad6674 100644
--- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
+++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
@@ -778,13 +778,13 @@ EfiDhcp4Start (
   IN EFI_EVENT  CompletionEvent   OPTIONAL
   )
 {
   DHCP_PROTOCOL *Instance;
   DHCP_SERVICE  *DhcpSb;
-  BOOLEAN   MediaPresent;
   EFI_STATUSStatus;
   EFI_TPL   OldTpl;
+  EFI_STATUSMediaStatus;
 
   //
   // First validate the parameters
   //
   if (This == NULL) {
@@ -811,13 +811,13 @@ EfiDhcp4Start (
   }
 
   //
   // Check Media Satus.
   //
-  MediaPresent = TRUE;
-  NetLibDetectMedia (DhcpSb->Controller, );
-  if (!MediaPresent) {
+  MediaStatus = EFI_SUCCESS;
+  NetLibDetectMediaWaitTimeout (DhcpSb->Controller, 
DHCP_CHECK_MEDIA_WAITING_TIME, );
+  if (MediaStatus != EFI_SUCCESS) {
 Status = EFI_NO_MEDIA;
 goto ON_ERROR;
   }
 
   DhcpSb->IoStatus = EFI_ALREADY_STARTED;
diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.h 
b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.h
index e546a08..2d66afe 100644
--- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.h
+++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.h
@@ -41,10 +41,11 @@ typedef struct _DHCP_PROTOCOL DHCP_PROTOCOL;
 #include "Dhcp4Io.h"
 
 #define DHCP_SERVICE_SIGNATURE   SIGNATURE_32 ('D', 'H', 'C', 'P')
 #define DHCP_PROTOCOL_SIGNATURE  SIGNATURE_32 ('d', 'h', 'c', 'p')
 
+#define DHCP_CHECK_MEDIA_WAITING_TIMEEFI_TIMER_PERIOD_SECONDS(20)
 
 //
 // The state of the DHCP service. It starts as UNCONFIGED. If
 // and active child configures the service successfully, it
 // goes to CONFIGED. If the active child configures NULL, it
diff --git a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiDhcp.c 
b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiDhcp.c
index 869a56a..976fe5d 100644
--- a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiDhcp.c
+++ b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiDhcp.c
@@ -358,23 +358,23 @@ IScsiDoDhcp (
   EFI_HANDLE  Dhcp4Handle;
   EFI_DHCP4_PROTOCOL  *Dhcp4;
   EFI_STATUS  Status;
   EFI_DHCP4_PACKET_OPTION *ParaList;
   EFI_DHCP4_CONFIG_DATA   Dhcp4ConfigData;
-  BOOLEAN MediaPresent;
+  EFI_STATUS  MediaStatus;
   UINT8   *Data;
 
   Dhcp4Handle = NULL;
   Dhcp4   = NULL;
   ParaList= NULL;
 
   //
   // Check media status before do DHCP
   //
-  MediaPresent = TRUE;
-  NetLibDetectMedia (Controller, );
-  if (!MediaPresent) {
+  MediaStatus = EFI_SUCCESS;
+  NetLibDetectMediaWaitTimeout (Controller, 
ISCSI_CHECK_MEDIA_GET_DHCP_WAITING_TIME, );
+  if (MediaStatus != EFI_SUCCESS) {
 return EFI_NO_MEDIA;
   }
 
   //
   // Create a DHCP4 child instance and get the protocol.
diff --git a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.c 
b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.c
index 14f13f8..4317de2 100644
--- a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.c
+++ b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.c
@@ -287,20 +287,20 @@ IScsiSessionLogin (
 {
   EFI_STATUSStatus;
   ISCSI_SESSION *Session;
   ISCSI_CONNECTION  *Conn;
   EFI_TCP4_PROTOCOL *Tcp4;
-  BOOLEAN   MediaPresent;
+  EFI_STATUSMediaStatus;
 
   Session = >Session;
 
   //
   // Check media status before session login
   //
-  MediaPresent = TRUE;
-  NetLibDetectMedia (Private->Controller, );
-  if (!MediaPresent) {
+  MediaStatus = EFI_SUCCESS;
+  NetLibDetectMediaWaitTimeout (Private->Controller, 
ISCSI_CHECK_MEDIA_LOGIN_WAITING_TIME, );
+  if (MediaStatus != EFI_SUCCESS) {
 return EFI_NO_MEDIA;
   }
 
   //
   // Set session identifier
diff --git a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.h 
b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.h
index 48b4e72..2f95323 100644
--- a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.h
+++ b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiProto.h
@@ -40,10 +40,13 @@ WITHOUT WARRANTIES OR

[edk2] [Patch 2/3 V2] NetworkPkg: Update Api from NetLibDetectMedia to NetLibDetectMediaWaitTimeout.

2017-12-14 Thread fanwang2 
From: Wang Fan 

V2:
   *Define time period in a macro instead of hard code.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wang Fan 
---
 NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c   |  8 
 NetworkPkg/Dhcp6Dxe/Dhcp6Impl.h   |  2 ++
 NetworkPkg/DnsDxe/DnsDhcp.c   | 16 
 NetworkPkg/DnsDxe/DnsDhcp.h   |  2 ++
 NetworkPkg/HttpBootDxe/HttpBootImpl.c |  8 
 NetworkPkg/HttpBootDxe/HttpBootImpl.h |  2 ++
 NetworkPkg/IScsiDxe/IScsiDhcp.c   |  9 +
 NetworkPkg/IScsiDxe/IScsiDhcp6.c  |  9 +
 NetworkPkg/IScsiDxe/IScsiProto.c  |  8 
 NetworkPkg/IScsiDxe/IScsiProto.h  |  3 +++
 NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c   |  8 
 NetworkPkg/UefiPxeBcDxe/PxeBcImpl.h   |  2 ++
 12 files changed, 45 insertions(+), 32 deletions(-)

diff --git a/NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c b/NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c
index 1107865..b479421 100644
--- a/NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c
+++ b/NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c
@@ -74,11 +74,11 @@ EfiDhcp6Start (
 {
   EFI_STATUS   Status;
   EFI_TPL  OldTpl;
   DHCP6_INSTANCE   *Instance;
   DHCP6_SERVICE*Service;
-  BOOLEAN  MediaPresent;
+  EFI_STATUS   MediaStatus;
 
   if (This == NULL) {
 return EFI_INVALID_PARAMETER;
   }
 
@@ -104,13 +104,13 @@ EfiDhcp6Start (
   OldTpl   = gBS->RaiseTPL (TPL_CALLBACK);
 
   //
   // Check Media Satus.
   //
-  MediaPresent = TRUE;
-  NetLibDetectMedia (Service->Controller, );
-  if (!MediaPresent) {
+  MediaStatus = EFI_SUCCESS;
+  NetLibDetectMediaWaitTimeout (Service->Controller, 
DHCP_CHECK_MEDIA_WAITING_TIME, );
+  if (MediaStatus != EFI_SUCCESS) {
 Status = EFI_NO_MEDIA;
 goto ON_ERROR;
   }
 
   Instance->UdpSts = EFI_ALREADY_STARTED;
diff --git a/NetworkPkg/Dhcp6Dxe/Dhcp6Impl.h b/NetworkPkg/Dhcp6Dxe/Dhcp6Impl.h
index 06780b6..7110bf8 100644
--- a/NetworkPkg/Dhcp6Dxe/Dhcp6Impl.h
+++ b/NetworkPkg/Dhcp6Dxe/Dhcp6Impl.h
@@ -60,10 +60,12 @@ typedef struct _DHCP6_INSTANCE DHCP6_INSTANCE;
 #define DHCP6_BASE_PACKET_SIZE1024
 
 #define DHCP6_PORT_CLIENT 546
 #define DHCP6_PORT_SERVER 547
 
+#define DHCP_CHECK_MEDIA_WAITING_TIMEEFI_TIMER_PERIOD_SECONDS(20)
+
 #define DHCP6_INSTANCE_FROM_THIS(Instance) CR ((Instance), DHCP6_INSTANCE, 
Dhcp6, DHCP6_INSTANCE_SIGNATURE)
 #define DHCP6_SERVICE_FROM_THIS(Service)   CR ((Service), DHCP6_SERVICE, 
ServiceBinding, DHCP6_SERVICE_SIGNATURE)
 
 extern EFI_IPv6_ADDRESS   mAllDhcpRelayAndServersAddress;
 extern EFI_IPv6_ADDRESS   mAllDhcpServersAddress;
diff --git a/NetworkPkg/DnsDxe/DnsDhcp.c b/NetworkPkg/DnsDxe/DnsDhcp.c
index 93779be..951477b 100644
--- a/NetworkPkg/DnsDxe/DnsDhcp.c
+++ b/NetworkPkg/DnsDxe/DnsDhcp.c
@@ -267,11 +267,11 @@ GetDns4ServerFromDhcp4 (
   )
 {
   EFI_STATUS  Status;
   EFI_HANDLE  Image;
   EFI_HANDLE  Controller;
-  BOOLEAN MediaPresent;
+  EFI_STATUS  MediaStatus;
   EFI_HANDLE  MnpChildHandle;  
   EFI_MANAGED_NETWORK_PROTOCOL*Mnp;
   EFI_MANAGED_NETWORK_CONFIG_DATA MnpConfigData;
   EFI_HANDLE  Dhcp4Handle;  
   EFI_DHCP4_PROTOCOL  *Dhcp4;
@@ -314,13 +314,13 @@ GetDns4ServerFromDhcp4 (
   IsDone = FALSE;
 
   //
   // Check media.
   //
-  MediaPresent = TRUE;
-  NetLibDetectMedia (Controller, );
-  if (!MediaPresent) {
+  MediaStatus = EFI_SUCCESS;
+  NetLibDetectMediaWaitTimeout (Controller, 
DNS_CHECK_MEDIA_GET_DHCP_WAITING_TIME, );
+  if (MediaStatus != EFI_SUCCESS) {
 return EFI_NO_MEDIA;
   }
 
   //
   // Create a Mnp child instance, get the protocol and config for it.
@@ -618,11 +618,11 @@ GetDns6ServerFromDhcp6 (
   EFI_STATUSStatus;
   EFI_STATUSTimerStatus;
   EFI_DHCP6_PACKET_OPTION   *Oro;
   EFI_DHCP6_RETRANSMISSION  InfoReqReXmit;
   EFI_EVENT Timer;
-  BOOLEAN   MediaPresent;
+  EFI_STATUSMediaStatus;
   DNS6_SERVER_INFOR DnsServerInfor;
 
   Dhcp6Handle = NULL;
   Dhcp6   = NULL;
   Oro = NULL;
@@ -633,13 +633,13 @@ GetDns6ServerFromDhcp6 (
   DnsServerInfor.ServerCount = DnsServerCount;
 
   //
   // Check media status before doing DHCP.
   //
-  MediaPresent = TRUE;
-  NetLibDetectMedia (Controller, );
-  if (!MediaPresent) {
+  MediaStatus = EFI_SUCCESS;
+  NetLibDetectMediaWaitTimeout (Controller, 
DNS_CHECK_MEDIA_GET_DHCP_WAITING_TIME, );
+  if (MediaStatus != EFI_SUCCESS) {
 return EFI_NO_MEDIA;
   }
 
   //
   // Create a DHCP6 child instance and get the protocol.
diff --git a/NetworkPkg/DnsDxe/DnsDhcp.h b/NetworkPkg/DnsDxe/DnsDhcp.h
index

[edk2] [Patch 3/3 V2] ShellPkg: Update Api from NetLibDetectMedia to NetLibDetectMediaWaitTimeout.

2017-12-14 Thread fanwang2 
From: Wang Fan 

V2:
   *Define time period in a macro instead of hard code.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wang Fan 
---
 ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c | 8 
 ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c | 8 
 ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c| 8 
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c 
b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
index 082ab72..ab6ab8b 100644
--- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
+++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
@@ -548,15 +548,15 @@ IfConfigShowInterfaceInfo (
   )
 {
   LIST_ENTRY   *Entry;
   LIST_ENTRY   *Next;
   IFCONFIG_INTERFACE_CB*IfCb;
-  BOOLEAN   MediaPresent;
+  EFI_STATUSMediaStatus;
   EFI_IPv4_ADDRESS  Gateway;
   UINT32Index;
   
-  MediaPresent = TRUE;
+  MediaStatus = EFI_SUCCESS;
 
   if (IsListEmpty (IfList)) {
 ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
(STR_IFCONFIG_INVALID_INTERFACE), gShellNetwork1HiiHandle);
   }
 
@@ -574,12 +574,12 @@ IfConfigShowInterfaceInfo (
 ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_IFCONFIG_INFO_IF_NAME), 
gShellNetwork1HiiHandle, IfCb->IfInfo->Name); 
 
 //
 // Get Media State.
 //
-if (EFI_SUCCESS == NetLibDetectMedia (IfCb->NicHandle, )) {
-  if (!MediaPresent) {
+if (EFI_SUCCESS == NetLibDetectMediaWaitTimeout (IfCb->NicHandle, 0, 
)) {
+  if (MediaStatus != EFI_SUCCESS) {
 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 {
diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c 
b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
index 10d291c..bec9535 100644
--- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
+++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
@@ -964,11 +964,11 @@ PingCreateIpInstance (
   EFI_STATUS   Status;
   UINTNHandleIndex;
   UINTNHandleNum;
   EFI_HANDLE   *HandleBuffer;
   BOOLEAN  UnspecifiedSrc;
-  BOOLEAN  MediaPresent;
+  EFI_STATUS   MediaStatus;
   EFI_SERVICE_BINDING_PROTOCOL *EfiSb;
   VOID *IpXCfg;
   EFI_IP6_CONFIG_DATA  Ip6Config;
   EFI_IP4_CONFIG_DATA  Ip4Config;
   VOID *IpXInterfaceInfo;
@@ -976,11 +976,11 @@ PingCreateIpInstance (
   EFI_IPv6_ADDRESS *Addr;
   UINTNAddrIndex;
 
   HandleBuffer  = NULL;
   UnspecifiedSrc= FALSE;
-  MediaPresent  = TRUE;
+  MediaStatus   = EFI_SUCCESS;
   EfiSb = NULL;
   IpXInterfaceInfo  = NULL;
   IfInfoSize= 0;
 
   //
@@ -1033,12 +1033,12 @@ PingCreateIpInstance (
 
 if (UnspecifiedSrc) {
   //
   // Check media.
   //
-  NetLibDetectMedia (HandleBuffer[HandleIndex], );
-  if (!MediaPresent) {
+  NetLibDetectMediaWaitTimeout (HandleBuffer[HandleIndex], 0, 
);
+  if (MediaStatus != EFI_SUCCESS) {
 //
 // Skip this one.
 //
 continue;
   }
diff --git a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c 
b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
index b784696..fa27c82 100644
--- a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
+++ b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
@@ -753,22 +753,22 @@ Ping6CreateIpInstance (
   EFI_STATUS   Status;
   UINTNHandleIndex;
   UINTNHandleNum;
   EFI_HANDLE   *HandleBuffer;
   BOOLEAN  UnspecifiedSrc;
-  BOOLEAN  MediaPresent;
+  EFI_STATUS   MediaStatus;
   EFI_SERVICE_BINDING_PROTOCOL *Ip6Sb;
   EFI_IP6_CONFIG_PROTOCOL  *Ip6Cfg;
   EFI_IP6_CONFIG_DATA  Ip6Config;
   EFI_IP6_CONFIG_INTERFACE_INFO*IfInfo;
   UINTNIfInfoSize;
   EFI_IPv6_ADDRESS *Addr;
   UINTNAddrIndex;
 
   HandleBuffer  = NULL;
   UnspecifiedSrc= FALSE;
-  MediaPresent  = TRUE;
+  MediaStatus   = EFI_SUCCESS
   Ip6Sb = NULL;
   IfInfo= NULL;
   IfInfoSize= 0;
 
   //

Re: [edk2] [PATCH] OvmfPkg/VirtioScsiDxe: Allocate all required vrings at VirtioScsiInit

2017-12-14 Thread Paolo Bonzini 
On 14/12/2017 07:55, zhengxiang (A) wrote:
> Hello Laszlo and Paolo,
> 
> Thanks for your review!
> 
> On 2017/12/13 19:16, Laszlo Ersek wrote:
>> On 12/13/17 10:29, Paolo Bonzini wrote:
>>> On 13/12/2017 09:35, Laszlo Ersek wrote:
 Perhaps you can update vhost-scsi similarly to the last patch of
 Maxime's v4 series, even without "VIRTIO_SCSI_F_MQ" -- in the
 SET_FEATURES request handler, just destroy the unused virtqueues that
 have not been configured by the guest driver until that time?
>>> Yes, this is the right solution.  We can assume that if the descriptor
>>> address is equal to zero, the queue is not in use.  This is not in the
>>> spec as far as I can see, but it is QEMU's assumption.  I will send a
>>> patch to the virtio specification.
> 
> I would try this solution! However, is there any possibility that the 
> allocated
> descriptor address is exactly equal to zero and the queue is in use?

That would break QEMU's virtio implementation, so it's pretty unlikely.

Paolo

> Moreover, is it feasible to skip the vhost_virtqueue_start() call for the 
> unused
> queues in vhost_dev_start() in QEMU?
> 
> 
> 
> Thanks,
> Xiang
> 
> 

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

[edk2] How to using PcdGetEx to change a PCD.

2017-12-14 Thread krishnaLee 
Hello,
I am learning and writing a application to change the Nt32pkg-virtual machine's 
boot time.follow code is success.
but I think if I using PcdGetEx16 function, it will also work well,but failed 
when I compile it.
I had read some Specs about the difference between PcdGetEx and PcdGet,but I 
can't understand,maybe I need some practice,
So can anyone modify it to using PcdGetEx to implement the same function in the 
application?
//source-code--start
EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
UINTN buffer=0;
UINTN index;
buffer=PcdGet16(PcdPlatformBootTimeOut);
//buffer=PcdGetEx16(,PcdPlatformBootTimeOut);//compile 
failed.
Print(L"buffer:%d\n",buffer);
PcdSet16(PcdPlatformBootTimeOut,5);
...


//source-code-end.


attachment is the full source code.
edk2-vUDK2017's build command:
build -p Nt32Pkg\Nt32Pkg.dsc -m Nt32Pkg\Application\mytestpcd2\mytestpcd2.inf


thank you very much!

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

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

2017-12-14 Thread Song, BinX 
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)
 
 #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;
   }
-- 
2.10.2.windows.1

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