Re: [edk2-devel] [PATCH v1 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Check BspIndex first before lock cmpxchg

["Ni, Ray" <ray.ni@intel.com>]

> This patch makes me uncomfortable. I understand what it intends to do,
> and the intent is not wrong, but we're again treating "volatile UINT32"
> as atomic, and non-reorderable against the
> InterlockedCompareExchange32(). This kind of "optimization" is what
> people write cautionary tales about, later. It would be nice to see a
> semi-formal *proof* that this cannot backfire.

Laszlo,
Thanks for the questions. I was OOO in the past 10 days for Chinese New Year.

From Chapter 9 "Multiple-Processor Management",
section 9.2.2 "Memory Ordering in P6 and More Recent Processor Families",
I read the following:

  In a single-processor system for memory regions defined as write-back cacheable,
  the memory ordering model respects the following principles...:
    * ...
    * Reads or writes cannot be reordered with I/O instructions, locked instructions, or serializing instructions.

So, it guarantees/proves "read of BspIndex" performs before "InterlockedCompareExchange32()/lock comxchg".

I think that can resolve one of your concern regarding the "ordering".

I don't quite understand your concern regarding the "atomic".


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115585): https://edk2.groups.io/g/devel/message/115585
Mute This Topic: https://groups.io/mt/104094808/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-