kernel/linux.git/arch/x86/platform, branch v6.6.131

x86/efi: efi_unmap_boot_services: fix calculation of ranges_to_free size

2026-04-02T11:07:22+00:00

[ Upstream commit 217c0a5c177a3d4f7c8497950cbf5c36756e8bbb ] ranges_to_free array should have enough room to store the entire EFI memmap plus an extra element for NULL entry. The calculation of this array size wrongly adds 1 to the overall size instead of adding 1 to the number of elements. Add parentheses to properly size the array. Reported-by: Guenter Roeck Fixes: a4b0bf6a40f3 ("x86/efi: defer freeing of boot services memory") Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

x86/efi: defer freeing of boot services memory

2026-03-25T10:05:36+00:00

commit a4b0bf6a40f3c107c67a24fbc614510ef5719980 upstream. efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete. Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM. If the freed memory resides in the areas that memory map for them is still uninitialized, they won't be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages. Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map. Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that's undesirable late in boot when there is concurrency. More robust approach is to only defer freeing of the EFI boot services memory. Split efi_free_boot_services() in two. First efi_unmap_boot_services() collects ranges that should be freed into an array then efi_free_boot_services() later frees them after deferred init is complete. Link: https://lore.kernel.org/all/ec2aaef14783869b3be6e3c253b2dcbf67dbc12a.camel@kernel.crashing.org Fixes: 916f676f8dc0 ("x86, efi: Retain boot service code until after switching to virtual mode") Cc: Signed-off-by: Mike Rapoport (Microsoft) Reviewed-by: Benjamin Herrenschmidt Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman

x86/xen/pvh: Enable PAE mode for 32-bit guest only when CONFIG_X86_PAE is set

2026-03-04T12:20:33+00:00

[ Upstream commit db9aded979b491a24871e1621cd4e8822dbca859 ] The PVH entry is available for 32-bit KVM guests, and 32-bit KVM guests do not depend on CONFIG_X86_PAE. However, mk_early_pgtbl_32() builds different pagetables depending on whether CONFIG_X86_PAE is set. Therefore, enabling PAE mode for 32-bit KVM guests without CONFIG_X86_PAE being set would result in a boot failure during CR3 loading. Signed-off-by: Hou Wenlong Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: Signed-off-by: Sasha Levin

x86/pvh: Call C code via the kernel virtual mapping

2025-05-02T05:51:02+00:00

commit e8fbc0d9cab6c1ee6403f42c0991b0c1d5dbc092 upstream. Calling C code via a different mapping than it was linked at is problematic, because the compiler assumes that RIP-relative and absolute symbol references are interchangeable. GCC in particular may use RIP-relative per-CPU variable references even when not using -fpic. So call xen_prepare_pvh() via its kernel virtual mapping on x86_64, so that those RIP-relative references produce the correct values. This matches the pre-existing behavior for i386, which also invokes xen_prepare_pvh() via the kernel virtual mapping before invoking startup_32 with paging disabled again. Fixes: 7243b93345f7 ("xen/pvh: Bootstrap PVH guest") Tested-by: Jason Andryuk Reviewed-by: Jason Andryuk Signed-off-by: Ard Biesheuvel Message-ID: <20241009160438.3884381-8-ardb+git@google.com> Signed-off-by: Juergen Gross [ Stable context update ] Signed-off-by: Jason Andryuk Signed-off-by: Greg Kroah-Hartman

x86/xen: fix memblock_reserve() usage on PVH

2025-04-25T08:45:55+00:00

commit 4c006734898a113a64a528027274a571b04af95a upstream. The current usage of memblock_reserve() in init_pvh_bootparams() is done before the .bss is zeroed, and that used to be fine when memblock_reserved_init_regions implicitly ended up in the .meminit.data section. However after commit 73db3abdca58c memblock_reserved_init_regions ends up in the .bss section, thus breaking it's usage before the .bss is cleared. Move and rename the call to xen_reserve_extra_memory() so it's done in the x86_init.oem.arch_setup hook, which gets executed after the .bss has been zeroed, but before calling e820__memory_setup(). Fixes: 73db3abdca58c ("init/modpost: conditionally check section mismatch to __meminit*") Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Message-ID: <20240725073116.14626-3-roger.pau@citrix.com> Signed-off-by: Juergen Gross [ Context fixup for hypercall_page removal ] Signed-off-by: Jason Andryuk Signed-off-by: Greg Kroah-Hartman

