From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.82301.1673602336843142427 for ; Fri, 13 Jan 2023 01:32:17 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=b1LN6J7L; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2A7E461127 for ; Fri, 13 Jan 2023 09:32:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C028C4339B for ; Fri, 13 Jan 2023 09:32:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673602335; bh=Zfqe5gotR23oz13c93QpXl6YetqtwLyjmgrKQ2Yj8Vc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=b1LN6J7Lr+zpKl0FUSL1QGRtO2kakUVl4GvZ2WUB2uyCKqWKfx17rW7cZg57ZF+Jo TQgy/cHyiYJZyNd7zJVQF+9SS2c06EttOmIHARrR90w4c3wFRBU0J2DMNBsSaLPDZw W2YoSffCOiP0uU9oxh2EYVylu4b5AW615LYavclMBOLeTSp44SKereceqKRyyImG9A fZ/fI2POQomAhkwer4ByGE7olLOleC6CBB6PpX7UxI/VVa9I05L1czNDSXvFm3HFpP xzcABarf6EMqDRoZun6xSTEUfMMzBvjnLThWyKnula+v9jcckKOXe2VbvAKwRgSvw3 adEaw6cOriEZw== Received: by mail-lf1-f42.google.com with SMTP id g13so32302824lfv.7 for ; Fri, 13 Jan 2023 01:32:14 -0800 (PST) X-Gm-Message-State: AFqh2kolMPjUihC/G9MZS429/sWhS/ntWsUqlJIA9R9fMBDXQEDMAMX1 lWdMpPLK+jJuF7qAoqJbO/2FeKdY4WLdcsWLw/Q= X-Google-Smtp-Source: AMrXdXvW1jPHxp7I548H9BmVwoPnIHOyAhKxPjk5bYesReN0okbPg3ZHQQcm25VJDb8bFsekzgkfniI0y520JvTvfDM= X-Received: by 2002:ac2:5dfa:0:b0:4b7:3a0:45d2 with SMTP id z26-20020ac25dfa000000b004b703a045d2mr4229927lfq.228.1673602333000; Fri, 13 Jan 2023 01:32:13 -0800 (PST) MIME-Version: 1.0 References: <20230113001419.2519031-1-dionnaglaze@google.com> <20230113071826.l4636jwkn36nuo2a@sirius.home.kraxel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Fri, 13 Jan 2023 10:32:01 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory behavior To: devel@edk2.groups.io, jiewen.yao@intel.com Cc: Gerd Hoffmann , Dionna Glaze , "Xu, Min M" , James Bottomley , Tom Lendacky , "Aktas, Erdem" , Andrew Fish , "Kinney, Michael D" Content-Type: text/plain; charset="UTF-8" On Fri, 13 Jan 2023 at 08:33, Yao, Jiewen wrote: > > This is API between BIOS and OS. > > I would like to see sign-off from OS side at least, before we can merge to EDKII main. > I have already indicated (and am happy to repeat here) that for Linux, I am fine with this approach, if it amounts to locating a protocol and invoking it to inform the firmware that it doesn't need to accept all available memory. Once we phase out the eager accept from the firmware entirely, we can remove the protocol as well, and the OS loader will look for it and simply not find it. > > > > -----Original Message----- > > From: Gerd Hoffmann > > Sent: Friday, January 13, 2023 3:18 PM > > To: devel@edk2.groups.io; Yao, Jiewen > > Cc: Dionna Glaze ; Ard Biescheuvel > > ; Xu, Min M ; James Bottomley > > ; Tom Lendacky ; Aktas, > > Erdem ; Andrew Fish ; Kinney, > > Michael D > > Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory > > behavior > > > > On Fri, Jan 13, 2023 at 03:46:34AM +0000, Yao, Jiewen wrote: > > > Hi Dionna > > > I think I understand your intention. > > > I believe we need OS side and UEFI standard sign-off for this > > *BZ3987_MEMORY_ACCEPTANCE_PROTOCOL*, because OS is the consumer, > > right? > > > If so, I suggest you maintain the work in a edk2-stage area for > > https://github.com/tianocore/edk2-staging. > > > > > > EDKII main branch is for production. MdePkg can only include the API > > definition approved by UEFI standard. > > > EDK2 staging is a place for POC / collaboration. That is why I think edk2 > > staging is more proper place for this feature. > > > > > > Without OS and UEFI standard sign-off, I don't think this > > BZ3987_MEMORY_ACCEPTANCE_PROTOCOL can be integrated to EDKII main > > branch, especially in MdePkg/Include/Protocol/MemoryAcceptance.h. > > > > Ok. Reading through the bug (comment 53) it looks like Intel's take on > > this is that it will simply not be needed long-term. > > > > How about adding it to OvmfPkg/Include/Protocol/MemoryAcceptance.h > > then? > > > > It surely will be very useful short-term. If it turns out that lazy > > accept support indeed becomes a standard feature we might drop this > > in 3-5 years. Or promote it to MdePkg should that not be the case. > > > > take care, > > Gerd > > > > > >