Re: [edk2] [PATCH 3/3] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

[Zeng, Star]

Leo,

The RestoreS3PageTables() in S3Resume.c may only build 4G page table when 
Build4GPageTableOnly is TRUE.
The page fault handler PageFaultHandler() in 
MdeModulePkg\Universal\Acpi\BootScriptExecutorDxe\X64\SetIdtEntry.c is to 
co-work with it.
Since BootScriptExecutorDxe is a standalone module, PcdGet64  
(PcdPteMemoryEncryptionAddressOrMask) could not be used in PageFaultHandler() 
as PcdPteMemoryEncryptionAddressOrMask may be configured to DYNAMIC type.
You can use similar logic with "mPage1GSupport for PcdUse1GPageTable" to use a 
global variable and cache the PcdPteMemoryEncryptionAddressOrMask PCD value at 
normal boot phase, and then the global variable can be used in 
PageFaultHandler() at S3 boot phase.

Thanks,
Star
-Original Message-
From: Leo Duran [mailto:leo.du...@amd.com] 
Sent: Thursday, February 9, 2017 5:13 AM
To: edk2-de...@ml01.01.org
Cc: Leo Duran ; Fan, Jeff ; Tian, Feng 
; Zeng, Star ; Laszlo Ersek 
; Brijesh Singh 
Subject: [PATCH 3/3] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add support for 
PCD PcdPteMemoryEncryptionAddressOrMask

This PCD holds the address mask for page table entries when memory encryption 
is enabled on AMD processors supporting the Secure Encrypted Virtualization 
(SEV) feature.

The mask is applied when page tables are created (S3Resume.c).

CC: Jeff Fan 
Cc: Feng Tian 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh 
Signed-off-by: Leo Duran 
---
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c   | 9 +
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf | 2 ++
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index d306fba..ee1e2cd 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
@@ -5,6 +5,7 @@
   control is passed to OS waking up handler.
 
   Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2017, AMD Incorporated. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions @@ -696,7 
