Re: [edk2] [PATCH 2/2] MdeModulePkg/SdDxe: Demote DEBUG print to DEBUG_BLKIO

[Wu, Hao A]

Thanks for the catch. I will update the commit log when pushing this change.

Best Regards,
Hao Wu


> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, June 12, 2018 1:07 PM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Ard Biesheuvel; Dong, Eric; Zeng, Star
> Subject: RE: [PATCH 2/2] MdeModulePkg/SdDxe: Demote DEBUG print to
> DEBUG_BLKIO
> 
> "to DEBUG_INFO" should be "DEBUG_BLKIO".
> 
> With that updated, Reviewed-by: Star Zeng 
> 
> -Original Message-
> From: Wu, Hao A
> Sent: Tuesday, June 12, 2018 11:37 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ard Biesheuvel
> ; Zeng, Star ; Dong, Eric
> 
> Subject: [PATCH 2/2] MdeModulePkg/SdDxe: Demote DEBUG print to
> DEBUG_BLKIO
> 
> Similar to commit 9dca2105ad960c9946d7cc2ece40f65e1999dac7, lower the
> priority of the DEBUG print in SDReadWrite() to DEBUG_INFO.
> 
> Cc: Ard Biesheuvel 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c
> b/MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c
> index 516c3e7042..b8d115abac 100644
> --- a/MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c
> +++ b/MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c
> @@ -1,7 +1,7 @@
>  /** @file
>The helper functions for BlockIo and BlockIo2 protocol.
> 
> -  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2015 - 2018, 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 @@ -670,7 +670,7 @@ SdReadWrite (
>  if (EFI_ERROR (Status)) {
>return Status;
>  }
> -DEBUG ((EFI_D_INFO, "Sd%a(): Lba 0x%x BlkNo 0x%x Event %p with %r\n",
> IsRead ? "Read" : "Write", Lba, BlockNum, Token->Event, Status));
> +DEBUG ((DEBUG_BLKIO, "Sd%a(): Lba 0x%x BlkNo 0x%x Event %p with
> + %r\n", IsRead ? "Read" : "Write", Lba, BlockNum, Token->Event,
> + Status));
> 
>  Lba   += BlockNum;
>  Buffer = (UINT8*)Buffer + BufferSize;
> --
> 2.12.0.windows.1

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

Re: [edk2] Crc32 Calculation Miss

[Guy Raviv]

I need to reach the pre memory code. Is it also loaded to the RAM(even
though it is already been executed?)

On Mon, 11 Jun 2018, 18:44 Gao, Liming,  wrote:

> In pre memory, PEI code run in flash. After memory is ready, PEI code will
> be loaded into memory. There is no interface to access the whole flash
> data. But, you can access the firmware image that contains PEI and DXE
> driver. In PEI phase, you can locate FvInfoPpi
> (gEfiPeiFirmwareVolumeInfoPpiGuid) to get FV image base address and size;
> in DXE phase, you can locate FVB protocol
> (gEfiFirmwareVolumeBlockProtocolGuid) to get FV image base address and
> size.
>
>
>
> *From:* Guy Raviv [mailto:guyrav...@gmail.com]
> *Sent:* Monday, June 11, 2018 4:38 PM
> *To:* Gao, Liming 
> *Cc:* edk2-devel@lists.01.org
> *Subject:* Re: [edk2] Crc32 Calculation Miss
>
>
>
> EFI_CALCULATE_CRC32()  just calculate the crc for the given address and
> size.
>
>
>
> my question is whether PEI *code *is loaded into the RAM or not.
>
> if it doesn't which seems reasonable, how can i reach it? some interface
> for accessing the whole flash data.
>
>
>
> Thanks,
>
>
>
> On Mon, Jun 11, 2018 at 5:34 AM Gao, Liming  wrote:
>
> Guy:
>
>   Does EFI_CALCULATE_CRC32() cover the flash data that includes PEI
> module?
>
>
>
> Thanks
>
> Liming
>
> *From:* Guy Raviv [mailto:guyrav...@gmail.com]
> *Sent:* Sunday, June 10, 2018 2:59 PM
> *To:* Gao, Liming 
> *Cc:* edk2-devel@lists.01.org
> *Subject:* Re: [edk2] Crc32 Calculation Miss
>
>
>
> Update -  it seems that only in the Pei modules a code change doesn't
> change the crc.
>
> Does it make sense?
>
> if so, is there any interface to calculate the flash data itself in the
> Dxe phase?
>
>
>
> Thanks!
>
> Guy
>
>
>
> On Thu, Jun 7, 2018 at 9:34 AM Guy Raviv  wrote:
>
> Hi Gao,
>
>
>
> I used the EFI_CALCULATE_CRC32 function from
> edkCompatibilityPkg\Foundation.
>
>
>
> Thanks,
>
>
>
> Guy
>
>
>
> On Wed, Jun 6, 2018 at 6:00 PM, Gao, Liming  wrote:
>
> Do you use CalculateCrc32() in BaseLib to calculate CRC32 value for the
> different buffer?
>
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Guy Raviv
> > Sent: Wednesday, June 6, 2018 10:18 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] Crc32 Calculation Miss
> >
> > Hi Everyone,
> >
> > I have an odd problem.
> > In a specific module in my code (MRC training), code modification doesn't
> > change the BIOS Crc calculation.
> > 1. i checked in my project's fdf file if the FV base address and region
> > size defined are the same as the parameters i'm putting in the
> calculation.
> > 2. i also compared two different binaries and found they are exactly the
> > same.
> >
> > does anyone have any idea what can be wrong here or where should i check?
> >
> > Thanks,
> > Guy
>
> > ___
> > 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 2/2] MdeModulePkg/SdDxe: Demote DEBUG print to DEBUG_BLKIO

[Zeng, Star]

"to DEBUG_INFO" should be "DEBUG_BLKIO".

With that updated, Reviewed-by: Star Zeng 

-Original Message-
From: Wu, Hao A 
Sent: Tuesday, June 12, 2018 11:37 AM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Ard Biesheuvel ; 
Zeng, Star ; Dong, Eric 
Subject: [PATCH 2/2] MdeModulePkg/SdDxe: Demote DEBUG print to DEBUG_BLKIO

Similar to commit 9dca2105ad960c9946d7cc2ece40f65e1999dac7, lower the priority 
of the DEBUG print in SDReadWrite() to DEBUG_INFO.

Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c 
b/MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c
index 516c3e7042..b8d115abac 100644
--- a/MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c
+++ b/MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c
@@ -1,7 +1,7 @@
 /** @file
   The helper functions for BlockIo and BlockIo2 protocol.
 
-  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2015 - 2018, 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 @@ -670,7 +670,7 @@ SdReadWrite (
 if (EFI_ERROR (Status)) {
   return Status;
 }
-DEBUG ((EFI_D_INFO, "Sd%a(): Lba 0x%x BlkNo 0x%x Event %p with %r\n", 
IsRead ? "Read" : "Write", Lba, BlockNum, Token->Event, Status));
+DEBUG ((DEBUG_BLKIO, "Sd%a(): Lba 0x%x BlkNo 0x%x Event %p with 
+ %r\n", IsRead ? "Read" : "Write", Lba, BlockNum, Token->Event, 
+ Status));
 
 Lba   += BlockNum;
 Buffer = (UINT8*)Buffer + BufferSize;
--
2.12.0.windows.1

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

Re: [edk2] [PATCH 1/2] MdeModulePkg/NvmExpressDxe: Adjust R/W DEBUG prints to BLKIO level

[Zeng, Star]

Reviewed-by: Star Zeng 

-Original Message-
From: Wu, Hao A 
Sent: Tuesday, June 12, 2018 11:37 AM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Ard Biesheuvel ; 
Zeng, Star ; Dong, Eric 
Subject: [PATCH 1/2] MdeModulePkg/NvmExpressDxe: Adjust R/W DEBUG prints to 
BLKIO level

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

Adjust the DEBUG prints within function:
NvmeRead(), NvmeWrite(), AsyncNvmeRead() and AsyncNvmeWrite()

to DEBUG_BLKIO for the consistency with other storage device drivers (e.g. ATA, 
USB and etc.).

Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c
index 734e1286c6..6c415109c1 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c
@@ -2,7 +2,7 @@
   NvmExpressDxe driver is used to manage non-volatile memory subsystem which 
follows
   NVM Express specification.
 
-  Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2013 - 2018, 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 @@ -218,7 +218,7 @@ NvmeRead (
 }
   }
 
-  DEBUG ((EFI_D_VERBOSE, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
+  DEBUG ((DEBUG_BLKIO, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
 "Remaining = 0x%08Lx, BlockSize = 0x%x, Status = %r\n", __FUNCTION__, Lba,
 (UINT64)OrginalBlocks, (UINT64)Blocks, BlockSize, Status));
 
@@ -296,7 +296,7 @@ NvmeWrite (
 }
   }
 
-  DEBUG ((EFI_D_VERBOSE, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
+  DEBUG ((DEBUG_BLKIO, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
 "Remaining = 0x%08Lx, BlockSize = 0x%x, Status = %r\n", __FUNCTION__, Lba,
 (UINT64)OrginalBlocks, (UINT64)Blocks, BlockSize, Status));
 
@@ -802,7 +802,7 @@ NvmeAsyncRead (
 }
   }
 
-  DEBUG ((EFI_D_VERBOSE, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
+  DEBUG ((DEBUG_BLKIO, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
 "Remaining = 0x%08Lx, BlockSize = 0x%x, Status = %r\n", __FUNCTION__, Lba,
 (UINT64)OrginalBlocks, (UINT64)Blocks, BlockSize, Status));
 
@@ -922,7 +922,7 @@ NvmeAsyncWrite (
 }
   }
 
-  DEBUG ((EFI_D_VERBOSE, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
+  DEBUG ((DEBUG_BLKIO, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
 "Remaining = 0x%08Lx, BlockSize = 0x%x, Status = %r\n", __FUNCTION__, Lba,
 (UINT64)OrginalBlocks, (UINT64)Blocks, BlockSize, Status));
 
--
2.12.0.windows.1

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

Re: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode

[Wang, Jian J]

Hi Laszlo,

Thank you very much for such thorough review. I'd like to explain a bit in 
advance.

Putting aside the specific coding issues in my patch, one thing is clear that 
SMM mode
has its own page table. CpuDxe should not touch it even if its public interface 
is called
via gBS services, because it has no knowledge of SMM internal things and it 
might
jeopardize SMM operation if it does. But current CpuDxe doesn't take this into 
account.
I think it should be fixed anyway, even there's no Heap Guard feature, since 
current
design allows SMM to touch memory owned by DXE but not vice versa.

The basic idea of this patch is, if we want to access DXE page table in SMM 
mode, we
cannot do this via CR3 register (it has been reloaded by SMM) directly but via 
a stored
value in a global. This is feasible because page table is just a chunk of 
normal memory.
All we need is an entry address pointer. When exiting SMM mode back to DXE, the
updated page table will take effect immediately once CR3 is restored to DXE 
version.
That means we can change DXE page table attributes even in SMM mode.

Please see my other responses below.

Regards,
Jian

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, June 11, 2018 8:18 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Yao, Jiewen ; Dong,
> Eric 
> Subject: Re: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE)
> page table in SMM mode
> 
> Hi Jian,
> 
> On 06/11/18 09:08, Jian J Wang wrote:
> > The SMM version of MemoryAllocationLib allows to free memory allocated
> > in DXE (before EndOfDxe). This is done by checking the memory range and
> > calling gBS services to do real operation if the memory to free is out
> > of SMRAM. This would cause problem if some memory related features, like
> > Heap Guard, have to update page table to change memory attributes.
> > Because page table in SMM mode is different from DXE mode, gBS memory
> > services cannot get the correct attributes of DXE memory from SMM page
> > table and then cause incorrect memory manipulations.
> 
> (1) I think this description makes sense, but it does not highlight the
> involvement of CpuDxe.
> 
> (1a) Please reference "MdePkg/Library/SmmMemoryAllocationLib" specifically.
> 
> (1b) The SmmMemoryAllocationLib instance implies that the call chain
> starts with a DXE_SMM_DRIVER calling FreePool() or FreePages().
> 
> DXE_SMM_DRIVERs can only call boot services, and protocols located with
> boot services, in their entry point functions.
> 
> CpuDxe is a DXE_DRIVER and it provides the CPU arch protocol (and the MP
> services protocol). Thus, our call chain can only occur if:
> 
> - a DXE_SMM_DRIVER calls the FreePool() or FreePages() library API,
> 
> - in its entry point function,
> 
> - releasing memory that's not SMRAM,
> 
> - and the heap guard feature is enabled, so the FreePool() or
>   FreePages() boot service ends up calling
>   EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes().
> 
> Please include this information in the commit message.
> 

Sure. I'll add it. Thanks.

> (2) Can you remind me how the SMM page tables map non-SMRAM memory?
> 
> Because, I assume that, after a FreePages() libary API call, the freed
> memory should not be accessible to either SMM code or normal DXE code.
> This seems to imply that both sets of page tables should be modified.
> What am I missing?
> 

For both SMM and DXE, we just do 1:1 full memory mapping in paging but in
different page tables. As far as I know, there's no such rules that freed pages
should not be accessible. I think it's just implementation dependent.

> >
> > The solution in this patch is to store the DXE page table information
> > (e.g. value of CR0, CR3 registers, etc.) in a global variable of CpuDxe
> > driver. If CpuDxe detects it's in SMM mode, it will use this global
> > variable to access page table instead of current processor registers.
> >
> > Change-Id: If810bb1828160b8bdd8cb616d86df2859c74971f
> 
> (3) I think this comes from Gerrit. Do you really need the "Change-Id"
> tag in the commit message? It doesn't say anything to the upstream edk2
> users.
> 
> If you really need it, I don't mind it though; just please let's not add
> it due to oversight.
> 

Sorry, it's added by our internal tool automatically. It can be deleted.

> (4) Please make sure that you don't *push* the patch with Gerrit. Gerrit
> does bad things to git metadata. Please see
>  archive.com/4A89E2EF3DFEDB4C8BFDE51014F606A14E22344D@SHSMSX104.c
> cr.corp.intel.com>.
> 

Sure.

> > Cc: Eric Dong 
> > Cc: Laszlo Ersek 
> > Cc: Jiewen Yao 
> > Cc: Ruiyu Ni 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang 
> > ---
> >  UefiCpuPkg/CpuDxe/CpuDxe.c   |   2 +-
> >  UefiCpuPkg/CpuDxe/CpuDxe.inf |   1 +
> >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 108 ++---
> --
> >  3 files changed, 75 insertions(+), 36 deletions(-)
> >
> > 

Re: [edk2] [patch V2 3/3] ShellPkg/Dp: Make the help info align with code

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Bi, Dandan
> Sent: Monday, June 11, 2018 4:32 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Ni, Ruiyu ; 
> Carsey, Jaben 
> Subject: [patch V2 3/3] ShellPkg/Dp: Make the help info align with code
> 
> Currently in DP, the Trace mode is enabled by default.
> And the profile mode is not implemented. but the help info
> of DP tool doesn't match current implementation. Which will
> make user confused. So now remove the unused source code
> related to the profile mode and update the help information
> of DP tool.
> 
> V2: Remove the unused code related to profile mode.
> 
> Cc: Liming Gao 
> Cc: Ruiyu Ni 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi 
> ---
>  ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c  |  96 ++--
>  ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h  |   7 --
>  ShellPkg/DynamicCommand/DpDynamicCommand/Dp.uni|   6 +-
>  ShellPkg/DynamicCommand/DpDynamicCommand/DpApp.inf |   1 -
>  .../DpDynamicCommand/DpDynamicCommand.inf  |   1 -
>  .../DynamicCommand/DpDynamicCommand/DpInternal.h   |  48 --
>  .../DynamicCommand/DpDynamicCommand/DpProfile.c| 100 
> -
>  7 files changed, 26 insertions(+), 233 deletions(-)
>  delete mode 100644 ShellPkg/DynamicCommand/DpDynamicCommand/DpProfile.c
> 
> diff --git a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c 
> b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
> index d8451dbf59f..38766613175 100644
> --- a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
> +++ b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
> @@ -82,14 +82,10 @@ UINT32 const  NumCum = sizeof(CumData) / 
> sizeof(PERF_CUM_DATA);
>  STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
>{L"-v", TypeFlag},   // -v   Verbose Mode
>{L"-A", TypeFlag},   // -A   All, Cooked
>{L"-R", TypeFlag},   // -R   RAW All
>{L"-s", TypeFlag},   // -s   Summary
> -#if PROFILING_IMPLEMENTED
> -  {L"-P", TypeFlag},   // -P   Dump Profile Data
> -  {L"-T", TypeFlag},   // -T   Dump Trace Data
> -#endif // PROFILING_IMPLEMENTED
>{L"-x", TypeFlag},   // -x   eXclude Cumulative Items
>{L"-i", TypeFlag},   // -i   Display Identifier
>{L"-c", TypeValue},  // -c   Display cumulative data.
>{L"-n", TypeValue},  // -n # Number of records to display for A and R
>{L"-t", TypeValue},  // -t # Threshold of interest
> @@ -114,13 +110,10 @@ DumpStatistics( void )
>ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_DP_STATS_NUMINCOMPLETE), 
> mDpHiiHandle, SummaryData.NumIncomplete);
>ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_DP_STATS_NUMPHASES), 
> mDpHiiHandle, SummaryData.NumSummary);
>ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_DP_STATS_NUMHANDLES), 
> mDpHiiHandle,SummaryData.NumHandles,
> SummaryData.NumTrace - SummaryData.NumHandles);
>ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_DP_STATS_NUMPEIMS), 
> mDpHiiHandle,  SummaryData.NumPEIMs);
>ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_DP_STATS_NUMGLOBALS), 
> mDpHiiHandle,SummaryData.NumGlobal);
> -#if PROFILING_IMPLEMENTED
> -  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_DP_STATS_NUMPROFILE), 
> mDpHiiHandle,SummaryData.NumProfile);
> -#endif // PROFILING_IMPLEMENTED
>SHELL_FREE_NON_NULL (StringPtr);
>SHELL_FREE_NON_NULL (StringPtrUnknown);
>  }
> 
>  /**
> @@ -682,11 +675,10 @@ VOID
>  InitSummaryData (
>VOID
>)
>  {
>SummaryData.NumTrace  = 0;
> -  SummaryData.NumProfile= 0 ;
>SummaryData.NumIncomplete = 0;
>SummaryData.NumSummary= 0;
>SummaryData.NumHandles= 0;
>SummaryData.NumPEIMs  = 0;
>SummaryData.NumGlobal = 0;
> @@ -719,12 +711,10 @@ RunDp (
>EFI_STRINGStringPtr;
>BOOLEAN   SummaryMode;
>BOOLEAN   VerboseMode;
>BOOLEAN   AllMode;
>BOOLEAN   RawMode;
> -  BOOLEAN   TraceMode;
> -  BOOLEAN   ProfileMode;
>BOOLEAN   ExcludeMode;
>BOOLEAN   CumulativeMode;
>CONST CHAR16  *CustomCumulativeToken;
>PERF_CUM_DATA *CustomCumulativeData;
>UINTN NameSize;
> @@ -734,12 +724,10 @@ RunDp (
>StringPtr   = NULL;
>SummaryMode = FALSE;
>VerboseMode = FALSE;
>AllMode = FALSE;
>RawMode = FALSE;
> -  TraceMode   = FALSE;
> -  ProfileMode = FALSE;
>ExcludeMode = FALSE;
>CumulativeMode = FALSE;
>CustomCumulativeData = NULL;
>ShellStatus = SHELL_SUCCESS;
> 
> @@ -763,14 +751,10 @@ RunDp (
>//
>VerboseMode = ShellCommandLineGetFlag (ParamPackage, L"-v");
>SummaryMode = (BOOLEAN) (ShellCommandLineGetFlag (ParamPackage, L"-S") || 
> ShellCommandLineGetFlag (ParamPackage,
> L"-s"));
>AllMode = ShellCommandLineGetFlag (ParamPackage, L"-A");
>RawMode = 

Re: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode

[Zeng, Star]

Sorry, fix typo.

DXE > (SMM communcation) > InSmm = TRUE > SMM driver dispatcher/SMM handler > 
InSmm = FALSE > (exit SMM communication) > DXE

-Original Message-
From: Zeng, Star 
Sent: Tuesday, June 12, 2018 11:35 AM
To: Laszlo Ersek ; Wang, Jian J ; 
edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Yao, Jiewen ; Dong, 
Eric ; Zeng, Star 
Subject: RE: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page 
table in SMM mode

Share some information here according to my knowledge.

The EFI_SMM_BASE2_PROTOCOL.InSmm definition in PI spec is really very 
confusion. The naming for it are not consistent.
The interface name: In*Smm*
The typedef name of InSmm: EFI_*SMM_INSIDE_OUT*2 The second parameter name of 
InSmm: In*Smram*
 
In reality, the implementation of EFI_SMM_BASE2_PROTOCOL.InSmm in PiSmmIpl 
returns the information that whether current executing code is SMM code or 
executed from SMM code.

DXE > (SMM communcation) > InSmm = TRUE > SMM driver dispatcher/SMM handler > 
(exit SMM communication) > InSmm = FALSE > DXE


Thanks,
Star

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Monday, June 11, 2018 8:18 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Yao, Jiewen ; Dong, 
Eric 
Subject: Re: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page 
table in SMM mode

Hi Jian,

On 06/11/18 09:08, Jian J Wang wrote:
> The SMM version of MemoryAllocationLib allows to free memory allocated 
> in DXE (before EndOfDxe). This is done by checking the memory range 
> and calling gBS services to do real operation if the memory to free is 
> out of SMRAM. This would cause problem if some memory related 
> features, like Heap Guard, have to update page table to change memory 
> attributes.
> Because page table in SMM mode is different from DXE mode, gBS memory 
> services cannot get the correct attributes of DXE memory from SMM page 
> table and then cause incorrect memory manipulations.

(1) I think this description makes sense, but it does not highlight the 
involvement of CpuDxe.

(1a) Please reference "MdePkg/Library/SmmMemoryAllocationLib" specifically.

(1b) The SmmMemoryAllocationLib instance implies that the call chain starts 
with a DXE_SMM_DRIVER calling FreePool() or FreePages().

DXE_SMM_DRIVERs can only call boot services, and protocols located with boot 
services, in their entry point functions.

CpuDxe is a DXE_DRIVER and it provides the CPU arch protocol (and the MP 
services protocol). Thus, our call chain can only occur if:

- a DXE_SMM_DRIVER calls the FreePool() or FreePages() library API,

- in its entry point function,

- releasing memory that's not SMRAM,

- and the heap guard feature is enabled, so the FreePool() or
  FreePages() boot service ends up calling
  EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes().

Please include this information in the commit message.

(2) Can you remind me how the SMM page tables map non-SMRAM memory?

Because, I assume that, after a FreePages() libary API call, the freed memory 
should not be accessible to either SMM code or normal DXE code.
This seems to imply that both sets of page tables should be modified.
What am I missing?

> 
> The solution in this patch is to store the DXE page table information 
> (e.g. value of CR0, CR3 registers, etc.) in a global variable of 
> CpuDxe driver. If CpuDxe detects it's in SMM mode, it will use this 
> global variable to access page table instead of current processor registers.
> 
> Change-Id: If810bb1828160b8bdd8cb616d86df2859c74971f

(3) I think this comes from Gerrit. Do you really need the "Change-Id"
tag in the commit message? It doesn't say anything to the upstream edk2 users.

If you really need it, I don't mind it though; just please let's not add it due 
to oversight.

(4) Please make sure that you don't *push* the patch with Gerrit. Gerrit does 
bad things to git metadata. Please see 
<4A89E2EF3DFEDB4C8BFDE51014F606A14E22344D@SHSMSX104.ccr.corp.intel.com">http://mid.mail-archive.com/4A89E2EF3DFEDB4C8BFDE51014F606A14E22344D@SHSMSX104.ccr.corp.intel.com>.

> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Cc: Jiewen Yao 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/CpuDxe/CpuDxe.c   |   2 +-
>  UefiCpuPkg/CpuDxe/CpuDxe.inf |   1 +
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 108
> ++-
>  3 files changed, 75 insertions(+), 36 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c 
> index 6ae2dcd1c7..1fd996fc3f 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.c
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
> @@ -404,7 +404,7 @@ CpuSetMemoryAttributes (
>// to avoid unnecessary computing.
>//
>if (mIsFlushingGCD) {
> -DEBUG((DEBUG_INFO, "  Flushing GCD\n"));
> +DEBUG((DEBUG_GCD, "  Flushing GCD\n"));
>  return EFI_SUCCESS;
>}

(5) I think it would be cleaner if we fixed the 

[edk2] [PATCH 0/2] Adjust DEBUG prints level for SD/NVMe BlockIo services

[Hao Wu]

For the SdDxe and NvmExpressDxe drivers, adjust the level of I/O
information related DEBUG prints to DEBUG_BLKIO.

Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 

Hao Wu (2):
  MdeModulePkg/NvmExpressDxe: Adjust R/W DEBUG prints to BLKIO level
  MdeModulePkg/SdDxe: Demote DEBUG print to DEBUG_BLKIO

 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c | 10 +-
 MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c  |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.12.0.windows.1

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

[edk2] [PATCH 1/2] MdeModulePkg/NvmExpressDxe: Adjust R/W DEBUG prints to BLKIO level

[Hao Wu]

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

Adjust the DEBUG prints within function:
NvmeRead(), NvmeWrite(), AsyncNvmeRead() and AsyncNvmeWrite()

to DEBUG_BLKIO for the consistency with other storage device drivers
(e.g. ATA, USB and etc.).

Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c
index 734e1286c6..6c415109c1 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c
@@ -2,7 +2,7 @@
   NvmExpressDxe driver is used to manage non-volatile memory subsystem which 
follows
   NVM Express specification.
 
-  Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2013 - 2018, 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
@@ -218,7 +218,7 @@ NvmeRead (
 }
   }
 
-  DEBUG ((EFI_D_VERBOSE, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
+  DEBUG ((DEBUG_BLKIO, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
 "Remaining = 0x%08Lx, BlockSize = 0x%x, Status = %r\n", __FUNCTION__, Lba,
 (UINT64)OrginalBlocks, (UINT64)Blocks, BlockSize, Status));
 
@@ -296,7 +296,7 @@ NvmeWrite (
 }
   }
 
-  DEBUG ((EFI_D_VERBOSE, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
+  DEBUG ((DEBUG_BLKIO, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
 "Remaining = 0x%08Lx, BlockSize = 0x%x, Status = %r\n", __FUNCTION__, Lba,
 (UINT64)OrginalBlocks, (UINT64)Blocks, BlockSize, Status));
 
@@ -802,7 +802,7 @@ NvmeAsyncRead (
 }
   }
 
-  DEBUG ((EFI_D_VERBOSE, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
+  DEBUG ((DEBUG_BLKIO, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
 "Remaining = 0x%08Lx, BlockSize = 0x%x, Status = %r\n", __FUNCTION__, Lba,
 (UINT64)OrginalBlocks, (UINT64)Blocks, BlockSize, Status));
 
@@ -922,7 +922,7 @@ NvmeAsyncWrite (
 }
   }
 
-  DEBUG ((EFI_D_VERBOSE, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
+  DEBUG ((DEBUG_BLKIO, "%a: Lba = 0x%08Lx, Original = 0x%08Lx, "
 "Remaining = 0x%08Lx, BlockSize = 0x%x, Status = %r\n", __FUNCTION__, Lba,
 (UINT64)OrginalBlocks, (UINT64)Blocks, BlockSize, Status));
 
-- 
2.12.0.windows.1

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

Re: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode

[Zeng, Star]

Share some information here according to my knowledge.

The EFI_SMM_BASE2_PROTOCOL.InSmm definition in PI spec is really very 
confusion. The naming for it are not consistent.
The interface name: In*Smm*
The typedef name of InSmm: EFI_*SMM_INSIDE_OUT*2
The second parameter name of InSmm: In*Smram*
 
In reality, the implementation of EFI_SMM_BASE2_PROTOCOL.InSmm in PiSmmIpl 
returns the information that whether current executing code is SMM code or 
executed from SMM code.

DXE > (SMM communcation) > InSmm = TRUE > SMM driver dispatcher/SMM handler > 
(exit SMM communication) > InSmm = FALSE > DXE


Thanks,
Star

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Monday, June 11, 2018 8:18 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Yao, Jiewen ; Dong, 
Eric 
Subject: Re: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page 
table in SMM mode

Hi Jian,

On 06/11/18 09:08, Jian J Wang wrote:
> The SMM version of MemoryAllocationLib allows to free memory allocated 
> in DXE (before EndOfDxe). This is done by checking the memory range 
> and calling gBS services to do real operation if the memory to free is 
> out of SMRAM. This would cause problem if some memory related 
> features, like Heap Guard, have to update page table to change memory 
> attributes.
> Because page table in SMM mode is different from DXE mode, gBS memory 
> services cannot get the correct attributes of DXE memory from SMM page 
> table and then cause incorrect memory manipulations.

(1) I think this description makes sense, but it does not highlight the 
involvement of CpuDxe.

(1a) Please reference "MdePkg/Library/SmmMemoryAllocationLib" specifically.

(1b) The SmmMemoryAllocationLib instance implies that the call chain starts 
with a DXE_SMM_DRIVER calling FreePool() or FreePages().

DXE_SMM_DRIVERs can only call boot services, and protocols located with boot 
services, in their entry point functions.

CpuDxe is a DXE_DRIVER and it provides the CPU arch protocol (and the MP 
services protocol). Thus, our call chain can only occur if:

- a DXE_SMM_DRIVER calls the FreePool() or FreePages() library API,

- in its entry point function,

- releasing memory that's not SMRAM,

- and the heap guard feature is enabled, so the FreePool() or
  FreePages() boot service ends up calling
  EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes().

Please include this information in the commit message.

(2) Can you remind me how the SMM page tables map non-SMRAM memory?

Because, I assume that, after a FreePages() libary API call, the freed memory 
should not be accessible to either SMM code or normal DXE code.
This seems to imply that both sets of page tables should be modified.
What am I missing?

> 
> The solution in this patch is to store the DXE page table information 
> (e.g. value of CR0, CR3 registers, etc.) in a global variable of 
> CpuDxe driver. If CpuDxe detects it's in SMM mode, it will use this 
> global variable to access page table instead of current processor registers.
> 
> Change-Id: If810bb1828160b8bdd8cb616d86df2859c74971f

(3) I think this comes from Gerrit. Do you really need the "Change-Id"
tag in the commit message? It doesn't say anything to the upstream edk2 users.

If you really need it, I don't mind it though; just please let's not add it due 
to oversight.

(4) Please make sure that you don't *push* the patch with Gerrit. Gerrit does 
bad things to git metadata. Please see 
<4A89E2EF3DFEDB4C8BFDE51014F606A14E22344D@SHSMSX104.ccr.corp.intel.com">http://mid.mail-archive.com/4A89E2EF3DFEDB4C8BFDE51014F606A14E22344D@SHSMSX104.ccr.corp.intel.com>.

> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Cc: Jiewen Yao 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/CpuDxe/CpuDxe.c   |   2 +-
>  UefiCpuPkg/CpuDxe/CpuDxe.inf |   1 +
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 108 
> ++-
>  3 files changed, 75 insertions(+), 36 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c 
> index 6ae2dcd1c7..1fd996fc3f 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.c
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
> @@ -404,7 +404,7 @@ CpuSetMemoryAttributes (
>// to avoid unnecessary computing.
>//
>if (mIsFlushingGCD) {
> -DEBUG((DEBUG_INFO, "  Flushing GCD\n"));
> +DEBUG((DEBUG_GCD, "  Flushing GCD\n"));
>  return EFI_SUCCESS;
>}

(5) I think it would be cleaner if we fixed the debug level for this message in 
a separate patch. You are not touching "CpuDxe.c" for any other reason.

>  
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.inf 
> b/UefiCpuPkg/CpuDxe/CpuDxe.inf index 3c938cee53..8c8773af90 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.inf
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.inf
> @@ -66,6 +66,7 @@
>  [Protocols]
>gEfiCpuArchProtocolGuid   ## PRODUCES
>gEfiMpServiceProtocolGuid

Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print to DEBUG_BLKIO

[Wu, Hao A]

Yes, BZ 980 was filed, and I will propose a patch for it.

Best Regards,
Hao Wu


> -Original Message-
> From: Zeng, Star
> Sent: Monday, June 11, 2018 5:13 PM
> To: Ard Biesheuvel; Wu, Hao A
> Cc: edk2-devel@lists.01.org; Laszlo Ersek; Zeng, Star
> Subject: RE: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print to
> DEBUG_BLKIO
> 
> Let's go to use DEBUG_BLKIO to be consistent.
> 
> Ard, Reviewed-by: Star Zeng .
> Hao, you can submit ticket on bugzilla and submit patch for NvmExpressDxe.
> 
> Thanks,
> Star
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, June 11, 2018 4:54 PM
> To: Wu, Hao A 
> Cc: Zeng, Star ; edk2-devel@lists.01.org; Laszlo Ersek
> 
> Subject: Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print to
> DEBUG_BLKIO
> 
> On 11 June 2018 at 10:38, Wu, Hao A  wrote:
> > Hi Ard,
> >
> > After a quick check on the behavior of other storage device drivers,
> > it seems to me that they are not using the same debug levels for this
> > kind of debug
> > message:
> >
> > ATA and USB mass storage - BLKIO
> > NVM Express - VERBOSE
> > SD/eMMC - INFO
> > SCSI - actually no such debug message
> >
> > My preference is to use the 'BLKIO' for the SD/eMMC case, since
> > literally, it seems the best fit and the majority of the drivers are using 
> > this
> level.
> > Or maybe we can use a combination of (DEBUG_BLKIO | DEBUG_VERBOSE).
> >
> > Ard and Star, what's your thought?
> >
> 
> I am happy to stick with the patch as I proposed it, i.e., DEBUG_BLKIO only
> 
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: Monday, June 11, 2018 4:15 PM
> >> To: Zeng, Star
> >> Cc: edk2-devel@lists.01.org; Laszlo Ersek; Wu, Hao A
> >> Subject: Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG
> print
> >> to DEBUG_BLKIO
> >>
> >> On 8 June 2018 at 05:15, Zeng, Star  wrote:
> >> > Good patch.
> >> >
> >> > Another choice is to use DEBUG_VERBOSE.
> >> > We see other driver uses DEBUG_VERBOSE for BlockIo service (Hao can
> >> comment on that).
> >> > We'd better to align them for consistency.
> >> >
> >>
> >> Hao,
> >>
> >> Do you have any preference regarding the exact priority level we will
> >> use for this particular DEBUG() print?
> >>
> >> Thanks,
> >> Ard.
> >>
> >>
> >> > -Original Message-
> >> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> > Sent: Friday, June 8, 2018 1:23 AM
> >> > To: Ard Biesheuvel ;
> >> > edk2-devel@lists.01.org
> >> > Cc: Zeng, Star 
> >> > Subject: Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG
> >> > print
> >> to DEBUG_BLKIO
> >> >
> >> > On 06/07/18 11:10, Ard Biesheuvel wrote:
> >> >> Lower the priority of the DEBUG print in EmmcReadWrite(), which is
> >> >> emitted for each read or write operation to the eMMC device, which
> >> >> clutters up the log output of builds created with DEBUG_INFO enabled.
> >> >>
> >> >> Suggested-by: Pipat Methavanitpong
> >> >> 
> >> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> >> Signed-off-by: Ard Biesheuvel 
> >> >> ---
> >> >>  MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c | 5 -
> >> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> >> >> b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> >> >> index e1d0f394a954..f6b230514b71 100644
> >> >> --- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> >> >> +++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> >> >> @@ -901,7 +901,10 @@ EmmcReadWrite (
> >> >>  if (EFI_ERROR (Status)) {
> >> >>return Status;
> >> >>  }
> >> >> -DEBUG ((EFI_D_INFO, "Emmc%a(): Part %d Lba 0x%x BlkNo 0x%x
> >> Event %p with %r\n", IsRead ? "Read " : "Write",
> >> Partition->PartitionType, Lba, BlockNum, (Token != NULL) ?
> >> Token->Event : NULL, Status));
> >> >> +DEBUG ((DEBUG_BLKIO,
> >> >> +  "Emmc%a(): Part %d Lba 0x%x BlkNo 0x%x Event %p with %r\n",
> >> >> +  IsRead ? "Read " : "Write", Partition->PartitionType, Lba, 
> >> >> BlockNum,
> >> >> +  (Token != NULL) ? Token->Event : NULL, Status));
> >> >>
> >> >>  Lba   += BlockNum;
> >> >>  Buffer = (UINT8*)Buffer + BufferSize;
> >> >>
> >> >
> >> > Reviewed-by: Laszlo Ersek 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Fix one bug of nest !include parser

[Kinney, Michael D]

Tested-by: Michael D Kinney 

Mike
 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Yonghong Zhu
> Sent: Monday, June 11, 2018 6:01 PM
> To: edk2-devel@lists.01.org
> Cc: Feng, YunhuaX ; Gao, Liming
> 
> Subject: [edk2] [Patch] BaseTools: Fix one bug of nest
> !include parser
> 
> From: Yunhua Feng 
> 
> The case is DSC file include file1, file1 include file2,
> after parse
> file2 finished, DSC parser get the wrong section type,
> then it would
> report invalid error.
> 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yunhua Feng 
> ---
>  BaseTools/Source/Python/Workspace/MetaFileParser.py | 6
> +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git
> a/BaseTools/Source/Python/Workspace/MetaFileParser.py
> b/BaseTools/Source/Python/Workspace/MetaFileParser.py
> index 8ab1dd2..4252e6d 100644
> ---
> a/BaseTools/Source/Python/Workspace/MetaFileParser.py
> +++
> b/BaseTools/Source/Python/Workspace/MetaFileParser.py
> @@ -1568,11 +1568,15 @@ class DscParser(MetaFileParser):
>  # Parse the included file
>  Parser.Start()
> 
>  # update current status with sub-parser's
> status
>  self._SectionName = Parser._SectionName
> -self._SectionType = Parser._SectionType
> +if not self._InSubsection:
> +self._SectionType = Parser._SectionType
> +self._SubsectionType =
> Parser._SubsectionType
> +self._InSubsection = Parser._InSubsection
> +
>  self._Scope = Parser._Scope
>  self._Enabled = Parser._Enabled
> 
>  # Insert all records in the table for the
> included file into dsc file table
>  Records = IncludedFileTable.GetAll()
> --
> 2.6.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] BaseTools/tools_def IA32: disable PIE code generation explicitly

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, June 12, 2018 12:29 AM
> To: edk2-devel@lists.01.org
> Cc: ler...@redhat.com; Gao, Liming ; Zhu, Yonghong 
> ; Ard Biesheuvel
> 
> Subject: [PATCH v2] BaseTools/tools_def IA32: disable PIE code generation 
> explicitly
> 
> As a security measure, some distros now build their GCC toolchains with
> PIE code generation enabled by default, because it is a prerequisite
> for ASLR to be enabled when running the executable.
> 
> This typically results in slightly larger code, but it also generates
> ELF relocations that our tooling cannot deal with, so let's disable it
> explicitly when using GCC49 or later for IA32. (Note that this does not
> apply to X64: it uses PIE code deliberately in some cases, and our
> tooling does deal with the resuling relocations)
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Acked-by: Laszlo Ersek 
> ---
>  BaseTools/Conf/tools_def.template | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 7e9c915755ed..733c6ec71709 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -4648,7 +4648,7 @@ DEFINE GCC48_AARCH64_DLINK2_FLAGS= 
> DEF(GCC47_AARCH64_DLINK2_FLAGS)
>  DEFINE GCC48_ARM_ASLDLINK_FLAGS  = DEF(GCC47_ARM_ASLDLINK_FLAGS)
>  DEFINE GCC48_AARCH64_ASLDLINK_FLAGS  = DEF(GCC47_AARCH64_ASLDLINK_FLAGS)
> 
> -DEFINE GCC49_IA32_CC_FLAGS   = DEF(GCC48_IA32_CC_FLAGS)
> +DEFINE GCC49_IA32_CC_FLAGS   = DEF(GCC48_IA32_CC_FLAGS) -fno-pic 
> -fno-pie
>  DEFINE GCC49_X64_CC_FLAGS= DEF(GCC48_X64_CC_FLAGS)
>  DEFINE GCC49_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-n,-q,--gc-sections -z 
> common-page-size=0x40
>  DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON) 
> -Wl,--entry,ReferenceAcpiTable -u
> ReferenceAcpiTable
> @@ -5357,10 +5357,10 @@ RELEASE_GCC48_AARCH64_CC_FLAGS   = 
> DEF(GCC48_AARCH64_CC_FLAGS) -Wno-unused-but-s
>  *_GCC49_IA32_RC_PATH  = DEF(GCC49_IA32_PREFIX)objcopy
> 
>  *_GCC49_IA32_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m32
> -*_GCC49_IA32_ASLDLINK_FLAGS   = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS) 
> -Wl,-m,elf_i386
> +*_GCC49_IA32_ASLDLINK_FLAGS   = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS) 
> -Wl,-m,elf_i386 -no-pie
>  *_GCC49_IA32_ASM_FLAGS= DEF(GCC49_ASM_FLAGS) -m32 -march=i386
>  *_GCC49_IA32_DLINK_FLAGS  = DEF(GCC49_IA32_X64_DLINK_FLAGS) 
> -Wl,-m,elf_i386,--oformat=elf32-i386
> -*_GCC49_IA32_DLINK2_FLAGS = DEF(GCC49_IA32_DLINK2_FLAGS)
> +*_GCC49_IA32_DLINK2_FLAGS = DEF(GCC49_IA32_DLINK2_FLAGS) -no-pie
>  *_GCC49_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
>  *_GCC49_IA32_OBJCOPY_FLAGS=
>  *_GCC49_IA32_NASM_FLAGS   = -f elf32
> @@ -5502,9 +5502,9 @@ RELEASE_GCC49_AARCH64_DLINK_FLAGS  = 
> DEF(GCC49_AARCH64_DLINK_FLAGS)
>  *_GCC5_IA32_RC_PATH  = DEF(GCC5_IA32_PREFIX)objcopy
> 
>  *_GCC5_IA32_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m32 -fno-lto
> -*_GCC5_IA32_ASLDLINK_FLAGS   = DEF(GCC5_IA32_X64_ASLDLINK_FLAGS) 
> -Wl,-m,elf_i386
> +*_GCC5_IA32_ASLDLINK_FLAGS   = DEF(GCC5_IA32_X64_ASLDLINK_FLAGS) 
> -Wl,-m,elf_i386 -no-pie
>  *_GCC5_IA32_ASM_FLAGS= DEF(GCC5_ASM_FLAGS) -m32 -march=i386
> -*_GCC5_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS)
> +*_GCC5_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS) -no-pie
>  *_GCC5_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
>  *_GCC5_IA32_OBJCOPY_FLAGS=
>  *_GCC5_IA32_NASM_FLAGS   = -f elf32
> --
> 2.17.1

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

[edk2] [Patch] BaseTools: Fix one bug of nest !include parser

[Yonghong Zhu]

From: Yunhua Feng 

The case is DSC file include file1, file1 include file2, after parse
file2 finished, DSC parser get the wrong section type, then it would
report invalid error.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng 
---
 BaseTools/Source/Python/Workspace/MetaFileParser.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Workspace/MetaFileParser.py 
b/BaseTools/Source/Python/Workspace/MetaFileParser.py
index 8ab1dd2..4252e6d 100644
--- a/BaseTools/Source/Python/Workspace/MetaFileParser.py
+++ b/BaseTools/Source/Python/Workspace/MetaFileParser.py
@@ -1568,11 +1568,15 @@ class DscParser(MetaFileParser):
 # Parse the included file
 Parser.Start()
 
 # update current status with sub-parser's status
 self._SectionName = Parser._SectionName
-self._SectionType = Parser._SectionType
+if not self._InSubsection:
+self._SectionType = Parser._SectionType
+self._SubsectionType = Parser._SubsectionType
+self._InSubsection = Parser._InSubsection
+
 self._Scope = Parser._Scope
 self._Enabled = Parser._Enabled
 
 # Insert all records in the table for the included file into dsc 
file table
 Records = IncludedFileTable.GetAll()
-- 
2.6.1.windows.1

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

Re: [edk2] [PATCH v2 1/5] MdeModulePkg/CapsulePei: clean Dcache before consuming capsule data

[Kinney, Michael D]

Ard,

What about memory init when the memory HOBs are
created.  Could you flush all the ranges of 
initialized memory by HOB as the HOBs are created?

PEI and DXE can not use memory not described by
the HOBs.  More memory can be added in DXE phase
through the GCD services, and additional flush 
could be done as added.

Mike

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, June 11, 2018 3:01 PM
> To: Kinney, Michael D 
> Cc: Yao, Jiewen ; edk2-
> de...@lists.01.org; Leif Lindholm
> ; Zeng, Star
> 
> Subject: Re: [PATCH v2 1/5] MdeModulePkg/CapsulePei:
> clean Dcache before consuming capsule data
> 
> On 11 June 2018 at 23:40, Kinney, Michael D
>  wrote:
> > Hi Ard,
> >
> > I would still prefer the cache maintenance be done
> independent
> > of capsules in case there is other memory ranges that
> need to
> > be flushed for other features.
> >
> > The CacheMaintenanceLib for ARM has several services
> that are
> > not implemented and ASSERT().  I found some ARM
> documentation
> > that says that caches can be flushed by looping
> through the
> > indexes.
> >
> >
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.
> doc.ddi0201d/ch03s03s05.html
> >
> 
> Please don't quote severely outdated documentation out
> of context.
> ARM9 is a ~15 year old core that predates SMP on ARM by
> several years.
> 
> > implementations that may not work with that algorithm.
> However
> > that could require a customized CacheMaintenanceLib.
> Can you
> > provide the flush all using the documented algorithm
> and use that
> > instance for systems that are compatible with the
> documented algorithm.
> 
> None of the ARM cores we support in EDK2 today (ARMv7
> and later) are
> compatible with the documented algorithm.
> 
> > Then, the flush all API can be used in ResetSystem()
> or SEC Phase
> > when the boot mode is warm reset.
> >
> 
> Flushing the entire cache is simply not possible. The
> set/way
> operations are only intended to be used before the core
> enters the
> coherency domain or after it leaves it again (i.e., when
> cores are
> powered up or down). Those set/way operations are not
> broadcast to
> other cores (or other masters such as DMA capable
> peripherals with
> caches), which means that a cache line that is cleaned
> by set/way may
> simply end up in another cache and never make it to main
> memory. In
> other words, set/way operations manage the cache itself
> rather than
> the contents of the caches.
> 
> The only way to perform cache maintenance in a way to
> ensure that the
> *content* makes it to main memory is to use cache
> maintenance by
> virtual address. This requires that you know the virtual
> address to
> begin with, and obviously requires that a mapping exists
> for that
> virtual address when executed with the MMU on.
> 
> The bottom line is that there is no flush all API, and
> we will have to
> work around that (and believe me, this is not the first
> time we are
> struggling to deal with this limitation).
> 
> So to summarize again, we have the following options,
> - UpdateCapsule - problematic because it may be called
> at runtime and
> the firmware has no means of translating the physical
> addresses
> - ResetSystem - same as above: it is a runtime service,
> and so it
> cannot rely on a mapping to exist for those physical
> addresses
> - SEC - lacks the information about where the capsule
> resides
> - CapsulePei - already extracts the information about
> the capsule
> address in memory, and can perform the cache maintenance
> right before
> consuming the data.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 0/5] BaseTools/BinToPcd: Multiple clean up tasks

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong

-Original Message-
From: Kinney, Michael D 
Sent: Saturday, June 09, 2018 2:15 PM
To: edk2-devel@lists.01.org
Cc: Sun, Yanyan ; Zhu, Yonghong ; 
Gao, Liming ; Kinney, Michael D 

Subject: [Patch 0/5] BaseTools/BinToPcd: Multiple clean up tasks

https://bugzilla.tianocore.org/show_bug.cgi?id=962
https://bugzilla.tianocore.org/show_bug.cgi?id=963
https://bugzilla.tianocore.org/show_bug.cgi?id=974
https://bugzilla.tianocore.org/show_bug.cgi?id=965

* Change "PcdToBin" to "BinToPcd"
* Update error message for --type HII.  If either --variable-guid
  or --variable-name is missing, then print an error message that
  states that both --variable-guid and --variable-name are required.
* --offset must be 8-byte aligned.
* Compatible with both Python 2.x and Python 3.x.
* Return error code when error message printed.
* Follow PEP-8 indent of 4 spaces.  https://www.python.org/dev/peps/pep-0008/

Cc: Yanyan Sun 
Cc: Yonghong Zhu 
Cc: Liming Gao 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1

Kinney, Michael D (5):
  BaseTools/BinToPcd: Fix typo in error messages
  BaseTools/BinToPcd: Clarify error message for --type HII
  BaseTools/BinToPcd: --offset must be 8-byte aligned
  BaseTools/BinToPcd: Update for Python 3 compatibility
  BaseTools/BinToPcd: Follow PEP-8 indent of 4 spaces

 BaseTools/Scripts/BinToPcd.py | 350 +-
 1 file changed, 179 insertions(+), 171 deletions(-)

-- 
2.14.2.windows.3

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

Re: [edk2] [PATCH v2 1/5] MdeModulePkg/CapsulePei: clean Dcache before consuming capsule data

[Ard Biesheuvel]

On 11 June 2018 at 23:40, Kinney, Michael D  wrote:
> Hi Ard,
>
> I would still prefer the cache maintenance be done independent
> of capsules in case there is other memory ranges that need to
> be flushed for other features.
>
> The CacheMaintenanceLib for ARM has several services that are
> not implemented and ASSERT().  I found some ARM documentation
> that says that caches can be flushed by looping through the
> indexes.
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0201d/ch03s03s05.html
>

Please don't quote severely outdated documentation out of context.
ARM9 is a ~15 year old core that predates SMP on ARM by several years.

> implementations that may not work with that algorithm.  However
> that could require a customized CacheMaintenanceLib.  Can you
> provide the flush all using the documented algorithm and use that
> instance for systems that are compatible with the documented algorithm.

None of the ARM cores we support in EDK2 today (ARMv7 and later) are
compatible with the documented algorithm.

> Then, the flush all API can be used in ResetSystem() or SEC Phase
> when the boot mode is warm reset.
>

Flushing the entire cache is simply not possible. The set/way
operations are only intended to be used before the core enters the
coherency domain or after it leaves it again (i.e., when cores are
powered up or down). Those set/way operations are not broadcast to
other cores (or other masters such as DMA capable peripherals with
caches), which means that a cache line that is cleaned by set/way may
simply end up in another cache and never make it to main memory. In
other words, set/way operations manage the cache itself rather than
the contents of the caches.

The only way to perform cache maintenance in a way to ensure that the
*content* makes it to main memory is to use cache maintenance by
virtual address. This requires that you know the virtual address to
begin with, and obviously requires that a mapping exists for that
virtual address when executed with the MMU on.

The bottom line is that there is no flush all API, and we will have to
work around that (and believe me, this is not the first time we are
struggling to deal with this limitation).

So to summarize again, we have the following options,
- UpdateCapsule - problematic because it may be called at runtime and
the firmware has no means of translating the physical addresses
- ResetSystem - same as above: it is a runtime service, and so it
cannot rely on a mapping to exist for those physical addresses
- SEC - lacks the information about where the capsule resides
- CapsulePei - already extracts the information about the capsule
address in memory, and can perform the cache maintenance right before
consuming the data.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 1/5] MdeModulePkg/CapsulePei: clean Dcache before consuming capsule data

[Kinney, Michael D]

Hi Ard,

I would still prefer the cache maintenance be done independent
of capsules in case there is other memory ranges that need to
be flushed for other features.

The CacheMaintenanceLib for ARM has several services that are
not implemented and ASSERT().  I found some ARM documentation 
that says that caches can be flushed by looping through the 
indexes.  

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0201d/ch03s03s05.html

I know you mentioned that there can be alternate MMU
implementations that may not work with that algorithm.  However
that could require a customized CacheMaintenanceLib.  Can you
provide the flush all using the documented algorithm and use that
instance for systems that are compatible with the documented algorithm.
Then, the flush all API can be used in ResetSystem() or SEC Phase
when the boot mode is warm reset.

Mike

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, June 11, 2018 2:29 PM
> To: Yao, Jiewen 
> Cc: edk2-devel@lists.01.org; Leif Lindholm
> ; Zeng, Star
> ; Kinney, Michael D
> 
> Subject: Re: [PATCH v2 1/5] MdeModulePkg/CapsulePei: clean
> Dcache before consuming capsule data
> 
> On 11 June 2018 at 23:27, Yao, Jiewen
>  wrote:
> > Hi Ard
> > May I suggest that we split the Capsule Dispatch patch
> from the cache maintenance patch?
> >
> > I think the former may require more time for design
> discussion.
> >
> 
> Yes, that is fine. As I explained, it has mainly to do with
> dispatching the capsule at a time when the console or GOP
> is available
> to report progress. This is separate from the cache
> maintenance issue.
> 
> 
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: Monday, June 11, 2018 2:25 PM
> >> To: edk2-devel@lists.01.org
> >> Cc: Leif Lindholm ; Zeng, Star
> ;
> >> Yao, Jiewen ; Kinney, Michael D
> >> ; Ard Biesheuvel
> 
> >> Subject: Re: [PATCH v2 1/5] MdeModulePkg/CapsulePei:
> clean Dcache before
> >> consuming capsule data
> >>
> >> On 8 June 2018 at 08:58, Ard Biesheuvel
>  wrote:
> >> > When capsule updates are staged for processing after a
> warm reboot,
> >> > they are copied into memory with the MMU and caches
> enabled. When
> >> > the capsule PEI gets around to coalescing the capsule,
> the MMU and
> >> > caches may still be disabled, and so on architectures
> where uncached
> >> > accesses are incoherent with the caches (such as ARM
> and AARCH64),
> >> > we may read stale data if we don't clean the caches to
> memory first.
> >> >
> >> > Note that this cache maintenance cannot be done during
> the invocation
> >> > of UpdateCapsule(), since the ScatterGatherList
> structures are only
> >> > identified by physical address, and at runtime, the
> firmware doesn't
> >> > know whether and where this memory is mapped, and
> cache maintenance
> >> > requires a virtual address.
> >> >
> >> > Reviewed-by: Jiewen Yao 
> >> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> >> > Signed-off-by: Ard Biesheuvel
> 
> >>
> >> Star,
> >>
> >> If you are ok with this version of the patch, please let
> me know.
> >>
> >> This patch and the PsciResetSystemLib one are
> prerequisites for making
> >> PersistAcrossReset capsules work at all on ARM systems.
> The remaining
> >> patches are only relevant when using the new progress
> reporting APIs,
> >> so those can wait, but I would like to merge this one as
> soon as it is
> >> ready.
> >>
> >> Thanks,
> >> Ard.
> >>
> >>
> >> > ---
> >> >  MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> |  1 +
> >> >
> MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
> | 38
> >> ++--
> >> >  2 files changed, 28 insertions(+), 11 deletions(-)
> >> >
> >> > diff --git
> a/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> >> b/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> >> > index c54bc21a95a8..594e110d1f8a 100644
> >> > --- a/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> >> > +++ b/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> >> > @@ -48,6 +48,7 @@ [Packages]
> >> >
> >> >  [LibraryClasses]
> >> >BaseLib
> >> > +  CacheMaintenanceLib
> >> >HobLib
> >> >BaseMemoryLib
> >> >PeiServicesLib
> >> > diff --git
> a/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.
> c
> >>
> b/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.
> c
> >> > index 3e7054cd38a9..52b80e30b479 100644
> >> > ---
> a/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.
> c
> >> > +++
> b/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.
> c
> >> > @@ -27,6 +27,7 @@ WITHOUT WARRANTIES OR
> REPRESENTATIONS OF ANY
> >> KIND, EITHER EXPRESS OR IMPLIED.
> >> >  #include 
> >> >
> >> >  #include 
> >> > +#include 
> >> >  #include 
> >> >  #include 
> >> >  #include 
> >> > @@ -253,6 +254,7 @@ ValidateCapsuleByMemoryResource (
> >> >)
> >> >  {
> >> >UINTN Index;
> >> > +  BOOLEAN   Valid;
> >> >
> >> >//
> >> > 

Re: [edk2] [PATCH v2 1/5] MdeModulePkg/CapsulePei: clean Dcache before consuming capsule data

[Ard Biesheuvel]

On 11 June 2018 at 23:27, Yao, Jiewen  wrote:
> Hi Ard
> May I suggest that we split the Capsule Dispatch patch from the cache 
> maintenance patch?
>
> I think the former may require more time for design discussion.
>

Yes, that is fine. As I explained, it has mainly to do with
dispatching the capsule at a time when the console or GOP is available
to report progress. This is separate from the cache maintenance issue.


>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Monday, June 11, 2018 2:25 PM
>> To: edk2-devel@lists.01.org
>> Cc: Leif Lindholm ; Zeng, Star 
>> ;
>> Yao, Jiewen ; Kinney, Michael D
>> ; Ard Biesheuvel 
>> Subject: Re: [PATCH v2 1/5] MdeModulePkg/CapsulePei: clean Dcache before
>> consuming capsule data
>>
>> On 8 June 2018 at 08:58, Ard Biesheuvel  wrote:
>> > When capsule updates are staged for processing after a warm reboot,
>> > they are copied into memory with the MMU and caches enabled. When
>> > the capsule PEI gets around to coalescing the capsule, the MMU and
>> > caches may still be disabled, and so on architectures where uncached
>> > accesses are incoherent with the caches (such as ARM and AARCH64),
>> > we may read stale data if we don't clean the caches to memory first.
>> >
>> > Note that this cache maintenance cannot be done during the invocation
>> > of UpdateCapsule(), since the ScatterGatherList structures are only
>> > identified by physical address, and at runtime, the firmware doesn't
>> > know whether and where this memory is mapped, and cache maintenance
>> > requires a virtual address.
>> >
>> > Reviewed-by: Jiewen Yao 
>> > Contributed-under: TianoCore Contribution Agreement 1.1
>> > Signed-off-by: Ard Biesheuvel 
>>
>> Star,
>>
>> If you are ok with this version of the patch, please let me know.
>>
>> This patch and the PsciResetSystemLib one are prerequisites for making
>> PersistAcrossReset capsules work at all on ARM systems. The remaining
>> patches are only relevant when using the new progress reporting APIs,
>> so those can wait, but I would like to merge this one as soon as it is
>> ready.
>>
>> Thanks,
>> Ard.
>>
>>
>> > ---
>> >  MdeModulePkg/Universal/CapsulePei/CapsulePei.inf   |  1 +
>> >  MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c | 38
>> ++--
>> >  2 files changed, 28 insertions(+), 11 deletions(-)
>> >
>> > diff --git a/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
>> b/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
>> > index c54bc21a95a8..594e110d1f8a 100644
>> > --- a/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
>> > +++ b/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
>> > @@ -48,6 +48,7 @@ [Packages]
>> >
>> >  [LibraryClasses]
>> >BaseLib
>> > +  CacheMaintenanceLib
>> >HobLib
>> >BaseMemoryLib
>> >PeiServicesLib
>> > diff --git a/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
>> b/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
>> > index 3e7054cd38a9..52b80e30b479 100644
>> > --- a/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
>> > +++ b/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
>> > @@ -27,6 +27,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
>> KIND, EITHER EXPRESS OR IMPLIED.
>> >  #include 
>> >
>> >  #include 
>> > +#include 
>> >  #include 
>> >  #include 
>> >  #include 
>> > @@ -253,6 +254,7 @@ ValidateCapsuleByMemoryResource (
>> >)
>> >  {
>> >UINTN Index;
>> > +  BOOLEAN   Valid;
>> >
>> >//
>> >// Sanity Check
>> > @@ -270,25 +272,39 @@ ValidateCapsuleByMemoryResource (
>> >  return FALSE;
>> >}
>> >
>> > +  Valid = FALSE;
>> >if (MemoryResource == NULL) {
>> >  //
>> >  // No memory resource descriptor reported in HOB list before capsule
>> Coalesce.
>> >  //
>> > -return TRUE;
>> > +Valid = TRUE;
>> > +  } else {
>> > +for (Index = 0; MemoryResource[Index].ResourceLength != 0; Index++) {
>> > +  if ((Address >= MemoryResource[Index].PhysicalStart) &&
>> > +  ((Address + Size) <= (MemoryResource[Index].PhysicalStart +
>> MemoryResource[Index].ResourceLength))) {
>> > +DEBUG ((EFI_D_INFO, "Address(0x%lx) Size(0x%lx) in
>> MemoryResource[0x%x] - Start(0x%lx) Length(0x%lx)\n",
>> > +Address, Size,
>> > +Index,
>> MemoryResource[Index].PhysicalStart,
>> MemoryResource[Index].ResourceLength));
>> > +Valid = TRUE;
>> > +break;
>> > +  }
>> > +}
>> > +if (!Valid) {
>> > +  DEBUG ((EFI_D_ERROR, "ERROR: Address(0x%lx) Size(0x%lx) not in
>> any MemoryResource\n", Address, Size));
>> > +}
>> >}
>> >
>> > -  for (Index = 0; MemoryResource[Index].ResourceLength != 0; Index++) {
>> > -if ((Address >= MemoryResource[Index].PhysicalStart) &&
>> > -((Address + Size) <= (MemoryResource[Index].PhysicalStart +
>> MemoryResource[Index].ResourceLength))) {
>> > -  DEBUG 

Re: [edk2] [PATCH v2 1/5] MdeModulePkg/CapsulePei: clean Dcache before consuming capsule data

[Yao, Jiewen]

Hi Ard
May I suggest that we split the Capsule Dispatch patch from the cache 
maintenance patch?

I think the former may require more time for design discussion.

Thank you
Yao Jiewen


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, June 11, 2018 2:25 PM
> To: edk2-devel@lists.01.org
> Cc: Leif Lindholm ; Zeng, Star 
> ;
> Yao, Jiewen ; Kinney, Michael D
> ; Ard Biesheuvel 
> Subject: Re: [PATCH v2 1/5] MdeModulePkg/CapsulePei: clean Dcache before
> consuming capsule data
> 
> On 8 June 2018 at 08:58, Ard Biesheuvel  wrote:
> > When capsule updates are staged for processing after a warm reboot,
> > they are copied into memory with the MMU and caches enabled. When
> > the capsule PEI gets around to coalescing the capsule, the MMU and
> > caches may still be disabled, and so on architectures where uncached
> > accesses are incoherent with the caches (such as ARM and AARCH64),
> > we may read stale data if we don't clean the caches to memory first.
> >
> > Note that this cache maintenance cannot be done during the invocation
> > of UpdateCapsule(), since the ScatterGatherList structures are only
> > identified by physical address, and at runtime, the firmware doesn't
> > know whether and where this memory is mapped, and cache maintenance
> > requires a virtual address.
> >
> > Reviewed-by: Jiewen Yao 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
> 
> Star,
> 
> If you are ok with this version of the patch, please let me know.
> 
> This patch and the PsciResetSystemLib one are prerequisites for making
> PersistAcrossReset capsules work at all on ARM systems. The remaining
> patches are only relevant when using the new progress reporting APIs,
> so those can wait, but I would like to merge this one as soon as it is
> ready.
> 
> Thanks,
> Ard.
> 
> 
> > ---
> >  MdeModulePkg/Universal/CapsulePei/CapsulePei.inf   |  1 +
> >  MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c | 38
> ++--
> >  2 files changed, 28 insertions(+), 11 deletions(-)
> >
> > diff --git a/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> b/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> > index c54bc21a95a8..594e110d1f8a 100644
> > --- a/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> > +++ b/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> > @@ -48,6 +48,7 @@ [Packages]
> >
> >  [LibraryClasses]
> >BaseLib
> > +  CacheMaintenanceLib
> >HobLib
> >BaseMemoryLib
> >PeiServicesLib
> > diff --git a/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
> b/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
> > index 3e7054cd38a9..52b80e30b479 100644
> > --- a/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
> > +++ b/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
> > @@ -27,6 +27,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
> >  #include 
> >
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -253,6 +254,7 @@ ValidateCapsuleByMemoryResource (
> >)
> >  {
> >UINTN Index;
> > +  BOOLEAN   Valid;
> >
> >//
> >// Sanity Check
> > @@ -270,25 +272,39 @@ ValidateCapsuleByMemoryResource (
> >  return FALSE;
> >}
> >
> > +  Valid = FALSE;
> >if (MemoryResource == NULL) {
> >  //
> >  // No memory resource descriptor reported in HOB list before capsule
> Coalesce.
> >  //
> > -return TRUE;
> > +Valid = TRUE;
> > +  } else {
> > +for (Index = 0; MemoryResource[Index].ResourceLength != 0; Index++) {
> > +  if ((Address >= MemoryResource[Index].PhysicalStart) &&
> > +  ((Address + Size) <= (MemoryResource[Index].PhysicalStart +
> MemoryResource[Index].ResourceLength))) {
> > +DEBUG ((EFI_D_INFO, "Address(0x%lx) Size(0x%lx) in
> MemoryResource[0x%x] - Start(0x%lx) Length(0x%lx)\n",
> > +Address, Size,
> > +Index,
> MemoryResource[Index].PhysicalStart,
> MemoryResource[Index].ResourceLength));
> > +Valid = TRUE;
> > +break;
> > +  }
> > +}
> > +if (!Valid) {
> > +  DEBUG ((EFI_D_ERROR, "ERROR: Address(0x%lx) Size(0x%lx) not in
> any MemoryResource\n", Address, Size));
> > +}
> >}
> >
> > -  for (Index = 0; MemoryResource[Index].ResourceLength != 0; Index++) {
> > -if ((Address >= MemoryResource[Index].PhysicalStart) &&
> > -((Address + Size) <= (MemoryResource[Index].PhysicalStart +
> MemoryResource[Index].ResourceLength))) {
> > -  DEBUG ((EFI_D_INFO, "Address(0x%lx) Size(0x%lx) in
> MemoryResource[0x%x] - Start(0x%lx) Length(0x%lx)\n",
> > -  Address, Size,
> > -  Index, MemoryResource[Index].PhysicalStart,
> MemoryResource[Index].ResourceLength));
> > -  return TRUE;
> > -}
> > +  if (Valid) {
> > +//
> > +// At this point, we 

Re: [edk2] [PATCH v2 1/5] MdeModulePkg/CapsulePei: clean Dcache before consuming capsule data

[Ard Biesheuvel]

On 8 June 2018 at 08:58, Ard Biesheuvel  wrote:
> When capsule updates are staged for processing after a warm reboot,
> they are copied into memory with the MMU and caches enabled. When
> the capsule PEI gets around to coalescing the capsule, the MMU and
> caches may still be disabled, and so on architectures where uncached
> accesses are incoherent with the caches (such as ARM and AARCH64),
> we may read stale data if we don't clean the caches to memory first.
>
> Note that this cache maintenance cannot be done during the invocation
> of UpdateCapsule(), since the ScatterGatherList structures are only
> identified by physical address, and at runtime, the firmware doesn't
> know whether and where this memory is mapped, and cache maintenance
> requires a virtual address.
>
> Reviewed-by: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Star,

If you are ok with this version of the patch, please let me know.

This patch and the PsciResetSystemLib one are prerequisites for making
PersistAcrossReset capsules work at all on ARM systems. The remaining
patches are only relevant when using the new progress reporting APIs,
so those can wait, but I would like to merge this one as soon as it is
ready.

Thanks,
Ard.


> ---
>  MdeModulePkg/Universal/CapsulePei/CapsulePei.inf   |  1 +
>  MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c | 38 
> ++--
>  2 files changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf 
> b/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> index c54bc21a95a8..594e110d1f8a 100644
> --- a/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> +++ b/MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> @@ -48,6 +48,7 @@ [Packages]
>
>  [LibraryClasses]
>BaseLib
> +  CacheMaintenanceLib
>HobLib
>BaseMemoryLib
>PeiServicesLib
> diff --git a/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c 
> b/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
> index 3e7054cd38a9..52b80e30b479 100644
> --- a/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
> +++ b/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
> @@ -27,6 +27,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  #include 
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -253,6 +254,7 @@ ValidateCapsuleByMemoryResource (
>)
>  {
>UINTN Index;
> +  BOOLEAN   Valid;
>
>//
>// Sanity Check
> @@ -270,25 +272,39 @@ ValidateCapsuleByMemoryResource (
>  return FALSE;
>}
>
> +  Valid = FALSE;
>if (MemoryResource == NULL) {
>  //
>  // No memory resource descriptor reported in HOB list before capsule 
> Coalesce.
>  //
> -return TRUE;
> +Valid = TRUE;
> +  } else {
> +for (Index = 0; MemoryResource[Index].ResourceLength != 0; Index++) {
> +  if ((Address >= MemoryResource[Index].PhysicalStart) &&
> +  ((Address + Size) <= (MemoryResource[Index].PhysicalStart + 
> MemoryResource[Index].ResourceLength))) {
> +DEBUG ((EFI_D_INFO, "Address(0x%lx) Size(0x%lx) in 
> MemoryResource[0x%x] - Start(0x%lx) Length(0x%lx)\n",
> +Address, Size,
> +Index, MemoryResource[Index].PhysicalStart, 
> MemoryResource[Index].ResourceLength));
> +Valid = TRUE;
> +break;
> +  }
> +}
> +if (!Valid) {
> +  DEBUG ((EFI_D_ERROR, "ERROR: Address(0x%lx) Size(0x%lx) not in any 
> MemoryResource\n", Address, Size));
> +}
>}
>
> -  for (Index = 0; MemoryResource[Index].ResourceLength != 0; Index++) {
> -if ((Address >= MemoryResource[Index].PhysicalStart) &&
> -((Address + Size) <= (MemoryResource[Index].PhysicalStart + 
> MemoryResource[Index].ResourceLength))) {
> -  DEBUG ((EFI_D_INFO, "Address(0x%lx) Size(0x%lx) in 
> MemoryResource[0x%x] - Start(0x%lx) Length(0x%lx)\n",
> -  Address, Size,
> -  Index, MemoryResource[Index].PhysicalStart, 
> MemoryResource[Index].ResourceLength));
> -  return TRUE;
> -}
> +  if (Valid) {
> +//
> +// At this point, we may still be running with the MMU and caches 
> disabled,
> +// and on architectures such as ARM or AARCH64, capsule [meta]data loaded
> +// into memory with the caches on is only guaranteed to be visible to the
> +// CPU running with the caches off after performing an explicit 
> writeback.
> +//
> +WriteBackDataCacheRange ((VOID *)(UINTN)Address, (UINTN)Size);
>}
>
> -  DEBUG ((EFI_D_ERROR, "ERROR: Address(0x%lx) Size(0x%lx) not in any 
> MemoryResource\n", Address, Size));
> -  return FALSE;
> +  return Valid;
>  }
>
>  /**
> --
> 2.17.0
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch] Vlv2TbltDevicePkg: Set SMM Stack size to 16 KB

[Kinney, Michael D]

From: Michael D Kinney 

Stack overflows were observed at the default SMM stack
size of 8 KB.  Increase stack size to 16 KB to prevent
SMM stack overflows.

Cc: David Wei 
Cc: Mang Guo 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 5 +
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc   | 5 +
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 5 +
 3 files changed, 15 insertions(+)

diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
index b6741257e7..af845ed19f 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
@@ -701,6 +701,11 @@ [PcdsFixedAtBuild.common]
   gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|2
 !endif
 
+  #
+  # Set SMM stack size to 16 KB.
+  #
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
+
 [PcdsFixedAtBuild.IA32.PEIM, PcdsFixedAtBuild.IA32.PEI_CORE, 
PcdsFixedAtBuild.IA32.SEC]
 !if $(TARGET) == RELEASE
   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x0
diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
index bd276f0643..44a6fcab18 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
@@ -701,6 +701,11 @@ [PcdsFixedAtBuild.common]
   gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|2
 !endif
 
+  #
+  # Set SMM stack size to 16 KB.
+  #
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
+
 [PcdsFixedAtBuild.IA32.PEIM, PcdsFixedAtBuild.IA32.PEI_CORE, 
PcdsFixedAtBuild.IA32.SEC]
 !if $(TARGET) == RELEASE
   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x0
diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
index 042a35b2b7..0217a2818f 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
@@ -701,6 +701,11 @@ [PcdsFixedAtBuild.common]
   gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|2
 !endif
 
+  #
+  # Set SMM stack size to 16 KB.
+  #
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
+
 [PcdsFixedAtBuild.IA32]
 !if $(TARGET) == RELEASE
   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x0
-- 
2.14.2.windows.3

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

Re: [edk2] [PATCH v2] BaseTools/tools_def IA32: disable PIE code generation explicitly

[Laszlo Ersek]

On 06/11/18 18:29, Ard Biesheuvel wrote:
> As a security measure, some distros now build their GCC toolchains with
> PIE code generation enabled by default, because it is a prerequisite
> for ASLR to be enabled when running the executable.
> 
> This typically results in slightly larger code, but it also generates
> ELF relocations that our tooling cannot deal with, so let's disable it
> explicitly when using GCC49 or later for IA32. (Note that this does not
> apply to X64: it uses PIE code deliberately in some cases, and our
> tooling does deal with the resuling relocations)
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Acked-by: Laszlo Ersek 
> ---
>  BaseTools/Conf/tools_def.template | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 7e9c915755ed..733c6ec71709 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -4648,7 +4648,7 @@ DEFINE GCC48_AARCH64_DLINK2_FLAGS= 
> DEF(GCC47_AARCH64_DLINK2_FLAGS)
>  DEFINE GCC48_ARM_ASLDLINK_FLAGS  = DEF(GCC47_ARM_ASLDLINK_FLAGS)
>  DEFINE GCC48_AARCH64_ASLDLINK_FLAGS  = DEF(GCC47_AARCH64_ASLDLINK_FLAGS)
>  
> -DEFINE GCC49_IA32_CC_FLAGS   = DEF(GCC48_IA32_CC_FLAGS)
> +DEFINE GCC49_IA32_CC_FLAGS   = DEF(GCC48_IA32_CC_FLAGS) -fno-pic 
> -fno-pie
>  DEFINE GCC49_X64_CC_FLAGS= DEF(GCC48_X64_CC_FLAGS)
>  DEFINE GCC49_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-n,-q,--gc-sections -z 
> common-page-size=0x40
>  DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON) 
> -Wl,--entry,ReferenceAcpiTable -u ReferenceAcpiTable
> @@ -5357,10 +5357,10 @@ RELEASE_GCC48_AARCH64_CC_FLAGS   = 
> DEF(GCC48_AARCH64_CC_FLAGS) -Wno-unused-but-s
>  *_GCC49_IA32_RC_PATH  = DEF(GCC49_IA32_PREFIX)objcopy
>  
>  *_GCC49_IA32_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m32
> -*_GCC49_IA32_ASLDLINK_FLAGS   = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS) 
> -Wl,-m,elf_i386
> +*_GCC49_IA32_ASLDLINK_FLAGS   = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS) 
> -Wl,-m,elf_i386 -no-pie
>  *_GCC49_IA32_ASM_FLAGS= DEF(GCC49_ASM_FLAGS) -m32 -march=i386
>  *_GCC49_IA32_DLINK_FLAGS  = DEF(GCC49_IA32_X64_DLINK_FLAGS) 
> -Wl,-m,elf_i386,--oformat=elf32-i386
> -*_GCC49_IA32_DLINK2_FLAGS = DEF(GCC49_IA32_DLINK2_FLAGS)
> +*_GCC49_IA32_DLINK2_FLAGS = DEF(GCC49_IA32_DLINK2_FLAGS) -no-pie
>  *_GCC49_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
>  *_GCC49_IA32_OBJCOPY_FLAGS= 
>  *_GCC49_IA32_NASM_FLAGS   = -f elf32
> @@ -5502,9 +5502,9 @@ RELEASE_GCC49_AARCH64_DLINK_FLAGS  = 
> DEF(GCC49_AARCH64_DLINK_FLAGS)
>  *_GCC5_IA32_RC_PATH  = DEF(GCC5_IA32_PREFIX)objcopy
>  
>  *_GCC5_IA32_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m32 -fno-lto
> -*_GCC5_IA32_ASLDLINK_FLAGS   = DEF(GCC5_IA32_X64_ASLDLINK_FLAGS) 
> -Wl,-m,elf_i386
> +*_GCC5_IA32_ASLDLINK_FLAGS   = DEF(GCC5_IA32_X64_ASLDLINK_FLAGS) 
> -Wl,-m,elf_i386 -no-pie
>  *_GCC5_IA32_ASM_FLAGS= DEF(GCC5_ASM_FLAGS) -m32 -march=i386
> -*_GCC5_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS)
> +*_GCC5_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS) -no-pie
>  *_GCC5_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
>  *_GCC5_IA32_OBJCOPY_FLAGS=
>  *_GCC5_IA32_NASM_FLAGS   = -f elf32
> 

Right, covering GCC49 works for me too. Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/4] OvmfPkg: add QemuRamfb to platform console

[Laszlo Ersek]

On 06/11/18 18:24, Laszlo Ersek wrote:
> On 06/08/18 13:39, Gerd Hoffmann wrote:
>> Add QemuRamfbDxe device path to the list of platform console devices,
>> so ConSplitter will pick up the device even though it isn't a PCI GPU.
> 
> This explanation is not wrong, but I'll list more details, just in case.
> 
> By adding the devpath to "gPlatformConsole" with CONSOLE_OUT,
> technically we push the devpath into the ConOut UEFI variable, as
> follows:
> 
>   BdsEntry()  
> [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]
> PlatformBootManagerBeforeConsole()
> [OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c]
>   PlatformInitializeConsole() 
> [OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c]
> EfiBootManagerUpdateConsoleVariable() 
> [MdeModulePkg/Library/UefiBootManagerLib/BmConsole.c]
> 
> After this, BdsEntry goes on to actually connect the device (i.e., it
> makes the QemuRamfbDxe driver bind the device):
> 
>   BdsEntry()  
> [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]
> EfiBootManagerConnectAllDefaultConsoles() 
> [MdeModulePkg/Library/UefiBootManagerLib/BmConsole.c]
> 
> Binding drivers to keyboard, serial and graphics devices, so that text
> input, text output, and graphics output protocols are produced, isn't
> per se sufficient for ConSplitterDxe to multiplex to/from those
> protocols. For that, ConPlatformDxe needs to "tag" the handles with
> EfiConsole(In|Out)DeviceGuid|EfiStandardErrorDeviceGuid --
> ConSplitterDxe depends on those protocols. It's ConPlatformDxe that
> needs the devpath to be in ConIn/ConOut/ErrOut, for the "tagging" to
> occur.
> 
> In total, we add the ramfb devpath to "gPlatformConsole" so that our
> PlatformInitializeConsole() function puts it in ConOut, despite ramfb
> not being a PCI display device. Binding the device to QemuRamFbDxe, and
> multiplexing from/to it happen "automatically" from there, thanks to
> BdsDxe, and ConPlatformDxe/ConSplitterDxe respectively.

Whoops, managed to confuse myself a little here; some correction should
be in order:

The ramfb driver does not follow the UEFI driver model. The GOP is
produced right in the entry point of the driver, not when platform BDS
connects the device.

It remains true however that ConPlatformDxe / ConSplitterDxe, which do
follow the UEFI driver model, bind the GOP in
EfiBootManagerConnectAllDefaultConsoles(). I guess I would re-formulate,

"""
In total, we add the ramfb devpath to "gPlatformConsole" so that our
PlatformInitializeConsole() function puts it in ConOut, despite ramfb
not being a PCI display device. Multiplexing from/to the ramfb GOP
happens "automatically" from there, thanks to
ConPlatformDxe/ConSplitterDxe.
"""

Which is basically what the current commit message says. :)

Sorry for any confusion caused!
Laszlo

> 
> (1) I don't mind if you stick with the current commit message; I just
> wanted to provide more details for this discussion.
> 
> More comments below:
> 
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Gerd Hoffmann 
>> ---
>>  .../Library/PlatformBootManagerLib/PlatformData.c  | 44 
>> ++
>>  1 file changed, 44 insertions(+)
>>
>> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c 
>> b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
>> index a50cd7bcaf..6202516971 100644
>> --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
>> +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
>> @@ -14,6 +14,7 @@
>>  **/
>>
>>  #include "BdsPlatform.h"
>> +#include 
>>
>>  //
>>  // Debug Agent UART Device Path structure
>> @@ -37,6 +38,17 @@ typedef struct {
>>  } USB_KEYBOARD_DEVICE_PATH;
>>  #pragma pack ()
>>
>> +//
>> +// QemuRamfb Device Path structure
>> +//
>> +#pragma pack(1)
>> +typedef struct {
>> +  VENDOR_DEVICE_PATHVendor;
>> +  ACPI_ADR_DEVICE_PATH  AcpiAdr;
>> +  EFI_DEVICE_PATH_PROTOCOL  End;
>> +} VENDOR_RAMFB_DEVICE_PATH;
>> +#pragma pack()
> 
> (2) Please add a space character between each "pack" and "(".
> 
>> +
>>  ACPI_HID_DEVICE_PATH   gPnpPs2KeyboardDeviceNode  = gPnpPs2Keyboard;
>>  ACPI_HID_DEVICE_PATH   gPnp16550ComPortDeviceNode = gPnp16550ComPort;
>>  UART_DEVICE_PATH   gUartDeviceNode= gUart;
>> @@ -100,6 +112,34 @@ STATIC USB_KEYBOARD_DEVICE_PATH gUsbKeyboardDevicePath 
>> = {
>>gEndEntire
>>  };
>>
>> +STATIC VENDOR_RAMFB_DEVICE_PATH gQemuRamfbDevicePath = {
>> +  {
>> +{
>> +  HARDWARE_DEVICE_PATH,
>> +  HW_VENDOR_DP,
>> +  {
>> +(UINT8) (sizeof (VENDOR_DEVICE_PATH)),
>> +(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
>> +  }
>> +},
>> +QEMU_RAMFB_GUID,
>> +  },
>> +  {
>> +{
>> +  ACPI_DEVICE_PATH,
>> +  ACPI_ADR_DP,
>> +  {
>> +(UINT8) (sizeof (ACPI_ADR_DEVICE_PATH)),
>> +(UINT8) ((sizeof (ACPI_ADR_DEVICE_PATH)) >> 8)
>> +  }
>> +},
>> +

Re: [edk2] [PATCH 0/4] Add QemuRamfbDxe driver

[Laszlo Ersek]

On 06/08/18 13:39, Gerd Hoffmann wrote:
> This is the efi driver for qemu ramfb, a simple boot framebuffer.
> Qemu patches just have been posted to qemu-devel.
> 
> Gerd Hoffmann (4):
>   OvmfPkg: add QEMU_RAMFB_GUID
>   OvmfPkg: add QemuRamfbDxe
>   OvmfPkg: add QemuRamfb to platform console
>   ArmVirtPkg: add QemuRamfbDxe
> 
>  OvmfPkg/Include/Guid/QemuRamfb.h   |  25 ++
>  .../Library/PlatformBootManagerLib/PlatformData.c  |  44 +++
>  OvmfPkg/QemuRamfbDxe/QemuRamfb.c   | 308 
> +
>  ArmVirtPkg/ArmVirtQemu.dsc |   2 +
>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc   |   1 +
>  ArmVirtPkg/ArmVirtQemuKernel.dsc   |   2 +
>  OvmfPkg/OvmfPkg.dec|   1 +
>  OvmfPkg/OvmfPkgIa32.dsc|   1 +
>  OvmfPkg/OvmfPkgIa32.fdf|   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc |   1 +
>  OvmfPkg/OvmfPkgIa32X64.fdf |   1 +
>  OvmfPkg/OvmfPkgX64.dsc |   1 +
>  OvmfPkg/OvmfPkgX64.fdf |   1 +
>  OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf  |  34 +++
>  14 files changed, 423 insertions(+)
>  create mode 100644 OvmfPkg/Include/Guid/QemuRamfb.h
>  create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfb.c
>  create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
> 

Some testing related questions:

- What happens in the UEFI shell if you do recursive connect/disconnect
cycles for all handles in the system? (Preferably initiated from serial.)

- What happens if you locate the parent handle (with the VenHw node)
and/or the child handle (with the GOP on it), and try to disconnect them?

- Have you tested mode changes with the MODE command?

Expected results:

- recursive connect / disconnect should not break, as far as the entire
system is concerned; the procedure should simply skip ramfb.

- targeted connect / disconnect for ramfb should fail (produce an error
message), but nothing should crash or stop working.

- mode changes should work.

I expect the first two behaviors because the driver is a platform DXE
driver, not a UEFI driver that conforms to the UEFI driver model -- we
don't install an EFI_DRIVER_BINDING_PROTOCOL instance, hence the driver
should be "invisible" to the connect / disconnect UEFI shell commands
(they should fail gracefully).

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

Re: [edk2] [PATCH 4/4] ArmVirtPkg: add QemuRamfbDxe

[Laszlo Ersek]

On 06/08/18 13:39, Gerd Hoffmann wrote:
> Build wireup for ArmVirt.

Ard requested earlier that we include the meaning of the subject line in
the body of the commit message as well, so that the commit message can
be sensibly read without looking at the subject line.

With a bit more elaboration like that:

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Gerd Hoffmann 
> ---
>  ArmVirtPkg/ArmVirtQemu.dsc   | 2 ++
>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 +
>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 ++
>  3 files changed, 5 insertions(+)
> 
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index d74feb709c..744d127a10 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -57,6 +57,7 @@
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
>
> PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
> +  
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
>FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
>
> PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
> @@ -391,6 +392,7 @@
>#
># Video support
>#
> +  OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
>OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>OvmfPkg/PlatformDxe/Platform.inf
>  
> diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
> b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> index 89f95b2d99..63a202c788 100644
> --- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> +++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> @@ -175,6 +175,7 @@ READ_LOCK_STATUS   = TRUE
>#
># Video support
>#
> +  INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
>INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>INF OvmfPkg/PlatformDxe/Platform.inf
>  
> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index 1e823aeab7..e59f53b728 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -57,6 +57,7 @@
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
>
> PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
> +  
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
>FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
>
> PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
> @@ -380,6 +381,7 @@
>#
># Video support
>#
> +  OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
>OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>OvmfPkg/PlatformDxe/Platform.inf
>  
> 

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

[edk2] [PATCH v2] BaseTools/tools_def IA32: disable PIE code generation explicitly

[Ard Biesheuvel]

As a security measure, some distros now build their GCC toolchains with
PIE code generation enabled by default, because it is a prerequisite
for ASLR to be enabled when running the executable.

This typically results in slightly larger code, but it also generates
ELF relocations that our tooling cannot deal with, so let's disable it
explicitly when using GCC49 or later for IA32. (Note that this does not
apply to X64: it uses PIE code deliberately in some cases, and our
tooling does deal with the resuling relocations)

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
---
 BaseTools/Conf/tools_def.template | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 7e9c915755ed..733c6ec71709 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4648,7 +4648,7 @@ DEFINE GCC48_AARCH64_DLINK2_FLAGS= 
DEF(GCC47_AARCH64_DLINK2_FLAGS)
 DEFINE GCC48_ARM_ASLDLINK_FLAGS  = DEF(GCC47_ARM_ASLDLINK_FLAGS)
 DEFINE GCC48_AARCH64_ASLDLINK_FLAGS  = DEF(GCC47_AARCH64_ASLDLINK_FLAGS)
 
-DEFINE GCC49_IA32_CC_FLAGS   = DEF(GCC48_IA32_CC_FLAGS)
+DEFINE GCC49_IA32_CC_FLAGS   = DEF(GCC48_IA32_CC_FLAGS) -fno-pic 
-fno-pie
 DEFINE GCC49_X64_CC_FLAGS= DEF(GCC48_X64_CC_FLAGS)
 DEFINE GCC49_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-n,-q,--gc-sections -z 
common-page-size=0x40
 DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON) 
-Wl,--entry,ReferenceAcpiTable -u ReferenceAcpiTable
@@ -5357,10 +5357,10 @@ RELEASE_GCC48_AARCH64_CC_FLAGS   = 
DEF(GCC48_AARCH64_CC_FLAGS) -Wno-unused-but-s
 *_GCC49_IA32_RC_PATH  = DEF(GCC49_IA32_PREFIX)objcopy
 
 *_GCC49_IA32_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m32
-*_GCC49_IA32_ASLDLINK_FLAGS   = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS) 
-Wl,-m,elf_i386
+*_GCC49_IA32_ASLDLINK_FLAGS   = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS) 
-Wl,-m,elf_i386 -no-pie
 *_GCC49_IA32_ASM_FLAGS= DEF(GCC49_ASM_FLAGS) -m32 -march=i386
 *_GCC49_IA32_DLINK_FLAGS  = DEF(GCC49_IA32_X64_DLINK_FLAGS) 
-Wl,-m,elf_i386,--oformat=elf32-i386
-*_GCC49_IA32_DLINK2_FLAGS = DEF(GCC49_IA32_DLINK2_FLAGS)
+*_GCC49_IA32_DLINK2_FLAGS = DEF(GCC49_IA32_DLINK2_FLAGS) -no-pie
 *_GCC49_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
 *_GCC49_IA32_OBJCOPY_FLAGS= 
 *_GCC49_IA32_NASM_FLAGS   = -f elf32
@@ -5502,9 +5502,9 @@ RELEASE_GCC49_AARCH64_DLINK_FLAGS  = 
DEF(GCC49_AARCH64_DLINK_FLAGS)
 *_GCC5_IA32_RC_PATH  = DEF(GCC5_IA32_PREFIX)objcopy
 
 *_GCC5_IA32_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m32 -fno-lto
-*_GCC5_IA32_ASLDLINK_FLAGS   = DEF(GCC5_IA32_X64_ASLDLINK_FLAGS) 
-Wl,-m,elf_i386
+*_GCC5_IA32_ASLDLINK_FLAGS   = DEF(GCC5_IA32_X64_ASLDLINK_FLAGS) 
-Wl,-m,elf_i386 -no-pie
 *_GCC5_IA32_ASM_FLAGS= DEF(GCC5_ASM_FLAGS) -m32 -march=i386
