On 10/28/13 22:27, Jordan Justen wrote:
> Previously we would only search for MMIO regions that were also
> above every EfiGcdMemoryTypeReserved and EfiGcdMemoryTypeSystemMemory
> region.
Yes.
More verbosely, the previous logic does the following:
- finds the "bounding box" for MMIO regions,
- finds the maximum for non-MMIO regions (reserved / system RAM),
- removes the lower part of the "bounding box" that falls under the
non-MMIO maximum,
- and the remaining bounding box is exported in
\_SB.PCI0._CRS.DWORDMEMORY, ResourceProducer/PosDecode, meaning that
the root bridge passes accesses to addresses in the "bounding box" to
child devices.
>
> Now we just search for the largest EfiGcdMemoryTypeMemoryMappedIo
> region.
As far as I can see, the direct difference is:
- while previously the final "bounding box" could have holes (ie.
EfiGcdMemoryTypeNonExistent) inside, and it could cover several MMIO
regions, and it used to be above all non-MMIO ranges,
- now the range will be the largest one contiguous MMIO range, and it
can be anywhere.
The new range may not be a subset of the former, clamped bounding box
(because a conventional RAM region could be located above it). It can be
both smaller (i) and greater (ii) than the previous bounding box.
(i) the bounding box can cover several MMIO ranges (with nonexistents
in-between optionally)
(ii) possible eg. in the non-subset case
So, I have no idea about the consequences, but exporting one contiguous
MMIO range in _CRS (with no nonexistents inside, ever) does seem clean.
> This will allow us to mark the flash memory as a runtime memory
> region in order to allow runtime access of variables stored in
> flash.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> ---
> OvmfPkg/AcpiPlatformDxe/Qemu.c | 37 ++++++++++++-------------------------
> 1 file changed, 12 insertions(+), 25 deletions(-)
>
> diff --git a/OvmfPkg/AcpiPlatformDxe/Qemu.c b/OvmfPkg/AcpiPlatformDxe/Qemu.c
> index 8a6ecf7..cab3219 100644
> --- a/OvmfPkg/AcpiPlatformDxe/Qemu.c
> +++ b/OvmfPkg/AcpiPlatformDxe/Qemu.c
> @@ -1,7 +1,7 @@
> /** @file
> OVMF ACPI QEMU support
>
> - Copyright (c) 2008 - 2012, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
>
> Copyright (C) 2012, Red Hat, Inc.
>
> @@ -232,16 +232,12 @@ PopulateFwData(
>
> Status = gDS->GetMemorySpaceMap (&NumDesc, &AllDesc);
> if (Status == EFI_SUCCESS) {
> - UINT64 NonMmio32MaxExclTop;
> - UINT64 Mmio32MinBase;
> - UINT64 Mmio32MaxExclTop;
> UINTN CurDesc;
> + CONST EFI_GCD_MEMORY_SPACE_DESCRIPTOR *Mmio32Desc;
>
> Status = EFI_UNSUPPORTED;
>
> - NonMmio32MaxExclTop = 0;
> - Mmio32MinBase = BASE_4GB;
> - Mmio32MaxExclTop = 0;
> + Mmio32Desc = NULL;
>
> for (CurDesc = 0; CurDesc < NumDesc; ++CurDesc) {
> CONST EFI_GCD_MEMORY_SPACE_DESCRIPTOR *Desc;
> @@ -253,21 +249,16 @@ PopulateFwData(
> if (ExclTop <= BASE_4GB) {
> switch (Desc->GcdMemoryType) {
> case EfiGcdMemoryTypeNonExistent:
> - break;
> -
> case EfiGcdMemoryTypeReserved:
> case EfiGcdMemoryTypeSystemMemory:
> - if (NonMmio32MaxExclTop < ExclTop) {
> - NonMmio32MaxExclTop = ExclTop;
> - }
> break;
>
> case EfiGcdMemoryTypeMemoryMappedIo:
> - if (Mmio32MinBase > Desc->BaseAddress) {
> - Mmio32MinBase = Desc->BaseAddress;
> - }
> - if (Mmio32MaxExclTop < ExclTop) {
> - Mmio32MaxExclTop = ExclTop;
> + if (Mmio32Desc == NULL ||
> + Desc->Length > Mmio32Desc->Length ||
> + (Desc->Length == Mmio32Desc->Length &&
> + Desc->BaseAddress > Mmio32Desc->BaseAddress)) {
> + Mmio32Desc = Desc;
> }
> break;
Seems to do what the commit message promises -- furthermore, it will
select the highest region if the largest size occurs at several bases.
>
> @@ -277,14 +268,10 @@ PopulateFwData(
> }
> }
>
> - if (Mmio32MinBase < NonMmio32MaxExclTop) {
> - Mmio32MinBase = NonMmio32MaxExclTop;
> - }
> -
> - if (Mmio32MinBase < Mmio32MaxExclTop) {
> - FwData->PciWindow32.Base = Mmio32MinBase;
> - FwData->PciWindow32.End = Mmio32MaxExclTop - 1;
> - FwData->PciWindow32.Length = Mmio32MaxExclTop - Mmio32MinBase;
> + if (Mmio32Desc != NULL) {
> + FwData->PciWindow32.Base = Mmio32Desc->BaseAddress;
> + FwData->PciWindow32.End = Mmio32Desc->BaseAddress +
> Mmio32Desc->Length - 1;
> + FwData->PciWindow32.Length = Mmio32Desc->Length;
>
> FwData->PciWindow64.Base = 0;
> FwData->PciWindow64.End = 0;
>
Reviewed-by: Laszlo Ersek <ler...@redhat.com>
--o--
I also wanted to test the series at this patch (and compare the
results to when the series is not applied). The guest I used is
RHEL-6, because the boot animation of that guest (efifb) exposes the
original _CRS problem well. Guest RAM: 5GB.
Host: RHEL-6 (no KVM support for readonly memslots, and qemu is older
as well) -- hence regression test.
Unfortunately, the following ASSERT() fires:
ASSERT /.../SecurityPkg/VariableAuthenticated/RuntimeDxe/Variable.c(3320):
mNvVariableCache->Size == VariableStoreLength
This error persists when I compile the series at patch #4 or at patch
#8. Removing the /NvVars file from the EFI system partition in the
guest doesn't help.
... After some debug patches, I think the problem is the following:
the DSC file has a section under [PcdsFixedAtBuild] where four
relevant PCDs get default values:
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xc000
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0xc000
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x2000
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x10000
The last three of these gets overridden at build time, in the FDF
file. However, the first one, PcdVariableStoreSize, remains unchanged.
On my host, the EMU variables are still used. In
InitializeFvAndVariableStoreHeaders(), the Size member of the
"variable FV header" is keyed off PcdVariableStoreSize.
Then, in InitNonVolatileVariableStore()
[SecurityPkg/VariableAuthenticated/RuntimeDxe/Variable.c], this data
is copied into freshly allocated storage, and ultimately accessed as
mNvVariableCache.
However, PcdFlashNvStorageVariableSize is updated in the FDF at build
time, and that's the PCD that VariableStoreLength below originates
from:
[...]
Reserved variable store memory: 0xDFFD0000; size: 128kb
[...]
QEMU flash was not detected. Writable FVB is not being installed.
[...]
EMU Variable FVB Started
EMU Variable FVB: Using pre-reserved block at DFFD0000
EMU Variable FVB: Basic FV headers were invalid
Installing FVB for EMU Variable support
[...]
InitNonVolatileVariableStore: NvStorageBase #1: 0xDFFD0000
InitNonVolatileVariableStore: VariableStoreBase=0xDF834060
InitNonVolatileVariableStore: NvStorageSize=0xE000
InitNonVolatileVariableStore: FvHeader->HeaderLength=0x48
InitNonVolatileVariableStore: VariableStoreLength=0xDFB8
InitNonVolatileVariableStore: mNvVariableCache->Size=0xBFB8
ASSERT
/home/lacos/src/upstream/edk2-git-svn/SecurityPkg/VariableAuthenticated/RuntimeDxe/Variable.c(3333):
mNvVariableCache->Size == VariableStoreLength
[...]
(The InitNonVolatileVariableStore entries before the ASSERT are from
my debug patch.)
That is, PcdVariableStoreSize remains static, as set in the DSC file,
whereas PcdFlashNvStorageVariableSize is set dynamically at build
time. The mismatch between the two triggers the assert.
In my opinion, these variables are fully independent, and we shouldn't
be looking at PcdVariableStoreSize *at all*. The ASSERT() is valid,
the problem is that the EMU variable code abuses PcdVariableStoreSize
in the role of PcdFlashNvStorageVariableSize. The attached patch seems
to fix the problem for me (but it could easily be wrong, of course).
--o--
OK, so back to testing:
(a) The OVMF debug log changes:
-ACPI PciWindow32: Base=0xE0000000 End=0xFEEFFFFF Length=0x1EF00000
+ACPI PciWindow32: Base=0xE0000000 End=0xFBFFFFFF Length=0x1C000000
(b) The FWDT table (dumped with acpidump) changes accordingly:
--- pre/FWDT.hex 2013-10-30 23:09:28.244990822 +0100
+++ post/FWDT.hex 2013-10-31 00:44:22.517005582 +0100
@@ -1,4 +1,4 @@
-00000000 00 00 00 e0 00 00 00 00 ff ff ef fe 00 00 00 00
|................|
-00000010 00 00 f0 1e 00 00 00 00 00 00 00 00 00 00 00 00
|................|
+00000000 00 00 00 e0 00 00 00 00 ff ff ff fb 00 00 00 00
|................|
+00000010 00 00 00 1c 00 00 00 00 00 00 00 00 00 00 00 00
|................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
00000030
(c) The guest dmesg changes like this:
PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs"
and report a bug
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7]
pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff]
pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
-pci_root PNP0A03:00: host bridge window [mem 0xe0000000-0xfeefffff]
+pci_root PNP0A03:00: host bridge window [mem 0xe0000000-0xfbffffff]
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7]
pci_bus 0000:00: root bus resource [io 0x0d00-0xffff]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
-pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfeefffff]
+pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfbffffff]
(d) /proc/iomem:
--- pre/iomem 2013-10-30 23:03:59.479997713 +0100
+++ post/iomem 2013-10-31 00:44:33.047004153 +0100
@@ -1,34 +1,34 @@
00000000-00000fff : reserved
00001000-0009ffff : System RAM
000a0000-000bffff : PCI Bus 0000:00
000f0000-000fffff : System ROM
-00100000-ddc23fff : System RAM
+00100000-ddc19fff : System RAM
01000000-01526934 : Kernel code
01526935-01c0f26f : Kernel data
01d58000-0201e9a3 : Kernel bss
03000000-0b0fffff : Crash kernel
-ddc24000-ddc2bfff : reserved
-ddc2c000-ddc41fff : System RAM
-ddc42000-dddcefff : reserved
+ddc1a000-ddc21fff : reserved
+ddc22000-ddc37fff : System RAM
+ddc38000-dddcefff : reserved
dddcf000-df7fefff : System RAM
df7ff000-df856fff : reserved
df857000-df85efff : ACPI Tables
df85f000-df862fff : ACPI Non-volatile Storage
df863000-dffcffff : System RAM
dffd0000-dfffffff : reserved
-e0000000-feefffff : PCI Bus 0000:00
+e0000000-fbffffff : PCI Bus 0000:00
e0000000-e1ffffff : 0000:00:02.0
e0000000-e023ffff : efifb
e2000000-e2000fff : 0000:00:06.0
e2000000-e2000fff : virtio-pci
e2001000-e2001fff : 0000:00:04.0
e2001000-e2001fff : virtio-pci
e2002000-e2002fff : 0000:00:03.0
e2002000-e2002fff : virtio-pci
e2003000-e2003fff : 0000:00:02.0
e2010000-e201ffff : 0000:00:02.0
e2020000-e202ffff : 0000:00:03.0
- fec00000-fec003ff : IOAPIC 0
- fee00000-feefffff : pnp 00:05
- fee00000-fee00fff : Local APIC
+fec00000-fec003ff : IOAPIC 0
+fee00000-feefffff : pnp 00:05
+ fee00000-fee00fff : Local APIC
100000000
Interestingly, this moves out IOAPIC 0 "from under" PCI Bus 0000:00,
at least in this view. I'm not sure if that will have any
consequence. The dmesg *diff* has nothing related to IOAPICs.
(e) The EFI frame buffer continues to work. The following section
remains intact in the guest dmesg:
efifb: probing for efifb
efifb: framebuffer at 0xe0000000, mapped to 0xffffc90001780000, using
2304k, total 2304k
efifb: mode is 1024x768x24, linelength=3072, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=0:8:8:8, shift=0:16:8:0
Console: switching to colour frame buffer device 128x48
fb0: EFI VGA frame buffer device
So, I found no regressions in my usual environment (after fixing the
ASSERT() with the attached patch).
Tested-by: Laszlo Ersek <ler...@redhat.com>
Thanks,
Laszlo
From 21bca8f776faa15e2b573abea93061e219531466 Mon Sep 17 00:00:00 2001
From: Laszlo Ersek <ler...@redhat.com>
Date: Thu, 31 Oct 2013 00:31:16 +0100
Subject: [PATCH] OvmfPkg: EMU Variable: refer to correct PCD when determining
NV storage size
According to the documentation in "MdeModulePkg/MdeModulePkg.dec", the PCD
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
gives
The size of volatile buffer. This buffer is used to store VOLATILE
attribute variable.
The EMU variable facility has nothing to do with volatile variables, it
emulates non-volatile variables. The storage size for those is given by
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
The patch updates all references in OvmfPkg, and corrects a dependent,
EMU-related comment in "MdeModulePkg/MdeModulePkg.dec" too.
OVMF's DSC files no longer refer to PcdVariableStoreSize -- the volatile
store size doesn't have to be kept in synch with the non-volatile store
size, hence the global default in MdeModulePkg/MdeModulePkg.dec will do
for the former.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <ler...@redhat.com>
---
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c | 8 ++++----
MdeModulePkg/MdeModulePkg.dec | 2 +-
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf | 3 +--
OvmfPkg/OvmfPkgIa32.dsc | 1 -
OvmfPkg/OvmfPkgIa32X64.dsc | 1 -
OvmfPkg/OvmfPkgX64.dsc | 1 -
OvmfPkg/PlatformPei/PlatformPei.inf | 1 -
7 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
index 7a8beb3..45d187e 100644
--- a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
+++ b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
@@ -676,7 +676,7 @@ InitializeFvAndVariableStoreHeaders (
// UINT32 Size;
(
- FixedPcdGet32 (PcdVariableStoreSize) -
+ FixedPcdGet32 (PcdFlashNvStorageVariableSize) -
OFFSET_OF (FVB_FV_HDR_AND_VARS_TEMPLATE, VarHdr)
),
@@ -745,7 +745,7 @@ InitializeFvAndVariableStoreHeaders (
// UINT32 Size;
(
- FixedPcdGet32 (PcdVariableStoreSize) -
+ FixedPcdGet32 (PcdFlashNvStorageVariableSize) -
OFFSET_OF (FVB_FV_HDR_AND_VARS_TEMPLATE, VarHdr)
),
@@ -810,7 +810,7 @@ FvbInitialize (
// Verify that the PCD's are set correctly.
//
if (
- (PcdGet32 (PcdVariableStoreSize) +
+ (PcdGet32 (PcdFlashNvStorageVariableSize) +
PcdGet32 (PcdFlashNvStorageFtwWorkingSize)
) >
EMU_FVB_BLOCK_SIZE
@@ -867,7 +867,7 @@ FvbInitialize (
//
// Initialize the Fault Tolerant Write data area
//
- SubPtr = (VOID*) ((UINT8*) Ptr + PcdGet32 (PcdVariableStoreSize));
+ SubPtr = (VOID*) ((UINT8*) Ptr + PcdGet32 (PcdFlashNvStorageVariableSize));
PcdSet32 (PcdFlashNvStorageFtwWorkingBase, (UINT32)(UINTN) SubPtr);
//
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index fc9f9cc..1128abb 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -721,7 +721,7 @@
gEfiMdeModulePkgTokenSpaceGuid.PcdHelloWorldPrintString|L"UEFI Hello
World!\n"|VOID*|0x40000004
## This PCD defines a reserved memory range for the EMU Variable driver's NV
Variable Store
- # The range is valid if non-zero. The memory range size must be
PcdVariableStoreSize.
+ # The range is valid if non-zero. The memory range size must be
PcdFlashNvStorageVariableSize.
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0|UINT64|0x40000008
## This PCD specifies whether the Single Root I/O virtualization support.
diff --git a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
index 4d4827d..2a31662 100644
--- a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
+++ b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
@@ -57,12 +57,11 @@
gEfiDevicePathProtocolGuid # PROTOCOL ALWAYS_PRODUCED
[FixedPcd]
- gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
[Pcd]
- gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 40ea397..264fd86 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -279,7 +279,6 @@
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x400
!endif
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxHardwareErrorVariableSize|0x8000
- gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xc000
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0xc000
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x2000
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x10000
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 106ba42..470cc07 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -284,7 +284,6 @@
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x400
!endif
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxHardwareErrorVariableSize|0x8000
- gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xc000
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0xc000
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x2000
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x10000
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 31690cc..563d130 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -284,7 +284,6 @@
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x400
!endif
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxHardwareErrorVariableSize|0x8000
- gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xc000
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0xc000
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x2000
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x10000
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 3d5cbbb..bfe333c 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -61,7 +61,6 @@
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfMemFvBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfMemFvSize
gUefiOvmfPkgTokenSpaceGuid.PcdAcpiPmBaseAddress
- gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved
--
1.8.3.1
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