+697,7 @@ RestoreS3PageTables (
   //
   // Make a PML4 Entry
   //
-  PageMapLevel4Entry->Uint64 = (UINT64)(UINTN)PageDirectoryPointerEntry;
+  PageMapLevel4Entry->Uint64 = 
+ (UINT64)(UINTN)PageDirectoryPointerEntry | PcdGet64 
+ (PcdPteMemoryEncryptionAddressOrMask);
   PageMapLevel4Entry->Bits.ReadWrite = 1;
   PageMapLevel4Entry->Bits.Present = 1;
 
@@ -707,7 +708,7 @@ RestoreS3PageTables (
   //
   // Fill in the Page Directory entries
   //
-  PageDirectory1GEntry->Uint64 = (UINT64)PageAddress;
+  PageDirectory1GEntry->Uint64 = (UINT64)PageAddress | PcdGet64 
+ (PcdPteMemoryEncryptionAddressOrMask);
   PageDirectory1GEntry->Bits.ReadWrite = 1;
   PageDirectory1GEntry->Bits.Present = 1;
   PageDirectory1GEntry->Bits.MustBe1 = 1; @@ -724,7 +725,7 @@ 
RestoreS3PageTables (
   //
   // Fill in a Page Directory Pointer Entries
   //
-  PageDirectoryPointerEntry->Uint64 = 
(UINT64)(UINTN)PageDirectoryEntry;
+  PageDirectoryPointerEntry->Uint64 = 
+ (UINT64)(UINTN)PageDirectoryEntry | PcdGet64 
+ (PcdPteMemoryEncryptionAddressOrMask);
   PageDirectoryPointerEntry->Bits.ReadWrite = 1;
   PageDirectoryPointerEntry->Bits.Present = 1;
 
@@ -732,7 +733,7 @@ RestoreS3PageTables (
 //
 // Fill in the Page Directory entries
 //
-PageDirectoryEntry->Uint64 = (UINT64)PageAddress;
+PageDirectoryEntry->Uint64 = (UINT64)PageAddress | PcdGet64 
+ (PcdPteMemoryEncryptionAddressOrMask);
 PageDirectoryEntry->Bits.ReadWrite = 1;
 PageDirectoryEntry->Bits.Present = 1;
 PageDirectoryEntry->Bits.MustBe1 = 1; diff --git 
a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
index 73aeca3..d514523 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
@@ -6,6 +6,7 @@
 # control is passed to OS waking up handler.
 #
 # Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2017, AMD Incorporated. All rights reserved.
 #
 # This program and the accompanying materials are  # licensed and made 
available under the terms and conditions of the BSD License @@ -91,6 +92,7 @@ 
[FeaturePcd]
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable  ## 

[edk2] [PATCH] MdePkg ACPI: Incorrect definition name for ACPI IORT Table signature

[Star Zeng]

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

The definition name for ACPI IO Remapping Table signature is incorrect
in Acpi60.h and Acpi61.h as below:

The name should be changed to
EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE
EFI_ACPI_6_1_IO_REMAPPING_TABLE_SIGNATURE

The comments
///
/// "IORT" Interrupt Source Override
///
will be also changed to
///
/// "IORT" I/O Remapping Table
///

Cc: Alexei Fedorov 
Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdePkg/Include/IndustryStandard/Acpi60.h | 6 +++---
 MdePkg/Include/IndustryStandard/Acpi61.h | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi60.h 
b/MdePkg/Include/IndustryStandard/Acpi60.h
index ab798e9cf4c1..6183d8a9bd6c 100644
--- a/MdePkg/Include/IndustryStandard/Acpi60.h
+++ b/MdePkg/Include/IndustryStandard/Acpi60.h
@@ -1,7 +1,7 @@
 /** @file   
   ACPI 6.0 definitions from the ACPI Specification Revision 6.0 Errata A 
January, 2016.
 
-  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
   (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
   This program and the accompanying materials  
   are licensed and made available under the terms and conditions of the BSD 
License 
@@ -2252,9 +2252,9 @@ typedef struct {
 #define EFI_ACPI_6_0_ISCSI_BOOT_FIRMWARE_TABLE_SIGNATURE  SIGNATURE_32('i', 
'B', 'F', 'T')
 
 ///
-/// "IORT" Interrupt Source Override
+/// "IORT" I/O Remapping Table
 ///
-#define EFI_ACPI_6_0_INTERRUPT_SOURCE_OVERRIDE_SIGNATURE  SIGNATURE_32('I', 
'O', 'R', 'T')
+#define EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE  SIGNATURE_32('I', 'O', 'R', 
'T')
 
 ///
 /// "IVRS" I/O Virtualization Reporting Structure
diff --git a/MdePkg/Include/IndustryStandard/Acpi61.h 
b/MdePkg/Include/IndustryStandard/Acpi61.h
index dc3153b7e7c8..0fac9a80694d 100644
--- a/MdePkg/Include/IndustryStandard/Acpi61.h
+++ b/MdePkg/Include/IndustryStandard/Acpi61.h
@@ -1,7 +1,7 @@
 /** @file   
   ACPI 6.1 definitions from the ACPI Specification Revision 6.1 January, 2016.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
   This program and the accompanying materials  
   are licensed and made available under the terms and conditions of the BSD 
License 
@@ -2284,9 +2284,9 @@ typedef struct {
 #define EFI_ACPI_6_1_ISCSI_BOOT_FIRMWARE_TABLE_SIGNATURE  SIGNATURE_32('i', 
'B', 'F', 'T')
 
 ///
-/// "IORT" Interrupt Source Override
+/// "IORT" I/O Remapping Table
 ///
-#define EFI_ACPI_6_1_INTERRUPT_SOURCE_OVERRIDE_SIGNATURE  SIGNATURE_32('I', 
'O', 'R', 'T')
+#define EFI_ACPI_6_1_IO_REMAPPING_TABLE_SIGNATURE  SIGNATURE_32('I', 'O', 'R', 
'T')
 
 ///
 /// "IVRS" I/O Virtualization Reporting Structure
-- 
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 3/3] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

[Fan, Jeff]

Leo,

If this PCD is only to patch address, could you make sure the other fields not 
to be updated in case the platform set the other fields in PCD.

PageTable setup in DxeIpl is in boot service data range. If this feature is 
only supported in POST phase, that's enough.

Thanks!
Jeff

-Original Message-
From: Duran, Leo [mailto:leo.du...@amd.com] 
Sent: Friday, February 10, 2017 12:28 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Tian, Feng; Zeng, Star; Laszlo Ersek; Singh, Brijesh
Subject: RE: [PATCH 3/3] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add support 
for PCD PcdPteMemoryEncryptionAddressOrMask

Hi Jeff,
The new PCD is intended to be OR'ed with the address (upper bits).
Leo.

> -Original Message-
> From: Fan, Jeff [mailto:jeff@intel.com]
> Sent: Thursday, February 09, 2017 8:23 PM
> To: Duran, Leo ; edk2-de...@ml01.01.org
> Cc: Tian, Feng ; Zeng, Star 
> ; Laszlo Ersek ; Singh, 
> Brijesh 
> Subject: RE: [PATCH 3/3] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add 
> support for PCD PcdPteMemoryEncryptionAddressOrMask
> 
> Hi Leo,
> 
> I want to understand your usage model. What fields are you going to 
> update in below Page Table Entry by the new PCD?
> 
> typedef union {
>   struct {
> UINT64  Present:1;// 0 = Not present in memory, 1 = 
> Present in
> memory
> UINT64  ReadWrite:1;  // 0 = Read-Only, 1= Read/Write
> UINT64  UserSupervisor:1; // 0 = Supervisor, 1=User
> UINT64  WriteThrough:1;   // 0 = Write-Back caching, 
> 1=Write-Through
> caching
> UINT64  CacheDisabled:1;  // 0 = Cached, 1=Non-Cached
> UINT64  Accessed:1;   // 0 = Not accessed, 1 = Accessed (set 
> by CPU)
> UINT64  Dirty:1;  // 0 = Not Dirty, 1 = written by 
> processor on access
> to page
> UINT64  MustBe1:1;// Must be 1
> UINT64  Global:1; // 0 = Not global page, 1 = global page 
> TLB not
> cleared on CR3 write
> UINT64  Available:3;  // Available for use by system software
> UINT64  PAT:1;//
> UINT64  MustBeZero:8; // Must be zero;
> UINT64  PageTableBaseAddress:31;  // Page Table Base Address
> UINT64  AvabilableHigh:11;// Available for use by system software
> UINT64  Nx:1; // 0 = Execute Code, 1 = No Code 
> Execution
>   } Bits;
>   UINT64Uint64;
> } PAGE_TABLE_ENTRY;
> 
> I did not see any updating in SMM. Is it un-necessary? Is this feature 
> working on POST phase or OS runtime phase?
> 
> Thanks!
> Jeff
> 
> -Original Message-
> From: Leo Duran [mailto:leo.du...@amd.com]
> Sent: Thursday, February 09, 2017 5:13 AM
> To: edk2-de...@ml01.01.org
> Cc: Leo Duran; Fan, Jeff; Tian, Feng; Zeng, Star; Laszlo Ersek; 
> Brijesh Singh
> Subject: [PATCH 3/3] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add 
> support for PCD PcdPteMemoryEncryptionAddressOrMask
> 
> This PCD holds the address mask for page table entries when memory 
> encryption is enabled on AMD processors supporting the Secure 
> Encrypted Virtualization (SEV) feature.
> 
> The mask is applied when page tables are created (S3Resume.c).
> 
> CC: Jeff Fan 
> Cc: Feng Tian 
> Cc: Star Zeng 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Brijesh Singh 
> Signed-off-by: Leo Duran 
> ---
>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c   | 9 +
>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf | 2 ++
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> index d306fba..ee1e2cd 100644
> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> @@ -5,6 +5,7 @@
>control is passed to OS waking up handler.
> 
>Copyright (c) 2006 - 2016, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2017, AMD Incorporated. All rights reserved.
> 
>This program and the accompanying materials
>are licensed and made available under the terms and conditions @@ 
> -696,7
> +697,7 @@ RestoreS3PageTables (
>//
>// Make a PML4 Entry
>//
> -  PageMapLevel4Entry->Uint64 =
> (UINT64)(UINTN)PageDirectoryPointerEntry;
> +  PageMapLevel4Entry->Uint64 =
> + (UINT64)(UINTN)PageDirectoryPointerEntry | PcdGet64 
> + (PcdPteMemoryEncryptionAddressOrMask);
>PageMapLevel4Entry->Bits.ReadWrite = 1;
>PageMapLevel4Entry->Bits.Present = 1;
> 
> @@ -707,7 +708,7 @@ RestoreS3PageTables (
>//
>// Fill in the Page Directory entries
>//
> -  

Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

[Ard Biesheuvel]

> On 10 Feb 2017, at 06:34, Ard Biesheuvel  wrote:
> 
> 
> 
>> On 10 Feb 2017, at 02:26, Yao, Jiewen  wrote:
>> 
>> Very good question.
>>  
>> 1)   Yes, I did test UEFI OS boot, which is mentioned in V1 summary:
>> ==
>> Tested OS: UEFI Win10, UEFI Ubuntu 16.04.
>> ==
>>  
>> 2)   Star helps double confirm that OS already takes over the control of 
>> page table on SetVirtualAddressMap().
>> See below log on UEFI Win10.
>> ==
>> DXEIPL CR3 0x8814
>> RUNTIMEDXE CR3 0x1AB000
>> ==
>>  
> 
> Not on AArch64/ARM linux, and the spec does not mandate it, so we need to 
> deal with this imo
> 

I think we should probably undo the protections for runtime drivers in EBS()


>> Thank you
>> Yao Jiewen
>>  
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
>> Biesheuvel
>> Sent: Thursday, February 9, 2017 8:48 AM
>> To: Yao, Jiewen 
>> Cc: Tian, Feng ; edk2-devel@lists.01.org; Leif Lindholm 
>> ; Kinney, Michael D ; 
>> Fan, Jeff ; Zeng, Star 
>> Subject: Re: [edk2] [PATCH V3 0/4] DXE Memory Protection
>>  
>> On 9 February 2017 at 16:30, Ard Biesheuvel  
>> wrote:
>> > On 9 February 2017 at 16:29, Yao, Jiewen  wrote:
>> >> Very good point.
>> >>
>> >> Can ARCH64 set 4K paging for 64K aligned runtime memory?
>> >>
>> >
>> > UEFI always uses 4 KB, but the OS may use 64 KB, so to create the
>> > virtual address map it needs the runtime regions to be 64 KB aligned.
>> >
>> >>
>> >>
>> >> If yes, how about we use
>> >>
>> >> “ImageRecord->ImageSize = ALIGN_VALUE(LoadedImage->ImageSize,
>> >> EFI_PAGE_SIZE);”
>> >>
>> >
>> 
>> Another question: did you try SetVirtualAddressMap()? It looks like we
>> need to lift read-only permissions to allow the runtime PE/COFF
>> relocation to apply the fixups
>> ___
>> 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 0/4] DXE Memory Protection

[Ard Biesheuvel]

> On 10 Feb 2017, at 02:26, Yao, Jiewen  wrote:
> 
> Very good question.
>  
> 1)   Yes, I did test UEFI OS boot, which is mentioned in V1 summary:
> ==
> Tested OS: UEFI Win10, UEFI Ubuntu 16.04.
> ==
>  
> 2)   Star helps double confirm that OS already takes over the control of 
> page table on SetVirtualAddressMap().
> See below log on UEFI Win10.
> ==
> DXEIPL CR3 0x8814
> RUNTIMEDXE CR3 0x1AB000
> ==
>  

Not on AArch64/ARM linux, and the spec does not mandate it, so we need to deal 
with this imo

> Thank you
> Yao Jiewen
>  
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
> Biesheuvel
> Sent: Thursday, February 9, 2017 8:48 AM
> To: Yao, Jiewen 
> Cc: Tian, Feng ; edk2-devel@lists.01.org; Leif Lindholm 
> ; Kinney, Michael D ; 
> Fan, Jeff ; Zeng, Star 
> Subject: Re: [edk2] [PATCH V3 0/4] DXE Memory Protection
>  
> On 9 February 2017 at 16:30, Ard Biesheuvel  wrote:
> > On 9 February 2017 at 16:29, Yao, Jiewen  wrote:
> >> Very good point.
> >>
> >> Can ARCH64 set 4K paging for 64K aligned runtime memory?
> >>
> >
> > UEFI always uses 4 KB, but the OS may use 64 KB, so to create the
> > virtual address map it needs the runtime regions to be 64 KB aligned.
> >
> >>
> >>
> >> If yes, how about we use
> >>
> >> “ImageRecord->ImageSize = ALIGN_VALUE(LoadedImage->ImageSize,
> >> EFI_PAGE_SIZE);”
> >>
> >
> 
> Another question: did you try SetVirtualAddressMap()? It looks like we
> need to lift read-only permissions to allow the runtime PE/COFF
> relocation to apply the fixups
> ___
> 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] NetworkPkg:Generate the correct operational state of the interface.

[Ye, Ting]

Reviewed-by: Ye Ting 


-Original Message-
From: Zhang, Lubo 
Sent: Friday, February 10, 2017 11:38 AM
To: Wu, Jiaxin ; edk2-devel@lists.01.org
Cc: Santhapur Naveen ; Ye, Ting ; 
Fu, Siyuan 
Subject: RE: [patch] NetworkPkg:Generate the correct operational state of the 
interface.

Yes,  I just find the typo error.

Thanks
Lubo

-Original Message-
From: Wu, Jiaxin
Sent: Friday, February 10, 2017 11:33 AM
To: Zhang, Lubo ; edk2-devel@lists.01.org
Cc: Santhapur Naveen ; Ye, Ting ; 
Fu, Siyuan 
Subject: RE: [patch] NetworkPkg:Generate the correct operational state of the 
interface.

Need change the commit log, replace the 'ifconfig -l' with 'ifconfig6 -l' since 
it's the fix for IPv6.

Others is good to me.

Reviewed-by: Wu Jiaxin 

Thanks,
Jiaxin


> -Original Message-
> From: Zhang, Lubo
> Sent: Friday, February 10, 2017 11:18 AM
> To: edk2-devel@lists.01.org
> Cc: Santhapur Naveen ; Ye, Ting 
> ; Fu, Siyuan ; Wu, Jiaxin 
> 
> Subject: [patch] NetworkPkg:Generate the correct operational state of 
> the interface.
> 
> Currently, When there are more than 9 Ethernet ports available, 
> 'ifconfig -l' is not listing all the ports, only show the ports 0 to 9.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo 
> Cc: Santhapur Naveen 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> ---
>  NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> index 4e881fd..e309b69 100644
> --- a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> +++ b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> @@ -1436,15 +1436,16 @@ VOID
>  Ip6ConfigInitIfInfo (
>IN  IP6_SERVICE*IpSb,
>OUT EFI_IP6_CONFIG_INTERFACE_INFO  *IfInfo
>)
>  {
> -  IfInfo->Name[0] = L'e';
> -  IfInfo->Name[1] = L't';
> -  IfInfo->Name[2] = L'h';
> -  IfInfo->Name[3] = (CHAR16) (L'0' +
> IpSb->Ip6ConfigInstance.IfIndex);
> -  IfInfo->Name[4] = 0;
> +  UnicodeSPrint (
> +IfInfo->Name,
> +sizeof (IfInfo->Name),
> +L"eth%x",
> +IpSb->Ip6ConfigInstance.IfIndex
> +  );
> 
>IfInfo->IfType= IpSb->SnpMode.IfType;
>IfInfo->HwAddressSize = IpSb->SnpMode.HwAddressSize;
>CopyMem (>HwAddress, >SnpMode.CurrentAddress,
> IfInfo->HwAddressSize);
>  }
> --
> 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:Generate the correct operational state of the interface.

[Ye, Ting]

Reviewed-by: Ye Ting  

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang 
Lubo
Sent: Friday, February 10, 2017 11:18 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Wu, Jiaxin 

Subject: [edk2] [patch] MdeModulePkg:Generate the correct operational state of 
the interface.

Currently, When there are more than 9 Ethernet ports available, 'ifconfig -l' 
is not listing all the ports, only show the ports 0 to 9.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Santhapur Naveen 
Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
index 131b03f..a6a3da8 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
@@ -1490,15 +1490,16 @@ VOID
 Ip4Config2InitIfInfo (
   IN  IP4_SERVICE*IpSb,
   OUT EFI_IP4_CONFIG2_INTERFACE_INFO *IfInfo
   )
 {
-  IfInfo->Name[0] = L'e';
-  IfInfo->Name[1] = L't';
-  IfInfo->Name[2] = L'h';
-  IfInfo->Name[3] = (CHAR16) (L'0' + IpSb->Ip4Config2Instance.IfIndex);
-  IfInfo->Name[4] = 0;
+  UnicodeSPrint (
+IfInfo->Name,
+EFI_IP4_CONFIG2_INTERFACE_INFO_NAME_SIZE,
+L"eth%x",
+IpSb->Ip4Config2Instance.IfIndex
+  );
 
   IfInfo->IfType= IpSb->SnpMode.IfType;
   IfInfo->HwAddressSize = IpSb->SnpMode.HwAddressSize;
   CopyMem (>HwAddress, >SnpMode.CurrentAddress, 
IfInfo->HwAddressSize);  }
--
1.9.5.msysgit.1

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

Re: [edk2] Should we add PCI VenderId defines to the PCI Includes in the MdePkg.

[Gao, Liming]

Andrew:
  I agree with you. Could you help submit the tracker in bugzilla for this 
request?

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Andrew Fish
>Sent: Friday, February 10, 2017 11:31 AM
>To: edk2-devel 
>Subject: [edk2] Should we add PCI VenderId defines to the PCI Includes in the
>MdePkg.
>
>Some one was asking me why the PCI VendorIds  are not included in the
>MdePkg and my answer was it seems like a good idea to me.
>
>We don't have to go crazy as we only really need the VendorIds for vendors
>who make things that EFI deals with. It is probably easy enough to get an 
>initial
>list, and then just add values on request.
>
>Looks like a bit of duplication is already in the tree...
>
>(master)>git grep -w 0x8086 -- *.h *.c
>AppPkg/Applications/Python/Python-2.7.10/Objects/unicodetype_db.h:2636:
>case 0x8086:
>AppPkg/Applications/Python/Python-2.7.2/Objects/unicodetype_db.h:2636:
>case 0x8086:
>CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformConsole.c:50
>2: (Pci->Hdr.VendorId == 0x8086)
>DuetPkg/Library/DuetBdsLib/BdsPlatform.c:857:  ((IS_PCI_ISA_PDECODE
>()) && (Pci.Hdr.VendorId == 0x8086) && (Pci.Hdr.DeviceId == 0x7110))) {
>DuetPkg/PciBusNoEnumerationDxe/PciBus.h:222:#define
>IS_INTEL_ISA_BRIDGE(_p) (IS_CLASS2 (_p, PCI_CLASS_BRIDGE,
>PCI_CLASS_BRIDGE_ISA_PDECODE) && ((_p)->Hdr.VendorId == 0x8086) &&
>((_p)->Hdr.DeviceId == 0x7110))
>OptionRomPkg/UndiRuntimeDxe/E100b.h:23:#define PCI_VENDOR_ID_INTEL
>0x8086
>OptionRomPkg/UndiRuntimeDxe/E100b.h:25:#define D100_VENDOR_ID
>0x8086
>OptionRomPkg/UndiRuntimeDxe/Init.c:113:  than contains a  DevicePath,
>PciIo protocol, Class code of 2, Vendor ID of 0x8086,
>OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.c:72:0x8086,   // UINT16
>CompatibleVid
>OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.h:50:#define
>V_INTEL_VENDOR_ID 0x8086
>OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c:848: (Pci-
>>Hdr.VendorId == 0x8086) &&
>PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c:118:Pci.Hdr.VendorId ==
>0x8086  ) {
>QuarkPlatformPkg/Feature/Capsule/Library/PlatformFlashAccessLib/SpiFlash
>Device.h:181:#define PFAB_CARD_VENDOR_ID   0x8086
>QuarkPlatformPkg/Platform/SpiFvbServices/SpiFlashDevice.h:182:#define
>PFAB_CARD_VENDOR_ID   0x8086
>QuarkSocPkg/QuarkNorthCluster/Include/QuarkNcSocId.h:363:#define
>V_INTEL_VENDOR_ID  0x8086
>QuarkSocPkg/QuarkSouthCluster/Include/Ioh.h:69:#define
>INTEL_VENDOR_ID 0x8086  // Intel Vendor ID
>Vlv2DeviceRefCodePkg/ValleyView2Soc/NorthCluster/Include/Valleyview.h:3
>9:#define MC_VID  0x8086
>Vlv2DeviceRefCodePkg/ValleyView2Soc/NorthCluster/Include/Valleyview.h:5
>2:#define IGD_VID 0x8086
>Vlv2DeviceRefCodePkg/ValleyView2Soc/SouthCluster/Include/PchRegs.h:119
>:#define V_PCH_INTEL_VENDOR_ID   0x8086
>Vlv2TbltDevicePkg/Include/CommonIncludes.h:24:#define V_INTEL_VID
>0x8086
>Vlv2TbltDevicePkg/Include/Platform.h:136:#define
>V_DEFAULT_SUBSYSTEM_VENDOR_ID0x8086
>Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardSsidSvid/BoardSsidSvid.h:2
>4:#define SUBSYSTEM_VENDOR_ID1   0x8086
>Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardSsidSvid/BoardSsidSvid.h:2
>8:#define SUBSYSTEM_VENDOR_ID2   0x8086
>Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardSsidSvid/BoardSsidSvid.h:3
>2:#define SUBSYSTEM_VENDOR_ID   0x8086
>Vlv2TbltDevicePkg/PciPlatform/BoardPciPlatform.c:30:#define
>V_INTEL_LAN_VENDOR_ID 0x8086 // INTEL 82574 Gbe Controller
>Vendor ID
>Vlv2TbltDevicePkg/PlatformDxe/PciDevice.c:42:#define INTEL_VENDOR_ID
>0x8086
>Vlv2TbltDevicePkg/VlvPlatformInitDxe/IgdOpRegion.h:134:  UINT16  VendorId;
>// 0x8086
>Vlv2TbltDevicePkg/VlvPlatformInitDxe/VlvPlatformInit.h:61:#define IGD_VID
>0x8086
>Vlv2TbltDevicePkg/Wpce791/LpcDriver.c:194:Pci.Hdr.VendorId ==
>0x8086 &&
>
>
>Thanks,
>
>Andrew Fish
>___
>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 02/12] MdePkg/SmiHandlerProfileLibNull: Add NULL instance.

[Yao, Jiewen]

Got it. Thanks!

From: Gao, Liming
Sent: Thursday, February 9, 2017 7:30 PM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Laszlo Ersek 

Subject: RE: [edk2] [PATCH 02/12] MdePkg/SmiHandlerProfileLibNull: Add NULL 
instance.

One minor comment. This library type is DXE_SMM_DRIVER. It should include 
, not 

With this change, Reviewed-by: Liming Gao 
>.

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Jiewen Yao
>Sent: Thursday, February 09, 2017 12:30 AM
>To: edk2-devel@lists.01.org
>Cc: Kinney, Michael D 
>>; Laszlo Ersek
>>; Gao, Liming 
>>
>Subject: [edk2] [PATCH 02/12] MdePkg/SmiHandlerProfileLibNull: Add NULL
>instance.
>
>Cc: Michael D Kinney 
>>
>Cc: Liming Gao >
>Cc: Laszlo Ersek >
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Jiewen Yao >
>---
> MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.c   | 72
>
> MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.inf | 36
>++
> MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.uni | 21
>++
> 3 files changed, 129 insertions(+)
>
>diff --git
>a/MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.c
>b/MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.c
>new file mode 100644
>index 000..207482a
>--- /dev/null
>+++ b/MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.c
>@@ -0,0 +1,72 @@
>+/** @file
>+  NULL instance of SmiHandlerProfile Library.
>+
>+  Copyright (c) 2017, Intel Corporation. All rights reserved.
>+  This program and the accompanying materials
>+  are licensed and made available under the terms and conditions of the BSD
>License
>+  which accompanies this distribution.  The full text of the license may be
>found at
>+  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.
>+
>+**/
>+
>+#include 
>+#include 
>+
>+/**
>+  This function is called by SmmChildDispatcher module to report
>+  a new SMI handler is registered, to SmmCore.
>+
>+  @param HandlerGuid The GUID to identify the type of the handler.
>+ For the SmmChildDispatch protocol, the HandlerGuid
>+ must be the GUID of SmmChildDispatch protocol.
>+  @param Handler The SMI handler.
>+  @param CallerAddress   The address of the module who registers the SMI
>handler.
>+  @param Context The context of the SMI handler.
>+ For the SmmChildDispatch protocol, the Context
>+ must match the one defined for SmmChildDispatch 
>protocol.
>+  @param ContextSize The size of the context in bytes.
>+ For the SmmChildDispatch protocol, the Context
>+ must match the one defined for SmmChildDispatch 
>protocol.
>+
>+  @retval EFI_SUCCESS   The information is recorded.
>+  @retval EFI_UNSUPPORTED   The feature is unsupported.
>+  @retval EFI_OUT_OF_RESOURCES  There is no enough resource to record
>the information.
>+**/
>+EFI_STATUS
>+EFIAPI
>+SmiHandlerProfileRegisterHandler (
>+  IN EFI_GUID   *HandlerGuid,
>+  IN EFI_SMM_HANDLER_ENTRY_POINT2   Handler,
>+  IN PHYSICAL_ADDRESS   CallerAddress,
>+  IN VOID   *Context, OPTIONAL
>+  IN UINTN  ContextSize OPTIONAL
>+  )
>+{
>+  return EFI_UNSUPPORTED;
>+}
>+
>+/**
>+  This function is called by SmmChildDispatcher module to report
>+  an existing SMI handler is unregistered, to SmmCore.
>+
>+  @param HandlerGuid The GUID to identify the type of the handler.
>+ For the SmmChildDispatch protocol, the HandlerGuid
>+ must be the GUID of SmmChildDispatch protocol.
>+  @param Handler The SMI handler.
>+
>+  @retval EFI_SUCCESS   The original record is removed.
>+  @retval EFI_UNSUPPORTED   The feature is unsupported.
>+  @retval EFI_NOT_FOUND There is no record for the HandlerGuid and
>handler.
>+**/
>+EFI_STATUS
>+EFIAPI
>+SmiHandlerProfileUnregisterHandler (
>+  IN EFI_GUID   *HandlerGuid,
>+  IN EFI_SMM_HANDLER_ENTRY_POINT2   Handler
>+  )
>+{
>+  return EFI_UNSUPPORTED;
>+}
>diff --git

Re: [edk2] [PATCH 3/3] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

[Duran, Leo]

Hi Jeff,
The new PCD is intended to be OR'ed with the address (upper bits).
Leo.

> -Original Message-
> From: Fan, Jeff [mailto:jeff@intel.com]
> Sent: Thursday, February 09, 2017 8:23 PM
> To: Duran, Leo ; edk2-de...@ml01.01.org
> Cc: Tian, Feng ; Zeng, Star ;
> Laszlo Ersek ; Singh, Brijesh 
> Subject: RE: [PATCH 3/3] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add
> support for PCD PcdPteMemoryEncryptionAddressOrMask
> 
> Hi Leo,
> 
> I want to understand your usage model. What fields are you going to update
> in below Page Table Entry by the new PCD?
> 
> typedef union {
>   struct {
> UINT64  Present:1;// 0 = Not present in memory, 1 = 
> Present in
> memory
> UINT64  ReadWrite:1;  // 0 = Read-Only, 1= Read/Write
> UINT64  UserSupervisor:1; // 0 = Supervisor, 1=User
> UINT64  WriteThrough:1;   // 0 = Write-Back caching, 
> 1=Write-Through
> caching
> UINT64  CacheDisabled:1;  // 0 = Cached, 1=Non-Cached
> UINT64  Accessed:1;   // 0 = Not accessed, 1 = Accessed (set 
> by CPU)
> UINT64  Dirty:1;  // 0 = Not Dirty, 1 = written by 
> processor on access
> to page
> UINT64  MustBe1:1;// Must be 1
> UINT64  Global:1; // 0 = Not global page, 1 = global page 
> TLB not
> cleared on CR3 write
> UINT64  Available:3;  // Available for use by system software
> UINT64  PAT:1;//
> UINT64  MustBeZero:8; // Must be zero;
> UINT64  PageTableBaseAddress:31;  // Page Table Base Address
> UINT64  AvabilableHigh:11;// Available for use by system software
> UINT64  Nx:1; // 0 = Execute Code, 1 = No Code 
> Execution
>   } Bits;
>   UINT64Uint64;
> } PAGE_TABLE_ENTRY;
> 
> I did not see any updating in SMM. Is it un-necessary? Is this feature working
> on POST phase or OS runtime phase?
> 
> Thanks!
> Jeff
> 
> -Original Message-
> From: Leo Duran [mailto:leo.du...@amd.com]
> Sent: Thursday, February 09, 2017 5:13 AM
> To: edk2-de...@ml01.01.org
> Cc: Leo Duran; Fan, Jeff; Tian, Feng; Zeng, Star; Laszlo Ersek; Brijesh Singh
> Subject: [PATCH 3/3] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add
> support for PCD PcdPteMemoryEncryptionAddressOrMask
> 
> This PCD holds the address mask for page table entries when memory
> encryption is enabled on AMD processors supporting the Secure Encrypted
> Virtualization (SEV) feature.
> 
> The mask is applied when page tables are created (S3Resume.c).
> 
> CC: Jeff Fan 
> Cc: Feng Tian 
> Cc: Star Zeng 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Brijesh Singh 
> Signed-off-by: Leo Duran 
> ---
>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c   | 9 +
>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf | 2 ++
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> index d306fba..ee1e2cd 100644
> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> @@ -5,6 +5,7 @@
>control is passed to OS waking up handler.
> 
>Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2017, AMD Incorporated. All rights reserved.
> 
>This program and the accompanying materials
>are licensed and made available under the terms and conditions @@ -696,7
> +697,7 @@ RestoreS3PageTables (
>//
>// Make a PML4 Entry
>//
> -  PageMapLevel4Entry->Uint64 =
> (UINT64)(UINTN)PageDirectoryPointerEntry;
> +  PageMapLevel4Entry->Uint64 =
> + (UINT64)(UINTN)PageDirectoryPointerEntry | PcdGet64
> + (PcdPteMemoryEncryptionAddressOrMask);
>PageMapLevel4Entry->Bits.ReadWrite = 1;
>PageMapLevel4Entry->Bits.Present = 1;
> 
> @@ -707,7 +708,7 @@ RestoreS3PageTables (
>//
>// Fill in the Page Directory entries
>//
> -  PageDirectory1GEntry->Uint64 = (UINT64)PageAddress;
> +  PageDirectory1GEntry->Uint64 = (UINT64)PageAddress | PcdGet64
> + (PcdPteMemoryEncryptionAddressOrMask);
>PageDirectory1GEntry->Bits.ReadWrite = 1;
>PageDirectory1GEntry->Bits.Present = 1;
>PageDirectory1GEntry->Bits.MustBe1 = 1; @@ -724,7 +725,7 @@
> RestoreS3PageTables (
>//
>// Fill in a Page Directory Pointer Entries
>//
> -  PageDirectoryPointerEntry->Uint64 =
> (UINT64)(UINTN)PageDirectoryEntry;
> +  PageDirectoryPointerEntry->Uint64 =
> + (UINT64)(UINTN)PageDirectoryEntry | PcdGet64
> + 

Re: [edk2] [patch] NetworkPkg:Generate the correct operational state of the interface.

[Zhang, Lubo]

Yes,  I just find the typo error.

Thanks
Lubo

-Original Message-
From: Wu, Jiaxin 
Sent: Friday, February 10, 2017 11:33 AM
To: Zhang, Lubo ; edk2-devel@lists.01.org
Cc: Santhapur Naveen ; Ye, Ting ; 
Fu, Siyuan 
Subject: RE: [patch] NetworkPkg:Generate the correct operational state of the 
interface.

Need change the commit log, replace the 'ifconfig -l' with 'ifconfig6 -l' since 
it's the fix for IPv6.

Others is good to me.

Reviewed-by: Wu Jiaxin 

Thanks,
Jiaxin


> -Original Message-
> From: Zhang, Lubo
> Sent: Friday, February 10, 2017 11:18 AM
> To: edk2-devel@lists.01.org
> Cc: Santhapur Naveen ; Ye, Ting 
> ; Fu, Siyuan ; Wu, Jiaxin 
> 
> Subject: [patch] NetworkPkg:Generate the correct operational state of 
> the interface.
> 
> Currently, When there are more than 9 Ethernet ports available, 
> 'ifconfig -l' is not listing all the ports, only show the ports 0 to 9.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo 
> Cc: Santhapur Naveen 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> ---
>  NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> index 4e881fd..e309b69 100644
> --- a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> +++ b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> @@ -1436,15 +1436,16 @@ VOID
>  Ip6ConfigInitIfInfo (
>IN  IP6_SERVICE*IpSb,
>OUT EFI_IP6_CONFIG_INTERFACE_INFO  *IfInfo
>)
>  {
> -  IfInfo->Name[0] = L'e';
> -  IfInfo->Name[1] = L't';
> -  IfInfo->Name[2] = L'h';
> -  IfInfo->Name[3] = (CHAR16) (L'0' + 
> IpSb->Ip6ConfigInstance.IfIndex);
> -  IfInfo->Name[4] = 0;
> +  UnicodeSPrint (
> +IfInfo->Name,
> +sizeof (IfInfo->Name),
> +L"eth%x",
> +IpSb->Ip6ConfigInstance.IfIndex
> +  );
> 
>IfInfo->IfType= IpSb->SnpMode.IfType;
>IfInfo->HwAddressSize = IpSb->SnpMode.HwAddressSize;
>CopyMem (>HwAddress, >SnpMode.CurrentAddress,
> IfInfo->HwAddressSize);
>  }
> --
> 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] NetworkPkg:Generate the correct operational state of the interface.

[Wu, Jiaxin]

Need change the commit log, replace the 'ifconfig -l' with 'ifconfig6 -l' since 
it's the fix for IPv6.

Others is good to me.

Reviewed-by: Wu Jiaxin 

Thanks,
Jiaxin


> -Original Message-
> From: Zhang, Lubo
> Sent: Friday, February 10, 2017 11:18 AM
> To: edk2-devel@lists.01.org
> Cc: Santhapur Naveen ; Ye, Ting
> ; Fu, Siyuan ; Wu, Jiaxin
> 
> Subject: [patch] NetworkPkg:Generate the correct operational state of the
> interface.
> 
> Currently, When there are more than 9 Ethernet ports available,
> 'ifconfig -l' is not listing all the ports, only show the ports 0 to 9.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo 
> Cc: Santhapur Naveen 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> ---
>  NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> index 4e881fd..e309b69 100644
> --- a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> +++ b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> @@ -1436,15 +1436,16 @@ VOID
>  Ip6ConfigInitIfInfo (
>IN  IP6_SERVICE*IpSb,
>OUT EFI_IP6_CONFIG_INTERFACE_INFO  *IfInfo
>)
>  {
> -  IfInfo->Name[0] = L'e';
> -  IfInfo->Name[1] = L't';
> -  IfInfo->Name[2] = L'h';
> -  IfInfo->Name[3] = (CHAR16) (L'0' + IpSb->Ip6ConfigInstance.IfIndex);
> -  IfInfo->Name[4] = 0;
> +  UnicodeSPrint (
> +IfInfo->Name,
> +sizeof (IfInfo->Name),
> +L"eth%x",
> +IpSb->Ip6ConfigInstance.IfIndex
> +  );
> 
>IfInfo->IfType= IpSb->SnpMode.IfType;
>IfInfo->HwAddressSize = IpSb->SnpMode.HwAddressSize;
>CopyMem (>HwAddress, >SnpMode.CurrentAddress,
> IfInfo->HwAddressSize);
>  }
> --
> 1.9.5.msysgit.1

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

[edk2] Should we add PCI VenderId defines to the PCI Includes in the MdePkg.

[Andrew Fish]

Some one was asking me why the PCI VendorIds  are not included in the MdePkg 
and my answer was it seems like a good idea to me. 

We don't have to go crazy as we only really need the VendorIds for vendors who 
make things that EFI deals with. It is probably easy enough to get an initial 
list, and then just add values on request.

Looks like a bit of duplication is already in the tree... 

(master)>git grep -w 0x8086 -- *.h *.c
AppPkg/Applications/Python/Python-2.7.10/Objects/unicodetype_db.h:2636:case 
0x8086:
AppPkg/Applications/Python/Python-2.7.2/Objects/unicodetype_db.h:2636:case 
0x8086:
CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformConsole.c:502:
 (Pci->Hdr.VendorId == 0x8086)
DuetPkg/Library/DuetBdsLib/BdsPlatform.c:857:  ((IS_PCI_ISA_PDECODE 
()) && (Pci.Hdr.VendorId == 0x8086) && (Pci.Hdr.DeviceId == 0x7110))) {
DuetPkg/PciBusNoEnumerationDxe/PciBus.h:222:#define IS_INTEL_ISA_BRIDGE(_p) 
(IS_CLASS2 (_p, PCI_CLASS_BRIDGE, PCI_CLASS_BRIDGE_ISA_PDECODE) && 
((_p)->Hdr.VendorId == 0x8086) && ((_p)->Hdr.DeviceId == 0x7110))
OptionRomPkg/UndiRuntimeDxe/E100b.h:23:#define PCI_VENDOR_ID_INTEL 0x8086
OptionRomPkg/UndiRuntimeDxe/E100b.h:25:#define D100_VENDOR_ID   0x8086
OptionRomPkg/UndiRuntimeDxe/Init.c:113:  than contains a  DevicePath, PciIo 
protocol, Class code of 2, Vendor ID of 0x8086,
OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.c:72:0x8086,   // UINT16  
CompatibleVid
OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.h:50:#define V_INTEL_VENDOR_ID 
0x8086
OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c:848: 
(Pci->Hdr.VendorId == 0x8086) &&
PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c:118:Pci.Hdr.VendorId == 
0x8086  ) {
QuarkPlatformPkg/Feature/Capsule/Library/PlatformFlashAccessLib/SpiFlashDevice.h:181:#define
 PFAB_CARD_VENDOR_ID   0x8086
QuarkPlatformPkg/Platform/SpiFvbServices/SpiFlashDevice.h:182:#define 
PFAB_CARD_VENDOR_ID   0x8086
QuarkSocPkg/QuarkNorthCluster/Include/QuarkNcSocId.h:363:#define 
V_INTEL_VENDOR_ID  0x8086
QuarkSocPkg/QuarkSouthCluster/Include/Ioh.h:69:#define INTEL_VENDOR_ID 
0x8086  // Intel Vendor ID
Vlv2DeviceRefCodePkg/ValleyView2Soc/NorthCluster/Include/Valleyview.h:39:#define
 MC_VID  0x8086
Vlv2DeviceRefCodePkg/ValleyView2Soc/NorthCluster/Include/Valleyview.h:52:#define
 IGD_VID 0x8086
Vlv2DeviceRefCodePkg/ValleyView2Soc/SouthCluster/Include/PchRegs.h:119:#define 
V_PCH_INTEL_VENDOR_ID   0x8086
Vlv2TbltDevicePkg/Include/CommonIncludes.h:24:#define V_INTEL_VID 0x8086
Vlv2TbltDevicePkg/Include/Platform.h:136:#define V_DEFAULT_SUBSYSTEM_VENDOR_ID  
  0x8086
Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardSsidSvid/BoardSsidSvid.h:24:#define
 SUBSYSTEM_VENDOR_ID1   0x8086
Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardSsidSvid/BoardSsidSvid.h:28:#define
 SUBSYSTEM_VENDOR_ID2   0x8086
Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardSsidSvid/BoardSsidSvid.h:32:#define
 SUBSYSTEM_VENDOR_ID   0x8086
Vlv2TbltDevicePkg/PciPlatform/BoardPciPlatform.c:30:#define   
V_INTEL_LAN_VENDOR_ID 0x8086 // INTEL 82574 Gbe Controller Vendor ID
Vlv2TbltDevicePkg/PlatformDxe/PciDevice.c:42:#define INTEL_VENDOR_ID 0x8086
Vlv2TbltDevicePkg/VlvPlatformInitDxe/IgdOpRegion.h:134:  UINT16  VendorId;   // 
0x8086
Vlv2TbltDevicePkg/VlvPlatformInitDxe/VlvPlatformInit.h:61:#define IGD_VID   
  0x8086
Vlv2TbltDevicePkg/Wpce791/LpcDriver.c:194:Pci.Hdr.VendorId == 
0x8086 &&


Thanks,

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

Re: [edk2] [patch] MdeModulePkg:Generate the correct operational state of the interface.

[Wu, Jiaxin]

Reviewed-by: Wu Jiaxin 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Zhang Lubo
> Sent: Friday, February 10, 2017 11:18 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin 
> Subject: [edk2] [patch] MdeModulePkg:Generate the correct operational
> state of the interface.
> 
> Currently, When there are more than 9 Ethernet ports available,
> 'ifconfig -l' is not listing all the ports, only show the ports 0 to 9.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo 
> Cc: Santhapur Naveen 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> ---
>  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c | 11 ++--
> ---
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> index 131b03f..a6a3da8 100644
> --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> @@ -1490,15 +1490,16 @@ VOID
>  Ip4Config2InitIfInfo (
>IN  IP4_SERVICE*IpSb,
>OUT EFI_IP4_CONFIG2_INTERFACE_INFO *IfInfo
>)
>  {
> -  IfInfo->Name[0] = L'e';
> -  IfInfo->Name[1] = L't';
> -  IfInfo->Name[2] = L'h';
> -  IfInfo->Name[3] = (CHAR16) (L'0' + IpSb->Ip4Config2Instance.IfIndex);
> -  IfInfo->Name[4] = 0;
> +  UnicodeSPrint (
> +IfInfo->Name,
> +EFI_IP4_CONFIG2_INTERFACE_INFO_NAME_SIZE,
> +L"eth%x",
> +IpSb->Ip4Config2Instance.IfIndex
> +  );
> 
>IfInfo->IfType= IpSb->SnpMode.IfType;
>IfInfo->HwAddressSize = IpSb->SnpMode.HwAddressSize;
>CopyMem (>HwAddress, >SnpMode.CurrentAddress,
> IfInfo->HwAddressSize);
>  }
> --
> 1.9.5.msysgit.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 02/12] MdePkg/SmiHandlerProfileLibNull: Add NULL instance.

[Gao, Liming]

One minor comment. This library type is DXE_SMM_DRIVER. It should include 
, not  

With this change, Reviewed-by: Liming Gao .

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Jiewen Yao
>Sent: Thursday, February 09, 2017 12:30 AM
>To: edk2-devel@lists.01.org
>Cc: Kinney, Michael D ; Laszlo Ersek
>; Gao, Liming 
>Subject: [edk2] [PATCH 02/12] MdePkg/SmiHandlerProfileLibNull: Add NULL
>instance.
>
>Cc: Michael D Kinney 
>Cc: Liming Gao 
>Cc: Laszlo Ersek 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Jiewen Yao 
>---
> MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.c   | 72
>
> MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.inf | 36
>++
> MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.uni | 21
>++
> 3 files changed, 129 insertions(+)
>
>diff --git
>a/MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.c
>b/MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.c
>new file mode 100644
>index 000..207482a
>--- /dev/null
>+++ b/MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.c
>@@ -0,0 +1,72 @@
>+/** @file
>+  NULL instance of SmiHandlerProfile Library.
>+
>+  Copyright (c) 2017, Intel Corporation. All rights reserved.
>+  This program and the accompanying materials
>+  are licensed and made available under the terms and conditions of the BSD
>License
>+  which accompanies this distribution.  The full text of the license may be
>found at
>+  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.
>+
>+**/
>+
>+#include 
>+#include 
>+
>+/**
>+  This function is called by SmmChildDispatcher module to report
>+  a new SMI handler is registered, to SmmCore.
>+
>+  @param HandlerGuid The GUID to identify the type of the handler.
>+ For the SmmChildDispatch protocol, the HandlerGuid
>+ must be the GUID of SmmChildDispatch protocol.
>+  @param Handler The SMI handler.
>+  @param CallerAddress   The address of the module who registers the SMI
>handler.
>+  @param Context The context of the SMI handler.
>+ For the SmmChildDispatch protocol, the Context
>+ must match the one defined for SmmChildDispatch 
>protocol.
>+  @param ContextSize The size of the context in bytes.
>+ For the SmmChildDispatch protocol, the Context
>+ must match the one defined for SmmChildDispatch 
>protocol.
>+
>+  @retval EFI_SUCCESS   The information is recorded.
>+  @retval EFI_UNSUPPORTED   The feature is unsupported.
>+  @retval EFI_OUT_OF_RESOURCES  There is no enough resource to record
>the information.
>+**/
>+EFI_STATUS
>+EFIAPI
>+SmiHandlerProfileRegisterHandler (
>+  IN EFI_GUID   *HandlerGuid,
>+  IN EFI_SMM_HANDLER_ENTRY_POINT2   Handler,
>+  IN PHYSICAL_ADDRESS   CallerAddress,
>+  IN VOID   *Context, OPTIONAL
>+  IN UINTN  ContextSize OPTIONAL
>+  )
>+{
>+  return EFI_UNSUPPORTED;
>+}
>+
>+/**
>+  This function is called by SmmChildDispatcher module to report
>+  an existing SMI handler is unregistered, to SmmCore.
>+
>+  @param HandlerGuid The GUID to identify the type of the handler.
>+ For the SmmChildDispatch protocol, the HandlerGuid
>+ must be the GUID of SmmChildDispatch protocol.
>+  @param Handler The SMI handler.
>+
>+  @retval EFI_SUCCESS   The original record is removed.
>+  @retval EFI_UNSUPPORTED   The feature is unsupported.
>+  @retval EFI_NOT_FOUND There is no record for the HandlerGuid and
>handler.
>+**/
>+EFI_STATUS
>+EFIAPI
>+SmiHandlerProfileUnregisterHandler (
>+  IN EFI_GUID   *HandlerGuid,
>+  IN EFI_SMM_HANDLER_ENTRY_POINT2   Handler
>+  )
>+{
>+  return EFI_UNSUPPORTED;
>+}
>diff --git
>a/MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.inf
>b/MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.inf
>new file mode 100644
>index 000..8220834
>--- /dev/null
>+++ b/MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.inf
>@@ -0,0 +1,36 @@
>+## @file
>+# NULL instance of SmiHandlerProfile Library.
>+#
>+#  Copyright (c) 2017, Intel Corporation. All rights reserved.
>+#
>+#  This program and the accompanying materials
>+#  are licensed and made available under the terms and conditions of the
>BSD License
>+#  which accompanies this distribution. The full text of the license 

Re: [edk2] [PATCH 01/12] MdePkg/Include: Add SmiHandlerProfileLib.h

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: Yao, Jiewen
>Sent: Thursday, February 09, 2017 12:30 AM
>To: edk2-devel@lists.01.org
>Cc: Kinney, Michael D ; Gao, Liming
>; Laszlo Ersek 
>Subject: [PATCH 01/12] MdePkg/Include: Add SmiHandlerProfileLib.h
>
>This library should be linked by SmmChildDispatch to
>report the hardware SMI handler maintained by SmmChildDispatch.
>
>Cc: Michael D Kinney 
>Cc: Liming Gao 
>Cc: Laszlo Ersek 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Jiewen Yao 
>---
> MdePkg/Include/Library/SmiHandlerProfileLib.h | 81
>
> MdePkg/MdePkg.dec |  5 +-
> 2 files changed, 85 insertions(+), 1 deletion(-)
>
>diff --git a/MdePkg/Include/Library/SmiHandlerProfileLib.h
>b/MdePkg/Include/Library/SmiHandlerProfileLib.h
>new file mode 100644
>index 000..10b7323
>--- /dev/null
>+++ b/MdePkg/Include/Library/SmiHandlerProfileLib.h
>@@ -0,0 +1,81 @@
>+/** @file
>+  Provides services to log the SMI handler registration.
>+
>+  This API provides services for the SMM Child Dispatch Protocols provider,
>+  to register SMI handler information to SmmCore.
>+
>+  NOTE:
>+  There is no need to update the consumers of SMST->SmiHandlerRegister()
>or
>+  the consumers of SMM Child Dispatch Protocols.
>+  The SmmCore (who produces SMST) should have ability to register such
>+  information directly.
>+  The SmmChildDispatcher (who produces SMM Child Dispatch Protocols)
>should
>+  be responsible to call the services to register information to SMM Core.
>+
>+Copyright (c) 2017, Intel Corporation. All rights reserved.
>+This program and the accompanying materials
>+are licensed and made available under the terms and conditions of the BSD
>License
>+which accompanies this distribution.  The full text of the license may be
>found at
>+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 __SMI_HANDLER_PROFILE_LIB_H__
>+#define __SMI_HANDLER_PROFILE_LIB_H__
>+
>+#include 
>+
>+/**
>+  This function is called by SmmChildDispatcher module to report
>+  a new SMI handler is registered, to SmmCore.
>+
>+  @param HandlerGuid The GUID to identify the type of the handler.
>+ For the SmmChildDispatch protocol, the HandlerGuid
>+ must be the GUID of SmmChildDispatch protocol.
>+  @param Handler The SMI handler.
>+  @param CallerAddress   The address of the module who registers the SMI
>handler.
>+  @param Context The context of the SMI handler.
>+ For the SmmChildDispatch protocol, the Context
>+ must match the one defined for SmmChildDispatch 
>protocol.
>+  @param ContextSize The size of the context in bytes.
>+ For the SmmChildDispatch protocol, the Context
>+ must match the one defined for SmmChildDispatch 
>protocol.
>+
>+  @retval EFI_SUCCESS   The information is recorded.
>+  @retval EFI_UNSUPPORTED   The feature is unsupported.
>+  @retval EFI_OUT_OF_RESOURCES  There is no enough resource to record
>the information.
>+**/
>+EFI_STATUS
>+EFIAPI
>+SmiHandlerProfileRegisterHandler (
>+  IN EFI_GUID   *HandlerGuid,
>+  IN EFI_SMM_HANDLER_ENTRY_POINT2   Handler,
>+  IN PHYSICAL_ADDRESS   CallerAddress,
>+  IN VOID   *Context, OPTIONAL
>+  IN UINTN  ContextSize OPTIONAL
>+  );
>+
>+/**
>+  This function is called by SmmChildDispatcher module to report
>+  an existing SMI handler is unregistered, to SmmCore.
>+
>+  @param HandlerGuid The GUID to identify the type of the handler.
>+ For the SmmChildDispatch protocol, the HandlerGuid
>+ must be the GUID of SmmChildDispatch protocol.
>+  @param Handler The SMI handler.
>+
>+  @retval EFI_SUCCESS   The original record is removed.
>+  @retval EFI_UNSUPPORTED   The feature is unsupported.
>+  @retval EFI_NOT_FOUND There is no record for the HandlerGuid and
>handler.
>+**/
>+EFI_STATUS
>+EFIAPI
>+SmiHandlerProfileUnregisterHandler (
>+  IN EFI_GUID   *HandlerGuid,
>+  IN EFI_SMM_HANDLER_ENTRY_POINT2   Handler
>+  );
>+
>+#endif
>diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
>index f2bdb30..3310029 100644
>--- a/MdePkg/MdePkg.dec
>+++ b/MdePkg/MdePkg.dec
>@@ -4,7 +4,7 @@
> # It also provides the definitions(including PPIs/PROTOCOLs/GUIDs) of
> # EFI1.10/UEFI2.6/PI1.4 and some Industry Standards.
> #
>-# Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
>+# Copyright 

[edk2] [patch] MdeModulePkg:Generate the correct operational state of the interface.

[Zhang Lubo]

Currently, When there are more than 9 Ethernet ports available,
'ifconfig -l' is not listing all the ports, only show the ports 0 to 9.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Santhapur Naveen 
Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
index 131b03f..a6a3da8 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
@@ -1490,15 +1490,16 @@ VOID
 Ip4Config2InitIfInfo (
   IN  IP4_SERVICE*IpSb,
   OUT EFI_IP4_CONFIG2_INTERFACE_INFO *IfInfo
   )
 {
-  IfInfo->Name[0] = L'e';
-  IfInfo->Name[1] = L't';
-  IfInfo->Name[2] = L'h';
-  IfInfo->Name[3] = (CHAR16) (L'0' + IpSb->Ip4Config2Instance.IfIndex);
-  IfInfo->Name[4] = 0;
+  UnicodeSPrint (
+IfInfo->Name,
+EFI_IP4_CONFIG2_INTERFACE_INFO_NAME_SIZE,
+L"eth%x",
+IpSb->Ip4Config2Instance.IfIndex
+  );
 
   IfInfo->IfType= IpSb->SnpMode.IfType;
   IfInfo->HwAddressSize = IpSb->SnpMode.HwAddressSize;
   CopyMem (>HwAddress, >SnpMode.CurrentAddress, 
IfInfo->HwAddressSize);
 }
-- 
1.9.5.msysgit.1

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

[edk2] [patch] NetworkPkg:Generate the correct operational state of the interface.

[Zhang Lubo]

Currently, When there are more than 9 Ethernet ports available,
'ifconfig -l' is not listing all the ports, only show the ports 0 to 9.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Santhapur Naveen 
Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
---
 NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c 
b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
index 4e881fd..e309b69 100644
--- a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
+++ b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
@@ -1436,15 +1436,16 @@ VOID
 Ip6ConfigInitIfInfo (
   IN  IP6_SERVICE*IpSb,
   OUT EFI_IP6_CONFIG_INTERFACE_INFO  *IfInfo
   )
 {
-  IfInfo->Name[0] = L'e';
-  IfInfo->Name[1] = L't';
-  IfInfo->Name[2] = L'h';
-  IfInfo->Name[3] = (CHAR16) (L'0' + IpSb->Ip6ConfigInstance.IfIndex);
-  IfInfo->Name[4] = 0;
+  UnicodeSPrint (
+IfInfo->Name,
+sizeof (IfInfo->Name),
+L"eth%x",
+IpSb->Ip6ConfigInstance.IfIndex
+  );
 
   IfInfo->IfType= IpSb->SnpMode.IfType;
   IfInfo->HwAddressSize = IpSb->SnpMode.HwAddressSize;
   CopyMem (>HwAddress, >SnpMode.CurrentAddress, 
IfInfo->HwAddressSize);
 }
-- 
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 v4 6/6] MdePkg/Pci22.h: Deprecate out-of-Spec IncompatiblePciDevice macros

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: Ni, Ruiyu
>Sent: Thursday, February 09, 2017 10:07 AM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming ; Fan, Jeff 
>Subject: [PATCH v4 6/6] MdePkg/Pci22.h: Deprecate out-of-Spec
>IncompatiblePciDevice macros
>
>DEVICE_ID_NOCARE is defined as 0x but Spec says (UINT64) -1
>should be used to match any VendorId/DeviceId/RevisionId/
>SubsystemVendorId/SubsystemDeviceId.
>
>PCI_BAR_OLD_ALIGN/PCI_BAR_EVEN_ALIGN/PCI_BAR_SQUAD_ALIGN/
>PCI_BAR_DQUAD_ALIGN are defined but Spec doesn't have such
>definitions.
>
>PCI_BAR_ALL is defined as 0xFF but Spec says (UINT64)-1 should be
>used to match all BARs.
>
>PCI_ACPI_UNUSED and PCI_BAR_NOCHANGE are defined as 0 which
>compliant with Spec but the name is too general and causes confusing.
>IncompatiblePciDeviceSupport could directly use 0.
>
>All of the above macros are marked as deprecated.
>
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Ruiyu Ni 
>Cc: Liming Gao 
>Cc: Jeff Fan 
>---
> MdePkg/Include/IndustryStandard/Pci22.h | 27 ++---
>--
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
>diff --git a/MdePkg/Include/IndustryStandard/Pci22.h
>b/MdePkg/Include/IndustryStandard/Pci22.h
>index 4cf8389..07718dc 100644
>--- a/MdePkg/Include/IndustryStandard/Pci22.h
>+++ b/MdePkg/Include/IndustryStandard/Pci22.h
>@@ -7,7 +7,7 @@
> PC Card Standard, 8.0
> PCI Power Management Interface Specifiction, Revision 1.2
>
>-  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
>+  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
>   Copyright (c) 2014 - 2015, Hewlett-Packard Development Company, L.P.
>   This program and the accompanying materials
>   are licensed and made available under the terms and conditions of the BSD
>License
>@@ -780,14 +780,24 @@ typedef struct {
>   ///
> } EFI_PCI_CAPABILITY_HOTPLUG;
>
>-#define DEVICE_ID_NOCARE0x
>+///
>+/// Below macros (till PCI_BAR_NOCHANGE) were used by
>EfiIncompatiblePciDeviceSupport Protocol.
>+///
>+#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
>+
>+///
>+/// [ATTENTION] These macros are deprecated because they don't match
>Spec or not defined in Spec.
>+///
>+#define DEVICE_ID_NOCARE0x ///< Deprecated. Value
>doesn't match Spec.
>+#define PCI_BAR_OLD_ALIGN   0xULL  ///< Deprecated.
>Value isn't defined in Spec.
>+#define PCI_BAR_EVEN_ALIGN  0xFFFEULL  ///< Deprecated.
>Value isn't defined in Spec.
>+#define PCI_BAR_SQUAD_ALIGN 0xFFFDULL  ///< Deprecated.
>Value isn't defined in Spec.
>+#define PCI_BAR_DQUAD_ALIGN 0xFFFCULL  ///< Deprecated.
>Value isn't defined in Spec.
>+#define PCI_BAR_ALL 0xFF   ///< Deprecated. Value 
>doesn't
>match Spec.
>+#define PCI_ACPI_UNUSED 0  ///< Deprecated. Macro 
>name is
>too general.
>+#define PCI_BAR_NOCHANGE0  ///< Deprecated. Macro 
>name is
>too general.
>
>-#define PCI_ACPI_UNUSED 0
>-#define PCI_BAR_NOCHANGE0
>-#define PCI_BAR_OLD_ALIGN   0xULL
>-#define PCI_BAR_EVEN_ALIGN  0xFFFEULL
>-#define PCI_BAR_SQUAD_ALIGN 0xFFFDULL
>-#define PCI_BAR_DQUAD_ALIGN 0xFFFCULL
>+#endif
>
> #define PCI_BAR_IDX00x00
> #define PCI_BAR_IDX10x01
>@@ -795,7 +805,6 @@ typedef struct {
> #define PCI_BAR_IDX30x03
> #define PCI_BAR_IDX40x04
> #define PCI_BAR_IDX50x05
>-#define PCI_BAR_ALL 0xFF
>
> ///
> /// EFI PCI Option ROM definitions
>--
>2.9.0.windows.1

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

[edk2] [patch] MdeMoudlePkg/DisplayEngine: Fix incorrect index used in array "InputText"

[Dandan Bi]

When set value to the array "InputText", the index was used incorrectly.
And the array "InputText" is not initialized. These will cause some value
in the array is random, so it will be shown incorrectly sometimes.
This patch is to fix this issue.

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

Cc: Eric Dong 
Cc: Liming Gao 
Cc: Wang Cloud 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 .../Universal/DisplayEngineDxe/InputHandler.c  | 33 --
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c 
b/MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c
index 400b934..d02c0bf 100644
--- a/MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c
+++ b/MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c
@@ -1,9 +1,9 @@
 /** @file
 Implementation for handling user input from the User Interfaces.
 
-Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
 http://opensource.org/licenses/bsd-license.php
 
@@ -522,10 +522,11 @@ GetNumericInput (
   Negative  = FALSE;
   ValidateFail  = FALSE;
 
   Question  = MenuOption->ThisTag;
   QuestionValue = >CurrentValue;
+  ZeroMem (InputText, MAX_NUMERIC_INPUT_WIDTH * sizeof (CHAR16));
 
   //
   // Only two case, user can enter to this function: Enter and +/- case.
   // In Enter case, gDirection = 0; in +/- case, gDirection = 
SCAN_LEFT/SCAN_WRIGHT
   //
@@ -688,20 +689,21 @@ GetNumericInput (
   }
 
   if (MenuOption->Sequence == 0) {
 InputText[0] = LEFT_NUMERIC_DELIMITER;
 SetUnicodeMem (InputText + 1, InputWidth, L' ');
-  } else {
+InputText[InputWidth + 1] = DATE_SEPARATOR;
+InputText[InputWidth + 2] = L'\0';
+  } else  if (MenuOption->Sequence == 1){
 SetUnicodeMem (InputText, InputWidth, L' ');
-  }
-
-  if (MenuOption->Sequence == 2) {
-InputText[InputWidth + 1] = RIGHT_NUMERIC_DELIMITER;
+InputText[InputWidth] = DATE_SEPARATOR;
+InputText[InputWidth + 1] = L'\0';
   } else {
-InputText[InputWidth + 1] = DATE_SEPARATOR;
+SetUnicodeMem (InputText, InputWidth, L' ');
+InputText[InputWidth] = RIGHT_NUMERIC_DELIMITER;
+InputText[InputWidth + 1] = L'\0';
   }
-  InputText[InputWidth + 2] = L'\0';
 
   PrintStringAt (Column, Row, InputText);
   if (MenuOption->Sequence == 0) {
 Column++;
   }
@@ -711,20 +713,21 @@ GetNumericInput (
   InputWidth = 2;
 
   if (MenuOption->Sequence == 0) {
 InputText[0] = LEFT_NUMERIC_DELIMITER;
 SetUnicodeMem (InputText + 1, InputWidth, L' ');
-  } else {
+InputText[InputWidth + 1] = TIME_SEPARATOR;
+InputText[InputWidth + 2] = L'\0';
+  } else if (MenuOption->Sequence == 1){
 SetUnicodeMem (InputText, InputWidth, L' ');
-  }
-
-  if (MenuOption->Sequence == 2) {
-InputText[InputWidth + 1] = RIGHT_NUMERIC_DELIMITER;
+InputText[InputWidth] = TIME_SEPARATOR;
+InputText[InputWidth + 1] = L'\0';
   } else {
-InputText[InputWidth + 1] = TIME_SEPARATOR;
+SetUnicodeMem (InputText, InputWidth, L' ');
+InputText[InputWidth] = RIGHT_NUMERIC_DELIMITER;
+InputText[InputWidth + 1] = L'\0';
   }
-  InputText[InputWidth + 2] = L'\0';
 
   PrintStringAt (Column, Row, InputText);
   if (MenuOption->Sequence == 0) {
 Column++;
   }
-- 
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 V3 0/4] DXE Memory Protection

[Yao, Jiewen]

Very good question.


1)   Yes, I did test UEFI OS boot, which is mentioned in V1 summary:
==
Tested OS: UEFI Win10, UEFI Ubuntu 16.04.
==


2)   Star helps double confirm that OS already takes over the control of 
page table on SetVirtualAddressMap().
See below log on UEFI Win10.
==
DXEIPL CR3 0x8814
RUNTIMEDXE CR3 0x1AB000
==

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Thursday, February 9, 2017 8:48 AM
To: Yao, Jiewen 
Cc: Tian, Feng ; edk2-devel@lists.01.org; Leif Lindholm 
; Kinney, Michael D ; 
Fan, Jeff ; Zeng, Star 
Subject: Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

On 9 February 2017 at 16:30, Ard Biesheuvel 
> wrote:
> On 9 February 2017 at 16:29, Yao, Jiewen 
> > wrote:
>> Very good point.
>>
>> Can ARCH64 set 4K paging for 64K aligned runtime memory?
>>
>
> UEFI always uses 4 KB, but the OS may use 64 KB, so to create the
> virtual address map it needs the runtime regions to be 64 KB aligned.
>
>>
>>
>> If yes, how about we use
>>
>> “ImageRecord->ImageSize = ALIGN_VALUE(LoadedImage->ImageSize,
>> EFI_PAGE_SIZE);”
>>
>

Another question: did you try SetVirtualAddressMap()? It looks like we
need to lift read-only permissions to allow the runtime PE/COFF
relocation to apply the fixups
___
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/3] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

[Fan, Jeff]

Hi Leo,

I want to understand your usage model. What fields are you going to update in 
below Page Table Entry by the new PCD?

typedef union {
  struct {
UINT64  Present:1;// 0 = Not present in memory, 1 = Present 
in memory
UINT64  ReadWrite:1;  // 0 = Read-Only, 1= Read/Write
UINT64  UserSupervisor:1; // 0 = Supervisor, 1=User
UINT64  WriteThrough:1;   // 0 = Write-Back caching, 
1=Write-Through caching
UINT64  CacheDisabled:1;  // 0 = Cached, 1=Non-Cached
UINT64  Accessed:1;   // 0 = Not accessed, 1 = Accessed (set by 
CPU)
UINT64  Dirty:1;  // 0 = Not Dirty, 1 = written by 
processor on access to page
UINT64  MustBe1:1;// Must be 1 
UINT64  Global:1; // 0 = Not global page, 1 = global page 
TLB not cleared on CR3 write
UINT64  Available:3;  // Available for use by system software
UINT64  PAT:1;//
UINT64  MustBeZero:8; // Must be zero;
UINT64  PageTableBaseAddress:31;  // Page Table Base Address
UINT64  AvabilableHigh:11;// Available for use by system software
UINT64  Nx:1; // 0 = Execute Code, 1 = No Code Execution
  } Bits;
  UINT64Uint64;
} PAGE_TABLE_ENTRY;

I did not see any updating in SMM. Is it un-necessary? Is this feature working 
on POST phase or OS runtime phase?

Thanks!
Jeff

-Original Message-
From: Leo Duran [mailto:leo.du...@amd.com] 
Sent: Thursday, February 09, 2017 5:13 AM
To: edk2-de...@ml01.01.org
Cc: Leo Duran; Fan, Jeff; Tian, Feng; Zeng, Star; Laszlo Ersek; Brijesh Singh
Subject: [PATCH 3/3] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add support for 
PCD PcdPteMemoryEncryptionAddressOrMask

This PCD holds the address mask for page table entries when memory encryption 
is enabled on AMD processors supporting the Secure Encrypted Virtualization 
(SEV) feature.

The mask is applied when page tables are created (S3Resume.c).

CC: Jeff Fan 
Cc: Feng Tian 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh 
Signed-off-by: Leo Duran 
---
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c   | 9 +
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf | 2 ++
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index d306fba..ee1e2cd 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
@@ -5,6 +5,7 @@
   control is passed to OS waking up handler.
 
   Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2017, AMD Incorporated. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions @@ -696,7 
+697,7 @@ RestoreS3PageTables (
   //
   // Make a PML4 Entry
   //
-  PageMapLevel4Entry->Uint64 = (UINT64)(UINTN)PageDirectoryPointerEntry;
+  PageMapLevel4Entry->Uint64 = 
+ (UINT64)(UINTN)PageDirectoryPointerEntry | PcdGet64 
+ (PcdPteMemoryEncryptionAddressOrMask);
   PageMapLevel4Entry->Bits.ReadWrite = 1;
   PageMapLevel4Entry->Bits.Present = 1;
 
@@ -707,7 +708,7 @@ RestoreS3PageTables (
   //
   // Fill in the Page Directory entries
   //
-  PageDirectory1GEntry->Uint64 = (UINT64)PageAddress;
+  PageDirectory1GEntry->Uint64 = (UINT64)PageAddress | PcdGet64 
+ (PcdPteMemoryEncryptionAddressOrMask);
   PageDirectory1GEntry->Bits.ReadWrite = 1;
   PageDirectory1GEntry->Bits.Present = 1;
   PageDirectory1GEntry->Bits.MustBe1 = 1; @@ -724,7 +725,7 @@ 
RestoreS3PageTables (
   //
   // Fill in a Page Directory Pointer Entries
   //
-  PageDirectoryPointerEntry->Uint64 = 
(UINT64)(UINTN)PageDirectoryEntry;
+  PageDirectoryPointerEntry->Uint64 = 
+ (UINT64)(UINTN)PageDirectoryEntry | PcdGet64 
+ (PcdPteMemoryEncryptionAddressOrMask);
   PageDirectoryPointerEntry->Bits.ReadWrite = 1;
   PageDirectoryPointerEntry->Bits.Present = 1;
 
@@ -732,7 +733,7 @@ RestoreS3PageTables (
 //
 // Fill in the Page Directory entries
 //
-PageDirectoryEntry->Uint64 = (UINT64)PageAddress;
+PageDirectoryEntry->Uint64 = (UINT64)PageAddress | PcdGet64 
+ (PcdPteMemoryEncryptionAddressOrMask);
 PageDirectoryEntry->Bits.ReadWrite = 1;
 PageDirectoryEntry->Bits.Present = 1;
 PageDirectoryEntry->Bits.MustBe1 = 1; diff --git 
a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
index 

Re: [edk2] [PATCH] ShellPkg SmbiosView: Correct some outputs for Type 0/3/10

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, February 09, 2017 1:24 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Ni, Ruiyu ;
> Carsey, Jaben 
> Subject: [PATCH] ShellPkg SmbiosView: Correct some outputs for Type
> 0/3/10
> Importance: High
> 
> Type 0: Update "EDD Enhanced Disk Driver)..." to
> "EDD (Enhanced Disk Driver)..." for
> STR_SMBIOSVIEW_PRINTINFO_EDD_ENHANCED_DRIVER
> 
> Type 3: Use L"  Laptop" instead of L"  LapTop" in
> SystemEnclosureTypeTable to match SMBIOS spec.
> 
> Type 10: The BIT7 of Device Type is representing the
> status of device whether it is enabled or disabled.
> But current code is not considering the BIT7 and will
> print "Undefined Value" for enabled device. Type 41
> has same definition of Device Type, the code is
> correct and will be applied to Type 10 by this patch.
> 
> Cc: Ruiyu Ni 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c |
> 3 ++-
>  ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
> | 2 +-
>  .../UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni|
> 2 +-
>  3 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> index 1d6002b92593..50d15ef1758e 100644
> ---
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> +++
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> @@ -570,7 +570,8 @@ SmbiosPrintStructure (
>UINTN NumOfDevice;
>NumOfDevice = (Struct->Type10->Hdr.Length - sizeof
> (SMBIOS_STRUCTURE)) / (2 * sizeof (UINT8));
>for (Index = 0; Index < NumOfDevice; Index++) {
> -DisplayOnboardDeviceTypes (Struct->Type10-
> >Device[Index].DeviceType, Option);
> +ShellPrintEx(-1,-1,(((Struct->Type10->Device[Index].DeviceType) &
> 0x80) != 0) ? L"Device Enabled\n": L"Device Disabled\n");
> +DisplayOnboardDeviceTypes ((Struct->Type10-
> >Device[Index].DeviceType) & 0x7F, Option);
>  ShellPrintHiiEx(-1,-1,NULL,STRING_TOKEN
> (STR_SMBIOSVIEW_PRINTINFO_DESC_STRING), gShellDebug1HiiHandle);
>  ShellPrintEx(-1,-1,L"%a\n",LibGetSmbiosString (Struct, 
> Struct->Type10-
> >Device[Index].DescriptionString));
>}
> diff --git
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> c
> index 02d9ab1f57b3..afea429b7aa3 100644
> ---
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> c
> +++
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> c
> @@ -166,7 +166,7 @@ TABLE_ITEM  SystemEnclosureTypeTable[] = {
>},
>{
>  0x09,
> -L"  LapTop"
> +L"  Laptop"
>},
>{
>  0x0A,
> diff --git
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosView
> Strings.uni
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosView
> Strings.uni
> index 7d694536dbcd..2cd682630557 100644
> ---
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosView
> Strings.uni
> +++
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosView
> Strings.uni
> @@ -133,7 +133,7 @@
>  #string STR_SMBIOSVIEW_PRINTINFO_SELECTED_BOOT_SUPPORTED
> #language en-US "Selectable Boot is supported\r\n"
>  #string STR_SMBIOSVIEW_PRINTINFO_BIOS_ROM_SOCKETED
> #language en-US "BIOS ROM is socketed\r\n"
>  #string STR_SMBIOSVIEW_PRINTINFO_BOOT_FROM_PC_CARD
> #language en-US "Boot From PC Card(PCMCIA)is supported\r\n"
> -#string STR_SMBIOSVIEW_PRINTINFO_EDD_ENHANCED_DRIVER
> #language en-US "EDD Enhanced Disk Driver) Specification is supported\r\n"
> +#string STR_SMBIOSVIEW_PRINTINFO_EDD_ENHANCED_DRIVER
> #language en-US "EDD (Enhanced Disk Driver) Specification is supported\r\n"
>  #string STR_SMBIOSVIEW_PRINTINFO_JAPANESE_FLOPPY_NEC
> #language en-US "Int 13h - Japanese Floppy for NEC 9800 1.2mb (3.5\",1k
> Bytes/Sector, 360 RPM) is supported\r\n"
>  #string STR_SMBIOSVIEW_PRINTINFO_JAPANESE_FLOPPY_TOSHIBA
> #language en-US "Int 13h - Japanese Floppy for Toshiba 1.2mn (3.5\", 360
> RPM) is supported\r\n"
>  #string STR_SMBIOSVIEW_PRINTINFO_FLOPPY_SERVICES_SUPPORTED
> #language en-US "Int 13h - 5.25\"/360KB Floppy Services are supported\r\n"
> --
> 2.7.0.windows.1

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

Re: [edk2] Print from DXE_DRIVER

[David A. Van Arnem]

On 02/08/2017 07:59 PM, Tim Lewis wrote:
> Also, on many systems, the output will be invisible, since boot screen output 
> is a platform policy. In general, using DEBUG() is better, since it can 
> either be redirected to StdErr() or through the serial port.
> 
> Tim

Thanks all, I do have some experience with using DEBUG() so I will take
that approach (and as Andrew said, that way the DEBUG() output can be
conditionally filtered based on priority so once I verify through that
and shell commands I can turn them off easily).

David
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Rebecca Cran
> Sent: Wednesday, February 08, 2017 6:56 PM
> To: Andrew Fish 
> Cc: edk2-de...@ml01.01.org; David A. Van Arnem 
> Subject: Re: [edk2] Print from DXE_DRIVER
> 
> 
>> On Feb 8, 2017, at 5:43 PM, Andrew Fish  wrote:
>>
>> If  you want to write directly to the UEFI Console you can try this. Place 
>> it in the entry point of your driver in case you have some bug that is 
>> preventing your from registering the Driver Binding Protocol. 
>>
>> gST->ConOut->OutputString (gST->ConOut, L"Hello World\n\r");
> 
> Note that on some systems, at some times gST->ConOut may be NULL, so it might 
> be worth checking before calling it (unless you know otherwise on your dev 
> system).
> 

-- 
Regards,
David Van Arnem
Development Engineer IV
Computer Measurement Laboratory, LLC

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

Re: [edk2] [PATCH v3 2/6] ArmVirtPkg: Resolve BmDmaLib class for PciHostBridgeDxe driver

[Ard Biesheuvel]

On 9 February 2017 at 19:33, Laszlo Ersek  wrote:
> On 02/09/17 18:56, Ard Biesheuvel wrote:
>> On 9 February 2017 at 16:40, Leo Duran  wrote:
>>> This patch adds the new DxeBmDmaLib (BmDmaLib class) library, which
>>> provides an abstraction layer for DMA operations implemented by the
>>> PciHostBridgeDxe driver.
>>>
>>> Cc: Laszlo Ersek 
>>> Cc: Ard Biesheuvel 
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Leo Duran 
>>> Reviewed-by: Laszlo Ersek 
>>
>> Laszlo already has this covered, but for redundancy (RAIM-1):
>^^
>
> I see what you did there. It's funny on three separate levels -- the pun
> as a whole, the letter "I" per se, and level "1" too.
>

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

Re: [edk2] [PATCH v4 6/6] MdePkg/Pci22.h: Deprecate out-of-Spec IncompatiblePciDevice macros

[Laszlo Ersek]

On 02/09/17 03:06, Ruiyu Ni wrote:
> DEVICE_ID_NOCARE is defined as 0x but Spec says (UINT64) -1
> should be used to match any VendorId/DeviceId/RevisionId/
> SubsystemVendorId/SubsystemDeviceId.
> 
> PCI_BAR_OLD_ALIGN/PCI_BAR_EVEN_ALIGN/PCI_BAR_SQUAD_ALIGN/
> PCI_BAR_DQUAD_ALIGN are defined but Spec doesn't have such
> definitions.
> 
> PCI_BAR_ALL is defined as 0xFF but Spec says (UINT64)-1 should be
> used to match all BARs.
> 
> PCI_ACPI_UNUSED and PCI_BAR_NOCHANGE are defined as 0 which
> compliant with Spec but the name is too general and causes confusing.
> IncompatiblePciDeviceSupport could directly use 0.
> 
> All of the above macros are marked as deprecated.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Liming Gao 
> Cc: Jeff Fan 
> ---
>  MdePkg/Include/IndustryStandard/Pci22.h | 27 ++-
>  1 file changed, 18 insertions(+), 9 deletions(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Pci22.h 
> b/MdePkg/Include/IndustryStandard/Pci22.h
> index 4cf8389..07718dc 100644
> --- a/MdePkg/Include/IndustryStandard/Pci22.h
> +++ b/MdePkg/Include/IndustryStandard/Pci22.h
> @@ -7,7 +7,7 @@
>  PC Card Standard, 8.0
>  PCI Power Management Interface Specifiction, Revision 1.2
>  
> -  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
>Copyright (c) 2014 - 2015, Hewlett-Packard Development Company, L.P.
>This program and the accompanying materials  
>are licensed and made available under the terms and conditions of the BSD 
> License 
> @@ -780,14 +780,24 @@ typedef struct {
>///
>  } EFI_PCI_CAPABILITY_HOTPLUG;
>  
> -#define DEVICE_ID_NOCARE0x
> +///
> +/// Below macros (till PCI_BAR_NOCHANGE) were used by 
> EfiIncompatiblePciDeviceSupport Protocol.
> +///
> +#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
> +
> +///
> +/// [ATTENTION] These macros are deprecated because they don't match Spec or 
> not defined in Spec.
> +///
> +#define DEVICE_ID_NOCARE0x ///< Deprecated. Value 
> doesn't match Spec.
> +#define PCI_BAR_OLD_ALIGN   0xULL  ///< Deprecated. Value 
> isn't defined in Spec.
> +#define PCI_BAR_EVEN_ALIGN  0xFFFEULL  ///< Deprecated. Value 
> isn't defined in Spec.
> +#define PCI_BAR_SQUAD_ALIGN 0xFFFDULL  ///< Deprecated. Value 
> isn't defined in Spec.
> +#define PCI_BAR_DQUAD_ALIGN 0xFFFCULL  ///< Deprecated. Value 
> isn't defined in Spec.
> +#define PCI_BAR_ALL 0xFF   ///< Deprecated. Value 
> doesn't match Spec.
> +#define PCI_ACPI_UNUSED 0  ///< Deprecated. Macro 
> name is too general.
> +#define PCI_BAR_NOCHANGE0  ///< Deprecated. Macro 
> name is too general.
>  
> -#define PCI_ACPI_UNUSED 0
> -#define PCI_BAR_NOCHANGE0
> -#define PCI_BAR_OLD_ALIGN   0xULL
> -#define PCI_BAR_EVEN_ALIGN  0xFFFEULL
> -#define PCI_BAR_SQUAD_ALIGN 0xFFFDULL
> -#define PCI_BAR_DQUAD_ALIGN 0xFFFCULL
> +#endif
>  
>  #define PCI_BAR_IDX00x00
>  #define PCI_BAR_IDX10x01
> @@ -795,7 +805,6 @@ typedef struct {
>  #define PCI_BAR_IDX30x03
>  #define PCI_BAR_IDX40x04
>  #define PCI_BAR_IDX50x05
> -#define PCI_BAR_ALL 0xFF
>  
>  ///
>  /// EFI PCI Option ROM definitions
> 

I didn't try to verify the macros one by one, but I agree that relative
to the previous version (*), the patch is now complete (PCI_ACPI_UNUSED
and PCI_BAR_NOCHANGE are covered).

Acked-by: Laszlo Ersek 

(*) It's not easy to identify the previous version, because both that
one and this one are marked as "[PATCH v4 6/6]".

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

Re: [edk2] [PATCH v3 2/6] ArmVirtPkg: Resolve BmDmaLib class for PciHostBridgeDxe driver

[Laszlo Ersek]

On 02/09/17 18:56, Ard Biesheuvel wrote:
> On 9 February 2017 at 16:40, Leo Duran  wrote:
>> This patch adds the new DxeBmDmaLib (BmDmaLib class) library, which
>> provides an abstraction layer for DMA operations implemented by the
>> PciHostBridgeDxe driver.
>>
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Leo Duran 
>> Reviewed-by: Laszlo Ersek 
> 
> Laszlo already has this covered, but for redundancy (RAIM-1):
   ^^

I see what you did there. It's funny on three separate levels -- the pun
as a whole, the letter "I" per se, and level "1" too.

I'm impressed! :)

Laszlo

> 
> Reviewed-by: Ard Biesheuvel 



> 
>> ---
>>  ArmVirtPkg/ArmVirtQemu.dsc   | 1 +
>>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 +
>>  2 files changed, 2 insertions(+)
>>
>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>> index 8fe3c38..d318f82 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>> @@ -59,6 +59,7 @@ [LibraryClasses.common]
>>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>>NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
>>
>> +  BmDmaLib|MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf
>>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>>
>> UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
>>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
>> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
>> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
>> index aa40374..721d78a 100644
>> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
>> @@ -58,6 +58,7 @@ [LibraryClasses.common]
>>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>>NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
>>
>> +  BmDmaLib|MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf
>>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>>
>> UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
>>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
>> --
>> 1.9.1
>>

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

[edk2] [PATCH 2/4] ArmPkg/ArmGicDxe: expose HardwareInterrupt2 protocol

[evan . lloyd]

From: Ard Biesheuvel 

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Girish Pathak 
Signed-off-by: Evan Lloyd 
Tested-by: Girish Pathak 
---
 ArmPkg/Drivers/ArmGic/ArmGicDxe.inf   |  1 +
 ArmPkg/Drivers/ArmGic/ArmGicDxe.h |  2 ++
 ArmPkg/Drivers/ArmGic/ArmGicCommonDxe.c   |  2 ++
 ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c | 38 +++-
 ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 37 ++-
 5 files changed, 78 insertions(+), 2 deletions(-)

diff --git a/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf 
b/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
index 
e554301c4b28022c805f69242cf6ee979d19abc2..69390638a9afb6aeccad510e7b572450568c1409
 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
+++ b/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
@@ -48,6 +48,7 @@ [LibraryClasses]
 
 [Protocols]
   gHardwareInterruptProtocolGuid
+  gHardwareInterrupt2ProtocolGuid
   gEfiCpuArchProtocolGuid
 
 [Pcd.common]
diff --git a/ArmPkg/Drivers/ArmGic/ArmGicDxe.h 
b/ArmPkg/Drivers/ArmGic/ArmGicDxe.h
index 
af33aa90b00c6775e10a831d63ed707394862362..2633e1ea194fa67511861a4165d54dad99a6f39b
 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicDxe.h
+++ b/ArmPkg/Drivers/ArmGic/ArmGicDxe.h
@@ -24,6 +24,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include 
 #include 
+#include 
 
 extern UINTNmGicNumInterrupts;
 extern HARDWARE_INTERRUPT_HANDLER  *gRegisteredInterruptHandlers;
@@ -34,6 +35,7 @@ extern HARDWARE_INTERRUPT_HANDLER  
*gRegisteredInterruptHandlers;
 EFI_STATUS
 InstallAndRegisterInterruptService (
   IN EFI_HARDWARE_INTERRUPT_PROTOCOL   *InterruptProtocol,
+  IN EFI_HARDWARE_INTERRUPT2_PROTOCOL  *Interrupt2Protocol,
   IN EFI_CPU_INTERRUPT_HANDLER  InterruptHandler,
   IN EFI_EVENT_NOTIFY   ExitBootServicesEvent
   );
diff --git a/ArmPkg/Drivers/ArmGic/ArmGicCommonDxe.c 
b/ArmPkg/Drivers/ArmGic/ArmGicCommonDxe.c
index 
be77b8361c5af033fd2889cdb48902af867f321d..ef6746f1ad7afba5bba30fc17774987cf17121b6
 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicCommonDxe.c
+++ b/ArmPkg/Drivers/ArmGic/ArmGicCommonDxe.c
@@ -88,6 +88,7 @@ RegisterInterruptSource (
 EFI_STATUS
 InstallAndRegisterInterruptService (
   IN EFI_HARDWARE_INTERRUPT_PROTOCOL   *InterruptProtocol,
+  IN EFI_HARDWARE_INTERRUPT2_PROTOCOL  *Interrupt2Protocol,
   IN EFI_CPU_INTERRUPT_HANDLER  InterruptHandler,
   IN EFI_EVENT_NOTIFY   ExitBootServicesEvent
   )
@@ -104,6 +105,7 @@ InstallAndRegisterInterruptService (
   Status = gBS->InstallMultipleProtocolInterfaces (
   ,
   , InterruptProtocol,
+  , Interrupt2Protocol,
   NULL
   );
   if (EFI_ERROR (Status)) {
diff --git a/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c 
b/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
index 
b9ecd5543a3e2e0b00fffbcf5543a60567bb5dde..8c4d66125e2e8c7af9898f336ee742ed0aebf058
 100644
--- a/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
+++ b/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
@@ -193,6 +193,41 @@ EFI_HARDWARE_INTERRUPT_PROTOCOL 
gHardwareInterruptV2Protocol = {
   GicV2EndOfInterrupt
 };
 
+STATIC
+EFI_STATUS
+EFIAPI
+GicV2GetTriggerType (
+  IN  EFI_HARDWARE_INTERRUPT2_PROTOCOL  *This,
+  IN  HARDWARE_INTERRUPT_SOURCE Source,
+  OUT EFI_HARDWARE_INTERRUPT2_TRIGGER_TYPE  *TriggerType
+  )
+{
+  return EFI_SUCCESS;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+GicV2SetTriggerType (
+  IN  EFI_HARDWARE_INTERRUPT2_PROTOCOL  *This,
+  IN  HARDWARE_INTERRUPT_SOURCE Source,
+  IN  EFI_HARDWARE_INTERRUPT2_TRIGGER_TYPE  TriggerType
+  )
+{
+  return EFI_SUCCESS;
+}
+
+STATIC EFI_HARDWARE_INTERRUPT2_PROTOCOL gHardwareInterrupt2V2Protocol = {
+  (HARDWARE_INTERRUPT2_REGISTER)RegisterInterruptSource,
+  (HARDWARE_INTERRUPT2_ENABLE)GicV2EnableInterruptSource,
+  (HARDWARE_INTERRUPT2_DISABLE)GicV2DisableInterruptSource,
+  (HARDWARE_INTERRUPT2_INTERRUPT_STATE)GicV2GetInterruptSourceState,
+  (HARDWARE_INTERRUPT2_END_OF_INTERRUPT)GicV2EndOfInterrupt,
+  GicV2GetTriggerType,
+  GicV2SetTriggerType
+};
+
+
 /**
   Shutdown our hardware
 
@@ -311,7 +346,8 @@ GicV2DxeInitialize (
   ArmGicEnableDistributor (mGicDistributorBase);
 
   Status = InstallAndRegisterInterruptService (
-  , GicV2IrqInterruptHandler, 
GicV2ExitBootServicesEvent);
+ , ,
+ GicV2IrqInterruptHandler, GicV2ExitBootServicesEvent);
 
   return Status;
 }
diff --git a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c 
b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
index 
8af97a93b1889b33978a7c7fb2a8417c83139142..02deeef78b6d7737172a5992c6decac43cfdd64a
 100644
--- a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
+++ b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
@@ -184,6 +184,40 @@ EFI_HARDWARE_INTERRUPT_PROTOCOL 
gHardwareInterruptV3Protocol = {
   

[edk2] [PATCH 3/4] ArmPkg/GenericWatchdogDxe: Set Watchdog interrupt type

[evan . lloyd]

From: Ard Biesheuvel 

Utilise the new HardwareInterrupt2 protocol to adjust the
Edje/Level characteristics of the Watchdog interrupt.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Girish Pathak 
Signed-off-by: Evan Lloyd 
Tested-by: Girish Pathak 
---
 ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf |  4 +--
 ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c   | 27 

 2 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf 
b/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
index 
fece14cc18315cd15510680c438288687b60c018..51d5c0042d84333b9fe66547c99a8d8ed987f175
 100644
--- a/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
+++ b/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
@@ -47,7 +47,7 @@ [Pcd.common]
 
 [Protocols]
   gEfiWatchdogTimerArchProtocolGuid
-  gHardwareInterruptProtocolGuid
+  gHardwareInterrupt2ProtocolGuid
 
 [Depex]
-  gHardwareInterruptProtocolGuid
+  gHardwareInterrupt2ProtocolGuid
diff --git a/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c 
b/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c
index 
54a1625a32137556b58fa93ddf7fbe4d0f22c786..9ba9bf79c961b52dc9b448039a9186e069fc29f7
 100644
--- a/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c
+++ b/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c
@@ -25,7 +25,8 @@
 #include 
 
 #include 
-#include 
+
+#include 
 
 #include "GenericWatchdog.h"
 
@@ -41,7 +42,7 @@ UINTN mTimerFrequencyHz = 0;
 // It is therefore stored here. 0 means the timer is not running.
 UINT64 mNumTimerTicks = 0;
 
-EFI_HARDWARE_INTERRUPT_PROTOCOL *mInterruptProtocol;
+EFI_HARDWARE_INTERRUPT2_PROTOCOL *mInterruptProtocol;
 
 EFI_STATUS
 WatchdogWriteOffsetRegister (
@@ -320,7 +321,7 @@ GenericWatchdogEntry (
   if (!EFI_ERROR (Status)) {
 // Install interrupt handler
 Status = gBS->LocateProtocol (
-,
+,
 NULL,
 (VOID **)
 );
@@ -331,13 +332,19 @@ GenericWatchdogEntry (
 WatchdogInterruptHandler
 );
   if (!EFI_ERROR (Status)) {
-// Install the Timer Architectural Protocol onto a new handle
-Handle = NULL;
-Status = gBS->InstallMultipleProtocolInterfaces (
-,
-, ,
-NULL
-);
+Status = mInterruptProtocol->SetTriggerType (
+mInterruptProtocol,
+FixedPcdGet32 
(PcdGenericWatchdogEl2IntrNum),
+
EFI_HARDWARE_INTERRUPT2_TRIGGER_EDGE_RISING);
+if (!EFI_ERROR (Status)) {
+  // Install the Timer Architectural Protocol onto a new handle
+  Handle = NULL;
+  Status = gBS->InstallMultipleProtocolInterfaces (
+  ,
+  , ,
+  NULL
+  );
+  }
   }
 }
   }
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

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

[edk2] [PATCH 4/4] ArmPkg:Provide GetTriggerType/SetTriggerType functions

[evan . lloyd]

From: Girish Pathak 

This change implements GetTriggerType and SetTriggerType functions
in ArmGicV2Dxe (GicV2GetTriggerType/GicV2SetTriggerType)
and ArmGicV3Dxe (GicV3GetTriggerType/GicV3SetTriggerType)

SetTriggerType configures the interrupt mode of an interrupt
as edge sensitive or level sensitive.

GetTriggerType function returns the mode of an interrupt.

The requirement for this change derives from a problem detected on ARM
Juno boards, but the change is of generic relevance.

NOTE: At this point the GICv3 code is not tested.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Girish Pathak 
Signed-off-by: Evan Lloyd 
Tested-by: Girish Pathak 
---
 ArmPkg/Include/Library/ArmGicLib.h|   4 +
 ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c | 165 ++--
 ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 159 +--
 3 files changed, 308 insertions(+), 20 deletions(-)

diff --git a/ArmPkg/Include/Library/ArmGicLib.h 
b/ArmPkg/Include/Library/ArmGicLib.h
index 
4364f3ffef464596f64cf59881d703cf54cf0ddd..6610f356c20e73d84ff3ba519956b426d97ef1eb
 100644
--- a/ArmPkg/Include/Library/ArmGicLib.h
+++ b/ArmPkg/Include/Library/ArmGicLib.h
@@ -51,6 +51,10 @@
 #define ARM_GIC_ICDDCR_ARE  (1 << 4) // Affinity Routing Enable (ARE)
 #define ARM_GIC_ICDDCR_DS   (1 << 6) // Disable Security (DS)
 
+// GICD_ICDICFR bits
+#define ARM_GIC_ICDICFR_LEVEL_TRIGGERED  0x0 // Level triggered interrupt
+#define ARM_GIC_ICDICFR_EDGE_TRIGGERED   0x1 // Edge triggered interrupt
+
 //
 // GIC Redistributor
 //
diff --git a/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c 
b/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
index 
8c4d66125e2e8c7af9898f336ee742ed0aebf058..1f47403c6cdc7e8c0f6ac65d3b95a562da6a2d32
 100644
--- a/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
+++ b/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
@@ -29,6 +29,7 @@ Abstract:
 #define ARM_GIC_DEFAULT_PRIORITY  0x80
 
 extern EFI_HARDWARE_INTERRUPT_PROTOCOL gHardwareInterruptV2Protocol;
+extern EFI_HARDWARE_INTERRUPT2_PROTOCOL gHardwareInterrupt2V2Protocol;
 
 STATIC UINT32 mGicInterruptInterfaceBase;
 STATIC UINT32 mGicDistributorBase;
@@ -193,19 +194,95 @@ EFI_HARDWARE_INTERRUPT_PROTOCOL 
gHardwareInterruptV2Protocol = {
   GicV2EndOfInterrupt
 };
 
+/**
+  Calculate GICD_ICFGRn base address and corresponding bit
+  field Int_config[1] of the GIC distributor register.
+
+  @param Source   Hardware source of the interrupt.
+  @param RegAddress   Corresponding GICD_ICFGRn base address.
+  @param BitNumberBit number in the register to set/reset.
+
+  @retval EFI_SUCCESS   Source interrupt supported.
+  @retval EFI_UNSUPPORTED   Source interrupt is not supported.
+**/
 STATIC
 EFI_STATUS
+GicGetDistributorIntrCfgBaseAndBitField (
+  IN HARDWARE_INTERRUPT_SOURCE Source,
+  OUT UINTN   *RegAddress,
+  OUT UINTN   *BitNumber
+  )
+{
+  UINTN  RegOffset;
+  UINTN  Field;
+
+  if (Source >= mGicNumInterrupts) {
+ASSERT(Source < mGicNumInterrupts);
+return EFI_UNSUPPORTED;
+  }
+
+  RegOffset = Source / 16;
+  Field = Source % 16;
+  *RegAddress = PcdGet64 (PcdGicDistributorBase)
+  + ARM_GIC_ICDICFR
+  + (4 * RegOffset);
+  *BitNumber = (Field * 2) + 1;
+
+  return EFI_SUCCESS;
+}
+
+/**
+  Get interrupt trigger type of an interrupt
+
+  @param This  Instance pointer for this protocol
+  @param SourceHardware source of the interrupt.
+  @param TriggerType   Returns interrupt trigger type.
+
+  @retval EFI_SUCCESS   Source interrupt supported.
+  @retval EFI_UNSUPPORTED   Source interrupt is not supported.
+**/
+EFI_STATUS
 EFIAPI
 GicV2GetTriggerType (
   IN  EFI_HARDWARE_INTERRUPT2_PROTOCOL  *This,
-  IN  HARDWARE_INTERRUPT_SOURCE Source,
+  IN  HARDWARE_INTERRUPT_SOURCE  Source,
   OUT EFI_HARDWARE_INTERRUPT2_TRIGGER_TYPE  *TriggerType
   )
 {
+  UINTN   RegAddress;
+  UINTN   BitNumber;
+  EFI_STATUS  Status;
+
+  RegAddress = 0;
+  BitNumber  = 0;
+
+  Status = GicGetDistributorIntrCfgBaseAndBitField (
+  Source,
+  ,
+  
+  );
+
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  *TriggerType = (MmioBitFieldRead32 (RegAddress, BitNumber, BitNumber) == 0)
+ ?  EFI_HARDWARE_INTERRUPT2_TRIGGER_LEVEL_HIGH
+ :  EFI_HARDWARE_INTERRUPT2_TRIGGER_EDGE_RISING;
+
   return EFI_SUCCESS;
 }
 
-STATIC
+/**
+  Set interrupt trigger type of an interrupt
+
+  @param This  Instance pointer for this protocol
+  @param SourceHardware source of the interrupt.
+  @param TriggerType   Interrupt trigger type.
+
+  @retval EFI_SUCCESS   Source interrupt supported.
+  @retval EFI_UNSUPPORTED   Source interrupt is not supported.

[edk2] [PATCH 1/4] EmbeddedPkg: introduce HardwareInterrupt2 protocol

[evan . lloyd]

From: Ard Biesheuvel 

The existing HardwareInterrupt protocol lacks the method to configure
the level/edge and polarity properties of an interrupt. So introduce a
new protocol HardwareInterrupt2, and add some new members that allow the
manipulation of those properties.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Girish Pathak 
Signed-off-by: Evan Lloyd 
Tested-by: Girish Pathak 
---
 EmbeddedPkg/EmbeddedPkg.dec   |   1 +
 EmbeddedPkg/Include/Protocol/HardwareInterrupt2.h | 181 
 2 files changed, 182 insertions(+)

diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
index 
2c2cf41103c282103c2a83ad9a105d0f6ac2e9a3..2464f715e68c8e0eb1214c0170fb040830b88f06
 100644
--- a/EmbeddedPkg/EmbeddedPkg.dec
+++ b/EmbeddedPkg/EmbeddedPkg.dec
@@ -58,6 +58,7 @@ [Guids.common]
 
 [Protocols.common]
   gHardwareInterruptProtocolGuid =  { 0x2890B3EA, 0x053D, 0x1643, { 0xAD, 
0x0C, 0xD6, 0x48, 0x08, 0xDA, 0x3F, 0xF1 } }
+  gHardwareInterrupt2ProtocolGuid = { 0x32898322, 0x2da1, 0x474a, { 0xba, 
0xaa, 0xf3, 0xf7, 0xcf, 0x56, 0x94, 0x70 } }
   gEfiDebugSupportPeriodicCallbackProtocolGuid = { 0x9546e07c, 0x2cbb, 0x4c88, 
{ 0x98, 0x6c, 0xcd, 0x34, 0x10, 0x86, 0xf0, 0x44 } }
   gEfiEblAddCommandProtocolGuid =   { 0xaeda2428, 0x9a22, 0x4637, { 0x9b, 
0x21, 0x54, 0x5e, 0x28, 0xfb, 0xb8, 0x29 } }
   gEmbeddedDeviceGuid =   { 0xbf4b9d10, 0x13ec, 0x43dd, { 0x88, 0x80, 0xe9, 
0xb, 0x71, 0x8f, 0x27, 0xde } }
diff --git a/EmbeddedPkg/Include/Protocol/HardwareInterrupt2.h 
b/EmbeddedPkg/Include/Protocol/HardwareInterrupt2.h
new file mode 100644
index 
..61acdaac4341951b8c1916858490a815cf94dc99
--- /dev/null
+++ b/EmbeddedPkg/Include/Protocol/HardwareInterrupt2.h
@@ -0,0 +1,181 @@
+/** @file
+
+  Copyright (c) 2016, 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 __HARDWARE_INTERRUPT2_H__
+#define __HARDWARE_INTERRUPT2_H__
+
+#include 
+
+// 22838932-1a2d-4a47-aaba-f3f7cf569470
+
+#define EFI_HARDWARE_INTERRUPT2_PROTOCOL_GUID \
+  { 0x32898322, 0x2da1, 0x474a, { 0xba, 0xaa, 0xf3, 0xf7, 0xcf, 0x56, 0x94, 
0x70 } }
+
+typedef enum {
+  EFI_HARDWARE_INTERRUPT2_TRIGGER_LEVEL_LOW,
+  EFI_HARDWARE_INTERRUPT2_TRIGGER_LEVEL_HIGH,
+  EFI_HARDWARE_INTERRUPT2_TRIGGER_EDGE_FALLING,
+  EFI_HARDWARE_INTERRUPT2_TRIGGER_EDGE_RISING,
+} EFI_HARDWARE_INTERRUPT2_TRIGGER_TYPE;
+
+typedef struct _EFI_HARDWARE_INTERRUPT2_PROTOCOL 
EFI_HARDWARE_INTERRUPT2_PROTOCOL;
+
+/**
+  Register Handler for the specified interrupt source.
+
+  @param This Instance pointer for this protocol
+  @param Source   Hardware source of the interrupt
+  @param Handler  Callback for interrupt. NULL to unregister
+
+  @retval EFI_SUCCESS Source was updated to support Handler.
+  @retval EFI_DEVICE_ERROR  Hardware could not be programmed.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *HARDWARE_INTERRUPT2_REGISTER) (
+  IN EFI_HARDWARE_INTERRUPT2_PROTOCOL*This,
+  IN HARDWARE_INTERRUPT_SOURCE  Source,
+  IN HARDWARE_INTERRUPT_HANDLER Handler
+  );
+
+
+/**
+  Enable interrupt source Source.
+
+  @param This Instance pointer for this protocol
+  @param Source   Hardware source of the interrupt
+
+  @retval EFI_SUCCESS   Source interrupt enabled.
+  @retval EFI_DEVICE_ERROR  Hardware could not be programmed.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *HARDWARE_INTERRUPT2_ENABLE) (
+  IN EFI_HARDWARE_INTERRUPT2_PROTOCOL*This,
+  IN HARDWARE_INTERRUPT_SOURCE  Source
+  );
+
+
+
+/**
+  Disable interrupt source Source.
+
+  @param This Instance pointer for this protocol
+  @param Source   Hardware source of the interrupt
+
+  @retval EFI_SUCCESS   Source interrupt disabled.
+  @retval EFI_DEVICE_ERROR  Hardware could not be programmed.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *HARDWARE_INTERRUPT2_DISABLE) (
+  IN EFI_HARDWARE_INTERRUPT2_PROTOCOL*This,
+  IN HARDWARE_INTERRUPT_SOURCE  Source
+  );
+
+
+/**
+  Return current state of interrupt source Source.
+
+  @param This Instance pointer for this protocol
+  @param Source   Hardware source of the interrupt
+  @param InterruptState  TRUE: source enabled, FALSE: source disabled.
+
+  @retval EFI_SUCCESS   InterruptState is valid
+  @retval EFI_DEVICE_ERROR  InterruptState is not valid
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *HARDWARE_INTERRUPT2_INTERRUPT_STATE) (
+  IN 

[edk2] [PATCH 0/4] HardwareInterrupt2 protocol

[evan . lloyd]

From: Evan Lloyd 

This series of patches corrects a problem detected on the ARM Juno
platform that is actually generic (at least to ARM GIC platforms).
The HardwareInterrupt protocol had no means of handling characteristics
like Edge/Level triggered and polarity.

A new HardwareInterrupt2 protocol (provided by Ard) is added,
and code changed to utilise the new capabilities.

The code is available for examination on Github at:
https://github.com/EvanLloyd/tianocore/tree/376_irqtype_v1

Ard Biesheuvel (3):
  EmbeddedPkg: introduce HardwareInterrupt2 protocol
  ArmPkg/ArmGicDxe: expose HardwareInterrupt2 protocol
  ArmPkg/GenericWatchdogDxe: Set Watchdog interrupt type

Girish Pathak (1):
  ArmPkg:Provide GetTriggerType/SetTriggerType functions

 EmbeddedPkg/EmbeddedPkg.dec  |   1 +
 ArmPkg/Drivers/ArmGic/ArmGicDxe.inf  |   1 +
 ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf |   4 +-
 ArmPkg/Drivers/ArmGic/ArmGicDxe.h|   2 +
 ArmPkg/Include/Library/ArmGicLib.h   |   4 +
 EmbeddedPkg/Include/Protocol/HardwareInterrupt2.h| 181 

 ArmPkg/Drivers/ArmGic/ArmGicCommonDxe.c  |   2 +
 ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c| 181 
+++-
 ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c| 178 
++-
 ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c   |  27 +--
 10 files changed, 567 insertions(+), 14 deletions(-)
 create mode 100644 EmbeddedPkg/Include/Protocol/HardwareInterrupt2.h

-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

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

Re: [edk2] [PATCH v3 2/6] ArmVirtPkg: Resolve BmDmaLib class for PciHostBridgeDxe driver

[Ard Biesheuvel]

On 9 February 2017 at 16:40, Leo Duran  wrote:
> This patch adds the new DxeBmDmaLib (BmDmaLib class) library, which
> provides an abstraction layer for DMA operations implemented by the
> PciHostBridgeDxe driver.
>
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Leo Duran 
> Reviewed-by: Laszlo Ersek 

Laszlo already has this covered, but for redundancy (RAIM-1):

Reviewed-by: Ard Biesheuvel 

> ---
>  ArmVirtPkg/ArmVirtQemu.dsc   | 1 +
>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 8fe3c38..d318f82 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -59,6 +59,7 @@ [LibraryClasses.common]
>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
>
> +  BmDmaLib|MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>
> UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index aa40374..721d78a 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -58,6 +58,7 @@ [LibraryClasses.common]
>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
>
> +  BmDmaLib|MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>
> UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> --
> 1.9.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 4/4] ArmPkg/ArmMmuLib: AARCH64: add support for modifying only permissions

[Ard Biesheuvel]

Since the new DXE page protection for PE/COFF images may invoke
EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes() with only permission
attributes set, add support for this in the AARCH64 MMU code.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 73 +++-
 1 file changed, 56 insertions(+), 17 deletions(-)

diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c 
b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
index 6aa970bc0514..764e54b5d747 100644
--- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
+++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
@@ -28,6 +28,10 @@
 // We use this index definition to define an invalid block entry
 #define TT_ATTR_INDX_INVALID((UINT32)~0)
 
+#define EFI_MEMORY_CACHETYPE_MASK   (EFI_MEMORY_UC | EFI_MEMORY_WC | \
+ EFI_MEMORY_WT | EFI_MEMORY_WB | \
+ EFI_MEMORY_UCE)
+
 STATIC
 UINT64
 ArmMemoryAttributeToPageAttribute (
@@ -101,25 +105,46 @@ PageAttributeToGcdAttribute (
   return GcdAttributes;
 }
 
-ARM_MEMORY_REGION_ATTRIBUTES
-GcdAttributeToArmAttribute (
+STATIC
+UINT64
+GcdAttributeToPageAttribute (
   IN UINT64 GcdAttributes
   )
 {
-  switch (GcdAttributes & 0xFF) {
+  UINT64 PageAttributes;
+
+  switch (GcdAttributes & EFI_MEMORY_CACHETYPE_MASK) {
   case EFI_MEMORY_UC:
-return ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
+PageAttributes = TT_ATTR_INDX_DEVICE_MEMORY;
+break;
   case EFI_MEMORY_WC:
-return ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
+PageAttributes = TT_ATTR_INDX_MEMORY_NON_CACHEABLE;
+break;
   case EFI_MEMORY_WT:
-return ARM_MEMORY_REGION_ATTRIBUTE_WRITE_THROUGH;
+PageAttributes = TT_ATTR_INDX_MEMORY_WRITE_THROUGH | TT_SH_INNER_SHAREABLE;
+break;
   case EFI_MEMORY_WB:
-return ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
+PageAttributes = TT_ATTR_INDX_MEMORY_WRITE_BACK | TT_SH_INNER_SHAREABLE;
+break;
   default:
-DEBUG ((EFI_D_ERROR, "GcdAttributeToArmAttribute: 0x%lX attributes is not 
supported.\n", GcdAttributes));
-ASSERT (0);
-return ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
+PageAttributes = TT_ATTR_INDX_MASK;
+break;
   }
+
+  if ((GcdAttributes & EFI_MEMORY_XP) != 0 ||
+  (GcdAttributes & EFI_MEMORY_CACHETYPE_MASK) == EFI_MEMORY_UC) {
+if (ArmReadCurrentEL () == AARCH64_EL2) {
+  PageAttributes |= TT_XN_MASK;
+} else {
+  PageAttributes |= TT_UXN_MASK | TT_PXN_MASK;
+}
+  }
+
+  if ((GcdAttributes & EFI_MEMORY_RO) != 0) {
+PageAttributes |= TT_AP_RO_RO;
+  }
+
+  return PageAttributes | TT_AF;
 }
 
 #define MIN_T0SZ16
@@ -434,17 +459,31 @@ SetMemoryAttributes (
   )
 {
   RETURN_STATUSStatus;
-  ARM_MEMORY_REGION_DESCRIPTOR MemoryRegion;
   UINT64  *TranslationTable;
-
-  MemoryRegion.PhysicalBase = BaseAddress;
-  MemoryRegion.VirtualBase = BaseAddress;
-  MemoryRegion.Length = Length;
-  MemoryRegion.Attributes = GcdAttributeToArmAttribute (Attributes);
+  UINT64   PageAttributes;
+  UINT64   PageAttributeMask;
+
+  PageAttributes = GcdAttributeToPageAttribute (Attributes);
+  PageAttributeMask = 0;
+
+  if ((Attributes & EFI_MEMORY_CACHETYPE_MASK) == 0) {
+//
+// No memory type was set in Attributes, so we are going to update the
+// permissions only.
+//
+PageAttributes &= TT_AP_MASK | TT_UXN_MASK | TT_PXN_MASK;
+PageAttributeMask = ~(TT_ADDRESS_MASK_BLOCK_ENTRY | TT_AP_MASK |
+  TT_PXN_MASK | TT_XN_MASK);
+  }
 
   TranslationTable = ArmGetTTBR0BaseAddress ();
 
-  Status = FillTranslationTable (TranslationTable, );
+  Status = UpdateRegionMapping (
+ TranslationTable,
+ BaseAddress,
+ Length,
+ PageAttributes,
+ PageAttributeMask);
   if (RETURN_ERROR (Status)) {
 return Status;
   }
-- 
2.7.4

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

[edk2] [PATCH 3/4] ArmPkg/CpuDxe: ARM: ignore page table updates that only change permissions

[Ard Biesheuvel]

Currently, we have not implemented support on 32-bit ARM for managing
permission bits in the page tables. Since the new DXE page protection
for PE/COFF images may invoke EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes()
with only permission attributes set, let's simply ignore those for now.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Drivers/CpuDxe/Arm/Mmu.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
index b6ba975b353a..89e429925ba9 100644
--- a/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
+++ b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
@@ -680,6 +680,13 @@ SetMemoryAttributes (
 {
   EFI_STATUSStatus;
 
+  //
+  // Ignore invocations that only modify permission bits
+  //
+  if ((Attributes & EFI_MEMORY_CACHETYPE_MASK) == 0) {
+return EFI_SUCCESS;
+  }
+
   if(((BaseAddress & 0xF) == 0) && ((Length & 0xF) == 0)) {
 // Is the base and length a multiple of 1 MB?
 DEBUG ((EFI_D_PAGE, "SetMemoryAttributes(): MMU section 0x%x length 0x%x 
to %lx\n", (UINTN)BaseAddress, (UINTN)Length, Attributes));
-- 
2.7.4

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

[edk2] [PATCH 2/4] ArmPkg/CpuDxe: translate invalid memory types in EfiAttributeToArmAttribute

[Ard Biesheuvel]

The single user of EfiAttributeToArmAttribute () is the protocol
method EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes(), which uses the
return value to compare against the ARM attributes of an existing mapping,
to infer whether it is actually necessary to change anything, or whether
the requested update is redundant. This saves some cache and TLB
maintenance on 32-bit ARM systems that use uncached translation tables.

However, EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes() may be invoked with
only permission bits set, in which case the implied requested action is to
update the permissions of the region without modifying the cacheability
attributes. This is currently not possible, because
EfiAttributeToArmAttribute () ASSERT()s [on AArch64] on Attributes arguments
that lack a cacheability bit.

So let's simply return TT_ATTR_INDX_INVALID (AArch64) or
TT_DESCRIPTOR_SECTION_TYPE_FAULT (ARM) in these cases (or'ed with the
appropriate permission bits). This way, the return value is equally
suitable for checking whether the attributes need to be modified, but
in a way that accommodates the use without a cacheability bit set.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c | 4 +---
 ArmPkg/Drivers/CpuDxe/Arm/Mmu.c | 3 ---
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c 
b/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c
index 15d5a8173233..7688846e70cb 100644
--- a/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c
+++ b/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c
@@ -216,9 +216,7 @@ EfiAttributeToArmAttribute (
 ArmAttributes = TT_ATTR_INDX_MEMORY_WRITE_BACK;
 break;
   default:
-DEBUG ((EFI_D_ERROR, "EfiAttributeToArmAttribute: 0x%lX attributes is not 
supported.\n", EfiAttributes));
-ASSERT (0);
-ArmAttributes = TT_ATTR_INDX_DEVICE_MEMORY;
+ArmAttributes = TT_ATTR_INDX_MASK;
   }
 
   // Set the access flag to match the block attributes
diff --git a/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
index 6dcfba69e879..b6ba975b353a 100644
--- a/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
+++ b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
@@ -733,10 +733,7 @@ EfiAttributeToArmAttribute (
 
 case EFI_MEMORY_UCE:
 default:
-  // Cannot be implemented UEFI definition unclear for ARM
-  // Cause a page fault if these ranges are accessed.
   ArmAttributes = TT_DESCRIPTOR_SECTION_TYPE_FAULT;
-  DEBUG ((EFI_D_PAGE, "SetMemoryAttributes(): Unsupported attribute %x 
will page fault on access\n", EfiAttributes));
   break;
   }
 
-- 
2.7.4

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

[edk2] [PATCH 1/4] ArmPkg/CpuDxe: Correct EFI_MEMORY_RO usage

[Ard Biesheuvel]

From: Jiewen Yao 

Current Arm CpuDxe driver uses EFI_MEMORY_WP for write protection,
according to UEFI spec, we should use EFI_MEMORY_RO for write protection.
The EFI_MEMORY_WP is the cache attribute instead of memory attribute.

Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c  |  3 ++-
 ArmPkg/Drivers/CpuDxe/Arm/Mmu.c  | 14 ++
 ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c |  5 +++--
 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c |  3 ++-
 4 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c 
b/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c
index d8bb41978066..15d5a8173233 100644
--- a/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c
+++ b/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c
@@ -3,6 +3,7 @@
 Copyright (c) 2009, Hewlett-Packard Company. All rights reserved.
 Portions copyright (c) 2010, Apple Inc. All rights reserved.
 Portions copyright (c) 2011-2013, ARM Ltd. All rights reserved.
+Copyright (c) 2017, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
@@ -224,7 +225,7 @@ EfiAttributeToArmAttribute (
   ArmAttributes |= TT_AF;
 
   // Determine protection attributes
-  if (EfiAttributes & EFI_MEMORY_WP) {
+  if (EfiAttributes & EFI_MEMORY_RO) {
 ArmAttributes |= TT_AP_RO_RO;
   }
 
diff --git a/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
index 14fc22d7a59f..6dcfba69e879 100644
--- a/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
+++ b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
@@ -3,6 +3,7 @@
 Copyright (c) 2009, Hewlett-Packard Company. All rights reserved.
 Portions copyright (c) 2010, Apple Inc. All rights reserved.
 Portions copyright (c) 2013, ARM Ltd. All rights reserved.
+Copyright (c) 2017, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
@@ -62,7 +63,7 @@ SectionToGcdAttributes (
   // determine protection attributes
   switch(SectionAttributes & TT_DESCRIPTOR_SECTION_AP_MASK) {
 case TT_DESCRIPTOR_SECTION_AP_NO_NO: // no read, no write
-  //*GcdAttributes |= EFI_MEMORY_WP | EFI_MEMORY_RP;
+  //*GcdAttributes |= EFI_MEMORY_RO | EFI_MEMORY_RP;
   break;
 
 case TT_DESCRIPTOR_SECTION_AP_RW_NO:
@@ -73,7 +74,7 @@ SectionToGcdAttributes (
 // read only cases map to write-protect
 case TT_DESCRIPTOR_SECTION_AP_RO_NO:
 case TT_DESCRIPTOR_SECTION_AP_RO_RO:
-  *GcdAttributes |= EFI_MEMORY_WP;
+  *GcdAttributes |= EFI_MEMORY_RO;
   break;
 
 default:
@@ -126,7 +127,7 @@ PageToGcdAttributes (
   // determine protection attributes
   switch(PageAttributes & TT_DESCRIPTOR_PAGE_AP_MASK) {
 case TT_DESCRIPTOR_PAGE_AP_NO_NO: // no read, no write
-  //*GcdAttributes |= EFI_MEMORY_WP | EFI_MEMORY_RP;
+  //*GcdAttributes |= EFI_MEMORY_RO | EFI_MEMORY_RP;
   break;
 
 case TT_DESCRIPTOR_PAGE_AP_RW_NO:
@@ -137,7 +138,7 @@ PageToGcdAttributes (
 // read only cases map to write-protect
 case TT_DESCRIPTOR_PAGE_AP_RO_NO:
 case TT_DESCRIPTOR_PAGE_AP_RO_RO:
-  *GcdAttributes |= EFI_MEMORY_WP;
+  *GcdAttributes |= EFI_MEMORY_RO;
   break;
 
 default:
@@ -730,9 +731,6 @@ EfiAttributeToArmAttribute (
   ArmAttributes = TT_DESCRIPTOR_SECTION_CACHE_POLICY_WRITE_BACK_ALLOC; // 
TEX [2:0] = 001, C=1, B=1
   break;
 
-case EFI_MEMORY_WP:
-case EFI_MEMORY_XP:
-case EFI_MEMORY_RP:
 case EFI_MEMORY_UCE:
 default:
   // Cannot be implemented UEFI definition unclear for ARM
@@ -743,7 +741,7 @@ EfiAttributeToArmAttribute (
   }
 
   // Determine protection attributes
-  if (EfiAttributes & EFI_MEMORY_WP) {
+  if (EfiAttributes & EFI_MEMORY_RO) {
 ArmAttributes |= TT_DESCRIPTOR_SECTION_AP_RO_RO;
   } else {
 ArmAttributes |= TT_DESCRIPTOR_SECTION_AP_RW_RW;
diff --git a/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c 
b/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c
index 723604d1df96..54d9b0163331 100644
--- a/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c
+++ b/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c
@@ -1,6 +1,7 @@
 /** @file
 *
 *  Copyright (c) 2013, ARM Limited. All rights reserved.
+*  Copyright (c) 2017, Intel Corporation. All rights reserved.
 *
 *  This program and the accompanying materials
 *  are licensed and made available under the terms and conditions of the BSD 
License
@@ -236,7 +237,7 @@ CpuConvertPagesToUncachedVirtualAddress (
   // be the PCI address. Code should always use the CPU address, and we will 
or in VirtualMask
   // to that address.
   //
-  Status = SetMemoryAttributes (Address, Length, EFI_MEMORY_WP, 0);
+  Status = 

[edk2] [PATCH 0/4] ArmPkg: add groundwork for DXE image protection

[Ard Biesheuvel]

The upcoming DXE image protection feature expects the EFI_CPU_ARCH_PROTOCOL
method SetMemoryAttributes() to deal with invocations that only modify
permission attributes, but leave the cacheability attributes alone. This
requires some groundwork to be performed in the MMU code for ARM.

Patch #1 is Jiewen's patch to retire EFI_MEMORY_WP, which is no longer
used as a permission attribute.

Patch #2 updates EfiAttributeToArmAttribute () so it can deal with
unspecified caching modes.

Patch #3 makes ARM deal with EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes()
calls that do not specify memory attributes. On ARM, we don't have code
that manages the permission bits in the page tables, so this does little
more than ignore such attributes.

Patch #4 implements the handling for AARCH64 to manage the permissions
bits without touching or caring about the memory type attributes.

Ard Biesheuvel (3):
  ArmPkg/CpuDxe: translate invalid memory types in
EfiAttributeToArmAttribute
  ArmPkg/CpuDxe: ARM: ignore page table updates that only change
permissions
  ArmPkg/ArmMmuLib: AARCH64: add support for modifying only permissions

Jiewen Yao (1):
  ArmPkg/CpuDxe: Correct EFI_MEMORY_RO usage

 ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c  |  7 +-
 ArmPkg/Drivers/CpuDxe/Arm/Mmu.c  | 24 ---
 ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c |  5 +-
 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 76 +++-
 4 files changed, 77 insertions(+), 35 deletions(-)

-- 
2.7.4

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

Re: [edk2] [PATCH] ShellPkg SmbiosView: Eliminate trailing " | " in PrintBitsInfo()

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Star Zeng
> Sent: Thursday, February 09, 2017 1:23 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Carsey, Jaben
> ; Zeng, Star 
> Subject: [edk2] [PATCH] ShellPkg SmbiosView: Eliminate trailing " | " in
> PrintBitsInfo()
> Importance: High
> 
> Current PrintBitsInfo() will always print an additional trailing
> " | " for the bit flags, for example,
> 
> Base Board Feature Flags: Hosting board |  Replaceable |
> 
> Th patch is to eliminate trailing " | " in PrintBitsInfo(), then
> the output will be like below
> 
> Base Board Feature Flags: Hosting board |  Replaceable
> 
> Cc: Ruiyu Ni 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  .../UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c | 18
> +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> c
> index 282ba584c8c9..02d9ab1f57b3 100644
> ---
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> c
> +++
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> c
> @@ -3449,19 +3449,24 @@ PrintBitsInfo (
> 
>UINTN   Index;
>UINT32  Value;
> -  BOOLEAN NoInfo;
> +  BOOLEAN FirstInfo;
> 
> -  NoInfo  = TRUE;
> +  FirstInfo = TRUE;
>Value   = Bits;
>//
>// query the table and print information
>//
>for (Index = 0; Index < Number; Index++) {
>  if (BIT (Value, Table[Index].Key) != 0) {
> +  if (!FirstInfo) {
> +//
> +// If it is not first info, print the separator first.
> +//
> +Print (L" | ");
> +  }
>Print (Table[Index].Info);
> -  Print (L" | ");
> 
> -  NoInfo = FALSE;
> +  FirstInfo = FALSE;
>//
>// clear the bit, for reserved bits test
>//
> @@ -3469,7 +3474,10 @@ PrintBitsInfo (
>  }
>}
> 
> -  if (NoInfo) {
> +  //
> +  // There is no any info if FirstInfo is still TRUE.
> +  //
> +  if (FirstInfo) {
>  ShellPrintHiiEx(-1,-1,NULL,STRING_TOKEN
> (STR_SMBIOSVIEW_QUERYTABLE_NO_INFO), gShellDebug1HiiHandle);
>}
> 
> --
> 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] UEFI LinuxLoader app usage

[Andrew Fish]

> On Feb 9, 2017, at 6:05 AM, Jun Nie  wrote:
> 
> 2017-02-09 21:44 GMT+08:00 Jun Nie :
>> I am new to UEFI and trying to boot Linux with LinuxLoader app. But I
>> cannot find detail information for below questions. Could anyone point
>> out where I can find related information or example code? Thanks for
>> your time!
>> 
>> 1. How to feed command line to this app so that ProcessAppCommandLine() can
>> process it?
> I know this app support parsing command line from shell. I am seeking
> method to launch this app from BDS directly without shell but cannot
> find where to specify value to LoadedImage->LoadOptions so that this
> app can get command line from it.
> 

The mechanism in EFI is the NVRAM variable for the boot option. See 
EFI_LOAD_OPTION.
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Uefi/UefiSpec.h#L2037
 


The UI to create boot variables is implementation dependent. When we designed 
it conceptually we thought the OS installer would be the primary entity writing 
the boot option as it was the entity installing the OS loader. 

I think there is a shell command to set boot options, I'm not sure if it lets 
you set the OptionalData in the EFI_LOAD_OPTION. 

Thanks,

Andrew Fish


>> 
>> 2. And how should I generate  device path string for raw blockIO
>> device with specified offset/size? UEFI 2.6 spec does not provide much
>> information in 9.4.5 Media Device Path Rules.
>> 
>> Thank you!
>> Jun
> ___
> 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 0/4] DXE Memory Protection

[Ard Biesheuvel]

On 9 February 2017 at 16:30, Ard Biesheuvel  wrote:
> On 9 February 2017 at 16:29, Yao, Jiewen  wrote:
>> Very good point.
>>
>> Can ARCH64 set 4K paging for 64K aligned runtime memory?
>>
>
> UEFI always uses 4 KB, but the OS may use 64 KB, so to create the
> virtual address map it needs the runtime regions to be 64 KB aligned.
>
>>
>>
>> If yes, how about we use
>>
>> “ImageRecord->ImageSize = ALIGN_VALUE(LoadedImage->ImageSize,
>> EFI_PAGE_SIZE);”
>>
>

Another question: did you try SetVirtualAddressMap()? It looks like we
need to lift read-only permissions to allow the runtime PE/COFF
relocation to apply the fixups
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 5/6] OvmfPkg: Resolve BmDmaLib class for PciHostBridgeDxe driver

[Leo Duran]

This patch adds the new DxeBmDmaLib (BmDmaLib class) library, which
provides an abstraction layer for DMA operations implemented by the
PciHostBridgeDxe driver.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 3 files changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 993547d..f2fea24 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -90,6 +90,7 @@ [LibraryClasses]
   
UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
   SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
+  BmDmaLib|MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index f36604e..0f1f85c 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -95,6 +95,7 @@ [LibraryClasses]
   
UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
   SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
+  BmDmaLib|MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index c5bf1a6..ec43249 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -95,6 +95,7 @@ [LibraryClasses]
   
UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
   SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
+  BmDmaLib|MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
-- 
1.9.1

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

[edk2] [PATCH v3 6/6] MdeModulePkg: Modify PciHostBridgeDxe to use new BmDmaLib class library

[Leo Duran]

The BmDmaLib class library provides an abstraction layer for Bus-master DMA
operations as currently implemented by the PciHostBridgeDxe driver. The
intent is to allow override of the library as required by specific hardware
implementations, such as AMD's Secure Encrypted Virtualization (SEV).

Cc: Feng Tian 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
signed-off-by: Leo Duran 
---
 .../Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf  |   1 +
 .../Bus/Pci/PciHostBridgeDxe/PciRootBridge.h   |  13 +-
 .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 272 +
 MdeModulePkg/MdeModulePkg.dsc  |   1 +
 4 files changed, 67 insertions(+), 220 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf 
b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
index d8b0439..35bb5c4 100644
--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
@@ -42,6 +42,7 @@ [LibraryClasses]
   BaseLib
   PciSegmentLib
   PciHostBridgeLib
+  BmDmaLib
 
 [Protocols]
   gEfiMetronomeArchProtocolGuid   ## CONSUMES
diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h 
b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h
index 13185b4..c125fcd 100644
--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h
+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h
@@ -34,6 +34,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 #include "PciHostResource.h"
 
 
@@ -43,17 +44,6 @@ typedef enum {
   PciOperation
 } OPERATION_TYPE;
 
-#define MAP_INFO_SIGNATURE  SIGNATURE_32 ('_', 'm', 'a', 'p')
-typedef struct {
-  UINT32Signature;
-  LIST_ENTRYLink;
-  EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_OPERATION Operation;
-  UINTN NumberOfBytes;
-  UINTN NumberOfPages;
-  EFI_PHYSICAL_ADDRESS  HostAddress;
-  EFI_PHYSICAL_ADDRESS  MappedHostAddress;
-} MAP_INFO;
-#define MAP_INFO_FROM_LINK(a) CR (a, MAP_INFO, Link, MAP_INFO_SIGNATURE)
 
 #define PCI_ROOT_BRIDGE_SIGNATURE SIGNATURE_32 ('_', 'p', 'r', 'b')
 
@@ -79,7 +69,6 @@ typedef struct {
   EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL   RootBridgeIo;
 
   BOOLEAN   ResourceSubmitted;
-  LIST_ENTRYMaps;
 } PCI_ROOT_BRIDGE_INSTANCE;
 
 #define ROOT_BRIDGE_FROM_THIS(a) CR (a, PCI_ROOT_BRIDGE_INSTANCE, 
RootBridgeIo, PCI_ROOT_BRIDGE_SIGNATURE)
diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c 
b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
index 8af131b..8a74bf6 100644
--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
@@ -17,7 +17,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include "PciRootBridge.h"
 #include "PciHostResource.h"
 
-#define NO_MAPPING  (VOID *) (UINTN) -1
 
 //
 // Lookup table for increment values based on transfer widths
@@ -55,6 +54,39 @@ UINT8 mOutStride[] = {
   0  // EfiPciWidthFillUint64
 };
 
+
+BM_DMA_OPERATION
+ConvertDmaOperation (
+  IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_OPERATION  RbOperation
+  )
+{
+  BM_DMA_OPERATION BmOperation;
+
+  switch (RbOperation) {
+  case EfiPciOperationBusMasterRead:
+  case EfiPciOperationBusMasterRead64:
+BmOperation = DmaOperationBusMasterRead;
+break;
+
+  case EfiPciOperationBusMasterWrite:
+  case EfiPciOperationBusMasterWrite64:
+BmOperation = DmaOperationBusMasterWrite;
+break;
+
+  case EfiPciOperationBusMasterCommonBuffer:
+  case EfiPciOperationBusMasterCommonBuffer64:
+BmOperation = DmaOperationBusMasterCommonBuffer;
+break;
+
+  default:
+BmOperation = DmaOperationBusMasterMaximum;
+break;
+  }
+
+  return BmOperation;
+}
+
+
 /**
   Construct the Pci Root Bridge instance.
 
@@ -168,7 +200,6 @@ CreateRootBridge (
 TypeMax * sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) + sizeof 
(EFI_ACPI_END_TAG_DESCRIPTOR)
 );
   ASSERT (RootBridge->ConfigBuffer != NULL);
-  InitializeListHead (>Maps);
 
   CopyMem (>Bus, >Bus, sizeof (PCI_ROOT_BRIDGE_APERTURE));
   CopyMem (>Io, >Io, sizeof (PCI_ROOT_BRIDGE_APERTURE));
@@ -1053,118 +1084,27 @@ RootBridgeIoMap (
   OUTVOID   **Mapping
   )
 {
-  EFI_STATUSStatus;
-  PCI_ROOT_BRIDGE_INSTANCE  *RootBridge;
-  EFI_PHYSICAL_ADDRESS  PhysicalAddress;
-  MAP_INFO  *MapInfo;
-
-  if (HostAddress == NULL || NumberOfBytes == NULL || DeviceAddress == NULL ||
-  Mapping == NULL) {
-return 

[edk2] [PATCH v3 1/6] MdeModulePkg: Add DxeBmDmaLib (BmDmaLib class) library

[Leo Duran]

This patch provides an abstraction layer for Bus-master DMA operations as
currently implemented by the PciHostBridgeDxe driver. The intent is to then
allow override of this library as may be required by specific hardware
implementations, such as AMD's Secure Encrypted Virtualization (SEV).

This new BmDmaLib class library is cloned from the existing DmaLib with
an additional DmaAbove4GB (BOOLEAN) parameter for the Map and Allocate
interfaces, so that decisions can be made about the need to allocate DMA
buffers below the 4GB boundary.

Cc: Feng Tian 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran 
---
 MdeModulePkg/Include/Library/BmDmaLib.h  | 161 +++
 MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.c   | 351 +++
 MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf |  41 +++
 MdeModulePkg/MdeModulePkg.dsc|   1 +
 4 files changed, 554 insertions(+)
 create mode 100644 MdeModulePkg/Include/Library/BmDmaLib.h
 create mode 100644 MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.c
 create mode 100644 MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf

diff --git a/MdeModulePkg/Include/Library/BmDmaLib.h 
b/MdeModulePkg/Include/Library/BmDmaLib.h
new file mode 100644
index 000..2c0e50f
--- /dev/null
+++ b/MdeModulePkg/Include/Library/BmDmaLib.h
@@ -0,0 +1,161 @@
+/** @file
+  DMA abstraction library APIs. Based on PCI IO protocol DMA abstractions.
+
+  Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
+  Copyright (c) 2017, AMD Inc. All rights reserved.
+
+  DMA Bus Master Read Operation:
+Call BmDmaMap() for DmaOperationBusMasterRead.
+Program the DMA Bus Master with the DeviceAddress returned by BmDmaMap().
+Start the DMA Bus Master.
+Wait for DMA Bus Master to complete the read operation.
+Call BmDmaUnmap().
+
+  DMA Bus Master Write Operation:
+Call BmDmaMap() for DmaOperationBusMasterWrite.
+Program the DMA Bus Master with the DeviceAddress returned by BmDmaMap().
+Start the DMA Bus Master.
+Wait for DMA Bus Master to complete the write operation.
+Call BmDmaUnmap().
+
+  DMA Bus Master Common Buffer Operation:
+Call BmDmaAllocateBuffer() to allocate a common buffer.
+Call BmDmaMap() for DmaOperationBusMasterCommonBuffer.
+Program the DMA Bus Master with the DeviceAddress returned by BmDmaMap().
+The common buffer can now be accessed equally by the processor and the DMA 
bus master.
+Call BmDmaUnmap().
+Call BmDmaFreeBuffer().
+
+  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.
+
+ Derived from:
+   EmbeddedPkg/Include/Library/DmaLib.h
+
+**/
+
+#ifndef __BM_DMA_LIB_H__
+#define __BM_DMA_LIB_H__
+
+
+typedef enum {
+  ///
+  /// A read operation from system memory by a bus master.
+  ///
+  DmaOperationBusMasterRead,
+  ///
+  /// A write operation from system memory by a bus master.
+  ///
+  DmaOperationBusMasterWrite,
+  ///
+  /// Provides both read and write access to system memory by both the 
processor and a
+  /// bus master. The buffer is coherent from both the processor's and the bus 
master's point of view.
+  ///
+  DmaOperationBusMasterCommonBuffer,
+  DmaOperationBusMasterMaximum
+} BM_DMA_OPERATION;
+
+
+/**
+  Provides the DMA controller-specific addresses needed to access system 
memory.
+
+  Operation is relative to the DMA bus master.
+
+  @param  DmaAbove4GB   Indicates capability of DMA operations above 
4GB.
+  @param  Operation Indicates if the bus master is going to read 
or write to system memory.
+  @param  HostAddress   The system memory address to map to the DMA 
controller.
+  @param  NumberOfBytes On input the number of bytes to map. On output 
the number of bytes
+that were mapped.
+  @param  DeviceAddress The resulting map address for the bus master 
controller to use to
+access the hosts HostAddress.
+  @param  Mapping   A resulting value to pass to BmDmaUnmap().
+
+  @retval EFI_SUCCESS   The range was mapped for the returned 
NumberOfBytes.
+  @retval EFI_UNSUPPORTED   The HostAddress cannot be mapped as a common 
buffer.
+  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
+  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a 
lack of resources.
+  @retval EFI_DEVICE_ERROR  The system hardware could not map the 
requested address.
+
+**/
+EFI_STATUS
+EFIAPI
+BmDmaMap (
+  IN BOOLEAN   

[edk2] [PATCH v3 4/6] MdeModulePkg: Resolve BmDmaLib class for PciHostBridgeDxe driver

[Leo Duran]

This patch adds the new DxeBmDmaLib (BmDmaLib class) library, which
provides an abstraction layer for DMA operations implemented by the
PciHostBridgeDxe driver.

Cc: Feng Tian 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran 
Reviewed-by: Laszlo Ersek 
---
 MdeModulePkg/MdeModulePkg.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 311922e..b343c19 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -48,6 +48,7 @@ [LibraryClasses]
   PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
   
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
   SortLib|MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf
+  BmDmaLib|MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf
   #
   # UEFI & PI
   #
-- 
1.9.1

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

[edk2] [PATCH v3 0/6] DxeBmDmaLib (BmDmaLib class) library

[Leo Duran]

This series provides an abstraction layer for Bus-master DMA operations as
currently implemented by the PciHostBridgeDxe driver. The intent is to then
allow override of this library as may be required by specific hardware
implementations, such as AMD's Secure Encrypted Virtualization (SEV).

Please refer to the RFC discussion for SEV here:
http://marc.info/?l=linux-mm=147190814023863=2

This new (BmDmaLib class) library is cloned from the existing DmaLib with
an additional DmaAbove4GB (BOOLEAN) parameter for the Map and Allocate
interfaces, so that decisions can be made about the need to allocate DMA
buffers below the 4GB boundary.

NOTE: The abstraction layer is intended for Bus-master (DMA capable)
devices, and not restricted to the PCI Root-Bridge use-case. Thus the
rationale for not using EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_OPERATION types.

Changes since RFC_v2:
- Include the actual DxeBmDmaLib library code that was untentionally
  missing in the previous [RFC v2 1/6] submission.
- Minor cleanup on commit messages.

Leo Duran (6):
  MdeModulePkg: Add DxeBmDmaLib (BmDmaLib class) library
  ArmVirtPkg: Resolve BmDmaLib class for PciHostBridgeDxe driver
  CorebootPayloadPkg: Resolve BmDmaLib class for PciHostBridgeDxe driver
  MdeModulePkg: Resolve BmDmaLib class for PciHostBridgeDxe driver
  OvmfPkg: Resolve BmDmaLib class for PciHostBridgeDxe driver
  MdeModulePkg: Modify PciHostBridgeDxe to use new BmDmaLib class
library

 ArmVirtPkg/ArmVirtQemu.dsc |   1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc   |   1 +
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc  |   1 +
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc   |   1 +
 .../Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf  |   1 +
 .../Bus/Pci/PciHostBridgeDxe/PciRootBridge.h   |  13 +-
 .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 272 
 MdeModulePkg/Include/Library/BmDmaLib.h| 161 ++
 MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.c | 351 +
 MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf   |  41 +++
 MdeModulePkg/MdeModulePkg.dsc  |   3 +
 OvmfPkg/OvmfPkgIa32.dsc|   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc |   1 +
 OvmfPkg/OvmfPkgX64.dsc |   1 +
 14 files changed, 629 insertions(+), 220 deletions(-)
 create mode 100644 MdeModulePkg/Include/Library/BmDmaLib.h
 create mode 100644 MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.c
 create mode 100644 MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf

-- 
1.9.1

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

[edk2] [PATCH v3 3/6] CorebootPayloadPkg: Resolve BmDmaLib class for PciHostBridgeDxe driver

[Leo Duran]

This patch adds the new DxeBmDmaLib (BmDmaLib class) library, which
provides an abstraction layer for DMA operations implemented by the
PciHostBridgeDxe driver.

Cc: Maurice Ma 
Cc: Prince Agyeman 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran 
Reviewed-by: Laszlo Ersek 
---
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 1 +
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 1 +
 2 files changed, 2 insertions(+)

diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
index cdfcb75..12fcd3f 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
@@ -140,6 +140,7 @@ [LibraryClasses]
   PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
   
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
   
CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
+  BmDmaLib|MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf
 
   #
   # UEFI & PI
diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
index 6b16af6..28e1ffa 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
@@ -140,6 +140,7 @@ [LibraryClasses]
   PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
   
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
   
CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
+  BmDmaLib|MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf
 
   #
   # UEFI & PI
-- 
1.9.1

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

[edk2] [PATCH v3 2/6] ArmVirtPkg: Resolve BmDmaLib class for PciHostBridgeDxe driver

[Leo Duran]

This patch adds the new DxeBmDmaLib (BmDmaLib class) library, which
provides an abstraction layer for DMA operations implemented by the
PciHostBridgeDxe driver.

Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran 
Reviewed-by: Laszlo Ersek 
---
 ArmVirtPkg/ArmVirtQemu.dsc   | 1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 +
 2 files changed, 2 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 8fe3c38..d318f82 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -59,6 +59,7 @@ [LibraryClasses.common]
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
 
+  BmDmaLib|MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index aa40374..721d78a 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -58,6 +58,7 @@ [LibraryClasses.common]
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
 
+  BmDmaLib|MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
-- 
1.9.1

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

Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

[Ard Biesheuvel]

On 9 February 2017 at 16:29, Yao, Jiewen  wrote:
> Very good point.
>
> Can ARCH64 set 4K paging for 64K aligned runtime memory?
>

UEFI always uses 4 KB, but the OS may use 64 KB, so to create the
virtual address map it needs the runtime regions to be 64 KB aligned.

>
>
> If yes, how about we use
>
> “ImageRecord->ImageSize = ALIGN_VALUE(LoadedImage->ImageSize,
> EFI_PAGE_SIZE);”
>

Perfect, thanks.

>
>
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, February 9, 2017 8:21 AM
> To: Yao, Jiewen 
> Cc: Tian, Feng ; edk2-devel@lists.01.org; Leif Lindholm
> ; Kinney, Michael D ;
> Fan, Jeff ; Zeng, Star 
> Subject: Re: [edk2] [PATCH V3 0/4] DXE Memory Protection
>
>
>
> On 9 February 2017 at 15:28, Ard Biesheuvel 
> wrote:
>
>
>> On 9 February 2017 at 15:27, Yao, Jiewen  wrote:
>>> 1)   That is great. I appreciate your quick response and help.
>>>
>>> I will drop my patch for ARM 2/4, and wait for yours.
>>>
>>
>> OK
>>
>>>
>>>
>>> 2)   For ImageEnd alignment issue, I agree with you.
>>>
>>> I plan to round up with:
>>>
>>> ImageRecord->ImageSize = ALIGN_VALUE(LoadedImage->ImageSize,
>>> SectionAlignment);
>>>
>>> before SetUefiImageProtectionAttributes (ImageRecord, Protect);
>>>
>>
>> Great, that should fix my issue!
>>
>
> Actually, does that still work correctly with 64 KB section alignment?
> I don't think the PE/COFF loader rounds up the allocation to section
> alignment, does it?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

[Yao, Jiewen]

Very good point.

Can ARCH64 set 4K paging for 64K aligned runtime memory?

If yes, how about we use
“ImageRecord->ImageSize = ALIGN_VALUE(LoadedImage->ImageSize, EFI_PAGE_SIZE);”


Thank you
Yao Jiewen

From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, February 9, 2017 8:21 AM
To: Yao, Jiewen 
Cc: Tian, Feng ; edk2-devel@lists.01.org; Leif Lindholm 
; Kinney, Michael D ; 
Fan, Jeff ; Zeng, Star 
Subject: Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

On 9 February 2017 at 15:28, Ard Biesheuvel 
> wrote:
> On 9 February 2017 at 15:27, Yao, Jiewen 
> > wrote:
>> 1)   That is great. I appreciate your quick response and help.
>>
>> I will drop my patch for ARM 2/4, and wait for yours.
>>
>
> OK
>
>>
>>
>> 2)   For ImageEnd alignment issue, I agree with you.
>>
>> I plan to round up with:
>>
>> ImageRecord->ImageSize = ALIGN_VALUE(LoadedImage->ImageSize,
>> SectionAlignment);
>>
>> before SetUefiImageProtectionAttributes (ImageRecord, Protect);
>>
>
> Great, that should fix my issue!
>

Actually, does that still work correctly with 64 KB section alignment?
I don't think the PE/COFF loader rounds up the allocation to section
alignment, does it?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

[Ard Biesheuvel]

On 9 February 2017 at 15:28, Ard Biesheuvel  wrote:
> On 9 February 2017 at 15:27, Yao, Jiewen  wrote:
>> 1)   That is great. I appreciate your quick response and help.
>>
>> I will drop my patch for ARM 2/4, and wait for yours.
>>
>
> OK
>
>>
>>
>> 2)   For ImageEnd alignment issue, I agree with you.
>>
>> I plan to round up with:
>>
>> ImageRecord->ImageSize = ALIGN_VALUE(LoadedImage->ImageSize,
>> SectionAlignment);
>>
>> before SetUefiImageProtectionAttributes (ImageRecord, Protect);
>>
>
> Great, that should fix my issue!
>

