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.83809.1673609076576721186 for ; Fri, 13 Jan 2023 03:24:36 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mW0MlK59; 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 CB3B261539 for ; Fri, 13 Jan 2023 11:24:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C242FC433F0 for ; Fri, 13 Jan 2023 11:24:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673609074; bh=qCaWv6lHNjVtmS/8MnAi3fUu6lZJhlEQCJIepyahtVw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=mW0MlK599vJ7+BaL6CySYcZ2bwK15PhC1aqoX2tX396yeDgoGp0ECBkMyBTnOSEaC vXkjRX8RvpxrmtCfToYA0IdRyMkRDh8xV0L1bE3mxUH2p2vaE8Y8DCYg/sSs99/oNx sUbcGOhXFCURwuZcY3Vtx8XZF5UkQNyajSmlDGauLg3iMn10xs2WhPhFPmGkIS0t3w fOmXMgzRamiiPeWXWdWvoDifwoep2pWMoQAI8A5+IDy7bqX/Udpz/gv9gCQcbNXr/h 9vUf2zqAqCgDTJ9QD/FklOBZLgd7azSvAK8t9iLVR54Cz5lvRigYZM+vc8Il/SNyKI kFnCWsv1+JKEQ== Received: by mail-lf1-f45.google.com with SMTP id m6so32659507lfj.11 for ; Fri, 13 Jan 2023 03:24:34 -0800 (PST) X-Gm-Message-State: AFqh2kpvd3chq6mBwwNayoUlmoCjN/Tpqxy2aSehnnlR0CVA/OyUlKXR JJWn3fmp7uOBeletm5lO2uFft8eclcbFHq65SHY= X-Google-Smtp-Source: AMrXdXtCUsm8dN52t3Y4lM2cKf2v5mmmp/UD04VI8mgBQhyRfAorzU+nL/dx0L1ikARyJjg8p44fkotVaMNxV3GxpLU= X-Received: by 2002:a05:6512:3d93:b0:4b8:9001:a694 with SMTP id k19-20020a0565123d9300b004b89001a694mr3889042lfv.426.1673609072708; Fri, 13 Jan 2023 03:24:32 -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 12:24:21 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory behavior To: "Yao, Jiewen" Cc: "devel@edk2.groups.io" , 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 12:11, Yao, Jiewen wrote: > > Sorry, that I did not say clearly. > > When I say: "sign-off", I mean the Linux community and the maintainer have reached the consensus and agree to merge the patch for OS. > > Would you please send to me the email from the maintainer, or the URL to record the conversation? > I am the maintainer. > > > -----Original Message----- > > From: devel@edk2.groups.io On Behalf Of Ard > > Biesheuvel > > Sent: Friday, January 13, 2023 5:32 PM > > To: devel@edk2.groups.io; Yao, Jiewen > > Cc: Gerd Hoffmann ; Dionna Glaze > > ; 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, 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 > > > > > > > > > > > > > > > > > > > > > > > > > > >