From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by mx.groups.io with SMTP id smtpd.web09.169.1663878556537010374 for ; Thu, 22 Sep 2022 13:29:16 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@google.com header.s=20210112 header.b=bWuH3jQ5; spf=pass (domain: google.com, ip: 209.85.218.44, mailfrom: dionnaglaze@google.com) Received: by mail-ej1-f44.google.com with SMTP id sd10so15241773ejc.2 for ; Thu, 22 Sep 2022 13:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=AABFIJYvdgb4H+9kfwMVjFJr77UWU84jcJatB7QxL8c=; b=bWuH3jQ5jIutFU7YSNDzVwd1IX+cbp9+yZtk8AvL42UPg4QzXmpJRFxLNvGbI+jgxo 0Ckz6U8/gDkzAZHVhAzETsowEpakHSvCuA0J41z41iNQG8GWi6nDxZVNC8BWmbIUnwr4 mHyFeTcjdDVQwm9MK2gMmJMw0eiDQrQaoNdLDtbq1+2L09AL0Dyf5d31FlAe78I7x2nU VBpYWAiUZdKqAEoNqioG+gjrgnzYjouhMl54SDDhIbVLTurI4YC0DuveRDFo1aXYP1oF 7aPoqU1tP69yOtIzQ9lDqKTXotHgk9sPG1zLlJy9wKaOw7JSgngXO9qZzmNPLFs7iS0X DrKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=AABFIJYvdgb4H+9kfwMVjFJr77UWU84jcJatB7QxL8c=; b=GRGF4InFBKO3n9BniCy2ypxgNdYKVQQeA8+LdLnlYEN2AbiDGOAYHawHiHSycgZyQE 9P3a6tczxItpKm2gfOCkKuk3BvgLMaYyAIKnKhMdLCMqmxwjTSpjwtwMIl2gg72RDQum 6iEZgYfPbnCmlyLBprRNrEqgsLtpRmb7IwE7hTsOX2L7z24okaRJzL1K4kS8JXn7BqCg Log87+nSFPRrNJMRmn2aUUGA1cIKc2b4nCVPRMbQPIQtSz+WK0X5W7rzw7vXYeHQ0nFL RY951kjDJ90eU/SF+hR5cM7hddBeilLK28NqRsKuNjTPADtG9diKDY5p+biGYu2QS/R5 N7Aw== X-Gm-Message-State: ACrzQf2/V2jYag2gQxp9wrjJkYzlCjedtDdARaE0sb+2xZlThHb3iX1A 6SeXKWtzxgufvZ67kv7g7EPwyTDz/31G9nHFntslyw== X-Google-Smtp-Source: AMsMyM4L0LXsFH+ygj6UfzTrG4qpPN6qyaRobCXNj84MPp1dh0rJItmXqB3+fVJNzqYYHQ/lrQT0VhsC1UnHoBacbp0= X-Received: by 2002:a17:907:8a0b:b0:77a:be0e:f19c with SMTP id sc11-20020a1709078a0b00b0077abe0ef19cmr4280062ejc.397.1663878554819; Thu, 22 Sep 2022 13:29:14 -0700 (PDT) MIME-Version: 1.0 References: <20220816064720.exlc72y4fbzlhh2n@sirius.home.kraxel.org> In-Reply-To: <20220816064720.exlc72y4fbzlhh2n@sirius.home.kraxel.org> From: "Dionna Glaze" Date: Thu, 22 Sep 2022 13:29:03 -0700 Message-ID: Subject: Re: [PATCH 00/14] Introduce Lazy-accept for Tdx guest To: Gerd Hoffmann Cc: "Xu, Min M" , "devel@edk2.groups.io" , "Kinney, Michael D" , "Gao, Liming" , "Aktas, Erdem" , James Bottomley , "Yao, Jiewen" , Tom Lendacky , "Gao, Jiaqi" , "Li, Xiaoyao" , "Yamahata, Isaku" , Ard Biesheuvel Content-Type: multipart/alternative; boundary="0000000000003663a305e949ea80" --0000000000003663a305e949ea80 Content-Type: text/plain; charset="UTF-8" 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 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) --0000000000003663a305e949ea80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have a working stack with proposal 5. I was using a vers= ion of grub that didn't use Linux's EFI handover protocol, and I wa= sn't signalling the unaccepted memory behavior at the right place (befo= re 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 us= ers will always get safe behavior.

I'll have p= atches 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:
=C2=A0 Hi,

> 3.=C2=A0 fw_cfg
>=C2=A0 =C2=A0- Add new fw_cfg item (opt/ovmf/AcceptAllMemory) to indica= te how to handle the unaccepted memory.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> True - accept all the memory
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> False - don't accept the memory
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Default - It allows the firmware to cho= ose depending on various factors.
>=C2=A0 =C2=A0- 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.=C2=A0 We can also simply store the config option in a EFI variabl= e.
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.=C2=A0 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 f= ixed
(either hard-coded or a compile-time option).

When the second stage is implemented "default" behavior would be<= br> dynamic, depending on the negotiation result.

take care,
=C2=A0 Gerd



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