Actually, does that still work correctly with 64 KB section alignment?
I don't think the PE/COFF loader rounds up the allocation to section
alignment, does it?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] SecurityPkg/TpmCommandLib: Add Tpm2ReadPublic.

[Jiewen Yao]

Cc: Chao Zhang 
Cc: Long Qin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yao Jiewen 
---
 SecurityPkg/Include/Library/Tpm2CommandLib.h  |  22 +-
 SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf |   3 +-
 SecurityPkg/Library/Tpm2CommandLib/Tpm2Object.c   | 346 

 3 files changed, 369 insertions(+), 2 deletions(-)

diff --git a/SecurityPkg/Include/Library/Tpm2CommandLib.h 
b/SecurityPkg/Include/Library/Tpm2CommandLib.h
index f7a04f2..80ada73 100644
--- a/SecurityPkg/Include/Library/Tpm2CommandLib.h
+++ b/SecurityPkg/Include/Library/Tpm2CommandLib.h
@@ -1,7 +1,7 @@
 /** @file
   This library is used by other modules to send TPM2 command.
 
-Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved. 
+Copyright (c) 2013 - 2017, Intel Corporation. All rights reserved. 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -959,6 +959,26 @@ Tpm2PolicyGetDigest (
  OUT  TPM2B_DIGEST  *PolicyHash
   );
 
+/**
+  This command allows access to the public area of a loaded object.
+
+  @param[in]  ObjectHandleTPM handle of an object
+  @param[out] OutPublic   Structure containing the public area of 
an object
+  @param[out] NameName of the object
+  @param[out] QualifiedName   The Qualified Name of the object
+
+  @retval EFI_SUCCESS  Operation completed successfully.
+  @retval EFI_DEVICE_ERROR Unexpected device behavior.
+**/
+EFI_STATUS
+EFIAPI
+Tpm2ReadPublic (
+  IN  TPMI_DH_OBJECTObjectHandle,
+  OUT TPM2B_PUBLIC  *OutPublic,
+  OUT TPM2B_NAME*Name,
+  OUT TPM2B_NAME*QualifiedName
+  );
+
 //
 // Help function
 //
