From: Greg Kroah-Hartman Date: Fri, 18 Feb 2022 09:17:58 +0000 (+0100) Subject: 5.15-stable patches X-Git-Tag: v4.9.303~73 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=a41bb464eb6bac33f82ae47f49f99538a65a61d8;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: drm-amd-pm-correct-the-sequence-of-sending-gpu-reset-msg.patch drm-amdgpu-skipping-sdma-hw_init-and-hw_fini-for-s0ix.patch drm-atomic-don-t-pollute-crtc_state-mode_blob-with-error-pointers.patch drm-i915-fix-dbuf-slice-config-lookup.patch drm-i915-fix-mbus-join-config-lookup.patch drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch drm-radeon-fix-backlight-control-on-imac-12-1.patch iwlwifi-fix-use-after-free.patch kvm-x86-nsvm-fix-potential-null-derefernce-on-nested-migration.patch kvm-x86-nsvm-mark-vmcb01-as-dirty-when-restoring-smm-saved-state.patch kvm-x86-nsvm-nvmx-set-nested_run_pending-on-vm-entry-which-is-a-result-of-rsm.patch kvm-x86-svm-don-t-passthrough-smap-smep-pke-bits-in-npt-gcr0.pg-case.patch kvm-x86-xen-fix-runstate-updates-to-be-atomic-when-preempting-vcpu.patch --- diff --git a/queue-5.15/drm-amd-pm-correct-the-sequence-of-sending-gpu-reset-msg.patch b/queue-5.15/drm-amd-pm-correct-the-sequence-of-sending-gpu-reset-msg.patch new file mode 100644 index 00000000000..64aa316cd88 --- /dev/null +++ b/queue-5.15/drm-amd-pm-correct-the-sequence-of-sending-gpu-reset-msg.patch @@ -0,0 +1,41 @@ +From 9c4f59ea3f865693150edf0c91d1cc6b451360dd Mon Sep 17 00:00:00 2001 +From: Yifan Zhang +Date: Fri, 11 Feb 2022 17:58:08 +0800 +Subject: drm/amd/pm: correct the sequence of sending gpu reset msg + +From: Yifan Zhang + +commit 9c4f59ea3f865693150edf0c91d1cc6b451360dd upstream. + +the 2nd parameter should be smu msg type rather than asic msg index. + +Fixes: 7d38d9dc4ecc ("drm/amdgpu: add mode2 reset support for yellow carp") +Signed-off-by: Yifan Zhang +Acked-by: Aaron Liu +Reviewed-by: Huang Rui +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c | 9 ++------- + 1 file changed, 2 insertions(+), 7 deletions(-) + +--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c ++++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c +@@ -291,14 +291,9 @@ static int yellow_carp_post_smu_init(str + + static int yellow_carp_mode_reset(struct smu_context *smu, int type) + { +- int ret = 0, index = 0; ++ int ret = 0; + +- index = smu_cmn_to_asic_specific_index(smu, CMN2ASIC_MAPPING_MSG, +- SMU_MSG_GfxDeviceDriverReset); +- if (index < 0) +- return index == -EACCES ? 0 : index; +- +- ret = smu_cmn_send_smc_msg_with_param(smu, (uint16_t)index, type, NULL); ++ ret = smu_cmn_send_smc_msg_with_param(smu, SMU_MSG_GfxDeviceDriverReset, type, NULL); + if (ret) + dev_err(smu->adev->dev, "Failed to mode reset!\n"); + diff --git a/queue-5.15/drm-amdgpu-skipping-sdma-hw_init-and-hw_fini-for-s0ix.patch b/queue-5.15/drm-amdgpu-skipping-sdma-hw_init-and-hw_fini-for-s0ix.patch new file mode 100644 index 00000000000..78af078ca5e --- /dev/null +++ b/queue-5.15/drm-amdgpu-skipping-sdma-hw_init-and-hw_fini-for-s0ix.patch @@ -0,0 +1,55 @@ +From f8f4e2a518347063179def4e64580b2d28233d03 Mon Sep 17 00:00:00 2001 +From: Rajib Mahapatra +Date: Thu, 10 Feb 2022 18:46:40 +0530 +Subject: drm/amdgpu: skipping SDMA hw_init and hw_fini for S0ix. + +From: Rajib Mahapatra + +commit f8f4e2a518347063179def4e64580b2d28233d03 upstream. + +[Why] +SDMA ring buffer test failed if suspend is aborted during +S0i3 resume. + +[How] +If suspend is aborted for some reason during S0i3 resume +cycle, it follows SDMA ring test failing and errors in amdgpu +resume. For RN/CZN/Picasso, SMU saves and restores SDMA +registers during S0ix cycle. So, skipping SDMA suspend and +resume from driver solves the issue. This time, the system +is able to resume gracefully even the suspend is aborted. + +Reviewed-by: Mario Limonciello +Reviewed-by: Alex Deucher +Signed-off-by: Rajib Mahapatra +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c +@@ -2062,6 +2062,10 @@ static int sdma_v4_0_suspend(void *handl + { + struct amdgpu_device *adev = (struct amdgpu_device *)handle; + ++ /* SMU saves SDMA state for us */ ++ if (adev->in_s0ix) ++ return 0; ++ + return sdma_v4_0_hw_fini(adev); + } + +@@ -2069,6 +2073,10 @@ static int sdma_v4_0_resume(void *handle + { + struct amdgpu_device *adev = (struct amdgpu_device *)handle; + ++ /* SMU restores SDMA state for us */ ++ if (adev->in_s0ix) ++ return 0; ++ + return sdma_v4_0_hw_init(adev); + } + diff --git a/queue-5.15/drm-atomic-don-t-pollute-crtc_state-mode_blob-with-error-pointers.patch b/queue-5.15/drm-atomic-don-t-pollute-crtc_state-mode_blob-with-error-pointers.patch new file mode 100644 index 00000000000..19b190cbbea --- /dev/null +++ b/queue-5.15/drm-atomic-don-t-pollute-crtc_state-mode_blob-with-error-pointers.patch @@ -0,0 +1,52 @@ +From 439cf34c8e0a8a33d8c15a31be1b7423426bc765 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Wed, 9 Feb 2022 11:19:27 +0200 +Subject: drm/atomic: Don't pollute crtc_state->mode_blob with error pointers +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ville Syrjälä + +commit 439cf34c8e0a8a33d8c15a31be1b7423426bc765 upstream. + +Make sure we don't assign an error pointer to crtc_state->mode_blob +as that will break all kinds of places that assume either NULL or a +valid pointer (eg. drm_property_blob_put()). + +Cc: stable@vger.kernel.org +Reported-by: fuyufan +Signed-off-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/20220209091928.14766-1-ville.syrjala@linux.intel.com +Acked-by: Maxime Ripard +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_atomic_uapi.c | 14 ++++++++------ + 1 file changed, 8 insertions(+), 6 deletions(-) + +--- a/drivers/gpu/drm/drm_atomic_uapi.c ++++ b/drivers/gpu/drm/drm_atomic_uapi.c +@@ -76,15 +76,17 @@ int drm_atomic_set_mode_for_crtc(struct + state->mode_blob = NULL; + + if (mode) { ++ struct drm_property_blob *blob; ++ + drm_mode_convert_to_umode(&umode, mode); +- state->mode_blob = +- drm_property_create_blob(state->crtc->dev, +- sizeof(umode), +- &umode); +- if (IS_ERR(state->mode_blob)) +- return PTR_ERR(state->mode_blob); ++ blob = drm_property_create_blob(crtc->dev, ++ sizeof(umode), &umode); ++ if (IS_ERR(blob)) ++ return PTR_ERR(blob); + + drm_mode_copy(&state->mode, mode); ++ ++ state->mode_blob = blob; + state->enable = true; + drm_dbg_atomic(crtc->dev, + "Set [MODE:%s] for [CRTC:%d:%s] state %p\n", diff --git a/queue-5.15/drm-i915-fix-dbuf-slice-config-lookup.patch b/queue-5.15/drm-i915-fix-dbuf-slice-config-lookup.patch new file mode 100644 index 00000000000..5d80d35fe17 --- /dev/null +++ b/queue-5.15/drm-i915-fix-dbuf-slice-config-lookup.patch @@ -0,0 +1,46 @@ +From 698bef8ff5d2edea5d1c9d6e5adf1bfed1e8a106 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Mon, 7 Feb 2022 15:26:59 +0200 +Subject: drm/i915: Fix dbuf slice config lookup +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ville Syrjälä + +commit 698bef8ff5d2edea5d1c9d6e5adf1bfed1e8a106 upstream. + +Apparently I totally fumbled the loop condition when I +removed the ARRAY_SIZE() stuff from the dbuf slice config +lookup. Comparing the loop index with the active_pipes bitmask +is utter nonsense, what we want to do is check to see if the +mask is zero or not. + +Note that the code actually ended up working correctly despite +the fumble, up until commit eef173954432 ("drm/i915: Allow +!join_mbus cases for adlp+ dbuf configuration") when things +broke for real. + +Cc: stable@vger.kernel.org +Fixes: 05e8155afe35 ("drm/i915: Use a sentinel to terminate the dbuf slice arrays") +Signed-off-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/20220207132700.481-1-ville.syrjala@linux.intel.com +Reviewed-by: Jani Nikula +(cherry picked from commit a28fde308c3c1c174249ff9559b57f24e6850086) +Signed-off-by: Tvrtko Ursulin +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/intel_pm.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -4861,7 +4861,7 @@ static u8 compute_dbuf_slices(enum pipe + { + int i; + +- for (i = 0; i < dbuf_slices[i].active_pipes; i++) { ++ for (i = 0; dbuf_slices[i].active_pipes != 0; i++) { + if (dbuf_slices[i].active_pipes == active_pipes && + dbuf_slices[i].join_mbus == join_mbus) + return dbuf_slices[i].dbuf_mask[pipe]; diff --git a/queue-5.15/drm-i915-fix-mbus-join-config-lookup.patch b/queue-5.15/drm-i915-fix-mbus-join-config-lookup.patch new file mode 100644 index 00000000000..debe9d6aaed --- /dev/null +++ b/queue-5.15/drm-i915-fix-mbus-join-config-lookup.patch @@ -0,0 +1,39 @@ +From 8d9d2a723d64b650f2e6423024ccb4a33f0cdc40 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Mon, 7 Feb 2022 15:27:00 +0200 +Subject: drm/i915: Fix mbus join config lookup +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ville Syrjälä + +commit 8d9d2a723d64b650f2e6423024ccb4a33f0cdc40 upstream. + +The bogus loop from compute_dbuf_slices() was copied into +check_mbus_joined() as well. So this lookup is wrong as well. +Fix it. + +Cc: stable@vger.kernel.org +Fixes: f4dc00863226 ("drm/i915/adl_p: MBUS programming") +Signed-off-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/20220207132700.481-2-ville.syrjala@linux.intel.com +Reviewed-by: Jani Nikula +(cherry picked from commit 053f2b85631316a9226f6340c1c0fd95634f7a5b) +Signed-off-by: Tvrtko Ursulin +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/intel_pm.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -4844,7 +4844,7 @@ static bool check_mbus_joined(u8 active_ + { + int i; + +- for (i = 0; i < dbuf_slices[i].active_pipes; i++) { ++ for (i = 0; dbuf_slices[i].active_pipes != 0; i++) { + if (dbuf_slices[i].active_pipes == active_pipes) + return dbuf_slices[i].join_mbus; + } diff --git a/queue-5.15/drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch b/queue-5.15/drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch new file mode 100644 index 00000000000..b6d74c45790 --- /dev/null +++ b/queue-5.15/drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch @@ -0,0 +1,62 @@ +From ea958422291de248b9e2eaaeea36004e84b64043 Mon Sep 17 00:00:00 2001 +From: Jani Nikula +Date: Thu, 10 Feb 2022 12:36:42 +0200 +Subject: drm/i915/opregion: check port number bounds for SWSCI display power state +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jani Nikula + +commit ea958422291de248b9e2eaaeea36004e84b64043 upstream. + +The mapping from enum port to whatever port numbering scheme is used by +the SWSCI Display Power State Notification is odd, and the memory of it +has faded. In any case, the parameter only has space for ports numbered +[0..4], and UBSAN reports bit shift beyond it when the platform has port +F or more. + +Since the SWSCI functionality is supposed to be obsolete for new +platforms (i.e. ones that might have port F or more), just bail out +early if the mapped and mangled port number is beyond what the Display +Power State Notification can support. + +Fixes: 9c4b0a683193 ("drm/i915: add opregion function to notify bios of encoder enable/disable") +Cc: # v3.13+ +Cc: Ville Syrjälä +Cc: Lucas De Marchi +Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4800 +Signed-off-by: Jani Nikula +Reviewed-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/cc363f42d6b5a5932b6d218fefcc8bdfb15dbbe5.1644489329.git.jani.nikula@intel.com +(cherry picked from commit 24a644ebbfd3b13cda702f98907f9dd123e34bf9) +Signed-off-by: Tvrtko Ursulin +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/display/intel_opregion.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +--- a/drivers/gpu/drm/i915/display/intel_opregion.c ++++ b/drivers/gpu/drm/i915/display/intel_opregion.c +@@ -361,6 +361,21 @@ int intel_opregion_notify_encoder(struct + port++; + } + ++ /* ++ * The port numbering and mapping here is bizarre. The now-obsolete ++ * swsci spec supports ports numbered [0..4]. Port E is handled as a ++ * special case, but port F and beyond are not. The functionality is ++ * supposed to be obsolete for new platforms. Just bail out if the port ++ * number is out of bounds after mapping. ++ */ ++ if (port > 4) { ++ drm_dbg_kms(&dev_priv->drm, ++ "[ENCODER:%d:%s] port %c (index %u) out of bounds for display power state notification\n", ++ intel_encoder->base.base.id, intel_encoder->base.name, ++ port_name(intel_encoder->port), port); ++ return -EINVAL; ++ } ++ + if (!enable) + parm |= 4 << 8; + diff --git a/queue-5.15/drm-radeon-fix-backlight-control-on-imac-12-1.patch b/queue-5.15/drm-radeon-fix-backlight-control-on-imac-12-1.patch new file mode 100644 index 00000000000..dcf174876e1 --- /dev/null +++ b/queue-5.15/drm-radeon-fix-backlight-control-on-imac-12-1.patch @@ -0,0 +1,33 @@ +From 364438fd629f7611a84c8e6d7de91659300f1502 Mon Sep 17 00:00:00 2001 +From: Nicholas Bishop +Date: Fri, 11 Feb 2022 14:57:39 -0500 +Subject: drm/radeon: Fix backlight control on iMac 12,1 + +From: Nicholas Bishop + +commit 364438fd629f7611a84c8e6d7de91659300f1502 upstream. + +The iMac 12,1 does not use the gmux driver for backlight, so the radeon +backlight device is needed to set the brightness. + +Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1838 +Signed-off-by: Nicholas Bishop +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/radeon/atombios_encoders.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/radeon/atombios_encoders.c ++++ b/drivers/gpu/drm/radeon/atombios_encoders.c +@@ -198,7 +198,8 @@ void radeon_atom_backlight_init(struct r + * so don't register a backlight device + */ + if ((rdev->pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE) && +- (rdev->pdev->device == 0x6741)) ++ (rdev->pdev->device == 0x6741) && ++ !dmi_match(DMI_PRODUCT_NAME, "iMac12,1")) + return; + + if (!radeon_encoder->enc_priv) diff --git a/queue-5.15/iwlwifi-fix-use-after-free.patch b/queue-5.15/iwlwifi-fix-use-after-free.patch new file mode 100644 index 00000000000..0b400baeb9f --- /dev/null +++ b/queue-5.15/iwlwifi-fix-use-after-free.patch @@ -0,0 +1,48 @@ +From bea2662e7818e15d7607d17d57912ac984275d94 Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Tue, 8 Feb 2022 11:47:30 +0100 +Subject: iwlwifi: fix use-after-free +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Johannes Berg + +commit bea2662e7818e15d7607d17d57912ac984275d94 upstream. + +If no firmware was present at all (or, presumably, all of the +firmware files failed to parse), we end up unbinding by calling +device_release_driver(), which calls remove(), which then in +iwlwifi calls iwl_drv_stop(), freeing the 'drv' struct. However +the new code I added will still erroneously access it after it +was freed. + +Set 'failure=false' in this case to avoid the access, all data +was already freed anyway. + +Cc: stable@vger.kernel.org +Reported-by: Stefan Agner +Reported-by: Wolfgang Walter +Reported-by: Jason Self +Reported-by: Dominik Behr +Reported-by: Marek Marczykowski-Górecki +Fixes: ab07506b0454 ("iwlwifi: fix leaks/bad data after failed firmware load") +Signed-off-by: Johannes Berg +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220208114728.e6b514cf4c85.Iffb575ca2a623d7859b542c33b2a507d01554251@changeid +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c ++++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c +@@ -1614,6 +1614,8 @@ static void iwl_req_fw_callback(const st + out_unbind: + complete(&drv->request_firmware_complete); + device_release_driver(drv->trans->dev); ++ /* drv has just been freed by the release */ ++ failure = false; + free: + if (failure) + iwl_dealloc_ucode(drv); diff --git a/queue-5.15/kvm-x86-nsvm-fix-potential-null-derefernce-on-nested-migration.patch b/queue-5.15/kvm-x86-nsvm-fix-potential-null-derefernce-on-nested-migration.patch new file mode 100644 index 00000000000..a98c491c6ec --- /dev/null +++ b/queue-5.15/kvm-x86-nsvm-fix-potential-null-derefernce-on-nested-migration.patch @@ -0,0 +1,72 @@ +From e1779c2714c3023e4629825762bcbc43a3b943df Mon Sep 17 00:00:00 2001 +From: Maxim Levitsky +Date: Mon, 7 Feb 2022 17:54:19 +0200 +Subject: KVM: x86: nSVM: fix potential NULL derefernce on nested migration + +From: Maxim Levitsky + +commit e1779c2714c3023e4629825762bcbc43a3b943df upstream. + +Turns out that due to review feedback and/or rebases +I accidentally moved the call to nested_svm_load_cr3 to be too early, +before the NPT is enabled, which is very wrong to do. + +KVM can't even access guest memory at that point as nested NPT +is needed for that, and of course it won't initialize the walk_mmu, +which is main issue the patch was addressing. + +Fix this for real. + +Fixes: 232f75d3b4b5 ("KVM: nSVM: call nested_svm_load_cr3 on nested state load") +Cc: stable@vger.kernel.org + +Signed-off-by: Maxim Levitsky +Message-Id: <20220207155447.840194-3-mlevitsk@redhat.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/nested.c | 26 ++++++++++++++------------ + 1 file changed, 14 insertions(+), 12 deletions(-) + +--- a/arch/x86/kvm/svm/nested.c ++++ b/arch/x86/kvm/svm/nested.c +@@ -1357,18 +1357,6 @@ static int svm_set_nested_state(struct k + !nested_vmcb_valid_sregs(vcpu, save)) + goto out_free; + +- /* +- * While the nested guest CR3 is already checked and set by +- * KVM_SET_SREGS, it was set when nested state was yet loaded, +- * thus MMU might not be initialized correctly. +- * Set it again to fix this. +- */ +- +- ret = nested_svm_load_cr3(&svm->vcpu, vcpu->arch.cr3, +- nested_npt_enabled(svm), false); +- if (WARN_ON_ONCE(ret)) +- goto out_free; +- + + /* + * All checks done, we can enter guest mode. Userspace provides +@@ -1394,6 +1382,20 @@ static int svm_set_nested_state(struct k + + svm_switch_vmcb(svm, &svm->nested.vmcb02); + nested_vmcb02_prepare_control(svm); ++ ++ /* ++ * While the nested guest CR3 is already checked and set by ++ * KVM_SET_SREGS, it was set when nested state was yet loaded, ++ * thus MMU might not be initialized correctly. ++ * Set it again to fix this. ++ */ ++ ++ ret = nested_svm_load_cr3(&svm->vcpu, vcpu->arch.cr3, ++ nested_npt_enabled(svm), false); ++ if (WARN_ON_ONCE(ret)) ++ goto out_free; ++ ++ + kvm_make_request(KVM_REQ_GET_NESTED_STATE_PAGES, vcpu); + ret = 0; + out_free: diff --git a/queue-5.15/kvm-x86-nsvm-mark-vmcb01-as-dirty-when-restoring-smm-saved-state.patch b/queue-5.15/kvm-x86-nsvm-mark-vmcb01-as-dirty-when-restoring-smm-saved-state.patch new file mode 100644 index 00000000000..f71f4051400 --- /dev/null +++ b/queue-5.15/kvm-x86-nsvm-mark-vmcb01-as-dirty-when-restoring-smm-saved-state.patch @@ -0,0 +1,49 @@ +From e8efa4ff00374d2e6f47f6e4628ca3b541c001af Mon Sep 17 00:00:00 2001 +From: Maxim Levitsky +Date: Mon, 7 Feb 2022 17:54:20 +0200 +Subject: KVM: x86: nSVM: mark vmcb01 as dirty when restoring SMM saved state + +From: Maxim Levitsky + +commit e8efa4ff00374d2e6f47f6e4628ca3b541c001af upstream. + +While usually, restoring the smm state makes the KVM enter +the nested guest thus a different vmcb (vmcb02 vs vmcb01), +KVM should still mark it as dirty, since hardware +can in theory cache multiple vmcbs. + +Failure to do so, combined with lack of setting the +nested_run_pending (which is fixed in the next patch), +might make KVM re-enter vmcb01, which was just exited from, +with completely different set of guest state registers +(SMM vs non SMM) and without proper dirty bits set, +which results in the CPU reusing stale IDTR pointer +which leads to a guest shutdown on any interrupt. + +On the real hardware this usually doesn't happen, +but when running nested, L0's KVM does check and +honour few dirty bits, causing this issue to happen. + +This patch fixes boot of hyperv and SMM enabled +windows VM running nested on KVM. + +Signed-off-by: Maxim Levitsky +Cc: stable@vger.kernel.org +Message-Id: <20220207155447.840194-4-mlevitsk@redhat.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/svm.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/x86/kvm/svm/svm.c ++++ b/arch/x86/kvm/svm/svm.c +@@ -4392,6 +4392,8 @@ static int svm_leave_smm(struct kvm_vcpu + * Enter the nested guest now + */ + ++ vmcb_mark_all_dirty(svm->vmcb01.ptr); ++ + vmcb12 = map.hva; + nested_load_control_from_vmcb12(svm, &vmcb12->control); + ret = enter_svm_guest_mode(vcpu, vmcb12_gpa, vmcb12, false); diff --git a/queue-5.15/kvm-x86-nsvm-nvmx-set-nested_run_pending-on-vm-entry-which-is-a-result-of-rsm.patch b/queue-5.15/kvm-x86-nsvm-nvmx-set-nested_run_pending-on-vm-entry-which-is-a-result-of-rsm.patch new file mode 100644 index 00000000000..aedf9741849 --- /dev/null +++ b/queue-5.15/kvm-x86-nsvm-nvmx-set-nested_run_pending-on-vm-entry-which-is-a-result-of-rsm.patch @@ -0,0 +1,51 @@ +From 759cbd59674a6c0aec616a3f4f0740ebd3f5fbef Mon Sep 17 00:00:00 2001 +From: Maxim Levitsky +Date: Mon, 7 Feb 2022 17:54:21 +0200 +Subject: KVM: x86: nSVM/nVMX: set nested_run_pending on VM entry which is a result of RSM + +From: Maxim Levitsky + +commit 759cbd59674a6c0aec616a3f4f0740ebd3f5fbef upstream. + +While RSM induced VM entries are not full VM entries, +they still need to be followed by actual VM entry to complete it, +unlike setting the nested state. + +This patch fixes boot of hyperv and SMM enabled +windows VM running nested on KVM, which fail due +to this issue combined with lack of dirty bit setting. + +Signed-off-by: Maxim Levitsky +Cc: stable@vger.kernel.org +Message-Id: <20220207155447.840194-5-mlevitsk@redhat.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/svm.c | 5 +++++ + arch/x86/kvm/vmx/vmx.c | 1 + + 2 files changed, 6 insertions(+) + +--- a/arch/x86/kvm/svm/svm.c ++++ b/arch/x86/kvm/svm/svm.c +@@ -4388,6 +4388,11 @@ static int svm_leave_smm(struct kvm_vcpu + nested_load_control_from_vmcb12(svm, &vmcb12->control); + ret = enter_svm_guest_mode(vcpu, vmcb12_gpa, vmcb12, false); + ++ if (ret) ++ goto unmap_save; ++ ++ svm->nested.nested_run_pending = 1; ++ + unmap_save: + kvm_vcpu_unmap(vcpu, &map_save, true); + unmap_map: +--- a/arch/x86/kvm/vmx/vmx.c ++++ b/arch/x86/kvm/vmx/vmx.c +@@ -7532,6 +7532,7 @@ static int vmx_leave_smm(struct kvm_vcpu + if (ret) + return ret; + ++ vmx->nested.nested_run_pending = 1; + vmx->nested.smm.guest_mode = false; + } + return 0; diff --git a/queue-5.15/kvm-x86-svm-don-t-passthrough-smap-smep-pke-bits-in-npt-gcr0.pg-case.patch b/queue-5.15/kvm-x86-svm-don-t-passthrough-smap-smep-pke-bits-in-npt-gcr0.pg-case.patch new file mode 100644 index 00000000000..4f1a676bdd2 --- /dev/null +++ b/queue-5.15/kvm-x86-svm-don-t-passthrough-smap-smep-pke-bits-in-npt-gcr0.pg-case.patch @@ -0,0 +1,78 @@ +From c53bbe2145f51d3bc0438c2db02e737b9b598bf3 Mon Sep 17 00:00:00 2001 +From: Maxim Levitsky +Date: Mon, 7 Feb 2022 17:54:18 +0200 +Subject: KVM: x86: SVM: don't passthrough SMAP/SMEP/PKE bits in !NPT && !gCR0.PG case + +From: Maxim Levitsky + +commit c53bbe2145f51d3bc0438c2db02e737b9b598bf3 upstream. + +When the guest doesn't enable paging, and NPT/EPT is disabled, we +use guest't paging CR3's as KVM's shadow paging pointer and +we are technically in direct mode as if we were to use NPT/EPT. + +In direct mode we create SPTEs with user mode permissions +because usually in the direct mode the NPT/EPT doesn't +need to restrict access based on guest CPL +(there are MBE/GMET extenstions for that but KVM doesn't use them). + +In this special "use guest paging as direct" mode however, +and if CR4.SMAP/CR4.SMEP are enabled, that will make the CPU +fault on each access and KVM will enter endless loop of page faults. + +Since page protection doesn't have any meaning in !PG case, +just don't passthrough these bits. + +The fix is the same as was done for VMX in commit: +commit 656ec4a4928a ("KVM: VMX: fix SMEP and SMAP without EPT") + +This fixes the boot of windows 10 without NPT for good. +(Without this patch, BSP boots, but APs were stuck in endless +loop of page faults, causing the VM boot with 1 CPU) + +Signed-off-by: Maxim Levitsky +Cc: stable@vger.kernel.org +Message-Id: <20220207155447.840194-2-mlevitsk@redhat.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/svm.c | 12 ++++++++++-- + 1 file changed, 10 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/svm/svm.c ++++ b/arch/x86/kvm/svm/svm.c +@@ -1727,6 +1727,7 @@ void svm_set_cr0(struct kvm_vcpu *vcpu, + { + struct vcpu_svm *svm = to_svm(vcpu); + u64 hcr0 = cr0; ++ bool old_paging = is_paging(vcpu); + + #ifdef CONFIG_X86_64 + if (vcpu->arch.efer & EFER_LME && !vcpu->arch.guest_state_protected) { +@@ -1743,8 +1744,11 @@ void svm_set_cr0(struct kvm_vcpu *vcpu, + #endif + vcpu->arch.cr0 = cr0; + +- if (!npt_enabled) ++ if (!npt_enabled) { + hcr0 |= X86_CR0_PG | X86_CR0_WP; ++ if (old_paging != is_paging(vcpu)) ++ svm_set_cr4(vcpu, kvm_read_cr4(vcpu)); ++ } + + /* + * re-enable caching here because the QEMU bios +@@ -1788,8 +1792,12 @@ void svm_set_cr4(struct kvm_vcpu *vcpu, + svm_flush_tlb(vcpu); + + vcpu->arch.cr4 = cr4; +- if (!npt_enabled) ++ if (!npt_enabled) { + cr4 |= X86_CR4_PAE; ++ ++ if (!is_paging(vcpu)) ++ cr4 &= ~(X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_PKE); ++ } + cr4 |= host_cr4_mce; + to_svm(vcpu)->vmcb->save.cr4 = cr4; + vmcb_mark_dirty(to_svm(vcpu)->vmcb, VMCB_CR); diff --git a/queue-5.15/kvm-x86-xen-fix-runstate-updates-to-be-atomic-when-preempting-vcpu.patch b/queue-5.15/kvm-x86-xen-fix-runstate-updates-to-be-atomic-when-preempting-vcpu.patch new file mode 100644 index 00000000000..a72434e46a2 --- /dev/null +++ b/queue-5.15/kvm-x86-xen-fix-runstate-updates-to-be-atomic-when-preempting-vcpu.patch @@ -0,0 +1,214 @@ +From fcb732d8f8cf6084f8480015ad41d25fb023a4dd Mon Sep 17 00:00:00 2001 +From: David Woodhouse +Date: Mon, 25 Oct 2021 14:29:01 +0100 +Subject: KVM: x86/xen: Fix runstate updates to be atomic when preempting vCPU +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: David Woodhouse + +commit fcb732d8f8cf6084f8480015ad41d25fb023a4dd upstream. + +There are circumstances whem kvm_xen_update_runstate_guest() should not +sleep because it ends up being called from __schedule() when the vCPU +is preempted: + +[ 222.830825] kvm_xen_update_runstate_guest+0x24/0x100 +[ 222.830878] kvm_arch_vcpu_put+0x14c/0x200 +[ 222.830920] kvm_sched_out+0x30/0x40 +[ 222.830960] __schedule+0x55c/0x9f0 + +To handle this, make it use the same trick as __kvm_xen_has_interrupt(), +of using the hva from the gfn_to_hva_cache directly. Then it can use +pagefault_disable() around the accesses and just bail out if the page +is absent (which is unlikely). + +I almost switched to using a gfn_to_pfn_cache here and bailing out if +kvm_map_gfn() fails, like kvm_steal_time_set_preempted() does — but on +closer inspection it looks like kvm_map_gfn() will *always* fail in +atomic context for a page in IOMEM, which means it will silently fail +to make the update every single time for such guests, AFAICT. So I +didn't do it that way after all. And will probably fix that one too. + +Cc: stable@vger.kernel.org +Fixes: 30b5c851af79 ("KVM: x86/xen: Add support for vCPU runstate information") +Signed-off-by: David Woodhouse +Message-Id: +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/xen.c | 97 ++++++++++++++++++++++++++++++++++++----------------- + 1 file changed, 67 insertions(+), 30 deletions(-) + +--- a/arch/x86/kvm/xen.c ++++ b/arch/x86/kvm/xen.c +@@ -93,32 +93,57 @@ static void kvm_xen_update_runstate(stru + void kvm_xen_update_runstate_guest(struct kvm_vcpu *v, int state) + { + struct kvm_vcpu_xen *vx = &v->arch.xen; ++ struct gfn_to_hva_cache *ghc = &vx->runstate_cache; ++ struct kvm_memslots *slots = kvm_memslots(v->kvm); ++ bool atomic = (state == RUNSTATE_runnable); + uint64_t state_entry_time; +- unsigned int offset; ++ int __user *user_state; ++ uint64_t __user *user_times; + + kvm_xen_update_runstate(v, state); + + if (!vx->runstate_set) + return; + +- BUILD_BUG_ON(sizeof(struct compat_vcpu_runstate_info) != 0x2c); ++ if (unlikely(slots->generation != ghc->generation || kvm_is_error_hva(ghc->hva)) && ++ kvm_gfn_to_hva_cache_init(v->kvm, ghc, ghc->gpa, ghc->len)) ++ return; ++ ++ /* We made sure it fits in a single page */ ++ BUG_ON(!ghc->memslot); ++ ++ if (atomic) ++ pagefault_disable(); + +- offset = offsetof(struct compat_vcpu_runstate_info, state_entry_time); +-#ifdef CONFIG_X86_64 + /* +- * The only difference is alignment of uint64_t in 32-bit. +- * So the first field 'state' is accessed directly using +- * offsetof() (where its offset happens to be zero), while the +- * remaining fields which are all uint64_t, start at 'offset' +- * which we tweak here by adding 4. ++ * The only difference between 32-bit and 64-bit versions of the ++ * runstate struct us the alignment of uint64_t in 32-bit, which ++ * means that the 64-bit version has an additional 4 bytes of ++ * padding after the first field 'state'. ++ * ++ * So we use 'int __user *user_state' to point to the state field, ++ * and 'uint64_t __user *user_times' for runstate_entry_time. So ++ * the actual array of time[] in each state starts at user_times[1]. + */ ++ BUILD_BUG_ON(offsetof(struct vcpu_runstate_info, state) != 0); ++ BUILD_BUG_ON(offsetof(struct compat_vcpu_runstate_info, state) != 0); ++ user_state = (int __user *)ghc->hva; ++ ++ BUILD_BUG_ON(sizeof(struct compat_vcpu_runstate_info) != 0x2c); ++ ++ user_times = (uint64_t __user *)(ghc->hva + ++ offsetof(struct compat_vcpu_runstate_info, ++ state_entry_time)); ++#ifdef CONFIG_X86_64 + BUILD_BUG_ON(offsetof(struct vcpu_runstate_info, state_entry_time) != + offsetof(struct compat_vcpu_runstate_info, state_entry_time) + 4); + BUILD_BUG_ON(offsetof(struct vcpu_runstate_info, time) != + offsetof(struct compat_vcpu_runstate_info, time) + 4); + + if (v->kvm->arch.xen.long_mode) +- offset = offsetof(struct vcpu_runstate_info, state_entry_time); ++ user_times = (uint64_t __user *)(ghc->hva + ++ offsetof(struct vcpu_runstate_info, ++ state_entry_time)); + #endif + /* + * First write the updated state_entry_time at the appropriate +@@ -132,10 +157,8 @@ void kvm_xen_update_runstate_guest(struc + BUILD_BUG_ON(sizeof(((struct compat_vcpu_runstate_info *)0)->state_entry_time) != + sizeof(state_entry_time)); + +- if (kvm_write_guest_offset_cached(v->kvm, &v->arch.xen.runstate_cache, +- &state_entry_time, offset, +- sizeof(state_entry_time))) +- return; ++ if (__put_user(state_entry_time, user_times)) ++ goto out; + smp_wmb(); + + /* +@@ -149,11 +172,8 @@ void kvm_xen_update_runstate_guest(struc + BUILD_BUG_ON(sizeof(((struct compat_vcpu_runstate_info *)0)->state) != + sizeof(vx->current_runstate)); + +- if (kvm_write_guest_offset_cached(v->kvm, &v->arch.xen.runstate_cache, +- &vx->current_runstate, +- offsetof(struct vcpu_runstate_info, state), +- sizeof(vx->current_runstate))) +- return; ++ if (__put_user(vx->current_runstate, user_state)) ++ goto out; + + /* + * Write the actual runstate times immediately after the +@@ -168,24 +188,23 @@ void kvm_xen_update_runstate_guest(struc + BUILD_BUG_ON(sizeof(((struct vcpu_runstate_info *)0)->time) != + sizeof(vx->runstate_times)); + +- if (kvm_write_guest_offset_cached(v->kvm, &v->arch.xen.runstate_cache, +- &vx->runstate_times[0], +- offset + sizeof(u64), +- sizeof(vx->runstate_times))) +- return; +- ++ if (__copy_to_user(user_times + 1, vx->runstate_times, sizeof(vx->runstate_times))) ++ goto out; + smp_wmb(); + + /* + * Finally, clear the XEN_RUNSTATE_UPDATE bit in the guest's + * runstate_entry_time field. + */ +- + state_entry_time &= ~XEN_RUNSTATE_UPDATE; +- if (kvm_write_guest_offset_cached(v->kvm, &v->arch.xen.runstate_cache, +- &state_entry_time, offset, +- sizeof(state_entry_time))) +- return; ++ __put_user(state_entry_time, user_times); ++ smp_wmb(); ++ ++ out: ++ mark_page_dirty_in_slot(v->kvm, ghc->memslot, ghc->gpa >> PAGE_SHIFT); ++ ++ if (atomic) ++ pagefault_enable(); + } + + int __kvm_xen_has_interrupt(struct kvm_vcpu *v) +@@ -337,6 +356,12 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcp + break; + } + ++ /* It must fit within a single page */ ++ if ((data->u.gpa & ~PAGE_MASK) + sizeof(struct vcpu_info) > PAGE_SIZE) { ++ r = -EINVAL; ++ break; ++ } ++ + r = kvm_gfn_to_hva_cache_init(vcpu->kvm, + &vcpu->arch.xen.vcpu_info_cache, + data->u.gpa, +@@ -354,6 +379,12 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcp + break; + } + ++ /* It must fit within a single page */ ++ if ((data->u.gpa & ~PAGE_MASK) + sizeof(struct pvclock_vcpu_time_info) > PAGE_SIZE) { ++ r = -EINVAL; ++ break; ++ } ++ + r = kvm_gfn_to_hva_cache_init(vcpu->kvm, + &vcpu->arch.xen.vcpu_time_info_cache, + data->u.gpa, +@@ -375,6 +406,12 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcp + break; + } + ++ /* It must fit within a single page */ ++ if ((data->u.gpa & ~PAGE_MASK) + sizeof(struct vcpu_runstate_info) > PAGE_SIZE) { ++ r = -EINVAL; ++ break; ++ } ++ + r = kvm_gfn_to_hva_cache_init(vcpu->kvm, + &vcpu->arch.xen.runstate_cache, + data->u.gpa, diff --git a/queue-5.15/series b/queue-5.15/series index bbf36239d42..f3f6b294de8 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -52,3 +52,16 @@ x86-xen-streamline-and-fix-pv-cpu-enumeration.patch revert-module-async-async_synchronize_full-on-module.patch gcc-plugins-stackleak-use-noinstr-in-favor-of-notrac.patch random-wake-up-dev-random-writers-after-zap.patch +kvm-x86-xen-fix-runstate-updates-to-be-atomic-when-preempting-vcpu.patch +kvm-x86-nsvm-nvmx-set-nested_run_pending-on-vm-entry-which-is-a-result-of-rsm.patch +kvm-x86-svm-don-t-passthrough-smap-smep-pke-bits-in-npt-gcr0.pg-case.patch +kvm-x86-nsvm-fix-potential-null-derefernce-on-nested-migration.patch +kvm-x86-nsvm-mark-vmcb01-as-dirty-when-restoring-smm-saved-state.patch +iwlwifi-fix-use-after-free.patch +drm-radeon-fix-backlight-control-on-imac-12-1.patch +drm-atomic-don-t-pollute-crtc_state-mode_blob-with-error-pointers.patch +drm-amd-pm-correct-the-sequence-of-sending-gpu-reset-msg.patch +drm-amdgpu-skipping-sdma-hw_init-and-hw_fini-for-s0ix.patch +drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch +drm-i915-fix-dbuf-slice-config-lookup.patch +drm-i915-fix-mbus-join-config-lookup.patch