(cc'ing some folks whom I've discussed this with off-list today) Full discussion here: https://lore.kernel.org/linux-efi/20230113212926.2904735-1-dionnaglaze@xxxxxxxxxx/ On Mon, 16 Jan 2023 at 23:46, Tom Lendacky <thomas.lendacky@xxxxxxx> wrote: > > On 1/16/23 15:22, Dave Hansen wrote: > > On 1/16/23 02:56, Gerd Hoffmann wrote: > >>> And we add this protocol to address very temporary problem: once > >>> unaccepted memory support get upstream it is just a dead weight. > >> Maybe, maybe not. unaccepted memory support has a Kconfig switch after > >> all. If we figure in 3-5 years that all distros have enabled it anyway > >> we can drop it again. For the transition period it will surely be > >> useful. > > > > I agree with Kirill here. > > > > Having unaccepted memory *AND* this firmware-driven feature really is > > just implementing the same thing twice. > > I'm not sure I follow you. This feature merely tells the firmware whether > or not the OS supports unaccepted memory, which then tells the firmware > whether it needs to accept the memory or whether the kernel can. > > We have had SNP guest support since 5.19 without support for unaccepted > memory. Imagine now using a newer OVMF that can support unaccepted memory. > How does the firmware know whether it must accept all the memory or > whether it can advertise unaccepted memory. By having the kernel call this > boot service protocol once support for unaccepted memory is in place, the > firmware now knows that it need not accept all the memory. > So if people deploying SEV agree that this is a useful feature to have, and people working on TDX saying this protocol must never exist, I think the obvious conclusion is that OVMF should only expose it when running on SEV. However, I am still failing to grasp why there is disagreement here. Linux already implements SEV support but unaccepted memory protocol is not supported yet, and so it is crystal clear that we need something to bridge the compatibility gap. Without this protocol, firmware must never accept memory, and the OS must always take charge of this, even if it prefers to accept memory eagerly. With this protocol in place, acceptance becomes a policy decision, where the default policy is 'accept' for OS implementations that have no understanding of unaccepted memory or the protocol. 'Enlightened' OSes can still decide not to call the protocol and therefore not having to bother with acceptance at all, given that the firmware will take care of it. As for the 'legacy' boot method: this bootloader can decide for itself whether or not it needs to invoke the protocol, and can invent its own methods for communicating/inspecting the OS image to obtain the information to base this decision on. This is outside of the scope of EFI. However, I also disagree with the binary 'no solution shall exist' vs 'a solution must cover every imaginable combination of bootloader and OS image': it makes sense to be pragmatic here, and limit ourselves to what people are actually deploying. And given the default behavior fo 'accept everything', the only penalty for ignoring the legacy bootloader case is a slower boot. I have been on the sidelines for most of the OVMF and Linux development regarding confidential compute, but where I did get involved, it was to try and reach consensus between the different technologies (including the ARM one), to avoid ending up with radical different approaches for doing the same thing. However, I guess we're at a point where SEV and TDX really want different solutions, so I think divergence might be the way to proceed.