Revert "x86/pvh: Set phys_base when calling xen_prepare_pvh()"

2024-12-11T15:13:43+00:00

This reverts commit f662b4a69e1d6c15db3354de6fc9f923417a5a10 which is commit b464b461d27d564125db760938643374864c1b1f upstream. It causes boot failures of domU guests, and should be reverted. Cc: Jason Andryuk Cc: Juergen Gross Cc: Sasha Levin Cc: Ard Biesheuvel Reported-by: Marek Marczykowski-Górecki Link: https://lore.kernel.org/r/Z1l6XbHP6BTTZSwr@mail-itl Signed-off-by: Greg Kroah-Hartman

Revert "x86/pvh: Call C code via the kernel virtual mapping"

2024-12-11T15:13:42+00:00

This reverts commit 83d123e27623713dd69eed2569eacf5f1b3c9033 which is commit e8fbc0d9cab6c1ee6403f42c0991b0c1d5dbc092 upstream. It causes boot failures of domU guests, and should be reverted. Cc: Jason Andryuk Cc: Ard Biesheuvel Cc: Juergen Gross Cc: Sasha Levin Reported-by: Marek Marczykowski-Górecki Link: https://lore.kernel.org/r/Z1l6XbHP6BTTZSwr@mail-itl Signed-off-by: Greg Kroah-Hartman

x86/pvh: Call C code via the kernel virtual mapping

2024-12-09T09:31:43+00:00

[ Upstream commit e8fbc0d9cab6c1ee6403f42c0991b0c1d5dbc092 ] Calling C code via a different mapping than it was linked at is problematic, because the compiler assumes that RIP-relative and absolute symbol references are interchangeable. GCC in particular may use RIP-relative per-CPU variable references even when not using -fpic. So call xen_prepare_pvh() via its kernel virtual mapping on x86_64, so that those RIP-relative references produce the correct values. This matches the pre-existing behavior for i386, which also invokes xen_prepare_pvh() via the kernel virtual mapping before invoking startup_32 with paging disabled again. Fixes: 7243b93345f7 ("xen/pvh: Bootstrap PVH guest") Tested-by: Jason Andryuk Reviewed-by: Jason Andryuk Signed-off-by: Ard Biesheuvel Message-ID: <20241009160438.3884381-8-ardb+git@google.com> Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin

x86/pvh: Set phys_base when calling xen_prepare_pvh()

2024-12-09T09:31:43+00:00

[ Upstream commit b464b461d27d564125db760938643374864c1b1f ] phys_base needs to be set for __pa() to work in xen_pvh_init() when finding the hypercall page. Set it before calling into xen_prepare_pvh(), which calls xen_pvh_init(). Clear it afterward to avoid __startup_64() adding to it and creating an incorrect value. Signed-off-by: Jason Andryuk Reviewed-by: Juergen Gross Message-ID: <20240823193630.2583107-4-jason.andryuk@amd.com> Signed-off-by: Juergen Gross Stable-dep-of: e8fbc0d9cab6 ("x86/pvh: Call C code via the kernel virtual mapping") Signed-off-by: Sasha Levin

x86/platform/iosf_mbi: Convert PCIBIOS_* return codes to errnos

2024-08-03T06:53:21+00:00

[ Upstream commit 7821fa101eab529521aa4b724bf708149d70820c ] iosf_mbi_pci_{read,write}_mdr() use pci_{read,write}_config_dword() that return PCIBIOS_* codes but functions also return -ENODEV which are not compatible error codes. As neither of the functions are related to PCI read/write functions, they should return normal errnos. Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning it. Fixes: 46184415368a ("arch: x86: New MailBox support driver for Intel SOC's") Signed-off-by: Ilpo Järvinen Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20240527125538.13620-4-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin