We make eager memory acceptance the default behavior at ExitBootServices
by using the standard-enforced behavior that if the call returns an
error code, then the map key is incorrect and the caller must re-call
GetMemoryMap to ensure the contents are correct.

Eager memory acceptance is implemented by using the UEFI v2.9-added
EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES to check a support condition
before changing all unaccepted memory type regions to conventional
memory after first using the MemoryAccept protocol to accept all memory
in each region. This update to the memory map only happens once, since
there are no extra unaccepted memory regions to change on the forced
second call to ExitBootServices.

The new acceptance logic is technology-agnostic and usable across TEE
technologies, so this patch series introduces a Confidenial Compute DXE
driver called CocoDxe.

To allow the OS loader to prevent the eager acceptance, and thus pass
the before-mentioned "support condition", we add a new protocol, up for
standardization, AcceptAllUnacceptedMemoryProtocol.
This protocol has one interface, Disable(). The OS loader can inform the
UEFI that it supports the unaccepted memory type and accepts the
responsibility to accept it.

The MemoryAcceptance protocol is necessary for safe rollout of the
unaccepted memory type, given the gradual update of guest OS kernels.
OVMF cannot rely on the following implication

  (MemEncryptSevIsEnabled () || MemEncryptTdxIsEnabled ())

  implies

  unaccepted memory is supported by the guest

This implication does not hold for e.g., upstream Linux, and will not
hold generally since both SEV-SNP and TDX define unaccepted memory
support as optional rather than required.

All images that support unaccepted memory must now locate and call this
new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and call the Disable
function.

Changes since v8:
 - First 3 patches removed since they were submitted separately.
 - Later patches rebased on edk2/master and modified to work with the
   current locations and namings of the unaccepted memory constants.
Changes since v7:
 - Rebased onto lazy accept v4 patch series, so memory accept protocol
   has the EDKII prefix, and the unaccepted memory type has the BZ3937
   prefix.
 - Removed a bad #include to a header removed in v7.
 - Renamed the protocol to BZ3987_MEMORY_ACCEPTANCE_PROTOCOL as per the
   discussion on the buganizer issue.
 - Uncrustify formatting

Changes since v6:
 - Added implementation of EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES.
 - Changed callback protocol of v5 to instead use the standardized event
   group for before_exit_boot_services.

Changes since v5:
 - Generic callback protocol moved to MdeModulePkg
 - Removed use of EFI_WARN_STALE_DATA and added comment that the callback
   should only return EFI_SUCCESS or EFI_INVALID_PARAMETER.
 - Removed errant log statement and fixed formatting.

Changes since v4:
 - Commit message wording
 - Replaced direct change to DxeMain with a more generic callback
   protocol.
 - Implemented the direct change as an instance of the callback protocol
   from a new CocoDxe driver.
 - Replaced "enable" protocol with a "disable" protocol, since the name
   was confusing. The AcceptAllUnacceptedMemory protocol directly names
   the behavior that is disabling.

Changes since v3:
 - "DxeMain accepts all memory" patch split into 3 to make each patch
   affect only one package at a time.

Changes since v2:
 - Removed the redundant memory accept interface and added the accept
   behavior to the DXE implementation of
   MemEncryptSevSnpPreValidateSystemRam.
 - Fixed missing #include in >=4GB patch.

Changes since v1:
 - Added a patch to classify SEV-SNP memory above 4GB unaccepted.
 - Fixed style problems in EfiMemoryAcceptProtocol implementation.

Cc: Ard Biescheuvel <ardb@kernel.org>
Cc: "Min M. Xu" <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Tom Lendacky <Thomas.Lendacky@amd.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Andrew Fish <afish@apple.com>
Cc: "Michael D. Kinney" <michael.d.kinney@intel.com>

Signed-off-by: Dionna Glaze <dionnaglaze@google.com>

Dionna Glaze (4):
  OvmfPkg: Introduce CocoDxe driver
  MdePkg: Introduce the MemoryAcceptance protocol
  OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe
  OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted

 MdePkg/Include/Protocol/MemoryAcceptance.h |  40 +++++
 MdePkg/MdePkg.dec                          |   3 +
 OvmfPkg/AmdSev/AmdSevX64.dsc               |   1 +
 OvmfPkg/AmdSev/AmdSevX64.fdf               |   1 +
 OvmfPkg/CocoDxe/CocoDxe.c                  | 175 +++++++++++++++++++++
 OvmfPkg/CocoDxe/CocoDxe.inf                |  46 ++++++
 OvmfPkg/IntelTdx/IntelTdxX64.dsc           |   1 +
 OvmfPkg/IntelTdx/IntelTdxX64.fdf           |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc                 |   1 +
 OvmfPkg/OvmfPkgIa32X64.fdf                 |   1 +
 OvmfPkg/OvmfPkgX64.dsc                     |   1 +
 OvmfPkg/OvmfPkgX64.fdf                     |   1 +
 OvmfPkg/PlatformPei/AmdSev.c               |   5 +
 13 files changed, 277 insertions(+)
 create mode 100644 MdePkg/Include/Protocol/MemoryAcceptance.h
 create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c
 create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf

