Re: [PATCH v2] UefiCpuPkg/PiSmmCpuDxeSmm: Avoid allocate Token every time.

["Laszlo Ersek" <lersek@redhat.com>]

On 12/02/19 06:14, Ni, Ray wrote:
>>> Laszlo,
>>> I agree with you to use to PCD for "token count per chunk".
>>> But I suggest the default value of that PCD can be at least 64.
>>> Reasons:
>>> 1. MM_MP is the new MP protocol in SMM environment and we expect
>>>     all SMM code start to use the new protocol instead of the original
>> StartupThisAp
>>>     service exposed through SMM System table.
>>
>> If we consider the older SmmStartupThisAp() / MmStartupThisAp() member
>> functions, the situation is almost the same -- (almost) no callers. In
>> edk2, only SmmPeriodicSmiLib seems to call this SMST (MMST) API. In
>> edk2-platforms, MinPlatformPkg uses the lib class, and also calls
>> SmmStartupThisAp().
>>
>> I'm just saying that "all SMM code" using "the original StartupThisAp
>> service" in fact means a single open source platform.
> 
> The benefit of MmMp is it introduces StartupAllAps service which
> is very useful in many core system.
> There are needs to call the new services in close source code.
> 
> PI spec contains a more detailed description on the differences:
> * It is possible to invoke a procedure on multiple processors.
> * Supports blocking and non-blocking modes of operation.
> 
>>
>>> 2. A value of 1 is totally to disable the pre-allocating.
>>
>> I disagree; with value 1, the InitializeDataForMmMp() function allocates
>> a new chunk, with room for 1 token. That occurs ahead of actually
>> needing the token, therefore it is a preallocation.
>>
>> What you mean is that the chunking will not make a difference relative
>> to the current behavior, because every token creation/use will require a
>> new chunk allocation. Indeed.
>>
>> But that doesn't change the fact that the first token will be allocated
>> prior to actually needing it, and if a platform never needs a token,
>> then the first chunk will just be there doing nothing.
> 
> I agree 1 is different  from disabling the pre-allocating.
> But 1 is not enough in a system that needs to use MmMp multiple times
> in a single SMI.
> 
>>
>>>     I prefer this
>>>     pre-allocating is activated by default given the reason #1.
>>>
>>> 64 * 32/64 (SPIN LOCK size) = 2KB/4KB is not a big size.
>>
>> Would it be possible to *not* produce the MM MP protocol at all, if the
>> PCD were 0? Because in that case, the DEC default for the PCD could be
>> 64 (or any other value), and in OVMF we could set the PCD in the DSC
>> file to zero. 
> 
> Back to your suggestion, I am a bit curious why you prefer to have a
> PCD to turn on/off MmMp instead of pre-allocating 2KB/4KB memory.

I tend to perceive SMRAM as a "premium" (scarce) resource. I could be wrong.

> Any PCD introduces a cost that future developers needs to understand
> the meaning of the PCD and know how to set the PCD.

Yes, I agree about that.

But, at least, a PCD is a well-documented and explicit artifact. An
allocated, but never used memory (SMRAM) block may similarly raise
questions, *if* someone still remembers it later (or stumbles upon it).
Documenting the SMRAM block (in the right place) can be difficult too.
If we don't document it, then there seems to be no maintenance burden,
but that's actually the worst solution (obscure behavior).

Anyway I've said enough in this thread; please go ahead with the
solution you deem best.

Thanks
Laszlo