From: Greg Kroah-Hartman Date: Tue, 1 Oct 2024 08:21:15 +0000 (+0200) Subject: 6.11-stable patches X-Git-Tag: v6.6.54~113 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d11efd85b6a5d90056ed7c06b3c41e85fd890a5d;p=thirdparty%2Fkernel%2Fstable-queue.git 6.11-stable patches added patches: xen-allow-mapping-acpi-data-using-a-different-physical-address.patch xen-move-checks-for-e820-conflicts-further-up.patch --- diff --git a/queue-6.11/series b/queue-6.11/series index 3bf0d4764ec..6ca0e8f1ab5 100644 --- a/queue-6.11/series +++ b/queue-6.11/series @@ -515,3 +515,5 @@ mm-call-the-security_mmap_file-lsm-hook-in-remap_file_pages.patch drm-amd-display-fix-synaptics-cascaded-panamera-dsc-determination.patch drm-amd-display-add-dsc-debug-log.patch drm-amdgpu-display-fix-a-mistake-in-revert-commit.patch +xen-move-checks-for-e820-conflicts-further-up.patch +xen-allow-mapping-acpi-data-using-a-different-physical-address.patch diff --git a/queue-6.11/xen-allow-mapping-acpi-data-using-a-different-physical-address.patch b/queue-6.11/xen-allow-mapping-acpi-data-using-a-different-physical-address.patch new file mode 100644 index 00000000000..8034a162456 --- /dev/null +++ b/queue-6.11/xen-allow-mapping-acpi-data-using-a-different-physical-address.patch @@ -0,0 +1,192 @@ +From 9221222c717dbddac1e3c49906525475d87a3a44 Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Fri, 9 Aug 2024 17:52:55 +0200 +Subject: xen: allow mapping ACPI data using a different physical address + +From: Juergen Gross + +commit 9221222c717dbddac1e3c49906525475d87a3a44 upstream. + +When running as a Xen PV dom0 the system needs to map ACPI data of the +host using host physical addresses, while those addresses can conflict +with the guest physical addresses of the loaded linux kernel. The same +problem might apply in case a PV guest is configured to use the host +memory map. + +This conflict can be solved by mapping the ACPI data to a different +guest physical address, but mapping the data via acpi_os_ioremap() +must still be possible using the host physical address, as this +address might be generated by AML when referencing some of the ACPI +data. + +When configured to support running as a Xen PV domain, have an +implementation of acpi_os_ioremap() being aware of the possibility to +need above mentioned translation of a host physical address to the +guest physical address. + +This modification requires to #include linux/acpi.h in some sources +which need to include asm/acpi.h directly. + +Signed-off-by: Juergen Gross +Reviewed-by: Jan Beulich +Signed-off-by: Juergen Gross +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/acpi.h | 8 ++++++++ + arch/x86/kernel/acpi/boot.c | 11 +++++++++++ + arch/x86/kernel/jailhouse.c | 1 + + arch/x86/kernel/mmconf-fam10h_64.c | 1 + + arch/x86/kernel/smpboot.c | 1 + + arch/x86/kernel/x86_init.c | 1 + + arch/x86/xen/p2m.c | 35 +++++++++++++++++++++++++++++++++++ + arch/x86/xen/setup.c | 2 +- + 8 files changed, 59 insertions(+), 1 deletion(-) + +--- a/arch/x86/include/asm/acpi.h ++++ b/arch/x86/include/asm/acpi.h +@@ -174,6 +174,14 @@ void acpi_generic_reduced_hw_init(void); + void x86_default_set_root_pointer(u64 addr); + u64 x86_default_get_root_pointer(void); + ++#ifdef CONFIG_XEN_PV ++/* A Xen PV domain needs a special acpi_os_ioremap() handling. */ ++extern void __iomem * (*acpi_os_ioremap)(acpi_physical_address phys, ++ acpi_size size); ++void __iomem *x86_acpi_os_ioremap(acpi_physical_address phys, acpi_size size); ++#define acpi_os_ioremap acpi_os_ioremap ++#endif ++ + #else /* !CONFIG_ACPI */ + + #define acpi_lapic 0 +--- a/arch/x86/kernel/acpi/boot.c ++++ b/arch/x86/kernel/acpi/boot.c +@@ -1778,3 +1778,14 @@ u64 x86_default_get_root_pointer(void) + { + return boot_params.acpi_rsdp_addr; + } ++ ++#ifdef CONFIG_XEN_PV ++void __iomem *x86_acpi_os_ioremap(acpi_physical_address phys, acpi_size size) ++{ ++ return ioremap_cache(phys, size); ++} ++ ++void __iomem * (*acpi_os_ioremap)(acpi_physical_address phys, acpi_size size) = ++ x86_acpi_os_ioremap; ++EXPORT_SYMBOL_GPL(acpi_os_ioremap); ++#endif +--- a/arch/x86/kernel/jailhouse.c ++++ b/arch/x86/kernel/jailhouse.c +@@ -12,6 +12,7 @@ + #include + #include + #include ++#include + #include + #include + #include +--- a/arch/x86/kernel/mmconf-fam10h_64.c ++++ b/arch/x86/kernel/mmconf-fam10h_64.c +@@ -9,6 +9,7 @@ + #include + #include + #include ++#include + + #include + #include +--- a/arch/x86/kernel/smpboot.c ++++ b/arch/x86/kernel/smpboot.c +@@ -60,6 +60,7 @@ + #include + #include + #include ++#include + + #include + #include +--- a/arch/x86/kernel/x86_init.c ++++ b/arch/x86/kernel/x86_init.c +@@ -8,6 +8,7 @@ + #include + #include + #include ++#include + + #include + #include +--- a/arch/x86/xen/p2m.c ++++ b/arch/x86/xen/p2m.c +@@ -70,6 +70,7 @@ + #include + #include + #include ++#include + + #include + #include +@@ -834,6 +835,34 @@ void __init xen_do_remap_nonram(void) + pr_info("Remapped %u non-RAM page(s)\n", remapped); + } + ++#ifdef CONFIG_ACPI ++/* ++ * Xen variant of acpi_os_ioremap() taking potentially remapped non-RAM ++ * regions into account. ++ * Any attempt to map an area crossing a remap boundary will produce a ++ * WARN() splat. ++ * phys is related to remap->maddr on input and will be rebased to remap->paddr. ++ */ ++static void __iomem *xen_acpi_os_ioremap(acpi_physical_address phys, ++ acpi_size size) ++{ ++ unsigned int i; ++ const struct nonram_remap *remap = xen_nonram_remap; ++ ++ for (i = 0; i < nr_nonram_remap; i++) { ++ if (phys + size > remap->maddr && ++ phys < remap->maddr + remap->size) { ++ WARN_ON(phys < remap->maddr || ++ phys + size > remap->maddr + remap->size); ++ phys += remap->paddr - remap->maddr; ++ break; ++ } ++ } ++ ++ return x86_acpi_os_ioremap(phys, size); ++} ++#endif /* CONFIG_ACPI */ ++ + /* + * Add a new non-RAM remap entry. + * In case of no free entry found, just crash the system. +@@ -848,6 +877,12 @@ void __init xen_add_remap_nonram(phys_ad + BUG(); + } + ++#ifdef CONFIG_ACPI ++ /* Switch to the Xen acpi_os_ioremap() variant. */ ++ if (nr_nonram_remap == 0) ++ acpi_os_ioremap = xen_acpi_os_ioremap; ++#endif ++ + xen_nonram_remap[nr_nonram_remap].maddr = maddr; + xen_nonram_remap[nr_nonram_remap].paddr = paddr; + xen_nonram_remap[nr_nonram_remap].size = size; +--- a/arch/x86/xen/setup.c ++++ b/arch/x86/xen/setup.c +@@ -15,12 +15,12 @@ + #include + #include + #include ++#include + + #include + #include + #include + #include +-#include + #include + #include + #include diff --git a/queue-6.11/xen-move-checks-for-e820-conflicts-further-up.patch b/queue-6.11/xen-move-checks-for-e820-conflicts-further-up.patch new file mode 100644 index 00000000000..663bc253a88 --- /dev/null +++ b/queue-6.11/xen-move-checks-for-e820-conflicts-further-up.patch @@ -0,0 +1,86 @@ +From c4498ae316da5b5786ccd448fc555f3339b8e4ca Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Tue, 6 Aug 2024 09:56:48 +0200 +Subject: xen: move checks for e820 conflicts further up +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Juergen Gross + +commit c4498ae316da5b5786ccd448fc555f3339b8e4ca upstream. + +Move the checks for e820 memory map conflicts using the +xen_chk_is_e820_usable() helper further up in order to prepare +resolving some of the possible conflicts by doing some e820 map +modifications, which must happen before evaluating the RAM layout. + +Signed-off-by: Juergen Gross +Tested-by: Marek Marczykowski-Górecki +Reviewed-by: Jan Beulich +Signed-off-by: Juergen Gross +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/xen/setup.c | 44 ++++++++++++++++++++++---------------------- + 1 file changed, 22 insertions(+), 22 deletions(-) + +--- a/arch/x86/xen/setup.c ++++ b/arch/x86/xen/setup.c +@@ -854,6 +854,28 @@ char * __init xen_memory_setup(void) + /* Make sure the Xen-supplied memory map is well-ordered. */ + e820__update_table(&xen_e820_table); + ++ /* ++ * Check whether the kernel itself conflicts with the target E820 map. ++ * Failing now is better than running into weird problems later due ++ * to relocating (and even reusing) pages with kernel text or data. ++ */ ++ xen_chk_is_e820_usable(__pa_symbol(_text), ++ __pa_symbol(_end) - __pa_symbol(_text), ++ "kernel"); ++ ++ /* ++ * Check for a conflict of the xen_start_info memory with the target ++ * E820 map. ++ */ ++ xen_chk_is_e820_usable(__pa(xen_start_info), sizeof(*xen_start_info), ++ "xen_start_info"); ++ ++ /* ++ * Check for a conflict of the hypervisor supplied page tables with ++ * the target E820 map. ++ */ ++ xen_pt_check_e820(); ++ + max_pages = xen_get_max_pages(); + + /* How many extra pages do we need due to remapping? */ +@@ -926,28 +948,6 @@ char * __init xen_memory_setup(void) + + e820__update_table(e820_table); + +- /* +- * Check whether the kernel itself conflicts with the target E820 map. +- * Failing now is better than running into weird problems later due +- * to relocating (and even reusing) pages with kernel text or data. +- */ +- xen_chk_is_e820_usable(__pa_symbol(_text), +- __pa_symbol(_end) - __pa_symbol(_text), +- "kernel"); +- +- /* +- * Check for a conflict of the xen_start_info memory with the target +- * E820 map. +- */ +- xen_chk_is_e820_usable(__pa(xen_start_info), sizeof(*xen_start_info), +- "xen_start_info"); +- +- /* +- * Check for a conflict of the hypervisor supplied page tables with +- * the target E820 map. +- */ +- xen_pt_check_e820(); +- + xen_reserve_xen_mfnlist(); + + /* Check for a conflict of the initrd with the target E820 map. */