-*_GCC5_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS)
+*_GCC5_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS) -no-pie
 *_GCC5_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
 *_GCC5_IA32_OBJCOPY_FLAGS=
 *_GCC5_IA32_NASM_FLAGS   = -f elf32
-- 
2.17.1

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

Re: [edk2] [PATCH] BaseTools/tools_def IA32: disable PIE code generation explicitly

[Ard Biesheuvel]

On 11 June 2018 at 18:09, Gao, Liming  wrote:
> Ard:
>   GCC49 tool chain can be used by GCC4.9 and above compiler. It provides the 
> GCC setting without LTO. GCC5 tool chain provides GCC setting with LTO. So, I 
> suggest to disable it also in GCC49 tool chain.
>

OK that works for me.


>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Tuesday, June 12, 2018 12:04 AM
>> To: Gao, Liming 
>> Cc: edk2-devel@lists.01.org; ler...@redhat.com; 
>> zenith...@users.sourceforge.net
>> Subject: Re: [edk2] [PATCH] BaseTools/tools_def IA32: disable PIE code 
>> generation explicitly
>>
>> On 11 June 2018 at 18:00, Gao, Liming  wrote:
>> > Ard:
>> >   Is this option required in GCC49 tool chain? Or, this option is only 
>> > required when lto is enabled?
>> >
>>
>> It has nothing to do with LTO.
>>
>> In theory, it could be required for any toolchain that supports -fpic
>> and or -fpie. However, not all 4.x toolchains support -fpie and so
>> they don't support -fno-pie either.
>>
>> Given that the distros only changed this default recently (in the 5.x
>> timeframe or later), it makes sense to only disable it for GCC5,
>> although it is safe to disable it for GCC49 as well.
>>
>> >> -Original Message-
>> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> >> Ard Biesheuvel
>> >> Sent: Monday, June 11, 2018 4:53 PM
>> >> To: Gao, Liming 
>> >> Cc: edk2-devel@lists.01.org; ler...@redhat.com; 
>> >> zenith...@users.sourceforge.net
>> >> Subject: Re: [edk2] [PATCH] BaseTools/tools_def IA32: disable PIE code 
>> >> generation explicitly
>> >>
>> >> On 11 June 2018 at 10:38, Gao, Liming  wrote:
>> >> > Ard:
>> >> >   Do you mean the default GCC compiler disables PIC and PIE for IA32 
>> >> > arch? But now, some distribution GCC compiler enables
>> PIC
>> >> and PIE by default. So, we have to obviously disable PIC and PIE in 
>> >> tools_def.txt.
>> >> >
>> >>
>> >> Yes. On my x86 Ubuntu 18.04 LTS system:
>> >>
>> >> $ gcc -v
>> >> Using built-in specs.
>> >> COLLECT_GCC=gcc
>> >> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
>> >> OFFLOAD_TARGET_NAMES=nvptx-none
>> >> OFFLOAD_TARGET_DEFAULT=1
>> >> Target: x86_64-linux-gnu
>> >> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
>> >> 7.3.0-16ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
>> >> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
>> >> --prefix=/usr --with-gcc-major-version-only
>> >> --with-as=/usr/bin/x86_64-linux-gnu-as
>> >> --with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7
>> >> --program-prefix=x86_64-linux-gnu- --enable-shared
>> >> --enable-linker-build-id --libexecdir=/usr/lib
>> >> --without-included-gettext --enable-threads=posix --libdir=/usr/lib
>> >> --enable-nls --with-sysroot=/ --enable-clocale=gnu
>> >> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
>> >> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
>> >> --disable-vtable-verify --enable-libmpx --enable-plugin
>> >> --enable-default-pie --with-system-zlib --with-target-system-zlib
>> >> --enable-objc-gc=auto --enable-multiarch --disable-werror
>> >> --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
>> >> --enable-multilib --with-tune=generic
>> >> --enable-offload-targets=nvptx-none --without-cuda-driver
>> >> --enable-checking=release --build=x86_64-linux-gnu
>> >> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
>> >> Thread model: posix
>> >> gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)
>> >>
>> >>
>> >> Notice the '--enable-default-pie' 4 lines from the bottom.
>> >>
>> >>
>> >>
>> >> >>-Original Message-
>> >> >>From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> >> >>Sent: Monday, June 11, 2018 3:42 PM
>> >> >>To: edk2-devel@lists.01.org
>> >> >>Cc: Zhu, Yonghong ; Gao, Liming
>> >> >>; ler...@redhat.com; Shi, Steven
>> >> >>; zenith...@users.sourceforge.net; Ard Biesheuvel
>> >> >>
>> >> >>Subject: [PATCH] BaseTools/tools_def IA32: disable PIE code generation
>> >> >>explicitly
>> >> >>
>> >> >>As a security measure, some distros now build their GCC toolchains with
>> >> >>PIE code generation enabled by default, because it is a prerequisite
>> >> >>for ASLR to be enabled when running the executable.
>> >> >>
>> >> >>This typically results in slightly larger code, but it also generates
>> >> >>ELF relocations that our tooling cannot deal with, so let's disable it
>> >> >>explicitly when using GCC5 for IA32. (Note that this does not apply to
>> >> >>X64: it uses PIE code deliberately in some cases, and our tooling does
>> >> >>deal with the resuling relocations)
>> >> >>
>> >> >>Contributed-under: TianoCore Contribution Agreement 1.1
>> >> >>Signed-off-by: Ard Biesheuvel 
>> >> >>---
>> >> >> BaseTools/Conf/tools_def.template | 6 +++---
>> >> >> 1 file changed, 3 insertions(+), 3 deletions(-)
>> >> >>
>> >> >>diff --git a/BaseTools/Conf/tools_def.template
>> >> 

