From: Greg Kroah-Hartman Date: Mon, 11 Oct 2021 07:47:44 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v5.14.12~12 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=a2d44bb2fb943918fe1bef05d1bf5f8c0f91976b;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: scsi-ufs-core-fix-task-management-completion.patch x86-entry-clear-x86_feature_smap-when-config_x86_smap-n.patch x86-entry-correct-reference-to-intended-config_64_bit.patch x86-hpet-use-another-crystalball-to-evaluate-hpet-usability.patch x86-kconfig-correct-reference-to-mwinchip3d.patch x86-platform-olpc-correct-ifdef-symbol-to-intended-config_olpc_xo15_sci.patch x86-sev-return-an-error-on-a-returned-non-zero-sw_exitinfo1.patch --- diff --git a/queue-5.10/scsi-ufs-core-fix-task-management-completion.patch b/queue-5.10/scsi-ufs-core-fix-task-management-completion.patch new file mode 100644 index 00000000000..3bbeb4db18f --- /dev/null +++ b/queue-5.10/scsi-ufs-core-fix-task-management-completion.patch @@ -0,0 +1,153 @@ +From f5ef336fd2e4c36dedae4e7ca66cf5349d6fda62 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Wed, 22 Sep 2021 12:10:59 +0300 +Subject: scsi: ufs: core: Fix task management completion + +From: Adrian Hunter + +commit f5ef336fd2e4c36dedae4e7ca66cf5349d6fda62 upstream. + +The UFS driver uses blk_mq_tagset_busy_iter() when identifying task +management requests to complete, however blk_mq_tagset_busy_iter() doesn't +work. + +blk_mq_tagset_busy_iter() only iterates requests dispatched by the block +layer. That appears as if it might have started since commit 37f4a24c2469 +("blk-mq: centralise related handling into blk_mq_get_driver_tag") which +removed 'data->hctx->tags->rqs[rq->tag] = rq' from blk_mq_rq_ctx_init() +which gets called: + + blk_get_request + blk_mq_alloc_request + __blk_mq_alloc_request + blk_mq_rq_ctx_init + +Since UFS task management requests are not dispatched by the block layer, +hctx->tags->rqs[rq->tag] remains NULL, and since blk_mq_tagset_busy_iter() +relies on finding requests using hctx->tags->rqs[rq->tag], UFS task +management requests are never found by blk_mq_tagset_busy_iter(). + +By using blk_mq_tagset_busy_iter(), the UFS driver was relying on internal +details of the block layer, which was fragile and subsequently got +broken. Fix by removing the use of blk_mq_tagset_busy_iter() and having the +driver keep track of task management requests. + +Link: https://lore.kernel.org/r/20210922091059.4040-1-adrian.hunter@intel.com +Fixes: 1235fc569e0b ("scsi: ufs: core: Fix task management request completion timeout") +Fixes: 69a6c269c097 ("scsi: ufs: Use blk_{get,put}_request() to allocate and free TMFs") +Cc: stable@vger.kernel.org +Tested-by: Bart Van Assche +Reviewed-by: Bart Van Assche +Signed-off-by: Adrian Hunter +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/ufs/ufshcd.c | 54 +++++++++++++++++++++------------------------- + drivers/scsi/ufs/ufshcd.h | 1 + 2 files changed, 26 insertions(+), 29 deletions(-) + +--- a/drivers/scsi/ufs/ufshcd.c ++++ b/drivers/scsi/ufs/ufshcd.c +@@ -6105,27 +6105,6 @@ static irqreturn_t ufshcd_check_errors(s + return retval; + } + +-struct ctm_info { +- struct ufs_hba *hba; +- unsigned long pending; +- unsigned int ncpl; +-}; +- +-static bool ufshcd_compl_tm(struct request *req, void *priv, bool reserved) +-{ +- struct ctm_info *const ci = priv; +- struct completion *c; +- +- WARN_ON_ONCE(reserved); +- if (test_bit(req->tag, &ci->pending)) +- return true; +- ci->ncpl++; +- c = req->end_io_data; +- if (c) +- complete(c); +- return true; +-} +- + /** + * ufshcd_tmc_handler - handle task management function completion + * @hba: per adapter instance +@@ -6136,14 +6115,24 @@ static bool ufshcd_compl_tm(struct reque + */ + static irqreturn_t ufshcd_tmc_handler(struct ufs_hba *hba) + { +- struct request_queue *q = hba->tmf_queue; +- struct ctm_info ci = { +- .hba = hba, +- .pending = ufshcd_readl(hba, REG_UTP_TASK_REQ_DOOR_BELL), +- }; ++ unsigned long flags, pending, issued; ++ irqreturn_t ret = IRQ_NONE; ++ int tag; + +- blk_mq_tagset_busy_iter(q->tag_set, ufshcd_compl_tm, &ci); +- return ci.ncpl ? IRQ_HANDLED : IRQ_NONE; ++ pending = ufshcd_readl(hba, REG_UTP_TASK_REQ_DOOR_BELL); ++ ++ spin_lock_irqsave(hba->host->host_lock, flags); ++ issued = hba->outstanding_tasks & ~pending; ++ for_each_set_bit(tag, &issued, hba->nutmrs) { ++ struct request *req = hba->tmf_rqs[tag]; ++ struct completion *c = req->end_io_data; ++ ++ complete(c); ++ ret = IRQ_HANDLED; ++ } ++ spin_unlock_irqrestore(hba->host->host_lock, flags); ++ ++ return ret; + } + + /** +@@ -6273,9 +6262,9 @@ static int __ufshcd_issue_tm_cmd(struct + ufshcd_hold(hba, false); + + spin_lock_irqsave(host->host_lock, flags); +- blk_mq_start_request(req); + + task_tag = req->tag; ++ hba->tmf_rqs[req->tag] = req; + treq->req_header.dword_0 |= cpu_to_be32(task_tag); + + memcpy(hba->utmrdl_base_addr + task_tag, treq, sizeof(*treq)); +@@ -6319,6 +6308,7 @@ static int __ufshcd_issue_tm_cmd(struct + } + + spin_lock_irqsave(hba->host->host_lock, flags); ++ hba->tmf_rqs[req->tag] = NULL; + __clear_bit(task_tag, &hba->outstanding_tasks); + spin_unlock_irqrestore(hba->host->host_lock, flags); + +@@ -9246,6 +9236,12 @@ int ufshcd_init(struct ufs_hba *hba, voi + err = PTR_ERR(hba->tmf_queue); + goto free_tmf_tag_set; + } ++ hba->tmf_rqs = devm_kcalloc(hba->dev, hba->nutmrs, ++ sizeof(*hba->tmf_rqs), GFP_KERNEL); ++ if (!hba->tmf_rqs) { ++ err = -ENOMEM; ++ goto free_tmf_queue; ++ } + + /* Reset the attached device */ + ufshcd_vops_device_reset(hba); +--- a/drivers/scsi/ufs/ufshcd.h ++++ b/drivers/scsi/ufs/ufshcd.h +@@ -731,6 +731,7 @@ struct ufs_hba { + + struct blk_mq_tag_set tmf_tag_set; + struct request_queue *tmf_queue; ++ struct request **tmf_rqs; + + struct uic_command *active_uic_cmd; + struct mutex uic_cmd_mutex; diff --git a/queue-5.10/series b/queue-5.10/series index d6b6b5ee8b4..93a7f88ef06 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -75,3 +75,10 @@ powerpc-bpf-fix-bpf_mod-when-imm-1.patch powerpc-bpf-fix-bpf_sub-when-imm-0x80000000.patch powerpc-64s-fix-program-check-interrupt-emergency-st.patch pseries-eeh-fix-the-kdump-kernel-crash-during-eeh_ps.patch +x86-platform-olpc-correct-ifdef-symbol-to-intended-config_olpc_xo15_sci.patch +x86-kconfig-correct-reference-to-mwinchip3d.patch +x86-sev-return-an-error-on-a-returned-non-zero-sw_exitinfo1.patch +x86-entry-correct-reference-to-intended-config_64_bit.patch +x86-entry-clear-x86_feature_smap-when-config_x86_smap-n.patch +x86-hpet-use-another-crystalball-to-evaluate-hpet-usability.patch +scsi-ufs-core-fix-task-management-completion.patch diff --git a/queue-5.10/x86-entry-clear-x86_feature_smap-when-config_x86_smap-n.patch b/queue-5.10/x86-entry-clear-x86_feature_smap-when-config_x86_smap-n.patch new file mode 100644 index 00000000000..a9b1fb51f95 --- /dev/null +++ b/queue-5.10/x86-entry-clear-x86_feature_smap-when-config_x86_smap-n.patch @@ -0,0 +1,69 @@ +From 3958b9c34c2729597e182cc606cc43942fd19f7c Mon Sep 17 00:00:00 2001 +From: Vegard Nossum +Date: Mon, 4 Oct 2021 00:34:23 +0200 +Subject: x86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n + +From: Vegard Nossum + +commit 3958b9c34c2729597e182cc606cc43942fd19f7c upstream. + +Commit + + 3c73b81a9164 ("x86/entry, selftests: Further improve user entry sanity checks") + +added a warning if AC is set when in the kernel. + +Commit + + 662a0221893a3d ("x86/entry: Fix AC assertion") + +changed the warning to only fire if the CPU supports SMAP. + +However, the warning can still trigger on a machine that supports SMAP +but where it's disabled in the kernel config and when running the +syscall_nt selftest, for example: + + ------------[ cut here ]------------ + WARNING: CPU: 0 PID: 49 at irqentry_enter_from_user_mode + CPU: 0 PID: 49 Comm: init Tainted: G T 5.15.0-rc4+ #98 e6202628ee053b4f310759978284bd8bb0ce6905 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 + RIP: 0010:irqentry_enter_from_user_mode + ... + Call Trace: + ? irqentry_enter + ? exc_general_protection + ? asm_exc_general_protection + ? asm_exc_general_protectio + +IS_ENABLED(CONFIG_X86_SMAP) could be added to the warning condition, but +even this would not be enough in case SMAP is disabled at boot time with +the "nosmap" parameter. + +To be consistent with "nosmap" behaviour, clear X86_FEATURE_SMAP when +!CONFIG_X86_SMAP. + +Found using entry-fuzz + satrandconfig. + + [ bp: Massage commit message. ] + +Fixes: 3c73b81a9164 ("x86/entry, selftests: Further improve user entry sanity checks") +Fixes: 662a0221893a ("x86/entry: Fix AC assertion") +Signed-off-by: Vegard Nossum +Signed-off-by: Borislav Petkov +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20211003223423.8666-1-vegard.nossum@oracle.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/common.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/x86/kernel/cpu/common.c ++++ b/arch/x86/kernel/cpu/common.c +@@ -320,6 +320,7 @@ static __always_inline void setup_smap(s + #ifdef CONFIG_X86_SMAP + cr4_set_bits(X86_CR4_SMAP); + #else ++ clear_cpu_cap(c, X86_FEATURE_SMAP); + cr4_clear_bits(X86_CR4_SMAP); + #endif + } diff --git a/queue-5.10/x86-entry-correct-reference-to-intended-config_64_bit.patch b/queue-5.10/x86-entry-correct-reference-to-intended-config_64_bit.patch new file mode 100644 index 00000000000..6dfa77d8809 --- /dev/null +++ b/queue-5.10/x86-entry-correct-reference-to-intended-config_64_bit.patch @@ -0,0 +1,42 @@ +From 2c861f2b859385e9eaa6e464a8a7435b5a6bf564 Mon Sep 17 00:00:00 2001 +From: Lukas Bulwahn +Date: Tue, 3 Aug 2021 13:35:23 +0200 +Subject: x86/entry: Correct reference to intended CONFIG_64_BIT + +From: Lukas Bulwahn + +commit 2c861f2b859385e9eaa6e464a8a7435b5a6bf564 upstream. + +Commit in Fixes adds a condition with IS_ENABLED(CONFIG_64_BIT), +but the intended config item is called CONFIG_64BIT, as defined in +arch/x86/Kconfig. + +Fortunately, scripts/checkkconfigsymbols.py warns: + +64_BIT +Referencing files: arch/x86/include/asm/entry-common.h + +Correct the reference to the intended config symbol. + +Fixes: 662a0221893a ("x86/entry: Fix AC assertion") +Suggested-by: Randy Dunlap +Signed-off-by: Lukas Bulwahn +Signed-off-by: Borislav Petkov +Cc: +Link: https://lkml.kernel.org/r/20210803113531.30720-2-lukas.bulwahn@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/entry-common.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/include/asm/entry-common.h ++++ b/arch/x86/include/asm/entry-common.h +@@ -24,7 +24,7 @@ static __always_inline void arch_check_u + * For !SMAP hardware we patch out CLAC on entry. + */ + if (boot_cpu_has(X86_FEATURE_SMAP) || +- (IS_ENABLED(CONFIG_64_BIT) && boot_cpu_has(X86_FEATURE_XENPV))) ++ (IS_ENABLED(CONFIG_64BIT) && boot_cpu_has(X86_FEATURE_XENPV))) + mask |= X86_EFLAGS_AC; + + WARN_ON_ONCE(flags & mask); diff --git a/queue-5.10/x86-hpet-use-another-crystalball-to-evaluate-hpet-usability.patch b/queue-5.10/x86-hpet-use-another-crystalball-to-evaluate-hpet-usability.patch new file mode 100644 index 00000000000..d89d7d42b90 --- /dev/null +++ b/queue-5.10/x86-hpet-use-another-crystalball-to-evaluate-hpet-usability.patch @@ -0,0 +1,159 @@ +From 6e3cd95234dc1eda488f4f487c281bac8fef4d9b Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Thu, 30 Sep 2021 19:21:39 +0200 +Subject: x86/hpet: Use another crystalball to evaluate HPET usability + +From: Thomas Gleixner + +commit 6e3cd95234dc1eda488f4f487c281bac8fef4d9b upstream. + +On recent Intel systems the HPET stops working when the system reaches PC10 +idle state. + +The approach of adding PCI ids to the early quirks to disable HPET on +these systems is a whack a mole game which makes no sense. + +Check for PC10 instead and force disable HPET if supported. The check is +overbroad as it does not take ACPI, intel_idle enablement and command +line parameters into account. That's fine as long as there is at least +PMTIMER available to calibrate the TSC frequency. The decision can be +overruled by adding "hpet=force" on the kernel command line. + +Remove the related early PCI quirks for affected Ice Cake and Coffin Lake +systems as they are not longer required. That should also cover all +other systems, i.e. Tiger Rag and newer generations, which are most +likely affected by this as well. + +Fixes: Yet another hardware trainwreck +Reported-by: Jakub Kicinski +Signed-off-by: Thomas Gleixner +Tested-by: Jakub Kicinski +Reviewed-by: Rafael J. Wysocki +Cc: stable@vger.kernel.org +Cc: Kai-Heng Feng +Cc: Bjorn Helgaas +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/early-quirks.c | 6 --- + arch/x86/kernel/hpet.c | 81 +++++++++++++++++++++++++++++++++++++++++ + 2 files changed, 81 insertions(+), 6 deletions(-) + +--- a/arch/x86/kernel/early-quirks.c ++++ b/arch/x86/kernel/early-quirks.c +@@ -711,12 +711,6 @@ static struct chipset early_qrk[] __init + */ + { PCI_VENDOR_ID_INTEL, 0x0f00, + PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, force_disable_hpet}, +- { PCI_VENDOR_ID_INTEL, 0x3e20, +- PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, force_disable_hpet}, +- { PCI_VENDOR_ID_INTEL, 0x3ec4, +- PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, force_disable_hpet}, +- { PCI_VENDOR_ID_INTEL, 0x8a12, +- PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, force_disable_hpet}, + { PCI_VENDOR_ID_BROADCOM, 0x4331, + PCI_CLASS_NETWORK_OTHER, PCI_ANY_ID, 0, apple_airport_reset}, + {} +--- a/arch/x86/kernel/hpet.c ++++ b/arch/x86/kernel/hpet.c +@@ -9,6 +9,7 @@ + + #include + #include ++#include + + #undef pr_fmt + #define pr_fmt(fmt) "hpet: " fmt +@@ -806,6 +807,83 @@ static bool __init hpet_counting(void) + return false; + } + ++static bool __init mwait_pc10_supported(void) ++{ ++ unsigned int eax, ebx, ecx, mwait_substates; ++ ++ if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) ++ return false; ++ ++ if (!cpu_feature_enabled(X86_FEATURE_MWAIT)) ++ return false; ++ ++ if (boot_cpu_data.cpuid_level < CPUID_MWAIT_LEAF) ++ return false; ++ ++ cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &mwait_substates); ++ ++ return (ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED) && ++ (ecx & CPUID5_ECX_INTERRUPT_BREAK) && ++ (mwait_substates & (0xF << 28)); ++} ++ ++/* ++ * Check whether the system supports PC10. If so force disable HPET as that ++ * stops counting in PC10. This check is overbroad as it does not take any ++ * of the following into account: ++ * ++ * - ACPI tables ++ * - Enablement of intel_idle ++ * - Command line arguments which limit intel_idle C-state support ++ * ++ * That's perfectly fine. HPET is a piece of hardware designed by committee ++ * and the only reasons why it is still in use on modern systems is the ++ * fact that it is impossible to reliably query TSC and CPU frequency via ++ * CPUID or firmware. ++ * ++ * If HPET is functional it is useful for calibrating TSC, but this can be ++ * done via PMTIMER as well which seems to be the last remaining timer on ++ * X86/INTEL platforms that has not been completely wreckaged by feature ++ * creep. ++ * ++ * In theory HPET support should be removed altogether, but there are older ++ * systems out there which depend on it because TSC and APIC timer are ++ * dysfunctional in deeper C-states. ++ * ++ * It's only 20 years now that hardware people have been asked to provide ++ * reliable and discoverable facilities which can be used for timekeeping ++ * and per CPU timer interrupts. ++ * ++ * The probability that this problem is going to be solved in the ++ * forseeable future is close to zero, so the kernel has to be cluttered ++ * with heuristics to keep up with the ever growing amount of hardware and ++ * firmware trainwrecks. Hopefully some day hardware people will understand ++ * that the approach of "This can be fixed in software" is not sustainable. ++ * Hope dies last... ++ */ ++static bool __init hpet_is_pc10_damaged(void) ++{ ++ unsigned long long pcfg; ++ ++ /* Check whether PC10 substates are supported */ ++ if (!mwait_pc10_supported()) ++ return false; ++ ++ /* Check whether PC10 is enabled in PKG C-state limit */ ++ rdmsrl(MSR_PKG_CST_CONFIG_CONTROL, pcfg); ++ if ((pcfg & 0xF) < 8) ++ return false; ++ ++ if (hpet_force_user) { ++ pr_warn("HPET force enabled via command line, but dysfunctional in PC10.\n"); ++ return false; ++ } ++ ++ pr_info("HPET dysfunctional in PC10. Force disabled.\n"); ++ boot_hpet_disable = true; ++ return true; ++} ++ + /** + * hpet_enable - Try to setup the HPET timer. Returns 1 on success. + */ +@@ -819,6 +897,9 @@ int __init hpet_enable(void) + if (!is_hpet_capable()) + return 0; + ++ if (hpet_is_pc10_damaged()) ++ return 0; ++ + hpet_set_mapping(); + if (!hpet_virt_address) + return 0; diff --git a/queue-5.10/x86-kconfig-correct-reference-to-mwinchip3d.patch b/queue-5.10/x86-kconfig-correct-reference-to-mwinchip3d.patch new file mode 100644 index 00000000000..8e9471a78a6 --- /dev/null +++ b/queue-5.10/x86-kconfig-correct-reference-to-mwinchip3d.patch @@ -0,0 +1,41 @@ +From 225bac2dc5d192e55f2c50123ee539b1edf8a411 Mon Sep 17 00:00:00 2001 +From: Lukas Bulwahn +Date: Tue, 3 Aug 2021 13:35:25 +0200 +Subject: x86/Kconfig: Correct reference to MWINCHIP3D + +From: Lukas Bulwahn + +commit 225bac2dc5d192e55f2c50123ee539b1edf8a411 upstream. + +Commit in Fixes intended to exclude the Winchip series and referred to +CONFIG_WINCHIP3D, but the config symbol is called CONFIG_MWINCHIP3D. + +Hence, scripts/checkkconfigsymbols.py warns: + +WINCHIP3D +Referencing files: arch/x86/Kconfig + +Correct the reference to the intended config symbol. + +Fixes: 69b8d3fcabdc ("x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G Kconfig group") +Suggested-by: Randy Dunlap +Signed-off-by: Lukas Bulwahn +Signed-off-by: Borislav Petkov +Cc: +Link: https://lkml.kernel.org/r/20210803113531.30720-4-lukas.bulwahn@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/Kconfig | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/Kconfig ++++ b/arch/x86/Kconfig +@@ -1415,7 +1415,7 @@ config HIGHMEM4G + + config HIGHMEM64G + bool "64GB" +- depends on !M486SX && !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && !MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !WINCHIP3D && !MK6 ++ depends on !M486SX && !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && !MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !MWINCHIP3D && !MK6 + select X86_PAE + help + Select this if you have a 32-bit processor and more than 4 diff --git a/queue-5.10/x86-platform-olpc-correct-ifdef-symbol-to-intended-config_olpc_xo15_sci.patch b/queue-5.10/x86-platform-olpc-correct-ifdef-symbol-to-intended-config_olpc_xo15_sci.patch new file mode 100644 index 00000000000..2fab14eb49a --- /dev/null +++ b/queue-5.10/x86-platform-olpc-correct-ifdef-symbol-to-intended-config_olpc_xo15_sci.patch @@ -0,0 +1,42 @@ +From 4758fd801f919b8b9acad78d2e49a195ec2be46b Mon Sep 17 00:00:00 2001 +From: Lukas Bulwahn +Date: Tue, 3 Aug 2021 13:35:24 +0200 +Subject: x86/platform/olpc: Correct ifdef symbol to intended CONFIG_OLPC_XO15_SCI + +From: Lukas Bulwahn + +commit 4758fd801f919b8b9acad78d2e49a195ec2be46b upstream. + +The refactoring in the commit in Fixes introduced an ifdef +CONFIG_OLPC_XO1_5_SCI, however the config symbol is actually called +"CONFIG_OLPC_XO15_SCI". + +Fortunately, ./scripts/checkkconfigsymbols.py warns: + +OLPC_XO1_5_SCI +Referencing files: arch/x86/platform/olpc/olpc.c + +Correct this ifdef condition to the intended config symbol. + +Fixes: ec9964b48033 ("Platform: OLPC: Move EC-specific functionality out from x86") +Suggested-by: Randy Dunlap +Signed-off-by: Lukas Bulwahn +Signed-off-by: Borislav Petkov +Cc: +Link: https://lkml.kernel.org/r/20210803113531.30720-3-lukas.bulwahn@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/platform/olpc/olpc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/platform/olpc/olpc.c ++++ b/arch/x86/platform/olpc/olpc.c +@@ -274,7 +274,7 @@ static struct olpc_ec_driver ec_xo1_driv + + static struct olpc_ec_driver ec_xo1_5_driver = { + .ec_cmd = olpc_xo1_ec_cmd, +-#ifdef CONFIG_OLPC_XO1_5_SCI ++#ifdef CONFIG_OLPC_XO15_SCI + /* + * XO-1.5 EC wakeups are available when olpc-xo15-sci driver is + * compiled in diff --git a/queue-5.10/x86-sev-return-an-error-on-a-returned-non-zero-sw_exitinfo1.patch b/queue-5.10/x86-sev-return-an-error-on-a-returned-non-zero-sw_exitinfo1.patch new file mode 100644 index 00000000000..947e82b59f6 --- /dev/null +++ b/queue-5.10/x86-sev-return-an-error-on-a-returned-non-zero-sw_exitinfo1.patch @@ -0,0 +1,36 @@ +From 06f2ac3d4219bbbfd93d79e01966a42053084f11 Mon Sep 17 00:00:00 2001 +From: Tom Lendacky +Date: Thu, 30 Sep 2021 23:42:01 -0500 +Subject: x86/sev: Return an error on a returned non-zero SW_EXITINFO1[31:0] + +From: Tom Lendacky + +commit 06f2ac3d4219bbbfd93d79e01966a42053084f11 upstream. + +After returning from a VMGEXIT NAE event, SW_EXITINFO1[31:0] is checked +for a value of 1, which indicates an error and that SW_EXITINFO2 +contains exception information. However, future versions of the GHCB +specification may define new values for SW_EXITINFO1[31:0], so really +any non-zero value should be treated as an error. + +Fixes: 597cfe48212a ("x86/boot/compressed/64: Setup a GHCB-based VC Exception handler") +Signed-off-by: Tom Lendacky +Signed-off-by: Borislav Petkov +Cc: # 5.10+ +Link: https://lkml.kernel.org/r/efc772af831e9e7f517f0439b13b41f56bad8784.1633063321.git.thomas.lendacky@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/sev-es-shared.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/x86/kernel/sev-es-shared.c ++++ b/arch/x86/kernel/sev-es-shared.c +@@ -130,6 +130,8 @@ static enum es_result sev_es_ghcb_hv_cal + } else { + ret = ES_VMM_ERROR; + } ++ } else if (ghcb->save.sw_exit_info_1 & 0xffffffff) { ++ ret = ES_VMM_ERROR; + } else { + ret = ES_OK; + }