Current memory attribute table implementation will only mark PE code
to be EfiRuntimeServicesCode, and mark rest to be EfiRuntimeServicesData.
However, there might be a case that a SMM code wants to allocate
EfiRuntimeServicesCode explicitly to let page table protect this region
to be read only. I
EFI_PAGES_TO_SIZE only handles UINTN, so we use EfiPagesToSize
to handle UINT64.
Cc: Jeff Fan
Cc: Michael D Kinney
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao
---
MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c | 6 +++---
1 file chan
PiSmmCore supports page level protection based upon the Memory Type
(EfiRuntimeServicesCode/EfiRuntimeServicesData) and PE image.
However, the Memory Type information is ignored in AllocatePool().
If a caller calls AllocatePool with EfiRuntimeServicesCode,
the final memory is still allocated as Ef
Cc: Jeff Fan
Cc: Michael D Kinney
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao
---
MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MdeModulePkg/Core/PiSmmCore/Memor
Got it. I will keep comment "Need add Free memory at first, to let
gSmmMemoryMap record data".
-Original Message-
From: Yao, Jiewen
Sent: Thursday, December 01, 2016 3:41 PM
To: Gao, Liming ; edk2-devel@lists.01.org
Cc: Zeng, Star
Subject: RE: [Patch] MdeModulePkg PiSmmCore: Update comm
The commit e27cca has a typo on DEBUG level macro. And this debug
message should be DEBUG_INFO rather than DEBUG_ERROR.
Cc: Jan Dabros
Cc: Marcin Wojtas
Cc: Star Zeng
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian
---
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcP
To prevent potential build failure.
Cc: Feng Tian
Cc: Jeff Fan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao
---
MdeModulePkg/Application/CapsuleApp/AppSupport.c | 8
MdeModulePkg/Application/CapsuleApp/CapsuleApp.c | 4 ++--
2 files changed, 6 inse
Reviewed-by: Feng Tian
Thanks
Feng
-Original Message-
From: Yao, Jiewen
Sent: Thursday, December 1, 2016 4:51 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng ; Fan, Jeff
Subject: [PATCH] MdeModulePkg/CapsuleApp: add Internal for function name.
To prevent potential build failure.
Cc: Fe
On Thu, Dec 01, 2016 at 09:52:15AM +0800, Zeng, Star wrote:
> On 2016/12/1 1:20, Leif Lindholm wrote:
> >LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
> >from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
> >kept for compatibility.
> >
> >Nevertheless, new
This patch fixes https://bugzilla.tianocore.org/show_bug.cgi?id=246
Previously, when SMM exception happens after EndOfDxe,
with StackGuard enabled on IA32, the #double fault exception
is reported instead of #page fault.
Root cause is below:
Current EDKII SMM page protection will lock GDT.
If IA3
https://bugzilla.tianocore.org/show_bug.cgi?id=257
For GCC compilers, when building with option '-fshort-wchar', wide char
string format '%ls' does not work properly for printf() function. The
string specified by '%ls' will not be printed.
This commit avoids using '%ls' for printf() function and
Hi Feng,
You are right. Sorry for the mistake.
Best regards,
Marcin
2016-12-01 9:41 GMT+01:00 Feng Tian :
> The commit e27cca has a typo on DEBUG level macro. And this debug
> message should be DEBUG_INFO rather than DEBUG_ERROR.
>
> Cc: Jan Dabros
> Cc: Marcin Wojtas
> Cc: Star Zeng
> Contri
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenBusDxe/GrantTable.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
index 5c4b528..2448585 100644
--- a/OvmfPkg/XenBusDxe/Gran
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/Include/Library/XenHypercallLib.h | 3 +++
OvmfPkg/Library/XenHypercallLib/XenHypercall.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/OvmfPkg/Include/Library/XenHypercallLib.h
b/Ovm
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenBusDxe/EventChannel.c | 1 +
OvmfPkg/XenBusDxe/EventChannel.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/OvmfPkg/XenBusDxe/EventChannel.c b/OvmfPkg/XenBusDxe/EventChannel.c
index 490ca5
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenBusDxe/XenStore.c | 13 +
OvmfPkg/XenBusDxe/XenStore.h | 10 ++
2 files changed, 23 insertions(+)
diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
inde
Hi,
That might be only with the Xen part of OVMF but now that the GCC5
toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail
to boot in Xen guests.
Here is the result:
X64 Exception Type - 06(#UD - Invalid Opcode) CPU Apic ID -
RIP - 1F26AF6B, CS - 0
LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.
Nevertheless, new code should be using the MdeModulePkg versions, so
change all references in in-tree platforms.
Since the patches ar
LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.
Since the libraries are identical, move DuetPkg to use the MdeModulePkg
versions instead.
Contributed-under: TianoCore Contribution A
LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.
Since the libraries are identical, move EmbeddedPkg to use the
MdeModulePkg versions instead.
Contributed-under: TianoCore Contributi
LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.
Since the libraries are identical, move EmulatorPkg to use the
MdeModulePkg versions instead.
Contributed-under: TianoCore Contributi
LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.
Since the libraries are identical, move BeagleBoardPkg to use the
MdeModulePkg versions instead.
Contributed-under: TianoCore Contrib
LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.
Since the libraries are identical, move iQuarkSocPkg to use the
MdeModulePkg versions instead.
Contributed-under: TianoCore Contribut
LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.
Since the libraries are identical, move OvmfPkg to use the MdeModulePkg
versions instead.
Contributed-under: TianoCore Contribution A
LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.
Since the libraries are identical, move Vlv2TbltDevicePkg to use the
MdeModulePkg versions instead.
Contributed-under: TianoCore Cont
Reviewed-by: Jaben Carsey
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ruiyu Ni
> Sent: Tuesday, November 22, 2016 6:58 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Chen, Chen A
>
> Subject: [edk2] [PATCH] ShellPkg/MV: Fix MV
Commit 0a99a65d2c8a ("fix incorrect device address of double buffer")
retained an explicit cast on the variable "Buffer" which became
incorrect with the other changes, leading to compilation failures
with some toolchains. Drop the cast.
Contributed-under: TianoCore Contribution Agreement 1.0
Repor
On 01/12/16 16:45, Leif Lindholm wrote:
Commit 0a99a65d2c8a ("fix incorrect device address of double buffer")
retained an explicit cast on the variable "Buffer" which became
incorrect with the other changes, leading to compilation failures
with some toolchains. Drop the cast.
Contributed-under
On 1 December 2016 at 16:45, Leif Lindholm wrote:
> Commit 0a99a65d2c8a ("fix incorrect device address of double buffer")
> retained an explicit cast on the variable "Buffer" which became
> incorrect with the other changes, leading to compilation failures
> with some toolchains. Drop the cast.
>
>
On Thu, Dec 01, 2016 at 05:00:19PM +, Ard Biesheuvel wrote:
> On 1 December 2016 at 16:45, Leif Lindholm wrote:
> > Commit 0a99a65d2c8a ("fix incorrect device address of double buffer")
> > retained an explicit cast on the variable "Buffer" which became
> > incorrect with the other changes, le
The BootScriptWriteMemPoll() helper function in both drivers does the
following:
- pop Delay from the variable argument list as UINT64, then truncate it to
UINTN,
- divide Delay by 10, using DivU64x32Remainder(), then store the quotient
in LoopTimes (also UINTN),
- pass LoopTimes to S3BootSc
The BaseNull instance of S3BootScriptLib obviously doesn't care about the
type of the S3BootScriptSaveMemPoll() function's LoopTimes parameter; this
lib instance doesn't do anything with the parameters received in
S3BootScriptSaveMemPoll().
The PiDxe instance saves the LoopTimes parameter in
EFI_B
The BootScriptMemPoll() helper function does the following:
- pop LoopTimes from the variable argument list as UINT64, then truncate
it to UINTN,
- pass the truncated value to S3BootScriptSaveMemPoll() as last argument.
The truncation to UINTN is now superfluous, thanks to the patch titled
"Md
While working on S3 boot script related stuff in OVMF, I wanted to see
if infinite blocking was possible in the various POLL opcodes. While
edk2's implementation of IO_POLL, PCI_CONFIG_POLL and PCI_CONFIG2_POLL
follows the PI spec vol5 closely, even internally (using 100ns delay
units), the MEM_POL
InternalQemuFwCfgIsAvailable() is an API that is incorrectly exposed by
the "OvmfPkg/Include/Library/QemuFwCfgLib.h" library class header; the API
is meant to be used internally to library instances (if it's needed at
all).
In OvmfPkg, we have two lib instances (for SEC and PEI/DXE); they provide
Add the type and macro definitions related to QEMU's DMA-like fw_cfg
access method in a dedicated header file.
Cc: Ard Biesheuvel
Cc: Jordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h | 50 +
The benefits of the DMA-like access method are (a) speed, (b) write
support in QEMU 2.9+.
(IOPort-based write support was discontinued in QEMU 2.4, and the
DMA-based one is being added to QEMU 2.9. Write support needs no separate
feature detection because writeability is governed on the level of
i
I plan to use the DMA interface of QEMU's fw_cfg in upcoming features
(one short term, another long term).
The first four patches in the series refactor the current library
instances (and even the lib class) slightly, while the last patch adds
the feature to OVMF.
Repo: https://github.com/lerse
InternalQemuFwCfgIsAvailable() is an API that is incorrectly exposed by
the "OvmfPkg/Include/Library/QemuFwCfgLib.h" library class header; the API
is meant to be used internally to library instances (if it's needed at
all). ArmVirtPkg's instance has no use for it actually, so simplify the
code and
where "QemuFwCfgDma.h" was added in the previous patch.
Cc: Ard Biesheuvel
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --g
Leif,
Yes. You can push QuarkSocPkg patch based on my previous rb.
Thanks,
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif
> Lindholm
> Sent: Thursday, December 1, 2016 7:53 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Ard B
On 12/01/16 16:53, Leif Lindholm wrote:
> LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
> from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
> kept for compatibility.
>
> Since the libraries are identical, move OvmfPkg to use the MdeModulePkg
> versions i
On 12/01/16 16:28, Anthony PERARD wrote:
> Hi,
>
> That might be only with the Xen part of OVMF but now that the GCC5
> toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail
> to boot in Xen guests.
>
> Here is the result:
> X64 Exception Type - 06(#UD - Invalid Opcode) CPU
On 2016-12-01 09:56:31, Laszlo Ersek wrote:
> Add the type and macro definitions related to QEMU's DMA-like fw_cfg
> access method in a dedicated header file.
>
> Cc: Ard Biesheuvel
> Cc: Jordan Justen
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek
> ---
For the future, I'd recommend adding Cc's for package owners to the
associated patch commit message.
Series Reviewed-by: Jordan Justen
On 2016-12-01 07:53:19, Leif Lindholm wrote:
> LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
> from IntelFrameworkModulePkg to MdeModule
On 2016-12-01 10:43:24, Laszlo Ersek wrote:
> On 12/01/16 16:28, Anthony PERARD wrote:
> > Hi,
> >
> > That might be only with the Xen part of OVMF but now that the GCC5
> > toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail
> > to boot in Xen guests.
> >
> > Here is the resul
On 11/23/16 16:44, Laszlo Ersek wrote:
> On 11/23/16 04:44, Jordan Justen wrote:
>> Series Reviewed-by: Jordan Justen
>
> Thank you!
>
> I'll delay pushing the patches until Michael Tsirkin reviews the
> interface spec in the QEMU series on qemu-devel.
This version of the series can be dropped
On 12/01/16 20:34, Jordan Justen wrote:
> On 2016-12-01 09:56:31, Laszlo Ersek wrote:
>> Add the type and macro definitions related to QEMU's DMA-like fw_cfg
>> access method in a dedicated header file.
>>
>> Cc: Ard Biesheuvel
>> Cc: Jordan Justen
>> Contributed-under: TianoCore Contribution Agr
On 12/01/16 21:06, Jordan Justen wrote:
> On 2016-12-01 10:43:24, Laszlo Ersek wrote:
>> On 12/01/16 16:28, Anthony PERARD wrote:
>>> Hi,
>>>
>>> That might be only with the Xen part of OVMF but now that the GCC5
>>> toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail
>>> to boot
On 12/01/16 09:23, Jiewen Yao wrote:
> PiSmmCore supports page level protection based upon the Memory Type
> (EfiRuntimeServicesCode/EfiRuntimeServicesData) and PE image.
>
> However, the Memory Type information is ignored in AllocatePool().
> If a caller calls AllocatePool with EfiRuntimeServices
On 12/01/16 13:04, Jiewen Yao wrote:
> This patch fixes https://bugzilla.tianocore.org/show_bug.cgi?id=246
>
> Previously, when SMM exception happens after EndOfDxe,
> with StackGuard enabled on IA32, the #double fault exception
> is reported instead of #page fault.
>
> Root cause is below:
>
>
Cc: Jiewen Yao
Cc: David Wei
Cc: Mang Guo
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney
---
Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 2 +-
Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Vlv
Update PlatformPkgGccX64.dsc to align with PlatformPkgX64.dsc
on library mappings and PCD settings.
Cc: Jiewen Yao
Cc: David Wei
Cc: Mang Guo
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney
---
Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 75 +++-
https://bugzilla.tianocore.org/show_bug.cgi?id=276
Fix library mapping and PCD settings required to use
the SOURCE_DEBUG_ENABLE feature in PEI, DXE, and SMM.
Cc: Jiewen Yao
Cc: David Wei
Cc: Mang Guo
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney
---
Vl
https://bugzilla.tianocore.org/show_bug.cgi?id=276
Add the UART console produced by the DebugAgent when
SOURCE_DEBUG_ENABLE is TRUE. Without this change, the
debugger connects but the Boot Manager and the UEFI
Shell do not have an active console because the Boot
Manager does not know about the De
Changes in V2
=
* Fix build failure when SOURCE_DEBUG_ENABLE is FALSE
Fix SOURCE_DEBUG_ENABLE feature that includes updates to library
mappings, PCD settings, and adding DebugAgent UART Console as one
of the possible console devices in the PlatformBdsLib.
The series also cleans up a f
On 2016-12-01 12:54:34, Laszlo Ersek wrote:
> On 12/01/16 21:06, Jordan Justen wrote:
> > On 2016-12-01 10:43:24, Laszlo Ersek wrote:
> >> Hrpmf, wait a second, I do see something interesting: in this series you
> >> *are* modifying APIs declared in a library class header (namely
> >> "OvmfPkg/Incl
On 2016-12-01 12:48:51, Laszlo Ersek wrote:
> On 12/01/16 20:34, Jordan Justen wrote:
> > On 2016-12-01 09:56:31, Laszlo Ersek wrote:
> >> Add the type and macro definitions related to QEMU's DMA-like fw_cfg
> >> access method in a dedicated header file.
> >>
> >> Cc: Ard Biesheuvel
> >> Cc: Jorda
I have a command like this:
X %_key% >v _key
and
X %_key% _key
These two commands should do, essentially the same thing, since the command 'X'
calls ShellSetEnvironmentVariable() if the 2nd parameter is present.
Any thoughts?
Tim
___
edk2-devel ma
Reviewed-by: Star Zeng
-Original Message-
From: Tian, Feng
Sent: Thursday, December 1, 2016 4:42 PM
To: edk2-devel@lists.01.org
Cc: Jan Dabros ; Marcin Wojtas ; Zeng,
Star
Subject: [patch] MdeModulePkg/SdMmc: Fix build failure caused by last check-in
The commit e27cca has a typo on DE
Using the latest Shell build, try:
ls -sfo | parse FileInfo 2
This ends up with a breakpoint when FreePool is called on Shell.c, line 1756.
I'm still debugging, but I wondered if anyone else has seen this?
Also:
ls -sfo > tmp
parse FileInfo 2 < tmp
prints nothing, but
parse tmp FileInfo 2
w
HI Laszlo
Thank you to raise this long time existing issue. :-)
There is historic reason that we inherit this undocumented API from EDK-I to
EDKII.
I do not object your update.
I am thinking if it is time to create a new API which can match PI
specification, and suggest all consumers use the ne
Reviewed-by: Ruiyu Ni
Regards,
Ray
>-Original Message-
>From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
>Sent: Thursday, December 1, 2016 11:53 PM
>To: edk2-devel@lists.01.org
>Cc: Ni, Ruiyu ; Justen, Jordan L
>; Andrew Fish ; Laszlo
>Ersek ; Kinney, Michael D ;
>Steele, Kelly ;
Thank you Laszlo.
This time, I did not use number purposely.
My thinking is that each patch resolves a specific problem. Although I fixed
all of them at same time, they can be check in independently.
Thank you
Yao Jiewen
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Friday, December 2, 2
if (StrStr (TempLine, L"ShellCommand,") == TempLine) {
LoopVariable++;
}
This line fails because, with redirected input, the file has the UCS-2 byte
order mark, so the string "ShellCommand," is not at the beginning of the line.
With the file, the byte order mark is not presen
Reviewed-by: Liming Gao
-Original Message-
From: Zhu, Yonghong
Sent: Wednesday, November 30, 2016 4:23 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming
Subject: [Patch] BaseTools: Fix the bug to parse the new map file format
Current the variable and Pcd format save in the map file is cha
Reviewed-by: Liming Gao
-Original Message-
From: Zhu, Yonghong
Sent: Wednesday, November 30, 2016 5:07 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming
Subject: [Patch] BaseTools: add error check for "#image" for idf file format
Add new error check for "#image" keyword used in the image
Reviewed-by: Liming Gao
-Original Message-
From: Zhu, Yonghong
Sent: Wednesday, November 30, 2016 4:24 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming
Subject: [Patch] BaseTools: Support QuotedString for PREBUILD/POSTBUILD in DSC
file
If the prebuild/postbuild script statement start wi
Hao:
Place move UnicodeStrLen() and Unicode2AsciiString() implementation before
main() function. If so, they are not required to be declared again.
Other changes are good. Reviewed-by: Liming Gao
Thanks
Liming
-Original Message-
From: Wu, Hao A
Sent: Thursday, December 01, 2016 8
Got it. I will move those 2 implementation before main() before code
check-in.
Best Regards,
Hao Wu
> -Original Message-
> From: Gao, Liming
> Sent: Friday, December 02, 2016 10:56 AM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Zhu, Yonghong
> Subject: RE: [PATCH] BaseTools/VolInfo: F
I agree to root cause this issue with GCC6. Could you help submit this issue in
bugzilia? Then, we will investigate it further.
Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
Ersek
Sent: Friday, December 02, 2016 2:43 AM
To
On 2016/12/2 9:53, Yao, Jiewen wrote:
HI Laszlo
Thank you to raise this long time existing issue. :-)
There is historic reason that we inherit this undocumented API from EDK-I to
EDKII.
I do not object your update.
I am thinking if it is time to create a new API which can match PI
specificati
After looking further, it appears that the FreePool() call on line 1756 is
unnecessary, and just causes a breakpoint.
Removing it allows the functionality to work correctly.
//FreePool (Split->SplitStdIn);
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.
73 matches
Mail list logo