diff --git a/SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf 
b/SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
index 740af3f..481a878 100644
--- a/SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
+++ b/SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
@@ -3,7 +3,7 @@
 #
 #  This library is used by other modules to send TPM 2.0 command.
 #
-# Copyright (c) 2013 - 2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2013 - 2017, Intel Corporation. All rights reserved.
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
 # which accompanies this distribution. The full text of the license may be 
found at
@@ -40,6 +40,7 @@
   Tpm2EnhancedAuthorization.c
   Tpm2Test.c
   Tpm2DictionaryAttack.c
+  Tpm2Object.c
   Tpm2Miscellaneous.c
   Tpm2Help.c
 
diff --git a/SecurityPkg/Library/Tpm2CommandLib/Tpm2Object.c 
b/SecurityPkg/Library/Tpm2CommandLib/Tpm2Object.c
new file mode 100644
index 000..e070ff2
--- /dev/null
+++ b/SecurityPkg/Library/Tpm2CommandLib/Tpm2Object.c
@@ -0,0 +1,346 @@
+/** @file
+  Implement TPM2 Object related command.
+
+Copyright (c) 2017, Intel Corporation. All rights reserved. 
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+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.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#pragma pack(1)
+
+typedef struct {
+  TPM2_COMMAND_HEADER   Header;
+  TPMI_DH_OBJECTObjectHandle;
+} TPM2_READ_PUBLIC_COMMAND;
+
+typedef struct {
+  TPM2_RESPONSE_HEADER   Header;
+  TPM2B_PUBLIC   OutPublic;
+  TPM2B_NAME Name;
+  TPM2B_NAME QualifiedName;
+} TPM2_READ_PUBLIC_RESPONSE;
+
+#pragma pack()
+
+/**
+  This command allows access to the public area of a loaded object.
+
+  @param[in]  ObjectHandleTPM handle of an object
+  @param[out] OutPublic   Structure containing the public area of 
an object
+  @param[out] NameName of the object
+  @param[out] QualifiedName   The Qualified Name of the object
+
+  @retval EFI_SUCCESS  Operation completed successfully.
+  @retval EFI_DEVICE_ERROR Unexpected device behavior.
+**/
+EFI_STATUS
+EFIAPI
+Tpm2ReadPublic (
+  IN  TPMI_DH_OBJECTObjectHandle,
+  OUT TPM2B_PUBLIC  *OutPublic,
+  OUT TPM2B_NAME*Name,
+  OUT TPM2B_NAME*QualifiedName
+  )
+{
+  EFI_STATUS Status;
+  TPM2_READ_PUBLIC_COMMAND   SendBuffer;
+  TPM2_READ_PUBLIC_RESPONSE  RecvBuffer;
+  UINT32 SendBufferSize;

Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

[Yao, Jiewen]

1)   That is great. I appreciate your quick response and help.
I will drop my patch for ARM 2/4, and wait for yours.


