[edk2,4/4] ArmVirtPkg: add name GUIDs to FvMain instances

Message ID 1468314987-19885-5-git-send-email-ard.biesheuvel@linaro.org
State Superseded
Headers show

Commit Message

Ard Biesheuvel July 12, 2016, 9:16 a.m.
Assign name GUIDs to the FVs that may appear in DevicePath references to
things like the UiApp and the UEFI Shell. This prevents these device
paths from changing inadvertently when the FV ends up in a different
memory location due to external occurrences such as, e.g., a change in
the amount of system memory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

---
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 +
 ArmVirtPkg/ArmVirtXen.fdf            | 1 +
 2 files changed, 2 insertions(+)

-- 
1.9.1

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Comments

Laszlo Ersek July 12, 2016, 9:53 a.m. | #1
On 07/12/16 11:16, Ard Biesheuvel wrote:
> Assign name GUIDs to the FVs that may appear in DevicePath references to

> things like the UiApp and the UEFI Shell. This prevents these device

> paths from changing inadvertently when the FV ends up in a different

> memory location due to external occurrences such as, e.g., a change in

> the amount of system memory.


I didn't know (or remember) the amount of system memory might have an
effect on this. In OvmfPkg the locations are fixed and only change when
we change the FDF files manually.

How (and where) is FVMAIN_COMPACT's file's compressed section
decompressed in ArmVirtQemu, and ArmVirtQemuKernel?

Thanks
Laszlo

> Contributed-under: TianoCore Contribution Agreement 1.0

> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

> ---

>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 +

>  ArmVirtPkg/ArmVirtXen.fdf            | 1 +

>  2 files changed, 2 insertions(+)

> 

> diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc

> index 7bed6785d099..ad7037fe5f63 100644

> --- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc

> +++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc

> @@ -24,6 +24,7 @@

>  ################################################################################

>  

>  [FV.FvMain]

> +FvNameGuid         = 64074afe-340a-4be6-94ba-91b5b4d0f71e

>  BlockSize          = 0x40

>  NumBlocks          = 0         # This FV gets compressed so make it just big enough

>  FvAlignment        = 16        # FV alignment and FV attributes setting.

> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf

> index 653aa30b4d33..0a97bd8e07c6 100644

> --- a/ArmVirtPkg/ArmVirtXen.fdf

> +++ b/ArmVirtPkg/ArmVirtXen.fdf

> @@ -104,6 +104,7 @@ [FD.XEN_EFI]

>  ################################################################################

>  

>  [FV.FvMain]

> +FvNameGuid         = 4d2d8743-6337-4c3f-a1d9-7cc7efd283db

>  BlockSize          = 0x40

>  NumBlocks          = 0         # This FV gets compressed so make it just big enough

>  FvAlignment        = 16        # FV alignment and FV attributes setting.

> 


_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Ard Biesheuvel July 12, 2016, 10:09 a.m. | #2
On 12 July 2016 at 11:53, Laszlo Ersek <lersek@redhat.com> wrote:
> On 07/12/16 11:16, Ard Biesheuvel wrote:

>> Assign name GUIDs to the FVs that may appear in DevicePath references to

>> things like the UiApp and the UEFI Shell. This prevents these device

>> paths from changing inadvertently when the FV ends up in a different

>> memory location due to external occurrences such as, e.g., a change in

>> the amount of system memory.

>

> I didn't know (or remember) the amount of system memory might have an

> effect on this. In OvmfPkg the locations are fixed and only change when

> we change the FDF files manually.

>

> How (and where) is FVMAIN_COMPACT's file's compressed section

> decompressed in ArmVirtQemu, and ArmVirtQemuKernel?

>



To be honest, I noticed it on a bare metal platform (AMD Seattle), and
extrapolated. But as you know, AARCH64 does not distinguish between <
4 GB and >= 4GB, and so it will typically attempt to decompress it as
high up in memory as it can.

In ArmVirtQemu's case, the FV is decompressed by PEI core (in response
to a PPI invocation done by DxeIpl which looks for the DXE core image)
, and in the PrePi case (ArmVirtQemuKernel and ArmVirtXen), we use
PrePiLib in EmbeddedPkg, since we skip PEI core entirely in that case.
I'm not sure where exactly the difference lies between OVMF and
ArmVirtQemu, but I could not find any code that allocates a fixed
address to decompress FvMain.

-- 
Ard.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Laszlo Ersek July 12, 2016, 10:56 a.m. | #3
On 07/12/16 12:09, Ard Biesheuvel wrote:
> On 12 July 2016 at 11:53, Laszlo Ersek <lersek@redhat.com> wrote:

>> On 07/12/16 11:16, Ard Biesheuvel wrote:

>>> Assign name GUIDs to the FVs that may appear in DevicePath references to

>>> things like the UiApp and the UEFI Shell. This prevents these device

>>> paths from changing inadvertently when the FV ends up in a different

>>> memory location due to external occurrences such as, e.g., a change in

>>> the amount of system memory.

>>

>> I didn't know (or remember) the amount of system memory might have an

>> effect on this. In OvmfPkg the locations are fixed and only change when

>> we change the FDF files manually.

>>

>> How (and where) is FVMAIN_COMPACT's file's compressed section

>> decompressed in ArmVirtQemu, and ArmVirtQemuKernel?

>>

> 

> 

> To be honest, I noticed it on a bare metal platform (AMD Seattle), and

> extrapolated. But as you know, AARCH64 does not distinguish between <

> 4 GB and >= 4GB, and so it will typically attempt to decompress it as

> high up in memory as it can.

> 

> In ArmVirtQemu's case, the FV is decompressed by PEI core (in response

> to a PPI invocation done by DxeIpl which looks for the DXE core image)

> , and in the PrePi case (ArmVirtQemuKernel and ArmVirtXen), we use

> PrePiLib in EmbeddedPkg, since we skip PEI core entirely in that case.

> I'm not sure where exactly the difference lies between OVMF and

> ArmVirtQemu, but I could not find any code that allocates a fixed

> address to decompress FvMain.

> 


Ahh I got confused for a minute, sorry -- I forgot that in ArmVirtPkg
the PEIMs are stored uncompressed and actually execute from flash. I was
looking for a SEC module or library doing the decompression, but that's
completely unjustified for ArmVirtPkg then.

So, the commit message certainly makes sense with your explanation, and
I can easily reproduce the symptom (-> multiple UEFI shell boot options)
just by changing the -m option passed to QEMU.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Patch

diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index 7bed6785d099..ad7037fe5f63 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -24,6 +24,7 @@ 
 ################################################################################
 
 [FV.FvMain]
+FvNameGuid         = 64074afe-340a-4be6-94ba-91b5b4d0f71e
 BlockSize          = 0x40
 NumBlocks          = 0         # This FV gets compressed so make it just big enough
 FvAlignment        = 16        # FV alignment and FV attributes setting.
diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
index 653aa30b4d33..0a97bd8e07c6 100644
--- a/ArmVirtPkg/ArmVirtXen.fdf
+++ b/ArmVirtPkg/ArmVirtXen.fdf
@@ -104,6 +104,7 @@  [FD.XEN_EFI]
 ################################################################################
 
 [FV.FvMain]
+FvNameGuid         = 4d2d8743-6337-4c3f-a1d9-7cc7efd283db
 BlockSize          = 0x40
 NumBlocks          = 0         # This FV gets compressed so make it just big enough
 FvAlignment        = 16        # FV alignment and FV attributes setting.