Branch: refs/heads/master
Home: https://github.com/tianocore/edk2
Commit: 8f9ef9c9a064839644ceca89df52a3693744a685
https://github.com/tianocore/edk2/commit/8f9ef9c9a064839644ceca89df52a3693744a685
Author: Gerd Hoffmann <kra...@redhat.com>
Date: 2022-10-07 (Fri, 07 Oct 2022)
Changed paths:
M OvmfPkg/Library/PlatformInitLib/MemDetect.c
Log Message:
-----------
OvmfPkg/PlatformInitLib: qemu cpuid physbits detection
Add some qemu specific quirks to PlatformAddressWidthFromCpuid()
to figure whenever the PhysBits value returned by CPUID is
something real we can work with or not.
See the source code comment for details on the logic.
Also apply some limits to the address space we are going to use:
* Place a hard cap at 47 PhysBits (128 TB) to avoid using addresses
which require 5-level paging support.
* Cap at 40 PhysBits (1 TB) in case the CPU has no support for
gigabyte pages, to avoid excessive amounts of pages being
used for page tables.
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Reviewed-by: Ard Biesheuvel <a...@kernel.org>
Commit: bbda386d25e5316445a9bd67c45b47ce248eeb25
https://github.com/tianocore/edk2/commit/bbda386d25e5316445a9bd67c45b47ce248eeb25
Author: Gerd Hoffmann <kra...@redhat.com>
Date: 2022-10-07 (Fri, 07 Oct 2022)
Changed paths:
M OvmfPkg/Library/PlatformInitLib/MemDetect.c
Log Message:
-----------
OvmfPkg/PlatformInitLib: detect physical address space
Try detect physical address space, when successful use it.
Otherwise go continue using the current guesswork code path.
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Reviewed-by: Ard Biesheuvel <a...@kernel.org>
Commit: ecb778d0ac62560aa172786ba19521f27bc3f650
https://github.com/tianocore/edk2/commit/ecb778d0ac62560aa172786ba19521f27bc3f650
Author: Gerd Hoffmann <kra...@redhat.com>
Date: 2022-10-07 (Fri, 07 Oct 2022)
Changed paths:
M OvmfPkg/Library/PlatformInitLib/MemDetect.c
Log Message:
-----------
OvmfPkg/PlatformInitLib: dynamic mmio window size
In case we have a reliable PhysMemAddressWidth use that to dynamically
size the 64bit address window. Allocate 1/8 of the physical address
space and place the window at the upper end of the address space.
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Reviewed-by: Ard Biesheuvel <a...@kernel.org>
Commit: 9e6b552b4c48bed39e9b8a2936d390fb5b95e07d
https://github.com/tianocore/edk2/commit/9e6b552b4c48bed39e9b8a2936d390fb5b95e07d
Author: Gerd Hoffmann <kra...@redhat.com>
Date: 2022-10-07 (Fri, 07 Oct 2022)
Changed paths:
M OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.c
M OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
Log Message:
-----------
OvmfPkg/PciHotPlugInitDxe: reserve more mmio space
In case the 64-bit pci mmio window is larger than the default size
of 32G be generous and hand out larger chunks of address space for
prefetchable mmio bridge windows.
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Reviewed-by: Ard Biesheuvel <a...@kernel.org>
Reviewed-by: Laszlo Ersek <ler...@redhat.com>
Commit: 8916a4f67f3c371b53ab4b0a09a697d40fea44ea
https://github.com/tianocore/edk2/commit/8916a4f67f3c371b53ab4b0a09a697d40fea44ea
Author: Gerd Hoffmann <kra...@redhat.com>
Date: 2022-10-07 (Fri, 07 Oct 2022)
Changed paths:
M OvmfPkg/Microvm/MicrovmX64.dsc
Log Message:
-----------
OvmfPkg/Microvm: add SECURE_BOOT_FEATURE_ENABLED
Compiler flag is needed to make (stateless) secure boot be actually
secure, i.e. restore EFI variables from ROM on reset.
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Reviewed-by: Ard Biesheuvel <a...@kernel.org>
Commit: 336133660715a08d2b8b1660ea86ef003d6854c4
https://github.com/tianocore/edk2/commit/336133660715a08d2b8b1660ea86ef003d6854c4
Author: Gerd Hoffmann <kra...@redhat.com>
Date: 2022-10-07 (Fri, 07 Oct 2022)
Changed paths:
M OvmfPkg/Microvm/MicrovmX64.dsc
M OvmfPkg/Microvm/MicrovmX64.fdf
Log Message:
-----------
Revert "OvmfPkg/Microvm: no secure boot"
This reverts commit 60d55c4156523e5dfb316b7c0c445b96c8f8be81.
Now that we have stateless secure boot support (which doesn't
need SMM) in OVMF we can enable the build option for MicroVM.
Bring it back by reverting the commit removing it.
Also add the new PlatformPKProtectionLib.
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Reviewed-by: Ard Biesheuvel <a...@kernel.org>
Commit: 406ad0582a3df7af498ec4f0adee1a95ceeae64f
https://github.com/tianocore/edk2/commit/406ad0582a3df7af498ec4f0adee1a95ceeae64f
Author: Gerd Hoffmann <kra...@redhat.com>
Date: 2022-10-07 (Fri, 07 Oct 2022)
Changed paths:
M OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
M OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
M OvmfPkg/OvmfPkg.dec
Log Message:
-----------
OvmfPkg: rename QemuBootOrderNNNN to VMMBootOrderNNNN
While the actual implementation (using qemu fw_cfg) is qemu-specific,
the idea to store the boot order as configured by the VMM in EFI
variables is not. So lets give the variables a more neutral name while
we still can (i.e. no stable tag yet with the new feature).
While being at it also fix the NNNN format (use %x instead of %d for
consistency with BootNNNN).
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Reviewed-by: Ard Biesheuvel <a...@kernel.org>
Compare: https://github.com/tianocore/edk2/compare/5ff7d712d489...406ad0582a3d
_______________________________________________
edk2-commits mailing list
edk2-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-commits