Re: [edk2] [PATCH 3/4] OvmfPkg: add QemuRamfb to platform console

[Laszlo Ersek]

On 06/08/18 13:39, Gerd Hoffmann wrote:
> Add QemuRamfbDxe device path to the list of platform console devices,
> so ConSplitter will pick up the device even though it isn't a PCI GPU.

This explanation is not wrong, but I'll list more details, just in case.

By adding the devpath to "gPlatformConsole" with CONSOLE_OUT,
technically we push the devpath into the ConOut UEFI variable, as
follows:

  BdsEntry()  
[MdeModulePkg/Universal/BdsDxe/BdsEntry.c]
PlatformBootManagerBeforeConsole()
[OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c]
  PlatformInitializeConsole() 
[OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c]
EfiBootManagerUpdateConsoleVariable() 
[MdeModulePkg/Library/UefiBootManagerLib/BmConsole.c]

After this, BdsEntry goes on to actually connect the device (i.e., it
makes the QemuRamfbDxe driver bind the device):

  BdsEntry()  
[MdeModulePkg/Universal/BdsDxe/BdsEntry.c]
EfiBootManagerConnectAllDefaultConsoles() 
[MdeModulePkg/Library/UefiBootManagerLib/BmConsole.c]

Binding drivers to keyboard, serial and graphics devices, so that text
input, text output, and graphics output protocols are produced, isn't
per se sufficient for ConSplitterDxe to multiplex to/from those
protocols. For that, ConPlatformDxe needs to "tag" the handles with
EfiConsole(In|Out)DeviceGuid|EfiStandardErrorDeviceGuid --
ConSplitterDxe depends on those protocols. It's ConPlatformDxe that
needs the devpath to be in ConIn/ConOut/ErrOut, for the "tagging" to
occur.

In total, we add the ramfb devpath to "gPlatformConsole" so that our
PlatformInitializeConsole() function puts it in ConOut, despite ramfb
not being a PCI display device. Binding the device to QemuRamFbDxe, and
multiplexing from/to it happen "automatically" from there, thanks to
BdsDxe, and ConPlatformDxe/ConSplitterDxe respectively.

(1) I don't mind if you stick with the current commit message; I just
wanted to provide more details for this discussion.

More comments below:

>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Gerd Hoffmann 
> ---
>  .../Library/PlatformBootManagerLib/PlatformData.c  | 44 
> ++
>  1 file changed, 44 insertions(+)
>
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c 
> b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
> index a50cd7bcaf..6202516971 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
> @@ -14,6 +14,7 @@
>  **/
>
>  #include "BdsPlatform.h"
> +#include 
>
>  //
>  // Debug Agent UART Device Path structure
> @@ -37,6 +38,17 @@ typedef struct {
>  } USB_KEYBOARD_DEVICE_PATH;
>  #pragma pack ()
>
> +//
> +// QemuRamfb Device Path structure
> +//
> +#pragma pack(1)
> +typedef struct {
> +  VENDOR_DEVICE_PATHVendor;
> +  ACPI_ADR_DEVICE_PATH  AcpiAdr;
> +  EFI_DEVICE_PATH_PROTOCOL  End;
> +} VENDOR_RAMFB_DEVICE_PATH;
> +#pragma pack()

(2) Please add a space character between each "pack" and "(".

> +
>  ACPI_HID_DEVICE_PATH   gPnpPs2KeyboardDeviceNode  = gPnpPs2Keyboard;
>  ACPI_HID_DEVICE_PATH   gPnp16550ComPortDeviceNode = gPnp16550ComPort;
>  UART_DEVICE_PATH   gUartDeviceNode= gUart;
> @@ -100,6 +112,34 @@ STATIC USB_KEYBOARD_DEVICE_PATH gUsbKeyboardDevicePath = 
> {
>gEndEntire
>  };
>
> +STATIC VENDOR_RAMFB_DEVICE_PATH gQemuRamfbDevicePath = {
> +  {
> +{
> +  HARDWARE_DEVICE_PATH,
> +  HW_VENDOR_DP,
> +  {
> +(UINT8) (sizeof (VENDOR_DEVICE_PATH)),
> +(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
> +  }
> +},
> +QEMU_RAMFB_GUID,
> +  },
> +  {
> +{
> +  ACPI_DEVICE_PATH,
> +  ACPI_ADR_DP,
> +  {
> +(UINT8) (sizeof (ACPI_ADR_DEVICE_PATH)),
> +(UINT8) ((sizeof (ACPI_ADR_DEVICE_PATH)) >> 8)
> +  }
> +},
> +ACPI_DISPLAY_ADR (1, 0, 0, 1, 0,
> +  ACPI_ADR_DISPLAY_TYPE_EXTERNAL_DIGITAL,
> +  0, 0)

(3) Urgh. On one hand, I dislike this dump of constants; on the other
hand, I don't want to ask you to repeat all the parameter comments that
I asked for in the previous patch.

OK, let's stick with the dump of constants, just make sure the
indentation is idiomatic.

> +  },
> +  gEndEntire
> +};
> +
>  //
>  // Predefined platform default console device path
>  //
> @@ -113,6 +153,10 @@ PLATFORM_CONSOLE_CONNECT_ENTRY   gPlatformConsole[] = {
>  CONSOLE_IN
>},
>{
> +(EFI_DEVICE_PATH_PROTOCOL *),
> +CONSOLE_OUT
> +  },

Right, this is consistent with PreparePciDisplayDevicePath().

Thanks,
Laszlo

> +  {
>  NULL,
>  0
>}
>

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

Re: [edk2] [PATCH] BaseTools/tools_def IA32: disable PIE code generation explicitly

[Gao, Liming]

Ard:
  GCC49 tool chain can be used by GCC4.9 and above compiler. It provides the 
GCC setting without LTO. GCC5 tool chain provides GCC setting with LTO. So, I 
suggest to disable it also in GCC49 tool chain. 

Thanks
Liming
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, June 12, 2018 12:04 AM
> To: Gao, Liming 
> Cc: edk2-devel@lists.01.org; ler...@redhat.com; 
> zenith...@users.sourceforge.net
> Subject: Re: [edk2] [PATCH] BaseTools/tools_def IA32: disable PIE code 
> generation explicitly
> 
> On 11 June 2018 at 18:00, Gao, Liming  wrote:
> > Ard:
> >   Is this option required in GCC49 tool chain? Or, this option is only 
> > required when lto is enabled?
> >
> 
> It has nothing to do with LTO.
> 
> In theory, it could be required for any toolchain that supports -fpic
> and or -fpie. However, not all 4.x toolchains support -fpie and so
> they don't support -fno-pie either.
> 
> Given that the distros only changed this default recently (in the 5.x
> timeframe or later), it makes sense to only disable it for GCC5,
> although it is safe to disable it for GCC49 as well.
> 
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
> >> Biesheuvel
> >> Sent: Monday, June 11, 2018 4:53 PM
> >> To: Gao, Liming 
> >> Cc: edk2-devel@lists.01.org; ler...@redhat.com; 
> >> zenith...@users.sourceforge.net
> >> Subject: Re: [edk2] [PATCH] BaseTools/tools_def IA32: disable PIE code 
> >> generation explicitly
> >>
> >> On 11 June 2018 at 10:38, Gao, Liming  wrote:
> >> > Ard:
> >> >   Do you mean the default GCC compiler disables PIC and PIE for IA32 
> >> > arch? But now, some distribution GCC compiler enables
> PIC
> >> and PIE by default. So, we have to obviously disable PIC and PIE in 
> >> tools_def.txt.
> >> >
> >>
> >> Yes. On my x86 Ubuntu 18.04 LTS system:
> >>
> >> $ gcc -v
> >> Using built-in specs.
> >> COLLECT_GCC=gcc
> >> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
> >> OFFLOAD_TARGET_NAMES=nvptx-none
> >> OFFLOAD_TARGET_DEFAULT=1
> >> Target: x86_64-linux-gnu
> >> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> >> 7.3.0-16ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
> >> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
> >> --prefix=/usr --with-gcc-major-version-only
> >> --with-as=/usr/bin/x86_64-linux-gnu-as
> >> --with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7
> >> --program-prefix=x86_64-linux-gnu- --enable-shared
> >> --enable-linker-build-id --libexecdir=/usr/lib
> >> --without-included-gettext --enable-threads=posix --libdir=/usr/lib
> >> --enable-nls --with-sysroot=/ --enable-clocale=gnu
> >> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> >> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> >> --disable-vtable-verify --enable-libmpx --enable-plugin
> >> --enable-default-pie --with-system-zlib --with-target-system-zlib
> >> --enable-objc-gc=auto --enable-multiarch --disable-werror
> >> --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
> >> --enable-multilib --with-tune=generic
> >> --enable-offload-targets=nvptx-none --without-cuda-driver
> >> --enable-checking=release --build=x86_64-linux-gnu
> >> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> >> Thread model: posix
> >> gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)
> >>
> >>
> >> Notice the '--enable-default-pie' 4 lines from the bottom.
> >>
> >>
> >>
> >> >>-Original Message-
> >> >>From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> >>Sent: Monday, June 11, 2018 3:42 PM
> >> >>To: edk2-devel@lists.01.org
> >> >>Cc: Zhu, Yonghong ; Gao, Liming
> >> >>; ler...@redhat.com; Shi, Steven
> >> >>; zenith...@users.sourceforge.net; Ard Biesheuvel
> >> >>
> >> >>Subject: [PATCH] BaseTools/tools_def IA32: disable PIE code generation
> >> >>explicitly
> >> >>
> >> >>As a security measure, some distros now build their GCC toolchains with
> >> >>PIE code generation enabled by default, because it is a prerequisite
> >> >>for ASLR to be enabled when running the executable.
> >> >>
> >> >>This typically results in slightly larger code, but it also generates
> >> >>ELF relocations that our tooling cannot deal with, so let's disable it
> >> >>explicitly when using GCC5 for IA32. (Note that this does not apply to
> >> >>X64: it uses PIE code deliberately in some cases, and our tooling does
> >> >>deal with the resuling relocations)
> >> >>
> >> >>Contributed-under: TianoCore Contribution Agreement 1.1
> >> >>Signed-off-by: Ard Biesheuvel 
> >> >>---
> >> >> BaseTools/Conf/tools_def.template | 6 +++---
> >> >> 1 file changed, 3 insertions(+), 3 deletions(-)
> >> >>
> >> >>diff --git a/BaseTools/Conf/tools_def.template
> >> >>b/BaseTools/Conf/tools_def.template
> >> >>index 7e9c915755ed..ab57f9c706e3 100755
> >> >>--- a/BaseTools/Conf/tools_def.template
> >> >>+++ b/BaseTools/Conf/tools_def.template
> >> >>@@ -4670,7 

Re: [edk2] [PATCH v3 2/2] ArmVirtPkg: switch to KVM safe IoLib implementation

[Ard Biesheuvel]

On 11 June 2018 at 12:44, Laszlo Ersek  wrote:
> On 06/11/18 09:25, Ard Biesheuvel wrote:
>> Switch to the new IoLib implementation that will only use KVM
>> safe instructions to perform MMIO memory accesses.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> ---
>> v2: split off from 1/1
>>
>>  ArmVirtPkg/ArmVirt.dsc.inc | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
>> index 766e4f598a07..7464ac70ed1b 100644
>> --- a/ArmVirtPkg/ArmVirt.dsc.inc
>> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
>> @@ -41,7 +41,7 @@ [LibraryClasses.common]
>>PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>>
>> PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
>>PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
>> -  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
>> +  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.inf
>>
>> UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
>>CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
>>
>>
>
> Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [PATCH v3 1/2] MdePkg/BaseIoLibIntrinsic: make BaseIoLibIntrinsic safe for ArmVirt/KVM

[Ard Biesheuvel]

On 11 June 2018 at 17:51, Gao, Liming  wrote:
> Reviewed-by: Liming Gao 
>

Pushed as 4134f2bddcb68d2e20ed000cdf54abf3f1140904

Thanks all

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
>> Biesheuvel
>> Sent: Monday, June 11, 2018 3:26 PM
>> To: edk2-devel@lists.01.org
>> Cc: Kinney, Michael D ; ler...@redhat.com; Gao, 
>> Liming ;
>> leif.lindh...@linaro.org; Ard Biesheuvel 
>> Subject: [edk2] [PATCH v3 1/2] MdePkg/BaseIoLibIntrinsic: make 
>> BaseIoLibIntrinsic safe for ArmVirt/KVM
>>
>> KVM on ARM refuses to decode load/store instructions used to perform
>> I/O to emulated devices, and instead relies on the exception syndrome
>> information to describe the operand register, access size, etc.
>> This is only possible for instructions that have a single input/output
>> register (as opposed to ones that increment the offset register, or
>> load/store pair instructions, etc). Otherwise, QEMU crashes with the
>> following error
>>
>>   error: kvm run failed Function not implemented
>>   R00=01010101 R01=0008 R02=0048 R03=08000820
>>   R04=0120 R05=7faaa0e0 R06=7faaa0dc R07=7faaa0e8
>>   R08=7faaa0ec R09=7faaa088 R10=00ff R11=0080
>>   R12=ff00 R13=7fccfe08 R14=7faa835f R15=7faa887c
>>   PSR=81f3 N--- T svc32
>>   QEMU: Terminated
>>
>> and KVM produces a warning such as the following in the kernel log
>>
>>   kvm [17646]: load/store instruction decoding not implemented
>>
>> The IoLib implementation provided by MdePkg/Library/BaseIoLibIntrinsic
>> is based on C code, and when LTO is in effect, the MMIO accesses could
>> be merged with, e.g., manipulations of the loop counter, producing
>> opcodes that KVM does not support for emulated MMIO.
>>
>> So let's add a special ArmVirt flavor of this library that implements
>> that actual load/store operations in assembler, ensuring that the
>> instructions involved can be emulated by KVM.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> ---
>> v3: add missing prototype comments in IoLibArmVirt.c
>> remove mention of ASSERT () from description of internal asm routines
>> v2: add missing .uni file
>> split off ArmVirtPkg change
>> add VS2017 version of AArch64 asm file
>> add reference to MdePkg.dsc
>>
>>  MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S | 148 
>>  MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.asm   | 149 
>>  MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.S | 145 
>>  MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.asm   | 149 
>>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.inf |  52 ++
>>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.uni |  23 +
>>  MdePkg/Library/BaseIoLibIntrinsic/IoLibArmVirt.c| 733 
>> 
>>  MdePkg/MdePkg.dsc   |   1 +
>>  8 files changed, 1400 insertions(+)
>>
>> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S 
>> b/MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S
>> new file mode 100644
>> index ..85f59324270c
>> --- /dev/null
>> +++ b/MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S
>> @@ -0,0 +1,148 @@
>> +#
>> +#  Copyright (c) 2014-2018, Linaro Limited. 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.
>> +#
>> +#
>> +
>> +.text
>> +.align 3
>> +
>> +GCC_ASM_EXPORT(MmioRead8Internal)
>> +GCC_ASM_EXPORT(MmioWrite8Internal)
>> +GCC_ASM_EXPORT(MmioRead16Internal)
>> +GCC_ASM_EXPORT(MmioWrite16Internal)
>> +GCC_ASM_EXPORT(MmioRead32Internal)
>> +GCC_ASM_EXPORT(MmioWrite32Internal)
>> +GCC_ASM_EXPORT(MmioRead64Internal)
>> +GCC_ASM_EXPORT(MmioWrite64Internal)
>> +
>> +//
>> +//  Reads an 8-bit MMIO register.
>> +//
>> +//  Reads the 8-bit MMIO register specified by Address. The 8-bit read 
>> value is
>> +//  returned. This function must guarantee that all MMIO read and write
>> +//  operations are serialized.
>> +//
>> +//  @param  Address The MMIO register to read.
>> +//
>> +//  @return The value read.
>> +//
>> +ASM_PFX(MmioRead8Internal):
>> +  ldrbw0, [x0]
>> +  dmb ld
>> +  ret
>> +
>> +//
>> +//  Writes an 8-bit MMIO register.
>> +//
>> +//  Writes the 8-bit MMIO register specified by Address with the value 
>> specified
>> +//  by Value and returns Value. This function must guarantee that all MMIO 
>> read
>> +//  and write operations are serialized.
>> +//
>> +//  @param  Address The MMIO register to 

Re: [edk2] [PATCH 2/4] OvmfPkg: add QemuRamfbDxe

[Laszlo Ersek]

On 06/08/18 13:39, Gerd Hoffmann wrote:

> diff --git a/OvmfPkg/QemuRamfbDxe/QemuRamfb.c 
> b/OvmfPkg/QemuRamfbDxe/QemuRamfb.c
> new file mode 100644
> index 00..f04a314c24
> --- /dev/null
> +++ b/OvmfPkg/QemuRamfbDxe/QemuRamfb.c
> @@ -0,0 +1,308 @@
> +#include 

(1) I think we should be able to drop this. See the leading comment in
"MdePkg/Include/Uefi.h" -- and this is not a UEFI_DRIVER but a platform
DXE_DRIVER module.

> +#include 
> +
> +#include 

OK, ZeroMem() is from this one.

> +#include 

OK, DEBUG() needs this.

> +#include 

OK, AppendDevicePathNode().

> +#include 

OK, FrameBufferBltConfigure().

> +#include 

OK, AllocateCopyPool().

> +#include 

(2) I think we can drop this. (Please also remove it from the
[LibraryClasses] section in the INF file.)

> +#include 

OK, gBS->InstallMultipleProtocolInterfaces().

> +#include 

(3) Well, strictly speaking, this isn't necessary as an #include -- the
corresponding lib class under [LibraryClasses] *is* necessary though.

I've grepped the tree for this #include directive, and usage is
inconsistent. In new drivers we introduce, I prefer that we not add the
include. Can you please drop it? (Again, do keep it in the INF file.)

> +#include 

(4) I tried to see if we use anything from UefiLib.h, and came up empty.
Can you please attempt to drop it both here and from [LibraryClasses] in
the INF file?

> +#include 

Yup, needed.

> +
> +#include 
> +
> +#define RAMFB_FORMAT  0x34325258 /* DRM_FORMAT_XRGB */
> +#define RAMFB_BPP 4
> +
> +EFI_GUID gQemuRamfbGuid = QEMU_RAMFB_GUID;

(5) Please drop this -- we have the declaration of gQemuRamfbGuid from
, and the definition comes from source code
auto-generated by the build tools.

