> Kirill's _initial_ patch does #1. If anyone desperately wants #2, they > have mechanisms available to make a kernel with only #1 approximate #2. > A user on that kernel could allocate and memset()ing a bunch of memory. > Or, they could have a firmware stub accept the memory before booting the > real kernel. > > It also doesn't rule out having a runtime knob or a boot parameter > implement #2. It's not a lot of code, but it involves new ABI. >
The new ABI is the safety problem. Without the new code, you have firmware that makes all but 3 GiB of memory unusable because it's classified as an unknown type. > However, *NONE* of this points me in the direction of saying that we > should have an OS/firmware protocol to negotiate whether the firmware or > OS does page acceptance other than the existing UEFI memory map bit. We know of distributions that are going to release SEV-SNP support without unaccepted memory support, and in so doing, tie the firmware's hands in trying to maintain safe behavior through a required default behavior of accepting all memory without explicit information from the OS in the form of this protocol. TDX support may also get released this way due to unexpected requirements from the linux community that push back Kirill's patches. They still haven't been thoroughly reviewed by a memory system expert, IIRC. -- -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98503): https://edk2.groups.io/g/devel/message/98503 Mute This Topic: https://groups.io/mt/96236145/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