2)   For ImageEnd alignment issue, I agree with you.
I plan to round up with:
ImageRecord->ImageSize = ALIGN_VALUE(LoadedImage->ImageSize, SectionAlignment);
before SetUefiImageProtectionAttributes (ImageRecord, Protect);

I will update it at V4.

Thank you
Yao Jiewen


From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Thursday, February 9, 2017 6:56 AM
To: Yao, Jiewen 
Cc: Tian, Feng ; edk2-devel@lists.01.org; Leif Lindholm 
; Kinney, Michael D ; 
Fan, Jeff ; Zeng, Star 
Subject: Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

On 9 February 2017 at 14:08, Yao, Jiewen 
> wrote:
> For X86 CPU, the memory protection attribute goes to page table, the cache
> attribute goes to MTRR register.
>
> Those are 2 difference resource, and can be set separately.
>
>
>
> The high level pseudo code is below:
>
> ===
>
> CacheAttribute = Attribute & CACHE_ATTRIBUTE_MASK
>
> MemoryProtectionAttribute = Attribute & MEMORY_PROTECTION_ATTRIBUTE_MASK
>
> If (CacheAttribute != 0) {
>
>  SetCacheAttribute(CacheAttribute)
>
> }
>
> SetMemoryProtectionAttribute(MemoryProtectionAttribute)
>
> ===
>
>
>
> NOTE: we need compare CacheAttribute == 0, because the cache attribute is an
> individual mask. 0x1 means UN_CACHE, 0x8 means WRITE_BACK. 0 is meaningless.
>
> We do not compare MemoryProtectionAttribute == 0, because 0 is a valid
> memory protection attribute, which means to disable protection.
>
>
>
> Before GCD sync, the DxeCore does not know the cache attribute, so that it
> can only set memory attribute. The CPU driver only modifies page table based
> upon MemoryProtectionAttribute and keep cache attribute untouched.
>

