回复: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
I have no more comments. Reviewed-by: Liming Gao for those changes. > -邮件原件- > 发件人: devel@edk2.groups.io 代表 Min Xu > 发送时间: 2022年10月26日 21:35 > 收件人: devel@edk2.groups.io; Gao, Liming ; > 'Dionna Amalie Glaze' > 抄送: Gao, Zhichao ; Ni, Ray ; > Aktas, Erdem ; 'Gerd Hoffmann' > ; 'James Bottomley' ; Yao, Jiewen > ; 'Tom Lendacky' ; > Gao, Jiaqi ; Wang, Jian J ; Liu, > Zhiguang ; Kinney, Michael D > ; 'Ard Biesheuvel' > 主题: Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > Tdx guest > > On October 26, 2022 9:27 AM, Gao Liming wrote: > > > > Min: > > Thanks for the update. I have no other comments for MdePkg changes in > > this patch set. > > > Hi, Liming > Below 5 patches are changes in MdePkg and MdeModulePkg. Can you give > "reviewed-by" if you have no other concerns? > > [PATCH V4 01/10] MdeModulePkg: Add PrePiHob.h > https://edk2.groups.io/g/devel/message/93671 > > [PATCH V4 02/10] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE > https://edk2.groups.io/g/devel/message/93672 > > [PATCH V4 04/10] MdePkg: Add UEFI Unaccepted memory definition > https://edk2.groups.io/g/devel/message/93674 > > [PATCH V4 05/10] MdeModulePkg: Update Dxe to handle unaccepted > memory type > https://edk2.groups.io/g/devel/message/93675 > > [PATCH V4 08/10] MdePkg: The prototype definition of > EdkiiMemoryAcceptProtocol > https://edk2.groups.io/g/devel/message/93678 > > Thanks > Min > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95788): https://edk2.groups.io/g/devel/message/95788 Mute This Topic: https://groups.io/mt/94700592/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
On October 26, 2022 9:27 AM, Gao Liming wrote: > > Min: > Thanks for the update. I have no other comments for MdePkg changes in > this patch set. > Hi, Liming Below 5 patches are changes in MdePkg and MdeModulePkg. Can you give "reviewed-by" if you have no other concerns? [PATCH V4 01/10] MdeModulePkg: Add PrePiHob.h https://edk2.groups.io/g/devel/message/93671 [PATCH V4 02/10] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE https://edk2.groups.io/g/devel/message/93672 [PATCH V4 04/10] MdePkg: Add UEFI Unaccepted memory definition https://edk2.groups.io/g/devel/message/93674 [PATCH V4 05/10] MdeModulePkg: Update Dxe to handle unaccepted memory type https://edk2.groups.io/g/devel/message/93675 [PATCH V4 08/10] MdePkg: The prototype definition of EdkiiMemoryAcceptProtocol https://edk2.groups.io/g/devel/message/93678 Thanks Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95609): https://edk2.groups.io/g/devel/message/95609 Mute This Topic: https://groups.io/mt/94581434/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
回复: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
Min: Thanks for the update. I have no other comments for MdePkg changes in this patch set. Thanks Liming > -邮件原件- > 发件人: devel@edk2.groups.io 代表 Min Xu > 发送时间: 2022年10月25日 9:08 > 收件人: Dionna Amalie Glaze ; Gao, Liming > > 抄送: devel@edk2.groups.io; Gao, Zhichao ; Ni, Ray > ; Aktas, Erdem ; Gerd > Hoffmann ; James Bottomley ; > Yao, Jiewen ; Tom Lendacky > ; Gao, Jiaqi ; Wang, Jian > J ; Liu, Zhiguang ; Kinney, > Michael D ; Ard Biesheuvel ; > Xu, Min M > 主题: Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > Tdx guest > > Hi, Liming > In Dionna's latest patch-sets the name of accept_all_unaccepted_memory > has been changed to BZ3987_MEMORY_ACCEPTANCE_PROTOCOL. > https://edk2.groups.io/g/devel/message/95525 > https://edk2.groups.io/g/devel/message/95530 > > So now these 2 protocols are named as > "BZ3987_MEMORY_ACCEPTANCE_PROTOCOL" and " > EDKII_MEMORY_ACCEPT_PROTOCOL". > Do you think they have addressed your concern? > > Thanks > Min > > > -Original Message- > > From: Dionna Amalie Glaze > > Sent: Friday, October 21, 2022 11:59 PM > > To: Xu, Min M > > Cc: devel@edk2.groups.io; Gao, Liming ; Gao, > > Zhichao ; Ni, Ray ; Aktas, > Erdem > > ; Gerd Hoffmann ; James > > Bottomley ; Yao, Jiewen ; > Tom > > Lendacky ; Gao, Jiaqi ; > > Wang, Jian J ; Liu, Zhiguang > > ; Kinney, Michael D > ; > > Ard Biesheuvel > > Subject: Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept > for > > Tdx guest > > > > > > Min: > > > > I understand that they are for the different purpose and usage. > > > > But, their protocol name are very similar. > > > Yes. They do look very similar. > > > > > > > If there is no better protocol name, I will also be fine. > > > Dionna, what's your thought? > > > > > > > The accept_all_unaccepted_memory name came from Ard's suggestion on > > an earlier patch series where I was using a Pcd. > > We're talking about the name over on the spec bug > > https://bugzilla.tianocore.org/show_bug.cgi?id=3987#c26 > > > > I think that any name concerning unaccepted memory is going to look a little > > same-y to others, so it's going to be troublesome if we require that they > > all > > strongly differ in name. I'm not strongly attached to the name, I just want > > to > > be conservative about what the name implies about the expected overall > > behavior of the system when that has not actually been decided upon. > > > > -- > > -Dionna Glaze, PhD (she/her) > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95586): https://edk2.groups.io/g/devel/message/95586 Mute This Topic: https://groups.io/mt/94573125/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
Hi, Liming In Dionna's latest patch-sets the name of accept_all_unaccepted_memory has been changed to BZ3987_MEMORY_ACCEPTANCE_PROTOCOL. https://edk2.groups.io/g/devel/message/95525 https://edk2.groups.io/g/devel/message/95530 So now these 2 protocols are named as "BZ3987_MEMORY_ACCEPTANCE_PROTOCOL" and " EDKII_MEMORY_ACCEPT_PROTOCOL". Do you think they have addressed your concern? Thanks Min > -Original Message- > From: Dionna Amalie Glaze > Sent: Friday, October 21, 2022 11:59 PM > To: Xu, Min M > Cc: devel@edk2.groups.io; Gao, Liming ; Gao, > Zhichao ; Ni, Ray ; Aktas, Erdem > ; Gerd Hoffmann ; James > Bottomley ; Yao, Jiewen ; Tom > Lendacky ; Gao, Jiaqi ; > Wang, Jian J ; Liu, Zhiguang > ; Kinney, Michael D ; > Ard Biesheuvel > Subject: Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > Tdx guest > > > > Min: > > > I understand that they are for the different purpose and usage. > > > But, their protocol name are very similar. > > Yes. They do look very similar. > > > > > If there is no better protocol name, I will also be fine. > > Dionna, what's your thought? > > > > The accept_all_unaccepted_memory name came from Ard's suggestion on > an earlier patch series where I was using a Pcd. > We're talking about the name over on the spec bug > https://bugzilla.tianocore.org/show_bug.cgi?id=3987#c26 > > I think that any name concerning unaccepted memory is going to look a little > same-y to others, so it's going to be troublesome if we require that they all > strongly differ in name. I'm not strongly attached to the name, I just want to > be conservative about what the name implies about the expected overall > behavior of the system when that has not actually been decided upon. > > -- > -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95545): https://edk2.groups.io/g/devel/message/95545 Mute This Topic: https://groups.io/mt/94423128/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
> > Min: > > I understand that they are for the different purpose and usage. But, their > > protocol name are very similar. > Yes. They do look very similar. > > > If there is no better protocol name, I will also be fine. > Dionna, what's your thought? > The accept_all_unaccepted_memory name came from Ard's suggestion on an earlier patch series where I was using a Pcd. We're talking about the name over on the spec bug https://bugzilla.tianocore.org/show_bug.cgi?id=3987#c26 I think that any name concerning unaccepted memory is going to look a little same-y to others, so it's going to be troublesome if we require that they all strongly differ in name. I'm not strongly attached to the name, I just want to be conservative about what the name implies about the expected overall behavior of the system when that has not actually been decided upon. -- -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95473): https://edk2.groups.io/g/devel/message/95473 Mute This Topic: https://groups.io/mt/94423128/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
On October 19, 2022 9:18 AM, Gao Liming wrote: > > Min: > I understand that they are for the different purpose and usage. But, their > protocol name are very similar. Yes. They do look very similar. > If there is no better protocol name, I will also be fine. Dionna, what's your thought? > > On October 10, 2022 10:28 AM, Gao Liming wrote: > > > > > > Min: > > > I have no comments for new unaccepted resource type and unaccepted > > gcd > > > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > > > > > For new protocol EfiMemoryAcceptProtocol, I see another patch > > > serial > > > https://edk2.groups.io/g/devel/message/94763 base on it to introduce > > > ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two > > protocols > > > be combined into one? > > > > > HI, Liming > > There are below discussions about your comments. > > https://edk2.groups.io/g/devel/message/94869 > > https://edk2.groups.io/g/devel/message/94944 > > https://edk2.groups.io/g/devel/message/95050 > > https://edk2.groups.io/g/devel/message/95109 > > > > Do you think these discussions address your comments? > > > > Thanks > > Min > > Thanks Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95356): https://edk2.groups.io/g/devel/message/95356 Mute This Topic: https://groups.io/mt/94423128/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
回复: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
Min: I understand that they are for the different purpose and usage. But, their protocol name are very similar. If there is no better protocol name, I will also be fine. Thanks Liming > -邮件原件- > 发件人: devel@edk2.groups.io 代表 Min Xu > 发送时间: 2022年10月18日 9:13 > 收件人: devel@edk2.groups.io; Gao, Liming > 抄送: Gao, Zhichao ; Ni, Ray ; > Aktas, Erdem ; 'Gerd Hoffmann' > ; 'James Bottomley' ; Yao, Jiewen > ; 'Tom Lendacky' ; > Gao, Jiaqi ; Wang, Jian J ; Liu, > Zhiguang ; Kinney, Michael D > > 主题: Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > Tdx guest > > On October 10, 2022 10:28 AM, Gao Liming wrote: > > > > Min: > > I have no comments for new unaccepted resource type and unaccepted > gcd > > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > > > For new protocol EfiMemoryAcceptProtocol, I see another patch serial > > https://edk2.groups.io/g/devel/message/94763 base on it to introduce > > ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two > protocols > > be combined into one? > > > HI, Liming > There are below discussions about your comments. > https://edk2.groups.io/g/devel/message/94869 > https://edk2.groups.io/g/devel/message/94944 > https://edk2.groups.io/g/devel/message/95050 > https://edk2.groups.io/g/devel/message/95109 > > Do you think these discussions address your comments? > > Thanks > Min > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95350): https://edk2.groups.io/g/devel/message/95350 Mute This Topic: https://groups.io/mt/94422345/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
On October 10, 2022 10:28 AM, Gao Liming wrote: > > Min: > I have no comments for new unaccepted resource type and unaccepted gcd > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > For new protocol EfiMemoryAcceptProtocol, I see another patch serial > https://edk2.groups.io/g/devel/message/94763 base on it to introduce > ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two protocols > be combined into one? > HI, Liming There are below discussions about your comments. https://edk2.groups.io/g/devel/message/94869 https://edk2.groups.io/g/devel/message/94944 https://edk2.groups.io/g/devel/message/95050 https://edk2.groups.io/g/devel/message/95109 Do you think these discussions address your comments? Thanks Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95303): https://edk2.groups.io/g/devel/message/95303 Mute This Topic: https://groups.io/mt/94229046/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
> The name of EDKII_MEMORY_ACCEPT_PROTOCOL indicates it is only used in edk2. Ah, yes I was basing my changes off probably a very old version of TDVF's patches that used the EFI_ naming convention, so folks looking at my branch might have been expecting that it'd be standardized. Cool. Just the one thing needed then. -- -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95109): https://edk2.groups.io/g/devel/message/95109 Mute This Topic: https://groups.io/mt/94229046/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
The name of EDKII_MEMORY_ACCEPT_PROTOCOL indicates it is only used in edk2. It's not going to be included in UEFI spec, at least in current stage. In our design of the protocol (EDKII_MEMORY_ACCEPT_PROTOCOL), it contains the function of EDKII_ACCEPT_MEMORY which is to accept the un-accepted memories based on the input address and size. We just want to make the protocol clear and straightforward. > -Original Message- > From: Dionna Amalie Glaze > Sent: Monday, October 10, 2022 11:51 PM > To: Ni, Ray > Cc: Xu, Min M ; devel@edk2.groups.io; Gao, Liming > ; Gao, Zhichao ; Aktas, > Erdem ; Gerd Hoffmann ; > James Bottomley ; Yao, Jiewen > ; Tom Lendacky ; Gao, > Jiaqi ; Wang, Jian J ; Liu, > Zhiguang ; Kinney, Michael D > > Subject: Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > Tdx guest > > > > > Can OS call AcceptMemory protocol for those ranges that are not accepted? > > > > AcceptMemory is not specified to avoid accepting previously accepted > memory. As I understand it, AcceptMemory is purely a hardware abstraction > layer for CC technologies inside the UEFI implementation. > It additionally is not meant to modify address spaces. Address space > modification happens around it. Gao has a point though, that the two could > be combined. I'm not sure if it's particularly helpful to expose AcceptMemory > to the OS. Exposing it I think would necessitate changing its semantics to be > safer, e.g., > > Use the insight that AcceptMemory is only used to accept full or partial > regions of unaccepted memory spaces: > > /** > * Accepts memory in page granularity from the beginning of a pointed-to > memory descriptor, and changes > * the type of the affected memory range to EfiConventionalMemory. > * > * @param[This] This A pointer to this protocol instance > * @param[AddressInSpace] An address within the memory descriptor from > which to accept pages. > * @param[NumPages] The amount of EFI_PAGE_SIZE blocks of memory to > accept from the memory > * descriptor's beginning and convert into EfiConventionalMemory. If pages > remain in the memory descriptor > * after acceptance, the remaining memory will start at the initial memory > descriptor's > * start address + NumPages * EFI_PAGE_SIZE > * with type EfiUnacceptedMemory. > * The changes to the memory map affect only the memory descriptor > named by AddressInSpace. > * > * Returns EFI_INVALID_PARAMETER if AddressInSpace names to a memory > descriptor that is not > * EfiUnacceptedMemory, or if the named memory descriptor is not at least > NumPages in size. > */ > EFI_STATUS EFIAPI AcceptFromMemorySpaceBeginning ( > IN ProtocolType *This, > IN EFI_VIRTUAL_ADDRESS AddressInSpace, > IN UINTN NumPages > ); > > /** > * To be called by the OS loader to indicate that it supports and accepts > responsibility for EfiUnacceptedMemory. > * > * Without calling this function, ExitBootServices will accept all unaccepted > memory before returning. This > * behavior maintains safety for OSes that do not support unaccepted > memory or know of this protocol. > */ > VOID EFIAPI DisableAcceptAllOnExitBootServices (IN ProtocolType *This); > > I think this could be a fine protocol to expose to the OS loader since it > would > be safer written this way, albeit AcceptFromMemorySpaceBeginning is rather > redundant for the behavior that the OS would need to implement if it calls > the disable function. > > I'm not too pleased about the naming behavior, but I also don't really like > requiring the interface to only accept the start address of any particular > memory descriptor. That's a matter of taste though. The implementation of > the memory descriptor search would not be much more complicated than a > couple inequality checks instead of a single equality check. > > I don't think it's worth the effort in this interface to allow an arbitrary > range > that could split a single memory descriptor into at most three instead of at > most two, since it is logic I don't think would be readily exercised. Given > that > we're talking about calling this function given knowledge of the MemoryMap, > and that the MemoryMap should be condensed to not have separate > memory descriptors that could be coalesced, I think the limitation that > NumPages fits within the single descriptor is reasonable. > > All this being said, what's the value of combining the protocols? One fewer > header and guid? I honestly don't know since I haven't been around long > enough to understand how these kinds of things evolve and create possible > warts. > > If it's just two two things though, I think a header and guid are worth > avoiding conf
Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
> > Can OS call AcceptMemory protocol for those ranges that are not accepted? > AcceptMemory is not specified to avoid accepting previously accepted memory. As I understand it, AcceptMemory is purely a hardware abstraction layer for CC technologies inside the UEFI implementation. It additionally is not meant to modify address spaces. Address space modification happens around it. Gao has a point though, that the two could be combined. I'm not sure if it's particularly helpful to expose AcceptMemory to the OS. Exposing it I think would necessitate changing its semantics to be safer, e.g., Use the insight that AcceptMemory is only used to accept full or partial regions of unaccepted memory spaces: /** * Accepts memory in page granularity from the beginning of a pointed-to memory descriptor, and changes * the type of the affected memory range to EfiConventionalMemory. * * @param[This] This A pointer to this protocol instance * @param[AddressInSpace] An address within the memory descriptor from which to accept pages. * @param[NumPages] The amount of EFI_PAGE_SIZE blocks of memory to accept from the memory * descriptor's beginning and convert into EfiConventionalMemory. If pages remain in the memory descriptor * after acceptance, the remaining memory will start at the initial memory descriptor's * start address + NumPages * EFI_PAGE_SIZE * with type EfiUnacceptedMemory. * The changes to the memory map affect only the memory descriptor named by AddressInSpace. * * Returns EFI_INVALID_PARAMETER if AddressInSpace names to a memory descriptor that is not * EfiUnacceptedMemory, or if the named memory descriptor is not at least NumPages in size. */ EFI_STATUS EFIAPI AcceptFromMemorySpaceBeginning ( IN ProtocolType *This, IN EFI_VIRTUAL_ADDRESS AddressInSpace, IN UINTN NumPages ); /** * To be called by the OS loader to indicate that it supports and accepts responsibility for EfiUnacceptedMemory. * * Without calling this function, ExitBootServices will accept all unaccepted memory before returning. This * behavior maintains safety for OSes that do not support unaccepted memory or know of this protocol. */ VOID EFIAPI DisableAcceptAllOnExitBootServices (IN ProtocolType *This); I think this could be a fine protocol to expose to the OS loader since it would be safer written this way, albeit AcceptFromMemorySpaceBeginning is rather redundant for the behavior that the OS would need to implement if it calls the disable function. I'm not too pleased about the naming behavior, but I also don't really like requiring the interface to only accept the start address of any particular memory descriptor. That's a matter of taste though. The implementation of the memory descriptor search would not be much more complicated than a couple inequality checks instead of a single equality check. I don't think it's worth the effort in this interface to allow an arbitrary range that could split a single memory descriptor into at most three instead of at most two, since it is logic I don't think would be readily exercised. Given that we're talking about calling this function given knowledge of the MemoryMap, and that the MemoryMap should be condensed to not have separate memory descriptors that could be coalesced, I think the limitation that NumPages fits within the single descriptor is reasonable. All this being said, what's the value of combining the protocols? One fewer header and guid? I honestly don't know since I haven't been around long enough to understand how these kinds of things evolve and create possible warts. If it's just two two things though, I think a header and guid are worth avoiding confusion by exposing AcceptMemory unnecessarily. > > -Original Message- > > From: Xu, Min M > > Sent: Monday, October 10, 2022 11:08 AM > > To: devel@edk2.groups.io; Dionna Amalie Glaze ; > > Gao, Liming > > Cc: Gao, Zhichao ; Ni, Ray ; > > Aktas, Erdem ; 'Gerd Hoffmann' > > ; 'James Bottomley' ; Yao, > > Jiewen ; 'Tom Lendacky' > > ; Gao, Jiaqi ; Wang, Jian > > J ; Liu, Zhiguang ; Kinney, > > Michael D ; Xu, Min M > > Subject: RE: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > > Tdx guest > > > > On October 10, 2022 10:28 AM, Gao Liming wrote: > > > > > > Min: > > > I have no comments for new unaccepted resource type and unaccepted > > gcd > > > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > > > > > For new protocol EfiMemoryAcceptProtocol, I see another patch serial > > > https://edk2.groups.io/g/devel/message/94763 base on it to introduce > > > ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two > > protocols > > > be combined into one? > > > > > EfiMemoryAcceptProtocol looks like this: > > typedef > > EFI_STATUS >
Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
Can OS call AcceptMemory protocol for those ranges that are not accepted? > -Original Message- > From: Xu, Min M > Sent: Monday, October 10, 2022 11:08 AM > To: devel@edk2.groups.io; Dionna Amalie Glaze ; > Gao, Liming > Cc: Gao, Zhichao ; Ni, Ray ; > Aktas, Erdem ; 'Gerd Hoffmann' > ; 'James Bottomley' ; Yao, > Jiewen ; 'Tom Lendacky' > ; Gao, Jiaqi ; Wang, Jian > J ; Liu, Zhiguang ; Kinney, > Michael D ; Xu, Min M > Subject: RE: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > Tdx guest > > On October 10, 2022 10:28 AM, Gao Liming wrote: > > > > Min: > > I have no comments for new unaccepted resource type and unaccepted > gcd > > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > > > For new protocol EfiMemoryAcceptProtocol, I see another patch serial > > https://edk2.groups.io/g/devel/message/94763 base on it to introduce > > ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two > protocols > > be combined into one? > > > EfiMemoryAcceptProtocol looks like this: > typedef > EFI_STATUS > (EFIAPI *EDKII_ACCEPT_MEMORY)( > IN EDKII_MEMORY_ACCEPT_PROTOCOL *This, > IN EFI_PHYSICAL_ADDRESS StartAddress, > IN UINTN Size > ); > This protocol is called to accept the memory based on the input start address > and size. > > While ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL looks like below: > typedef > EFI_STATUS > (EFIAPI *BZ3987_DISABLE_ACCEPT_ALL_UNACCEPTED_MEMORY)( > IN BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL *This > ); > According to its description (https://edk2.groups.io/g/devel/message/94768) > this protocol is used to disable the behavior of accepting all unaccepted > memory. And it is designed to be called by the OS loader, not EDK2 itself. > > I am afraid these 2 protocols cannot be combined into one. > > Dionna what's your thought? > > Thanks > Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94870): https://edk2.groups.io/g/devel/message/94870 Mute This Topic: https://groups.io/mt/94229046/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
On October 10, 2022 10:28 AM, Gao Liming wrote: > > Min: > I have no comments for new unaccepted resource type and unaccepted gcd > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > For new protocol EfiMemoryAcceptProtocol, I see another patch serial > https://edk2.groups.io/g/devel/message/94763 base on it to introduce > ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two protocols > be combined into one? > EfiMemoryAcceptProtocol looks like this: typedef EFI_STATUS (EFIAPI *EDKII_ACCEPT_MEMORY)( IN EDKII_MEMORY_ACCEPT_PROTOCOL *This, IN EFI_PHYSICAL_ADDRESS StartAddress, IN UINTN Size ); This protocol is called to accept the memory based on the input start address and size. While ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL looks like below: typedef EFI_STATUS (EFIAPI *BZ3987_DISABLE_ACCEPT_ALL_UNACCEPTED_MEMORY)( IN BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL *This ); According to its description (https://edk2.groups.io/g/devel/message/94768) this protocol is used to disable the behavior of accepting all unaccepted memory. And it is designed to be called by the OS loader, not EDK2 itself. I am afraid these 2 protocols cannot be combined into one. Dionna what's your thought? Thanks Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94869): https://edk2.groups.io/g/devel/message/94869 Mute This Topic: https://groups.io/mt/94229046/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
Min: I have no comments for new unaccepted resource type and unaccepted gcd type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. For new protocol EfiMemoryAcceptProtocol, I see another patch serial https://edk2.groups.io/g/devel/message/94763 base on it to introduce ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two protocols be combined into one? Thanks Liming > -邮件原件- > 发件人: Xu, Min M > 发送时间: 2022年9月29日 14:57 > 收件人: devel@edk2.groups.io; Gao, Liming ; > Wang, Jian J ; Liu, Zhiguang > ; Kinney, Michael D > 抄送: Gao, Zhichao ; Ni, Ray ; > Aktas, Erdem ; Gerd Hoffmann > ; James Bottomley ; Yao, Jiewen > ; Tom Lendacky ; Gao, > Jiaqi > 主题: RE: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest > > On September 22, 2022 1:25 PM, Min Xu wrote: > > > > Hi, Liming/Jian/Zhiguang/Michael > > Can you help to review below patches for the lazy-accept feature? Because > > you're the maintainer/reviewer of the related modules. > > Any comment is welcome. > > > There is still no comments received since last notification. Can > Liming/Jian/Zhiguang/Michael provide your review comments about the > lazy-accept feature? > > > > [PATCH V4 01/10] MdeModulePkg: Add PrePiHob.h > > https://edk2.groups.io/g/devel/message/93671 > > > > [PATCH V4 02/10] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE > > https://edk2.groups.io/g/devel/message/93672 > > > > [PATCH V4 04/10] MdePkg: Add UEFI Unaccepted memory definition > > https://edk2.groups.io/g/devel/message/93674 > > > > [PATCH V4 05/10] MdeModulePkg: Update Dxe to handle unaccepted > > memory type > > https://edk2.groups.io/g/devel/message/93675 > > > > [PATCH V4 08/10] MdePkg: The prototype definition of > > EdkiiMemoryAcceptProtocol > > https://edk2.groups.io/g/devel/message/93678 > > > > Thanks much! > Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94860): https://edk2.groups.io/g/devel/message/94860 Mute This Topic: https://groups.io/mt/94229046/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
