This is very interesting. I am trying to involve the discussion to learn. I did some experiment. ----a.c---- // Copy EDKII MemoryFence() and as Laszlo said it's just a compiler fence. void

This is correct, alternatively you could have this: do { // Force re-reading *Address on every iteration CompilerFence (); Value = *Address; } while (Value == 0xFF); //

I can say about the MemoryFence() calls I've added, and about the ones Ankur is about to add, that we're aware of the data flow directions. We could certainly annotate every such location with either

I agree with this summary. Volatile using in MpInitLib or PiSmmCpu driver cannot be emitted because different CPU threads change the same memory content to synchronize with each other. I don’t quite

Right, I agree with everything you said thus far. (I don't claim to be an expert on this, of course.) CompilerFence() is a "better volatile" (for RAM only, not for MMIO), where we can allow the

Hi Nate, I have created the following Tianocore repositories: * edk2-edkrepo * edk2-edkrepo-manifest I have added you and Ashley to the EDK II Tools Maintainers team with write access to both of

Yep, the point on volatile is pretty much correct. An object that has the volatile type qualifier may be manipulated in ways unknown to the implementation (the compiler) and, therefore, the

Laszlo, Thanks for looking into this. I noticed most of the MemoryFence() usage[1] is in the virtual platforms so changes seem manageable. I guess 3rd party code that defines its own low level

No, LFENCE and SFENCE are only useful with special load and store instructions and are not needed in edk2. In addition, neither of the two orders earlier stores against subsequent loads; MFENCE is

I agree with Ard (I'm not a contributor of EDK2 but thought I'd add my 2 sense anyway). `volatile` should only be used if a pointer load/store is utilized in a context where you expect the

Acquire fences are barriers between earlier loads and subsequent loads and stores; those earlier loads then synchronize with release stores in other threads. Release fences are barriers been earlier

Acquire semantics typically order writes before reads, not /between/ reads. Similarly, release semantics imply that all outstanding writes complete before a barrier with acquire semantics is permitted

Hi All, here's the declaration of MemoryFence(), from <BaseLib.h>: The IA32 and X64 implementations of MemoryFence() are not memory barriers, only compiler barriers, however. This is a problem for

From a RHEL perspective, I'd be okay with a nasm-2.15.03 version requirement. Thanks Laszlo

Hi All, This email is to collect feedback about update NASM version to 2.15.05 for build image. NASM (https://nasm.us/) is an assembler for the x86 CPU architecture platform. Current open CI is using

Hi All, I have shared some initial thoughts on the RNG implementation updates at

Hi Sami, I don't see any further discussions on this. Have you made any progress with sharing the design documents or scheduling a review? -- Rebecca Cran

Rebecca: My new mail address is Liming Gao <gaoliming@...>. It has updated in Maintainers.txt. Thanks Liming

By the way, I've started getting bounces from Liming's Intel email address. -- Rebecca Cran

Yes, that's fine with me. -- Rebecca Cran