OK, I think we should be able to work around this, although it is not
pretty. I will send it out as a separate patch.

I do have one other question though: would it be possible to round up
the end of the image to page size in this code? (in
SetUefiImageProtectionAttributes()) Otherwise, we may end up calling
SetMemoryAttributes() with a length that is not page aligned, which
hits an EFI_UNSUPPORTED on ARM. Given that the PE/COFF loader always
allocates full pages, we know the space after the image is not used,
so it is possible (and even more secure!) to clear the exec bit on it.

"""
  //
  // Last DATA
  //
  ASSERT (CurrentBase <= ImageEnd);
  if (CurrentBase < ImageEnd) {
//
// DATA
//
if (Protect) {
  Attribute = EFI_MEMORY_XP;
} else {
  Attribute = 0;
}
SetUefiImageMemoryAttributes (
  CurrentBase,
  ImageEnd - CurrentBase,
  Attribute
  );
  }
"""
___
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 0/4] DXE Memory Protection

[Ard Biesheuvel]

On 9 February 2017 at 15:27, Yao, Jiewen  wrote:
> 1)   That is great. I appreciate your quick response and help.
>
> I will drop my patch for ARM 2/4, and wait for yours.
>

OK

>
>
> 2)   For ImageEnd alignment issue, I agree with you.
>
> I plan to round up with:
>
> ImageRecord->ImageSize = ALIGN_VALUE(LoadedImage->ImageSize,
> SectionAlignment);
>
> before SetUefiImageProtectionAttributes (ImageRecord, Protect);
>

Great, that should fix my issue!

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

Re: [edk2] [PATCH] Discussion about PcdDxeIplSwitchToLongMode

[Duran, Leo]

All,

I've changed the 'Subject' line to avoid confusion.

Thanks,
Leo.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, February 09, 2017 3:46 AM
> To: Zeng, Star ; Yao, Jiewen ;
> Duran, Leo ; edk2-de...@ml01.01.org
> Cc: Tian, Feng ; Singh, Brijesh
> ; Justen, Jordan L 
> Subject: Re: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD
> PcdPteMemoryEncryptionAddressOrMask
> 
> On 02/09/17 10:17, Zeng, Star wrote:
> > EFI_HOB_CPU?
> > Is there discussion in PIWG for it?
> 
> None that I'm aware of.
> 
> Thanks
> Laszlo
> 
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Thursday, February 9, 2017 5:13 PM
> > To: Zeng, Star ; Yao, Jiewen
> > ; Duran, Leo ;
> > edk2-de...@ml01.01.org
> > Cc: Tian, Feng ; Singh, Brijesh
> > ; Justen, Jordan L 
> > Subject: Re: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD
> > PcdPteMemoryEncryptionAddressOrMask
> >
> > On 02/09/17 06:26, Zeng, Star wrote:
> >> Correct typo in below email.
> >>
> >> "about how to determine DXE is 32BITs or 64BITs" should be "about how
> >> to determine PEI is 32BITs or 64BITs".
> >>
> >> At that time, we were discussing if the code needs to allocate <4G
> >> ACPI table for PEI phase at S3 resume.
> >
> > Indeed. Although OVMF X64 has a 64-bit PEI phase, that PEI phase can
> access only <4G RAM. IIRC one suggestion was to introduce a new HOB for
> this, so that PEI can advertise such a limitation to DXE.
> >
> > Thanks
> > Laszlo
> >
> >
> >>
> >> Thanks,
> >> Star
> >> -Original Message-
> >> From: Zeng, Star
> >> Sent: Thursday, February 9, 2017 1:12 PM
> >> To: Laszlo Ersek ; Yao, Jiewen
> >> ; Duran, Leo ;
> >> edk2-de...@ml01.01.org
> >> Cc: Tian, Feng ; Singh, Brijesh
> >> ; Justen, Jordan L
> >> ; Zeng, Star 
> >> Subject: RE: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD
> >> PcdPteMemoryEncryptionAddressOrMask
> >>
> >> In fact, X64 DxeIplPeim does not refer PcdDxeIplSwitchToLongMode at all.
> >>
> >> DxeIpl.inf:
> >> [FeaturePcd.IA32]
> >>   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode  ##
> CONSUMES
> >>
> >> As I remember, I did a draft patch below before for the discussion about
> how to determine DXE is 32BITs or 64BITs in title "[edk2] [PATCH v3 2/4]
> IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed", I
> can't find the archive link any more.
> >>
> >> ---
> >>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c | 5 +
> >>  MdeModulePkg/MdeModulePkg.dec  | 4 +++-
> >>  2 files changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> >> b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> >> index 640..348e084 100644
> >> --- a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> >> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> >> @@ -43,6 +43,11 @@ HandOffToDxeCore (
> >>EFI_PEI_VECTOR_HANDOFF_INFO_PPI *VectorHandoffInfoPpi;
> >>
> >>//
> >> +  // It should be FALSE for both PEI and DXE are 64-bit.
> >> +  //
> >> +  ASSERT (PcdGetBool (PcdDxeIplSwitchToLongMode) == FALSE);
> >> +
> >> +  //
> >>// Get Vector Hand-off Info PPI and build Guided HOB
> >>//
> >>Status = PeiServicesLocatePpi (
> >> diff --git a/MdeModulePkg/MdeModulePkg.dec
> >> b/MdeModulePkg/MdeModulePkg.dec index af7bcab..4a73f7b 100644
> >> --- a/MdeModulePkg/MdeModulePkg.dec
> >> +++ b/MdeModulePkg/MdeModulePkg.dec
> >> @@ -712,8 +712,10 @@
> >>## Indicates if DxeIpl should switch to long mode to enter DXE phase.
> >>#  It is assumed that 64-bit DxeCore is built in firmware if it is true;
> otherwise 32-bit DxeCore
> >>#  is built in firmware.
> >> +  #  And it should be FALSE for both PEI and DXE are 64-bit.
> >>#   TRUE  - DxeIpl will load a 64-bit DxeCore and switch to long mode to
> hand over to DxeCore.
> >> -  #   FALSE - DxeIpl will load a 32-bit DxeCore and perform stack switch 
> >> to
> hand over to DxeCore.
> >> +  #   FALSE - DxeIpl will load a 32-bit DxeCore and perform stack switch 
> >> to
> hand over to DxeCore,
> >> +  #   or both PEI and DXE are 64-bit.
> >># @Prompt DxeIpl switch to long mode.
> >>
> >>
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|TRUE|B
> OOLEAN
> >> |
> >> 0x0001003b
> >>
> >> --
> >>
> >>
> >> Thanks,
> >> Star
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Thursday, February 9, 2017 3:48 AM
> >> To: Yao, Jiewen ; Duran, Leo
> >> ; Zeng, 

Re: [edk2] [RFC v2 1/6] MdeModulePkg: Add DxeBmDmaLib (BmDmaLib class) library

[Duran, Leo]

Hi Ray.
I'll review what I previously sent, and will resend if necessary.
Thanks,
Leo.

> -Original Message-
> From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
> Sent: Wednesday, February 08, 2017 7:59 PM
> To: Duran, Leo ; edk2-devel@lists.01.org
> Cc: Tian, Feng ; Singh, Brijesh
> ; ard.biesheu...@linaro.org; Justen, Jordan L
> ; Zeng, Star ;
> ler...@redhat.com; Agyeman, Prince 
> Subject: RE: [edk2] [RFC v2 1/6] MdeModulePkg: Add DxeBmDmaLib
> (BmDmaLib class) library
> 
> Leo,
> Did you forget to add the BmDmaLib implementation in the patch?
> 
> Thanks/Ray
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Leo Duran
> > Sent: Saturday, January 14, 2017 6:14 AM
> > To: edk2-devel@lists.01.org
> > Cc: Tian, Feng ; brijesh.si...@amd.com;
> > ard.biesheu...@linaro.org; Justen, Jordan L
> > ; Leo Duran ; Zeng,
> Star
> > ; ler...@redhat.com; Agyeman, Prince
> > 
> > Subject: [edk2] [RFC v2 1/6] MdeModulePkg: Add DxeBmDmaLib
> (BmDmaLib
> > class) library
> >
> > This patch provides an abstraction layer for Bus-master DMA operations
> > as currently implemented by the PciHostBridgeDxe driver. The intent is
> > to then allow override of this library as may be required by specific
> > hardware implementations, such as AMD's Secure Encrypted Virtualization
> (SEV).
> >
> > This new (BmDmaLib class) library is cloned from the existing DmaLib
> > with an additional DmaAbove4GB (BOOLEAN) parameter for the Map and
> > Allocate interfaces, so that decisions can be made about the need to
> > allocate DMA buffers below the 4GB boundary.
> > ---
> >  MdeModulePkg/MdeModulePkg.dsc | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/MdeModulePkg/MdeModulePkg.dsc
> > b/MdeModulePkg/MdeModulePkg.dsc index 5996fe5..311922e 100644
> > --- a/MdeModulePkg/MdeModulePkg.dsc
> > +++ b/MdeModulePkg/MdeModulePkg.dsc
> > @@ -275,6 +275,7 @@ [Components]
> >MdeModulePkg/Core/Pei/PeiMain.inf
> >MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
> >
> > +  MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf
> >MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
> >
> >
> MdeModulePkg/Library/UefiMemoryAllocationProfileLib/UefiMemoryAlloca
> > tionProfileLib.inf
> >
> >
> MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllo
> > cationLib.inf
> > --
> > 1.9.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] UEFI LinuxLoader app usage

[Leif Lindholm]

Hi Jun,

On Thu, Feb 09, 2017 at 10:05:50PM +0800, Jun Nie wrote:
> 2017-02-09 21:44 GMT+08:00 Jun Nie :
> >  I am new to UEFI and trying to boot Linux with LinuxLoader app. But I
> > cannot find detail information for below questions. Could anyone point
> > out where I can find related information or example code? Thanks for
> > your time!
> >
> > 1. How to feed command line to this app so that ProcessAppCommandLine() can
> > process it?
>
> I know this app support parsing command line from shell. I am seeking
> method to launch this app from BDS directly without shell but cannot
> find where to specify value to LoadedImage->LoadOptions so that this
> app can get command line from it.

The LinuxLoader was a severely unreliable non-UEFI-compliant
component which was deleted from the edk2 repository in November last
year. Unless your Linux kernel is older than version 3.16 (64-bit) or
4.5 (32-bit), there is no reason to use it.

And if it is, it is worth looking for alternative solutions.

> > 2. And how should I generate  device path string for raw blockIO
> > device with specified offset/size? UEFI 2.6 spec does not provide much
> > information in 9.4.5 Media Device Path Rules.

You say raw blockIO device - what does this mean?
If the system produces a raw block device from something like an
eMMC, then I would recommend putting a partition table on it, and
finding the desired offset from this.

Best Regards,

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

Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

[Ard Biesheuvel]

On 9 February 2017 at 14:08, Yao, Jiewen  wrote:
> For X86 CPU, the memory protection attribute goes to page table, the cache
> attribute goes to MTRR register.
>
> Those are 2 difference resource, and can be set separately.
>
>
>
> The high level pseudo code is below:
>
> ===
>
> CacheAttribute = Attribute & CACHE_ATTRIBUTE_MASK
>
> MemoryProtectionAttribute = Attribute & MEMORY_PROTECTION_ATTRIBUTE_MASK
>
> If (CacheAttribute != 0) {
>
>  SetCacheAttribute(CacheAttribute)
>
> }
>
> SetMemoryProtectionAttribute(MemoryProtectionAttribute)
>
> ===
>
>
>
> NOTE: we need compare CacheAttribute == 0, because the cache attribute is an
> individual mask. 0x1 means UN_CACHE, 0x8 means WRITE_BACK. 0 is meaningless.
>
> We do not compare MemoryProtectionAttribute == 0, because 0 is a valid
> memory protection attribute, which means to disable protection.
>
>
>
> Before GCD sync, the DxeCore does not know the cache attribute, so that it
> can only set memory attribute. The CPU driver only modifies page table based
> upon MemoryProtectionAttribute and keep cache attribute untouched.
>

OK, I think we should be able to work around this, although it is not
pretty. I will send it out as a separate patch.

I do have one other question though: would it be possible to round up
the end of the image to page size in this code? (in
SetUefiImageProtectionAttributes()) Otherwise, we may end up calling
SetMemoryAttributes() with a length that is not page aligned, which
hits an EFI_UNSUPPORTED on ARM. Given that the PE/COFF loader always
allocates full pages, we know the space after the image is not used,
so it is possible (and even more secure!) to clear the exec bit on it.

"""
  //
  // Last DATA
  //
  ASSERT (CurrentBase <= ImageEnd);
  if (CurrentBase < ImageEnd) {
//
// DATA
//
if (Protect) {
  Attribute = EFI_MEMORY_XP;
} else {
  Attribute = 0;
}
SetUefiImageMemoryAttributes (
  CurrentBase,
  ImageEnd - CurrentBase,
  Attribute
  );
  }
"""
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

[Yao, Jiewen]

I forget mentioning the V3 update also include below 2 feedback:
=
4) Rename file PageTableLib.h/.c to CpuPageTable.h/.c file (from Jeff Fan)
5) Remove multi-entrypoint usage (from Liming Gao/Mike Kinney)
=

