public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Song, BinX" <binx.song@intel.com>
To: Fan Jeff <vanjeff_919@hotmail.com>,
	"Ni, Ruiyu" <ruiyu.ni@intel.com>,
	Laszlo Ersek <lersek@redhat.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Dong, Eric" <eric.dong@intel.com>
Subject: Re: [PATCH V2] UefiCpuPkg: Check invalid RegisterCpuFeature parameter
Date: Thu, 14 Dec 2017 01:41:43 +0000	[thread overview]
Message-ID: <559D2DF22BC9A3468B4FA1AA547F0EF1025C2620@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <CO2PR19MB013784B5AFD158702FD85096D7350@CO2PR19MB0137.namprd19.prod.outlook.com>

Hi All,

Thanks for your suggestion, I will update a V3 patch.

Best Regards,
Bell Song

From: Fan Jeff [mailto:vanjeff_919@hotmail.com]
Sent: Wednesday, December 13, 2017 11:35 PM
To: Ni, Ruiyu <ruiyu.ni@intel.com>; Laszlo Ersek <lersek@redhat.com>; Song, BinX <binx.song@intel.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.dong@intel.com>
Subject: 答复: [edk2] [PATCH V2] UefiCpuPkg: Check invalid RegisterCpuFeature parameter


I agree to add one _MAX #define in library instance implementation instead of in class header file.



Jeff



________________________________
From: edk2-devel <edk2-devel-bounces@lists.01.org<mailto:edk2-devel-bounces@lists.01.org>> on behalf of Ni, Ruiyu <ruiyu.ni@Intel.com<mailto:ruiyu.ni@Intel.com>>
Sent: Wednesday, December 13, 2017 4:49:01 PM
To: Laszlo Ersek; Song, BinX; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Dong, Eric
Subject: Re: [edk2] [PATCH V2] UefiCpuPkg: Check invalid RegisterCpuFeature parameter

On 12/13/2017 4:44 PM, Laszlo Ersek wrote:
> On 12/13/17 03:35, Song, BinX wrote:
>> V2:
>> Update function name, add more detail description.
>> V1:
>> Check and assert invalid RegisterCpuFeature function parameter
>>
>> Cc: Eric Dong <eric.dong@intel.com<mailto:eric.dong@intel.com>>
>> Cc: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Bell Song <binx.song@intel.com<mailto:binx.song@intel.com>>
>> ---
>>   .../Include/Library/RegisterCpuFeaturesLib.h       |  5 ++++
>>   .../RegisterCpuFeaturesLib.c                       | 29 ++++++++++++++++++++++
>>   2 files changed, 34 insertions(+)
>>
>> diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
>> index 9331e49..fc3ccda 100644
>> --- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
>> +++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
>> @@ -71,6 +71,11 @@
>>   #define CPU_FEATURE_APIC_TPR_UPDATE_MESSAGE         (32+9)
>>   #define CPU_FEATURE_ENERGY_PERFORMANCE_BIAS         (32+10)
>>   #define CPU_FEATURE_PPIN                            (32+11)
>> +//
>> +// Currently, CPU_FEATURE_PROC_TRACE is the MAX feature we support.
>> +// If you define a feature bigger than it, please also replace it
>> +// in RegisterCpuFeatureLibIsFeatureValid function.
>> +//
>>   #define CPU_FEATURE_PROC_TRACE                      (32+12)
>>
>>   #define CPU_FEATURE_BEFORE_ALL                      BIT27
>> diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
>> index dd6a82b..6ec26e1 100644
>> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
>> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
>> @@ -81,6 +81,34 @@ DumpCpuFeature (
>>   }
>>
>>   /**
>> +  Determines if the CPU feature is valid.
>> +
>> +  @param[in]  Feature        Pointer to CPU feature
>> +
>> +  @retval TRUE  The CPU feature is valid.
>> +  @retval FALSE The CPU feature is invalid.
>> +**/
>> +BOOLEAN
>> +RegisterCpuFeatureLibIsFeatureValid (
>> +  IN UINT32        Feature
>> +  )
>> +{
>> +  UINT32      Data;
>> +
>> +  Data = Feature;
>> +  Data &= ~(CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER | CPU_FEATURE_BEFORE_ALL | CPU_FEATURE_AFTER_ALL);
>> +  //
>> +  // Currently, CPU_FEATURE_PROC_TRACE is the MAX feature we support.
>> +  // If you define a feature bigger than it, please replace it at below.
>> +  //
>> +  if (Data > CPU_FEATURE_PROC_TRACE) {
>> +    DEBUG ((DEBUG_ERROR, "Invalid CPU feature: 0x%x ", Feature));
>> +    return FALSE;
>> +  }
>> +  return TRUE;
>> +}
>> +
>> +/**
>>     Determines if the feature bit mask is in dependent CPU feature bit mask buffer.
>>
>>     @param[in]  FeatureMask        Pointer to CPU feature bit mask
>> @@ -444,6 +472,7 @@ RegisterCpuFeature (
>>
>>     VA_START (Marker, InitializeFunc);
>>     Feature = VA_ARG (Marker, UINT32);
>> +  ASSERT (RegisterCpuFeatureLibIsFeatureValid(Feature));
>>     while (Feature != CPU_FEATURE_END) {
>>       ASSERT ((Feature & (CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER))
>>                       != (CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER));
>>
>
> The consensus thus far seems to be that we should not add a separate
> _MAX macro for this purpose. I don't understand why -- in my opinion it
> would be easier to update the macro in one place only.
>
> Now, I realize we have a library class header file here, and a library
> instance. Those things are separate; it is conceivable that another
> library instance is developed independently, and thus we should not tie
> the MAX feature of *all* library instances to the same central class header.
>
> However, this separation is already being violated in this patch: the
> RegisterCpuFeatureLibIsFeatureValid() function is an implementation
> detail of the (currently only one) library instance. Thus, the lib class
> header should not refer to it, even in a comment.
>
> So, I don't understand why we can't just add a _MAX macro. The central
> library instance could use _MAX; all other (out of tree) instances would
> not use _MAX.
>

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

> Anyway, this doesn't mean the patch is not correct.
>
> Acked-by: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>
>
> Thanks
> Laszlo
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
>


--
Thanks,
Ray
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel

      reply	other threads:[~2017-12-14  1:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-13  2:35 [PATCH V2] UefiCpuPkg: Check invalid RegisterCpuFeature parameter Song, BinX
2017-12-13  2:42 ` Ni, Ruiyu
2017-12-13  8:44 ` Laszlo Ersek
2017-12-13  8:49   ` Ni, Ruiyu
2017-12-13 15:34     ` 答复: " Fan Jeff
2017-12-14  1:41       ` Song, BinX [this message]

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=559D2DF22BC9A3468B4FA1AA547F0EF1025C2620@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