-- 
2.39.0.314.g84b9a713c41-goog



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98402): https://edk2.groups.io/g/devel/message/98402
Mute This Topic: https://groups.io/mt/96236145/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

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.


Thank you
Yao, Jiewen

> -----Original Message-----
> From: Dionna Glaze <dionnaglaze@google.com>
> Sent: Friday, January 13, 2023 8:14 AM
> To: devel@edk2.groups.io
> Cc: Dionna Glaze <dionnaglaze@google.com>; Ard Biescheuvel
> <ardb@kernel.org>; Xu, Min M <min.m.xu@intel.com>; Gerd Hoffmann
> <kraxel@redhat.com>; James Bottomley <jejb@linux.ibm.com>; Tom
> Lendacky <Thomas.Lendacky@amd.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Aktas, Erdem <erdemaktas@google.com>; Andrew
> Fish <afish@apple.com>; Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: [PATCH v9 0/4] Add safe unaccepted memory behavior
> 
> We make eager memory acceptance the default behavior at ExitBootServices
> by using the standard-enforced behavior that if the call returns an
> error code, then the map key is incorrect and the caller must re-call
> GetMemoryMap to ensure the contents are correct.
> 
> Eager memory acceptance is implemented by using the UEFI v2.9-added
> EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES to check a support
> condition
> before changing all unaccepted memory type regions to conventional
> memory after first using the MemoryAccept protocol to accept all memory
> in each region. This update to the memory map only happens once, since
> there are no extra unaccepted memory regions to change on the forced
> second call to ExitBootServices.
> 
> The new acceptance logic is technology-agnostic and usable across TEE
> technologies, so this patch series introduces a Confidenial Compute DXE
> driver called CocoDxe.
> 
> To allow the OS loader to prevent the eager acceptance, and thus pass
> the before-mentioned "support condition", we add a new protocol, up for
> standardization, AcceptAllUnacceptedMemoryProtocol.
> This protocol has one interface, Disable(). The OS loader can inform the
> UEFI that it supports the unaccepted memory type and accepts the
> responsibility to accept it.
> 
> The MemoryAcceptance protocol is necessary for safe rollout of the
> unaccepted memory type, given the gradual update of guest OS kernels.
> OVMF cannot rely on the following implication
> 
>   (MemEncryptSevIsEnabled () || MemEncryptTdxIsEnabled ())
> 
>   implies
> 
>   unaccepted memory is supported by the guest
> 
> This implication does not hold for e.g., upstream Linux, and will not
> hold generally since both SEV-SNP and TDX define unaccepted memory
> support as optional rather than required.
> 
> All images that support unaccepted memory must now locate and call this
> new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and call the
> Disable
> function.
> 
> Changes since v8:
>  - First 3 patches removed since they were submitted separately.
>  - Later patches rebased on edk2/master and modified to work with the
>    current locations and namings of the unaccepted memory constants.
> Changes since v7:
>  - Rebased onto lazy accept v4 patch series, so memory accept protocol
>    has the EDKII prefix, and the unaccepted memory type has the BZ3937
>    prefix.
>  - Removed a bad #include to a header removed in v7.
>  - Renamed the protocol to BZ3987_MEMORY_ACCEPTANCE_PROTOCOL as
> per the
>    discussion on the buganizer issue.
>  - Uncrustify formatting
> 
> Changes since v6:
>  - Added implementation of
> EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES.
>  - Changed callback protocol of v5 to instead use the standardized event
>    group for before_exit_boot_services.
> 
> Changes since v5:
>  - Generic callback protocol moved to MdeModulePkg
>  - Removed use of EFI_WARN_STALE_DATA and added comment that the
> callback
>    should only return EFI_SUCCESS or EFI_INVALID_PARAMETER.
>  - Removed errant log statement and fixed formatting.
> 
> Changes since v4:
>  - Commit message wording
>  - Replaced direct change to DxeMain with a more generic callback
>    protocol.
>  - Implemented the direct change as an instance of the callback protocol
>    from a new CocoDxe driver.
>  - Replaced "enable" protocol with a "disable" protocol, since the name
>    was confusing. The AcceptAllUnacceptedMemory protocol directly names
>    the behavior that is disabling.
> 
> Changes since v3:
>  - "DxeMain accepts all memory" patch split into 3 to make each patch
>    affect only one package at a time.
> 
> Changes since v2:
>  - Removed the redundant memory accept interface and added the accept
>    behavior to the DXE implementation of
>    MemEncryptSevSnpPreValidateSystemRam.
>  - Fixed missing #include in >=4GB patch.
> 
> Changes since v1:
>  - Added a patch to classify SEV-SNP memory above 4GB unaccepted.
>  - Fixed style problems in EfiMemoryAcceptProtocol implementation.
> 
> Cc: Ard Biescheuvel <ardb@kernel.org>
> Cc: "Min M. Xu" <min.m.xu@intel.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: James Bottomley <jejb@linux.ibm.com>
> Cc: Tom Lendacky <Thomas.Lendacky@amd.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Erdem Aktas <erdemaktas@google.com>
> Cc: Andrew Fish <afish@apple.com>
> Cc: "Michael D. Kinney" <michael.d.kinney@intel.com>
> 
> Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
> 
> Dionna Glaze (4):
>   OvmfPkg: Introduce CocoDxe driver
>   MdePkg: Introduce the MemoryAcceptance protocol
>   OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe
>   OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted
> 
>  MdePkg/Include/Protocol/MemoryAcceptance.h |  40 +++++
>  MdePkg/MdePkg.dec                          |   3 +
>  OvmfPkg/AmdSev/AmdSevX64.dsc               |   1 +
>  OvmfPkg/AmdSev/AmdSevX64.fdf               |   1 +
>  OvmfPkg/CocoDxe/CocoDxe.c                  | 175 +++++++++++++++++++++
>  OvmfPkg/CocoDxe/CocoDxe.inf                |  46 ++++++
>  OvmfPkg/IntelTdx/IntelTdxX64.dsc           |   1 +
>  OvmfPkg/IntelTdx/IntelTdxX64.fdf           |   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc                 |   1 +
>  OvmfPkg/OvmfPkgIa32X64.fdf                 |   1 +
>  OvmfPkg/OvmfPkgX64.dsc                     |   1 +
>  OvmfPkg/OvmfPkgX64.fdf                     |   1 +
>  OvmfPkg/PlatformPei/AmdSev.c               |   5 +
>  13 files changed, 277 insertions(+)
>  create mode 100644 MdePkg/Include/Protocol/MemoryAcceptance.h
>  create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c
>  create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf
> 
> --
> 2.39.0.314.g84b9a713c41-goog



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98434): https://edk2.groups.io/g/devel/message/98434
Mute This Topic: https://groups.io/mt/96236145/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

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



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98451): https://edk2.groups.io/g/devel/message/98451
Mute This Topic: https://groups.io/mt/96236145/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

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.



