From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web10.84152.1673611222506639016 for ; Fri, 13 Jan 2023 04:00:23 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=E7lQUnvr; spf=pass (domain: kernel.org, ip: 145.40.68.75, 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 ams.source.kernel.org (Postfix) with ESMTPS id 77474B8212D for ; Fri, 13 Jan 2023 12:00:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 266D8C433F2 for ; Fri, 13 Jan 2023 12:00:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673611219; bh=y6TUI4l/G7qmITVa11kY/dnQHngUZ4GrPUho2h/Bpgs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=E7lQUnvrp2bl648JSfmSSbY7m1Ae87duCeYSsZZhlT7Xm8AVmbzaivKDWg9vaNQ7R akEFqmnLiHTBoyZD0rY2wLGEhRz/HDUDibsi9OraiTpZNsJFWM2b1EH1XsBLVb8fMM ewI4Hlw/JHtKo2jdv/X7Iv4vtJIwr+go2NCxkPzT1X907m23wkWEaq3EYmepMlu5Iu GhS+5YZBwISKL/MNsoD5R8r18H5QqApgc0Z0go3dGe8lJjj0PHgIeJJiYw2d0MNF8I 3bnL77rDiMbAAjNf7grIBG7l/e9jAf2kQMtuUbFrB+LP4M4yvncLeoN6r1HqFWwZq2 v7suYwDwKWdNg== Received: by mail-lj1-f178.google.com with SMTP id f20so22243101lja.4 for ; Fri, 13 Jan 2023 04:00:19 -0800 (PST) X-Gm-Message-State: AFqh2kpcDRUx0aF/ugV/rAqohN9DoUKt3JuQOrz6zK+Kehkr8U+QI4JD oR22Q3BdOX1CdCsY8ConYzEI43hwjjL/y/P8ZLE= X-Google-Smtp-Source: AMrXdXtwi2V+WdklOB5DCTl2JF04HbKk2QtdOIc2PZ5vlNlTyTKhVwQExDBZT+v1vIp83dZ1SS13Qx1F5/FrOC9CDw4= X-Received: by 2002:a2e:98d2:0:b0:289:7fc6:e1d with SMTP id s18-20020a2e98d2000000b002897fc60e1dmr339246ljj.69.1673611217147; Fri, 13 Jan 2023 04:00:17 -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 13:00:05 +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:45, Yao, Jiewen wrote: > > Would you please send me the URL for the Linux patch? > > I would check with other OS people as well. > OK. I don't remember whether or not a patch was sent to the linux-efi list already. Dionna: can you please cc jiewen and edk2-devel when you (re)send it? Thanks. > > -----Original Message----- > > From: devel@edk2.groups.io On Behalf Of Ard > > Biesheuvel > > Sent: Friday, January 13, 2023 7:24 PM > > 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 > > > > Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory > > behavior > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >