I have a working stack with proposal 5. I was using a version of grub that
didn't use Linux's EFI handover protocol, and I wasn't signalling the
unaccepted memory behavior at the right place (before EBS).

Many thanks to everyone who contributed to this discussion and brought some
creative ideas to the table. Thanks especially to Ard, for multiple
consultations.
With proposal 5, we won't need any control plane annotation for disabling
unaccepted memory, and users will always get safe behavior.

I'll have patches out to OVMF (based on this patch series) and to Linux
shortly.

On Mon, Aug 15, 2022 at 11:47 PM Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
>
> > 3.  fw_cfg
> >   - Add new fw_cfg item (opt/ovmf/AcceptAllMemory) to indicate how to
> handle the unaccepted memory.
> >       > True - accept all the memory
> >       > False - don't accept the memory
> >       > Default - It allows the firmware to choose depending on various
> factors.
> >   - Glaze has submit the patch
> https://lore.kernel.org/all/20220620223300.1555849-1-dionnaglaze@google.com/
>
> > Proposal 3) only works for QEMU because of fw_cfg.
>
> Well, while that is true for the patch at hand it doesn't have to be
> that way.  We can also simply store the config option in a EFI variable.
> Wire up a HII configuration so it can be changed via firmware setup.
> Allow setting the EFI variable from fw_cfg, so qemu users can set that
> on the qemu command line too (and possibly have similar mechanisms for
> other hypervisors, hello cloudhv).
>
> > I wonder if lazy-accept feature can be split into 2 stages.
> > 1. In first stage there is a config option to indicate if lazy-accept is
> enabled or not.
> > 2. In the second stage the automatic negotiation is introduced so that
> lazy-accept is enabled or not by the negotiation result.
>
> Absolutely.  That is one of the reasons why I suggested to have a
> true/false/default config option instead of just true/false.
>
> When the first stage is implemented "default" behavior would be fixed
> (either hard-coded or a compile-time option).
>
> When the second stage is implemented "default" behavior would be
> dynamic, depending on the negotiation result.
>
> take care,
>   Gerd
>
>

-- 
-Dionna Glaze, PhD (she/her)