OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c | 53 +++++++ OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf | 48 +++++++ OvmfPkg/OvmfPkg.dec | 6 + OvmfPkg/OvmfPkgIa32.dsc | 15 +- OvmfPkg/OvmfPkgIa32.fdf | 8 +- OvmfPkg/OvmfPkgIa32X64.dsc | 15 +- OvmfPkg/OvmfPkgIa32X64.fdf | 8 +- OvmfPkg/OvmfPkgX64.dsc | 15 +- OvmfPkg/OvmfPkgX64.fdf | 8 +- OvmfPkg/PlatformPei/MemTypeInfo.c | 151 ++++++++++++++++++++ OvmfPkg/PlatformPei/Platform.c | 26 +--- OvmfPkg/PlatformPei/Platform.h | 5 + OvmfPkg/PlatformPei/PlatformPei.inf | 3 + OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 1 + OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf | 1 + OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c | 58 +++++--- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c | 1 + OvmfPkg/README | 10 ++ 18 files changed, 385 insertions(+), 47 deletions(-) create mode 100644 OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c create mode 100644 OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf create mode 100644 OvmfPkg/PlatformPei/MemTypeInfo.c
Repo: https://github.com/lersek/edk2.git Branch: memmap_defrag_v2 This version is identical to the v1 seres I posted in March. Some patches of the v1 series have been committed. I've been rebasing and using the rest since, and am now posting it as v2. References: * https://bugzilla.tianocore.org/show_bug.cgi?id=386 * http://mid.mail-archive.com/20170314233246.17864-1-lersek@redhat.com https://lists.01.org/pipermail/edk2-devel/2017-March/008525.html * http://mid.mail-archive.com/20170327080544.24748-1-jordan.l.justen@intel.com https://lists.01.org/pipermail/edk2-devel/2017-March/009049.html Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Thanks Laszlo Laszlo Ersek (8): OvmfPkg: introduce PcdMemVarstoreEmuEnable feature flag OvmfPkg/QemuFlashFvbServicesRuntimeDxe: check PcdMemVarstoreEmuEnable OvmfPkg: conditionally disable reserved memory varstore emulation at build OvmfPkg: introduce FlashNvStorageAddressLib OvmfPkg: include FaultTolerantWritePei and VariablePei OvmfPkg/QemuFlashFvbServicesRuntimeDxe: don't set flash PCDs if SMM or no-emu OvmfPkg/PlatformPei: remedy UEFI memory map fragmentation OvmfPkg/README: document MEM_VARSTORE_EMU_ENABLE and memmap defrag OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c | 53 +++++++ OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf | 48 +++++++ OvmfPkg/OvmfPkg.dec | 6 + OvmfPkg/OvmfPkgIa32.dsc | 15 +- OvmfPkg/OvmfPkgIa32.fdf | 8 +- OvmfPkg/OvmfPkgIa32X64.dsc | 15 +- OvmfPkg/OvmfPkgIa32X64.fdf | 8 +- OvmfPkg/OvmfPkgX64.dsc | 15 +- OvmfPkg/OvmfPkgX64.fdf | 8 +- OvmfPkg/PlatformPei/MemTypeInfo.c | 151 ++++++++++++++++++++ OvmfPkg/PlatformPei/Platform.c | 26 +--- OvmfPkg/PlatformPei/Platform.h | 5 + OvmfPkg/PlatformPei/PlatformPei.inf | 3 + OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 1 + OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf | 1 + OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c | 58 +++++--- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c | 1 + OvmfPkg/README | 10 ++ 18 files changed, 385 insertions(+), 47 deletions(-) create mode 100644 OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c create mode 100644 OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf create mode 100644 OvmfPkg/PlatformPei/MemTypeInfo.c -- 2.14.1.3.gb7cf6e02401b _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
As I recall, this enables a modest (non-essential) improvement in fragmentation, at the cost of more ways to configure OVMF to hang during boot. (With info available via debugcon.) I would prefer if were able to always fallback and continue boot. Later, after GOP has started we could visibly warn the user that they haven't properly enabled SMM and/or flash. If we had a way to do this, I would be in favor of displaying an error message and delaying for 30 seconds before booting if flash has not been enabled. (Or, if SMM was enabled in the build, but not set on the command line.) At that point, I think we could start to transition to making flash an boot requirement for OVMF. But first we need to be able to visibly warn the user why they are not able to boot. -Jordan On 2017-11-30 08:30:21, Laszlo Ersek wrote: > Repo: https://github.com/lersek/edk2.git > Branch: memmap_defrag_v2 > > This version is identical to the v1 seres I posted in March. Some > patches of the v1 series have been committed. I've been rebasing and > using the rest since, and am now posting it as v2. References: > > * https://bugzilla.tianocore.org/show_bug.cgi?id=386 > > * http://mid.mail-archive.com/20170314233246.17864-1-lersek@redhat.com > https://lists.01.org/pipermail/edk2-devel/2017-March/008525.html > > * http://mid.mail-archive.com/20170327080544.24748-1-jordan.l.justen@intel.com > https://lists.01.org/pipermail/edk2-devel/2017-March/009049.html > > Cc: Anthony Perard <anthony.perard@citrix.com> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> > Cc: Jordan Justen <jordan.l.justen@intel.com> > Cc: Julien Grall <julien.grall@linaro.org> > > Thanks > Laszlo > > Laszlo Ersek (8): > OvmfPkg: introduce PcdMemVarstoreEmuEnable feature flag > OvmfPkg/QemuFlashFvbServicesRuntimeDxe: check PcdMemVarstoreEmuEnable > OvmfPkg: conditionally disable reserved memory varstore emulation at > build > OvmfPkg: introduce FlashNvStorageAddressLib > OvmfPkg: include FaultTolerantWritePei and VariablePei > OvmfPkg/QemuFlashFvbServicesRuntimeDxe: don't set flash PCDs if SMM or > no-emu > OvmfPkg/PlatformPei: remedy UEFI memory map fragmentation > OvmfPkg/README: document MEM_VARSTORE_EMU_ENABLE and memmap defrag > > OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c | 53 +++++++ > OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf | 48 +++++++ > OvmfPkg/OvmfPkg.dec | 6 + > OvmfPkg/OvmfPkgIa32.dsc | 15 +- > OvmfPkg/OvmfPkgIa32.fdf | 8 +- > OvmfPkg/OvmfPkgIa32X64.dsc | 15 +- > OvmfPkg/OvmfPkgIa32X64.fdf | 8 +- > OvmfPkg/OvmfPkgX64.dsc | 15 +- > OvmfPkg/OvmfPkgX64.fdf | 8 +- > OvmfPkg/PlatformPei/MemTypeInfo.c | 151 ++++++++++++++++++++ > OvmfPkg/PlatformPei/Platform.c | 26 +--- > OvmfPkg/PlatformPei/Platform.h | 5 + > OvmfPkg/PlatformPei/PlatformPei.inf | 3 + > OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 1 + > OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf | 1 + > OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c | 58 +++++--- > OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c | 1 + > OvmfPkg/README | 10 ++ > 18 files changed, 385 insertions(+), 47 deletions(-) > create mode 100644 OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c > create mode 100644 OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf > create mode 100644 OvmfPkg/PlatformPei/MemTypeInfo.c > > -- > 2.14.1.3.gb7cf6e02401b > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 30 November 2017 at 19:00, Jordan Justen <jordan.l.justen@intel.com> wrote: > As I recall, this enables a modest (non-essential) improvement in > fragmentation, at the cost of more ways to configure OVMF to hang > during boot. (With info available via debugcon.) > > I would prefer if were able to always fallback and continue boot. > Later, after GOP has started we could visibly warn the user that they > haven't properly enabled SMM and/or flash. > > If we had a way to do this, I would be in favor of displaying an error > message and delaying for 30 seconds before booting if flash has not > been enabled. (Or, if SMM was enabled in the build, but not set on the > command line.) > > At that point, I think we could start to transition to making flash an > boot requirement for OVMF. But first we need to be able to visibly > warn the user why they are not able to boot. > That doesn't argue against this series, does it? AFAICT it only argues against building OVMF with a non-default value for MEM_VARSTORE_EMU_ENABLE > On 2017-11-30 08:30:21, Laszlo Ersek wrote: >> Repo: https://github.com/lersek/edk2.git >> Branch: memmap_defrag_v2 >> >> This version is identical to the v1 seres I posted in March. Some >> patches of the v1 series have been committed. I've been rebasing and >> using the rest since, and am now posting it as v2. References: >> >> * https://bugzilla.tianocore.org/show_bug.cgi?id=386 >> >> * http://mid.mail-archive.com/20170314233246.17864-1-lersek@redhat.com >> https://lists.01.org/pipermail/edk2-devel/2017-March/008525.html >> >> * http://mid.mail-archive.com/20170327080544.24748-1-jordan.l.justen@intel.com >> https://lists.01.org/pipermail/edk2-devel/2017-March/009049.html >> >> Cc: Anthony Perard <anthony.perard@citrix.com> >> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> Cc: Jordan Justen <jordan.l.justen@intel.com> >> Cc: Julien Grall <julien.grall@linaro.org> >> >> Thanks >> Laszlo >> >> Laszlo Ersek (8): >> OvmfPkg: introduce PcdMemVarstoreEmuEnable feature flag >> OvmfPkg/QemuFlashFvbServicesRuntimeDxe: check PcdMemVarstoreEmuEnable >> OvmfPkg: conditionally disable reserved memory varstore emulation at >> build >> OvmfPkg: introduce FlashNvStorageAddressLib >> OvmfPkg: include FaultTolerantWritePei and VariablePei >> OvmfPkg/QemuFlashFvbServicesRuntimeDxe: don't set flash PCDs if SMM or >> no-emu >> OvmfPkg/PlatformPei: remedy UEFI memory map fragmentation >> OvmfPkg/README: document MEM_VARSTORE_EMU_ENABLE and memmap defrag >> >> OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c | 53 +++++++ >> OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf | 48 +++++++ >> OvmfPkg/OvmfPkg.dec | 6 + >> OvmfPkg/OvmfPkgIa32.dsc | 15 +- >> OvmfPkg/OvmfPkgIa32.fdf | 8 +- >> OvmfPkg/OvmfPkgIa32X64.dsc | 15 +- >> OvmfPkg/OvmfPkgIa32X64.fdf | 8 +- >> OvmfPkg/OvmfPkgX64.dsc | 15 +- >> OvmfPkg/OvmfPkgX64.fdf | 8 +- >> OvmfPkg/PlatformPei/MemTypeInfo.c | 151 ++++++++++++++++++++ >> OvmfPkg/PlatformPei/Platform.c | 26 +--- >> OvmfPkg/PlatformPei/Platform.h | 5 + >> OvmfPkg/PlatformPei/PlatformPei.inf | 3 + >> OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 1 + >> OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf | 1 + >> OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c | 58 +++++--- >> OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c | 1 + >> OvmfPkg/README | 10 ++ >> 18 files changed, 385 insertions(+), 47 deletions(-) >> create mode 100644 OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c >> create mode 100644 OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf >> create mode 100644 OvmfPkg/PlatformPei/MemTypeInfo.c >> >> -- >> 2.14.1.3.gb7cf6e02401b >> _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 12/01/17 09:42, Ard Biesheuvel wrote: > On 30 November 2017 at 19:00, Jordan Justen <jordan.l.justen@intel.com> wrote: >> As I recall, this enables a modest (non-essential) improvement in >> fragmentation, at the cost of more ways to configure OVMF to hang >> during boot. (With info available via debugcon.) >> >> I would prefer if were able to always fallback and continue boot. >> Later, after GOP has started we could visibly warn the user that they >> haven't properly enabled SMM and/or flash. >> >> If we had a way to do this, I would be in favor of displaying an error >> message and delaying for 30 seconds before booting if flash has not >> been enabled. (Or, if SMM was enabled in the build, but not set on the >> command line.) >> >> At that point, I think we could start to transition to making flash an >> boot requirement for OVMF. But first we need to be able to visibly >> warn the user why they are not able to boot. >> > > That doesn't argue against this series, does it? AFAICT it only argues > against building OVMF with a non-default value for > MEM_VARSTORE_EMU_ENABLE ... which is explicitly documented in patch 8. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 11/30/17 20:00, Jordan Justen wrote: > As I recall, this enables a modest (non-essential) improvement in > fragmentation, My testing from 2 minutes ago shows that the UEFI memmap (as dumped by the Linux guest) goes from 82 entries to 56 entries. I consider the defragmentation a QoS question, and the patch set an avenue to further features like S4. > at the cost of more ways to configure OVMF to hang > during boot. (With info available via debugcon.) Yes. The configuration is static, the default is sane, and distros can pretty well decide if they want it or not, same as with SMM_REQUIRE. (Some package providers offer multiple builds.) > I would prefer if were able to always fallback and continue boot. Sure, I would prefer that too. Can someone write it? - Flash detection in the PEI phase, using the SMM_REQUIRE build, would require OVMF to raise an SMI, enter SMM, do the detection, and propagate the result. - Assuming it works, all we get with it is that OVMF guests launched with the "-bios" flag (including all OVMF/Xen guests) will get a PEI phase r/o variable driver that has *zero* chance at returning actual variable contents (because it cannot read the \NvVars file from the ESP, even if there is such a partition and/or file.) Is the above worth it, for users and packagers that consciously set MEM_VARSTORE_EMU_ENABLE to FALSE at build, and then expect the binary to boot with "-bios"? > Later, after GOP has started we could visibly warn the user that they > haven't properly enabled SMM and/or flash. GOPs are provided by UEFI_DRIVER modules, generally. SMM/flash are required much earlier than that. Perhaps we could use status codes, and report them to the serial port. Then I assume the complaint would be that (a) users don't understand status codes, (b) users don't look at the serial port. > If we had a way to do this, I would be in favor of displaying an error > message and delaying for 30 seconds before booting if flash has not > been enabled. (Or, if SMM was enabled in the build, but not set on the > command line.) An SMM build *must not* boot on a misconfigured QEMU. > At that point, I think we could start to transition to making flash an > boot requirement for OVMF. But first we need to be able to visibly > warn the user why they are not able to boot. I don't think this is a reasonable requirement. First, the series does not make flash a requirement for OVMF, it allows packagers to make that choice. Which they already have to make if they consider SMM_REQUIRE. Second, up till very recent commit d1de487dd2e7 ("MdeModulePkg/BdsDxe: fall back to a Boot Manager Menu loop before hanging", 2017-11-22), OVMF (and edk2) wouldn't report a boot failure to the console that was caused by *much higher level* problems, such as booting a traditional BIOS / OS disk image without having a CSM and a built-in shell. And when I tried to introduce edk2-specific status codes for emitting more detail about the boot process to the user, to the system console, I was asked to talk to PIWG for standardizing the status codes first. So on one hand, you want me to report very low level boot requirement violations through a later, highly abstracted interface; and on the other hand, when I try to report details of the *same* high abstraction level, I'm directed to a standards body. I guess I give up. Thanks for your time. Laszlo > > -Jordan > > On 2017-11-30 08:30:21, Laszlo Ersek wrote: >> Repo: https://github.com/lersek/edk2.git >> Branch: memmap_defrag_v2 >> >> This version is identical to the v1 seres I posted in March. Some >> patches of the v1 series have been committed. I've been rebasing and >> using the rest since, and am now posting it as v2. References: >> >> * https://bugzilla.tianocore.org/show_bug.cgi?id=386 >> >> * http://mid.mail-archive.com/20170314233246.17864-1-lersek@redhat.com >> https://lists.01.org/pipermail/edk2-devel/2017-March/008525.html >> >> * http://mid.mail-archive.com/20170327080544.24748-1-jordan.l.justen@intel.com >> https://lists.01.org/pipermail/edk2-devel/2017-March/009049.html >> >> Cc: Anthony Perard <anthony.perard@citrix.com> >> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> Cc: Jordan Justen <jordan.l.justen@intel.com> >> Cc: Julien Grall <julien.grall@linaro.org> >> >> Thanks >> Laszlo >> >> Laszlo Ersek (8): >> OvmfPkg: introduce PcdMemVarstoreEmuEnable feature flag >> OvmfPkg/QemuFlashFvbServicesRuntimeDxe: check PcdMemVarstoreEmuEnable >> OvmfPkg: conditionally disable reserved memory varstore emulation at >> build >> OvmfPkg: introduce FlashNvStorageAddressLib >> OvmfPkg: include FaultTolerantWritePei and VariablePei >> OvmfPkg/QemuFlashFvbServicesRuntimeDxe: don't set flash PCDs if SMM or >> no-emu >> OvmfPkg/PlatformPei: remedy UEFI memory map fragmentation >> OvmfPkg/README: document MEM_VARSTORE_EMU_ENABLE and memmap defrag >> >> OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c | 53 +++++++ >> OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf | 48 +++++++ >> OvmfPkg/OvmfPkg.dec | 6 + >> OvmfPkg/OvmfPkgIa32.dsc | 15 +- >> OvmfPkg/OvmfPkgIa32.fdf | 8 +- >> OvmfPkg/OvmfPkgIa32X64.dsc | 15 +- >> OvmfPkg/OvmfPkgIa32X64.fdf | 8 +- >> OvmfPkg/OvmfPkgX64.dsc | 15 +- >> OvmfPkg/OvmfPkgX64.fdf | 8 +- >> OvmfPkg/PlatformPei/MemTypeInfo.c | 151 ++++++++++++++++++++ >> OvmfPkg/PlatformPei/Platform.c | 26 +--- >> OvmfPkg/PlatformPei/Platform.h | 5 + >> OvmfPkg/PlatformPei/PlatformPei.inf | 3 + >> OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 1 + >> OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf | 1 + >> OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c | 58 +++++--- >> OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c | 1 + >> OvmfPkg/README | 10 ++ >> 18 files changed, 385 insertions(+), 47 deletions(-) >> create mode 100644 OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c >> create mode 100644 OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf >> create mode 100644 OvmfPkg/PlatformPei/MemTypeInfo.c >> >> -- >> 2.14.1.3.gb7cf6e02401b >> _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
© 2016 - 2024 Red Hat, Inc.