public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Zeng, Star" <star.zeng@intel.com>
To: "Bi, Dandan" <dandan.bi@intel.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Laszlo Ersek <lersek@redhat.com>
Cc: "Dong, Eric" <eric.dong@intel.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	"Gao, Liming" <liming.gao@intel.com>,
	"Leif Lindholm" <leif.lindholm@linaro.org>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>,
	"Zeng, Star" <star.zeng@intel.com>
Subject: Re: [PATCH v2 4/5] MdeModulePkg/DxeCorePerformanceLib: use AllocatePeiAccessiblePages
Date: Fri, 25 May 2018 02:44:55 +0000	[thread overview]
Message-ID: <0C09AFA07DD0434D9E2A0C6AEB0483103BAF0D2C@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <3C0D5C461C9E904E8F62152F6274C0BB3BAD963A@shsmsx102.ccr.corp.intel.com>

mAcpiBootPerformanceTable->Header.Length could reflect the real table length, right?
When the padding (from the PCD) memory is used, mAcpiBootPerformanceTable->Header.Length will be updated accordingly.
If that is the case, it seems safe without ZeroMem.
Anyway it needs to be verified.


But, to be simple, I do not object to have ZeroMem to be equivalent with previous code.



Thanks,
Star
-----Original Message-----
From: Bi, Dandan 
Sent: Friday, May 25, 2018 10:01 AM
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Laszlo Ersek <lersek@redhat.com>
Cc: Dong, Eric <eric.dong@intel.com>; edk2-devel@lists.01.org; Gao, Liming <liming.gao@intel.com>; Leif Lindholm <leif.lindholm@linaro.org>; Kinney, Michael D <michael.d.kinney@intel.com>; Zeng, Star <star.zeng@intel.com>
Subject: RE: [edk2] [PATCH v2 4/5] MdeModulePkg/DxeCorePerformanceLib: use AllocatePeiAccessiblePages

Hi Ard,

Thank you very much for helping fix this issue.

And for ZeroMem(), it should be added back.
Because after the memory is allocated, the optional padding (from the PCD) memory will be used directly. 
If ZeoMem() is dropped, then some contents in the padding memory will not be zero. Thus will impact the tool to parse the contents.

Thanks,
Dandan
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard Biesheuvel
Sent: Thursday, May 24, 2018 8:54 PM
To: Laszlo Ersek <lersek@redhat.com>
Cc: Dong, Eric <eric.dong@intel.com>; edk2-devel@lists.01.org; Gao, Liming <liming.gao@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Leif Lindholm <leif.lindholm@linaro.org>; Kinney, Michael D <michael.d.kinney@intel.com>; Zeng, Star <star.zeng@intel.com>
Subject: Re: [edk2] [PATCH v2 4/5] MdeModulePkg/DxeCorePerformanceLib: use AllocatePeiAccessiblePages

On 24 May 2018 at 14:49, Laszlo Ersek <lersek@redhat.com> wrote:
> On 05/24/18 11:09, Ard Biesheuvel wrote:
>> Replace the call to and implementation of the function
>> FpdtAllocateReservedMemoryBelow4G() with a call to 
>> AllocatePeiAccessiblePages, which boils down to the same on X64, but 
>> does not crash non-X64 systems that lack memory below 4 GB.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> Note that the ZeroMem() call is dropped, but it is redundant anyway, 
>> given that the subsequent CopyMem() call supersedes it immediately.
>
> I'm not sure the ZeroMem() is redundant. The allocation size -- before rounding up to full pages -- is computed like this:
>
>   BootPerformanceDataSize = sizeof (BOOT_PERFORMANCE_TABLE) + mPerformanceLength + PcdGet32 (PcdExtFpdtBootRecordPadSize);
>   if (SmmCommData != NULL && SmmBootRecordData != NULL) {
>     BootPerformanceDataSize += SmmBootRecordDataSize;
>   }
>
> ZeroMem() covers all of the above, but the CopyMem() calls don't seem to cover the optional padding (from the PCD).
>
> I'm unsure if that matters, of course.
>

You're quite right. I'm not sure how I missed that.

In any case, I can add back the ZeroMem () quite easily after the single invocation of AllocatePeiAccessiblePages() that I am adding in this file.

