> > I still don't understand why we need to support every imaginable > > combination of firmware, bootloader and OS. Unaccepted memory only > > exists on a special kind of virtual machine, which provides very > > little added value unless you opt into the security and attestation > > features, which are all heavily based on firmware protocols. So why > > should care about a EFI-aware bootloader calling ExitBootServices() > > and subsequently doing a legacy boot of Linux on such systems? > > Why break what works? Some users want it. > The users that want legacy boot features will not be broken, they'll only get a safe view of the memory map. I don't think it's right to choose unsafe behavior for a legacy setup. > This patch adds complexity, breaks what works and the only upside will > turn into a dead weight soon. > > There's alternative to add option to instruct firmware to accept all > memory from VMM side. It will serve legacy OS that doesn't know about > unaccepted memory and it is also can be use by latency-sensitive users > later on (analog of qemu -mem-prealloc). > This means that users of a distro that has not enabled unaccepted memory support cannot simply start a VM with the usual command, but instead have to know a baroque extra flag to get access to all the memory that they configured the machine (and for a CSP customer, paid for). That's not a good experience. With GCE at least, you can't (shouldn't) associate the boot feature flag with a disk image because disks are mutable. If a customer upgrades their kernel after initially starting their VM, they can't remove the flag due to the way image annotations work. All of this headache goes away by adopting a small patch to the kernel that calls a 0-ary protocol interface and keeping safe acceptance behavior in the firmware. I think Gerd is right here that we should treat it as a transition feature that we can remove later. > -- > Kiryl Shutsemau / Kirill A. Shutemov -- -Dionna Glaze, PhD (she/her)
