Ok, so that doesn't look as bad as I thought. But we'll have to be more strict than other arches: even EFI services and protocols that are marked as safe for execution under this MP protocol are likel

The code changes by itself look fine to me. The only problem I see is that we cannot run arbitrary code on other cores with the MMU off, given that in that case, they don't comply with the UEFI AArch6

Hello Jiewen, Thanks for writing this up. As you know, ARM is a bit behind in the CCA space, and so I will not be able to take part in these discussions in great detail. I will leave it to the contrib

If it matches the current spec definitional (however surprisingly), I am fine with the current proposal.

So the problem is secondary loaders that assume that all peripherals have been connected, right? To me, the options Minimal/All Network Devices/All Devices seems a bit arbitrary - what about block dev

This is an unfortunate oversight in the architecture, but RNDRRS most certainly does not return a true random number. RNDR and RNDRRS both return the output of a DRBG (pseudo RNG), and the only differ

I'd say it is because we are reasoning about how accesses to the data are ordered, not about the data itself.

Generally, yes. But I already mentioned non-cache coherent DMA devices, and we also have some ARM platforms that use non-shareable mappings for SRAM, which is used as temporary PEI memory in some case

<snip> I don't think the message passing paradigm is 100% accurate but it is very close. You should realize that a modern system is a network of CPUs, caches, DRAM controllers and other bus masters, w

We rely heavily on LTO for both Visual Studio and GNU/Clang toolchains.

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