> The patch looks good to me otherwise.
>
> Thanks
> Laszlo
>
>
>>
>>  MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c |
>> 45 ++------------------
>>  1 file changed, 4 insertions(+), 41 deletions(-)
>>
>> diff --git
>> a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
>> b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
>> index 71d624fc9ce9..b1f09710b65c 100644
>> ---
>> a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
>> +++ b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLi
>> +++ b.c
>> @@ -165,46 +165,6 @@ IsKnownID (
>>    }
>>  }
>>
>> -/**
>> -  Allocate EfiReservedMemoryType below 4G memory address.
>> -
>> -  This function allocates EfiReservedMemoryType below 4G memory address.
>> -
>> -  @param[in]  Size   Size of memory to allocate.
>> -
>> -  @return Allocated address for output.
>> -
>> -**/
>> -VOID *
>> -FpdtAllocateReservedMemoryBelow4G (
>> -  IN UINTN       Size
>> -  )
>> -{
>> -  UINTN                 Pages;
>> -  EFI_PHYSICAL_ADDRESS  Address;
>> -  EFI_STATUS            Status;
>> -  VOID                  *Buffer;
>> -
>> -  Buffer  = NULL;
>> -  Pages   = EFI_SIZE_TO_PAGES (Size);
>> -  Address = 0xffffffff;
>> -
>> -  Status = gBS->AllocatePages (
>> -                  AllocateMaxAddress,
>> -                  EfiReservedMemoryType,
>> -                  Pages,
>> -                  &Address
>> -                  );
>> -  ASSERT_EFI_ERROR (Status);
>> -
>> -  if (!EFI_ERROR (Status)) {
>> -    Buffer = (VOID *) (UINTN) Address;
>> -    ZeroMem (Buffer, Size);
>> -  }
>> -
>> -  return Buffer;
>> -}
>> -
>>  /**
>>    Allocate buffer for Boot Performance table.
>>
>> @@ -348,7 +308,10 @@ AllocateBootPerformanceTable (
>>      //
>>      // Fail to allocate at specified address, continue to allocate at any address.
>>      //
>> -    mAcpiBootPerformanceTable = (BOOT_PERFORMANCE_TABLE *) FpdtAllocateReservedMemoryBelow4G (BootPerformanceDataSize);
>> +    mAcpiBootPerformanceTable = (BOOT_PERFORMANCE_TABLE *) AllocatePeiAccessiblePages (
>> +                                                             EfiReservedMemoryType,
>> +                                                             EFI_SIZE_TO_PAGES (BootPerformanceDataSize)
>> +                                                             );
>>    }
>>    DEBUG ((DEBUG_INFO, "DxeCorePerformanceLib: ACPI Boot Performance 
>> Table address = 0x%x\n", mAcpiBootPerformanceTable));
>>
>>
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


  reply	other threads:[~2018-05-25  2:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-24  9:09 [PATCH v2 0/5] Abstract allocation of PEI accessible memory Ard Biesheuvel
2018-05-24  9:09 ` [PATCH v2 1/5] OvmfPkg/PlatformBootManagerLib: add missing report status code call Ard Biesheuvel
2018-05-24  9:09 ` [PATCH v2 2/5] ArmVirtPkg/PlatformBootManagerLib: " Ard Biesheuvel
2018-05-24  9:09 ` [PATCH v2 3/5] MdePkg/DxeServicesLib: introduce AllocatePeiAccessiblePages routine Ard Biesheuvel
2018-05-24 12:36   ` Laszlo Ersek
2018-05-24  9:09 ` [PATCH v2 4/5] MdeModulePkg/DxeCorePerformanceLib: use AllocatePeiAccessiblePages Ard Biesheuvel
2018-05-24 12:49   ` Laszlo Ersek
2018-05-24 12:54     ` Ard Biesheuvel
2018-05-24 13:09       ` Laszlo Ersek
2018-05-25  2:00       ` Bi, Dandan
2018-05-25  2:44         ` Zeng, Star [this message]
2018-05-25  3:07           ` Bi, Dandan
2018-05-24  9:09 ` [PATCH v2 5/5] MdeModulePkg/FirmwarePerformanceDataTableDxe: " Ard Biesheuvel
2018-05-24 12:53   ` Laszlo Ersek
2018-05-24 16:57 ` [PATCH v2 0/5] Abstract allocation of PEI accessible memory Kinney, Michael D

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0C09AFA07DD0434D9E2A0C6AEB0483103BAF0D2C@shsmsx102.ccr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox