Jiewen: New SpeculationBarrier() will be for all ARCHs. IA32 and X64 implementation will be same to AsmLfence(). ARM and AARCH64 will have their own implementation. Right?
After this API is added, the consumer code to use AsmLfence() can be updated to use SpeculationBarrier(). Thanks Liming >-----Original Message----- >From: Yao, Jiewen >Sent: Tuesday, December 18, 2018 10:08 AM >To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Wu, Hao A ><hao.a...@intel.com> >Cc: edk2-devel@lists.01.org; Gao, Liming <liming....@intel.com>; Zhang, >Chao B <chao.b.zh...@intel.com> >Subject: RE: [edk2] [PATCH 05/13] MdePkg/Library/BaseLib/AArch64: Add >AsmLfence function > >+ Wu Hao, since he contributed the original patch. > >Ard >Would you please file a Bugzilla for that? Then we can start working on that. > >Thank you >Yao Jiewen > >> -----Original Message----- >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >> Sent: Monday, December 17, 2018 5:28 PM >> To: Yao, Jiewen <jiewen....@intel.com> >> Cc: edk2-devel@lists.01.org; Gao, Liming <liming....@intel.com>; Zhang, >> Chao B <chao.b.zh...@intel.com> >> Subject: Re: [edk2] [PATCH 05/13] MdePkg/Library/BaseLib/AArch64: Add >> AsmLfence function >> >> On Mon, 17 Dec 2018 at 09:44, Yao, Jiewen <jiewen....@intel.com> wrote: >> > >> > Thanks Ard. >> > I have little concern about "Spec", because people may read it as >> "Specification", especially in our team. :) >> > >> >> I understand :-) >> >> SpeculationBarrier() is fine with me. >> >> >> > >> > > -----Original Message----- >> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf >> Of >> > > Ard Biesheuvel >> > > Sent: Monday, December 17, 2018 4:35 PM >> > > To: Yao, Jiewen <jiewen....@intel.com> >> > > Cc: edk2-devel@lists.01.org; Gao, Liming <liming....@intel.com>; >> Zhang, >> > > Chao B <chao.b.zh...@intel.com> >> > > Subject: Re: [edk2] [PATCH 05/13] MdePkg/Library/BaseLib/AArch64: >> Add >> > > AsmLfence function >> > > >> > > On Mon, 17 Dec 2018 at 09:30, Yao, Jiewen <jiewen....@intel.com> >> wrote: >> > > > >> > > > I reviewed the ARM white paper - >> > > >> file:///C:/Users/jyao1/Downloads/Cache_Speculation_Side-channels-v2.4.p >> > > df >> > > > >> > > > I agree with you that LoadFence might not be the best idea. >> > > > >> > > > How about SpeculationBarrier() ? >> > > > >> > > >> > > That works for me. Or SpecFence (). As long as it does not conflate >> > > memory ordering with controlling the side effects of speculative >> > > execution, it is ok with me. >> > > >> > > I'll contribute the ARM and AARCH64 implementations asap once the >> > > generic changes are posted on the list. >> > > >> > > Thanks, >> > > >> > > > > -----Original Message----- >> > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On >> Behalf >> > > Of >> > > > > Yao, Jiewen >> > > > > Sent: Monday, December 17, 2018 4:25 PM >> > > > > To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Leif Lindholm >> > > > > <leif.lindh...@linaro.org> >> > > > > Cc: edk2-devel@lists.01.org; Zhang, Chao B >> <chao.b.zh...@intel.com>; >> > > > > Gao, Liming <liming....@intel.com> >> > > > > Subject: Re: [edk2] [PATCH 05/13] MdePkg/Library/BaseLib/AArch64: >> > > Add >> > > > > AsmLfence function >> > > > > >> > > > > Hi Ard >> > > > > I am OK to refine it now. >> > > > > >> > > > > Do you have any proposal on the naming from ARM side? >> > > > > >> > > > > Thank you >> > > > > Yao Jiewen >> > > > > >> > > > > > -----Original Message----- >> > > > > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >> > > > > > Sent: Monday, December 17, 2018 4:11 PM >> > > > > > To: Yao, Jiewen <jiewen....@intel.com>; Leif Lindholm >> > > > > > <leif.lindh...@linaro.org> >> > > > > > Cc: Gao, Liming <liming....@intel.com>; Jagadeesh Ujja >> > > > > > <jagadeesh.u...@arm.com>; edk2-devel@lists.01.org; Zhang, Chao >> B >> > > > > > <chao.b.zh...@intel.com> >> > > > > > Subject: Re: [PATCH 05/13] MdePkg/Library/BaseLib/AArch64: Add >> > > > > > AsmLfence function >> > > > > > >> > > > > > On Mon, 17 Dec 2018 at 08:45, Ard Biesheuvel >> > > > > <ard.biesheu...@linaro.org> >> > > > > > wrote: >> > > > > > > >> > > > > > > On Mon, 17 Dec 2018 at 04:29, Yao, Jiewen >> <jiewen....@intel.com> >> > > > > > wrote: >> > > > > > > > >> > > > > > > > I think we have below definition. >> > > > > > > > -- MemoryFence: Serialize load and store operations. >> > > > > > > > -- LoadFence: Serialize load operations. >> > > > > > > > -- StoreFence: Serialize store operations. >> > > > > > > > >> > > > > > > > According to IA32 SDM, Intel has MFENCE, LFENCE and SFENCE. >> > > > > > > > If ARM only has DMB, it is possible to use DMB for >> MemoryFence, >> > > > > > LoadFence or StoreFence. >> > > > > > > > >> > > > > > > > Maybe it is better to use LoadFence, instead of AsmLFence? >> > > > > > > > Then we can align with MemoryFence. >> > > > > > > > >> > > > > > > >> > > > > > > I think using AsmLfence() all over the code to limit speculation >> was a >> > > > > > > mistake, and I am disappointed nobody from the ARM side was >> > > involved >> > > > > > > at all when these changes were proposed. >> > > > > > > >> > > > > > >> > > > > > OK, I have to apologize here. Hao did cc us on these patches, and >so >> > > > > > we did have the opportunity to respond at the time. >> > > > > > >> > > > > > But that doesn't change the fact that AsmLfence() should be >> replaced >> > > > > > by an abstraction that describes the specific semantics of the x86 >> > > > > > Lfence implemetation beyond memory ordering that we are >relying >> on >> > > > > > here. >> > > > > > >> > > > > > >> > > > > > >> > > > > > > The code changes rely on specific semantics of the x86 Lfence >> > > > > > > instructions, i.e., that beyond load serialization, they ensure >> > > > > > > that >> > > > > > > all instructions (not just loads) complete before the lfence >> > > > > > > completes. This is a much stronger notion than a load barrier, >> > > > > > > and >> so >> > > > > > > the abstraction should have been defined as something like a >> > > > > > > ExecFence() or pipeline barrier etc, and the x86 specific >> > > > > > > implementation would have been mapped onto Lfence. For the >> ARM >> > > > > side, >> > > > > > > we probably need an ISB instruction here as well as some kind of >> > > other >> > > > > > > barrier. Calling it LoadFence() makes no sense whatsoever. >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > > > -----Original Message----- >> > > > > > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] >> On >> > > > > Behalf >> > > > > > Of >> > > > > > > > > Gao, Liming >> > > > > > > > > Sent: Monday, December 17, 2018 10:04 AM >> > > > > > > > > To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Jagadeesh >> Ujja >> > > > > > > > > <jagadeesh.u...@arm.com>; Leif Lindholm >> > > > > <leif.lindh...@linaro.org> >> > > > > > > > > Cc: edk2-devel@lists.01.org; Zhang, Chao B >> > > > > > <chao.b.zh...@intel.com> >> > > > > > > > > Subject: Re: [edk2] [PATCH 05/13] >> > > MdePkg/Library/BaseLib/AArch64: >> > > > > > Add >> > > > > > > > > AsmLfence function >> > > > > > > > > >> > > > > > > > > Ard: >> > > > > > > > > My first comment is to suggest updating the caller code for >> the >> > > > > arch >> > > > > > > > > specific code. But, there are two drivers that have the same >> > > usage. >> > > > > > This >> > > > > > > > > way will introduce the duplicated code logic. So, I suggest >> another >> > > > > way >> > > > > > to >> > > > > > > > > extend AsmLfence() API scope for the different ARCHs. If >> you >> > > think >> > > > > it >> > > > > > brings >> > > > > > > > > the confuse, I just think another way to resolve this case in >the >> > > caller >> > > > > > code. >> > > > > > > > > >> > > > > > > > > #if defined (MDE_CPU_IA32) || defined (MDE_CPU_X64) >> > > > > > > > > AsmLfence(); >> > > > > > > > > #else >> > > > > > > > > MemoryFence() >> > > > > > > > > #endif >> > > > > > > > > >> > > > > > > > > Thanks >> > > > > > > > > Liming >> > > > > > > > > >-----Original Message----- >> > > > > > > > > >From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >> > > > > > > > > >Sent: Friday, December 14, 2018 9:54 PM >> > > > > > > > > >To: Jagadeesh Ujja <jagadeesh.u...@arm.com>; Leif >> Lindholm >> > > > > > > > > ><leif.lindh...@linaro.org> >> > > > > > > > > >Cc: edk2-devel@lists.01.org; Gao, Liming >> > > <liming....@intel.com>; >> > > > > > Zhang, >> > > > > > > > > >Chao B <chao.b.zh...@intel.com> >> > > > > > > > > >Subject: Re: [PATCH 05/13] >> MdePkg/Library/BaseLib/AArch64: >> > > Add >> > > > > > > > > >AsmLfence function >> > > > > > > > > > >> > > > > > > > > >On Fri, 14 Dec 2018 at 13:13, Jagadeesh Ujja >> > > > > > <jagadeesh.u...@arm.com> >> > > > > > > > > >wrote: >> > > > > > > > > >> >> > > > > > > > > >> Variable service driver includes a call to AsmLfence. To >> reuse >> > > this >> > > > > > > > > >> driver on AArch64 based platforms, add an >implementation >> of >> > > > > > AsmLfence >> > > > > > > > > >> that acts as a wrapper on the AArch64 specific >> MemoryFence >> > > > > > function. >> > > > > > > > > >> >> > > > > > > > > >> Contributed-under: TianoCore Contribution Agreement >1.1 >> > > > > > > > > >> Signed-off-by: Jagadeesh Ujja <jagadeesh.u...@arm.com> >> > > > > > > > > >> --- >> > > > > > > > > >> MdePkg/Include/Library/BaseLib.h | 33 >> > > > > > +++++++++------ >> > > > > > > > > >> MdePkg/Library/BaseLib/AArch64/AsmLfence.S | 42 >> > > > > > > > > >++++++++++++++++++++ >> > > > > > > > > >> MdePkg/Library/BaseLib/AArch64/AsmLfence.asm | 41 >> > > > > > > > > >+++++++++++++++++++ >> > > > > > > > > >> MdePkg/Library/BaseLib/BaseLib.inf | 2 + >> > > > > > > > > >> 4 files changed, 105 insertions(+), 13 deletions(-) >> > > > > > > > > >> >> > > > > > > > > >> diff --git a/MdePkg/Include/Library/BaseLib.h >> > > > > > > > > >b/MdePkg/Include/Library/BaseLib.h >> > > > > > > > > >> index 8cc0869..ca961ee 100644 >> > > > > > > > > >> --- a/MdePkg/Include/Library/BaseLib.h >> > > > > > > > > >> +++ b/MdePkg/Include/Library/BaseLib.h >> > > > > > > > > >> @@ -7697,19 +7697,6 @@ AsmWriteTr ( >> > > > > > > > > >> ); >> > > > > > > > > >> >> > > > > > > > > >> /** >> > > > > > > > > >> - Performs a serializing operation on all >> load-from-memory >> > > > > > instructions >> > > > > > > > > that >> > > > > > > > > >> - were issued prior the AsmLfence function. >> > > > > > > > > >> - >> > > > > > > > > >> - Executes a LFENCE instruction. This function is only >> > > available >> > > > > on >> > > > > > IA-32 >> > > > > > > > > and >> > > > > > > > > >x64. >> > > > > > > > > >> - >> > > > > > > > > >> -**/ >> > > > > > > > > >> -VOID >> > > > > > > > > >> -EFIAPI >> > > > > > > > > >> -AsmLfence ( >> > > > > > > > > >> - VOID >> > > > > > > > > >> - ); >> > > > > > > > > >> - >> > > > > > > > > >> -/** >> > > > > > > > > >> Patch the immediate operand of an IA32 or X64 >> instruction >> > > > > such >> > > > > > that >> > > > > > > > > the >> > > > > > > > > >byte, >> > > > > > > > > >> word, dword or qword operand is encoded at the end >> of >> > > the >> > > > > > > > > instruction's >> > > > > > > > > >> binary representation. >> > > > > > > > > >> @@ -7752,4 +7739,24 @@ PatchInstructionX86 ( >> > > > > > > > > >> ); >> > > > > > > > > >> >> > > > > > > > > >> #endif // defined (MDE_CPU_IA32) || defined >> > > (MDE_CPU_X64) >> > > > > > > > > >> + >> > > > > > > > > >> +#if defined (MDE_CPU_IA32) || defined (MDE_CPU_X64) >> || >> > > > > > defined >> > > > > > > > > >(MDE_CPU_AARCH64) >> > > > > > > > > >> + >> > > > > > > > > >> +/** >> > > > > > > > > >> + Performs a serializing operation on all >> load-from-memory >> > > > > > instructions >> > > > > > > > > that >> > > > > > > > > >> + were issued prior the AsmLfence function. >> > > > > > > > > >> + >> > > > > > > > > >> + In case of IA-32 and x64, Executes a LFENCE >> instruction. >> > > > > > > > > >> + >> > > > > > > > > >> + In case of AArch64 this acts as a wrapper on the >> AArch64 >> > > > > > > > > >> + specific MemoryFence function >> > > > > > > > > >> + >> > > > > > > > > >> +**/ >> > > > > > > > > >> +VOID >> > > > > > > > > >> +EFIAPI >> > > > > > > > > >> +AsmLfence ( >> > > > > > > > > >> + VOID >> > > > > > > > > >> + ); >> > > > > > > > > >> + >> > > > > > > > > >> +#endif // defined (MDE_CPU_IA32) || defined >> > > (MDE_CPU_X64) >> > > > > > || >> > > > > > > > > >defined (MDE_CPU_AARCH64) >> > > > > > > > > >> #endif // !defined (__BASE_LIB__) >> > > > > > > > > >> diff --git a/MdePkg/Library/BaseLib/AArch64/AsmLfence.S >> > > > > > > > > >b/MdePkg/Library/BaseLib/AArch64/AsmLfence.S >> > > > > > > > > >> new file mode 100644 >> > > > > > > > > >> index 0000000..2fd804b >> > > > > > > > > >> --- /dev/null >> > > > > > > > > >> +++ b/MdePkg/Library/BaseLib/AArch64/AsmLfence.S >> > > > > > > > > >> @@ -0,0 +1,42 @@ >> > > > > > > > > >> >> > > > > +##------------------------------------------------------------------------------ >> > > > > > > > > >> +# >> > > > > > > > > >> +# AsmLfence() for AArch64 >> > > > > > > > > >> +# >> > > > > > > > > >> +# Copyright (c) 2013-2018, ARM Ltd. All rights reserved. >> > > > > > > > > >> +# >> > > > > > > > > >> +# This program and the accompanying materials >> > > > > > > > > >> +# are licensed and made available under the terms and >> > > conditions >> > > > > > of the >> > > > > > > > > >BSD License >> > > > > > > > > >> +# which accompanies this distribution. The full text of >> the >> > > > > license >> > > > > > may >> > > > > > > > > be >> > > > > > > > > >found at >> > > > > > > > > >> +# http://opensource.org/licenses/bsd-license.php. >> > > > > > > > > >> +# >> > > > > > > > > >> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD >> LICENSE >> > > ON >> > > > > AN >> > > > > > "AS >> > > > > > > > > IS" >> > > > > > > > > >BASIS, >> > > > > > > > > >> +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY >> > > KIND, >> > > > > > EITHER >> > > > > > > > > >EXPRESS OR IMPLIED. >> > > > > > > > > >> +# >> > > > > > > > > >> >> > > > > +##------------------------------------------------------------------------------ >> > > > > > > > > >> + >> > > > > > > > > >> +.text >> > > > > > > > > >> +.p2align 2 >> > > > > > > > > >> + >> > > > > > > > > >> +GCC_ASM_EXPORT(AsmLfence) >> > > > > > > > > >> + >> > > > > > > > > >> +# IMPORT >> > > > > > > > > >> +GCC_ASM_IMPORT(MemoryFence) >> > > > > > > > > >> + >> > > > > > > > > >> +#/** >> > > > > > > > > >> +# Used to serialize load and store operations. >> > > > > > > > > >> +# >> > > > > > > > > >> +# All loads and stores that proceed calls to this >> > > > > > > > > >> function >> are >> > > > > > > > > guaranteed to >> > > > > > > > > >be >> > > > > > > > > >> +# globally visible when this function returns. >> > > > > > > > > >> +# >> > > > > > > > > >> +#**/ >> > > > > > > > > >> +#VOID >> > > > > > > > > >> +#EFIAPI >> > > > > > > > > >> +#AsmLfence ( >> > > > > > > > > >> +# VOID >> > > > > > > > > >> +# ); >> > > > > > > > > >> +# >> > > > > > > > > >> +ASM_PFX(AsmLfence): >> > > > > > > > > >> + stp x29, x30, [sp, #-16]! >> > > > > > > > > >> + bl MemoryFence >> > > > > > > > > >> + ldp x29, x30, [sp], #0x10 >> > > > > > > > > >> + ret >> > > > > > > > > > >> > > > > > > > > >Any reason we can't simply do >> > > > > > > > > > >> > > > > > > > > >b MemoryFence >> > > > > > > > > > >> > > > > > > > > >here? >> > > > > > > > > > >> > > > > > > > > >Also, why I understand the rationale, I still think it >> > > > > > > > > >would be >> > > better >> > > > > > > > > >to change callers of the [x86 specific] AsmLfence() than to >> > > introduce >> > > > > > > > > >an alias of MemoryFence() for architectures where Lfence is >> not >> > > > > > > > > >defined. >> > > > > > > > > > >> > > > > > > > > >This is not only about tidiness, but also about potentially >> having >> > > > > > > > > >different semantics, which we can't provide in general on >> ARM, >> > > but >> > > > > > > > > >only in particular cases [such as the code that is modified >> > > > > > > > > >in >> this >> > > > > > > > > >series] >> > > > > > > > > > >> > > > > > > > > >In other words, newly introduced occurrences of >> AsmLfence() >> > > now >> > > > > > have >> > > > > > > > > >to be audited for being appropriate on AArc64 if they are >> added >> > > to >> > > > > > > > > >generic code. >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> diff --git >> a/MdePkg/Library/BaseLib/AArch64/AsmLfence.asm >> > > > > > > > > >b/MdePkg/Library/BaseLib/AArch64/AsmLfence.asm >> > > > > > > > > >> new file mode 100644 >> > > > > > > > > >> index 0000000..7dd5659 >> > > > > > > > > >> --- /dev/null >> > > > > > > > > >> +++ b/MdePkg/Library/BaseLib/AArch64/AsmLfence.asm >> > > > > > > > > >> @@ -0,0 +1,41 @@ >> > > > > > > > > >> >> > > +;------------------------------------------------------------------------------ >> > > > > > > > > >> +; >> > > > > > > > > >> +; AsmLfence() for AArch64 >> > > > > > > > > >> +; >> > > > > > > > > >> +; Copyright (c) 2013-2018, ARM Ltd. All rights reserved. >> > > > > > > > > >> +; >> > > > > > > > > >> +; This program and the accompanying materials >> > > > > > > > > >> +; are licensed and made available under the terms and >> > > conditions >> > > > > > of the >> > > > > > > > > >BSD License >> > > > > > > > > >> +; which accompanies this distribution. The full text of >> the >> > > > > license >> > > > > > may >> > > > > > > > > be >> > > > > > > > > >found at >> > > > > > > > > >> +; http://opensource.org/licenses/bsd-license.php. >> > > > > > > > > >> +; >> > > > > > > > > >> +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD >> LICENSE >> > > ON >> > > > > AN >> > > > > > "AS >> > > > > > > > > IS" >> > > > > > > > > >BASIS, >> > > > > > > > > >> +; WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY >> > > KIND, >> > > > > > EITHER >> > > > > > > > > >EXPRESS OR IMPLIED. >> > > > > > > > > >> +; >> > > > > > > > > >> >> > > +;------------------------------------------------------------------------------ >> > > > > > > > > >> + >> > > > > > > > > >> + EXPORT AsmLfence >> > > > > > > > > >> + AREA BaseLib_LowLevel, CODE, READONLY >> > > > > > > > > >> + # IMPORT >> > > > > > > > > >> + GCC_ASM_IMPORT(MemoryFence) >> > > > > > > > > >> + >> > > > > > > > > >> +;/** >> > > > > > > > > >> +; Used to serialize load and store operations. >> > > > > > > > > >> +; >> > > > > > > > > >> +; All loads and stores that proceed calls to this >> > > > > > > > > >> function >> are >> > > > > > guaranteed >> > > > > > > > > to >> > > > > > > > > >be >> > > > > > > > > >> +; globally visible when this function returns. >> > > > > > > > > >> +; >> > > > > > > > > >> +;**/ >> > > > > > > > > >> +;VOID >> > > > > > > > > >> +;EFIAPI >> > > > > > > > > >> +;AsmLfence ( >> > > > > > > > > >> +; VOID >> > > > > > > > > >> +; ); >> > > > > > > > > >> +; >> > > > > > > > > >> +AsmLfence >> > > > > > > > > >> + stp x29, x30, [sp, #-16]! >> > > > > > > > > >> + bl MemoryFence >> > > > > > > > > >> + ldp x29, x30, [sp], #0x10 >> > > > > > > > > >> + ret >> > > > > > > > > >> + >> > > > > > > > > >> + END >> > > > > > > > > >> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf >> > > > > > > > > >b/MdePkg/Library/BaseLib/BaseLib.inf >> > > > > > > > > >> index b84e583..b7d7bcb 100644 >> > > > > > > > > >> --- a/MdePkg/Library/BaseLib/BaseLib.inf >> > > > > > > > > >> +++ b/MdePkg/Library/BaseLib/BaseLib.inf >> > > > > > > > > >> @@ -585,6 +585,7 @@ >> > > > > > > > > >> Math64.c >> > > > > > > > > >> >> > > > > > > > > >> AArch64/MemoryFence.S | GCC >> > > > > > > > > >> + AArch64/AsmLfence.S | GCC >> > > > > > > > > >> AArch64/SwitchStack.S | GCC >> > > > > > > > > >> AArch64/EnableInterrupts.S | GCC >> > > > > > > > > >> AArch64/DisableInterrupts.S | GCC >> > > > > > > > > >> @@ -593,6 +594,7 @@ >> > > > > > > > > >> AArch64/CpuBreakpoint.S | GCC >> > > > > > > > > >> >> > > > > > > > > >> AArch64/MemoryFence.asm | MSFT >> > > > > > > > > >> + AArch64/AsmLfence.asm | MSFT >> > > > > > > > > >> AArch64/SwitchStack.asm | MSFT >> > > > > > > > > >> AArch64/EnableInterrupts.asm | MSFT >> > > > > > > > > >> AArch64/DisableInterrupts.asm | MSFT >> > > > > > > > > >> -- >> > > > > > > > > >> 2.7.4 >> > > > > > > > > >> >> > > > > > > > > _______________________________________________ >> > > > > > > > > edk2-devel mailing list >> > > > > > > > > edk2-devel@lists.01.org >> > > > > > > > > https://lists.01.org/mailman/listinfo/edk2-devel >> > > > > _______________________________________________ >> > > > > edk2-devel mailing list >> > > > > edk2-devel@lists.01.org >> > > > > https://lists.01.org/mailman/listinfo/edk2-devel >> > > _______________________________________________ >> > > edk2-devel mailing list >> > > edk2-devel@lists.01.org >> > > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