(I'll comment more on the usage below.)

> +
> +typedef struct RAMFB_CONFIG {
> +  UINT64 Address;
> +  UINT32 FourCC;
> +  UINT32 Flags;
> +  UINT32 Width;
> +  UINT32 Height;
> +  UINT32 Stride;
> +} RAMFB_CONFIG;

(6) Please wrap this in:

#pragma pack (1)
...
#pragma pack ()

(7) We could also add this type definition in a new file
"OvmfPkg/Include/IndustryStandard/QemuRamfbConfig.h". However, I do
realize that's somewhat overkill. Up to you; I don't mind if we keep it
here.

> +
> +EFI_HANDLERamfbHandle;
> +EFI_HANDLEGopHandle;
> +FRAME_BUFFER_CONFIGURE*QemuRamfbFrameBufferBltConfigure;
> +UINTN QemuRamfbFrameBufferBltConfigureSize;

(8) Please make all these variables STATIC, and also prepend an "m"
prefix to their names (it stands for "module"):

STATIC EFI_HANDLEmRamfbHandle;

> +
> +EFI_GRAPHICS_OUTPUT_MODE_INFORMATION QemuRamfbModeInfo[] = {

(9) Same comment as (8).

> +  {
> +.HorizontalResolution  = 640,
> +.VerticalResolution= 480,
> +  },{
> +.HorizontalResolution  = 800,
> +.VerticalResolution= 600,
> +  },{
> +.HorizontalResolution  = 1024,
> +.VerticalResolution= 768,
> +  }
> +};

(10) In edk2 we cannot use designated initializers. I suggest (for
example) assigning these values in the entry point function.

Alternatively, please use the C90-style syntax for aggregate
initialization (i.e. just insert enough zeros):

STATIC EFI_GRAPHICS_OUTPUT_MODE_INFORMATION QemuRamfbModeInfo[] = {
  {
0,   // Version
640, // HorizontalResolution
400, // VerticalResolution
0,   // PixelFormat -- filled in later
0,   // PixelInformation -- will be ignored
0// PixelsPerScanLine -- filled in later
  },
  ...
};

> +#define QemuRamfbModeCount 
> (sizeof(QemuRamfbModeInfo)/sizeof(QemuRamfbModeInfo[0]))

(11) Please use ARRAY_SIZE() instead, wherever necessary.

> +
> +EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE QemuRamfbMode = {
> +  .MaxMode   = QemuRamfbModeCount,
> +  .Mode  = 0,
> +  .Info  = QemuRamfbModeInfo,
> +  .SizeOfInfo= sizeof(EFI_GRAPHICS_OUTPUT_MODE_INFORMATION),
> +};

(12) See (10).

(13) Please insert a space between "sizeof" and "(". In edk2, we put one
space between function identifier / function-like macro name, and the
opening paren, in function calls / macro invocations.

(Obviously, I know that "sizeof" is neither a function nor a macro; it
is an operator. In fact my preferred style is just "sizeof object", no
parens. However, if we use the parens, which is indeed required for
typenames, then we should use one space.)

> +
> +EFI_STATUS
> +EFIAPI
> +QemuRamfbGraphicsOutputQueryMode (

(14) Please also make all functions STATIC, except InitializeQemuRamfb().

> +  IN  EFI_GRAPHICS_OUTPUT_PROTOCOL  *This,
> +  IN  UINT32ModeNumber,
> +  OUT UINTN *SizeOfInfo,
> +  OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  **Info
> +  )
> +{
> +  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *ModeInfo;
> +
> +  if (Info == NULL || SizeOfInfo == NULL || ModeNumber > 
> QemuRamfbMode.MaxMode) {

(15) I think the ModeNumber comparison is off-by-one; 

Re: [edk2] [PATCH v3 1/2] MdePkg/BaseIoLibIntrinsic: make BaseIoLibIntrinsic safe for ArmVirt/KVM

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
> Biesheuvel
> Sent: Monday, June 11, 2018 3:26 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; ler...@redhat.com; Gao, 
> Liming ;
> leif.lindh...@linaro.org; Ard Biesheuvel 
> Subject: [edk2] [PATCH v3 1/2] MdePkg/BaseIoLibIntrinsic: make 
> BaseIoLibIntrinsic safe for ArmVirt/KVM
> 
> KVM on ARM refuses to decode load/store instructions used to perform
> I/O to emulated devices, and instead relies on the exception syndrome
> information to describe the operand register, access size, etc.
> This is only possible for instructions that have a single input/output
> register (as opposed to ones that increment the offset register, or
> load/store pair instructions, etc). Otherwise, QEMU crashes with the
> following error
> 
>   error: kvm run failed Function not implemented
>   R00=01010101 R01=0008 R02=0048 R03=08000820
>   R04=0120 R05=7faaa0e0 R06=7faaa0dc R07=7faaa0e8
>   R08=7faaa0ec R09=7faaa088 R10=00ff R11=0080
>   R12=ff00 R13=7fccfe08 R14=7faa835f R15=7faa887c
>   PSR=81f3 N--- T svc32
>   QEMU: Terminated
> 
> and KVM produces a warning such as the following in the kernel log
> 
>   kvm [17646]: load/store instruction decoding not implemented
> 
> The IoLib implementation provided by MdePkg/Library/BaseIoLibIntrinsic
> is based on C code, and when LTO is in effect, the MMIO accesses could
> be merged with, e.g., manipulations of the loop counter, producing
> opcodes that KVM does not support for emulated MMIO.
> 
> So let's add a special ArmVirt flavor of this library that implements
> that actual load/store operations in assembler, ensuring that the
> instructions involved can be emulated by KVM.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> v3: add missing prototype comments in IoLibArmVirt.c
> remove mention of ASSERT () from description of internal asm routines
> v2: add missing .uni file
> split off ArmVirtPkg change
> add VS2017 version of AArch64 asm file
> add reference to MdePkg.dsc
> 
>  MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S | 148 
>  MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.asm   | 149 
>  MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.S | 145 
>  MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.asm   | 149 
>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.inf |  52 ++
>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.uni |  23 +
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibArmVirt.c| 733 
> 
>  MdePkg/MdePkg.dsc   |   1 +
>  8 files changed, 1400 insertions(+)
> 
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S 
> b/MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S
> new file mode 100644
> index ..85f59324270c
> --- /dev/null
> +++ b/MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S
> @@ -0,0 +1,148 @@
> +#
> +#  Copyright (c) 2014-2018, Linaro Limited. 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.
> +#
> +#
> +
> +.text
> +.align 3
> +
> +GCC_ASM_EXPORT(MmioRead8Internal)
> +GCC_ASM_EXPORT(MmioWrite8Internal)
> +GCC_ASM_EXPORT(MmioRead16Internal)
> +GCC_ASM_EXPORT(MmioWrite16Internal)
> +GCC_ASM_EXPORT(MmioRead32Internal)
> +GCC_ASM_EXPORT(MmioWrite32Internal)
> +GCC_ASM_EXPORT(MmioRead64Internal)
> +GCC_ASM_EXPORT(MmioWrite64Internal)
> +
> +//
> +//  Reads an 8-bit MMIO register.
> +//
> +//  Reads the 8-bit MMIO register specified by Address. The 8-bit read value 
> is
> +//  returned. This function must guarantee that all MMIO read and write
> +//  operations are serialized.
> +//
> +//  @param  Address The MMIO register to read.
> +//
> +//  @return The value read.
> +//
> +ASM_PFX(MmioRead8Internal):
> +  ldrbw0, [x0]
> +  dmb ld
> +  ret
> +
> +//
> +//  Writes an 8-bit MMIO register.
> +//
> +//  Writes the 8-bit MMIO register specified by Address with the value 
> specified
> +//  by Value and returns Value. This function must guarantee that all MMIO 
> read
> +//  and write operations are serialized.
> +//
> +//  @param  Address The MMIO register to write.
> +//  @param  Value   The value to write to the MMIO register.
> +//
> +ASM_PFX(MmioWrite8Internal):
> +  dmb st
> +  strbw1, [x0]
> +  ret
> +
> +//
> +//  Reads a 16-bit MMIO register.
> +//
> +//  Reads the 

Re: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit ProcessCapsules () to be called once

[Kinney, Michael D]

Jiewen,

A platform can have multiple FMP protocols to
update system firmware and may be mapped to
different FW storage devices with different
security attributes.  I think your proposal
would treat them all the same. Right?

Mike



> -Original Message-
> From: Yao, Jiewen
> Sent: Monday, June 11, 2018 6:56 AM
> To: Ard Biesheuvel 
> Cc: Kinney, Michael D ;
> edk2-devel@lists.01.org; Zeng, Star
> ; leif.lindh...@linaro.org
> Subject: RE: [edk2] [PATCH v2 2/5]
> MdeModulePkg/DxeCapsuleLibFmp: permit ProcessCapsules
> () to be called once
> 
> Ah. Good point.
> 
> I think the embedded driver dispatch can be controlled
> by EndOfDxe, which is similar to
> MdeModulePkg\Universal\SecurityStubDxe.
> 
> So we can have both EndOfDxe and
> PcdSystemFmpLockEventGuid.
> EndOfDxe controls embedded driver dispatch.
> PcdSystemFmpLockEventGuid controls 1st call and 2nd
> call.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Ard
> > Biesheuvel
> > Sent: Monday, June 11, 2018 5:40 AM
> > To: Yao, Jiewen 
> > Cc: Kinney, Michael D ;
> edk2-devel@lists.01.org;
> > Zeng, Star ;
> leif.lindh...@linaro.org
> > Subject: Re: [edk2] [PATCH v2 2/5]
> MdeModulePkg/DxeCapsuleLibFmp: permit
> > ProcessCapsules () to be called once
> >
> > On 11 June 2018 at 14:37, Yao, Jiewen
>  wrote:
> > > If all fmp can be processed one time，you just need
> call once. Then system
> > reset.
> > >
> >
> > I understand that. But if the capsule has embedded
> drivers, the
> > library will only dispatch them on the second call,
> even if the
> > platform does not require making that distinction. It
> seems to me that
> > the phasing between the first and the second call is
> closely tied to
> > the semantics of EndOfDxe and the associated policy
> on X86 not to
> > allow third party code before it has been signalled.
> >
> > Could we not parameterize this in some way as well?
> >
> >
> > >
> > >> 在 2018年6月11日，上午12:27，Ard Biesheuvel
> >  写道：
> > >>
> > >>> On 10 June 2018 at 21:21, Yao, Jiewen
>  wrote:
> > >>> Just got some idea since I am also reviewing
> FmpDevicePkg patch.
> > >>>
> > >>>
> > >>> The key problem we are trying to resolve that is:
> The core code uses
> > EndOfDxe as the lock event for system firmware, but
> an ARM platform may want
> > to lock system firmware later, maybe in other lock
> event.
> > >>>
> > >>> As such, how about we generalize the lock event
> as
> > PcdSystemFmpLockEventGuid? We can use EndOfDxeGuid as
> default one to keep
> > the compatibility. At same time this brings the
> flexibility for platform overriding.
> > >>>
> > >>>
> > >>> We only need update DxeCapsuleLibConstructor() to
> use the new PcdGuid,
> > instead of hardcode EndOfDxe.
> > >>> We don't need update the logic in
> ProcessCapsules() and
> > ProcessTheseCapsules().
> > >>> The policy in current platform is already
> enforced, if the platform has a
> > trusted console.
> > >>> For ARM platform, which wants to lock system
> firmware later. It can
> > configure another lock event GUID explicitly in
> platform DSC.
> > >>>
> > >>
> > >> But that means we are still required to call
> ProcessCapsules () twice, no?
> > >>
> >  -Original Message-
> >  From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of
> > Yao,
> >  Jiewen
> >  Sent: Sunday, June 10, 2018 12:02 PM
> >  To: Kinney, Michael D
> ; Ard Biesheuvel
> >  
> >  Cc: edk2-devel@lists.01.org;
> leif.lindh...@linaro.org; Zeng, Star
> >  
> >  Subject: Re: [edk2] [PATCH v2 2/5]
> MdeModulePkg/DxeCapsuleLibFmp:
> > permit
> >  ProcessCapsules () to be called once
> > 
> >  My concern is that *always allowing* processing
> SystemCapsule after
> > EndOfDxe
> >  has security risk.
> > 
> >  IMHO, the risk is not *process*, if it is a
> platform choice. Instead, the risk is
> >  *allow*, in the core logic.
> > 
> >  If we really want to do that, I hope we need a
> way to distinguish the
> > difference
> >  between a platform dispatching SystemCapsule
> after EndOfDxe
> > *purposely* and
> >  a platform dispatching SystemCapsule after
> EndOfDxe *by mistake*.
> > 
> >  Maybe some policy enforcement in the core logic.
> Static policy, at build
> > time.
> > 
> >  Thank you
> >  Yao Jiewen
> > 
> > > -Original Message-
> > > From: Kinney, Michael D
> > > Sent: Sunday, June 10, 2018 8:57 AM
> > > To: Ard Biesheuvel ;
> Yao, Jiewen
> > > ; Kinney, Michael D
> > 
> > > Cc: edk2-devel@lists.01.org; Zeng, Star
> ;
> > > leif.lindh...@linaro.org
> > > Subject: RE: [edk2] [PATCH v2 2/5]
> MdeModulePkg/DxeCapsuleLibFmp:
> > permit
> > > ProcessCapsules () to be called once
> > >
> > > Ard,
> > >
> > > I agree it should be a platform choice to
> process capsules
> > > before or after End of DXE.  It is even allowed
> in 

Re: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit ProcessCapsules () to be called once

[Ard Biesheuvel]

On 11 June 2018 at 15:55, Yao, Jiewen  wrote:
> Ah. Good point.
>
> I think the embedded driver dispatch can be controlled by EndOfDxe, which is 
> similar to MdeModulePkg\Universal\SecurityStubDxe.
>
> So we can have both EndOfDxe and PcdSystemFmpLockEventGuid.
> EndOfDxe controls embedded driver dispatch.
> PcdSystemFmpLockEventGuid controls 1st call and 2nd call.
>

But in our case, we don't need an event at all. The BDS just calls
ProcessCapsules() whenever it wants to.

I'm rather relucant to complicate the code with an additional event
that we don't really need, while retaining some of the EndOfDxe
handling as well. Could you think of another way to handle this use
case?

Thanks,
Ard.

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
>> Biesheuvel
>> Sent: Monday, June 11, 2018 5:40 AM
>> To: Yao, Jiewen 
>> Cc: Kinney, Michael D ; edk2-devel@lists.01.org;
>> Zeng, Star ; leif.lindh...@linaro.org
>> Subject: Re: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit
>> ProcessCapsules () to be called once
>>
>> On 11 June 2018 at 14:37, Yao, Jiewen  wrote:
>> > If all fmp can be processed one time，you just need call once. Then system
>> reset.
>> >
>>
>> I understand that. But if the capsule has embedded drivers, the
>> library will only dispatch them on the second call, even if the
>> platform does not require making that distinction. It seems to me that
>> the phasing between the first and the second call is closely tied to
>> the semantics of EndOfDxe and the associated policy on X86 not to
>> allow third party code before it has been signalled.
>>
>> Could we not parameterize this in some way as well?
>>
>>
>> >
>> >> 在 2018年6月11日，上午12:27，Ard Biesheuvel
>>  写道：
>> >>
>> >>> On 10 June 2018 at 21:21, Yao, Jiewen  wrote:
>> >>> Just got some idea since I am also reviewing FmpDevicePkg patch.
>> >>>
>> >>>
>> >>> The key problem we are trying to resolve that is: The core code uses
>> EndOfDxe as the lock event for system firmware, but an ARM platform may want
>> to lock system firmware later, maybe in other lock event.
>> >>>
>> >>> As such, how about we generalize the lock event as
>> PcdSystemFmpLockEventGuid? We can use EndOfDxeGuid as default one to keep
>> the compatibility. At same time this brings the flexibility for platform 
>> overriding.
>> >>>
>> >>>
>> >>> We only need update DxeCapsuleLibConstructor() to use the new PcdGuid,
>> instead of hardcode EndOfDxe.
>> >>> We don't need update the logic in ProcessCapsules() and
>> ProcessTheseCapsules().
>> >>> The policy in current platform is already enforced, if the platform has a
>> trusted console.
>> >>> For ARM platform, which wants to lock system firmware later. It can
>> configure another lock event GUID explicitly in platform DSC.
>> >>>
>> >>
>> >> But that means we are still required to call ProcessCapsules () twice, no?
>> >>
>>  -Original Message-
>>  From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Yao,
>>  Jiewen
>>  Sent: Sunday, June 10, 2018 12:02 PM
>>  To: Kinney, Michael D ; Ard Biesheuvel
>>  
>>  Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Zeng, Star
>>  
>>  Subject: Re: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp:
>> permit
>>  ProcessCapsules () to be called once
>> 
>>  My concern is that *always allowing* processing SystemCapsule after
>> EndOfDxe
>>  has security risk.
>> 
>>  IMHO, the risk is not *process*, if it is a platform choice. Instead, 
>>  the risk is
>>  *allow*, in the core logic.
>> 
>>  If we really want to do that, I hope we need a way to distinguish the
>> difference
>>  between a platform dispatching SystemCapsule after EndOfDxe
>> *purposely* and
>>  a platform dispatching SystemCapsule after EndOfDxe *by mistake*.
>> 
>>  Maybe some policy enforcement in the core logic. Static policy, at build
>> time.
>> 
>>  Thank you
>>  Yao Jiewen
>> 
>> > -Original Message-
>> > From: Kinney, Michael D
>> > Sent: Sunday, June 10, 2018 8:57 AM
>> > To: Ard Biesheuvel ; Yao, Jiewen
>> > ; Kinney, Michael D
>> 
>> > Cc: edk2-devel@lists.01.org; Zeng, Star ;
>> > leif.lindh...@linaro.org
>> > Subject: RE: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp:
>> permit
>> > ProcessCapsules () to be called once
>> >
>> > Ard,
>> >
>> > I agree it should be a platform choice to process capsules
>> > before or after End of DXE.  It is even allowed in the
>> > UEFI Spec for capsules to be processed immediately
>> > which would include at OS runtime after ExitBootServices.
>> >
>> > There are 2 inputs to these choices:
>> > * The flags set in the Capsule itself.  See UEFI 2.7 Spec
>> >  Table 38 for the 5 allowed combinations.
>> > * Platform policy for each of these 5 capsule types and
>> >  when each 

Re: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit ProcessCapsules () to be called once

[Yao, Jiewen]

Ah. Good point.

I think the embedded driver dispatch can be controlled by EndOfDxe, which is 
similar to MdeModulePkg\Universal\SecurityStubDxe.

So we can have both EndOfDxe and PcdSystemFmpLockEventGuid.
EndOfDxe controls embedded driver dispatch.
PcdSystemFmpLockEventGuid controls 1st call and 2nd call.

Thank you
Yao Jiewen


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
> Biesheuvel
> Sent: Monday, June 11, 2018 5:40 AM
> To: Yao, Jiewen 
> Cc: Kinney, Michael D ; edk2-devel@lists.01.org;
> Zeng, Star ; leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit
> ProcessCapsules () to be called once
> 
> On 11 June 2018 at 14:37, Yao, Jiewen  wrote:
> > If all fmp can be processed one time，you just need call once. Then system
> reset.
> >
> 
> I understand that. But if the capsule has embedded drivers, the
> library will only dispatch them on the second call, even if the
> platform does not require making that distinction. It seems to me that
> the phasing between the first and the second call is closely tied to
> the semantics of EndOfDxe and the associated policy on X86 not to
> allow third party code before it has been signalled.
> 
> Could we not parameterize this in some way as well?
> 
> 
> >
> >> 在 2018年6月11日，上午12:27，Ard Biesheuvel
>  写道：
> >>
> >>> On 10 June 2018 at 21:21, Yao, Jiewen  wrote:
> >>> Just got some idea since I am also reviewing FmpDevicePkg patch.
> >>>
> >>>
> >>> The key problem we are trying to resolve that is: The core code uses
> EndOfDxe as the lock event for system firmware, but an ARM platform may want
> to lock system firmware later, maybe in other lock event.
> >>>
> >>> As such, how about we generalize the lock event as
> PcdSystemFmpLockEventGuid? We can use EndOfDxeGuid as default one to keep
> the compatibility. At same time this brings the flexibility for platform 
> overriding.
> >>>
> >>>
> >>> We only need update DxeCapsuleLibConstructor() to use the new PcdGuid,
> instead of hardcode EndOfDxe.
> >>> We don't need update the logic in ProcessCapsules() and
> ProcessTheseCapsules().
> >>> The policy in current platform is already enforced, if the platform has a
> trusted console.
> >>> For ARM platform, which wants to lock system firmware later. It can
> configure another lock event GUID explicitly in platform DSC.
> >>>
> >>
> >> But that means we are still required to call ProcessCapsules () twice, no?
> >>
>  -Original Message-
>  From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yao,
>  Jiewen
>  Sent: Sunday, June 10, 2018 12:02 PM
>  To: Kinney, Michael D ; Ard Biesheuvel
>  
>  Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Zeng, Star
>  
>  Subject: Re: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp:
> permit
>  ProcessCapsules () to be called once
> 
>  My concern is that *always allowing* processing SystemCapsule after
> EndOfDxe
>  has security risk.
> 
>  IMHO, the risk is not *process*, if it is a platform choice. Instead, 
>  the risk is
>  *allow*, in the core logic.
> 
>  If we really want to do that, I hope we need a way to distinguish the
> difference
>  between a platform dispatching SystemCapsule after EndOfDxe
> *purposely* and
>  a platform dispatching SystemCapsule after EndOfDxe *by mistake*.
> 
>  Maybe some policy enforcement in the core logic. Static policy, at build
> time.
> 
>  Thank you
>  Yao Jiewen
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Sunday, June 10, 2018 8:57 AM
> > To: Ard Biesheuvel ; Yao, Jiewen
> > ; Kinney, Michael D
> 
> > Cc: edk2-devel@lists.01.org; Zeng, Star ;
> > leif.lindh...@linaro.org
> > Subject: RE: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp:
> permit
> > ProcessCapsules () to be called once
> >
> > Ard,
> >
> > I agree it should be a platform choice to process capsules
> > before or after End of DXE.  It is even allowed in the
> > UEFI Spec for capsules to be processed immediately
> > which would include at OS runtime after ExitBootServices.
> >
> > There are 2 inputs to these choices:
> > * The flags set in the Capsule itself.  See UEFI 2.7 Spec
> >  Table 38 for the 5 allowed combinations.
> > * Platform policy for each of these 5 capsule types and
> >  when each of these 5 capsule types are allowed to be
> >  processed.
> >
> > Jiewen's comments point to some assumptions that have been
> > made in the logic.  These assumptions may be considered a
> > safe default platform policy, but the code logic should
> > allow the platform to easily select alternate policies.
> >
> > I think the patch you have provided attempts to add one
> > additional policy.  Perhaps we should look at this from
> > 

Re: [edk2] [PATCH 1/4] OvmfPkg: add QEMU_RAMFB_GUID

[Laszlo Ersek]

Hi Gerd,

On 06/08/18 13:39, Gerd Hoffmann wrote:
> Add GUID header file for the QemuRamfbDxe driver.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/Include/Guid/QemuRamfb.h | 25 +
>  OvmfPkg/OvmfPkg.dec  |  1 +
>  2 files changed, 26 insertions(+)
>  create mode 100644 OvmfPkg/Include/Guid/QemuRamfb.h
> 
> diff --git a/OvmfPkg/Include/Guid/QemuRamfb.h 
> b/OvmfPkg/Include/Guid/QemuRamfb.h
> new file mode 100644
> index 00..878224599d
> --- /dev/null
> +++ b/OvmfPkg/Include/Guid/QemuRamfb.h
> @@ -0,0 +1,25 @@
> +/** @file
> +  Recommended GUID to be used in the Vendor Hardware device path nodes that
> +  identify qemu ramfb devices.
> +
> +  Copyright (C) 2018, Red Hat, Inc.
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License that accompanies this
> +  distribution. The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __QEMU_RAMFB_H__
> +#define __QEMU_RAMFB_H__
> +
> +#define QEMU_RAMFB_GUID \
> +{0x837dca9e, 0xe874, 0x4d82, {0xb2, 0x9a, 0x23, 0xfe, 0x0e, 0x23, 0xd1, 
> 0xe2}}
> +
> +extern EFI_GUID gQemuRamfbGuid;
> +
> +#endif
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index dc5597db41..a16c22a289 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -75,6 +75,7 @@
>gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 
> 0x12, 0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
>gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 
> 0xac, 0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
>gVirtioMmioTransportGuid= {0x837dca9e, 0xe874, 0x4d82, {0xb2, 
> 0x9a, 0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
> +  gQemuRamfbGuid  = {0x837dca9e, 0xe874, 0x4d82, {0xb2, 
> 0x9a, 0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
>gXenBusRootDeviceGuid   = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 
> 0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
>gRootBridgesConnectedEventGroupGuid = {0x24a2d66f, 0xeedd, 0x4086, {0x90, 
> 0x42, 0xf2, 0x6e, 0x47, 0x97, 0xee, 0x69}}
>  
> 

this patch is all good, formally speaking, but you should please
generate a new GUID with "uuidgen", rather than using the one from
"VirtioMmioTransport.h" :)

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

Re: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit ProcessCapsules () to be called once

[Ard Biesheuvel]

On 11 June 2018 at 14:37, Yao, Jiewen  wrote:
> If all fmp can be processed one time，you just need call once. Then system 
> reset.
>

I understand that. But if the capsule has embedded drivers, the
library will only dispatch them on the second call, even if the
platform does not require making that distinction. It seems to me that
the phasing between the first and the second call is closely tied to
the semantics of EndOfDxe and the associated policy on X86 not to
allow third party code before it has been signalled.

Could we not parameterize this in some way as well?


>
>> 在 2018年6月11日，上午12:27，Ard Biesheuvel  写道：
>>
>>> On 10 June 2018 at 21:21, Yao, Jiewen  wrote:
>>> Just got some idea since I am also reviewing FmpDevicePkg patch.
>>>
>>>
>>> The key problem we are trying to resolve that is: The core code uses 
>>> EndOfDxe as the lock event for system firmware, but an ARM platform may 
>>> want to lock system firmware later, maybe in other lock event.
>>>
>>> As such, how about we generalize the lock event as 
>>> PcdSystemFmpLockEventGuid? We can use EndOfDxeGuid as default one to keep 
>>> the compatibility. At same time this brings the flexibility for platform 
>>> overriding.
>>>
>>>
>>> We only need update DxeCapsuleLibConstructor() to use the new PcdGuid, 
>>> instead of hardcode EndOfDxe.
>>> We don't need update the logic in ProcessCapsules() and 
>>> ProcessTheseCapsules().
>>> The policy in current platform is already enforced, if the platform has a 
>>> trusted console.
>>> For ARM platform, which wants to lock system firmware later. It can 
>>> configure another lock event GUID explicitly in platform DSC.
>>>
>>
>> But that means we are still required to call ProcessCapsules () twice, no?
>>
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao,
 Jiewen
 Sent: Sunday, June 10, 2018 12:02 PM
 To: Kinney, Michael D ; Ard Biesheuvel
 
 Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Zeng, Star
 
 Subject: Re: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit
 ProcessCapsules () to be called once

 My concern is that *always allowing* processing SystemCapsule after 
 EndOfDxe
 has security risk.

 IMHO, the risk is not *process*, if it is a platform choice. Instead, the 
 risk is
 *allow*, in the core logic.

 If we really want to do that, I hope we need a way to distinguish the 
 difference
 between a platform dispatching SystemCapsule after EndOfDxe *purposely* and
 a platform dispatching SystemCapsule after EndOfDxe *by mistake*.

 Maybe some policy enforcement in the core logic. Static policy, at build 
 time.

 Thank you
 Yao Jiewen

> -Original Message-
> From: Kinney, Michael D
> Sent: Sunday, June 10, 2018 8:57 AM
> To: Ard Biesheuvel ; Yao, Jiewen
> ; Kinney, Michael D 
> Cc: edk2-devel@lists.01.org; Zeng, Star ;
> leif.lindh...@linaro.org
> Subject: RE: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit
> ProcessCapsules () to be called once
>
> Ard,
>
> I agree it should be a platform choice to process capsules
> before or after End of DXE.  It is even allowed in the
> UEFI Spec for capsules to be processed immediately
> which would include at OS runtime after ExitBootServices.
>
> There are 2 inputs to these choices:
> * The flags set in the Capsule itself.  See UEFI 2.7 Spec
>  Table 38 for the 5 allowed combinations.
> * Platform policy for each of these 5 capsule types and
>  when each of these 5 capsule types are allowed to be
>  processed.
>
> Jiewen's comments point to some assumptions that have been
> made in the logic.  These assumptions may be considered a
> safe default platform policy, but the code logic should
> allow the platform to easily select alternate policies.
>
> I think the patch you have provided attempts to add one
> additional policy.  Perhaps we should look at this from
> the UEFI Spec perspective and see how difficult it is to
> express policies for the supported capsule types.
>
> I will review your patch in more detail tomorrow.
>
> Thanks,
>
> Mike
>
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Saturday, June 9, 2018 10:42 PM
>> To: Yao, Jiewen 
>> Cc: edk2-devel@lists.01.org; Kinney, Michael D
>> ; Zeng, Star
>> ; leif.lindh...@linaro.org
>> Subject: Re: [edk2] [PATCH v2 2/5]
>> MdeModulePkg/DxeCapsuleLibFmp: permit ProcessCapsules
>> () to be called once
>>
>> On 10 June 2018 at 07:38, Yao, Jiewen
>>  wrote:
>>> Hi Ard
>>> According to PI spec, "Prior to invoking any UEFI
>> drivers, or applications that are not from the platform
>> manufacturer, or connecting consoles, the 

Re: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit ProcessCapsules () to be called once

[Yao, Jiewen]

If all fmp can be processed one time，you just need call once. Then system reset.

thank you!
Yao, Jiewen


> 在 2018年6月11日，上午12:27，Ard Biesheuvel  写道：
> 
>> On 10 June 2018 at 21:21, Yao, Jiewen  wrote:
>> Just got some idea since I am also reviewing FmpDevicePkg patch.
>> 
>> 
>> The key problem we are trying to resolve that is: The core code uses 
>> EndOfDxe as the lock event for system firmware, but an ARM platform may want 
>> to lock system firmware later, maybe in other lock event.
>> 
>> As such, how about we generalize the lock event as 
>> PcdSystemFmpLockEventGuid? We can use EndOfDxeGuid as default one to keep 
>> the compatibility. At same time this brings the flexibility for platform 
>> overriding.
>> 
>> 
>> We only need update DxeCapsuleLibConstructor() to use the new PcdGuid, 
>> instead of hardcode EndOfDxe.
>> We don't need update the logic in ProcessCapsules() and 
>> ProcessTheseCapsules().
>> The policy in current platform is already enforced, if the platform has a 
>> trusted console.
>> For ARM platform, which wants to lock system firmware later. It can 
>> configure another lock event GUID explicitly in platform DSC.
>> 
> 
> But that means we are still required to call ProcessCapsules () twice, no?
> 
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao,
>>> Jiewen
>>> Sent: Sunday, June 10, 2018 12:02 PM
>>> To: Kinney, Michael D ; Ard Biesheuvel
>>> 
>>> Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Zeng, Star
>>> 
>>> Subject: Re: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit
>>> ProcessCapsules () to be called once
>>> 
>>> My concern is that *always allowing* processing SystemCapsule after EndOfDxe
>>> has security risk.
>>> 
>>> IMHO, the risk is not *process*, if it is a platform choice. Instead, the 
>>> risk is
>>> *allow*, in the core logic.
>>> 
>>> If we really want to do that, I hope we need a way to distinguish the 
>>> difference
>>> between a platform dispatching SystemCapsule after EndOfDxe *purposely* and
>>> a platform dispatching SystemCapsule after EndOfDxe *by mistake*.
>>> 
>>> Maybe some policy enforcement in the core logic. Static policy, at build 
>>> time.
>>> 
>>> Thank you
>>> Yao Jiewen
>>> 
 -Original Message-
 From: Kinney, Michael D
 Sent: Sunday, June 10, 2018 8:57 AM
 To: Ard Biesheuvel ; Yao, Jiewen
 ; Kinney, Michael D 
 Cc: edk2-devel@lists.01.org; Zeng, Star ;
 leif.lindh...@linaro.org
 Subject: RE: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit
 ProcessCapsules () to be called once
 
 Ard,
 
 I agree it should be a platform choice to process capsules
 before or after End of DXE.  It is even allowed in the
 UEFI Spec for capsules to be processed immediately
 which would include at OS runtime after ExitBootServices.
 
 There are 2 inputs to these choices:
 * The flags set in the Capsule itself.  See UEFI 2.7 Spec
  Table 38 for the 5 allowed combinations.
 * Platform policy for each of these 5 capsule types and
  when each of these 5 capsule types are allowed to be
  processed.
 
 Jiewen's comments point to some assumptions that have been
 made in the logic.  These assumptions may be considered a
 safe default platform policy, but the code logic should
 allow the platform to easily select alternate policies.
 
 I think the patch you have provided attempts to add one
 additional policy.  Perhaps we should look at this from
 the UEFI Spec perspective and see how difficult it is to
 express policies for the supported capsule types.
 
 I will review your patch in more detail tomorrow.
 
 Thanks,
 
 Mike
 
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Saturday, June 9, 2018 10:42 PM
> To: Yao, Jiewen 
> Cc: edk2-devel@lists.01.org; Kinney, Michael D
> ; Zeng, Star
> ; leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH v2 2/5]
> MdeModulePkg/DxeCapsuleLibFmp: permit ProcessCapsules
> () to be called once
> 
> On 10 June 2018 at 07:38, Yao, Jiewen
>  wrote:
>> Hi Ard
>> According to PI spec, "Prior to invoking any UEFI
> drivers, or applications that are not from the platform
> manufacturer, or connecting consoles, the platform
> should signals the event EFI_END_OF_DXE_EVENT_GUID"
>> 
>> In brief, EndOfDxe is signaled before 3rd part code
> running.
>> 
>> As such, it is legal that a trusted console is
> connected before EndOfDxe.
>> You can report progress to user before EndOfDxe.
>> 
> 
> So how do I connect a trusted console on a system with
> a plugin graphics card?
> How can I report capsule update progress on such a
> system?
> On a system such as ARM where the actual flash update
> involves calls
> 

Re: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode

[Laszlo Ersek]

Hi Jian,

On 06/11/18 09:08, Jian J Wang wrote:
> The SMM version of MemoryAllocationLib allows to free memory allocated
> in DXE (before EndOfDxe). This is done by checking the memory range and
> calling gBS services to do real operation if the memory to free is out
> of SMRAM. This would cause problem if some memory related features, like
> Heap Guard, have to update page table to change memory attributes.
> Because page table in SMM mode is different from DXE mode, gBS memory
> services cannot get the correct attributes of DXE memory from SMM page
> table and then cause incorrect memory manipulations.

(1) I think this description makes sense, but it does not highlight the
involvement of CpuDxe.

(1a) Please reference "MdePkg/Library/SmmMemoryAllocationLib" specifically.

(1b) The SmmMemoryAllocationLib instance implies that the call chain
starts with a DXE_SMM_DRIVER calling FreePool() or FreePages().

DXE_SMM_DRIVERs can only call boot services, and protocols located with
boot services, in their entry point functions.

CpuDxe is a DXE_DRIVER and it provides the CPU arch protocol (and the MP
services protocol). Thus, our call chain can only occur if:

- a DXE_SMM_DRIVER calls the FreePool() or FreePages() library API,

- in its entry point function,

- releasing memory that's not SMRAM,

- and the heap guard feature is enabled, so the FreePool() or
  FreePages() boot service ends up calling
  EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes().

Please include this information in the commit message.

(2) Can you remind me how the SMM page tables map non-SMRAM memory?

Because, I assume that, after a FreePages() libary API call, the freed
memory should not be accessible to either SMM code or normal DXE code.
This seems to imply that both sets of page tables should be modified.
What am I missing?

> 
> The solution in this patch is to store the DXE page table information
> (e.g. value of CR0, CR3 registers, etc.) in a global variable of CpuDxe
> driver. If CpuDxe detects it's in SMM mode, it will use this global
> variable to access page table instead of current processor registers.
> 
> Change-Id: If810bb1828160b8bdd8cb616d86df2859c74971f

(3) I think this comes from Gerrit. Do you really need the "Change-Id"
tag in the commit message? It doesn't say anything to the upstream edk2
users.

If you really need it, I don't mind it though; just please let's not add
it due to oversight.

(4) Please make sure that you don't *push* the patch with Gerrit. Gerrit
does bad things to git metadata. Please see
<4A89E2EF3DFEDB4C8BFDE51014F606A14E22344D@SHSMSX104.ccr.corp.intel.com">http://mid.mail-archive.com/4A89E2EF3DFEDB4C8BFDE51014F606A14E22344D@SHSMSX104.ccr.corp.intel.com>.

> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Cc: Jiewen Yao 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/CpuDxe/CpuDxe.c   |   2 +-
>  UefiCpuPkg/CpuDxe/CpuDxe.inf |   1 +
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 108 
> ++-
>  3 files changed, 75 insertions(+), 36 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c
> index 6ae2dcd1c7..1fd996fc3f 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.c
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
> @@ -404,7 +404,7 @@ CpuSetMemoryAttributes (
>// to avoid unnecessary computing.
>//
>if (mIsFlushingGCD) {
> -DEBUG((DEBUG_INFO, "  Flushing GCD\n"));
> +DEBUG((DEBUG_GCD, "  Flushing GCD\n"));
>  return EFI_SUCCESS;
>}

(5) I think it would be cleaner if we fixed the debug level for this
message in a separate patch. You are not touching "CpuDxe.c" for any
other reason.

>  
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.inf b/UefiCpuPkg/CpuDxe/CpuDxe.inf
> index 3c938cee53..8c8773af90 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.inf
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.inf
> @@ -66,6 +66,7 @@
>  [Protocols]
>gEfiCpuArchProtocolGuid   ## PRODUCES
>gEfiMpServiceProtocolGuid ## PRODUCES
> +  gEfiSmmBase2ProtocolGuid

(6) protocol usage note is missing (should be "## SOMETIMES_CONSUMES" I
think.)

>  
>  [Guids]
>gIdleLoopEventGuid## CONSUMES   ## 
> Event
> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c 
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> index e2595b4d89..bf420d3792 100644
> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "CpuDxe.h"
>  #include "CpuPageTable.h"
> @@ -87,7 +88,33 @@ PAGE_ATTRIBUTE_TABLE mPageAttributeTable[] = {
>{Page1G,  SIZE_1GB, PAGING_1G_ADDRESS_MASK_64},
>  };
>  
> -PAGE_TABLE_POOL   *mPageTablePool = NULL;
> +PAGE_TABLE_POOL   *mPageTablePool = NULL;
> +PAGE_TABLE_LIB_PAGING_CONTEXT mPagingContext;
> +EFI_SMM_BASE2_PROTOCOL*mSmmBase2 = NULL;
> +
> +BOOLEAN
> +IsInSmm (
> +  VOID
> +  )
> +{
> +  EFI_STATUS 

Re: [edk2] [platforms PATCH 00/25] Armada herdware description rework

[Marcin Wojtas]

Hi Ard,

2018-06-11 14:01 GMT+02:00 Ard Biesheuvel :
> On 11 June 2018 at 13:49, Marcin Wojtas  wrote:
>> Hi Ard,
>>
>> 2018-06-11 13:00 GMT+02:00 Ard Biesheuvel :
>>> Marcin,
>>>
>>> I am a bit reluctant to review another huge set of Armada patches
>>> while we are still waiting for MacchiatoBin support to land. The only
>>> hardware i have access to is MacchiatoBin, and it has been well over a
>>> year now that MacchiatoBin support has been between 'under
>>> construction' and 'about to land any day now'.
>>>
>>> The patches in this series actually carry traces of McBin support,
>>> which suggests to me that they were taken from an internal tree that
>>> does support MacchiatoBin, but it has been removed. What is that
>>> about?
>>
>> MacchiatoBin addition is on top of those patches in the branch I
>> prepared solely for upstream. Anyway, I understand your point and
>> let's skip this big patchset for now. I will submit support for other
>> boards, once it's accepted, let's return to this one.
>>
>
>
> Patch 5/25:
>
> """
> From: jinghua 
>
> This patch enables compilation of MvBoardDescDxe driver for
> Armada70x0-DB, Armada80x0-DB and Armada80x0McBin.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: jinghua 
> Reviewed-by: Kostya Porotchkin 
> """
>
> So this patch clearly contained MacchiatoBin support at some point,
> but you removed it before upstreaming the patch. That really makes me
> sad.

Yes, I inverted the order of the patches when cleaning the branch. I
wanted to add the whole new boards support in a minimal possible way,
but that clearly wasn't best idea. Nvm, I'll submit new board now.

>
> BTW can you please drop the @marvell.com Reviewed-by tags, and add
> your own Signed-off-by to patches that you did not author yourself?

Sure will do.

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

Re: [edk2] [platforms PATCH 00/25] Armada herdware description rework

[Ard Biesheuvel]

On 11 June 2018 at 13:49, Marcin Wojtas  wrote:
> Hi Ard,
>
> 2018-06-11 13:00 GMT+02:00 Ard Biesheuvel :
>> Marcin,
>>
>> I am a bit reluctant to review another huge set of Armada patches
>> while we are still waiting for MacchiatoBin support to land. The only
>> hardware i have access to is MacchiatoBin, and it has been well over a
>> year now that MacchiatoBin support has been between 'under
>> construction' and 'about to land any day now'.
>>
>> The patches in this series actually carry traces of McBin support,
>> which suggests to me that they were taken from an internal tree that
>> does support MacchiatoBin, but it has been removed. What is that
>> about?
>
> MacchiatoBin addition is on top of those patches in the branch I
> prepared solely for upstream. Anyway, I understand your point and
> let's skip this big patchset for now. I will submit support for other
> boards, once it's accepted, let's return to this one.
>


Patch 5/25:

"""
From: jinghua 

This patch enables compilation of MvBoardDescDxe driver for
Armada70x0-DB, Armada80x0-DB and Armada80x0McBin.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: jinghua 
Reviewed-by: Kostya Porotchkin 
"""

So this patch clearly contained MacchiatoBin support at some point,
but you removed it before upstreaming the patch. That really makes me
sad.

BTW can you please drop the @marvell.com Reviewed-by tags, and add
your own Signed-off-by to patches that you did not author yourself?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms PATCH 00/25] Armada herdware description rework

[Marcin Wojtas]

Hi Ard,

2018-06-11 13:00 GMT+02:00 Ard Biesheuvel :
> Marcin,
>
> I am a bit reluctant to review another huge set of Armada patches
> while we are still waiting for MacchiatoBin support to land. The only
> hardware i have access to is MacchiatoBin, and it has been well over a
> year now that MacchiatoBin support has been between 'under
> construction' and 'about to land any day now'.
>
> The patches in this series actually carry traces of McBin support,
> which suggests to me that they were taken from an internal tree that
> does support MacchiatoBin, but it has been removed. What is that
> about?

MacchiatoBin addition is on top of those patches in the branch I
prepared solely for upstream. Anyway, I understand your point and
let's skip this big patchset for now. I will submit support for other
boards, once it's accepted, let's return to this one.

Best regards,
Marcin

>
> edk2-platforms is not intended as a baseline for Marvell customers to
> base their private trees on, we actually prefer code that runs on
> systems that are widely available (such as MacchiatoBin)
>
> Thanks,
> Ard.
>
>
> On 8 June 2018 at 17:33, Marcin Wojtas  wrote:
>> Hi,
>>
>> This big patchset reworks handling of the SoC and Boards' description
>> to the final version. Hitherto mechanism of hardcoded structures
>> and parsing PCDs inside the drivers was unfortunate - it didn't
>> allow to support different SoC families with different number
>> of controllers or base addresses.
>>
>> The main concept is introducing a hardware description layer
>> with the new protocol, which is responsible for providing
>> data to the consumer platforms drivers. Additionally a new
>> SoC and Board description libraries allow to move information
>> from overly used PCDs to C code in an organized manner:
>>
>> ArmadaSoCDescLib + ArmadaBoardDescLib
>> (per SoC family)   (per Board, in next steps more of description
>>|of ComPhy, Mpp and others can go there)
>>|   |
>>|   |
>>|-> MV_BOARD_DESC <-|
>> |
>> |
>> |
>> Driver/Library (e.g. ComPhy, I2c, Pp2Dxe)
>>
>> Please don't be discouraged by big amount of patches,
>> they are sort of repeatable: update protocol, libraries and
>> the consumer drivers/libraries until the MvHwDescLib.h
>> header could be completely removed. More details can
>> be found in the commit logs.
>>
>> The patches are available in the github:
>> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/boarddesc-upstream-r20180608
>>
>> I'm looking forward to review and any comments/remarks.
>>
>> Best regards,
>> Marcin
>>
>> Marcin Wojtas (21):
>>   Marvell/Library: Introduce ArmadaBoardDescLib class
>>   Marvell/Library: UtmiPhyLib: Switch to use MARVELL_BOARD_DESC protocol
>>   Marvell/Library: RealTimeClockLib: Simplify obtaining base address
>>   Marvell/Armada7k8k: Extend ArmadaSoCDescLib with PP2 information
>>   Marvell/Drivers: MvBoardDesc: Extend protocol with PP2 support
>>   Marvell/Drivers: Pp2Dxe: Switch to use MARVELL_BOARD_DESC protocol
>>   Marvell/Armada7k8k: Extend ArmadaSoCDescLib with AHCI/SDMMC/XHCI
>>   Marvell/Drivers: MvBoardDesc: Extend protocol with AHCI/SDMMC/XHCI
>>   Marvell/Drivers: NonDiscoverable: Switch to use MARVELL_BOARD_DESC
>>   Marvell/Library: ComPhyLib: Get AHCI data with MARVELL_BOARD_DESC
>>   Marvell/Armada7k8k: Extend ArmadaSoCDescLib with ComPhy information
>>   Marvell/Drivers: MvBoardDesc: Extend protocol with COMPHY support
>>   Marvell/Library: ComPhyLib: Switch library to use MARVELL_BOARD_DESC
>>   Marvell/Armada7k8k: Extend ArmadaSoCDescLib with MDIO information
>>   Marvell/Drivers: MvBoardDesc: Extend protocol with MDIO support
>>   Marvell/Drivers: MvMdioDxe: Enable 64bit addressing
>>   Marvell/Drivers: MvMdioDxe: Switch driver to use MARVELL_BOARD_DESC
>>   Marvell/Armada7k8k: Extend ArmadaSoCDescLib with I2C information
>>   Marvell/Drivers: MvBoardDesc: Extend protocol with I2C support
>>   Marvell/Drivers: MvI2cDxe: Switch driver to use MARVELL_BOARD_DESC
>>   Marvell/Drivers: MvPhyDxe: Remove MvHwDescLib.h dependency
>>
>> jinghua (4):
>>   Marvell/Library: Introduce ArmadaSoCDescLib class
>>   Marvell: Introduce MARVELL_BOARD_DESC_PROTOCOL
>>   Marvell/Drivers: MvBoardDescDxe: Introduce board description driver
>>   Marvell/Armada7k8k: Enable board description driver compilation
>>
>>  Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc  
>>  |   2 +-
>>  Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf  
>>  |   1 +
>>  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc   
>>  |   2 +
>>  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.inf  
>>  |   2 -
>>  
>> Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
>>| 338 
>>  
>> 

Re: [edk2] [platforms PATCH 00/25] Armada herdware description rework

[Ard Biesheuvel]

Marcin,

I am a bit reluctant to review another huge set of Armada patches
while we are still waiting for MacchiatoBin support to land. The only
hardware i have access to is MacchiatoBin, and it has been well over a
year now that MacchiatoBin support has been between 'under
construction' and 'about to land any day now'.

The patches in this series actually carry traces of McBin support,
which suggests to me that they were taken from an internal tree that
does support MacchiatoBin, but it has been removed. What is that
about?

edk2-platforms is not intended as a baseline for Marvell customers to
base their private trees on, we actually prefer code that runs on
systems that are widely available (such as MacchiatoBin)

Thanks,
Ard.


On 8 June 2018 at 17:33, Marcin Wojtas  wrote:
> Hi,
>
> This big patchset reworks handling of the SoC and Boards' description
> to the final version. Hitherto mechanism of hardcoded structures
> and parsing PCDs inside the drivers was unfortunate - it didn't
> allow to support different SoC families with different number
> of controllers or base addresses.
>
> The main concept is introducing a hardware description layer
> with the new protocol, which is responsible for providing
> data to the consumer platforms drivers. Additionally a new
> SoC and Board description libraries allow to move information
> from overly used PCDs to C code in an organized manner:
>
> ArmadaSoCDescLib + ArmadaBoardDescLib
> (per SoC family)   (per Board, in next steps more of description
>|of ComPhy, Mpp and others can go there)
>|   |
>|   |
>|-> MV_BOARD_DESC <-|
> |
> |
> |
> Driver/Library (e.g. ComPhy, I2c, Pp2Dxe)
>
> Please don't be discouraged by big amount of patches,
> they are sort of repeatable: update protocol, libraries and
> the consumer drivers/libraries until the MvHwDescLib.h
> header could be completely removed. More details can
> be found in the commit logs.
>
> The patches are available in the github:
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/boarddesc-upstream-r20180608
>
> I'm looking forward to review and any comments/remarks.
>
> Best regards,
> Marcin
>
> Marcin Wojtas (21):
>   Marvell/Library: Introduce ArmadaBoardDescLib class
>   Marvell/Library: UtmiPhyLib: Switch to use MARVELL_BOARD_DESC protocol
>   Marvell/Library: RealTimeClockLib: Simplify obtaining base address
>   Marvell/Armada7k8k: Extend ArmadaSoCDescLib with PP2 information
>   Marvell/Drivers: MvBoardDesc: Extend protocol with PP2 support
>   Marvell/Drivers: Pp2Dxe: Switch to use MARVELL_BOARD_DESC protocol
>   Marvell/Armada7k8k: Extend ArmadaSoCDescLib with AHCI/SDMMC/XHCI
>   Marvell/Drivers: MvBoardDesc: Extend protocol with AHCI/SDMMC/XHCI
>   Marvell/Drivers: NonDiscoverable: Switch to use MARVELL_BOARD_DESC
>   Marvell/Library: ComPhyLib: Get AHCI data with MARVELL_BOARD_DESC
>   Marvell/Armada7k8k: Extend ArmadaSoCDescLib with ComPhy information
>   Marvell/Drivers: MvBoardDesc: Extend protocol with COMPHY support
>   Marvell/Library: ComPhyLib: Switch library to use MARVELL_BOARD_DESC
>   Marvell/Armada7k8k: Extend ArmadaSoCDescLib with MDIO information
>   Marvell/Drivers: MvBoardDesc: Extend protocol with MDIO support
>   Marvell/Drivers: MvMdioDxe: Enable 64bit addressing
>   Marvell/Drivers: MvMdioDxe: Switch driver to use MARVELL_BOARD_DESC
>   Marvell/Armada7k8k: Extend ArmadaSoCDescLib with I2C information
>   Marvell/Drivers: MvBoardDesc: Extend protocol with I2C support
>   Marvell/Drivers: MvI2cDxe: Switch driver to use MARVELL_BOARD_DESC
>   Marvell/Drivers: MvPhyDxe: Remove MvHwDescLib.h dependency
>
> jinghua (4):
>   Marvell/Library: Introduce ArmadaSoCDescLib class
>   Marvell: Introduce MARVELL_BOARD_DESC_PROTOCOL
>   Marvell/Drivers: MvBoardDescDxe: Introduce board description driver
>   Marvell/Armada7k8k: Enable board description driver compilation
>
>  Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc   
> |   2 +-
>  Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf   
> |   1 +
>  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> |   2 +
>  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.inf   
> |   2 -
>  
> Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
>| 338 
>  
> Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.inf
>  |  37 ++
>  Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c   
> |  29 +-
>  Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.inf 
> |   2 +-
>  Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.c   
> | 573 
>  Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h   
> |  

Re: [edk2] [PATCH v3 1/2] MdePkg/BaseIoLibIntrinsic: make BaseIoLibIntrinsic safe for ArmVirt/KVM

[Laszlo Ersek]

On 06/11/18 09:25, Ard Biesheuvel wrote:
> KVM on ARM refuses to decode load/store instructions used to perform
> I/O to emulated devices, and instead relies on the exception syndrome
> information to describe the operand register, access size, etc.
> This is only possible for instructions that have a single input/output
> register (as opposed to ones that increment the offset register, or
> load/store pair instructions, etc). Otherwise, QEMU crashes with the
> following error
> 
>   error: kvm run failed Function not implemented
>   R00=01010101 R01=0008 R02=0048 R03=08000820
>   R04=0120 R05=7faaa0e0 R06=7faaa0dc R07=7faaa0e8
>   R08=7faaa0ec R09=7faaa088 R10=00ff R11=0080
>   R12=ff00 R13=7fccfe08 R14=7faa835f R15=7faa887c
>   PSR=81f3 N--- T svc32
>   QEMU: Terminated
> 
> and KVM produces a warning such as the following in the kernel log
> 
>   kvm [17646]: load/store instruction decoding not implemented
> 
> The IoLib implementation provided by MdePkg/Library/BaseIoLibIntrinsic
> is based on C code, and when LTO is in effect, the MMIO accesses could
> be merged with, e.g., manipulations of the loop counter, producing
> opcodes that KVM does not support for emulated MMIO.
> 
> So let's add a special ArmVirt flavor of this library that implements
> that actual load/store operations in assembler, ensuring that the
> instructions involved can be emulated by KVM.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> v3: add missing prototype comments in IoLibArmVirt.c
> remove mention of ASSERT () from description of internal asm routines
> v2: add missing .uni file
> split off ArmVirtPkg change
> add VS2017 version of AArch64 asm file
> add reference to MdePkg.dsc
> 
>  MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S | 148 
>  MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.asm   | 149 
>  MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.S | 145 
>  MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.asm   | 149 
>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.inf |  52 ++
>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.uni |  23 +
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibArmVirt.c| 733 
> 
>  MdePkg/MdePkg.dsc   |   1 +
>  8 files changed, 1400 insertions(+)

Acked-by: Laszlo Ersek 

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

Re: [edk2] [PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq Support

[Udit Kumar]

Thanks for review Ard. 

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, June 11, 2018 3:35 PM
> To: Udit Kumar 
> Cc: Leif Lindholm ; edk2-devel@lists.01.org
> Subject: Re: [PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq
> Support
> 
> Hello Udit,
> 
> Apologies for not bringing this up the first time, but I have some additional
> comments. The first time around, I only had a cursory look because at that
> point I was still skeptical whether we needed this library in the first place.

I hope, now you agree to have this lib 

> On 5 June 2018 at 19:59, Udit Kumar  wrote:
> > Some platform support dynamic clocking, Which is controlled by some
> > jumper setting or hardware registers.
> > Result of that PCD PL011UartClkInHz needs to be updated for frequency
> > change.
> > This patch implements support for dynamic frequency for
> > PL011 uart.
> > This patch implements default lib, which is using Pcd.
> > Platform which needs dynamic clocking needs implement
> > PL011UartClockLib
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Udit Kumar 
> > ---
> >  ArmPlatformPkg/ArmPlatformPkg.dec  |  1 +
> >  ArmPlatformPkg/Include/Library/PL011UartClockLib.h | 32
> > +++
> .../Library/PL011UartClockLib/PL011UartClockLib.c  | 29
> +
> >  .../PL011UartClockLib/PL011UartClockLib.inf| 37
> ++
> 
> Please add a reference to the new library in the [Components] section of
> ArmPlatformPkg.dsc as well, so we can build it standalone.

Ok 
 
> >  4 files changed, 99 insertions(+)
> >  create mode 100644
> ArmPlatformPkg/Include/Library/PL011UartClockLib.h
> >  create mode 100644
> > ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
> >  create mode 100644
> > ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
> >
> > diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec
> > b/ArmPlatformPkg/ArmPlatformPkg.dec
> > index dff4598..5f67e74 100644
> > --- a/ArmPlatformPkg/ArmPlatformPkg.dec
> > +++ b/ArmPlatformPkg/ArmPlatformPkg.dec
> > @@ -36,6 +36,7 @@
> >LcdHwLib|Include/Library/LcdHwLib.h
> >LcdPlatformLib|Include/Library/LcdPlatformLib.h
> >NorFlashPlatformLib|Include/Library/NorFlashPlatformLib.h
> > +  PL011UartClockLib|Include/Library/PL011UartClockLib.h
> >PL011UartLib|Include/Library/PL011UartLib.h
> >
> >  [Guids.common]
> > diff --git a/ArmPlatformPkg/Include/Library/PL011UartClockLib.h
> > b/ArmPlatformPkg/Include/Library/PL011UartClockLib.h
> > new file mode 100644
> > index 000..93813a0
> > --- /dev/null
> > +++ b/ArmPlatformPkg/Include/Library/PL011UartClockLib.h
> > @@ -0,0 +1,32 @@
> > +/** @file
> > +*
> > +*  Copyright 2018 NXP
> > +*
> > +*  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
> > +*
> >
> +https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fo
> pe
> > +nsource.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40
> >
> +nxp.com%7C2ac27eb60055478ac37d08d5cf82d550%7C686ea1d3bc2b4c
> 6fa92cd99c
> >
> +5c301635%7C0%7C0%7C636643083195138179=C%2F2MhK2ZA6
> XPmC5c8byWlK3
> > +xAC6rFmLYofPKlj6M7%2FI%3D=0
> > +*
> > +*  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 __PL011CLOCKLIB_H__
> > +#define __PL011CLOCKLIB_H__
> 
> Nit: use __PL011UARTCLOCKLIB_H__ to match the filename.

My miss, thanks  will do in v3
 
> > +
> > +
> > +/**
> > +  Return frequency of PL011.
> > +
> 
> Mention the baud clock?

Sure 
> > +  By default this function returns FixedPcdGet32 (PL011UartClkInHz)
> > +
> 
> Drop this line please, it is not part of the prototype

Ok 
 
> > +  @return Return frequency of PL011
> > +
> > +**/
> > +UINT32
> > +ArmPlatformGetPL011ClockFreq (
> 
> The ArmPlatform prefix is unnecessary here: please use
> PL011UartClockGetFreq() instead.

Ok 
 
> > +  VOID
> > +  );
> > +
> > +#endif
> > diff --git
> > a/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
> > b/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
> > new file mode 100644
> > index 000..b56af14
> > --- /dev/null
> > +++ b/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
> > @@ -0,0 +1,29 @@
> > +/** @file
> > +*
> > +*  Copyright 2018 NXP
> > +*
> > +*  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
> > +*
> >
> +https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fo
> pe
> > +nsource.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40
> >

Re: [edk2] [PATCH 2/2] ArmPlatformPkg: Include PL011UartClock Lib

[Udit Kumar]

Thanks Ard 

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, June 11, 2018 3:37 PM
> To: Udit Kumar 
> Cc: Leif Lindholm ; edk2-devel@lists.01.org
> Subject: Re: [PATCH 2/2] ArmPlatformPkg: Include PL011UartClock Lib
> 
> On 5 June 2018 at 19:59, Udit Kumar  wrote:
> > This patch includes, PL011UartClock lib.
> >
> > In case of no implemenation of this Clock Lib, Pcd value will be used
> > for PL011 frequency.
> >
> 
> Please improve the commit log. You are modifying the code to obtain the
> PL011 baud clock frequency from a library instead of a PCD

Ok 
 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Udit Kumar 
> > ---
> >  ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c   | 5
> +++--
> >  ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf | 1
> > +
> >  2 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git
> > a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> > b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> > index 6aa8063..c73e8db 100644
> > --- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> > +++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> > @@ -19,6 +19,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >
> > @@ -48,7 +49,7 @@ SerialPortInitialize (
> >
> >return PL011UartInitializePort (
> > (UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> > -   FixedPcdGet32 (PL011UartClkInHz),
> > +   ArmPlatformGetPL011ClockFreq(),
> > ,
> > ,
> > ,
> > @@ -156,7 +157,7 @@ SerialPortSetAttributes (  {
> >return PL011UartInitializePort (
> > (UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> > -   FixedPcdGet32 (PL011UartClkInHz),
> > +   ArmPlatformGetPL011ClockFreq(),
> > BaudRate,
> > ReceiveFifoDepth,
> > Parity,
> > diff --git
> > a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> > b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> > index 3683e06..5ce5b2f 100644
> > --- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> > +++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> > @@ -26,6 +26,7 @@
> >PL011SerialPortLib.c
> >
> >  [LibraryClasses]
> > +  PL011UartClockLib
> >PL011UartLib
> >PcdLib
> >
> 
> You need to add a library resolution to
> ArmPlatformPkg/ArmPlatformPkg.dsc for this library or you will break the
> build.

I will do this, 

FYI,
With update in edk2-platform, my compile was ok for Juno and NXP boards 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Platform: Add PL011UartClock Lib

[Ard Biesheuvel]

On 5 June 2018 at 20:00, Udit Kumar  wrote:
> [v2]
>   Updated name of clock lib
>

Please add a commit log

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Meenakshi Aggarwal 
> ---
>  Platform/AMD/OverdriveBoard/OverdriveBoard.dsc   | 1 +
>  Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 1 +
>  Platform/Hisilicon/D05/D05.dsc   | 2 ++
>  Platform/Hisilicon/HiKey/HiKey.dsc   | 1 +
>  Platform/Hisilicon/HiKey960/HiKey960.dsc | 1 +

Please change Silicon/Hisilicon/Hisilicon.dsc.inc instead of all three
files above.

>  Platform/LeMaker/CelloBoard/CelloBoard.dsc   | 1 +
>  Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 1 +
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 1 +
>  Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc  | 1 +
>  9 files changed, 10 insertions(+)
>
> diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
> b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
> index 5e564f6..8dc58a6 100644
> --- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
> +++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
> @@ -106,6 +106,7 @@ DEFINE DO_CAPSULE   = FALSE
>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>
># ARM PL011 UART Driver
> +  
> PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
>PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
>
> SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
>
> diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
> b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
> index 8a43d31..3a7dad4 100644
> --- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
> +++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
> @@ -87,6 +87,7 @@
>
> RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
>TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
># ARM PL011 UART Driver
> +  
> PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
>PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
>
> SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
> diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
> index b6e1a9d..8396550 100644
> --- a/Platform/Hisilicon/D05/D05.dsc
> +++ b/Platform/Hisilicon/D05/D05.dsc
> @@ -96,6 +96,7 @@
>UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
>
>LpcLib|Silicon/Hisilicon/Hi1610/Library/LpcLib/LpcLib.inf
> +  
> PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
>
> SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
>
>  [LibraryClasses.common.SEC]
> @@ -104,6 +105,7 @@
>
>  [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>I2CLib|Silicon/Hisilicon/Library/I2CLib/I2CLibRuntime.inf
> +  
> PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
>
> SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
>
>  [BuildOptions]
> diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc 
> b/Platform/Hisilicon/HiKey/HiKey.dsc
> index 83dd68a..f158529 100644
> --- a/Platform/Hisilicon/HiKey/HiKey.dsc
> +++ b/Platform/Hisilicon/HiKey/HiKey.dsc
> @@ -46,6 +46,7 @@
>DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
>
> +  
> PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
>
> SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
>
> RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
>TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
> diff --git a/Platform/Hisilicon/HiKey960/HiKey960.dsc 
> b/Platform/Hisilicon/HiKey960/HiKey960.dsc
> index 79e6875..a65c5b4 100644
> --- a/Platform/Hisilicon/HiKey960/HiKey960.dsc
> +++ b/Platform/Hisilicon/HiKey960/HiKey960.dsc
> @@ -45,6 +45,7 @@
>DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
>
> +  
> PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
>
> SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
>
> RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
>TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
> diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.dsc 
> b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
> index 7cd166d..0ca027e 100644
> --- a/Platform/LeMaker/CelloBoard/CelloBoard.dsc
> +++ b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
> @@ -102,6 +102,7 @@ DEFINE DO_FLASHER   = FALSE
>

Re: [edk2] [PATCH 2/2] ArmPlatformPkg: Include PL011UartClock Lib

[Ard Biesheuvel]

On 5 June 2018 at 19:59, Udit Kumar  wrote:
> This patch includes, PL011UartClock lib.
>
> In case of no implemenation of this Clock Lib,
> Pcd value will be used for PL011 frequency.
>

Please improve the commit log. You are modifying the code to obtain
the PL011 baud clock frequency from a library instead of a PCD

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Udit Kumar 
> ---
>  ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c   | 5 +++--
>  ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf | 1 +
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c 
> b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> index 6aa8063..c73e8db 100644
> --- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> +++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> @@ -19,6 +19,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -48,7 +49,7 @@ SerialPortInitialize (
>
>return PL011UartInitializePort (
> (UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> -   FixedPcdGet32 (PL011UartClkInHz),
> +   ArmPlatformGetPL011ClockFreq(),
> ,
> ,
> ,
> @@ -156,7 +157,7 @@ SerialPortSetAttributes (
>  {
>return PL011UartInitializePort (
> (UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> -   FixedPcdGet32 (PL011UartClkInHz),
> +   ArmPlatformGetPL011ClockFreq(),
> BaudRate,
> ReceiveFifoDepth,
> Parity,
> diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf 
> b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> index 3683e06..5ce5b2f 100644
> --- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> +++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> @@ -26,6 +26,7 @@
>PL011SerialPortLib.c
>
>  [LibraryClasses]
> +  PL011UartClockLib
>PL011UartLib
>PcdLib
>

You need to add a library resolution to
ArmPlatformPkg/ArmPlatformPkg.dsc for this library or you will break
the build.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq Support

[Ard Biesheuvel]

Hello Udit,

Apologies for not bringing this up the first time, but I have some
additional comments. The first time around, I only had a cursory look
because at that point I was still skeptical whether we needed this
library in the first place.

On 5 June 2018 at 19:59, Udit Kumar  wrote:
> Some platform support dynamic clocking, Which is controlled
> by some jumper setting or hardware registers.
> Result of that PCD PL011UartClkInHz needs to be updated for
> frequency change.
> This patch implements support for dynamic frequency for
> PL011 uart.
> This patch implements default lib, which is using Pcd.
> Platform which needs dynamic clocking needs implement
> PL011UartClockLib
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Udit Kumar 
> ---
>  ArmPlatformPkg/ArmPlatformPkg.dec  |  1 +
>  ArmPlatformPkg/Include/Library/PL011UartClockLib.h | 32 +++
>  .../Library/PL011UartClockLib/PL011UartClockLib.c  | 29 +
>  .../PL011UartClockLib/PL011UartClockLib.inf| 37 
> ++

Please add a reference to the new library in the [Components] section
of ArmPlatformPkg.dsc as well, so we can build it standalone.

>  4 files changed, 99 insertions(+)
>  create mode 100644 ArmPlatformPkg/Include/Library/PL011UartClockLib.h
>  create mode 100644 
> ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
>  create mode 100644 
> ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
>
> diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
> b/ArmPlatformPkg/ArmPlatformPkg.dec
> index dff4598..5f67e74 100644
> --- a/ArmPlatformPkg/ArmPlatformPkg.dec
> +++ b/ArmPlatformPkg/ArmPlatformPkg.dec
> @@ -36,6 +36,7 @@
>LcdHwLib|Include/Library/LcdHwLib.h
>LcdPlatformLib|Include/Library/LcdPlatformLib.h
>NorFlashPlatformLib|Include/Library/NorFlashPlatformLib.h
> +  PL011UartClockLib|Include/Library/PL011UartClockLib.h
>PL011UartLib|Include/Library/PL011UartLib.h
>
>  [Guids.common]
> diff --git a/ArmPlatformPkg/Include/Library/PL011UartClockLib.h 
> b/ArmPlatformPkg/Include/Library/PL011UartClockLib.h
> new file mode 100644
> index 000..93813a0
> --- /dev/null
> +++ b/ArmPlatformPkg/Include/Library/PL011UartClockLib.h
> @@ -0,0 +1,32 @@
> +/** @file
> +*
> +*  Copyright 2018 NXP
> +*
> +*  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 __PL011CLOCKLIB_H__
> +#define __PL011CLOCKLIB_H__

Nit: use __PL011UARTCLOCKLIB_H__ to match the filename.

> +
> +
> +/**
> +  Return frequency of PL011.
> +

Mention the baud clock?
> +  By default this function returns FixedPcdGet32 (PL011UartClkInHz)
> +

Drop this line please, it is not part of the prototype

> +  @return Return frequency of PL011
> +
> +**/
> +UINT32
> +ArmPlatformGetPL011ClockFreq (

The ArmPlatform prefix is unnecessary here: please use
PL011UartClockGetFreq() instead.

> +  VOID
> +  );
> +
> +#endif
> diff --git a/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c 
> b/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
> new file mode 100644
> index 000..b56af14
> --- /dev/null
> +++ b/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
> @@ -0,0 +1,29 @@
> +/** @file
> +*
> +*  Copyright 2018 NXP
> +*
> +*  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 
> +
> +/**
> +  Return clock in for PL011 Uart IP.
> +**/
> +UINT32

Please add EFIAPI even if it is defined to an empty string when using GCC/ARM.

> +ArmPlatformGetPL011ClockFreq (
> +  VOID
> +  )
> +{
> +  // This function needs to be implemented on platforms which supports
> +  // dynamic clocking to avoid re-building of UEFI firmware for PL011
> +  // clock change

Please drop this comment, it does not belong here. You can add
something along these lines in the declaration of the library class if
you want, but you can drop it altogether IMO.

> +  return FixedPcdGet32 (PL011UartClkInHz);
> +}
> diff --git a/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf 
> b/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
> new file mode 100644
> index 000..5f6f699
> --- /dev/null
> +++ 

Re: [edk2] Bug 843 - Need to remove unnecessary return statements in void functions of EDKII.

[Laszlo Ersek]

On 06/11/18 11:47, Laszlo Ersek wrote:
> On 06/11/18 09:17, Mohammad Younas Khan Pathan wrote:

> (4) Please split the patch to one patch per top-level directory. For
> example, you should have a separate patch for OvmfPkg.

This is required by our development workflow, but it's also required for
technical reasons. I'm just noticing that your posting (with message ID
)
hasn't even reached the list, and that's because the email was oversized
-- 855190 bytes. That's way beyond the limit.

If you split the changes with the right granularity, this won't be a
problem.

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

Re: [edk2] Bug 843 - Need to remove unnecessary return statements in void functions of EDKII.

[Laszlo Ersek]

Hello Younas,

On 06/11/18 09:17, Mohammad Younas Khan Pathan wrote:
> Hi all,
> 
> Please find the differences updated below, review and share your comments:

(1) Please submit the patch according to the edk2 development process.

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

In particular, please don't paste a diff into whatever email client you
use (e.g. gmail web interface); please use "git send-email" (or another
tool that can send out pristine patches that were generated with "git
format-patch").

(2) You need to add your Contributed-by and Signed-off-by lines at the
end of the commit message. Please refer to "Contributions.txt" in the
project root directory. In general, please write an appropriate commit
message.

(3) Please don't update copyright notices in source code that don't
belong to you (or to your employer). For example, you update Intel
copyright notices in several spots, but you don't seem to have an
@intel.com email address.

(4) Please split the patch to one patch per top-level directory. For
example, you should have a separate patch for OvmfPkg.

(5) Preferably, if the goal is to remove useless "return" statements,
don't remove or add unrelated empty lines; for example in
"OptionRomPkg/UndiRuntimeDxe/Init.c". It's OK to remove adjacent empty
lines that had been clearly added, originally, to separate the "return"
statements from the rest of the code.

I suggest that we work on the OvmfPkg patch at first, to get your
environment and workflow set up. Once the OvmfPkg patch looks good in
all areas, you can submit the rest of the patches the same way.

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

Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print to DEBUG_BLKIO

[Ard Biesheuvel]

On 11 June 2018 at 11:12, Zeng, Star  wrote:
> Let's go to use DEBUG_BLKIO to be consistent.
>
> Ard, Reviewed-by: Star Zeng .
> Hao, you can submit ticket on bugzilla and submit patch for NvmExpressDxe.
>

Thanks all

Pushed as 9dca2105ad96


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, June 11, 2018 4:54 PM
> To: Wu, Hao A 
> Cc: Zeng, Star ; edk2-devel@lists.01.org; Laszlo Ersek 
> 
> Subject: Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print to 
> DEBUG_BLKIO
>
> On 11 June 2018 at 10:38, Wu, Hao A  wrote:
>> Hi Ard,
>>
>> After a quick check on the behavior of other storage device drivers,
>> it seems to me that they are not using the same debug levels for this
>> kind of debug
>> message:
>>
>> ATA and USB mass storage - BLKIO
>> NVM Express - VERBOSE
>> SD/eMMC - INFO
>> SCSI - actually no such debug message
>>
>> My preference is to use the 'BLKIO' for the SD/eMMC case, since
>> literally, it seems the best fit and the majority of the drivers are using 
>> this level.
>> Or maybe we can use a combination of (DEBUG_BLKIO | DEBUG_VERBOSE).
>>
>> Ard and Star, what's your thought?
>>
>
> I am happy to stick with the patch as I proposed it, i.e., DEBUG_BLKIO only
>
>>> -Original Message-
>>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>>> Sent: Monday, June 11, 2018 4:15 PM
>>> To: Zeng, Star
>>> Cc: edk2-devel@lists.01.org; Laszlo Ersek; Wu, Hao A
>>> Subject: Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print
>>> to DEBUG_BLKIO
>>>
>>> On 8 June 2018 at 05:15, Zeng, Star  wrote:
>>> > Good patch.
>>> >
>>> > Another choice is to use DEBUG_VERBOSE.
>>> > We see other driver uses DEBUG_VERBOSE for BlockIo service (Hao can
>>> comment on that).
>>> > We'd better to align them for consistency.
>>> >
>>>
>>> Hao,
>>>
>>> Do you have any preference regarding the exact priority level we will
>>> use for this particular DEBUG() print?
>>>
>>> Thanks,
>>> Ard.
>>>
>>>
>>> > -Original Message-
>>> > From: Laszlo Ersek [mailto:ler...@redhat.com]
>>> > Sent: Friday, June 8, 2018 1:23 AM
>>> > To: Ard Biesheuvel ;
>>> > edk2-devel@lists.01.org
>>> > Cc: Zeng, Star 
>>> > Subject: Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG
>>> > print
>>> to DEBUG_BLKIO
>>> >
>>> > On 06/07/18 11:10, Ard Biesheuvel wrote:
>>> >> Lower the priority of the DEBUG print in EmmcReadWrite(), which is
>>> >> emitted for each read or write operation to the eMMC device, which
>>> >> clutters up the log output of builds created with DEBUG_INFO enabled.
>>> >>
>>> >> Suggested-by: Pipat Methavanitpong
>>> >> 
>>> >> Contributed-under: TianoCore Contribution Agreement 1.1
>>> >> Signed-off-by: Ard Biesheuvel 
>>> >> ---
>>> >>  MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c | 5 -
>>> >>  1 file changed, 4 insertions(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
>>> >> b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
>>> >> index e1d0f394a954..f6b230514b71 100644
>>> >> --- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
>>> >> +++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
>>> >> @@ -901,7 +901,10 @@ EmmcReadWrite (
>>> >>  if (EFI_ERROR (Status)) {
>>> >>return Status;
>>> >>  }
>>> >> -DEBUG ((EFI_D_INFO, "Emmc%a(): Part %d Lba 0x%x BlkNo 0x%x
>>> Event %p with %r\n", IsRead ? "Read " : "Write",
>>> Partition->PartitionType, Lba, BlockNum, (Token != NULL) ?
>>> Token->Event : NULL, Status));
>>> >> +DEBUG ((DEBUG_BLKIO,
>>> >> +  "Emmc%a(): Part %d Lba 0x%x BlkNo 0x%x Event %p with %r\n",
>>> >> +  IsRead ? "Read " : "Write", Partition->PartitionType, Lba, 
>>> >> BlockNum,
>>> >> +  (Token != NULL) ? Token->Event : NULL, Status));
>>> >>
>>> >>  Lba   += BlockNum;
>>> >>  Buffer = (UINT8*)Buffer + BufferSize;
>>> >>
>>> >
>>> > Reviewed-by: Laszlo Ersek 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools/tools_def IA32: disable PIE code generation explicitly

[Laszlo Ersek]

On 06/11/18 09:42, Ard Biesheuvel wrote:
> As a security measure, some distros now build their GCC toolchains with
> PIE code generation enabled by default, because it is a prerequisite
> for ASLR to be enabled when running the executable.
> 
> This typically results in slightly larger code, but it also generates
> ELF relocations that our tooling cannot deal with, so let's disable it
> explicitly when using GCC5 for IA32. (Note that this does not apply to
> X64: it uses PIE code deliberately in some cases, and our tooling does
> deal with the resuling relocations)
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  BaseTools/Conf/tools_def.template | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 7e9c915755ed..ab57f9c706e3 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -4670,7 +4670,7 @@ DEFINE GCC49_AARCH64_DLINK2_FLAGS= 
> DEF(GCC48_AARCH64_DLINK2_FLAGS)
>  DEFINE GCC49_ARM_ASLDLINK_FLAGS  = DEF(GCC48_ARM_ASLDLINK_FLAGS)
>  DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
>  
> -DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS)
> +DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS) -fno-pic 
> -fno-pie
>  DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS)
>  DEFINE GCC5_IA32_X64_DLINK_COMMON= DEF(GCC49_IA32_X64_DLINK_COMMON)
>  DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
> @@ -5502,9 +5502,9 @@ RELEASE_GCC49_AARCH64_DLINK_FLAGS  = 
> DEF(GCC49_AARCH64_DLINK_FLAGS)
>  *_GCC5_IA32_RC_PATH  = DEF(GCC5_IA32_PREFIX)objcopy
>  
>  *_GCC5_IA32_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m32 -fno-lto
> -*_GCC5_IA32_ASLDLINK_FLAGS   = DEF(GCC5_IA32_X64_ASLDLINK_FLAGS) 
> -Wl,-m,elf_i386
> +*_GCC5_IA32_ASLDLINK_FLAGS   = DEF(GCC5_IA32_X64_ASLDLINK_FLAGS) 
> -Wl,-m,elf_i386 -no-pie
>  *_GCC5_IA32_ASM_FLAGS= DEF(GCC5_ASM_FLAGS) -m32 -march=i386
> -*_GCC5_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS)
> +*_GCC5_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS) -no-pie
>  *_GCC5_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
>  *_GCC5_IA32_OBJCOPY_FLAGS=
>  *_GCC5_IA32_NASM_FLAGS   = -f elf32
> 

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

Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print to DEBUG_BLKIO

