[ add Tony who may care about the more-reliable removal ] Ard Biesheuvel wrote: > From: Ard Biesheuvel <ardb@xxxxxxxxxx> > > Between kexec and confidential VM support, handling the EFI memory maps > correctly on x86 is already proving to be rather difficult (as opposed > to other EFI architectures which manage to never modify the EFI memory > map to begin with) > > EFI fake memory map support is essentially a development hack (for > testing new support for the 'special purpose' and 'more reliable' EFI > memory attributes) that leaked into production code. The regions marked > in this manner are not actually recognized as such by the firmware > itself or the EFI stub (and never have), and marking memory as 'more > reliable' seems rather futile if the underlying memory is just ordinary > RAM. > > Marking memory as 'special purpose' in this way is also dubious, but may > be in use in production code nonetheless. However, the same should be > achievable by using the memmap= command line option with the ! operator. Ugh, sorry I missed this earlier. I only now just saw this bubble up in my inbox from the reply from Boris, but I have concerns with this removal. The problem is that what is and is not "special purpose" is a platform *and* use case policy. BIOS can only make a rough guess at platform manufacturing time, and certainly does not have use case information. One of the main reasons to prefer efi_fake_mem over memmap= is all of the end user hand holding needed to correct broken usage of memmap= https://nvdimm.wiki.kernel.org/how_to_choose_the_correct_memmap_kernel_parameter_for_pmem_on_your_system ...if anything I have been wanting to rip out memmap= more than efi_fake_mem just to cut down on the PEBKAC reports from memmap= users from the PMEM days. Those reports only died down because Optane died, but CXL is here now to revive that "fun". However, that said, maybe the safety properties of efi_fake_mem=nn@ss:0x40000 can be brought over to memmap=. The main property that protects end users is that the attribute only applies to existing EFI Conventional Memory ranges. So unlike memmap= that blindly replaces the memory map whether it makes sense or not, efi_fake_mem= would fail gracefully if the attribute was applied to nonsense ranges. > EFI fake memmap support is not enabled by any of the major distros > (Debian, Fedora, SUSE, Ubuntu) and does not exist on other > architectures, so let's drop support for it. I think part of the problem here is that platform with differentiated memory, (PMEM, HBM, CXL, etc...) have remained somewhat boutique since the introduction of this facility. As they become more ubiquitous, as trends seem to indicate, I think the frustration with BIOS policy may become more widespread. So we can remove it and see who screams, but we may want to put a work-alike safe option in memmap= first just to keep our own sanity.