> -----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



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98453): https://edk2.groups.io/g/devel/message/98453
Mute This Topic: https://groups.io/mt/96236145/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

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
>
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98463): https://edk2.groups.io/g/devel/message/98463
Mute This Topic: https://groups.io/mt/96236145/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

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
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98471): https://edk2.groups.io/g/devel/message/98471
Mute This Topic: https://groups.io/mt/96236145/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

On Fri, 13 Jan 2023 at 12:11, Yao, Jiewen <jiewen.yao@intel.com> 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 <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
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > 
> >
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98472): https://edk2.groups.io/g/devel/message/98472
Mute This Topic: https://groups.io/mt/96236145/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

Would you please send me the URL for the Linux patch?

I would check with other OS people as well.

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 7:24 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: devel@edk2.groups.io; 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 12:11, Yao, Jiewen <jiewen.yao@intel.com> 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 <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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98473): https://edk2.groups.io/g/devel/message/98473
Mute This Topic: https://groups.io/mt/96236145/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

On Fri, 13 Jan 2023 at 12:45, Yao, Jiewen <jiewen.yao@intel.com> 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 <devel@edk2.groups.io> On Behalf Of Ard
> > Biesheuvel
> > Sent: Friday, January 13, 2023 7:24 PM
> > To: Yao, Jiewen <jiewen.yao@intel.com>
> > Cc: devel@edk2.groups.io; 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 12:11, Yao, Jiewen <jiewen.yao@intel.com> 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 <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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> > 
> >
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98474): https://edk2.groups.io/g/devel/message/98474
Mute This Topic: https://groups.io/mt/96236145/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-