[Zeng, Star]

Let's go to use DEBUG_BLKIO to be consistent.

Ard, Reviewed-by: Star Zeng .
Hao, you can submit ticket on bugzilla and submit patch for NvmExpressDxe.

Thanks,
Star
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Monday, June 11, 2018 4:54 PM
To: Wu, Hao A 
Cc: Zeng, Star ; edk2-devel@lists.01.org; Laszlo Ersek 

Subject: Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print to 
DEBUG_BLKIO

On 11 June 2018 at 10:38, Wu, Hao A  wrote:
> Hi Ard,
>
> After a quick check on the behavior of other storage device drivers, 
> it seems to me that they are not using the same debug levels for this 
> kind of debug
> message:
>
> ATA and USB mass storage - BLKIO
> NVM Express - VERBOSE
> SD/eMMC - INFO
> SCSI - actually no such debug message
>
> My preference is to use the 'BLKIO' for the SD/eMMC case, since 
> literally, it seems the best fit and the majority of the drivers are using 
> this level.
> Or maybe we can use a combination of (DEBUG_BLKIO | DEBUG_VERBOSE).
>
> Ard and Star, what's your thought?
>

I am happy to stick with the patch as I proposed it, i.e., DEBUG_BLKIO only

>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Monday, June 11, 2018 4:15 PM
>> To: Zeng, Star
>> Cc: edk2-devel@lists.01.org; Laszlo Ersek; Wu, Hao A
>> Subject: Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print 
>> to DEBUG_BLKIO
>>
>> On 8 June 2018 at 05:15, Zeng, Star  wrote:
>> > Good patch.
>> >
>> > Another choice is to use DEBUG_VERBOSE.
>> > We see other driver uses DEBUG_VERBOSE for BlockIo service (Hao can
>> comment on that).
>> > We'd better to align them for consistency.
>> >
>>
>> Hao,
>>
>> Do you have any preference regarding the exact priority level we will 
>> use for this particular DEBUG() print?
>>
>> Thanks,
>> Ard.
>>
>>
>> > -Original Message-
>> > From: Laszlo Ersek [mailto:ler...@redhat.com]
>> > Sent: Friday, June 8, 2018 1:23 AM
>> > To: Ard Biesheuvel ; 
>> > edk2-devel@lists.01.org
>> > Cc: Zeng, Star 
>> > Subject: Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG 
>> > print
>> to DEBUG_BLKIO
>> >
>> > On 06/07/18 11:10, Ard Biesheuvel wrote:
>> >> Lower the priority of the DEBUG print in EmmcReadWrite(), which is 
>> >> emitted for each read or write operation to the eMMC device, which 
>> >> clutters up the log output of builds created with DEBUG_INFO enabled.
>> >>
>> >> Suggested-by: Pipat Methavanitpong 
>> >> 
>> >> Contributed-under: TianoCore Contribution Agreement 1.1
>> >> Signed-off-by: Ard Biesheuvel 
>> >> ---
>> >>  MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c | 5 -
>> >>  1 file changed, 4 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
>> >> b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
>> >> index e1d0f394a954..f6b230514b71 100644
>> >> --- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
>> >> +++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
>> >> @@ -901,7 +901,10 @@ EmmcReadWrite (
>> >>  if (EFI_ERROR (Status)) {
>> >>return Status;
>> >>  }
>> >> -DEBUG ((EFI_D_INFO, "Emmc%a(): Part %d Lba 0x%x BlkNo 0x%x
>> Event %p with %r\n", IsRead ? "Read " : "Write", 
>> Partition->PartitionType, Lba, BlockNum, (Token != NULL) ? 
>> Token->Event : NULL, Status));
>> >> +DEBUG ((DEBUG_BLKIO,
>> >> +  "Emmc%a(): Part %d Lba 0x%x BlkNo 0x%x Event %p with %r\n",
>> >> +  IsRead ? "Read " : "Write", Partition->PartitionType, Lba, 
>> >> BlockNum,
>> >> +  (Token != NULL) ? Token->Event : NULL, Status));
>> >>
>> >>  Lba   += BlockNum;
>> >>  Buffer = (UINT8*)Buffer + BufferSize;
>> >>
>> >
>> > Reviewed-by: Laszlo Ersek 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print to DEBUG_BLKIO

[Ard Biesheuvel]

On 11 June 2018 at 10:38, Wu, Hao A  wrote:
> Hi Ard,
>
> After a quick check on the behavior of other storage device drivers, it seems
> to me that they are not using the same debug levels for this kind of debug
> message:
>
> ATA and USB mass storage - BLKIO
> NVM Express - VERBOSE
> SD/eMMC - INFO
> SCSI - actually no such debug message
>
> My preference is to use the 'BLKIO' for the SD/eMMC case, since literally, it
> seems the best fit and the majority of the drivers are using this level.
> Or maybe we can use a combination of (DEBUG_BLKIO | DEBUG_VERBOSE).
>
> Ard and Star, what's your thought?
>

I am happy to stick with the patch as I proposed it, i.e., DEBUG_BLKIO only

>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Monday, June 11, 2018 4:15 PM
>> To: Zeng, Star
>> Cc: edk2-devel@lists.01.org; Laszlo Ersek; Wu, Hao A
>> Subject: Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print to
>> DEBUG_BLKIO
>>
>> On 8 June 2018 at 05:15, Zeng, Star  wrote:
>> > Good patch.
>> >
>> > Another choice is to use DEBUG_VERBOSE.
>> > We see other driver uses DEBUG_VERBOSE for BlockIo service (Hao can
>> comment on that).
>> > We'd better to align them for consistency.
>> >
>>
>> Hao,
>>
>> Do you have any preference regarding the exact priority level we will
>> use for this particular DEBUG() print?
>>
>> Thanks,
>> Ard.
>>
>>
>> > -Original Message-
>> > From: Laszlo Ersek [mailto:ler...@redhat.com]
>> > Sent: Friday, June 8, 2018 1:23 AM
>> > To: Ard Biesheuvel ; edk2-devel@lists.01.org
>> > Cc: Zeng, Star 
>> > Subject: Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print
>> to DEBUG_BLKIO
>> >
>> > On 06/07/18 11:10, Ard Biesheuvel wrote:
>> >> Lower the priority of the DEBUG print in EmmcReadWrite(), which is
>> >> emitted for each read or write operation to the eMMC device, which
>> >> clutters up the log output of builds created with DEBUG_INFO enabled.
>> >>
>> >> Suggested-by: Pipat Methavanitpong
>> >> 
>> >> Contributed-under: TianoCore Contribution Agreement 1.1
>> >> Signed-off-by: Ard Biesheuvel 
>> >> ---
>> >>  MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c | 5 -
>> >>  1 file changed, 4 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
>> >> b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
>> >> index e1d0f394a954..f6b230514b71 100644
>> >> --- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
>> >> +++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
>> >> @@ -901,7 +901,10 @@ EmmcReadWrite (
>> >>  if (EFI_ERROR (Status)) {
>> >>return Status;
>> >>  }
>> >> -DEBUG ((EFI_D_INFO, "Emmc%a(): Part %d Lba 0x%x BlkNo 0x%x
>> Event %p with %r\n", IsRead ? "Read " : "Write", Partition->PartitionType, 
>> Lba,
>> BlockNum, (Token != NULL) ? Token->Event : NULL, Status));
>> >> +DEBUG ((DEBUG_BLKIO,
>> >> +  "Emmc%a(): Part %d Lba 0x%x BlkNo 0x%x Event %p with %r\n",
>> >> +  IsRead ? "Read " : "Write", Partition->PartitionType, Lba, 
>> >> BlockNum,
>> >> +  (Token != NULL) ? Token->Event : NULL, Status));
>> >>
>> >>  Lba   += BlockNum;
>> >>  Buffer = (UINT8*)Buffer + BufferSize;
>> >>
>> >
>> > Reviewed-by: Laszlo Ersek 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools/tools_def IA32: disable PIE code generation explicitly

[Ard Biesheuvel]

On 11 June 2018 at 10:38, Gao, Liming  wrote:
> Ard:
>   Do you mean the default GCC compiler disables PIC and PIE for IA32 arch? 
> But now, some distribution GCC compiler enables PIC and PIE by default. So, 
> we have to obviously disable PIC and PIE in tools_def.txt.
>

Yes. On my x86 Ubuntu 18.04 LTS system:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.3.0-16ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
--prefix=/usr --with-gcc-major-version-only
--with-as=/usr/bin/x86_64-linux-gnu-as
--with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)


Notice the '--enable-default-pie' 4 lines from the bottom.



>>-Original Message-
>>From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>>Sent: Monday, June 11, 2018 3:42 PM
>>To: edk2-devel@lists.01.org
>>Cc: Zhu, Yonghong ; Gao, Liming
>>; ler...@redhat.com; Shi, Steven
>>; zenith...@users.sourceforge.net; Ard Biesheuvel
>>
>>Subject: [PATCH] BaseTools/tools_def IA32: disable PIE code generation
>>explicitly
>>
>>As a security measure, some distros now build their GCC toolchains with
>>PIE code generation enabled by default, because it is a prerequisite
>>for ASLR to be enabled when running the executable.
>>
>>This typically results in slightly larger code, but it also generates
>>ELF relocations that our tooling cannot deal with, so let's disable it
>>explicitly when using GCC5 for IA32. (Note that this does not apply to
>>X64: it uses PIE code deliberately in some cases, and our tooling does
>>deal with the resuling relocations)
>>
>>Contributed-under: TianoCore Contribution Agreement 1.1
>>Signed-off-by: Ard Biesheuvel 
>>---
>> BaseTools/Conf/tools_def.template | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>>diff --git a/BaseTools/Conf/tools_def.template
>>b/BaseTools/Conf/tools_def.template
>>index 7e9c915755ed..ab57f9c706e3 100755
>>--- a/BaseTools/Conf/tools_def.template
>>+++ b/BaseTools/Conf/tools_def.template
>>@@ -4670,7 +4670,7 @@ DEFINE GCC49_AARCH64_DLINK2_FLAGS=
>>DEF(GCC48_AARCH64_DLINK2_FLAGS)
>> DEFINE GCC49_ARM_ASLDLINK_FLAGS  =
>>DEF(GCC48_ARM_ASLDLINK_FLAGS)
>> DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  =
>>DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
>>
>>-DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS)
>>+DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS) -fno-pic
>>-fno-pie
>> DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS)
>> DEFINE GCC5_IA32_X64_DLINK_COMMON=
>>DEF(GCC49_IA32_X64_DLINK_COMMON)
>> DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  =
>>DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
>>@@ -5502,9 +5502,9 @@ RELEASE_GCC49_AARCH64_DLINK_FLAGS  =
>>DEF(GCC49_AARCH64_DLINK_FLAGS)
>> *_GCC5_IA32_RC_PATH  = DEF(GCC5_IA32_PREFIX)objcopy
>>
>> *_GCC5_IA32_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m32 -fno-lto
>>-*_GCC5_IA32_ASLDLINK_FLAGS   = DEF(GCC5_IA32_X64_ASLDLINK_FLAGS)
>>-Wl,-m,elf_i386
>>+*_GCC5_IA32_ASLDLINK_FLAGS   =
>>DEF(GCC5_IA32_X64_ASLDLINK_FLAGS) -Wl,-m,elf_i386 -no-pie
>> *_GCC5_IA32_ASM_FLAGS= DEF(GCC5_ASM_FLAGS) -m32 -
>>march=i386
>>-*_GCC5_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS)
>>+*_GCC5_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS) -no-
>>pie
>> *_GCC5_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
>> *_GCC5_IA32_OBJCOPY_FLAGS=
>> *_GCC5_IA32_NASM_FLAGS   = -f elf32
>>--
>>2.17.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools: Remove dsc nested include checking.

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Lin, Derek (HPS UEFI Dev) [mailto:derek.l...@hpe.com] 
Sent: Wednesday, May 09, 2018 5:03 PM
To: edk2-devel@lists.01.org
Cc: Zhu, Yonghong ; Lin, Derek (HPS UEFI Dev) 

