From 08e1cf47f8de75f9bf281e2894d1677e0b767e2a Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sun, 10 Sep 2023 19:30:53 +0100 Subject: [PATCH] 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 --- ...re-correct-the-number-of-chas-on-emr.patch | 61 ++++++++++++++++ queue-5.15/series | 2 + ...eemptible-delays-in-sgx_vepc_release.patch | 70 +++++++++++++++++++ 3 files changed, 133 insertions(+) create mode 100644 queue-5.15/perf-x86-uncore-correct-the-number-of-chas-on-emr.patch create mode 100644 queue-5.15/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 index 00000000000..789f5b6818d --- /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 +Date: Tue, 5 Sep 2023 06:42:48 -0700 +Subject: perf/x86/uncore: Correct the number of CHAs on EMR + +From: Kan Liang + +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 +Reported-by: Yunying Sun +Signed-off-by: Kan Liang +Signed-off-by: Ingo Molnar +Tested-by: Yunying Sun +Link: https://lore.kernel.org/r/20230905134248.496114-1-kan.liang@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 2808900a214..d20c7ef3b03 100644 --- 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 index 00000000000..93baa1bd964 --- /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 +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 + +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 +Signed-off-by: Jack Wang +Signed-off-by: Ingo Molnar +Tested-by: Yu Zhang +Reviewed-by: Jarkko Sakkinen +Reviewed-by: Kai Huang +Acked-by: Haitao Huang +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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)) -- 2.47.3