Thank you
Yao Jiewen

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiewen
> Yao
> Sent: Wednesday, February 8, 2017 11:20 PM
> To: edk2-devel@lists.01.org
> Cc: Tian, Feng ; Ard Biesheuvel
> ; Leif Lindholm ; Kinney,
> Michael D ; Fan, Jeff ; Zeng,
> Star 
> Subject: [edk2] [PATCH V3 0/4] DXE Memory Protection
> 
>  V3 
> 1) Add PCD for policy control (feedback from Ard Biesheuvel)
> (Discussed with Mike Kinney)
> +  #BIT0   - Image from unknown device. 
> +  #BIT1   - Image from firmware volume.
> +  # @Prompt Set image protection policy.
> +  # @ValidRange 0x8002 | 0x - 0x001F
> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy|0x0002|UIN
> T32|0x1047
> 
> 2) Remove unused function in CpuDxe.(feedback from Liming Gao)
> 3) Add commit log on link option assumption (feedback from Feng Tian)
> 
>  V2 
> 1) Clean up ArmPkg, (feedback from Leif Lindholm)
> 
>  V1 
> This series patch provides capability to protect PE/COFF image
> in DXE memory.
> If the UEFI image is page aligned, the image code section is set to read
> only and the image data section is set to non-executable.
> 
> The DxeCore calls CpuArchProtocol->SetMemoryAttributes() to protect
> the image.
> 
> Tested platform: NT32/Quark IA32/OVMF IA32/OVMF IA32X64/Intel internal X64/
> Tested OS: UEFI Win10, UEFI Ubuntu 16.04.
> 
> Untested platform: ARM/AARCH64.
> Can ARM/AARCH64 owner help to take a look and try the ARM platform?
> 
> 
> Cc: Jeff Fan 
> Cc: Michael Kinney 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Star Zeng 
> Cc: Feng Tian 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> 
> Jiewen Yao (4):
>   UefiCpuPkg/CpuDxe: Add memory attribute setting.
>   ArmPkg/CpuDxe: Correct EFI_MEMORY_RO usage
>   MdeModulePkg/dec: add PcdImageProtectionPolicy.
>   MdeModulePkg/DxeCore: Add UEFI image protection.
> 
>  ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c  |   3 +-
>  ArmPkg/Drivers/CpuDxe/Arm/Mmu.c  |  14 +-
>  ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c |   5 +-
>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c |   3 +-
>  MdeModulePkg/Core/Dxe/DxeMain.h  |  53 ++
>  MdeModulePkg/Core/Dxe/DxeMain.inf|   5 +-
>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c  |   3 +-
>  MdeModulePkg/Core/Dxe/Image/Image.c  |   7 +-
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c| 735
> ++
>  MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c |  24 +-
>  MdeModulePkg/MdeModulePkg.dec|  10 +
>  UefiCpuPkg/CpuDxe/CpuDxe.c   | 141 ++--
>  UefiCpuPkg/CpuDxe/CpuDxe.inf |   5 +-
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 779
> 
>  UefiCpuPkg/CpuDxe/CpuPageTable.h | 113 +++
>  15 files changed, 1801 insertions(+), 99 deletions(-)
>  create mode 100644 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
>  create mode 100644 UefiCpuPkg/CpuDxe/CpuPageTable.c
>  create mode 100644 UefiCpuPkg/CpuDxe/CpuPageTable.h
> 
> --
> 2.7.4.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 0/4] DXE Memory Protection

[Yao, Jiewen]

For X86 CPU, the memory protection attribute goes to page table, the cache 
attribute goes to MTRR register.
Those are 2 difference resource, and can be set separately.

The high level pseudo code is below:
===
CacheAttribute = Attribute & CACHE_ATTRIBUTE_MASK
MemoryProtectionAttribute = Attribute & MEMORY_PROTECTION_ATTRIBUTE_MASK
If (CacheAttribute != 0) {
 SetCacheAttribute(CacheAttribute)
}
SetMemoryProtectionAttribute(MemoryProtectionAttribute)
===

NOTE: we need compare CacheAttribute == 0, because the cache attribute is an 
individual mask. 0x1 means UN_CACHE, 0x8 means WRITE_BACK. 0 is meaningless.
We do not compare MemoryProtectionAttribute == 0, because 0 is a valid memory 
protection attribute, which means to disable protection.

Before GCD sync, the DxeCore does not know the cache attribute, so that it can 
only set memory attribute. The CPU driver only modifies page table based upon 
MemoryProtectionAttribute and keep cache attribute untouched.


Thank you
Yao Jiewen

From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, February 9, 2017 5:52 AM
To: Yao, Jiewen 
Cc: Tian, Feng ; edk2-devel@lists.01.org; Leif Lindholm 
; Kinney, Michael D ; 
Fan, Jeff ; Zeng, Star 
Subject: Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

On 9 February 2017 at 13:19, Yao, Jiewen 
> wrote:
> Thank you Ard. I check the ARM code again.
>
>
>
> It seems the ARM CPU driver is similar as X86 CPU driver – it installs
> CpuArch protocol, then SyncCacheConfig.
>
> 
>
>   Status = gBS->InstallMultipleProtocolInterfaces (
>
> ,
>
> ,   ,
>
> , ,
>
> NULL
>
> );
>
>
>
>   //
>
>   // Make sure GCD and MMU settings match. This API calls
> gDS->SetMemorySpaceAttributes ()
>
>   // and that calls EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes, so this code
> needs to go
>
>   // after the protocol is installed
>
>   //
>
>   SyncCacheConfig ();
>
> 
>
>


Thanks a lot for taking the time to look at this.

>
> In my update, the DxeCore registers a CPU ARCH callback function to setup PE
> code/data section attribute there.
>
> At that time, the GCD attribute is not ready. As such, the cache attribute
> is all 0.
>
>
>
> After SyncCacheConfig(), the rest attribute setting will carry expected GCD
> update.
>

So how does x86 deal with this situation if it follows the same basic approach?

>
>
> Here is my thought:
>
> 1)   How about I set default PcdImageProtectionPolicy to be 0 for ARM in
> DEC file? As such the ARM platform is not impacted.
>
> 2)   At same time, someone from ARM can help to enhance the CPU driver
> to make it work.
>


> In my opinion, ASSERT() here is not the best idea. According to PI spec V2,
> 12.3, EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes(), the EFI_UNSUPPORTED is
> expected.
>
>
>
>
>
>
>
> Just for your reference, below is the OVMF log for X86 CPU:
>
> It sets page attribute only before GCD sync, then set both page attribute
> and cache attributes after GCD sync.
>
> 
>
> Loading driver at 0x7605000 EntryPoint=0x76066E9 CpuDxe.efi
>
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 70D9410
>
> ProtectUefiImageCommon - 0x70D91A8
>
>   - 0x07605000 - 0xE000
>
> CurrentPagingContext:
>
>   MachineType   - 0x14C
>
>   PageTableBase - 0x76A9000
>
>   Attributes- 0xC002
>
> InstallProtocolInterface: 26BACCB1-6F42-11D4-BCE7-0080C73C8881 7611128
>
> MemoryProtectionCpuArchProtocolNotify: ImageRecordCount - 0xA
>
> SetUefiImageMemoryAttributes - 0x076CE000 - 0x1000
> (0x4000)
>
> ConvertPageEntryAttribute 0x76CE023->0x876CE023
>
> SetUefiImageMemoryAttributes - 0x076CF000 - 0x00016000
> (0x0002)
>
> ConvertPageEntryAttribute 0x76CF023->0x76CF021
>
> ConvertPageEntryAttribute 0x76D0023->0x76D0021
>
> ConvertPageEntryAttribute 0x76D1023->0x76D1021
>
> ConvertPageEntryAttribute 0x76D2023->0x76D2021
>
> ConvertPageEntryAttribute 0x76D3023->0x76D3021
>
> ConvertPageEntryAttribute 0x76D4023->0x76D4021
>
> ConvertPageEntryAttribute 0x76D5023->0x76D5021
>
> ConvertPageEntryAttribute 0x76D6023->0x76D6021
>
> ConvertPageEntryAttribute 0x76D7023->0x76D7021
>
> ConvertPageEntryAttribute 0x76D8023->0x76D8021
>
> ConvertPageEntryAttribute 0x76D9023->0x76D9021
>
> ConvertPageEntryAttribute 0x76DA023->0x76DA021
>
> ConvertPageEntryAttribute 0x76DB023->0x76DB021
>
> ConvertPageEntryAttribute 0x76DC023->0x76DC021
>
> ConvertPageEntryAttribute 0x76DD023->0x76DD021
>
> ConvertPageEntryAttribute 0x76DE023->0x76DE021
>
> ConvertPageEntryAttribute 0x76DF023->0x76DF021
>
> ConvertPageEntryAttribute 

Re: [edk2] UEFI LinuxLoader app usage

[Jun Nie]

2017-02-09 21:44 GMT+08:00 Jun Nie :
>  I am new to UEFI and trying to boot Linux with LinuxLoader app. But I
> cannot find detail information for below questions. Could anyone point
> out where I can find related information or example code? Thanks for
> your time!
>
> 1. How to feed command line to this app so that ProcessAppCommandLine() can
> process it?
I know this app support parsing command line from shell. I am seeking
method to launch this app from BDS directly without shell but cannot
find where to specify value to LoadedImage->LoadOptions so that this
app can get command line from it.

>
> 2. And how should I generate  device path string for raw blockIO
> device with specified offset/size? UEFI 2.6 spec does not provide much
> information in 9.4.5 Media Device Path Rules.
>
> Thank you!
> Jun
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

[Yao, Jiewen]

Thank you Ard. I check the ARM code again.

It seems the ARM CPU driver is similar as X86 CPU driver - it installs CpuArch 
protocol, then SyncCacheConfig.

  Status = gBS->InstallMultipleProtocolInterfaces (
,
,   ,
, ,
NULL
);

  //
  // Make sure GCD and MMU settings match. This API calls 
gDS->SetMemorySpaceAttributes ()
  // and that calls EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes, so this code 
needs to go
  // after the protocol is installed
  //
  SyncCacheConfig ();


In my update, the DxeCore registers a CPU ARCH callback function to setup PE 
code/data section attribute there.
At that time, the GCD attribute is not ready. As such, the cache attribute is 
all 0.

After SyncCacheConfig(), the rest attribute setting will carry expected GCD 
update.

Here is my thought:

1)   How about I set default PcdImageProtectionPolicy to be 0 for ARM in 
DEC file? As such the ARM platform is not impacted.

2)   At same time, someone from ARM can help to enhance the CPU driver to 
make it work.
In my opinion, ASSERT() here is not the best idea. According to PI spec V2, 
12.3, EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes(), the EFI_UNSUPPORTED is 
expected.



Just for your reference, below is the OVMF log for X86 CPU:
It sets page attribute only before GCD sync, then set both page attribute and 
cache attributes after GCD sync.

Loading driver at 0x7605000 EntryPoint=0x76066E9 CpuDxe.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 70D9410
ProtectUefiImageCommon - 0x70D91A8
  - 0x07605000 - 0xE000
CurrentPagingContext:
  MachineType   - 0x14C
  PageTableBase - 0x76A9000
  Attributes- 0xC002
InstallProtocolInterface: 26BACCB1-6F42-11D4-BCE7-0080C73C8881 7611128
MemoryProtectionCpuArchProtocolNotify: ImageRecordCount - 0xA
SetUefiImageMemoryAttributes - 0x076CE000 - 0x1000 
(0x4000)
ConvertPageEntryAttribute 0x76CE023->0x876CE023
SetUefiImageMemoryAttributes - 0x076CF000 - 0x00016000 
(0x0002)
ConvertPageEntryAttribute 0x76CF023->0x76CF021
ConvertPageEntryAttribute 0x76D0023->0x76D0021
ConvertPageEntryAttribute 0x76D1023->0x76D1021
ConvertPageEntryAttribute 0x76D2023->0x76D2021
ConvertPageEntryAttribute 0x76D3023->0x76D3021
ConvertPageEntryAttribute 0x76D4023->0x76D4021
ConvertPageEntryAttribute 0x76D5023->0x76D5021
ConvertPageEntryAttribute 0x76D6023->0x76D6021
ConvertPageEntryAttribute 0x76D7023->0x76D7021
ConvertPageEntryAttribute 0x76D8023->0x76D8021
ConvertPageEntryAttribute 0x76D9023->0x76D9021
ConvertPageEntryAttribute 0x76DA023->0x76DA021
ConvertPageEntryAttribute 0x76DB023->0x76DB021
ConvertPageEntryAttribute 0x76DC023->0x76DC021
ConvertPageEntryAttribute 0x76DD023->0x76DD021
ConvertPageEntryAttribute 0x76DE023->0x76DE021
ConvertPageEntryAttribute 0x76DF023->0x76DF021
ConvertPageEntryAttribute 0x76E0023->0x76E0021
ConvertPageEntryAttribute 0x76E1023->0x76E1021
ConvertPageEntryAttribute 0x76E2003->0x76E2001
ConvertPageEntryAttribute 0x76E3023->0x76E3021
ConvertPageEntryAttribute 0x76E4023->0x76E4021
SetUefiImageMemoryAttributes - 0x076E5000 - 0xB000 
(0x4000)
ConvertPageEntryAttribute 0x76E5023->0x876E5023
ConvertPageEntryAttribute 0x76E6023->0x876E6023
ConvertPageEntryAttribute 0x76E7023->0x876E7023
ConvertPageEntryAttribute 0x76E8023->0x876E8023
ConvertPageEntryAttribute 0x76E9023->0x876E9023
ConvertPageEntryAttribute 0x76EA023->0x876EA023
ConvertPageEntryAttribute 0x76EB063->0x876EB063
ConvertPageEntryAttribute 0x76EC063->0x876EC063
ConvertPageEntryAttribute 0x76ED063->0x876ED063
ConvertPageEntryAttribute 0x76EE003->0x876EE003
ConvertPageEntryAttribute 0x76EF003->0x876EF003
SetUefiImageMemoryAttributes - 0x07637000 - 0x1000 
(0x4000)
ConvertPageEntryAttribute 0x7637063->0x87637063
SetUefiImageMemoryAttributes - 0x07638000 - 0x6000 
(0x0002)
ConvertPageEntryAttribute 0x7638063->0x7638061
ConvertPageEntryAttribute 0x7639063->0x7639061
ConvertPageEntryAttribute 0x763A063->0x763A061
ConvertPageEntryAttribute 0x763B063->0x763B061
ConvertPageEntryAttribute 0x763C063->0x763C061
ConvertPageEntryAttribute 0x763D063->0x763D061
SetUefiImageMemoryAttributes - 0x0763E000 - 0x5000 
(0x4000)
ConvertPageEntryAttribute 0x763E063->0x8763E063
ConvertPageEntryAttribute 0x763F063->0x8763F063
ConvertPageEntryAttribute 0x7640063->0x87640063
ConvertPageEntryAttribute 0x7641063->0x87641063
ConvertPageEntryAttribute 0x7642063->0x87642063
SetUefiImageMemoryAttributes - 0x0762E000 - 0x1000 
(0x4000)
ConvertPageEntryAttribute 

Re: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD PcdPteMemoryEncryptionAddressOrMask

[Laszlo Ersek]

On 02/09/17 10:17, Zeng, Star wrote:
> EFI_HOB_CPU?
> Is there discussion in PIWG for it?

None that I'm aware of.

Thanks
Laszlo

