On 01/27/14 23:01, Bill Paul wrote:
> Hello all:
>
> I have some questions related to what I think is a recent change in the OVMF
> code.
>
> I checked out the EDK2 code to build a set of OVMF images for use with QEMU.
> I'm using QEMU 1.1.1 on FreeBSD/amd64 9.1-RELEASE.
>
> When I did the svn checkout, I got revision 15189.
>
> I was able to build the firmware for both IA32 and X64 (after first setting
> up
> the cross-compiler environment with mingw-gcc-build.py and building the
> BaseTools for FreeBSD). I used the general UNIX-based instructions, and for
> the most part, building OVMF on FreeBSD is pretty painless. (The only real
> nit
> is that edk2/BaseTools/Source/C/GenFv/GenFvInternalLib.c wants <uuid/uuid.h>,
> but on FreeBSD it's just <uuid.h>. Everything else works just like it says on
> the box.)
>
> I added the openssl patch to the CryptoPkg patch and built with the following
> commands:
>
> build -a X64 -p OvmfPkg/OvmfPkgX64.dsc \
> -DFD_SIZE_2MB -DSECURE_BOOT_ENABLE=TRUE
>
> build -a IA32 -p OvmfPkg/OvmfPkgIa32.dsc \
> -DFD_SIZE_2MB -DSECURE_BOOT_ENABLE=TRUE
>
> The resulting OVMF images boot up and run with QEMU just fine, however I
> noticed one major difference in behavior compared to the images that I built
> the last time around (which was back in April/May of last year).
>
> The difference is in the memory map. There is a large (2MB) block at address
> 0x820000 marked as ACPI NVS. Below is the output from memmap run from the
> shell that shows this (this is with a simulation using qemu-system-x86-64
> using 2GB of RAM):
>
> [...]
> Shell> memmap -b
> Type Start End #pages Attributes
> Available 0000000000000000-000000000009FFFF 00000000000000A0 000000000000000F
> Available 0000000000100000-000000000081FFFF 0000000000000720 000000000000000F
> ACPI_NVS 0000000000820000-00000000008FFFFF 00000000000000E0 000000000000000F
> BS_Data 0000000000900000-0000000000FFFFFF 0000000000000700 000000000000000F
> Available 0000000001000000-000000007BFFFFFF 000000000007B000 000000000000000F
> BS_Data 000000007C000000-000000007C01FFFF 0000000000000020 000000000000000F
> Available 000000007C020000-000000007E32EFFF 000000000000230F 000000000000000F
> BS_Data 000000007E32F000-000000007E353FFF 0000000000000025 000000000000000F
> Available 000000007E354000-000000007E364FFF 0000000000000011 000000000000000F
> BS_Data 000000007E365000-000000007E49AFFF 0000000000000136 000000000000000F
> LoaderCode 000000007E49B000-000000007E56EFFF 00000000000000D4 000000000000000F
> BS_Data 000000007E56F000-000000007EA29FFF 00000000000004BB 000000000000000F
> BS_Code 000000007EA2A000-000000007EC0BFFF 00000000000001E2 000000000000000F
> RT_Data 000000007EC0C000-000000007ECBEFFF 00000000000000B3 800000000000000F
> RT_Code 000000007ECBF000-000000007ED51FFF 0000000000000093 800000000000000F
> BS_Data 000000007ED52000-000000007FD51FFF 0000000000001000 000000000000000F
> Available 000000007FD52000-000000007FD53FFF 0000000000000002 000000000000000F
> BS_Code 000000007FD54000-000000007FED1FFF 000000000000017E 000000000000000F
> RT_Code 000000007FED2000-000000007FF01FFF 0000000000000030 800000000000000F
> RT_Data 000000007FF02000-000000007FF25FFF 0000000000000024 800000000000000F
> Reserved 000000007FF26000-000000007FF29FFF 0000000000000004 000000000000000F
> ACPIRec 000000007FF2A000-000000007FF31FFF 0000000000000008 000000000000000F
> ACPI_NVS 000000007FF32000-000000007FF35FFF 0000000000000004 000000000000000F
> BS_Data 000000007FF36000-000000007FFCFFFF 000000000000009A 000000000000000F
> RT_Data 000000007FFD0000-000000007FFFFFFF 0000000000000030 800000000000000F
> RT_Data 00000000FFE00000-00000000FFFFFFFF 0000000000000200 8000000000000001
> Reserved : 4 Pages (16,384)
> LoaderCode: 212 Pages (868,352)
> LoaderData: 0 Pages (0)
> BS_Code : 864 Pages (3,538,944)
> BS_Data : 7,632 Pages (31,260,672)
> RT_Code : 195 Pages (798,720)
> RT_Data : 775 Pages (3,174,400)
> ACPI Recl : 8 Pages (32,768)
> ACPI NVS : 228 Pages (933,888)
> MMIO : 0 Pages (0)
> Available : 514,786 Pages (2,108,563,456)
> Total Memory: 2049 MB (2,149,187,584 Bytes)
> [...]
>
> After some investigation, I found that this has to do with the following code
> in OvmfPkg/PlatformPei/Fv.c:
>
> [...]
> DEBUG ((EFI_D_INFO, "Platform PEI Firmware Volume Initialization\n"));
>
> //
> // Create a memory allocation HOB for the PEI FV.
> //
> // This is marked as ACPI NVS so it will still be available on S3 resume.
> //
> BuildMemoryAllocationHob (
> PcdGet32 (PcdOvmfPeiMemFvBase),
> PcdGet32 (PcdOvmfPeiMemFvSize),
> EfiACPIMemoryNVS
> );
> [...]
>
> The PeiFv address is set to 0x800000 in OvmfPkgX64.fdf and OvmfPkgIa32.fdf:
>
> [...]
> [FD.MEMFD]
> BaseAddress = 0x800000
> Size = 0x800000
> ErasePolarity = 1
> BlockSize = 0x10000
> NumBlocks = 0x80
>
> 0x000000|0x006000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
>
> 0x010000|0x008000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
>
> 0x020000|0x0E0000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
> FV = PEIFV
>
> 0x100000|0x700000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
> FV = DXEFV
> [...]
>
> My questions are:
>
> - What exactly is this block for? It's not clear to me what the PEI module
> does, though it seems to have something to do with bootstrapping the firmware
> out of the flash region. Once the firmware is up and running, does this
> really
> need to be preserved?
It must be preserved.
Jordan is in the middle of adding S3 suspend/resume support to OVMF. The
most recent posted version was
[edk2] [PATCH v4 00/26] S3 suspend/resume for OVMF
The first eight patches have been pushed (ending at SVN r15151), and
that's what you're seeing. It's not a bug, it's just that the actual use
case for this code is not visible in the tree yet.
The use case is (going to be): at S3 resume, the VM is actually re-set,
and the firmware starts to run from the beginning. It has to overwrite
some RAM areas unconditionally to be able to run, and it needs some RAM
areas to stay intact from the time of the very first cold boot.
The area you've identified belongs to the second category. It contains a
firmware volume that holds the various PEI modules that must run at both
normal startup and at S3 resume. The OS must not trample over this area
during runtime because the modules will be needed after you suspend and
wake the VM. The OS is instructed to stay away by marking the area in
the memory map as ACPI NVS.
> - If it must be preserved, is there any way to move this to some other
> location in RAM? (I tried fiddling with the BaseAddress value in the .fdf
> files, and that helps, but that's not really a portable solution.
>
> It happens that, at least for me, this block creates a memory hole in the
> worst possible location. I can work around the problem a bit by changing the
> BaseAddress shown above to a location a bit higher up in RAM, but something
> tells me there's got to be a better way.
Placing this string of areas at 0x800000 is quite arbitrary for us, as
far as I know. I believe (without doing any investigation) that we could
move it a bit around, but it must stay low. The decompression happens at
an early stage.
Why does it bother you where it is right now? What conflict do you see?
Additionally, after the full S3 support series committed, further code
will be added to honor the case when the user disables S3 on the qemu
command line ("-global PIIX4_PM.disable_s3=1"). Then the memory
allocation in question will be qualified as Boot Services Data (rather
than ACPI NVS), and the OS will be able to drop it after transitioning
to runtime.
Laszlo
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