Subject: [PATCH] BaseTools: Remove dsc nested include checking.

The dsc nested include checking make unexpected build error when building 
project A and switch to project B.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Derek Lin 
---
 BaseTools/Source/Python/Workspace/MetaFileParser.py | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/MetaFileParser.py 
b/BaseTools/Source/Python/Workspace/MetaFileParser.py
index 36843643ed..e1f4ea995d 100644
--- a/BaseTools/Source/Python/Workspace/MetaFileParser.py
+++ b/BaseTools/Source/Python/Workspace/MetaFileParser.py
@@ -2,7 +2,7 @@
 # This file is used to parse meta files  #  # Copyright (c) 2008 - 2018, Intel 
Corporation. All rights reserved. -# (C) Copyright 2015-2016 Hewlett 
Packard Enterprise Development LP
+# (C) Copyright 2015-2018 Hewlett Packard Enterprise Development LP
 # This program and the accompanying materials  # are licensed and made 
available under the terms and conditions of the BSD License  # which 
accompanies this distribution.  The full text of the license may be found at @@ 
-1551,10 +1551,21 @@ class DscParser(MetaFileParser):
 
 self.IncludedFiles.add (IncludedFile1)
 
+# todo: rework the nested include checking logic
+# Current nested include checking rely on dsc file order inside 
build.db.
+# It is not reliable and will lead to build fail in some case.
+#
+# When project A and B include a common dsc file C.
+# Build project A. It give dsc file A = ID 1 in build.db, and C ID 
= 2.
+# Build project B. It give dsc file B ID = 3, and C ID still = 2.
+# Then, we build project B fail, unless we clean build.db.
+# In oldder BaseTools, the project B ID will still be 1,
+# that's why it work before.
+
 # Does not allow lower level included file to include upper level 
included file
-if Parser._From != Owner and int(Owner) > int (Parser._From):
-EdkLogger.error('parser', FILE_ALREADY_EXIST, 
File=self._FileWithError,
-Line=self._LineIndex + 1, ExtraData="{0} is already 
included at a higher level.".format(IncludedFile1))
+#if Parser._From != Owner and int(Owner) > int (Parser._From):
+#EdkLogger.error('parser', FILE_ALREADY_EXIST, 
File=self._FileWithError,
+#Line=self._LineIndex + 1, ExtraData="{0} is already 
included at a higher level.".format(IncludedFile1))
 
 
 # set the parser status with current status
--
2.15.1.windows.2


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

Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print to DEBUG_BLKIO

[Wu, Hao A]

Hi Ard,

After a quick check on the behavior of other storage device drivers, it seems
to me that they are not using the same debug levels for this kind of debug
message:

ATA and USB mass storage - BLKIO
NVM Express - VERBOSE
SD/eMMC - INFO
SCSI - actually no such debug message

My preference is to use the 'BLKIO' for the SD/eMMC case, since literally, it
seems the best fit and the majority of the drivers are using this level.
Or maybe we can use a combination of (DEBUG_BLKIO | DEBUG_VERBOSE).

Ard and Star, what's your thought?

Best Regards,
Hao Wu

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, June 11, 2018 4:15 PM
> To: Zeng, Star
> Cc: edk2-devel@lists.01.org; Laszlo Ersek; Wu, Hao A
> Subject: Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print to
> DEBUG_BLKIO
> 
> On 8 June 2018 at 05:15, Zeng, Star  wrote:
> > Good patch.
> >
> > Another choice is to use DEBUG_VERBOSE.
> > We see other driver uses DEBUG_VERBOSE for BlockIo service (Hao can
> comment on that).
> > We'd better to align them for consistency.
> >
> 
> Hao,
> 
> Do you have any preference regarding the exact priority level we will
> use for this particular DEBUG() print?
> 
> Thanks,
> Ard.
> 
> 
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Friday, June 8, 2018 1:23 AM
> > To: Ard Biesheuvel ; edk2-devel@lists.01.org
> > Cc: Zeng, Star 
> > Subject: Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print
> to DEBUG_BLKIO
> >
> > On 06/07/18 11:10, Ard Biesheuvel wrote:
> >> Lower the priority of the DEBUG print in EmmcReadWrite(), which is
> >> emitted for each read or write operation to the eMMC device, which
> >> clutters up the log output of builds created with DEBUG_INFO enabled.
> >>
> >> Suggested-by: Pipat Methavanitpong
> >> 
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Ard Biesheuvel 
> >> ---
> >>  MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c | 5 -
> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> >> b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> >> index e1d0f394a954..f6b230514b71 100644
> >> --- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> >> +++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> >> @@ -901,7 +901,10 @@ EmmcReadWrite (
> >>  if (EFI_ERROR (Status)) {
> >>return Status;
> >>  }
> >> -DEBUG ((EFI_D_INFO, "Emmc%a(): Part %d Lba 0x%x BlkNo 0x%x
> Event %p with %r\n", IsRead ? "Read " : "Write", Partition->PartitionType, 
> Lba,
> BlockNum, (Token != NULL) ? Token->Event : NULL, Status));
> >> +DEBUG ((DEBUG_BLKIO,
> >> +  "Emmc%a(): Part %d Lba 0x%x BlkNo 0x%x Event %p with %r\n",
> >> +  IsRead ? "Read " : "Write", Partition->PartitionType, Lba, BlockNum,
> >> +  (Token != NULL) ? Token->Event : NULL, Status));
> >>
> >>  Lba   += BlockNum;
> >>  Buffer = (UINT8*)Buffer + BufferSize;
> >>
> >
> > Reviewed-by: Laszlo Ersek 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools/tools_def IA32: disable PIE code generation explicitly

[Gao, Liming]

Ard:
  Do you mean the default GCC compiler disables PIC and PIE for IA32 arch? But 
now, some distribution GCC compiler enables PIC and PIE by default. So, we have 
to obviously disable PIC and PIE in tools_def.txt. 

Thanks
Liming
>-Original Message-
>From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>Sent: Monday, June 11, 2018 3:42 PM
>To: edk2-devel@lists.01.org
>Cc: Zhu, Yonghong ; Gao, Liming
>; ler...@redhat.com; Shi, Steven
>; zenith...@users.sourceforge.net; Ard Biesheuvel
>
>Subject: [PATCH] BaseTools/tools_def IA32: disable PIE code generation
>explicitly
>
>As a security measure, some distros now build their GCC toolchains with
>PIE code generation enabled by default, because it is a prerequisite
>for ASLR to be enabled when running the executable.
>
>This typically results in slightly larger code, but it also generates
>ELF relocations that our tooling cannot deal with, so let's disable it
>explicitly when using GCC5 for IA32. (Note that this does not apply to
>X64: it uses PIE code deliberately in some cases, and our tooling does
>deal with the resuling relocations)
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Ard Biesheuvel 
>---
> BaseTools/Conf/tools_def.template | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/BaseTools/Conf/tools_def.template
>b/BaseTools/Conf/tools_def.template
>index 7e9c915755ed..ab57f9c706e3 100755
>--- a/BaseTools/Conf/tools_def.template
>+++ b/BaseTools/Conf/tools_def.template
>@@ -4670,7 +4670,7 @@ DEFINE GCC49_AARCH64_DLINK2_FLAGS=
>DEF(GCC48_AARCH64_DLINK2_FLAGS)
> DEFINE GCC49_ARM_ASLDLINK_FLAGS  =
>DEF(GCC48_ARM_ASLDLINK_FLAGS)
> DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  =
>DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
>
>-DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS)
>+DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS) -fno-pic
>-fno-pie
> DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS)
> DEFINE GCC5_IA32_X64_DLINK_COMMON=
>DEF(GCC49_IA32_X64_DLINK_COMMON)
> DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  =
>DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
>@@ -5502,9 +5502,9 @@ RELEASE_GCC49_AARCH64_DLINK_FLAGS  =
>DEF(GCC49_AARCH64_DLINK_FLAGS)
> *_GCC5_IA32_RC_PATH  = DEF(GCC5_IA32_PREFIX)objcopy
>
> *_GCC5_IA32_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m32 -fno-lto
>-*_GCC5_IA32_ASLDLINK_FLAGS   = DEF(GCC5_IA32_X64_ASLDLINK_FLAGS)
>-Wl,-m,elf_i386
>+*_GCC5_IA32_ASLDLINK_FLAGS   =
>DEF(GCC5_IA32_X64_ASLDLINK_FLAGS) -Wl,-m,elf_i386 -no-pie
> *_GCC5_IA32_ASM_FLAGS= DEF(GCC5_ASM_FLAGS) -m32 -
>march=i386
>-*_GCC5_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS)
>+*_GCC5_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS) -no-
>pie
> *_GCC5_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
> *_GCC5_IA32_OBJCOPY_FLAGS=
> *_GCC5_IA32_NASM_FLAGS   = -f elf32
>--
>2.17.1

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

