From: "Ard Biesheuvel" <ardb@kernel.org>
To: devel@edk2.groups.io, jiewen.yao@intel.com
Cc: Gerd Hoffmann <kraxel@redhat.com>,
Dionna Glaze <dionnaglaze@google.com>,
"Xu, Min M" <min.m.xu@intel.com>,
James Bottomley <jejb@linux.ibm.com>,
Tom Lendacky <Thomas.Lendacky@amd.com>,
"Aktas, Erdem" <erdemaktas@google.com>,
Andrew Fish <afish@apple.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory behavior
Date: Fri, 13 Jan 2023 10:32:01 +0100 [thread overview]
Message-ID: <CAMj1kXF5uV75Opq2F2gFYD2iZa3U8LyOJ6JtjkwECS9tB9njpw@mail.gmail.com> (raw)
In-Reply-To: <MW4PR11MB5872A91CAB3465C308126EAB8CC29@MW4PR11MB5872.namprd11.prod.outlook.com>
On Fri, 13 Jan 2023 at 08:33, Yao, Jiewen <jiewen.yao@intel.com> 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 <kraxel@redhat.com>
> > Sent: Friday, January 13, 2023 3:18 PM
> > To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>
> > Cc: Dionna Glaze <dionnaglaze@google.com>; Ard Biescheuvel
> > <ardb@kernel.org>; Xu, Min M <min.m.xu@intel.com>; James Bottomley
> > <jejb@linux.ibm.com>; Tom Lendacky <Thomas.Lendacky@amd.com>; Aktas,
> > Erdem <erdemaktas@google.com>; Andrew Fish <afish@apple.com>; Kinney,
> > Michael D <michael.d.kinney@intel.com>
> > 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
>
>
>
>
>
>
next prev parent reply other threads:[~2023-01-13 9:32 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 0:14 [PATCH v9 0/4] Add safe unaccepted memory behavior Dionna Glaze
2023-01-13 0:14 ` [PATCH v9 1/4] OvmfPkg: Introduce CocoDxe driver Dionna Glaze
2023-01-13 0:14 ` [PATCH v9 2/4] MdePkg: Introduce the MemoryAcceptance protocol Dionna Glaze
2023-01-13 0:14 ` [PATCH v9 3/4] OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe Dionna Glaze
2023-01-13 0:14 ` [PATCH v9 4/4] OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted Dionna Glaze
2023-01-13 3:46 ` [PATCH v9 0/4] Add safe unaccepted memory behavior Yao, Jiewen
2023-01-13 7:18 ` [edk2-devel] " Gerd Hoffmann
2023-01-13 7:32 ` Yao, Jiewen
2023-01-13 9:32 ` Ard Biesheuvel [this message]
2023-01-13 11:11 ` Yao, Jiewen
2023-01-13 11:24 ` Ard Biesheuvel
2023-01-13 11:44 ` Yao, Jiewen
2023-01-13 12:00 ` Ard Biesheuvel
2023-01-13 16:00 ` dave.hansen
2023-01-13 17:06 ` Dionna Glaze
2023-01-13 17:57 ` Dave Hansen
2023-01-13 18:23 ` Dionna Glaze
2023-01-13 18:34 ` Dave Hansen
2023-01-16 10:28 ` Gerd Hoffmann
2023-01-24 22:42 ` Lendacky, Thomas
2023-01-24 22:46 ` Dave Hansen
2023-01-25 9:01 ` Ard Biesheuvel
2023-01-25 9:18 ` Gerd Hoffmann
2023-01-25 11:44 ` Ard Biesheuvel
2023-01-25 12:10 ` Gerd Hoffmann
2023-01-25 14:52 ` Ard Biesheuvel
2023-01-25 16:56 ` Yao, Jiewen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMj1kXF5uV75Opq2F2gFYD2iZa3U8LyOJ6JtjkwECS9tB9njpw@mail.gmail.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox