public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"ardb@kernel.org" <ardb@kernel.org>
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 11:11:30 +0000	[thread overview]
Message-ID: <MW4PR11MB5872D184C9101DB977FDF2DB8CC29@MW4PR11MB5872.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAMj1kXF5uV75Opq2F2gFYD2iZa3U8LyOJ6JtjkwECS9tB9njpw@mail.gmail.com>

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?

Thank you
Yao, Jiewen


> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ard
> Biesheuvel
> Sent: Friday, January 13, 2023 5:32 PM
> To: devel@edk2.groups.io; Yao, Jiewen <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
> 
> 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
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 


  reply	other threads:[~2023-01-13 11:11 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
2023-01-13 11:11         ` Yao, Jiewen [this message]
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=MW4PR11MB5872D184C9101DB977FDF2DB8CC29@MW4PR11MB5872.namprd11.prod.outlook.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