--- /dev/null
+From 083fa05bbaf65a01866b5440031c822e32ad7510 Mon Sep 17 00:00:00 2001
+From: Praful Swarnakar <Praful.Swarnakar@amd.com>
+Date: Wed, 22 Sep 2021 23:01:29 +0530
+Subject: drm/amd/display: Fix Display Flicker on embedded panels
+
+From: Praful Swarnakar <Praful.Swarnakar@amd.com>
+
+commit 083fa05bbaf65a01866b5440031c822e32ad7510 upstream.
+
+[Why]
+ASSR is dependent on Signed PSP Verstage to enable Content
+Protection for eDP panels. Unsigned PSP verstage is used
+during development phase causing ASSR to FAIL.
+As a result, link training is performed with
+DP_PANEL_MODE_DEFAULT instead of DP_PANEL_MODE_EDP for
+eDP panels that causes display flicker on some panels.
+
+[How]
+- Do not change panel mode, if ASSR is disabled
+- Just report and continue to perform eDP link training
+with right settings further.
+
+Signed-off-by: Praful Swarnakar <Praful.Swarnakar@amd.com>
+Reviewed-by: Harry Wentland <harry.wentland@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 15 +++++++--------
+ 1 file changed, 7 insertions(+), 8 deletions(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
++++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+@@ -1813,14 +1813,13 @@ bool perform_link_training_with_retries(
+ if (panel_mode == DP_PANEL_MODE_EDP) {
+ struct cp_psp *cp_psp = &stream->ctx->cp_psp;
+
+- if (cp_psp && cp_psp->funcs.enable_assr) {
+- if (!cp_psp->funcs.enable_assr(cp_psp->handle, link)) {
+- /* since eDP implies ASSR on, change panel
+- * mode to disable ASSR
+- */
+- panel_mode = DP_PANEL_MODE_DEFAULT;
+- }
+- }
++ if (cp_psp && cp_psp->funcs.enable_assr)
++ /* ASSR is bound to fail with unsigned PSP
++ * verstage used during devlopment phase.
++ * Report and continue with eDP panel mode to
++ * perform eDP link training with right settings
++ */
++ cp_psp->funcs.enable_assr(cp_psp->handle, link);
+ }
+ #endif
+
--- /dev/null
+From 467a51b69d0828887fb1b6719159a6b16da688f8 Mon Sep 17 00:00:00 2001
+From: Josip Pavic <Josip.Pavic@amd.com>
+Date: Fri, 17 Sep 2021 11:01:47 -0400
+Subject: drm/amd/display: initialize backlight_ramping_override to false
+
+From: Josip Pavic <Josip.Pavic@amd.com>
+
+commit 467a51b69d0828887fb1b6719159a6b16da688f8 upstream.
+
+[Why]
+Stack variable params.backlight_ramping_override is uninitialized, so it
+contains junk data
+
+[How]
+Initialize the variable to false
+
+Reviewed-by: Roman Li <Roman.Li@amd.com>
+Acked-by: Anson Jacob <Anson.Jacob@amd.com>
+Signed-off-by: Josip Pavic <Josip.Pavic@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+@@ -1724,6 +1724,7 @@ static int dm_late_init(void *handle)
+ linear_lut[i] = 0xFFFF * i / 15;
+
+ params.set = 0;
++ params.backlight_ramping_override = false;
+ params.backlight_ramping_start = 0xCCCC;
+ params.backlight_ramping_reduction = 0xCCCCCCCC;
+ params.backlight_lut_array_size = 16;
--- /dev/null
+From d942856865c733ff60450de9691af796ad71d7bc Mon Sep 17 00:00:00 2001
+From: Charlene Liu <Charlene.Liu@amd.com>
+Date: Mon, 20 Sep 2021 14:30:02 -0400
+Subject: drm/amd/display: Pass PCI deviceid into DC
+
+From: Charlene Liu <Charlene.Liu@amd.com>
+
+commit d942856865c733ff60450de9691af796ad71d7bc upstream.
+
+[why]
+pci deviceid not passed to dal dc, without proper break,
+dcn2.x falls into dcn3.x code path
+
+[how]
+pass in pci deviceid, and break once dal_version initialized.
+
+Reviewed-by: Zhan Liu <Zhan.Liu@amd.com>
+Acked-by: Anson Jacob <Anson.Jacob@amd.com>
+Signed-off-by: Charlene Liu <Charlene.Liu@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+@@ -1117,6 +1117,7 @@ static int amdgpu_dm_init(struct amdgpu_
+
+ init_data.asic_id.pci_revision_id = adev->pdev->revision;
+ init_data.asic_id.hw_internal_rev = adev->external_rev_id;
++ init_data.asic_id.chip_id = adev->pdev->device;
+
+ init_data.asic_id.vram_width = adev->gmc.vram_width;
+ /* TODO: initialize init_data.asic_id.vram_type here!!!! */
--- /dev/null
+From 98122e63a7ecc08c4172a17d97a06ef5536eb268 Mon Sep 17 00:00:00 2001
+From: Simon Ser <contact@emersion.fr>
+Date: Mon, 27 Sep 2021 15:08:44 +0000
+Subject: drm/amdgpu: check tiling flags when creating FB on GFX8-
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Simon Ser <contact@emersion.fr>
+
+commit 98122e63a7ecc08c4172a17d97a06ef5536eb268 upstream.
+
+On GFX9+, format modifiers are always enabled and ensure the
+frame-buffers can be scanned out at ADDFB2 time.
+
+On GFX8-, format modifiers are not supported and no other check
+is performed. This means ADDFB2 IOCTLs will succeed even if the
+tiling isn't supported for scan-out, and will result in garbage
+displayed on screen [1].
+
+Fix this by adding a check for tiling flags for GFX8 and older.
+The check is taken from radeonsi in Mesa (see how is_displayable
+is populated in gfx6_compute_surface).
+
+Changes in v2: use drm_WARN_ONCE instead of drm_WARN (Michel)
+
+[1]: https://github.com/swaywm/wlroots/issues/3185
+
+Signed-off-by: Simon Ser <contact@emersion.fr>
+Acked-by: Michel Dänzer <mdaenzer@redhat.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: Harry Wentland <hwentlan@amd.com>
+Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
+Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 31 ++++++++++++++++++++++++++++
+ 1 file changed, 31 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+@@ -837,6 +837,28 @@ static int convert_tiling_flags_to_modif
+ return 0;
+ }
+
++/* Mirrors the is_displayable check in radeonsi's gfx6_compute_surface */
++static int check_tiling_flags_gfx6(struct amdgpu_framebuffer *afb)
++{
++ u64 micro_tile_mode;
++
++ /* Zero swizzle mode means linear */
++ if (AMDGPU_TILING_GET(afb->tiling_flags, SWIZZLE_MODE) == 0)
++ return 0;
++
++ micro_tile_mode = AMDGPU_TILING_GET(afb->tiling_flags, MICRO_TILE_MODE);
++ switch (micro_tile_mode) {
++ case 0: /* DISPLAY */
++ case 3: /* RENDER */
++ return 0;
++ default:
++ drm_dbg_kms(afb->base.dev,
++ "Micro tile mode %llu not supported for scanout\n",
++ micro_tile_mode);
++ return -EINVAL;
++ }
++}
++
+ static void get_block_dimensions(unsigned int block_log2, unsigned int cpp,
+ unsigned int *width, unsigned int *height)
+ {
+@@ -1103,6 +1125,7 @@ int amdgpu_display_framebuffer_init(stru
+ const struct drm_mode_fb_cmd2 *mode_cmd,
+ struct drm_gem_object *obj)
+ {
++ struct amdgpu_device *adev = drm_to_adev(dev);
+ int ret, i;
+
+ /*
+@@ -1122,6 +1145,14 @@ int amdgpu_display_framebuffer_init(stru
+ if (ret)
+ return ret;
+
++ if (!dev->mode_config.allow_fb_modifiers) {
++ drm_WARN_ONCE(dev, adev->family >= AMDGPU_FAMILY_AI,
++ "GFX9+ requires FB check based on format modifier\n");
++ ret = check_tiling_flags_gfx6(rfb);
++ if (ret)
++ return ret;
++ }
++
+ if (dev->mode_config.allow_fb_modifiers &&
+ !(rfb->base.flags & DRM_MODE_FB_MODIFIERS)) {
+ ret = convert_tiling_flags_to_modifier(rfb);
--- /dev/null
+From 9f52c25f59b504a29dda42d83ac1e24d2af535d4 Mon Sep 17 00:00:00 2001
+From: Hawking Zhang <Hawking.Zhang@amd.com>
+Date: Sun, 26 Sep 2021 22:19:35 +0800
+Subject: drm/amdgpu: correct initial cp_hqd_quantum for gfx9
+
+From: Hawking Zhang <Hawking.Zhang@amd.com>
+
+commit 9f52c25f59b504a29dda42d83ac1e24d2af535d4 upstream.
+
+didn't read the value of mmCP_HQD_QUANTUM from correct
+register offset
+
+Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Reviewed-by: Le Ma <Le.Ma@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+@@ -3598,7 +3598,7 @@ static int gfx_v9_0_mqd_init(struct amdg
+
+ /* set static priority for a queue/ring */
+ gfx_v9_0_mqd_set_priority(ring, mqd);
+- mqd->cp_hqd_quantum = RREG32(mmCP_HQD_QUANTUM);
++ mqd->cp_hqd_quantum = RREG32_SOC15(GC, 0, mmCP_HQD_QUANTUM);
+
+ /* map_queues packet doesn't need activate the queue,
+ * so only kiq need set this field.
--- /dev/null
+From 26db706a6d77b9e184feb11725e97e53b7a89519 Mon Sep 17 00:00:00 2001
+From: Prike Liang <Prike.Liang@amd.com>
+Date: Wed, 25 Aug 2021 13:36:38 +0800
+Subject: drm/amdgpu: force exit gfxoff on sdma resume for rmb s0ix
+
+From: Prike Liang <Prike.Liang@amd.com>
+
+commit 26db706a6d77b9e184feb11725e97e53b7a89519 upstream.
+
+In the s2idle stress test sdma resume fail occasionally,in the
+failed case GPU is in the gfxoff state.This issue may introduce
+by firmware miss handle doorbell S/R and now temporary fix the issue
+by forcing exit gfxoff for sdma resume.
+
+Signed-off-by: Prike Liang <Prike.Liang@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
++++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
+@@ -883,6 +883,12 @@ static int sdma_v5_2_start(struct amdgpu
+ msleep(1000);
+ }
+
++ /* TODO: check whether can submit a doorbell request to raise
++ * a doorbell fence to exit gfxoff.
++ */
++ if (adev->in_s0ix)
++ amdgpu_gfx_off_ctrl(adev, false);
++
+ sdma_v5_2_soft_reset(adev);
+ /* unhalt the MEs */
+ sdma_v5_2_enable(adev, true);
+@@ -891,6 +897,8 @@ static int sdma_v5_2_start(struct amdgpu
+
+ /* start the gfx rings and rlc compute queues */
+ r = sdma_v5_2_gfx_resume(adev);
++ if (adev->in_s0ix)
++ amdgpu_gfx_off_ctrl(adev, true);
+ if (r)
+ return r;
+ r = sdma_v5_2_rlc_resume(adev);
--- /dev/null
+From 8d68bad6d869fae8f4d50ab6423538dec7da72d1 Mon Sep 17 00:00:00 2001
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+Date: Tue, 7 Sep 2021 18:35:30 +0200
+Subject: KVM: nVMX: Filter out all unsupported controls when eVMCS was activated
+
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+
+commit 8d68bad6d869fae8f4d50ab6423538dec7da72d1 upstream.
+
+Windows Server 2022 with Hyper-V role enabled failed to boot on KVM when
+enlightened VMCS is advertised. Debugging revealed there are two exposed
+secondary controls it is not happy with: SECONDARY_EXEC_ENABLE_VMFUNC and
+SECONDARY_EXEC_SHADOW_VMCS. These controls are known to be unsupported,
+as there are no corresponding fields in eVMCSv1 (see the comment above
+EVMCS1_UNSUPPORTED_2NDEXEC definition).
+
+Previously, commit 31de3d2500e4 ("x86/kvm/hyper-v: move VMX controls
+sanitization out of nested_enable_evmcs()") introduced the required
+filtering mechanism for VMX MSRs but for some reason put only known
+to be problematic (and not full EVMCS1_UNSUPPORTED_* lists) controls
+there.
+
+Note, Windows Server 2022 seems to have gained some sanity check for VMX
+MSRs: it doesn't even try to launch a guest when there's something it
+doesn't like, nested_evmcs_check_controls() mechanism can't catch the
+problem.
+
+Let's be bold this time and instead of playing whack-a-mole just filter out
+all unsupported controls from VMX MSRs.
+
+Fixes: 31de3d2500e4 ("x86/kvm/hyper-v: move VMX controls sanitization out of nested_enable_evmcs()")
+Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Message-Id: <20210907163530.110066-1-vkuznets@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/evmcs.c | 12 +++++++++---
+ arch/x86/kvm/vmx/vmx.c | 9 +++++----
+ 2 files changed, 14 insertions(+), 7 deletions(-)
+
+--- a/arch/x86/kvm/vmx/evmcs.c
++++ b/arch/x86/kvm/vmx/evmcs.c
+@@ -354,14 +354,20 @@ void nested_evmcs_filter_control_msr(u32
+ switch (msr_index) {
+ case MSR_IA32_VMX_EXIT_CTLS:
+ case MSR_IA32_VMX_TRUE_EXIT_CTLS:
+- ctl_high &= ~VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL;
++ ctl_high &= ~EVMCS1_UNSUPPORTED_VMEXIT_CTRL;
+ break;
+ case MSR_IA32_VMX_ENTRY_CTLS:
+ case MSR_IA32_VMX_TRUE_ENTRY_CTLS:
+- ctl_high &= ~VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL;
++ ctl_high &= ~EVMCS1_UNSUPPORTED_VMENTRY_CTRL;
+ break;
+ case MSR_IA32_VMX_PROCBASED_CTLS2:
+- ctl_high &= ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
++ ctl_high &= ~EVMCS1_UNSUPPORTED_2NDEXEC;
++ break;
++ case MSR_IA32_VMX_PINBASED_CTLS:
++ ctl_high &= ~EVMCS1_UNSUPPORTED_PINCTRL;
++ break;
++ case MSR_IA32_VMX_VMFUNC:
++ ctl_low &= ~EVMCS1_UNSUPPORTED_VMFUNC;
+ break;
+ }
+
+--- a/arch/x86/kvm/vmx/vmx.c
++++ b/arch/x86/kvm/vmx/vmx.c
+@@ -1840,10 +1840,11 @@ static int vmx_get_msr(struct kvm_vcpu *
+ &msr_info->data))
+ return 1;
+ /*
+- * Enlightened VMCS v1 doesn't have certain fields, but buggy
+- * Hyper-V versions are still trying to use corresponding
+- * features when they are exposed. Filter out the essential
+- * minimum.
++ * Enlightened VMCS v1 doesn't have certain VMCS fields but
++ * instead of just ignoring the features, different Hyper-V
++ * versions are either trying to use them and fail or do some
++ * sanity checking and refuse to boot. Filter all unsupported
++ * features out.
+ */
+ if (!msr_info->host_initiated &&
+ vmx->nested.enlightened_vmcs_enabled)
--- /dev/null
+From 24a996ade34d00deef5dee2c33aacd8fda91ec31 Mon Sep 17 00:00:00 2001
+From: Chenyi Qiang <chenyi.qiang@intel.com>
+Date: Tue, 14 Sep 2021 17:50:41 +0800
+Subject: KVM: nVMX: Fix nested bus lock VM exit
+
+From: Chenyi Qiang <chenyi.qiang@intel.com>
+
+commit 24a996ade34d00deef5dee2c33aacd8fda91ec31 upstream.
+
+Nested bus lock VM exits are not supported yet. If L2 triggers bus lock
+VM exit, it will be directed to L1 VMM, which would cause unexpected
+behavior. Therefore, handle L2's bus lock VM exits in L0 directly.
+
+Fixes: fe6b6bc802b4 ("KVM: VMX: Enable bus lock VM exit")
+Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
+Reviewed-by: Sean Christopherson <seanjc@google.com>
+Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
+Message-Id: <20210914095041.29764-1-chenyi.qiang@intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/nested.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/arch/x86/kvm/vmx/nested.c
++++ b/arch/x86/kvm/vmx/nested.c
+@@ -5898,6 +5898,12 @@ static bool nested_vmx_l0_wants_exit(str
+ case EXIT_REASON_VMFUNC:
+ /* VM functions are emulated through L2->L0 vmexits. */
+ return true;
++ case EXIT_REASON_BUS_LOCK:
++ /*
++ * At present, bus lock VM exit is never exposed to L1.
++ * Handle L2's bus locks in L0 directly.
++ */
++ return true;
+ default:
+ break;
+ }
--- /dev/null
+From bb18a677746543e7f5eeb478129c92cedb0f9658 Mon Sep 17 00:00:00 2001
+From: Peter Gonda <pgonda@google.com>
+Date: Wed, 15 Sep 2021 10:17:55 -0700
+Subject: KVM: SEV: Acquire vcpu mutex when updating VMSA
+
+From: Peter Gonda <pgonda@google.com>
+
+commit bb18a677746543e7f5eeb478129c92cedb0f9658 upstream.
+
+The update-VMSA ioctl touches data stored in struct kvm_vcpu, and
+therefore should not be performed concurrently with any VCPU ioctl
+that might cause KVM or the processor to use the same data.
+
+Adds vcpu mutex guard to the VMSA updating code. Refactors out
+__sev_launch_update_vmsa() function to deal with per vCPU parts
+of sev_launch_update_vmsa().
+
+Fixes: ad73109ae7ec ("KVM: SVM: Provide support to launch and run an SEV-ES guest")
+Signed-off-by: Peter Gonda <pgonda@google.com>
+Cc: Marc Orr <marcorr@google.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Cc: Sean Christopherson <seanjc@google.com>
+Cc: Brijesh Singh <brijesh.singh@amd.com>
+Cc: kvm@vger.kernel.org
+Cc: stable@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Message-Id: <20210915171755.3773766-1-pgonda@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/sev.c | 53 +++++++++++++++++++++++++++----------------------
+ 1 file changed, 30 insertions(+), 23 deletions(-)
+
+--- a/arch/x86/kvm/svm/sev.c
++++ b/arch/x86/kvm/svm/sev.c
+@@ -596,43 +596,50 @@ static int sev_es_sync_vmsa(struct vcpu_
+ return 0;
+ }
+
+-static int sev_launch_update_vmsa(struct kvm *kvm, struct kvm_sev_cmd *argp)
++static int __sev_launch_update_vmsa(struct kvm *kvm, struct kvm_vcpu *vcpu,
++ int *error)
+ {
+- struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info;
+ struct sev_data_launch_update_vmsa vmsa;
++ struct vcpu_svm *svm = to_svm(vcpu);
++ int ret;
++
++ /* Perform some pre-encryption checks against the VMSA */
++ ret = sev_es_sync_vmsa(svm);
++ if (ret)
++ return ret;
++
++ /*
++ * The LAUNCH_UPDATE_VMSA command will perform in-place encryption of
++ * the VMSA memory content (i.e it will write the same memory region
++ * with the guest's key), so invalidate it first.
++ */
++ clflush_cache_range(svm->vmsa, PAGE_SIZE);
++
++ vmsa.reserved = 0;
++ vmsa.handle = to_kvm_svm(kvm)->sev_info.handle;
++ vmsa.address = __sme_pa(svm->vmsa);
++ vmsa.len = PAGE_SIZE;
++ return sev_issue_cmd(kvm, SEV_CMD_LAUNCH_UPDATE_VMSA, &vmsa, error);
++}
++
++static int sev_launch_update_vmsa(struct kvm *kvm, struct kvm_sev_cmd *argp)
++{
+ struct kvm_vcpu *vcpu;
+ int i, ret;
+
+ if (!sev_es_guest(kvm))
+ return -ENOTTY;
+
+- vmsa.reserved = 0;
+-
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+- struct vcpu_svm *svm = to_svm(vcpu);
+-
+- /* Perform some pre-encryption checks against the VMSA */
+- ret = sev_es_sync_vmsa(svm);
++ ret = mutex_lock_killable(&vcpu->mutex);
+ if (ret)
+ return ret;
+
+- /*
+- * The LAUNCH_UPDATE_VMSA command will perform in-place
+- * encryption of the VMSA memory content (i.e it will write
+- * the same memory region with the guest's key), so invalidate
+- * it first.
+- */
+- clflush_cache_range(svm->vmsa, PAGE_SIZE);
+-
+- vmsa.handle = sev->handle;
+- vmsa.address = __sme_pa(svm->vmsa);
+- vmsa.len = PAGE_SIZE;
+- ret = sev_issue_cmd(kvm, SEV_CMD_LAUNCH_UPDATE_VMSA, &vmsa,
+- &argp->error);
++ ret = __sev_launch_update_vmsa(kvm, vcpu, &argp->error);
++
++ mutex_unlock(&vcpu->mutex);
+ if (ret)
+ return ret;
+-
+- svm->vcpu.arch.guest_state_protected = true;
+ }
+
+ return 0;
--- /dev/null
+From 5b92b6ca92b65bef811048c481e4446f4828500a Mon Sep 17 00:00:00 2001
+From: Peter Gonda <pgonda@google.com>
+Date: Tue, 21 Sep 2021 08:03:45 -0700
+Subject: KVM: SEV: Allow some commands for mirror VM
+
+From: Peter Gonda <pgonda@google.com>
+
+commit 5b92b6ca92b65bef811048c481e4446f4828500a upstream.
+
+A mirrored SEV-ES VM will need to call KVM_SEV_LAUNCH_UPDATE_VMSA to
+setup its vCPUs and have them measured, and their VMSAs encrypted. Without
+this change, it is impossible to have mirror VMs as part of SEV-ES VMs.
+
+Also allow the guest status check and debugging commands since they do
+not change any guest state.
+
+Signed-off-by: Peter Gonda <pgonda@google.com>
+Cc: Marc Orr <marcorr@google.com>
+Cc: Nathan Tempelman <natet@google.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Cc: Sean Christopherson <seanjc@google.com>
+Cc: Steve Rutherford <srutherford@google.com>
+Cc: Brijesh Singh <brijesh.singh@amd.com>
+Cc: kvm@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Cc: stable@vger.kernel.org
+Fixes: 54526d1fd593 ("KVM: x86: Support KVM VMs sharing SEV context", 2021-04-21)
+Message-Id: <20210921150345.2221634-3-pgonda@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/sev.c | 19 +++++++++++++++++--
+ 1 file changed, 17 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/svm/sev.c
++++ b/arch/x86/kvm/svm/sev.c
+@@ -1509,6 +1509,20 @@ static int sev_receive_finish(struct kvm
+ return sev_issue_cmd(kvm, SEV_CMD_RECEIVE_FINISH, &data, &argp->error);
+ }
+
++static bool cmd_allowed_from_miror(u32 cmd_id)
++{
++ /*
++ * Allow mirrors VM to call KVM_SEV_LAUNCH_UPDATE_VMSA to enable SEV-ES
++ * active mirror VMs. Also allow the debugging and status commands.
++ */
++ if (cmd_id == KVM_SEV_LAUNCH_UPDATE_VMSA ||
++ cmd_id == KVM_SEV_GUEST_STATUS || cmd_id == KVM_SEV_DBG_DECRYPT ||
++ cmd_id == KVM_SEV_DBG_ENCRYPT)
++ return true;
++
++ return false;
++}
++
+ int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
+ {
+ struct kvm_sev_cmd sev_cmd;
+@@ -1525,8 +1539,9 @@ int svm_mem_enc_op(struct kvm *kvm, void
+
+ mutex_lock(&kvm->lock);
+
+- /* enc_context_owner handles all memory enc operations */
+- if (is_mirroring_enc_context(kvm)) {
++ /* Only the enc_context_owner handles some memory enc operations. */
++ if (is_mirroring_enc_context(kvm) &&
++ !cmd_allowed_from_miror(sev_cmd.id)) {
+ r = -EINVAL;
+ goto out;
+ }
--- /dev/null
+From 50c038018d6be20361e8a2890262746a4ac5b11f Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Tue, 14 Sep 2021 14:09:50 -0700
+Subject: KVM: SEV: Pin guest memory for write for RECEIVE_UPDATE_DATA
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 50c038018d6be20361e8a2890262746a4ac5b11f upstream.
+
+Require the target guest page to be writable when pinning memory for
+RECEIVE_UPDATE_DATA. Per the SEV API, the PSP writes to guest memory:
+
+ The result is then encrypted with GCTX.VEK and written to the memory
+ pointed to by GUEST_PADDR field.
+
+Fixes: 15fb7de1a7f5 ("KVM: SVM: Add KVM_SEV_RECEIVE_UPDATE_DATA command")
+Cc: stable@vger.kernel.org
+Cc: Peter Gonda <pgonda@google.com>
+Cc: Marc Orr <marcorr@google.com>
+Cc: Tom Lendacky <thomas.lendacky@amd.com>
+Cc: Brijesh Singh <brijesh.singh@amd.com>
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20210914210951.2994260-2-seanjc@google.com>
+Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
+Reviewed-by: Peter Gonda <pgonda@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/sev.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/svm/sev.c
++++ b/arch/x86/kvm/svm/sev.c
+@@ -1465,7 +1465,7 @@ static int sev_receive_update_data(struc
+
+ /* Pin guest memory */
+ guest_page = sev_pin_memory(kvm, params.guest_uaddr & PAGE_MASK,
+- PAGE_SIZE, &n, 0);
++ PAGE_SIZE, &n, 1);
+ if (IS_ERR(guest_page)) {
+ ret = PTR_ERR(guest_page);
+ goto e_free_trans;
--- /dev/null
+From f43c887cb7cb5b66c4167d40a4209027f5fdb5ce Mon Sep 17 00:00:00 2001
+From: Peter Gonda <pgonda@google.com>
+Date: Tue, 21 Sep 2021 08:03:44 -0700
+Subject: KVM: SEV: Update svm_vm_copy_asid_from for SEV-ES
+
+From: Peter Gonda <pgonda@google.com>
+
+commit f43c887cb7cb5b66c4167d40a4209027f5fdb5ce upstream.
+
+For mirroring SEV-ES the mirror VM will need more then just the ASID.
+The FD and the handle are required to all the mirror to call psp
+commands. The mirror VM will need to call KVM_SEV_LAUNCH_UPDATE_VMSA to
+setup its vCPUs' VMSAs for SEV-ES.
+
+Signed-off-by: Peter Gonda <pgonda@google.com>
+Cc: Marc Orr <marcorr@google.com>
+Cc: Nathan Tempelman <natet@google.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Cc: Sean Christopherson <seanjc@google.com>
+Cc: Steve Rutherford <srutherford@google.com>
+Cc: Brijesh Singh <brijesh.singh@amd.com>
+Cc: kvm@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Cc: stable@vger.kernel.org
+Fixes: 54526d1fd593 ("KVM: x86: Support KVM VMs sharing SEV context", 2021-04-21)
+Message-Id: <20210921150345.2221634-2-pgonda@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/sev.c | 16 ++++++++++++----
+ 1 file changed, 12 insertions(+), 4 deletions(-)
+
+--- a/arch/x86/kvm/svm/sev.c
++++ b/arch/x86/kvm/svm/sev.c
+@@ -1716,8 +1716,7 @@ int svm_vm_copy_asid_from(struct kvm *kv
+ {
+ struct file *source_kvm_file;
+ struct kvm *source_kvm;
+- struct kvm_sev_info *mirror_sev;
+- unsigned int asid;
++ struct kvm_sev_info source_sev, *mirror_sev;
+ int ret;
+
+ source_kvm_file = fget(source_fd);
+@@ -1740,7 +1739,8 @@ int svm_vm_copy_asid_from(struct kvm *kv
+ goto e_source_unlock;
+ }
+
+- asid = to_kvm_svm(source_kvm)->sev_info.asid;
++ memcpy(&source_sev, &to_kvm_svm(source_kvm)->sev_info,
++ sizeof(source_sev));
+
+ /*
+ * The mirror kvm holds an enc_context_owner ref so its asid can't
+@@ -1760,8 +1760,16 @@ int svm_vm_copy_asid_from(struct kvm *kv
+ /* Set enc_context_owner and copy its encryption context over */
+ mirror_sev = &to_kvm_svm(kvm)->sev_info;
+ mirror_sev->enc_context_owner = source_kvm;
+- mirror_sev->asid = asid;
+ mirror_sev->active = true;
++ mirror_sev->asid = source_sev.asid;
++ mirror_sev->fd = source_sev.fd;
++ mirror_sev->es_active = source_sev.es_active;
++ mirror_sev->handle = source_sev.handle;
++ /*
++ * Do not copy ap_jump_table. Since the mirror does not share the same
++ * KVM contexts as the original, and they may have different
++ * memory-views.
++ */
+
+ mutex_unlock(&kvm->lock);
+ return 0;
--- /dev/null
+From f1815e0aa770f2127c5df31eb5c2f0e37b60fa77 Mon Sep 17 00:00:00 2001
+From: Mingwei Zhang <mizhang@google.com>
+Date: Sun, 12 Sep 2021 18:18:15 +0000
+Subject: KVM: SVM: fix missing sev_decommission in sev_receive_start
+
+From: Mingwei Zhang <mizhang@google.com>
+
+commit f1815e0aa770f2127c5df31eb5c2f0e37b60fa77 upstream.
+
+DECOMMISSION the current SEV context if binding an ASID fails after
+RECEIVE_START. Per AMD's SEV API, RECEIVE_START generates a new guest
+context and thus needs to be paired with DECOMMISSION:
+
+ The RECEIVE_START command is the only command other than the LAUNCH_START
+ command that generates a new guest context and guest handle.
+
+The missing DECOMMISSION can result in subsequent SEV launch failures,
+as the firmware leaks memory and might not able to allocate more SEV
+guest contexts in the future.
+
+Note, LAUNCH_START suffered the same bug, but was previously fixed by
+commit 934002cd660b ("KVM: SVM: Call SEV Guest Decommission if ASID
+binding fails").
+
+Cc: Alper Gun <alpergun@google.com>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Brijesh Singh <brijesh.singh@amd.com>
+Cc: David Rienjes <rientjes@google.com>
+Cc: Marc Orr <marcorr@google.com>
+Cc: John Allen <john.allen@amd.com>
+Cc: Peter Gonda <pgonda@google.com>
+Cc: Sean Christopherson <seanjc@google.com>
+Cc: Tom Lendacky <thomas.lendacky@amd.com>
+Cc: Vipin Sharma <vipinsh@google.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Marc Orr <marcorr@google.com>
+Acked-by: Brijesh Singh <brijesh.singh@amd.com>
+Fixes: af43cbbf954b ("KVM: SVM: Add support for KVM_SEV_RECEIVE_START command")
+Signed-off-by: Mingwei Zhang <mizhang@google.com>
+Reviewed-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20210912181815.3899316-1-mizhang@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/sev.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/svm/sev.c
++++ b/arch/x86/kvm/svm/sev.c
+@@ -1405,8 +1405,10 @@ static int sev_receive_start(struct kvm
+
+ /* Bind ASID to this guest */
+ ret = sev_bind_asid(kvm, start.handle, error);
+- if (ret)
++ if (ret) {
++ sev_decommission(start.handle);
+ goto e_free_session;
++ }
+
+ params.handle = start.handle;
+ if (copy_to_user((void __user *)(uintptr_t)argp->data,
--- /dev/null
+From 5c49d1850ddd3240d20dc40b01f593e35a184f38 Mon Sep 17 00:00:00 2001
+From: Zhenzhong Duan <zhenzhong.duan@intel.com>
+Date: Sun, 26 Sep 2021 09:55:45 +0800
+Subject: KVM: VMX: Fix a TSX_CTRL_CPUID_CLEAR field mask issue
+
+From: Zhenzhong Duan <zhenzhong.duan@intel.com>
+
+commit 5c49d1850ddd3240d20dc40b01f593e35a184f38 upstream.
+
+When updating the host's mask for its MSR_IA32_TSX_CTRL user return entry,
+clear the mask in the found uret MSR instead of vmx->guest_uret_msrs[i].
+Modifying guest_uret_msrs directly is completely broken as 'i' does not
+point at the MSR_IA32_TSX_CTRL entry. In fact, it's guaranteed to be an
+out-of-bounds accesses as is always set to kvm_nr_uret_msrs in a prior
+loop. By sheer dumb luck, the fallout is limited to "only" failing to
+preserve the host's TSX_CTRL_CPUID_CLEAR. The out-of-bounds access is
+benign as it's guaranteed to clear a bit in a guest MSR value, which are
+always zero at vCPU creation on both x86-64 and i386.
+
+Cc: stable@vger.kernel.org
+Fixes: 8ea8b8d6f869 ("KVM: VMX: Use common x86's uret MSR list as the one true list")
+Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
+Reviewed-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20210926015545.281083-1-zhenzhong.duan@intel.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/vmx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/vmx/vmx.c
++++ b/arch/x86/kvm/vmx/vmx.c
+@@ -6816,7 +6816,7 @@ static int vmx_create_vcpu(struct kvm_vc
+ */
+ tsx_ctrl = vmx_find_uret_msr(vmx, MSR_IA32_TSX_CTRL);
+ if (tsx_ctrl)
+- vmx->guest_uret_msrs[i].mask = ~(u64)TSX_CTRL_CPUID_CLEAR;
++ tsx_ctrl->mask = ~(u64)TSX_CTRL_CPUID_CLEAR;
+ }
+
+ err = alloc_loaded_vmcs(&vmx->vmcs01);
--- /dev/null
+From 03a6e84069d1870f5b3d360e64cb330b66f76dee Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Mon, 20 Sep 2021 17:02:55 -0700
+Subject: KVM: x86: Clear KVM's cached guest CR3 at RESET/INIT
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 03a6e84069d1870f5b3d360e64cb330b66f76dee upstream.
+
+Explicitly zero the guest's CR3 and mark it available+dirty at RESET/INIT.
+Per Intel's SDM and AMD's APM, CR3 is zeroed at both RESET and INIT. For
+RESET, this is a nop as vcpu is zero-allocated. For INIT, the bug has
+likely escaped notice because no firmware/kernel puts its page tables root
+at PA=0, let alone relies on INIT to get the desired CR3 for such page
+tables.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20210921000303.400537-3-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/x86.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -10873,6 +10873,9 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcp
+
+ static_call(kvm_x86_vcpu_reset)(vcpu, init_event);
+
++ vcpu->arch.cr3 = 0;
++ kvm_register_mark_dirty(vcpu, VCPU_EXREG_CR3);
++
+ /*
+ * Reset the MMU context if paging was enabled prior to INIT (which is
+ * implied if CR0.PG=1 as CR0 will be '0' prior to RESET). Unlike the
--- /dev/null
+From 2f9b68f57c6278c322793a06063181deded0ad69 Mon Sep 17 00:00:00 2001
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+Date: Fri, 27 Aug 2021 11:25:14 +0200
+Subject: KVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect()
+
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+
+commit 2f9b68f57c6278c322793a06063181deded0ad69 upstream.
+
+KASAN reports the following issue:
+
+ BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
+ Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798
+
+ CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G X --------- ---
+ Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020
+ Call Trace:
+ dump_stack+0xa5/0xe6
+ print_address_description.constprop.0+0x18/0x130
+ ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
+ __kasan_report.cold+0x7f/0x114
+ ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
+ kasan_report+0x38/0x50
+ kasan_check_range+0xf5/0x1d0
+ kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
+ kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm]
+ ? kvm_arch_exit+0x110/0x110 [kvm]
+ ? sched_clock+0x5/0x10
+ ioapic_write_indirect+0x59f/0x9e0 [kvm]
+ ? static_obj+0xc0/0xc0
+ ? __lock_acquired+0x1d2/0x8c0
+ ? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm]
+
+The problem appears to be that 'vcpu_bitmap' is allocated as a single long
+on stack and it should really be KVM_MAX_VCPUS long. We also seem to clear
+the lower 16 bits of it with bitmap_zero() for no particular reason (my
+guess would be that 'bitmap' and 'vcpu_bitmap' variables in
+kvm_bitmap_or_dest_vcpus() caused the confusion: while the later is indeed
+16-bit long, the later should accommodate all possible vCPUs).
+
+Fixes: 7ee30bc132c6 ("KVM: x86: deliver KVM IOAPIC scan request to target vCPUs")
+Fixes: 9a2ae9f6b6bb ("KVM: x86: Zero the IOAPIC scan request dest vCPUs bitmap")
+Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
+Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
+Reviewed-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20210827092516.1027264-7-vkuznets@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/ioapic.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/kvm/ioapic.c
++++ b/arch/x86/kvm/ioapic.c
+@@ -319,8 +319,8 @@ static void ioapic_write_indirect(struct
+ unsigned index;
+ bool mask_before, mask_after;
+ union kvm_ioapic_redirect_entry *e;
+- unsigned long vcpu_bitmap;
+ int old_remote_irr, old_delivery_status, old_dest_id, old_dest_mode;
++ DECLARE_BITMAP(vcpu_bitmap, KVM_MAX_VCPUS);
+
+ switch (ioapic->ioregsel) {
+ case IOAPIC_REG_VERSION:
+@@ -384,9 +384,9 @@ static void ioapic_write_indirect(struct
+ irq.shorthand = APIC_DEST_NOSHORT;
+ irq.dest_id = e->fields.dest_id;
+ irq.msi_redir_hint = false;
+- bitmap_zero(&vcpu_bitmap, 16);
++ bitmap_zero(vcpu_bitmap, KVM_MAX_VCPUS);
+ kvm_bitmap_or_dest_vcpus(ioapic->kvm, &irq,
+- &vcpu_bitmap);
++ vcpu_bitmap);
+ if (old_dest_mode != e->fields.dest_mode ||
+ old_dest_id != e->fields.dest_id) {
+ /*
+@@ -399,10 +399,10 @@ static void ioapic_write_indirect(struct
+ kvm_lapic_irq_dest_mode(
+ !!e->fields.dest_mode);
+ kvm_bitmap_or_dest_vcpus(ioapic->kvm, &irq,
+- &vcpu_bitmap);
++ vcpu_bitmap);
+ }
+ kvm_make_scan_ioapic_request_mask(ioapic->kvm,
+- &vcpu_bitmap);
++ vcpu_bitmap);
+ } else {
+ kvm_make_scan_ioapic_request(ioapic->kvm);
+ }
--- /dev/null
+From faf6b755629627f19feafa75b32e81cd7738f12d Mon Sep 17 00:00:00 2001
+From: Maxim Levitsky <mlevitsk@redhat.com>
+Date: Tue, 14 Sep 2021 18:48:16 +0300
+Subject: KVM: x86: nSVM: don't copy virt_ext from vmcb12
+
+From: Maxim Levitsky <mlevitsk@redhat.com>
+
+commit faf6b755629627f19feafa75b32e81cd7738f12d upstream.
+
+These field correspond to features that we don't expose yet to L2
+
+While currently there are no CVE worthy features in this field,
+if AMD adds more features to this field, that could allow guest
+escapes similar to CVE-2021-3653 and CVE-2021-3656.
+
+Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
+Message-Id: <20210914154825.104886-6-mlevitsk@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/nested.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/arch/x86/kvm/svm/nested.c
++++ b/arch/x86/kvm/svm/nested.c
+@@ -545,7 +545,6 @@ static void nested_vmcb02_prepare_contro
+ (svm->nested.ctl.int_ctl & int_ctl_vmcb12_bits) |
+ (svm->vmcb01.ptr->control.int_ctl & int_ctl_vmcb01_bits);
+
+- svm->vmcb->control.virt_ext = svm->nested.ctl.virt_ext;
+ svm->vmcb->control.int_vector = svm->nested.ctl.int_vector;
+ svm->vmcb->control.int_state = svm->nested.ctl.int_state;
+ svm->vmcb->control.event_inj = svm->nested.ctl.event_inj;
--- /dev/null
+From e8a747d0884e554a8c1872da6c8f680a4f893c6d Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Wed, 29 Sep 2021 15:24:25 -0700
+Subject: KVM: x86: Swap order of CPUID entry "index" vs. "significant flag" checks
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit e8a747d0884e554a8c1872da6c8f680a4f893c6d upstream.
+
+Check whether a CPUID entry's index is significant before checking for a
+matching index to hack-a-fix an undefined behavior bug due to consuming
+uninitialized data. RESET/INIT emulation uses kvm_cpuid() to retrieve
+CPUID.0x1, which does _not_ have a significant index, and fails to
+initialize the dummy variable that doubles as EBX/ECX/EDX output _and_
+ECX, a.k.a. index, input.
+
+Practically speaking, it's _extremely_ unlikely any compiler will yield
+code that causes problems, as the compiler would need to inline the
+kvm_cpuid() call to detect the uninitialized data, and intentionally hose
+the kernel, e.g. insert ud2, instead of simply ignoring the result of
+the index comparison.
+
+Although the sketchy "dummy" pattern was introduced in SVM by commit
+66f7b72e1171 ("KVM: x86: Make register state after reset conform to
+specification"), it wasn't actually broken until commit 7ff6c0350315
+("KVM: x86: Remove stateful CPUID handling") arbitrarily swapped the
+order of operations such that "index" was checked before the significant
+flag.
+
+Avoid consuming uninitialized data by reverting to checking the flag
+before the index purely so that the fix can be easily backported; the
+offending RESET/INIT code has been refactored, moved, and consolidated
+from vendor code to common x86 since the bug was introduced. A future
+patch will directly address the bad RESET/INIT behavior.
+
+The undefined behavior was detected by syzbot + KernelMemorySanitizer.
+
+ BUG: KMSAN: uninit-value in cpuid_entry2_find arch/x86/kvm/cpuid.c:68
+ BUG: KMSAN: uninit-value in kvm_find_cpuid_entry arch/x86/kvm/cpuid.c:1103
+ BUG: KMSAN: uninit-value in kvm_cpuid+0x456/0x28f0 arch/x86/kvm/cpuid.c:1183
+ cpuid_entry2_find arch/x86/kvm/cpuid.c:68 [inline]
+ kvm_find_cpuid_entry arch/x86/kvm/cpuid.c:1103 [inline]
+ kvm_cpuid+0x456/0x28f0 arch/x86/kvm/cpuid.c:1183
+ kvm_vcpu_reset+0x13fb/0x1c20 arch/x86/kvm/x86.c:10885
+ kvm_apic_accept_events+0x58f/0x8c0 arch/x86/kvm/lapic.c:2923
+ vcpu_enter_guest+0xfd2/0x6d80 arch/x86/kvm/x86.c:9534
+ vcpu_run+0x7f5/0x18d0 arch/x86/kvm/x86.c:9788
+ kvm_arch_vcpu_ioctl_run+0x245b/0x2d10 arch/x86/kvm/x86.c:10020
+
+ Local variable ----dummy@kvm_vcpu_reset created at:
+ kvm_vcpu_reset+0x1fb/0x1c20 arch/x86/kvm/x86.c:10812
+ kvm_apic_accept_events+0x58f/0x8c0 arch/x86/kvm/lapic.c:2923
+
+Reported-by: syzbot+f3985126b746b3d59c9d@syzkaller.appspotmail.com
+Reported-by: Alexander Potapenko <glider@google.com>
+Fixes: 2a24be79b6b7 ("KVM: VMX: Set EDX at INIT with CPUID.0x1, Family-Model-Stepping")
+Fixes: 7ff6c0350315 ("KVM: x86: Remove stateful CPUID handling")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Message-Id: <20210929222426.1855730-2-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/cpuid.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/cpuid.c
++++ b/arch/x86/kvm/cpuid.c
+@@ -65,8 +65,8 @@ static inline struct kvm_cpuid_entry2 *c
+ for (i = 0; i < nent; i++) {
+ e = &entries[i];
+
+- if (e->function == function && (e->index == index ||
+- !(e->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX)))
++ if (e->function == function &&
++ (!(e->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX) || e->index == index))
+ return e;
+ }
+
--- /dev/null
+From f0c15b360fb65ee39849afe987c16eb3d0175d0d Mon Sep 17 00:00:00 2001
+From: Sean Young <sean@mess.org>
+Date: Tue, 14 Sep 2021 16:57:46 +0200
+Subject: media: ir_toy: prevent device from hanging during transmit
+
+From: Sean Young <sean@mess.org>
+
+commit f0c15b360fb65ee39849afe987c16eb3d0175d0d upstream.
+
+If the IR Toy is receiving IR while a transmit is done, it may end up
+hanging. We can prevent this from happening by re-entering sample mode
+just before issuing the transmit command.
+
+Link: https://github.com/bengtmartensson/HarcHardware/discussions/25
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/rc/ir_toy.c | 21 ++++++++++++++++++++-
+ 1 file changed, 20 insertions(+), 1 deletion(-)
+
+--- a/drivers/media/rc/ir_toy.c
++++ b/drivers/media/rc/ir_toy.c
+@@ -24,6 +24,7 @@ static const u8 COMMAND_VERSION[] = { 'v
+ // End transmit and repeat reset command so we exit sump mode
+ static const u8 COMMAND_RESET[] = { 0xff, 0xff, 0, 0, 0, 0, 0 };
+ static const u8 COMMAND_SMODE_ENTER[] = { 's' };
++static const u8 COMMAND_SMODE_EXIT[] = { 0 };
+ static const u8 COMMAND_TXSTART[] = { 0x26, 0x24, 0x25, 0x03 };
+
+ #define REPLY_XMITCOUNT 't'
+@@ -309,12 +310,30 @@ static int irtoy_tx(struct rc_dev *rc, u
+ buf[i] = cpu_to_be16(v);
+ }
+
+- buf[count] = cpu_to_be16(0xffff);
++ buf[count] = 0xffff;
+
+ irtoy->tx_buf = buf;
+ irtoy->tx_len = size;
+ irtoy->emitted = 0;
+
++ // There is an issue where if the unit is receiving IR while the
++ // first TXSTART command is sent, the device might end up hanging
++ // with its led on. It does not respond to any command when this
++ // happens. To work around this, re-enter sample mode.
++ err = irtoy_command(irtoy, COMMAND_SMODE_EXIT,
++ sizeof(COMMAND_SMODE_EXIT), STATE_RESET);
++ if (err) {
++ dev_err(irtoy->dev, "exit sample mode: %d\n", err);
++ return err;
++ }
++
++ err = irtoy_command(irtoy, COMMAND_SMODE_ENTER,
++ sizeof(COMMAND_SMODE_ENTER), STATE_COMMAND);
++ if (err) {
++ dev_err(irtoy->dev, "enter sample mode: %d\n", err);
++ return err;
++ }
++
+ err = irtoy_command(irtoy, COMMAND_TXSTART, sizeof(COMMAND_TXSTART),
+ STATE_TX);
+ kfree(buf);
--- /dev/null
+From b81bede4d138ce62f7342e27bf55ac93c8071818 Mon Sep 17 00:00:00 2001
+From: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Date: Thu, 26 Aug 2021 10:21:07 +0200
+Subject: mmc: renesas_sdhi: fix regression with hard reset on old SDHIs
+
+From: Wolfram Sang <wsa+renesas@sang-engineering.com>
+
+commit b81bede4d138ce62f7342e27bf55ac93c8071818 upstream.
+
+Old SDHI instances have a default value for the reset register which
+keeps it in reset state by default. So, when applying a hard reset we
+need to manually leave the soft reset state as well. Later SDHI
+instances have a different default value, the one we write manually now.
+
+Fixes: b4d86f37eacb ("mmc: renesas_sdhi: do hard reset if possible")
+Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210826082107.47299-1-wsa+renesas@sang-engineering.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/renesas_sdhi_core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/mmc/host/renesas_sdhi_core.c
++++ b/drivers/mmc/host/renesas_sdhi_core.c
+@@ -582,6 +582,8 @@ static void renesas_sdhi_reset(struct tm
+ /* Unknown why but without polling reset status, it will hang */
+ read_poll_timeout(reset_control_status, ret, ret == 0, 1, 100,
+ false, priv->rstc);
++ /* At least SDHI_VER_GEN2_SDR50 needs manual release of reset */
++ sd_ctrl_write16(host, CTL_RESET_SD, 0x0001);
+ priv->needs_adjust_hs400 = false;
+ renesas_sdhi_set_clock(host, host->clk_cache);
+ } else if (priv->scc_ctl) {
--- /dev/null
+From 41e76c6a3c83c85e849f10754b8632ea763d9be4 Mon Sep 17 00:00:00 2001
+From: Nick Desaulniers <ndesaulniers@google.com>
+Date: Mon, 20 Sep 2021 16:25:33 -0700
+Subject: nbd: use shifts rather than multiplies
+
+From: Nick Desaulniers <ndesaulniers@google.com>
+
+commit 41e76c6a3c83c85e849f10754b8632ea763d9be4 upstream.
+
+commit fad7cd3310db ("nbd: add the check to prevent overflow in
+__nbd_ioctl()") raised an issue from the fallback helpers added in
+commit f0907827a8a9 ("compiler.h: enable builtin overflow checkers and
+add fallback code")
+
+ERROR: modpost: "__divdi3" [drivers/block/nbd.ko] undefined!
+
+As Stephen Rothwell notes:
+ The added check_mul_overflow() call is being passed 64 bit values.
+ COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW is not set for this build (see
+ include/linux/overflow.h).
+
+Specifically, the helpers for checking whether the results of a
+multiplication overflowed (__unsigned_mul_overflow,
+__signed_add_overflow) use the division operator when
+!COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW. This is problematic for 64b
+operands on 32b hosts.
+
+This was fixed upstream by
+commit 76ae847497bc ("Documentation: raise minimum supported version of
+GCC to 5.1")
+which is not suitable to be backported to stable.
+
+Further, __builtin_mul_overflow() would emit a libcall to a
+compiler-rt-only symbol when compiling with clang < 14 for 32b targets.
+
+ld.lld: error: undefined symbol: __mulodi4
+
+In order to keep stable buildable with GCC 4.9 and clang < 14, modify
+struct nbd_config to instead track the number of bits of the block size;
+reconstructing the block size using runtime checked shifts that are not
+problematic for those compilers and in a ways that can be backported to
+stable.
+
+In nbd_set_size, we do validate that the value of blksize must be a
+power of two (POT) and is in the range of [512, PAGE_SIZE] (both
+inclusive).
+
+This does modify the debugfs interface.
+
+Cc: stable@vger.kernel.org
+Cc: Arnd Bergmann <arnd@kernel.org>
+Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
+Link: https://github.com/ClangBuiltLinux/linux/issues/1438
+Link: https://lore.kernel.org/all/20210909182525.372ee687@canb.auug.org.au/
+Link: https://lore.kernel.org/stable/CAHk-=whiQBofgis_rkniz8GBP9wZtSZdcDEffgSLO62BUGV3gg@mail.gmail.com/
+Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
+Reported-by: Nathan Chancellor <nathan@kernel.org>
+Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
+Suggested-by: Kees Cook <keescook@chromium.org>
+Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
+Suggested-by: Pavel Machek <pavel@ucw.cz>
+Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Link: https://lore.kernel.org/r/20210920232533.4092046-1-ndesaulniers@google.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/block/nbd.c | 29 +++++++++++++++++------------
+ 1 file changed, 17 insertions(+), 12 deletions(-)
+
+--- a/drivers/block/nbd.c
++++ b/drivers/block/nbd.c
+@@ -97,13 +97,18 @@ struct nbd_config {
+
+ atomic_t recv_threads;
+ wait_queue_head_t recv_wq;
+- loff_t blksize;
++ unsigned int blksize_bits;
+ loff_t bytesize;
+ #if IS_ENABLED(CONFIG_DEBUG_FS)
+ struct dentry *dbg_dir;
+ #endif
+ };
+
++static inline unsigned int nbd_blksize(struct nbd_config *config)
++{
++ return 1u << config->blksize_bits;
++}
++
+ struct nbd_device {
+ struct blk_mq_tag_set tag_set;
+
+@@ -147,7 +152,7 @@ static struct dentry *nbd_dbg_dir;
+
+ #define NBD_MAGIC 0x68797548
+
+-#define NBD_DEF_BLKSIZE 1024
++#define NBD_DEF_BLKSIZE_BITS 10
+
+ static unsigned int nbds_max = 16;
+ static int max_part = 16;
+@@ -350,12 +355,12 @@ static int nbd_set_size(struct nbd_devic
+ loff_t blksize)
+ {
+ if (!blksize)
+- blksize = NBD_DEF_BLKSIZE;
++ blksize = 1u << NBD_DEF_BLKSIZE_BITS;
+ if (blksize < 512 || blksize > PAGE_SIZE || !is_power_of_2(blksize))
+ return -EINVAL;
+
+ nbd->config->bytesize = bytesize;
+- nbd->config->blksize = blksize;
++ nbd->config->blksize_bits = __ffs(blksize);
+
+ if (!nbd->task_recv)
+ return 0;
+@@ -1370,7 +1375,7 @@ static int nbd_start_device(struct nbd_d
+ args->index = i;
+ queue_work(nbd->recv_workq, &args->work);
+ }
+- return nbd_set_size(nbd, config->bytesize, config->blksize);
++ return nbd_set_size(nbd, config->bytesize, nbd_blksize(config));
+ }
+
+ static int nbd_start_device_ioctl(struct nbd_device *nbd, struct block_device *bdev)
+@@ -1439,11 +1444,11 @@ static int __nbd_ioctl(struct block_devi
+ case NBD_SET_BLKSIZE:
+ return nbd_set_size(nbd, config->bytesize, arg);
+ case NBD_SET_SIZE:
+- return nbd_set_size(nbd, arg, config->blksize);
++ return nbd_set_size(nbd, arg, nbd_blksize(config));
+ case NBD_SET_SIZE_BLOCKS:
+- if (check_mul_overflow((loff_t)arg, config->blksize, &bytesize))
++ if (check_shl_overflow(arg, config->blksize_bits, &bytesize))
+ return -EINVAL;
+- return nbd_set_size(nbd, bytesize, config->blksize);
++ return nbd_set_size(nbd, bytesize, nbd_blksize(config));
+ case NBD_SET_TIMEOUT:
+ nbd_set_cmd_timeout(nbd, arg);
+ return 0;
+@@ -1509,7 +1514,7 @@ static struct nbd_config *nbd_alloc_conf
+ atomic_set(&config->recv_threads, 0);
+ init_waitqueue_head(&config->recv_wq);
+ init_waitqueue_head(&config->conn_wait);
+- config->blksize = NBD_DEF_BLKSIZE;
++ config->blksize_bits = NBD_DEF_BLKSIZE_BITS;
+ atomic_set(&config->live_connections, 0);
+ try_module_get(THIS_MODULE);
+ return config;
+@@ -1637,7 +1642,7 @@ static int nbd_dev_dbg_init(struct nbd_d
+ debugfs_create_file("tasks", 0444, dir, nbd, &nbd_dbg_tasks_fops);
+ debugfs_create_u64("size_bytes", 0444, dir, &config->bytesize);
+ debugfs_create_u32("timeout", 0444, dir, &nbd->tag_set.timeout);
+- debugfs_create_u64("blocksize", 0444, dir, &config->blksize);
++ debugfs_create_u32("blocksize_bits", 0444, dir, &config->blksize_bits);
+ debugfs_create_file("flags", 0444, dir, nbd, &nbd_dbg_flags_fops);
+
+ return 0;
+@@ -1841,7 +1846,7 @@ nbd_device_policy[NBD_DEVICE_ATTR_MAX +
+ static int nbd_genl_size_set(struct genl_info *info, struct nbd_device *nbd)
+ {
+ struct nbd_config *config = nbd->config;
+- u64 bsize = config->blksize;
++ u64 bsize = nbd_blksize(config);
+ u64 bytes = config->bytesize;
+
+ if (info->attrs[NBD_ATTR_SIZE_BYTES])
+@@ -1850,7 +1855,7 @@ static int nbd_genl_size_set(struct genl
+ if (info->attrs[NBD_ATTR_BLOCK_SIZE_BYTES])
+ bsize = nla_get_u64(info->attrs[NBD_ATTR_BLOCK_SIZE_BYTES]);
+
+- if (bytes != config->bytesize || bsize != config->blksize)
++ if (bytes != config->bytesize || bsize != nbd_blksize(config))
+ return nbd_set_size(nbd, bytes, bsize);
+ return 0;
+ }
--- /dev/null
+From b201cb0ebe87b209e252d85668e517ac1929e250 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Jos=C3=A9=20Exp=C3=B3sito?= <jose.exposito89@gmail.com>
+Date: Mon, 20 Sep 2021 18:03:12 +0200
+Subject: platform/x86/intel: hid: Add DMI switches allow list
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: José Expósito <jose.exposito89@gmail.com>
+
+commit b201cb0ebe87b209e252d85668e517ac1929e250 upstream.
+
+Some devices, even non convertible ones, can send incorrect
+SW_TABLET_MODE reports.
+
+Add an allow list and accept such reports only from devices in it.
+
+Bug reported for Dell XPS 17 9710 on:
+https://gitlab.freedesktop.org/libinput/libinput/-/issues/662
+
+Reported-by: Tobias Gurtzick <magic@wizardtales.com>
+Suggested-by: Hans de Goede <hdegoede@redhat.com>
+Tested-by: Tobias Gurtzick <magic@wizardtales.com>
+Signed-off-by: José Expósito <jose.exposito89@gmail.com>
+Link: https://lore.kernel.org/r/20210920160312.9787-1-jose.exposito89@gmail.com
+[hdegoede@redhat.com: Check dmi_switches_auto_add_allow_list only once]
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/intel-hid.c | 27 ++++++++++++++++++++++-----
+ 1 file changed, 22 insertions(+), 5 deletions(-)
+
+--- a/drivers/platform/x86/intel-hid.c
++++ b/drivers/platform/x86/intel-hid.c
+@@ -118,12 +118,30 @@ static const struct dmi_system_id dmi_vg
+ { }
+ };
+
++/*
++ * Some devices, even non convertible ones, can send incorrect SW_TABLET_MODE
++ * reports. Accept such reports only from devices in this list.
++ */
++static const struct dmi_system_id dmi_auto_add_switch[] = {
++ {
++ .matches = {
++ DMI_EXACT_MATCH(DMI_CHASSIS_TYPE, "31" /* Convertible */),
++ },
++ },
++ {
++ .matches = {
++ DMI_EXACT_MATCH(DMI_CHASSIS_TYPE, "32" /* Detachable */),
++ },
++ },
++ {} /* Array terminator */
++};
++
+ struct intel_hid_priv {
+ struct input_dev *input_dev;
+ struct input_dev *array;
+ struct input_dev *switches;
+ bool wakeup_mode;
+- bool dual_accel;
++ bool auto_add_switch;
+ };
+
+ #define HID_EVENT_FILTER_UUID "eeec56b3-4442-408f-a792-4edd4d758054"
+@@ -452,10 +470,8 @@ static void notify_handler(acpi_handle h
+ * Some convertible have unreliable VGBS return which could cause incorrect
+ * SW_TABLET_MODE report, in these cases we enable support when receiving
+ * the first event instead of during driver setup.
+- *
+- * See dual_accel_detect.h for more info on the dual_accel check.
+ */
+- if (!priv->switches && !priv->dual_accel && (event == 0xcc || event == 0xcd)) {
++ if (!priv->switches && priv->auto_add_switch && (event == 0xcc || event == 0xcd)) {
+ dev_info(&device->dev, "switch event received, enable switches supports\n");
+ err = intel_hid_switches_setup(device);
+ if (err)
+@@ -596,7 +612,8 @@ static int intel_hid_probe(struct platfo
+ return -ENOMEM;
+ dev_set_drvdata(&device->dev, priv);
+
+- priv->dual_accel = dual_accel_detect();
++ /* See dual_accel_detect.h for more info on the dual_accel check. */
++ priv->auto_add_switch = dmi_check_system(dmi_auto_add_switch) && !dual_accel_detect();
+
+ err = intel_hid_input_setup(device);
+ if (err) {
--- /dev/null
+From 773e89ab0056aaa2baa1ffd9f044551654410104 Mon Sep 17 00:00:00 2001
+From: Zelin Deng <zelin.deng@linux.alibaba.com>
+Date: Wed, 29 Sep 2021 13:13:49 +0800
+Subject: ptp: Fix ptp_kvm_getcrosststamp issue for x86 ptp_kvm
+
+From: Zelin Deng <zelin.deng@linux.alibaba.com>
+
+commit 773e89ab0056aaa2baa1ffd9f044551654410104 upstream.
+
+hv_clock is preallocated to have only HVC_BOOT_ARRAY_SIZE (64) elements;
+if the PTP_SYS_OFFSET_PRECISE ioctl is executed on vCPUs whose index is
+64 of higher, retrieving the struct pvclock_vcpu_time_info pointer with
+"src = &hv_clock[cpu].pvti" will result in an out-of-bounds access and
+a wild pointer. Change it to "this_cpu_pvti()" which is guaranteed to
+be valid.
+
+Fixes: 95a3d4454bb1 ("Switch kvmclock data to a PER_CPU variable")
+Signed-off-by: Zelin Deng <zelin.deng@linux.alibaba.com>
+Cc: <stable@vger.kernel.org>
+Message-Id: <1632892429-101194-3-git-send-email-zelin.deng@linux.alibaba.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ptp/ptp_kvm_x86.c | 9 ++-------
+ 1 file changed, 2 insertions(+), 7 deletions(-)
+
+--- a/drivers/ptp/ptp_kvm_x86.c
++++ b/drivers/ptp/ptp_kvm_x86.c
+@@ -15,8 +15,6 @@
+ #include <linux/ptp_clock_kernel.h>
+ #include <linux/ptp_kvm.h>
+
+-struct pvclock_vsyscall_time_info *hv_clock;
+-
+ static phys_addr_t clock_pair_gpa;
+ static struct kvm_clock_pairing clock_pair;
+
+@@ -28,8 +26,7 @@ int kvm_arch_ptp_init(void)
+ return -ENODEV;
+
+ clock_pair_gpa = slow_virt_to_phys(&clock_pair);
+- hv_clock = pvclock_get_pvti_cpu0_va();
+- if (!hv_clock)
++ if (!pvclock_get_pvti_cpu0_va())
+ return -ENODEV;
+
+ ret = kvm_hypercall2(KVM_HC_CLOCK_PAIRING, clock_pair_gpa,
+@@ -64,10 +61,8 @@ int kvm_arch_ptp_get_crosststamp(u64 *cy
+ struct pvclock_vcpu_time_info *src;
+ unsigned int version;
+ long ret;
+- int cpu;
+
+- cpu = smp_processor_id();
+- src = &hv_clock[cpu].pvti;
++ src = this_cpu_pvti();
+
+ do {
+ /*
--- /dev/null
+From bc0bdc5afaa740d782fbf936aaeebd65e5c2921d Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Wed, 15 Sep 2021 17:21:43 -0300
+Subject: RDMA/cma: Do not change route.addr.src_addr.ss_family
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit bc0bdc5afaa740d782fbf936aaeebd65e5c2921d upstream.
+
+If the state is not idle then rdma_bind_addr() will immediately fail and
+no change to global state should happen.
+
+For instance if the state is already RDMA_CM_LISTEN then this will corrupt
+the src_addr and would cause the test in cma_cancel_operation():
+
+ if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev)
+
+To view a mangled src_addr, eg with a IPv6 loopback address but an IPv4
+family, failing the test.
+
+This would manifest as this trace from syzkaller:
+
+ BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26
+ Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204
+
+ CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0
+ Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+ Call Trace:
+ __dump_stack lib/dump_stack.c:79 [inline]
+ dump_stack+0x141/0x1d7 lib/dump_stack.c:120
+ print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232
+ __kasan_report mm/kasan/report.c:399 [inline]
+ kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416
+ __list_add_valid+0x93/0xa0 lib/list_debug.c:26
+ __list_add include/linux/list.h:67 [inline]
+ list_add_tail include/linux/list.h:100 [inline]
+ cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline]
+ rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751
+ ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102
+ ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732
+ vfs_write+0x28e/0xa30 fs/read_write.c:603
+ ksys_write+0x1ee/0x250 fs/read_write.c:658
+ do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+Which is indicating that an rdma_id_private was destroyed without doing
+cma_cancel_listens().
+
+Instead of trying to re-use the src_addr memory to indirectly create an
+any address build one explicitly on the stack and bind to that as any
+other normal flow would do.
+
+Link: https://lore.kernel.org/r/0-v1-9fbb33f5e201+2a-cma_listen_jgg@nvidia.com
+Cc: stable@vger.kernel.org
+Fixes: 732d41c545bb ("RDMA/cma: Make the locking for automatic state transition more clear")
+Reported-by: syzbot+6bb0528b13611047209c@syzkaller.appspotmail.com
+Tested-by: Hao Sun <sunhao.th@gmail.com>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/core/cma.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/infiniband/core/cma.c
++++ b/drivers/infiniband/core/cma.c
+@@ -3768,9 +3768,13 @@ int rdma_listen(struct rdma_cm_id *id, i
+ int ret;
+
+ if (!cma_comp_exch(id_priv, RDMA_CM_ADDR_BOUND, RDMA_CM_LISTEN)) {
++ struct sockaddr_in any_in = {
++ .sin_family = AF_INET,
++ .sin_addr.s_addr = htonl(INADDR_ANY),
++ };
++
+ /* For a well behaved ULP state will be RDMA_CM_IDLE */
+- id->route.addr.src_addr.ss_family = AF_INET;
+- ret = rdma_bind_addr(id, cma_src_addr(id_priv));
++ ret = rdma_bind_addr(id, (struct sockaddr *)&any_in);
+ if (ret)
+ return ret;
+ if (WARN_ON(!cma_comp_exch(id_priv, RDMA_CM_ADDR_BOUND,
--- /dev/null
+From 305d568b72f17f674155a2a8275f865f207b3808 Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Thu, 16 Sep 2021 15:34:46 -0300
+Subject: RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit 305d568b72f17f674155a2a8275f865f207b3808 upstream.
+
+The FSM can run in a circle allowing rdma_resolve_ip() to be called twice
+on the same id_priv. While this cannot happen without going through the
+work, it violates the invariant that the same address resolution
+background request cannot be active twice.
+
+ CPU 1 CPU 2
+
+rdma_resolve_addr():
+ RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY
+ rdma_resolve_ip(addr_handler) #1
+
+ process_one_req(): for #1
+ addr_handler():
+ RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND
+ mutex_unlock(&id_priv->handler_mutex);
+ [.. handler still running ..]
+
+rdma_resolve_addr():
+ RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY
+ rdma_resolve_ip(addr_handler)
+ !! two requests are now on the req_list
+
+rdma_destroy_id():
+ destroy_id_handler_unlock():
+ _destroy_id():
+ cma_cancel_operation():
+ rdma_addr_cancel()
+
+ // process_one_req() self removes it
+ spin_lock_bh(&lock);
+ cancel_delayed_work(&req->work);
+ if (!list_empty(&req->list)) == true
+
+ ! rdma_addr_cancel() returns after process_on_req #1 is done
+
+ kfree(id_priv)
+
+ process_one_req(): for #2
+ addr_handler():
+ mutex_lock(&id_priv->handler_mutex);
+ !! Use after free on id_priv
+
+rdma_addr_cancel() expects there to be one req on the list and only
+cancels the first one. The self-removal behavior of the work only happens
+after the handler has returned. This yields a situations where the
+req_list can have two reqs for the same "handle" but rdma_addr_cancel()
+only cancels the first one.
+
+The second req remains active beyond rdma_destroy_id() and will
+use-after-free id_priv once it inevitably triggers.
+
+Fix this by remembering if the id_priv has called rdma_resolve_ip() and
+always cancel before calling it again. This ensures the req_list never
+gets more than one item in it and doesn't cost anything in the normal flow
+that never uses this strange error path.
+
+Link: https://lore.kernel.org/r/0-v1-3bc675b8006d+22-syz_cancel_uaf_jgg@nvidia.com
+Cc: stable@vger.kernel.org
+Fixes: e51060f08a61 ("IB: IP address based RDMA connection manager")
+Reported-by: syzbot+dc3dfba010d7671e05f5@syzkaller.appspotmail.com
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/core/cma.c | 23 +++++++++++++++++++++++
+ drivers/infiniband/core/cma_priv.h | 1 +
+ 2 files changed, 24 insertions(+)
+
+--- a/drivers/infiniband/core/cma.c
++++ b/drivers/infiniband/core/cma.c
+@@ -1776,6 +1776,14 @@ static void cma_cancel_operation(struct
+ {
+ switch (state) {
+ case RDMA_CM_ADDR_QUERY:
++ /*
++ * We can avoid doing the rdma_addr_cancel() based on state,
++ * only RDMA_CM_ADDR_QUERY has a work that could still execute.
++ * Notice that the addr_handler work could still be exiting
++ * outside this state, however due to the interaction with the
++ * handler_mutex the work is guaranteed not to touch id_priv
++ * during exit.
++ */
+ rdma_addr_cancel(&id_priv->id.route.addr.dev_addr);
+ break;
+ case RDMA_CM_ROUTE_QUERY:
+@@ -3410,6 +3418,21 @@ int rdma_resolve_addr(struct rdma_cm_id
+ if (dst_addr->sa_family == AF_IB) {
+ ret = cma_resolve_ib_addr(id_priv);
+ } else {
++ /*
++ * The FSM can return back to RDMA_CM_ADDR_BOUND after
++ * rdma_resolve_ip() is called, eg through the error
++ * path in addr_handler(). If this happens the existing
++ * request must be canceled before issuing a new one.
++ * Since canceling a request is a bit slow and this
++ * oddball path is rare, keep track once a request has
++ * been issued. The track turns out to be a permanent
++ * state since this is the only cancel as it is
++ * immediately before rdma_resolve_ip().
++ */
++ if (id_priv->used_resolve_ip)
++ rdma_addr_cancel(&id->route.addr.dev_addr);
++ else
++ id_priv->used_resolve_ip = 1;
+ ret = rdma_resolve_ip(cma_src_addr(id_priv), dst_addr,
+ &id->route.addr.dev_addr,
+ timeout_ms, addr_handler,
+--- a/drivers/infiniband/core/cma_priv.h
++++ b/drivers/infiniband/core/cma_priv.h
+@@ -91,6 +91,7 @@ struct rdma_id_private {
+ u8 afonly;
+ u8 timeout;
+ u8 min_rnr_timer;
++ u8 used_resolve_ip;
+ enum ib_gid_type gid_type;
+
+ /*
gpio-pca953x-do-not-ignore-i2c-errors.patch
scsi-ufs-fix-illegal-offset-in-upiu-event-trace.patch
mac80211-fix-use-after-free-in-ccmp-gcmp-rx.patch
+platform-x86-intel-hid-add-dmi-switches-allow-list.patch
+x86-kvmclock-move-this_cpu_pvti-into-kvmclock.h.patch
+ptp-fix-ptp_kvm_getcrosststamp-issue-for-x86-ptp_kvm.patch
+kvm-x86-fix-stack-out-of-bounds-memory-access-from-ioapic_write_indirect.patch
+kvm-x86-nsvm-don-t-copy-virt_ext-from-vmcb12.patch
+kvm-x86-clear-kvm-s-cached-guest-cr3-at-reset-init.patch
+kvm-x86-swap-order-of-cpuid-entry-index-vs.-significant-flag-checks.patch
+kvm-nvmx-filter-out-all-unsupported-controls-when-evmcs-was-activated.patch
+kvm-sev-update-svm_vm_copy_asid_from-for-sev-es.patch
+kvm-sev-pin-guest-memory-for-write-for-receive_update_data.patch
+kvm-sev-acquire-vcpu-mutex-when-updating-vmsa.patch
+kvm-sev-allow-some-commands-for-mirror-vm.patch
+kvm-svm-fix-missing-sev_decommission-in-sev_receive_start.patch
+kvm-nvmx-fix-nested-bus-lock-vm-exit.patch
+kvm-vmx-fix-a-tsx_ctrl_cpuid_clear-field-mask-issue.patch
+mmc-renesas_sdhi-fix-regression-with-hard-reset-on-old-sdhis.patch
+media-ir_toy-prevent-device-from-hanging-during-transmit.patch
+rdma-cma-do-not-change-route.addr.src_addr.ss_family.patch
+rdma-cma-ensure-rdma_addr_cancel-happens-before-issuing-more-requests.patch
+nbd-use-shifts-rather-than-multiplies.patch
+drm-amd-display-initialize-backlight_ramping_override-to-false.patch
+drm-amd-display-pass-pci-deviceid-into-dc.patch
+drm-amd-display-fix-display-flicker-on-embedded-panels.patch
+drm-amdgpu-force-exit-gfxoff-on-sdma-resume-for-rmb-s0ix.patch
+drm-amdgpu-check-tiling-flags-when-creating-fb-on-gfx8.patch
+drm-amdgpu-correct-initial-cp_hqd_quantum-for-gfx9.patch
--- /dev/null
+From ad9af930680bb396c87582edc172b3a7cf2a3fbf Mon Sep 17 00:00:00 2001
+From: Zelin Deng <zelin.deng@linux.alibaba.com>
+Date: Wed, 29 Sep 2021 13:13:48 +0800
+Subject: x86/kvmclock: Move this_cpu_pvti into kvmclock.h
+
+From: Zelin Deng <zelin.deng@linux.alibaba.com>
+
+commit ad9af930680bb396c87582edc172b3a7cf2a3fbf upstream.
+
+There're other modules might use hv_clock_per_cpu variable like ptp_kvm,
+so move it into kvmclock.h and export the symbol to make it visiable to
+other modules.
+
+Signed-off-by: Zelin Deng <zelin.deng@linux.alibaba.com>
+Cc: <stable@vger.kernel.org>
+Message-Id: <1632892429-101194-2-git-send-email-zelin.deng@linux.alibaba.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/include/asm/kvmclock.h | 14 ++++++++++++++
+ arch/x86/kernel/kvmclock.c | 13 ++-----------
+ 2 files changed, 16 insertions(+), 11 deletions(-)
+
+--- a/arch/x86/include/asm/kvmclock.h
++++ b/arch/x86/include/asm/kvmclock.h
+@@ -2,6 +2,20 @@
+ #ifndef _ASM_X86_KVM_CLOCK_H
+ #define _ASM_X86_KVM_CLOCK_H
+
++#include <linux/percpu.h>
++
+ extern struct clocksource kvm_clock;
+
++DECLARE_PER_CPU(struct pvclock_vsyscall_time_info *, hv_clock_per_cpu);
++
++static inline struct pvclock_vcpu_time_info *this_cpu_pvti(void)
++{
++ return &this_cpu_read(hv_clock_per_cpu)->pvti;
++}
++
++static inline struct pvclock_vsyscall_time_info *this_cpu_hvclock(void)
++{
++ return this_cpu_read(hv_clock_per_cpu);
++}
++
+ #endif /* _ASM_X86_KVM_CLOCK_H */
+--- a/arch/x86/kernel/kvmclock.c
++++ b/arch/x86/kernel/kvmclock.c
+@@ -49,18 +49,9 @@ early_param("no-kvmclock-vsyscall", pars
+ static struct pvclock_vsyscall_time_info
+ hv_clock_boot[HVC_BOOT_ARRAY_SIZE] __bss_decrypted __aligned(PAGE_SIZE);
+ static struct pvclock_wall_clock wall_clock __bss_decrypted;
+-static DEFINE_PER_CPU(struct pvclock_vsyscall_time_info *, hv_clock_per_cpu);
+ static struct pvclock_vsyscall_time_info *hvclock_mem;
+-
+-static inline struct pvclock_vcpu_time_info *this_cpu_pvti(void)
+-{
+- return &this_cpu_read(hv_clock_per_cpu)->pvti;
+-}
+-
+-static inline struct pvclock_vsyscall_time_info *this_cpu_hvclock(void)
+-{
+- return this_cpu_read(hv_clock_per_cpu);
+-}
++DEFINE_PER_CPU(struct pvclock_vsyscall_time_info *, hv_clock_per_cpu);
++EXPORT_PER_CPU_SYMBOL_GPL(hv_clock_per_cpu);
+
+ /*
+ * The wallclock is the time of day when we booted. Since then, some time may
projects / thirdparty / kernel / stable-queue.git / commitdiff