Re: [edk2] Crc32 Calculation Miss

[Guy Raviv]

 EFI_CALCULATE_CRC32()  just calculate the crc for the given address and
size.

my question is whether PEI *code *is loaded into the RAM or not.
if it doesn't which seems reasonable, how can i reach it? some interface
for accessing the whole flash data.

Thanks,

On Mon, Jun 11, 2018 at 5:34 AM Gao, Liming  wrote:

> Guy:
>
>   Does EFI_CALCULATE_CRC32() cover the flash data that includes PEI
> module?
>
>
>
> Thanks
>
> Liming
>
> *From:* Guy Raviv [mailto:guyrav...@gmail.com]
> *Sent:* Sunday, June 10, 2018 2:59 PM
> *To:* Gao, Liming 
> *Cc:* edk2-devel@lists.01.org
> *Subject:* Re: [edk2] Crc32 Calculation Miss
>
>
>
> Update -  it seems that only in the Pei modules a code change doesn't
> change the crc.
>
> Does it make sense?
>
> if so, is there any interface to calculate the flash data itself in the
> Dxe phase?
>
>
>
> Thanks!
>
> Guy
>
>
>
> On Thu, Jun 7, 2018 at 9:34 AM Guy Raviv  wrote:
>
> Hi Gao,
>
>
>
> I used the EFI_CALCULATE_CRC32 function from
> edkCompatibilityPkg\Foundation.
>
>
>
> Thanks,
>
>
>
> Guy
>
>
>
> On Wed, Jun 6, 2018 at 6:00 PM, Gao, Liming  wrote:
>
> Do you use CalculateCrc32() in BaseLib to calculate CRC32 value for the
> different buffer?
>
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Guy Raviv
> > Sent: Wednesday, June 6, 2018 10:18 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] Crc32 Calculation Miss
> >
> > Hi Everyone,
> >
> > I have an odd problem.
> > In a specific module in my code (MRC training), code modification doesn't
> > change the BIOS Crc calculation.
> > 1. i checked in my project's fdf file if the FV base address and region
> > size defined are the same as the parameters i'm putting in the
> calculation.
> > 2. i also compared two different binaries and found they are exactly the
> > same.
> >
> > does anyone have any idea what can be wrong here or where should i check?
> >
> > Thanks,
> > Guy
>
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>
>
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [patch V2 1/3] ShellPkg/Dp: make sure memory is freed before exit

[Dandan Bi]

Run dp command now:
Firstly it will get performance records from FPDT and then
parse the DP command. And if encounter invalid parameters,
it will exit directly. Thus the performance records got before
are invalid. And what's worse is that the memory allocated in
getting performance records phase is not freed.

This patch update the code to parse the command firstly and
then get the performance records. And make sure that all the
clean work has been done before exiting.

Cc: Liming Gao 
Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
Reviewed-by: Ruiyu Ni 
---
 ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c | 70 ++-
 1 file changed, 37 insertions(+), 33 deletions(-)

diff --git a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c 
b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
index aa9c2cdf7a8..fe85937f557 100644
--- a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
+++ b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c
@@ -390,11 +390,11 @@ BuildCachedGuidHandleTable (
   }
   if (HandleBuffer != NULL) {
 FreePool (HandleBuffer);
 HandleBuffer = NULL;
   }
-  return Status;
+  return EFI_SUCCESS;
 }
 
 /**
   Get Measurement form Fpdt records.
 
@@ -729,39 +729,10 @@ RunDp (
   // initialize the shell lib (we must be in non-auto-init...)
   //
   Status = ShellInitialize();
   ASSERT_EFI_ERROR(Status);
 
-  //
-  // DP dump performance data by parsing FPDT table in ACPI table.
-  // Folloing 3 steps are to get the measurement form the FPDT table.
-  //
-
-  //
-  //1. Get FPDT from ACPI table.
-  //
-  Status = GetBootPerformanceTable ();
-  if (EFI_ERROR(Status)) {
-return Status;
-  }
-
-  //
-  //2. Cache the ModuleGuid and hanlde mapping table.
-  //
-  Status = BuildCachedGuidHandleTable();
-  if (EFI_ERROR (Status)) {
-return Status;
-  }
-
-  //
-  //3. Build the measurement array form the FPDT records.
-  //
-  Status = BuildMeasurementList ();
-  if (EFI_ERROR(Status)) {
-return Status;
-  }
-
   //
   // Process Command Line arguments
   //
   Status = ShellCommandLineParse (ParamList, , NULL, TRUE);
   if (EFI_ERROR(Status)) {
@@ -809,10 +780,42 @@ RunDp (
 #if PROFILING_IMPLEMENTED
 ProfileMode = TRUE;
 #endif  // PROFILING_IMPLEMENTED
   }
 
+  //
+  // DP dump performance data by parsing FPDT table in ACPI table.
+  // Folloing 3 steps are to get the measurement form the FPDT table.
+  //
+
+  //
+  //1. Get FPDT from ACPI table.
+  //
+  Status = GetBootPerformanceTable ();
+  if (EFI_ERROR (Status)) {
+ShellStatus = Status;
+goto Done;
+  }
+
+  //
+  //2. Cache the ModuleGuid and hanlde mapping table.
+  //
+  Status = BuildCachedGuidHandleTable();
+  if (EFI_ERROR (Status)) {
+ShellStatus = Status;
+goto Done;
+  }
+
+  //
+  //3. Build the measurement array form the FPDT records.
+  //
+  Status = BuildMeasurementList ();
+  if (EFI_ERROR (Status)) {
+ShellStatus = SHELL_OUT_OF_RESOURCES;
+goto Done;
+  }
+
   //
   // Initialize the pre-defined cumulative data.
   //
   InitCumulativeData ();
 
@@ -821,21 +824,22 @@ RunDp (
   //
   CustomCumulativeToken = ShellCommandLineGetValue (ParamPackage, L"-c");
   if (CustomCumulativeToken != NULL) {
 CustomCumulativeData = AllocateZeroPool (sizeof (PERF_CUM_DATA));
 if (CustomCumulativeData == NULL) {
-  return SHELL_OUT_OF_RESOURCES;
+  ShellStatus = SHELL_OUT_OF_RESOURCES;
+  goto Done;
 }
 CustomCumulativeData->MinDur = PERF_MAXDUR;
 CustomCumulativeData->MaxDur = 0;
 CustomCumulativeData->Count  = 0;
 CustomCumulativeData->Duration = 0;
 NameSize = StrLen (CustomCumulativeToken) + 1;
 CustomCumulativeData->Name   = AllocateZeroPool (NameSize);
 if (CustomCumulativeData->Name == NULL) {
-  FreePool (CustomCumulativeData);
-  return SHELL_OUT_OF_RESOURCES;
+  ShellStatus = SHELL_OUT_OF_RESOURCES;
+  goto Done;
 }
 UnicodeStrToAsciiStrS (CustomCumulativeToken, CustomCumulativeData->Name, 
NameSize);
   }
 
   //
-- 
2.14.3.windows.1

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

Re: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit ProcessCapsules () to be called once

[Ard Biesheuvel]

On 10 June 2018 at 21:21, Yao, Jiewen  wrote:
> Just got some idea since I am also reviewing FmpDevicePkg patch.
>
>
> The key problem we are trying to resolve that is: The core code uses EndOfDxe 
> as the lock event for system firmware, but an ARM platform may want to lock 
> system firmware later, maybe in other lock event.
>
> As such, how about we generalize the lock event as PcdSystemFmpLockEventGuid? 
> We can use EndOfDxeGuid as default one to keep the compatibility. At same 
> time this brings the flexibility for platform overriding.
>
>
> We only need update DxeCapsuleLibConstructor() to use the new PcdGuid, 
> instead of hardcode EndOfDxe.
> We don't need update the logic in ProcessCapsules() and 
> ProcessTheseCapsules().
> The policy in current platform is already enforced, if the platform has a 
> trusted console.
> For ARM platform, which wants to lock system firmware later. It can configure 
> another lock event GUID explicitly in platform DSC.
>

But that means we are still required to call ProcessCapsules () twice, no?

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao,
>> Jiewen
>> Sent: Sunday, June 10, 2018 12:02 PM
>> To: Kinney, Michael D ; Ard Biesheuvel
>> 
>> Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Zeng, Star
>> 
>> Subject: Re: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit
>> ProcessCapsules () to be called once
>>
>> My concern is that *always allowing* processing SystemCapsule after EndOfDxe
>> has security risk.
>>
>> IMHO, the risk is not *process*, if it is a platform choice. Instead, the 
>> risk is
>> *allow*, in the core logic.
>>
>> If we really want to do that, I hope we need a way to distinguish the 
>> difference
>> between a platform dispatching SystemCapsule after EndOfDxe *purposely* and
>> a platform dispatching SystemCapsule after EndOfDxe *by mistake*.
>>
>> Maybe some policy enforcement in the core logic. Static policy, at build 
>> time.
>>
>> Thank you
>> Yao Jiewen
>>
>> > -Original Message-
>> > From: Kinney, Michael D
>> > Sent: Sunday, June 10, 2018 8:57 AM
>> > To: Ard Biesheuvel ; Yao, Jiewen
>> > ; Kinney, Michael D 
>> > Cc: edk2-devel@lists.01.org; Zeng, Star ;
>> > leif.lindh...@linaro.org
>> > Subject: RE: [edk2] [PATCH v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: permit
>> > ProcessCapsules () to be called once
>> >
>> > Ard,
>> >
>> > I agree it should be a platform choice to process capsules
>> > before or after End of DXE.  It is even allowed in the
>> > UEFI Spec for capsules to be processed immediately
>> > which would include at OS runtime after ExitBootServices.
>> >
>> > There are 2 inputs to these choices:
>> > * The flags set in the Capsule itself.  See UEFI 2.7 Spec
>> >   Table 38 for the 5 allowed combinations.
>> > * Platform policy for each of these 5 capsule types and
>> >   when each of these 5 capsule types are allowed to be
>> >   processed.
>> >
>> > Jiewen's comments point to some assumptions that have been
>> > made in the logic.  These assumptions may be considered a
>> > safe default platform policy, but the code logic should
>> > allow the platform to easily select alternate policies.
>> >
>> > I think the patch you have provided attempts to add one
>> > additional policy.  Perhaps we should look at this from
>> > the UEFI Spec perspective and see how difficult it is to
>> > express policies for the supported capsule types.
>> >
>> > I will review your patch in more detail tomorrow.
>> >
>> > Thanks,
>> >
>> > Mike
>> >
>> > > -Original Message-
>> > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> > > Sent: Saturday, June 9, 2018 10:42 PM
>> > > To: Yao, Jiewen 
>> > > Cc: edk2-devel@lists.01.org; Kinney, Michael D
>> > > ; Zeng, Star
>> > > ; leif.lindh...@linaro.org
>> > > Subject: Re: [edk2] [PATCH v2 2/5]
>> > > MdeModulePkg/DxeCapsuleLibFmp: permit ProcessCapsules
>> > > () to be called once
>> > >
>> > > On 10 June 2018 at 07:38, Yao, Jiewen
>> > >  wrote:
>> > > > Hi Ard
>> > > > According to PI spec, "Prior to invoking any UEFI
>> > > drivers, or applications that are not from the platform
>> > > manufacturer, or connecting consoles, the platform
>> > > should signals the event EFI_END_OF_DXE_EVENT_GUID"
>> > > >
>> > > > In brief, EndOfDxe is signaled before 3rd part code
>> > > running.
>> > > >
>> > > > As such, it is legal that a trusted console is
>> > > connected before EndOfDxe.
>> > > > You can report progress to user before EndOfDxe.
>> > > >
>> > >
>> > > So how do I connect a trusted console on a system with
>> > > a plugin graphics card?
>> > > How can I report capsule update progress on such a
>> > > system?
>> > > On a system such as ARM where the actual flash update
>> > > involves calls
>> > > into the standalone MM layer, which makes the
>> > > distinction unnecessary,
>> > > how do you recommend to handle this if it is mandatory
>> > > according to
>> > > you to process the capsule before 

[edk2] [PATCH v3 2/2] ArmVirtPkg: switch to KVM safe IoLib implementation

[Ard Biesheuvel]

Switch to the new IoLib implementation that will only use KVM
safe instructions to perform MMIO memory accesses.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
v2: split off from 1/1

 ArmVirtPkg/ArmVirt.dsc.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index 766e4f598a07..7464ac70ed1b 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -41,7 +41,7 @@ [LibraryClasses.common]
   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
   
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
   PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
-  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
+  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.inf
   
UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
   CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
 
-- 
2.17.1

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

[edk2] [PATCH v3 1/2] MdePkg/BaseIoLibIntrinsic: make BaseIoLibIntrinsic safe for ArmVirt/KVM

[Ard Biesheuvel]

KVM on ARM refuses to decode load/store instructions used to perform
I/O to emulated devices, and instead relies on the exception syndrome
information to describe the operand register, access size, etc.
This is only possible for instructions that have a single input/output
register (as opposed to ones that increment the offset register, or
load/store pair instructions, etc). Otherwise, QEMU crashes with the
following error

  error: kvm run failed Function not implemented
  R00=01010101 R01=0008 R02=0048 R03=08000820
  R04=0120 R05=7faaa0e0 R06=7faaa0dc R07=7faaa0e8
  R08=7faaa0ec R09=7faaa088 R10=00ff R11=0080
  R12=ff00 R13=7fccfe08 R14=7faa835f R15=7faa887c
  PSR=81f3 N--- T svc32
  QEMU: Terminated

and KVM produces a warning such as the following in the kernel log

  kvm [17646]: load/store instruction decoding not implemented

The IoLib implementation provided by MdePkg/Library/BaseIoLibIntrinsic
is based on C code, and when LTO is in effect, the MMIO accesses could
be merged with, e.g., manipulations of the loop counter, producing
opcodes that KVM does not support for emulated MMIO.

So let's add a special ArmVirt flavor of this library that implements
that actual load/store operations in assembler, ensuring that the
instructions involved can be emulated by KVM.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
v3: add missing prototype comments in IoLibArmVirt.c
remove mention of ASSERT () from description of internal asm routines
v2: add missing .uni file
split off ArmVirtPkg change
add VS2017 version of AArch64 asm file
add reference to MdePkg.dsc

 MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S | 148 
 MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.asm   | 149 
 MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.S | 145 
 MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.asm   | 149 
 MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.inf |  52 ++
 MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.uni |  23 +
 MdePkg/Library/BaseIoLibIntrinsic/IoLibArmVirt.c| 733 

 MdePkg/MdePkg.dsc   |   1 +
 8 files changed, 1400 insertions(+)

diff --git a/MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S 
b/MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S
new file mode 100644
index ..85f59324270c
--- /dev/null
+++ b/MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S
@@ -0,0 +1,148 @@
+#
+#  Copyright (c) 2014-2018, Linaro Limited. 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.
+#
+#
+
+.text
+.align 3
+
+GCC_ASM_EXPORT(MmioRead8Internal)
+GCC_ASM_EXPORT(MmioWrite8Internal)
+GCC_ASM_EXPORT(MmioRead16Internal)
+GCC_ASM_EXPORT(MmioWrite16Internal)
+GCC_ASM_EXPORT(MmioRead32Internal)
+GCC_ASM_EXPORT(MmioWrite32Internal)
+GCC_ASM_EXPORT(MmioRead64Internal)
+GCC_ASM_EXPORT(MmioWrite64Internal)
+
+//
+//  Reads an 8-bit MMIO register.
+//
+//  Reads the 8-bit MMIO register specified by Address. The 8-bit read value is
+//  returned. This function must guarantee that all MMIO read and write
+//  operations are serialized.
+//
+//  @param  Address The MMIO register to read.
+//
+//  @return The value read.
+//
+ASM_PFX(MmioRead8Internal):
+  ldrbw0, [x0]
+  dmb ld
+  ret
+
+//
+//  Writes an 8-bit MMIO register.
+//
+//  Writes the 8-bit MMIO register specified by Address with the value 
specified
+//  by Value and returns Value. This function must guarantee that all MMIO read
+//  and write operations are serialized.
+//
+//  @param  Address The MMIO register to write.
+//  @param  Value   The value to write to the MMIO register.
+//
+ASM_PFX(MmioWrite8Internal):
+  dmb st
+  strbw1, [x0]
+  ret
+
+//
+//  Reads a 16-bit MMIO register.
+//
+//  Reads the 16-bit MMIO register specified by Address. The 16-bit read value 
is
+//  returned. This function must guarantee that all MMIO read and write
+//  operations are serialized.
+//
+//  @param  Address The MMIO register to read.
+//
+//  @return The value read.
+//
+ASM_PFX(MmioRead16Internal):
+  ldrhw0, [x0]
+  dmb ld
+  ret
+
+//
+//  Writes a 16-bit MMIO register.
+//
+//  Writes the 16-bit MMIO register specified by Address with the value 
specified
+//  by Value and returns Value. This function must guarantee that all MMIO read
+//  and write operations are serialized.
+//
+//  @param  Address The MMIO register to write.
+//  @param  Value   The value to write to 

[edk2] [PATCH 0/2] fix DXE memory free issue in SMM mode

[Jian J Wang]

This patch series try to fix an issue caused by trying to free memory
allocated in DXE but freed in SMM mode. This happens only if Heap
Guard feature is enabled, which needs to update page table. The root
cause is that DXE and SMM don't share the same paging configuration
but CpuDxe driver still tries to access page table through current
processor registers (CR3) in SMM mode, during memory free opration in
DXE core. This will cause DXE core got the incorrect paging attributes
of memory to be freed, and then fail the free operation.

The solution is let CpuDxe store the paging configuration in a global
variable and use it to access DXE page table if in SMM mode.

Jian J Wang (2):
  UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode
  MdeModulePkg/Core: remove SMM check for Heap Guard feature detection

 MdeModulePkg/Core/Dxe/Mem/HeapGuard.c |  10 
 UefiCpuPkg/CpuDxe/CpuDxe.c|   2 +-
 UefiCpuPkg/CpuDxe/CpuDxe.inf  |   1 +
 UefiCpuPkg/CpuDxe/CpuPageTable.c  | 108 +++---
 4 files changed, 75 insertions(+), 46 deletions(-)

-- 
2.16.2.windows.1

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

[edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode

[Jian J Wang]

The SMM version of MemoryAllocationLib allows to free memory allocated
in DXE (before EndOfDxe). This is done by checking the memory range and
calling gBS services to do real operation if the memory to free is out
of SMRAM. This would cause problem if some memory related features, like
Heap Guard, have to update page table to change memory attributes.
Because page table in SMM mode is different from DXE mode, gBS memory
services cannot get the correct attributes of DXE memory from SMM page
table and then cause incorrect memory manipulations.

The solution in this patch is to store the DXE page table information
(e.g. value of CR0, CR3 registers, etc.) in a global variable of CpuDxe
driver. If CpuDxe detects it's in SMM mode, it will use this global
variable to access page table instead of current processor registers.

Change-Id: If810bb1828160b8bdd8cb616d86df2859c74971f
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Jiewen Yao 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 UefiCpuPkg/CpuDxe/CpuDxe.c   |   2 +-
 UefiCpuPkg/CpuDxe/CpuDxe.inf |   1 +
 UefiCpuPkg/CpuDxe/CpuPageTable.c | 108 ++-
 3 files changed, 75 insertions(+), 36 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c
index 6ae2dcd1c7..1fd996fc3f 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -404,7 +404,7 @@ CpuSetMemoryAttributes (
   // to avoid unnecessary computing.
   //
   if (mIsFlushingGCD) {
-DEBUG((DEBUG_INFO, "  Flushing GCD\n"));
+DEBUG((DEBUG_GCD, "  Flushing GCD\n"));
 return EFI_SUCCESS;
   }
 
diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.inf b/UefiCpuPkg/CpuDxe/CpuDxe.inf
index 3c938cee53..8c8773af90 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.inf
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.inf
@@ -66,6 +66,7 @@
 [Protocols]
   gEfiCpuArchProtocolGuid   ## PRODUCES
   gEfiMpServiceProtocolGuid ## PRODUCES
+  gEfiSmmBase2ProtocolGuid
 
 [Guids]
   gIdleLoopEventGuid## CONSUMES   ## Event
diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c b/UefiCpuPkg/CpuDxe/CpuPageTable.c
index e2595b4d89..bf420d3792 100644
--- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
+++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "CpuDxe.h"
 #include "CpuPageTable.h"
@@ -87,7 +88,33 @@ PAGE_ATTRIBUTE_TABLE mPageAttributeTable[] = {
   {Page1G,  SIZE_1GB, PAGING_1G_ADDRESS_MASK_64},
 };
 
-PAGE_TABLE_POOL   *mPageTablePool = NULL;
+PAGE_TABLE_POOL   *mPageTablePool = NULL;
+PAGE_TABLE_LIB_PAGING_CONTEXT mPagingContext;
+EFI_SMM_BASE2_PROTOCOL*mSmmBase2 = NULL;
+
+BOOLEAN
+IsInSmm (
+  VOID
+  )
+{
+  EFI_STATUS  Status;
+  BOOLEAN InSmm;
+
+  InSmm = FALSE;
+  if (mSmmBase2 == NULL) {
+Status = gBS->LocateProtocol (, NULL,
+  (VOID **));
+if (EFI_ERROR (Status)) {
+  mSmmBase2 = NULL;
+}
+  }
+
+  if (mSmmBase2 != NULL) {
+mSmmBase2->InSmm (mSmmBase2, );
+  }
+
+  return InSmm;
+}
 
 /**
   Return current paging context.
@@ -102,42 +129,45 @@ GetCurrentPagingContext (
   UINT32 RegEax;
   UINT32 RegEdx;
 
-  ZeroMem(PagingContext, sizeof(*PagingContext));
-  if (sizeof(UINTN) == sizeof(UINT64)) {
-PagingContext->MachineType = IMAGE_FILE_MACHINE_X64;
-  } else {
-PagingContext->MachineType = IMAGE_FILE_MACHINE_I386;
-  }
-  if ((AsmReadCr0 () & BIT31) != 0) {
-PagingContext->ContextData.X64.PageTableBase = (AsmReadCr3 () & 
PAGING_4K_ADDRESS_MASK_64);
-  } else {
-PagingContext->ContextData.X64.PageTableBase = 0;
-  }
+  if (!IsInSmm ()) {
+if (sizeof(UINTN) == sizeof(UINT64)) {
+  mPagingContext.MachineType = IMAGE_FILE_MACHINE_X64;
+} else {
+  mPagingContext.MachineType = IMAGE_FILE_MACHINE_I386;
+}
+if ((AsmReadCr0 () & BIT31) != 0) {
+  mPagingContext.ContextData.X64.PageTableBase = (AsmReadCr3 () & 
PAGING_4K_ADDRESS_MASK_64);
+} else {
+  mPagingContext.ContextData.X64.PageTableBase = 0;
+}
 
-  if ((AsmReadCr4 () & BIT4) != 0) {
-PagingContext->ContextData.Ia32.Attributes |= 
PAGE_TABLE_LIB_PAGING_CONTEXT_IA32_X64_ATTRIBUTES_PSE;
-  }
-  if ((AsmReadCr4 () & BIT5) != 0) {
-PagingContext->ContextData.Ia32.Attributes |= 
PAGE_TABLE_LIB_PAGING_CONTEXT_IA32_X64_ATTRIBUTES_PAE;
-  }
-  if ((AsmReadCr0 () & BIT16) != 0) {
-PagingContext->ContextData.Ia32.Attributes |= 
PAGE_TABLE_LIB_PAGING_CONTEXT_IA32_X64_ATTRIBUTES_WP_ENABLE;
-  }
+if ((AsmReadCr4 () & BIT4) != 0) {
+  mPagingContext.ContextData.Ia32.Attributes |= 
PAGE_TABLE_LIB_PAGING_CONTEXT_IA32_X64_ATTRIBUTES_PSE;
+}
+if ((AsmReadCr4 () & BIT5) != 0) {
+  mPagingContext.ContextData.Ia32.Attributes |= 
PAGE_TABLE_LIB_PAGING_CONTEXT_IA32_X64_ATTRIBUTES_PAE;
+}
+if ((AsmReadCr0 () & BIT16) 

[edk2] [PATCH 2/2] MdeModulePkg/Core: remove SMM check for Heap Guard feature detection

[Jian J Wang]

CpuDxe driver is updated to be able to access DXE page table in SMM mode,
which means Heap Guard can get correct memory paging attributes in what
ever modes. It's not necessary to exclude SMM from detecting Heap Guard
feature support.

Change-Id: I5310e6e49a258ac7a9240e40c8c99cdb692c1e02
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c 
b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
index 9d765c98f6..447c56bb11 100644
--- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
+++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
@@ -667,21 +667,11 @@ IsMemoryTypeToGuard (
 {
   UINT64 TestBit;
   UINT64 ConfigBit;
-  BOOLEAN InSmm;
 
   if (AllocateType == AllocateAddress) {
 return FALSE;
   }
 
-  InSmm = FALSE;
-  if (gSmmBase2 != NULL) {
-gSmmBase2->InSmm (gSmmBase2, );
-  }
-
-  if (InSmm) {
-return FALSE;
-  }
-
   if ((PcdGet8 (PcdHeapGuardPropertyMask) & PageOrPool) == 0) {
 return FALSE;
   }
-- 
2.16.2.windows.1

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

Re: [edk2] [PATCH v2 1/2] MdePkg/BaseIoLibIntrinsic: make BaseIoLibIntrinsic safe for ArmVirt/KVM

[Ard Biesheuvel]

On 11 June 2018 at 07:42, Gao, Liming  wrote:
> Ard:
>   The function MmioRead8Internal() .. MmioWrite64Internal() miss the function 
> header comments. Please add them.
>

OK

> Thanks
> Liming
>>-Original Message-
>>From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>>Sent: Monday, June 11, 2018 2:09 AM
>>To: edk2-devel@lists.01.org
>>Cc: leif.lindh...@linaro.org; ler...@redhat.com; Gao, Liming
>>; Kinney, Michael D ;
>>Ard Biesheuvel 
>>Subject: [PATCH v2 1/2] MdePkg/BaseIoLibIntrinsic: make BaseIoLibIntrinsic
>>safe for ArmVirt/KVM
>>
>>KVM on ARM refuses to decode load/store instructions used to perform
>>I/O to emulated devices, and instead relies on the exception syndrome
>>information to describe the operand register, access size, etc.
>>This is only possible for instructions that have a single input/output
>>register (as opposed to ones that increment the offset register, or
>>load/store pair instructions, etc). Otherwise, QEMU crashes with the
>>following error
>>
>>  error: kvm run failed Function not implemented
>>  R00=01010101 R01=0008 R02=0048 R03=08000820
>>  R04=0120 R05=7faaa0e0 R06=7faaa0dc R07=7faaa0e8
>>  R08=7faaa0ec R09=7faaa088 R10=00ff R11=0080
>>  R12=ff00 R13=7fccfe08 R14=7faa835f R15=7faa887c
>>  PSR=81f3 N--- T svc32
>>  QEMU: Terminated
>>
>>and KVM produces a warning such as the following in the kernel log
>>
>>  kvm [17646]: load/store instruction decoding not implemented
>>
>>The IoLib implementation provided by MdePkg/Library/BaseIoLibIntrinsic
>>is based on C code, and when LTO is in effect, the MMIO accesses could
>>be merged with, e.g., manipulations of the loop counter, producing
>>opcodes that KVM does not support for emulated MMIO.
>>
>>So let's add a special ArmVirt flavor of this library that implements
>>that actual load/store operations in assembler, ensuring that the
>>instructions involved can be emulated by KVM.
>>
>>Contributed-under: TianoCore Contribution Agreement 1.1
>>Signed-off-by: Ard Biesheuvel 
>>---
>> MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S | 164 +
>> MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.asm   | 165
>>+
>> MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.S | 161 +
>> MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.asm   | 165 +
>> MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.inf |  52 ++
>> MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.uni |  23 +
>> MdePkg/Library/BaseIoLibIntrinsic/IoLibArmVirt.c| 641
>>
>> MdePkg/MdePkg.dsc   |   1 +
>> 8 files changed, 1372 insertions(+)
>>
>>diff --git a/MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S
>>b/MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S
>>new file mode 100644
>>index ..47be68a3e783
>>--- /dev/null
>>+++ b/MdePkg/Library/BaseIoLibIntrinsic/AArch64/ArmVirtMmio.S
>>@@ -0,0 +1,164 @@
>>+#
>>+#  Copyright (c) 2014-2018, Linaro Limited. 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.
>>+#
>>+#
>>+
>>+.text
>>+.align 3
>>+
>>+GCC_ASM_EXPORT(MmioRead8Internal)
>>+GCC_ASM_EXPORT(MmioWrite8Internal)
>>+GCC_ASM_EXPORT(MmioRead16Internal)
>>+GCC_ASM_EXPORT(MmioWrite16Internal)
>>+GCC_ASM_EXPORT(MmioRead32Internal)
>>+GCC_ASM_EXPORT(MmioWrite32Internal)
>>+GCC_ASM_EXPORT(MmioRead64Internal)
>>+GCC_ASM_EXPORT(MmioWrite64Internal)
>>+
>>+//
>>+//  Reads an 8-bit MMIO register.
>>+//
>>+//  Reads the 8-bit MMIO register specified by Address. The 8-bit read value
>>is
>>+//  returned. This function must guarantee that all MMIO read and write
>>+//  operations are serialized.
>>+//
>>+//  If 8-bit MMIO register operations are not supported, then ASSERT().
>>+//
>>+//  @param  Address The MMIO register to read.
>>+//
>>+//  @return The value read.
>>+//
>>+ASM_PFX(MmioRead8Internal):
>>+  ldrbw0, [x0]
>>+  dmb ld
>>+  ret
>>+
>>+//
>>+//  Writes an 8-bit MMIO register.
>>+//
>>+//  Writes the 8-bit MMIO register specified by Address with the value
>>specified
>>+//  by Value and returns Value. This function must guarantee that all MMIO
>>read
>>+//  and write operations are serialized.
>>+//
>>+//  If 8-bit MMIO register operations are not supported, then ASSERT().
>>+//
>>+//  @param  Address The MMIO register to write.
>>+//  @param  Value   The value to write to the MMIO register.
>>+//
>>+ASM_PFX(MmioWrite8Internal):
>>+  dmb st
>>+  strbw1, [x0]
>>+  ret
>>+
>>+//
>>+//  Reads a 16-bit MMIO register.
>>+//
>>+//