--- /dev/null
+From f5ef336fd2e4c36dedae4e7ca66cf5349d6fda62 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Wed, 22 Sep 2021 12:10:59 +0300
+Subject: scsi: ufs: core: Fix task management completion
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+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 <bvanassche@acm.org>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
--- /dev/null
+From 3958b9c34c2729597e182cc606cc43942fd19f7c Mon Sep 17 00:00:00 2001
+From: Vegard Nossum <vegard.nossum@oracle.com>
+Date: Mon, 4 Oct 2021 00:34:23 +0200
+Subject: x86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n
+
+From: Vegard Nossum <vegard.nossum@oracle.com>
+
+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 <vegard.nossum@oracle.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20211003223423.8666-1-vegard.nossum@oracle.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+ }
--- /dev/null
+From 2c861f2b859385e9eaa6e464a8a7435b5a6bf564 Mon Sep 17 00:00:00 2001
+From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+Date: Tue, 3 Aug 2021 13:35:23 +0200
+Subject: x86/entry: Correct reference to intended CONFIG_64_BIT
+
+From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+
+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 <rdunlap@infradead.org>
+Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/20210803113531.30720-2-lukas.bulwahn@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 6e3cd95234dc1eda488f4f487c281bac8fef4d9b Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Thu, 30 Sep 2021 19:21:39 +0200
+Subject: x86/hpet: Use another crystalball to evaluate HPET usability
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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 <kuba@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Jakub Kicinski <kuba@kernel.org>
+Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>
+Cc: stable@vger.kernel.org
+Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Cc: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <asm/hpet.h>
+ #include <asm/time.h>
++#include <asm/mwait.h>
+
+ #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;
--- /dev/null
+From 225bac2dc5d192e55f2c50123ee539b1edf8a411 Mon Sep 17 00:00:00 2001
+From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+Date: Tue, 3 Aug 2021 13:35:25 +0200
+Subject: x86/Kconfig: Correct reference to MWINCHIP3D
+
+From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+
+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 <rdunlap@infradead.org>
+Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/20210803113531.30720-4-lukas.bulwahn@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 4758fd801f919b8b9acad78d2e49a195ec2be46b Mon Sep 17 00:00:00 2001
+From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+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 <lukas.bulwahn@gmail.com>
+
+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 <rdunlap@infradead.org>
+Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/20210803113531.30720-3-lukas.bulwahn@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 06f2ac3d4219bbbfd93d79e01966a42053084f11 Mon Sep 17 00:00:00 2001
+From: Tom Lendacky <thomas.lendacky@amd.com>
+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 <thomas.lendacky@amd.com>
+
+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 <thomas.lendacky@amd.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: <stable@vger.kernel.org> # 5.10+
+Link: https://lkml.kernel.org/r/efc772af831e9e7f517f0439b13b41f56bad8784.1633063321.git.thomas.lendacky@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