> 
> Thanks,
> Star
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Thursday, February 9, 2017 5:13 PM
> To: Zeng, Star ; Yao, Jiewen ; 
> Duran, Leo ; edk2-de...@ml01.01.org
> Cc: Tian, Feng ; Singh, Brijesh ; 
> Justen, Jordan L 
> Subject: Re: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD 
> PcdPteMemoryEncryptionAddressOrMask
> 
> On 02/09/17 06:26, Zeng, Star wrote:
>> Correct typo in below email.
>>
>> "about how to determine DXE is 32BITs or 64BITs" should be "about how 
>> to determine PEI is 32BITs or 64BITs".
>>
>> At that time, we were discussing if the code needs to allocate <4G 
>> ACPI table for PEI phase at S3 resume.
> 
> Indeed. Although OVMF X64 has a 64-bit PEI phase, that PEI phase can access 
> only <4G RAM. IIRC one suggestion was to introduce a new HOB for this, so 
> that PEI can advertise such a limitation to DXE.
> 
> Thanks
> Laszlo
> 
> 
>>
>> Thanks,
>> Star
>> -Original Message-
>> From: Zeng, Star
>> Sent: Thursday, February 9, 2017 1:12 PM
>> To: Laszlo Ersek ; Yao, Jiewen 
>> ; Duran, Leo ; 
>> edk2-de...@ml01.01.org
>> Cc: Tian, Feng ; Singh, Brijesh 
>> ; Justen, Jordan L ; 
>> Zeng, Star 
>> Subject: RE: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD 
>> PcdPteMemoryEncryptionAddressOrMask
>>
>> In fact, X64 DxeIplPeim does not refer PcdDxeIplSwitchToLongMode at all.
>>
>> DxeIpl.inf:
>> [FeaturePcd.IA32]
>>   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode  ## CONSUMES
>>
>> As I remember, I did a draft patch below before for the discussion about how 
>> to determine DXE is 32BITs or 64BITs in title "[edk2] [PATCH v3 2/4] 
>> IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed", I 
>> can't find the archive link any more.
>>
>> ---
>>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c | 5 +
>>  MdeModulePkg/MdeModulePkg.dec  | 4 +++-
>>  2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c 
>> b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
>> index 640..348e084 100644
>> --- a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
>> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
>> @@ -43,6 +43,11 @@ HandOffToDxeCore (
>>EFI_PEI_VECTOR_HANDOFF_INFO_PPI *VectorHandoffInfoPpi;
>>  
>>//
>> +  // It should be FALSE for both PEI and DXE are 64-bit.
>> +  //
>> +  ASSERT (PcdGetBool (PcdDxeIplSwitchToLongMode) == FALSE);
>> +
>> +  //
>>// Get Vector Hand-off Info PPI and build Guided HOB
>>//
>>Status = PeiServicesLocatePpi (
>> diff --git a/MdeModulePkg/MdeModulePkg.dec 
>> b/MdeModulePkg/MdeModulePkg.dec index af7bcab..4a73f7b 100644
>> --- a/MdeModulePkg/MdeModulePkg.dec
>> +++ b/MdeModulePkg/MdeModulePkg.dec
>> @@ -712,8 +712,10 @@
>>## Indicates if DxeIpl should switch to long mode to enter DXE phase.
>>#  It is assumed that 64-bit DxeCore is built in firmware if it is true; 
>> otherwise 32-bit DxeCore
>>#  is built in firmware.
>> +  #  And it should be FALSE for both PEI and DXE are 64-bit.
>>#   TRUE  - DxeIpl will load a 64-bit DxeCore and switch to long mode to 
>> hand over to DxeCore.
>> -  #   FALSE - DxeIpl will load a 32-bit DxeCore and perform stack switch to 
>> hand over to DxeCore.
>> +  #   FALSE - DxeIpl will load a 32-bit DxeCore and perform stack switch to 
>> hand over to DxeCore,
>> +  #   or both PEI and DXE are 64-bit.
>># @Prompt DxeIpl switch to long mode.
>>
>> gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|TRUE|BOOLEAN|
>> 0x0001003b
>>  
>> --
>>
>>
>> Thanks,
>> Star
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Thursday, February 9, 2017 3:48 AM
>> To: Yao, Jiewen ; Duran, Leo 
>> ; Zeng, Star ; 
>> edk2-de...@ml01.01.org
>> Cc: Tian, Feng ; Singh, Brijesh 
>> ; Justen, Jordan L 
>> Subject: Re: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD 
>> PcdPteMemoryEncryptionAddressOrMask
>>
>> On 02/08/17 19:20, Yao, Jiewen wrote:
>>> Got it.
>>>
>>>  
>>>
>>> If the means of PcdDxeIplSwitchtoLongMode  is unclear, we may add 
>>> more description to make it clear.
>>>
>>>  
>>>
>>> If we believe "PcdDxeIplSwitchtoLongMode  == DXE is Long mode" as 
>>> final conclusion, can we treat that as a bug and fix OVMF X64?
>>
>> I don't know how to "fix" that. What is there to fix?
>>
>> Flipping the PCD to TRUE in OVMF X64 would break OVMF X64, and likely OVMF 
>> 

[edk2] [PATCH] ShellPkg SmbiosView: Correct some outputs for Type 0/3/10

[Star Zeng]

Type 0: Update "EDD Enhanced Disk Driver)..." to
"EDD (Enhanced Disk Driver)..." for
STR_SMBIOSVIEW_PRINTINFO_EDD_ENHANCED_DRIVER

Type 3: Use L"  Laptop" instead of L"  LapTop" in
SystemEnclosureTypeTable to match SMBIOS spec.

Type 10: The BIT7 of Device Type is representing the
status of device whether it is enabled or disabled.
But current code is not considering the BIT7 and will
print "Undefined Value" for enabled device. Type 41
has same definition of Device Type, the code is
correct and will be applied to Type 10 by this patch.

Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c | 3 ++-
 ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c| 2 +-
 .../UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni| 2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
index 1d6002b92593..50d15ef1758e 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
@@ -570,7 +570,8 @@ SmbiosPrintStructure (
   UINTN NumOfDevice;
   NumOfDevice = (Struct->Type10->Hdr.Length - sizeof (SMBIOS_STRUCTURE)) / 
(2 * sizeof (UINT8));
   for (Index = 0; Index < NumOfDevice; Index++) {
-DisplayOnboardDeviceTypes (Struct->Type10->Device[Index].DeviceType, 
Option);
+ShellPrintEx(-1,-1,(((Struct->Type10->Device[Index].DeviceType) & 
0x80) != 0) ? L"Device Enabled\n": L"Device Disabled\n");
+DisplayOnboardDeviceTypes ((Struct->Type10->Device[Index].DeviceType) 
& 0x7F, Option);
 ShellPrintHiiEx(-1,-1,NULL,STRING_TOKEN 
(STR_SMBIOSVIEW_PRINTINFO_DESC_STRING), gShellDebug1HiiHandle);
 ShellPrintEx(-1,-1,L"%a\n",LibGetSmbiosString (Struct, 
Struct->Type10->Device[Index].DescriptionString));
   }
diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
index 02d9ab1f57b3..afea429b7aa3 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
@@ -166,7 +166,7 @@ TABLE_ITEM  SystemEnclosureTypeTable[] = {
   },
   {
 0x09,
-L"  LapTop"
+L"  Laptop"
   },
   {
 0x0A,
diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni
index 7d694536dbcd..2cd682630557 100644
--- 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni
+++ 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni
@@ -133,7 +133,7 @@
 #string STR_SMBIOSVIEW_PRINTINFO_SELECTED_BOOT_SUPPORTED#language 
en-US "Selectable Boot is supported\r\n"
 #string STR_SMBIOSVIEW_PRINTINFO_BIOS_ROM_SOCKETED  #language 
en-US "BIOS ROM is socketed\r\n"
 #string STR_SMBIOSVIEW_PRINTINFO_BOOT_FROM_PC_CARD  #language 
en-US "Boot From PC Card(PCMCIA)is supported\r\n"
-#string STR_SMBIOSVIEW_PRINTINFO_EDD_ENHANCED_DRIVER#language 
en-US "EDD Enhanced Disk Driver) Specification is supported\r\n"
+#string STR_SMBIOSVIEW_PRINTINFO_EDD_ENHANCED_DRIVER#language 
en-US "EDD (Enhanced Disk Driver) Specification is supported\r\n"
 #string STR_SMBIOSVIEW_PRINTINFO_JAPANESE_FLOPPY_NEC#language 
en-US "Int 13h - Japanese Floppy for NEC 9800 1.2mb (3.5\",1k Bytes/Sector, 360 
RPM) is supported\r\n"
 #string STR_SMBIOSVIEW_PRINTINFO_JAPANESE_FLOPPY_TOSHIBA#language 
en-US "Int 13h - Japanese Floppy for Toshiba 1.2mn (3.5\", 360 RPM) is 
supported\r\n"
 #string STR_SMBIOSVIEW_PRINTINFO_FLOPPY_SERVICES_SUPPORTED  #language 
en-US "Int 13h - 5.25\"/360KB Floppy Services are supported\r\n"
-- 
2.7.0.windows.1

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

[edk2] [PATCH] ShellPkg SmbiosView: Eliminate trailing " | " in PrintBitsInfo()

[Star Zeng]

Current PrintBitsInfo() will always print an additional trailing
" | " for the bit flags, for example,

Base Board Feature Flags: Hosting board |  Replaceable |

Th patch is to eliminate trailing " | " in PrintBitsInfo(), then
the output will be like below

Base Board Feature Flags: Hosting board |  Replaceable

Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 .../UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
index 282ba584c8c9..02d9ab1f57b3 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
@@ -3449,19 +3449,24 @@ PrintBitsInfo (
 
   UINTN   Index;
   UINT32  Value;
-  BOOLEAN NoInfo;
+  BOOLEAN FirstInfo;
 
-  NoInfo  = TRUE;
+  FirstInfo = TRUE;
   Value   = Bits;
   //
   // query the table and print information
   //
   for (Index = 0; Index < Number; Index++) {
 if (BIT (Value, Table[Index].Key) != 0) {
+  if (!FirstInfo) {
+//
+// If it is not first info, print the separator first.
+//
+Print (L" | ");
+  }
   Print (Table[Index].Info);
-  Print (L" | ");
 
-  NoInfo = FALSE;
+  FirstInfo = FALSE;
   //
   // clear the bit, for reserved bits test
   //
@@ -3469,7 +3474,10 @@ PrintBitsInfo (
 }
   }
 
-  if (NoInfo) {
+  //
+  // There is no any info if FirstInfo is still TRUE.
+  //
+  if (FirstInfo) {
 ShellPrintHiiEx(-1,-1,NULL,STRING_TOKEN 
(STR_SMBIOSVIEW_QUERYTABLE_NO_INFO), gShellDebug1HiiHandle);
   }
 
-- 
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 V3 0/4] DXE Memory Protection

[Ard Biesheuvel]

On 9 February 2017 at 09:09, Ard Biesheuvel  wrote:
> On 9 February 2017 at 08:49, Ard Biesheuvel  wrote:
>> On 9 February 2017 at 07:43, Yao, Jiewen  wrote:
>>> Hi Lindholm/Ard
>>> This version 3 contains both of your feedback before.
>>>
>>> If you can do me a favor to evaluated the impact to ARM, that will be great.
>>>
>>
>> I will take a look right away.
>>
>
> I am hitting the following assert as soon as ArmCpuDxe is loaded:
>
> Loading driver at 0x0005BE15000 EntryPoint=0x0005BE16048 ArmCpuDxe.efi
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 5B142398
> ProtectUefiImageCommon - 0x5B142140
>   - 0x5BE15000 - 0x0001
> InstallProtocolInterface: 26BACCB1-6F42-11D4-BCE7-0080C73C8881 5BE23008
> InstallProtocolInterface: AD651C7D-3C22-4DBF-92E8-38A7CDAE87B2 5BE230B0
> MemoryProtectionCpuArchProtocolNotify:
> ProtectUefiImageCommon - 0x5EF02400
>   - 0x5EEC4000 - 0x00042000
> SetUefiImageMemoryAttributes - 0x5EEC4000 - 0x1000
> (0x4000)
> EfiAttributeToArmAttribute: 0x4000 attributes is not supported.
> ASSERT [ArmCpuDxe]
> /home/ard/build/uefi-next/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c(220): 0
>
> The reason appears to be that the GCD memory descriptor retrieved in
> SetUefiImageMemoryAttributes() for this region has Attributes == 0
>
> I am digging further ...

Attached is the output of DEBUG_GCD
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD PcdPteMemoryEncryptionAddressOrMask

[Zeng, Star]

Seemingly not big problem since OVMF does not support 64BITs waking vector.

Thanks,
Star
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, February 9, 2017 5:10 PM
To: Zeng, Star ; Yao, Jiewen ; 
Duran, Leo ; edk2-de...@ml01.01.org
Cc: Tian, Feng ; Singh, Brijesh ; 
Justen, Jordan L 
Subject: Re: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD 
PcdPteMemoryEncryptionAddressOrMask

On 02/09/17 06:56, Zeng, Star wrote:
> Stick to current comments and code, OvmfPkg X64 has bug? J
> 
>  
> 
> PCD comments:
> 
> #
> It is assumed that 64-bit DxeCore is built in firmware if it is true; 
> otherwise 32-bit DxeCore
> 
>  
> 
> Code pieces in S3ResumePei, S3SaveStateDxe, SmmLockBoxPeiLib, etc:
> 
> // Both BIOS and OS wants 64bit vector
> 
> if (FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
> 
>   return TRUE;
> 
> }
> 
>  
> 
> //
> 
> // BIOS supports 64bit waking vector.
> //
> 
> if(FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
>   returnTRUE;
> 
> }
> 
>  
> 
> if ((sizeof(UINTN) == sizeof(UINT32)) && (FeaturePcdGet
> (PcdDxeIplSwitchToLongMode)) ) {
> 
>   //
> 
>  // 32 PEI + 64 DXE
> 
>  //
> 
>  
> 
>  
> 
> According to above, the patch I drafted is wrong.

That's too bad, because I agreed with it. :(

I can't start working on this right now, but if you guys think it's a big 
problem, please file an OvmfPkg BZ, and we'll have to audit all uses of 
PcdDxeIplSwitchToLongMode, to see what might break if we flip it to TRUE for 
OVMF X64.

Thanks
Laszlo

> 
>  
> 
> Thanks,
> 
> Star
> 
> *From:*Yao, Jiewen
> *Sent:* Thursday, February 9, 2017 1:23 PM
> *To:* Zeng, Star ; Laszlo Ersek 
> ; Duran, Leo ; 
> edk2-de...@ml01.01.org
> *Cc:* Tian, Feng ; Singh, Brijesh 
> ; Justen, Jordan L 
> *Subject:* RE: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD 
> PcdPteMemoryEncryptionAddressOrMask
> 
>  
> 
> I suggest we evaluate **all** usages of 
> PcdDxeIplSwitchToLongModebecause this is an incompatible change.
> 
>  
> 
> #
> It is assumed that 64-bit DxeCore is built in firmware if it is true; 
> otherwise 32-bit DxeCore
> 
>  
> 
> Thank you
> 
> Yao Jiewen
> 
>  
> 
> *From:*Zeng, Star
> *Sent:* Wednesday, February 8, 2017 9:12 PM
> *To:* Laszlo Ersek >; 
> Yao, Jiewen >; 
> Duran, Leo >; 
> edk2-de...@ml01.01.org 
> *Cc:* Tian, Feng >; 
> Singh, Brijesh >; 
> Justen, Jordan L  >; Zeng, Star  >
> *Subject:* RE: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD 
> PcdPteMemoryEncryptionAddressOrMask
> 
>  
> 
> In fact, X64 DxeIplPeim does not refer PcdDxeIplSwitchToLongMode at all.
> 
> DxeIpl.inf:
> [FeaturePcd.IA32]
>   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode  ## CONSUMES
> 
> As I remember, I did a draft patch below before for the discussion about how 
> to determine *PEI* is 32BITs or 64BITs in title "[edk2] [PATCH v3 2/4] 
> IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed", I can't 
> find the archive link any more.
> 
> ---
>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c | 5 +
>  MdeModulePkg/MdeModulePkg.dec  | 4 +++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c 
> b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> index 640..348e084 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> @@ -43,6 +43,11 @@ HandOffToDxeCore (
>EFI_PEI_VECTOR_HANDOFF_INFO_PPI *VectorHandoffInfoPpi;
>  
>//
> +  // It should be FALSE for both PEI and DXE are 64-bit.
> +  //
> +  ASSERT (PcdGetBool (PcdDxeIplSwitchToLongMode) == FALSE);
> +
> +  //
>// Get Vector Hand-off Info PPI and build Guided HOB
>//
>Status = PeiServicesLocatePpi (
> diff --git a/MdeModulePkg/MdeModulePkg.dec 
> b/MdeModulePkg/MdeModulePkg.dec index af7bcab..4a73f7b 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -712,8 +712,10 @@
>## Indicates if DxeIpl should switch to long mode to enter DXE phase.
>#  It is assumed that 64-bit DxeCore is built in firmware if it is true; 
> otherwise 32-bit DxeCore
>#  is built in firmware.
> +  #  And it should be FALSE for both PEI and DXE are 64-bit.
>#   TRUE  - DxeIpl will load a 64-bit DxeCore and switch to long mode to 
> hand over to DxeCore.
> -  #   FALSE - DxeIpl will 

Re: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD PcdPteMemoryEncryptionAddressOrMask

[Zeng, Star]

EFI_HOB_CPU?
Is there discussion in PIWG for it?

Thanks,
Star
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, February 9, 2017 5:13 PM
To: Zeng, Star ; Yao, Jiewen ; 
Duran, Leo ; edk2-de...@ml01.01.org
Cc: Tian, Feng ; Singh, Brijesh ; 
Justen, Jordan L 
Subject: Re: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD 
PcdPteMemoryEncryptionAddressOrMask

On 02/09/17 06:26, Zeng, Star wrote:
> Correct typo in below email.
> 
> "about how to determine DXE is 32BITs or 64BITs" should be "about how 
> to determine PEI is 32BITs or 64BITs".
> 
> At that time, we were discussing if the code needs to allocate <4G 
> ACPI table for PEI phase at S3 resume.

Indeed. Although OVMF X64 has a 64-bit PEI phase, that PEI phase can access 
only <4G RAM. IIRC one suggestion was to introduce a new HOB for this, so that 
PEI can advertise such a limitation to DXE.

Thanks
Laszlo


> 
> Thanks,
> Star
> -Original Message-
> From: Zeng, Star
> Sent: Thursday, February 9, 2017 1:12 PM
> To: Laszlo Ersek ; Yao, Jiewen 
> ; Duran, Leo ; 
> edk2-de...@ml01.01.org
> Cc: Tian, Feng ; Singh, Brijesh 
> ; Justen, Jordan L ; 
> Zeng, Star 
> Subject: RE: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD 
> PcdPteMemoryEncryptionAddressOrMask
> 
> In fact, X64 DxeIplPeim does not refer PcdDxeIplSwitchToLongMode at all.
> 
> DxeIpl.inf:
> [FeaturePcd.IA32]
>   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode  ## CONSUMES
> 
> As I remember, I did a draft patch below before for the discussion about how 
> to determine DXE is 32BITs or 64BITs in title "[edk2] [PATCH v3 2/4] 
> IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed", I can't 
> find the archive link any more.
> 
> ---
>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c | 5 +
>  MdeModulePkg/MdeModulePkg.dec  | 4 +++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c 
> b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> index 640..348e084 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> @@ -43,6 +43,11 @@ HandOffToDxeCore (
>EFI_PEI_VECTOR_HANDOFF_INFO_PPI *VectorHandoffInfoPpi;
>  
>//
> +  // It should be FALSE for both PEI and DXE are 64-bit.
> +  //
> +  ASSERT (PcdGetBool (PcdDxeIplSwitchToLongMode) == FALSE);
> +
> +  //
>// Get Vector Hand-off Info PPI and build Guided HOB
>//
>Status = PeiServicesLocatePpi (
> diff --git a/MdeModulePkg/MdeModulePkg.dec 
> b/MdeModulePkg/MdeModulePkg.dec index af7bcab..4a73f7b 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -712,8 +712,10 @@
>## Indicates if DxeIpl should switch to long mode to enter DXE phase.
>#  It is assumed that 64-bit DxeCore is built in firmware if it is true; 
> otherwise 32-bit DxeCore
>#  is built in firmware.
> +  #  And it should be FALSE for both PEI and DXE are 64-bit.
>#   TRUE  - DxeIpl will load a 64-bit DxeCore and switch to long mode to 
> hand over to DxeCore.
> -  #   FALSE - DxeIpl will load a 32-bit DxeCore and perform stack switch to 
> hand over to DxeCore.
> +  #   FALSE - DxeIpl will load a 32-bit DxeCore and perform stack switch to 
> hand over to DxeCore,
> +  #   or both PEI and DXE are 64-bit.
># @Prompt DxeIpl switch to long mode.
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|TRUE|BOOLEAN|
> 0x0001003b
>  
> --
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, February 9, 2017 3:48 AM
> To: Yao, Jiewen ; Duran, Leo 
> ; Zeng, Star ; 
> edk2-de...@ml01.01.org
> Cc: Tian, Feng ; Singh, Brijesh 
> ; Justen, Jordan L 
> Subject: Re: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD 
> PcdPteMemoryEncryptionAddressOrMask
> 
> On 02/08/17 19:20, Yao, Jiewen wrote:
>> Got it.
>>
>>  
>>
>> If the means of PcdDxeIplSwitchtoLongMode  is unclear, we may add 
>> more description to make it clear.
>>
>>  
>>
>> If we believe "PcdDxeIplSwitchtoLongMode  == DXE is Long mode" as 
>> final conclusion, can we treat that as a bug and fix OVMF X64?
> 
> I don't know how to "fix" that. What is there to fix?
> 
> Flipping the PCD to TRUE in OVMF X64 would break OVMF X64, and likely OVMF 
> Ia32X64 too. For two reasons:
> 
> 
> (1) Toggling the PCD would alter the behavior of the DXE IPL PEIM and/or the 
> DXE Core, and that behavior has never ever been tested with OVMF X64.
> 
> The 

Re: [edk2] Sourceforge svn mirror of edk2

[Laszlo Ersek]

On 02/09/17 04:49, Gao, Liming wrote:
> Hi, all
>   Edk2 svn mirror works now!
> 
> Thanks
> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
>> Liming
>> Sent: Thursday, February 09, 2017 9:54 AM
>> To: Laszlo Ersek ; Shifflett, Joseph
>> 
>> Cc: edk2-devel@lists.01.org 
>> Subject: Re: [edk2] Sourceforge svn mirror of edk2
>>
>> Recently, our auto sync machine meets with some issue. We are working on it
>> to let it work back asap.
>>
>> Long term goal is to stop svn, and everyone uses edk2 git.

Hm, I apologize, I honestly believed we were past that point. Apparently
not just yet :)

Sorry about the misinformation.

Laszlo

>> Thanks
>> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Wednesday, February 8, 2017 11:18 PM
>> To: Shifflett, Joseph 
>> Cc: edk2-devel@lists.01.org 
>> Subject: Re: [edk2] Sourceforge svn mirror of edk2
>>
>> On 02/08/17 16:00, Shifflett, Joseph wrote:
>>> I apologize if this is not the best list.
>>
>> It is the correct list, yes.
>>
>>>
>>> There hasn't been a commit that was cherrypicked from the git repo
>>> into the sourceforge svn repo since 2/3.
>>>
>>> This was an automated process for the last year or two.  Was it
>>> intentionally discontinued?
>>
>> Yes, it was intentionally discontinued.
>>
>> Official Wiki article about the git-based development workflow:
>>
>> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-
>> Process
>>
>> (See also further articles linked from therein.)
>>
>> My personal recommendations (long article):
>>
>> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-
>> guide-for-edk2-contributors-and-maintainers
>>
>> 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

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

Re: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD PcdPteMemoryEncryptionAddressOrMask

[Laszlo Ersek]

On 02/09/17 06:26, Zeng, Star wrote:
> Correct typo in below email.
> 
> "about how to determine DXE is 32BITs or 64BITs" should be "about how
> to determine PEI is 32BITs or 64BITs".
> 
> At that time, we were discussing if the code needs to allocate <4G
> ACPI table for PEI phase at S3 resume.

Indeed. Although OVMF X64 has a 64-bit PEI phase, that PEI phase can
access only <4G RAM. IIRC one suggestion was to introduce a new HOB for
this, so that PEI can advertise such a limitation to DXE.

Thanks
Laszlo


> 
> Thanks,
> Star
> -Original Message-
> From: Zeng, Star 
> Sent: Thursday, February 9, 2017 1:12 PM
> To: Laszlo Ersek ; Yao, Jiewen ; 
> Duran, Leo ; edk2-de...@ml01.01.org
> Cc: Tian, Feng ; Singh, Brijesh ; 
> Justen, Jordan L ; Zeng, Star 
> Subject: RE: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD 
> PcdPteMemoryEncryptionAddressOrMask
> 
> In fact, X64 DxeIplPeim does not refer PcdDxeIplSwitchToLongMode at all.
> 
> DxeIpl.inf:
> [FeaturePcd.IA32]
>   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode  ## CONSUMES
> 
> As I remember, I did a draft patch below before for the discussion about how 
> to determine DXE is 32BITs or 64BITs in title "[edk2] [PATCH v3 2/4] 
> IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed", I can't 
> find the archive link any more.
> 
> ---
>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c | 5 +
>  MdeModulePkg/MdeModulePkg.dec  | 4 +++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c 
> b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> index 640..348e084 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> @@ -43,6 +43,11 @@ HandOffToDxeCore (
>EFI_PEI_VECTOR_HANDOFF_INFO_PPI *VectorHandoffInfoPpi;
>  
>//
> +  // It should be FALSE for both PEI and DXE are 64-bit.
> +  //
> +  ASSERT (PcdGetBool (PcdDxeIplSwitchToLongMode) == FALSE);
> +
> +  //
>// Get Vector Hand-off Info PPI and build Guided HOB
>//
>Status = PeiServicesLocatePpi (
> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec 
> index af7bcab..4a73f7b 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -712,8 +712,10 @@
>## Indicates if DxeIpl should switch to long mode to enter DXE phase.
>#  It is assumed that 64-bit DxeCore is built in firmware if it is true; 
> otherwise 32-bit DxeCore
>#  is built in firmware.
> +  #  And it should be FALSE for both PEI and DXE are 64-bit.
>#   TRUE  - DxeIpl will load a 64-bit DxeCore and switch to long mode to 
> hand over to DxeCore.
> -  #   FALSE - DxeIpl will load a 32-bit DxeCore and perform stack switch to 
> hand over to DxeCore.
> +  #   FALSE - DxeIpl will load a 32-bit DxeCore and perform stack switch to 
> hand over to DxeCore,
> +  #   or both PEI and DXE are 64-bit.
># @Prompt DxeIpl switch to long mode.
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|TRUE|BOOLEAN|0x0001003b
>  
> --
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, February 9, 2017 3:48 AM
> To: Yao, Jiewen ; Duran, Leo ; Zeng, 
> Star ; edk2-de...@ml01.01.org
> Cc: Tian, Feng ; Singh, Brijesh ; 
> Justen, Jordan L 
> Subject: Re: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD 
> PcdPteMemoryEncryptionAddressOrMask
> 
> On 02/08/17 19:20, Yao, Jiewen wrote:
>> Got it.
>>
>>  
>>
>> If the means of PcdDxeIplSwitchtoLongMode  is unclear, we may add more 
>> description to make it clear.
>>
>>  
>>
>> If we believe "PcdDxeIplSwitchtoLongMode  == DXE is Long mode" as 
>> final conclusion, can we treat that as a bug and fix OVMF X64?
> 
> I don't know how to "fix" that. What is there to fix?
> 
> Flipping the PCD to TRUE in OVMF X64 would break OVMF X64, and likely OVMF 
> Ia32X64 too. For two reasons:
> 
> 
> (1) Toggling the PCD would alter the behavior of the DXE IPL PEIM and/or the 
> DXE Core, and that behavior has never ever been tested with OVMF X64.
> 
> The PcdDxeIplSwitchToLongMode=FALSE setting in the X64 DSC dates back to:
> 
>   commit 8fa729a8b1401f01c6fd8ddbcab45e4a4904fa9a
>   Author: lgao4 
>   Date:   Mon Mar 15 01:40:59 2010 +
> 
>   Merge the same type PCD section.
> 
>   git-svn-id: 
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10243 
> 6f19259b-4bc3-4df7-8a09-765794883524
> 
> and before that, to:
> 
>   commit 49ba9447c92d6fca214476381107a180d08e59d1
>   Author: jljusten 
>   Date:   Wed 

Re: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD PcdPteMemoryEncryptionAddressOrMask

[Laszlo Ersek]

On 02/09/17 06:56, Zeng, Star wrote:
> Stick to current comments and code, OvmfPkg X64 has bug? J
> 
>  
> 
> PCD comments:
> 
> #
> It is assumed that 64-bit DxeCore is built in firmware if it is true; 
> otherwise 32-bit DxeCore
> 
>  
> 
> Code pieces in S3ResumePei, S3SaveStateDxe, SmmLockBoxPeiLib, etc:
> 
> // Both BIOS and OS wants 64bit vector
> 
> if (FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
> 
>   return TRUE;
> 
> }
> 
>  
> 
> //
> 
> // BIOS supports 64bit waking vector.
> //
> 
> if(FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
>   returnTRUE;
> 
> }
> 
>  
> 
> if ((sizeof(UINTN) == sizeof(UINT32)) && (FeaturePcdGet
> (PcdDxeIplSwitchToLongMode)) ) {
> 
>   //
> 
>  // 32 PEI + 64 DXE
> 
>  //
> 
>  
> 
>  
> 
> According to above, the patch I drafted is wrong.

That's too bad, because I agreed with it. :(

I can't start working on this right now, but if you guys think it's a
big problem, please file an OvmfPkg BZ, and we'll have to audit all uses
of PcdDxeIplSwitchToLongMode, to see what might break if we flip it to
TRUE for OVMF X64.

Thanks
Laszlo

> 
>  
> 
> Thanks,
> 
> Star
> 
> *From:*Yao, Jiewen
> *Sent:* Thursday, February 9, 2017 1:23 PM
> *To:* Zeng, Star ; Laszlo Ersek
> ; Duran, Leo ; edk2-de...@ml01.01.org
> *Cc:* Tian, Feng ; Singh, Brijesh
> ; Justen, Jordan L 
> *Subject:* RE: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD
> PcdPteMemoryEncryptionAddressOrMask
> 
>  
> 
> I suggest we evaluate **all** usages of PcdDxeIplSwitchToLongModebecause
> this is an incompatible change.
> 
>  
> 
> #
> It is assumed that 64-bit DxeCore is built in firmware if it is true; 
> otherwise 32-bit DxeCore
> 
>  
> 
> Thank you
> 
> Yao Jiewen
> 
>  
> 
> *From:*Zeng, Star
> *Sent:* Wednesday, February 8, 2017 9:12 PM
> *To:* Laszlo Ersek >; Yao,
> Jiewen >; Duran, Leo
> >; edk2-de...@ml01.01.org
> 
> *Cc:* Tian, Feng >;
> Singh, Brijesh >;
> Justen, Jordan L  >; Zeng, Star  >
> *Subject:* RE: [edk2] [PATCH] MdeModulePkg: Add dynamic PCD
> PcdPteMemoryEncryptionAddressOrMask
> 
>  
> 
> In fact, X64 DxeIplPeim does not refer PcdDxeIplSwitchToLongMode at all.
> 
> DxeIpl.inf:
> [FeaturePcd.IA32]
>   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode  ## CONSUMES
> 
> As I remember, I did a draft patch below before for the discussion about how 
> to determine *PEI* is 32BITs or 64BITs in title "[edk2] [PATCH v3 2/4] 
> IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed", I can't 
> find the archive link any more.
> 
> ---
>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c | 5 +
>  MdeModulePkg/MdeModulePkg.dec  | 4 +++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c 
> b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> index 640..348e084 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
> @@ -43,6 +43,11 @@ HandOffToDxeCore (
>EFI_PEI_VECTOR_HANDOFF_INFO_PPI *VectorHandoffInfoPpi;
>  
>//
> +  // It should be FALSE for both PEI and DXE are 64-bit.
> +  //
> +  ASSERT (PcdGetBool (PcdDxeIplSwitchToLongMode) == FALSE);
> +
> +  //
>// Get Vector Hand-off Info PPI and build Guided HOB
>//
>Status = PeiServicesLocatePpi (
> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index af7bcab..4a73f7b 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -712,8 +712,10 @@
>## Indicates if DxeIpl should switch to long mode to enter DXE phase.
>#  It is assumed that 64-bit DxeCore is built in firmware if it is true; 
> otherwise 32-bit DxeCore
>#  is built in firmware.
> +  #  And it should be FALSE for both PEI and DXE are 64-bit.
>#   TRUE  - DxeIpl will load a 64-bit DxeCore and switch to long mode to 
> hand over to DxeCore.
> -  #   FALSE - DxeIpl will load a 32-bit DxeCore and perform stack switch to 
> hand over to DxeCore.
> +  #   FALSE - DxeIpl will load a 32-bit DxeCore and perform stack switch to 
> hand over to DxeCore,
> +  #   or both PEI and DXE are 64-bit.
># @Prompt DxeIpl switch to long mode.
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|TRUE|BOOLEAN|0x0001003b
>  
> --
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Thursday, February 9, 2017 3:48 AM
> To: Yao, Jiewen  

Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

[Ard Biesheuvel]

On 9 February 2017 at 08:49, Ard Biesheuvel  wrote:
> On 9 February 2017 at 07:43, Yao, Jiewen  wrote:
>> Hi Lindholm/Ard
>> This version 3 contains both of your feedback before.
>>
>> If you can do me a favor to evaluated the impact to ARM, that will be great.
>>
>
> I will take a look right away.
>

I am hitting the following assert as soon as ArmCpuDxe is loaded:

Loading driver at 0x0005BE15000 EntryPoint=0x0005BE16048 ArmCpuDxe.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 5B142398
ProtectUefiImageCommon - 0x5B142140
  - 0x5BE15000 - 0x0001
InstallProtocolInterface: 26BACCB1-6F42-11D4-BCE7-0080C73C8881 5BE23008
InstallProtocolInterface: AD651C7D-3C22-4DBF-92E8-38A7CDAE87B2 5BE230B0
MemoryProtectionCpuArchProtocolNotify:
ProtectUefiImageCommon - 0x5EF02400
  - 0x5EEC4000 - 0x00042000
SetUefiImageMemoryAttributes - 0x5EEC4000 - 0x1000
(0x4000)
EfiAttributeToArmAttribute: 0x4000 attributes is not supported.
ASSERT [ArmCpuDxe]
/home/ard/build/uefi-next/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c(220): 0

The reason appears to be that the GCD memory descriptor retrieved in
SetUefiImageMemoryAttributes() for this region has Attributes == 0

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

Re: [edk2] [PATCH v3] OvmfPkg/QemuBootOrderLib: Fix NOOPT build failure

[Laszlo Ersek]

On 02/09/17 03:08, Dandan Bi wrote:
> This patch is to fix the IA32/NOOPT/VS Toolchain build failure.
> The VS2015 failure log as below:
> QemuBootOrderLib.lib(ExtraRootBusMap.obj) : 
> error LNK2001: unresolved external symbol __allmul
> s:\..\Build\OvmfIa32\NOOPT_VS2015\IA32\MdeModulePkg\
> Universal\BdsDxe\BdsDxe\DEBUG\BdsDxe.dll : 
> fatal error LNK1120: 1 unresolved externals
> NMAKE : fatal error U1077: 
> '"C:\Program Files\Microsoft Visual Studio 14.0\Vc\bin\link.exe"' : 
> return code '0x460'
> Stop.

Ah! So after all, it is the 64-bit multiplication implicit to the
subscripting by a UINT64! That's something I'll have to keep in mind.

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> 
> Notes:
>   V3: Add VS compiler error message in commit log.
> 
> ---
>  OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.c 
> b/OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.c
> index ec42214..70ba161 100644
> --- a/OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.c
> +++ b/OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.c
> @@ -306,8 +306,8 @@ MapRootBusPosToBusNr (
>  return EFI_INVALID_PARAMETER;
>}
>if (RootBusPos > ExtraRootBusMap->Count) {
>  return EFI_NOT_FOUND;
>}
> -  *RootBusNr = ExtraRootBusMap->BusNumbers[RootBusPos - 1];
> +  *RootBusNr = ExtraRootBusMap->BusNumbers[(UINTN)RootBusPos - 1];
>return EFI_SUCCESS;
>  }
> 

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

Re: [edk2] [PATCH V3 0/4] DXE Memory Protection

[Ard Biesheuvel]

On 9 February 2017 at 07:43, Yao, Jiewen  wrote:
> Hi Lindholm/Ard
> This version 3 contains both of your feedback before.
>
> If you can do me a favor to evaluated the impact to ARM, that will be great.
>

I will take a look right away.

> Thank you
> Yao Jiewen
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiewen
>> Yao
>> Sent: Wednesday, February 8, 2017 11:20 PM
>> To: edk2-devel@lists.01.org
>> Cc: Tian, Feng ; Ard Biesheuvel
>> ; Leif Lindholm ; 
>> Kinney,
>> Michael D ; Fan, Jeff ; Zeng,
>> Star 
>> Subject: [edk2] [PATCH V3 0/4] DXE Memory Protection
>>
>>  V3 
>> 1) Add PCD for policy control (feedback from Ard Biesheuvel)
>> (Discussed with Mike Kinney)
>> +  #BIT0   - Image from unknown device. 
>> +  #BIT1   - Image from firmware volume.
>> +  # @Prompt Set image protection policy.
>> +  # @ValidRange 0x8002 | 0x - 0x001F
>> +
>> gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy|0x0002|UIN
>> T32|0x1047
>>
>> 2) Remove unused function in CpuDxe.(feedback from Liming Gao)
>> 3) Add commit log on link option assumption (feedback from Feng Tian)
>>
>>  V2 
>> 1) Clean up ArmPkg, (feedback from Leif Lindholm)
>>
>>  V1 
>> This series patch provides capability to protect PE/COFF image
>> in DXE memory.
>> If the UEFI image is page aligned, the image code section is set to read
>> only and the image data section is set to non-executable.
>>
>> The DxeCore calls CpuArchProtocol->SetMemoryAttributes() to protect
>> the image.
>>
>> Tested platform: NT32/Quark IA32/OVMF IA32/OVMF IA32X64/Intel internal X64/
>> Tested OS: UEFI Win10, UEFI Ubuntu 16.04.
>>
>> Untested platform: ARM/AARCH64.
>> Can ARM/AARCH64 owner help to take a look and try the ARM platform?
>>
>>
>> Cc: Jeff Fan 
>> Cc: Michael Kinney 
>> Cc: Leif Lindholm 
>> Cc: Ard Biesheuvel 
>> Cc: Star Zeng 
>> Cc: Feng Tian 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Jiewen Yao 
>>
>> Jiewen Yao (4):
>>   UefiCpuPkg/CpuDxe: Add memory attribute setting.
>>   ArmPkg/CpuDxe: Correct EFI_MEMORY_RO usage
>>   MdeModulePkg/dec: add PcdImageProtectionPolicy.
>>   MdeModulePkg/DxeCore: Add UEFI image protection.
>>
>>  ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c  |   3 +-
>>  ArmPkg/Drivers/CpuDxe/Arm/Mmu.c  |  14 +-
>>  ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c |   5 +-
>>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c |   3 +-
>>  MdeModulePkg/Core/Dxe/DxeMain.h  |  53 ++
>>  MdeModulePkg/Core/Dxe/DxeMain.inf|   5 +-
>>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c  |   3 +-
>>  MdeModulePkg/Core/Dxe/Image/Image.c  |   7 +-
>>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c| 735
>> ++
>>  MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c |  24 +-
>>  MdeModulePkg/MdeModulePkg.dec|  10 +
>>  UefiCpuPkg/CpuDxe/CpuDxe.c   | 141 ++--
>>  UefiCpuPkg/CpuDxe/CpuDxe.inf |   5 +-
>>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 779
>> 
>>  UefiCpuPkg/CpuDxe/CpuPageTable.h | 113 +++
>>  15 files changed, 1801 insertions(+), 99 deletions(-)
>>  create mode 100644 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
>>  create mode 100644 UefiCpuPkg/CpuDxe/CpuPageTable.c
>>  create mode 100644 UefiCpuPkg/CpuDxe/CpuPageTable.h
>>
>> --
>> 2.7.4.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