summaryrefslogtreecommitdiff
path: root/BaseTools/Source/Python
diff options
context:
space:
mode:
authorMitchell Augustin <mitchell.augustin@canonical.com>2025-03-13 08:52:03 -0500
committermergify[bot] <37929162+mergify[bot]@users.noreply.github.com>2025-03-14 12:06:11 +0000
commit9ac1704af6645da45d20fb545294e308ef9c887e (patch)
treeb5d098cfcf39dc7b85496d7073b874062f18515d /BaseTools/Source/Python
parent2aff039da7a8443352f572cecb7ec8109455e7d8 (diff)
downloadedk2-9ac1704af6645da45d20fb545294e308ef9c887e.zip
edk2-9ac1704af6645da45d20fb545294e308ef9c887e.tar.gz
edk2-9ac1704af6645da45d20fb545294e308ef9c887e.tar.bz2
OvmfPkg: Use user-specified opt/ovmf/X-PciMmio64Mb value unconditionally
Prior to this change, OVMF considers opt/ovmf/X-PciMmio64Mb the minimum aperture size, allowing us to force the window to be larger but not smaller than what PlatformDynamicMmioWindow calculates. Adjust OVMF so that a smaller value for the aperture is honored. Context: Due to an inefficiency in the way older host kernels manage pfnmaps for guest VM memory ranges [0], guests with large-BAR GPUs passed-through have a very long (multiple minutes) initialization time when the MMIO window advertised by OVMF is sufficiently sized for the passed-through BARs (i.e., the correct OVMF behavior). However, on older distro series such as Ubuntu Jammy, users have benefited from fast guest boot times when OVMF advertised an MMIO window that was too small to accommodate the full BAR, since this resulted in the long PCI initialization process being skipped (and retried later, if pci=realloc pci=nocrs were set). While the root cause is being fully addressed in the upstream kernel [1], the solution relies on huge pfnmap support, which is a substantial series with many ABI changes that is unlikely to land in many LTS and legacy distro kernels, including those of Ubuntu Noble. As a result, the only kernel improvement supported on those kernels is this patch [2], which reduces the extra boot time by about half. Unfortunately, that boot time is still an average of 1-3 minutes longer per-VM-boot than what can be achieved when the host is running a version of OVMF without PlatformDynamicMmioWindow (PDMW) support (introduced in [3]) Since there is no way to force the use of the classic MMIO window size[4] in any version of OVMF after [3], and since we have a use case for such functionality on legacy distro kernels that would yield significant, recurring compute time savings across all impacted VMs, this change to this knob's behavior seems appropriate. [0]: https://lore.kernel.org/all/CAHTA-uYp07FgM6T1OZQKqAdSA5JrZo0ReNEyZgQZub4mDRrV5w@mail.gmail.com/ [1]: https://lore.kernel.org/all/20250205231728.2527186-1-alex.williamson@redhat.com/ [2]: https://lore.kernel.org/all/20250111210652.402845-1-alex.williamson@redhat.com/ [3]: ecb778d [4]: https://edk2.groups.io/g/devel/topic/109651206?p=Created,,,20,1,0,0 Signed-off-by: Mitchell Augustin <mitchell.augustin@canonical.com>
Diffstat (limited to 'BaseTools/Source/Python')
0 files changed, 0 insertions, 0 deletions