5.15-stable patches

added patches:
	perf-x86-uncore-correct-the-number-of-chas-on-emr.patch
	x86-sgx-break-up-long-non-preemptible-delays-in-sgx_vepc_release.patch

diff --git a/queue-5.15/perf-x86-uncore-correct-the-number-of-chas-on-emr.patch b/queue-5.15/perf-x86-uncore-correct-the-number-of-chas-on-emr.patch
new file mode 100644 (file)
index 0000000..789f5b6
--- /dev/null
+++ b/queue-5.15/perf-x86-uncore-correct-the-number-of-chas-on-emr.patch
@@ -0,0 +1,61 @@
+From 6f7f984fa85b305799076a1bcec941b9377587de Mon Sep 17 00:00:00 2001
+From: Kan Liang <kan.liang@linux.intel.com>
+Date: Tue, 5 Sep 2023 06:42:48 -0700
+Subject: perf/x86/uncore: Correct the number of CHAs on EMR
+
+From: Kan Liang <kan.liang@linux.intel.com>
+
+commit 6f7f984fa85b305799076a1bcec941b9377587de upstream.
+
+Starting from SPR, the basic uncore PMON information is retrieved from
+the discovery table (resides in an MMIO space populated by BIOS). It is
+called the discovery method. The existing value of the type->num_boxes
+is from the discovery table.
+
+On some SPR variants, there is a firmware bug that makes the value from the
+discovery table incorrect. We use the value from the
+SPR_MSR_UNC_CBO_CONFIG MSR to replace the one from the discovery table:
+
+   38776cc45eb7 ("perf/x86/uncore: Correct the number of CHAs on SPR")
+
+Unfortunately, the SPR_MSR_UNC_CBO_CONFIG isn't available for the EMR
+XCC (Always returns 0), but the above firmware bug doesn't impact the
+EMR XCC.
+
+Don't let the value from the MSR replace the existing value from the
+discovery table.
+
+Fixes: 38776cc45eb7 ("perf/x86/uncore: Correct the number of CHAs on SPR")
+Reported-by: Stephane Eranian <eranian@google.com>
+Reported-by: Yunying Sun <yunying.sun@intel.com>
+Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Tested-by: Yunying Sun <yunying.sun@intel.com>
+Link: https://lore.kernel.org/r/20230905134248.496114-1-kan.liang@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/events/intel/uncore_snbep.c |   12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/events/intel/uncore_snbep.c
++++ b/arch/x86/events/intel/uncore_snbep.c
+@@ -6078,8 +6078,18 @@ void spr_uncore_cpu_init(void)
+ 
+       type = uncore_find_type_by_id(uncore_msr_uncores, UNCORE_SPR_CHA);
+       if (type) {
++              /*
++               * The value from the discovery table (stored in the type->num_boxes
++               * of UNCORE_SPR_CHA) is incorrect on some SPR variants because of a
++               * firmware bug. Using the value from SPR_MSR_UNC_CBO_CONFIG to replace it.
++               */
+               rdmsrl(SPR_MSR_UNC_CBO_CONFIG, num_cbo);
+-              type->num_boxes = num_cbo;
++              /*
++               * The MSR doesn't work on the EMR XCC, but the firmware bug doesn't impact
++               * the EMR XCC. Don't let the value from the MSR replace the existing value.
++               */
++              if (num_cbo)
++                      type->num_boxes = num_cbo;
+       }
+       spr_uncore_iio_free_running.num_boxes = uncore_type_max_boxes(uncore_msr_uncores, UNCORE_SPR_IIO);
+ }

diff --git a/queue-5.15/series b/queue-5.15/series
index 2808900a21472b993792ddb121269d66a7565e56..d20c7ef3b03e8f5495eecab3bdafd17ceca512eb 100644 (file)
--- a/queue-5.15/series
+++ b/queue-5.15/series
@@ -370,3 +370,5 @@ usb-core-unite-old-scheme-and-new-scheme-descriptor-reads.patch
 usb-core-change-usb_get_device_descriptor-api.patch
 usb-core-fix-race-by-not-overwriting-udev-descriptor-in-hub_port_init.patch
 usb-core-fix-oversight-in-superspeed-initialization.patch
+x86-sgx-break-up-long-non-preemptible-delays-in-sgx_vepc_release.patch
+perf-x86-uncore-correct-the-number-of-chas-on-emr.patch

diff --git a/queue-5.15/x86-sgx-break-up-long-non-preemptible-delays-in-sgx_vepc_release.patch b/queue-5.15/x86-sgx-break-up-long-non-preemptible-delays-in-sgx_vepc_release.patch
new file mode 100644 (file)
index 0000000..93baa1b
--- /dev/null
+++ b/queue-5.15/x86-sgx-break-up-long-non-preemptible-delays-in-sgx_vepc_release.patch
@@ -0,0 +1,70 @@
+From 3d7d72a34e05b23e21bafc8bfb861e73c86b31f3 Mon Sep 17 00:00:00 2001
+From: Jack Wang <jinpu.wang@ionos.com>
+Date: Wed, 6 Sep 2023 15:17:12 +0200
+Subject: x86/sgx: Break up long non-preemptible delays in sgx_vepc_release()
+
+From: Jack Wang <jinpu.wang@ionos.com>
+
+commit 3d7d72a34e05b23e21bafc8bfb861e73c86b31f3 upstream.
+
+On large enclaves we hit the softlockup warning with following call trace:
+
+       xa_erase()
+       sgx_vepc_release()
+       __fput()
+       task_work_run()
+       do_exit()
+
+The latency issue is similar to the one fixed in:
+
+  8795359e35bc ("x86/sgx: Silence softlockup detection when releasing large enclaves")
+
+The test system has 64GB of enclave memory, and all is assigned to a single VM.
+Release of 'vepc' takes a longer time and causes long latencies, which triggers
+the softlockup warning.
+
+Add cond_resched() to give other tasks a chance to run and reduce
+latencies, which also avoids the softlockup detector.
+
+[ mingo: Rewrote the changelog. ]
+
+Fixes: 540745ddbc70 ("x86/sgx: Introduce virtual EPC for use by KVM guests")
+Reported-by: Yu Zhang <yu.zhang@ionos.com>
+Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Tested-by: Yu Zhang <yu.zhang@ionos.com>
+Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
+Reviewed-by: Kai Huang <kai.huang@intel.com>
+Acked-by: Haitao Huang <haitao.huang@linux.intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/sgx/virt.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/x86/kernel/cpu/sgx/virt.c
++++ b/arch/x86/kernel/cpu/sgx/virt.c
+@@ -167,6 +167,7 @@ static int sgx_vepc_release(struct inode
+                       continue;
+ 
+               xa_erase(&vepc->page_array, index);
++              cond_resched();
+       }
+ 
+       /*
+@@ -185,6 +186,7 @@ static int sgx_vepc_release(struct inode
+                       list_add_tail(&epc_page->list, &secs_pages);
+ 
+               xa_erase(&vepc->page_array, index);
++              cond_resched();
+       }
+ 
+       /*
+@@ -206,6 +208,7 @@ static int sgx_vepc_release(struct inode
+ 
+               if (sgx_vepc_free_page(epc_page))
+                       list_add_tail(&epc_page->list, &secs_pages);
++              cond_resched();
+       }
+ 
+       if (!list_empty(&secs_pages))