--- /dev/null
+From ff1712f953e27f0b0718762ec17d0adb15c9fd0b Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Fri, 20 Nov 2020 13:57:48 +0000
+Subject: arm64: pgtable: Ensure dirty bit is preserved across pte_wrprotect()
+
+From: Will Deacon <will@kernel.org>
+
+commit ff1712f953e27f0b0718762ec17d0adb15c9fd0b upstream.
+
+With hardware dirty bit management, calling pte_wrprotect() on a writable,
+dirty PTE will lose the dirty state and return a read-only, clean entry.
+
+Move the logic from ptep_set_wrprotect() into pte_wrprotect() to ensure that
+the dirty bit is preserved for writable entries, as this is required for
+soft-dirty bit management if we enable it in the future.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits")
+Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
+Link: https://lore.kernel.org/r/20201120143557.6715-3-will@kernel.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/include/asm/pgtable.h | 27 ++++++++++++++-------------
+ 1 file changed, 14 insertions(+), 13 deletions(-)
+
+--- a/arch/arm64/include/asm/pgtable.h
++++ b/arch/arm64/include/asm/pgtable.h
+@@ -146,13 +146,6 @@ static inline pte_t set_pte_bit(pte_t pt
+ return pte;
+ }
+
+-static inline pte_t pte_wrprotect(pte_t pte)
+-{
+- pte = clear_pte_bit(pte, __pgprot(PTE_WRITE));
+- pte = set_pte_bit(pte, __pgprot(PTE_RDONLY));
+- return pte;
+-}
+-
+ static inline pte_t pte_mkwrite(pte_t pte)
+ {
+ pte = set_pte_bit(pte, __pgprot(PTE_WRITE));
+@@ -178,6 +171,20 @@ static inline pte_t pte_mkdirty(pte_t pt
+ return pte;
+ }
+
++static inline pte_t pte_wrprotect(pte_t pte)
++{
++ /*
++ * If hardware-dirty (PTE_WRITE/DBM bit set and PTE_RDONLY
++ * clear), set the PTE_DIRTY bit.
++ */
++ if (pte_hw_dirty(pte))
++ pte = pte_mkdirty(pte);
++
++ pte = clear_pte_bit(pte, __pgprot(PTE_WRITE));
++ pte = set_pte_bit(pte, __pgprot(PTE_RDONLY));
++ return pte;
++}
++
+ static inline pte_t pte_mkold(pte_t pte)
+ {
+ return clear_pte_bit(pte, __pgprot(PTE_AF));
+@@ -799,12 +806,6 @@ static inline void ptep_set_wrprotect(st
+ pte = READ_ONCE(*ptep);
+ do {
+ old_pte = pte;
+- /*
+- * If hardware-dirty (PTE_WRITE/DBM bit set and PTE_RDONLY
+- * clear), set the PTE_DIRTY bit.
+- */
+- if (pte_hw_dirty(pte))
+- pte = pte_mkdirty(pte);
+ pte = pte_wrprotect(pte);
+ pte_val(pte) = cmpxchg_relaxed(&pte_val(*ptep),
+ pte_val(old_pte), pte_val(pte));
--- /dev/null
+From 07509e10dcc77627f8b6a57381e878fe269958d3 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Fri, 20 Nov 2020 13:28:01 +0000
+Subject: arm64: pgtable: Fix pte_accessible()
+
+From: Will Deacon <will@kernel.org>
+
+commit 07509e10dcc77627f8b6a57381e878fe269958d3 upstream.
+
+pte_accessible() is used by ptep_clear_flush() to figure out whether TLB
+invalidation is necessary when unmapping pages for reclaim. Although our
+implementation is correct according to the architecture, returning true
+only for valid, young ptes in the absence of racing page-table
+modifications, this is in fact flawed due to lazy invalidation of old
+ptes in ptep_clear_flush_young() where we elide the expensive DSB
+instruction for completing the TLB invalidation.
+
+Rather than penalise the aging path, adjust pte_accessible() to return
+true for any valid pte, even if the access flag is cleared.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 76c714be0e5e ("arm64: pgtable: implement pte_accessible()")
+Reported-by: Yu Zhao <yuzhao@google.com>
+Acked-by: Yu Zhao <yuzhao@google.com>
+Reviewed-by: Minchan Kim <minchan@kernel.org>
+Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
+Link: https://lore.kernel.org/r/20201120143557.6715-2-will@kernel.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/include/asm/pgtable.h | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/arch/arm64/include/asm/pgtable.h
++++ b/arch/arm64/include/asm/pgtable.h
+@@ -108,8 +108,6 @@ extern unsigned long empty_zero_page[PAG
+ #define pte_valid(pte) (!!(pte_val(pte) & PTE_VALID))
+ #define pte_valid_not_user(pte) \
+ ((pte_val(pte) & (PTE_VALID | PTE_USER)) == PTE_VALID)
+-#define pte_valid_young(pte) \
+- ((pte_val(pte) & (PTE_VALID | PTE_AF)) == (PTE_VALID | PTE_AF))
+ #define pte_valid_user(pte) \
+ ((pte_val(pte) & (PTE_VALID | PTE_USER)) == (PTE_VALID | PTE_USER))
+
+@@ -117,9 +115,12 @@ extern unsigned long empty_zero_page[PAG
+ * Could the pte be present in the TLB? We must check mm_tlb_flush_pending
+ * so that we don't erroneously return false for pages that have been
+ * remapped as PROT_NONE but are yet to be flushed from the TLB.
++ * Note that we can't make any assumptions based on the state of the access
++ * flag, since ptep_clear_flush_young() elides a DSB when invalidating the
++ * TLB.
+ */
+ #define pte_accessible(mm, pte) \
+- (mm_tlb_flush_pending(mm) ? pte_present(pte) : pte_valid_young(pte))
++ (mm_tlb_flush_pending(mm) ? pte_present(pte) : pte_valid(pte))
+
+ /*
+ * p??_access_permitted() is true for valid user mappings (subject to the
--- /dev/null
+From 476e23f4c540949ac5ea4fad4f6f6fa0e2d41f42 Mon Sep 17 00:00:00 2001
+From: Jon Hunter <jonathanh@nvidia.com>
+Date: Wed, 11 Nov 2020 10:41:17 +0000
+Subject: arm64: tegra: Correct the UART for Jetson Xavier NX
+
+From: Jon Hunter <jonathanh@nvidia.com>
+
+commit 476e23f4c540949ac5ea4fad4f6f6fa0e2d41f42 upstream.
+
+The Jetson Xavier NX board routes UARTA to the 40-pin header and UARTC
+to a 12-pin debug header. The UARTs can be used by either the Tegra
+Combined UART (TCU) driver or the Tegra 8250 driver. By default, the
+TCU will use UARTC on Jetson Xavier NX. Currently, device-tree for
+Xavier NX enables the TCU and the Tegra 8250 node for UARTC. Fix this
+by disabling the Tegra 8250 node for UARTC and enabling the Tegra 8250
+node for UARTA.
+
+Fixes: 3f9efbbe57bc ("arm64: tegra: Add support for Jetson Xavier NX")
+Cc: stable@vger.kernel.org
+Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/boot/dts/nvidia/tegra194-p3668-0000.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/nvidia/tegra194-p3668-0000.dtsi
++++ b/arch/arm64/boot/dts/nvidia/tegra194-p3668-0000.dtsi
+@@ -54,7 +54,7 @@
+ status = "okay";
+ };
+
+- serial@c280000 {
++ serial@3100000 {
+ status = "okay";
+ };
+
--- /dev/null
+From f24a2acc15bcc7bbd295f9759efc873b88fbe429 Mon Sep 17 00:00:00 2001
+From: JC Kuo <jckuo@nvidia.com>
+Date: Thu, 19 Nov 2020 15:23:45 +0800
+Subject: arm64: tegra: Fix USB_VBUS_EN0 regulator on Jetson TX1
+
+From: JC Kuo <jckuo@nvidia.com>
+
+commit f24a2acc15bcc7bbd295f9759efc873b88fbe429 upstream.
+
+USB host mode is broken on the OTG port of Jetson TX1 platform because
+the USB_VBUS_EN0 regulator (regulator@11) is being overwritten by the
+vdd-cam-1v2 regulator. This commit rearranges USB_VBUS_EN0 to be
+regulator@14.
+
+Fixes: 257c8047be44 ("arm64: tegra: jetson-tx1: Add camera supplies")
+Cc: stable@vger.kernel.org
+Signed-off-by: JC Kuo <jckuo@nvidia.com>
+Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi | 20 ++++++++++----------
+ 1 file changed, 10 insertions(+), 10 deletions(-)
+
+--- a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
++++ b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
+@@ -1663,16 +1663,6 @@
+ vin-supply = <&vdd_5v0_sys>;
+ };
+
+- vdd_usb_vbus_otg: regulator@11 {
+- compatible = "regulator-fixed";
+- regulator-name = "USB_VBUS_EN0";
+- regulator-min-microvolt = <5000000>;
+- regulator-max-microvolt = <5000000>;
+- gpio = <&gpio TEGRA_GPIO(CC, 4) GPIO_ACTIVE_HIGH>;
+- enable-active-high;
+- vin-supply = <&vdd_5v0_sys>;
+- };
+-
+ vdd_hdmi: regulator@10 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_HDMI_5V0";
+@@ -1712,4 +1702,14 @@
+ enable-active-high;
+ vin-supply = <&vdd_3v3_sys>;
+ };
++
++ vdd_usb_vbus_otg: regulator@14 {
++ compatible = "regulator-fixed";
++ regulator-name = "USB_VBUS_EN0";
++ regulator-min-microvolt = <5000000>;
++ regulator-max-microvolt = <5000000>;
++ gpio = <&gpio TEGRA_GPIO(CC, 4) GPIO_ACTIVE_HIGH>;
++ enable-active-high;
++ vin-supply = <&vdd_5v0_sys>;
++ };
+ };
--- /dev/null
+From 7acc79eb5f78d3d1aa5dd21fc0a0329f1b7f2be5 Mon Sep 17 00:00:00 2001
+From: Kenneth Feng <kenneth.feng@amd.com>
+Date: Tue, 17 Nov 2020 21:10:59 +0800
+Subject: drm/amd/amdgpu: fix null pointer in runtime pm
+
+From: Kenneth Feng <kenneth.feng@amd.com>
+
+commit 7acc79eb5f78d3d1aa5dd21fc0a0329f1b7f2be5 upstream.
+
+fix the null pointer issue when runtime pm is triggered.
+
+Signed-off-by: Kenneth Feng <kenneth.feng@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/amdgpu_device.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+@@ -4593,7 +4593,7 @@ int amdgpu_device_baco_enter(struct drm_
+ if (!amdgpu_device_supports_baco(adev->ddev))
+ return -ENOTSUPP;
+
+- if (ras && ras->supported)
++ if (ras && ras->supported && adev->nbio.funcs->enable_doorbell_interrupt)
+ adev->nbio.funcs->enable_doorbell_interrupt(adev, false);
+
+ return amdgpu_dpm_baco_enter(adev);
+@@ -4612,7 +4612,7 @@ int amdgpu_device_baco_exit(struct drm_d
+ if (ret)
+ return ret;
+
+- if (ras && ras->supported)
++ if (ras && ras->supported && adev->nbio.funcs->enable_doorbell_interrupt)
+ adev->nbio.funcs->enable_doorbell_interrupt(adev, true);
+
+ return 0;
--- /dev/null
+From d661155bfca329851a27bb5120fab027db43bd23 Mon Sep 17 00:00:00 2001
+From: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+Date: Tue, 17 Nov 2020 15:25:48 -0500
+Subject: drm/amd/display: Avoid HDCP initialization in devices without output
+
+From: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+
+commit d661155bfca329851a27bb5120fab027db43bd23 upstream.
+
+The HDCP feature requires at least one connector attached to the device;
+however, some GPUs do not have a physical output, making the HDCP
+initialization irrelevant. This patch disables HDCP initialization when
+the graphic card does not have output.
+
+Acked-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@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 | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+@@ -960,7 +960,7 @@ static int amdgpu_dm_init(struct amdgpu_
+ amdgpu_dm_init_color_mod();
+
+ #ifdef CONFIG_DRM_AMD_DC_HDCP
+- if (adev->asic_type >= CHIP_RAVEN) {
++ if (adev->dm.dc->caps.max_links > 0 && adev->asic_type >= CHIP_RAVEN) {
+ adev->dm.hdcp_workqueue = hdcp_create_workqueue(adev, &init_params.cp_psp, adev->dm.dc);
+
+ if (!adev->dm.hdcp_workqueue)
--- /dev/null
+From dbbf2728d50343b7947001a81f4c8cc98e4b44e5 Mon Sep 17 00:00:00 2001
+From: Sonny Jiang <sonny.jiang@amd.com>
+Date: Fri, 20 Nov 2020 02:38:09 -0500
+Subject: drm/amdgpu: fix a page fault
+
+From: Sonny Jiang <sonny.jiang@amd.com>
+
+commit dbbf2728d50343b7947001a81f4c8cc98e4b44e5 upstream.
+
+The UVD firmware is copied to cpu addr in uvd_resume, so it
+should be used after that. This is to fix a bug introduced by
+patch drm/amdgpu: fix SI UVD firmware validate resume fail.
+
+Signed-off-by: Sonny Jiang <sonny.jiang@amd.com>
+Reviewed-by: Leo Liu <leo.liu@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/uvd_v3_1.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c
++++ b/drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c
+@@ -555,13 +555,6 @@ static int uvd_v3_1_sw_init(void *handle
+ if (r)
+ return r;
+
+- /* Retrieval firmware validate key */
+- ptr = adev->uvd.inst[0].cpu_addr;
+- ptr += 192 + 16;
+- memcpy(&ucode_len, ptr, 4);
+- ptr += ucode_len;
+- memcpy(&adev->uvd.keyselect, ptr, 4);
+-
+ ring = &adev->uvd.inst->ring;
+ sprintf(ring->name, "uvd");
+ r = amdgpu_ring_init(adev, ring, 512, &adev->uvd.inst->irq, 0,
+@@ -573,6 +566,13 @@ static int uvd_v3_1_sw_init(void *handle
+ if (r)
+ return r;
+
++ /* Retrieval firmware validate key */
++ ptr = adev->uvd.inst[0].cpu_addr;
++ ptr += 192 + 16;
++ memcpy(&ucode_len, ptr, 4);
++ ptr += ucode_len;
++ memcpy(&adev->uvd.keyselect, ptr, 4);
++
+ r = amdgpu_uvd_entity_init(adev);
+
+ return r;
--- /dev/null
+From 4d6a95366117b241bb3298e1c318a36ebb7544d0 Mon Sep 17 00:00:00 2001
+From: Sonny Jiang <sonny.jiang@amd.com>
+Date: Fri, 6 Nov 2020 16:42:47 -0500
+Subject: drm/amdgpu: fix SI UVD firmware validate resume fail
+
+From: Sonny Jiang <sonny.jiang@amd.com>
+
+commit 4d6a95366117b241bb3298e1c318a36ebb7544d0 upstream.
+
+The SI UVD firmware validate key is stored at the end of firmware,
+which is changed during resume while playing video. So get the key
+at sw_init and store it for fw validate using.
+
+Signed-off-by: Sonny Jiang <sonny.jiang@amd.com>
+Reviewed-by: Leo Liu <leo.liu@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/amdgpu_uvd.h | 1 +
+ drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c | 20 +++++++++++---------
+ 2 files changed, 12 insertions(+), 9 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h
+@@ -67,6 +67,7 @@ struct amdgpu_uvd {
+ unsigned harvest_config;
+ /* store image width to adjust nb memory state */
+ unsigned decode_image_width;
++ uint32_t keyselect;
+ };
+
+ int amdgpu_uvd_sw_init(struct amdgpu_device *adev);
+--- a/drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c
++++ b/drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c
+@@ -277,15 +277,8 @@ static void uvd_v3_1_mc_resume(struct am
+ */
+ static int uvd_v3_1_fw_validate(struct amdgpu_device *adev)
+ {
+- void *ptr;
+- uint32_t ucode_len, i;
+- uint32_t keysel;
+-
+- ptr = adev->uvd.inst[0].cpu_addr;
+- ptr += 192 + 16;
+- memcpy(&ucode_len, ptr, 4);
+- ptr += ucode_len;
+- memcpy(&keysel, ptr, 4);
++ int i;
++ uint32_t keysel = adev->uvd.keyselect;
+
+ WREG32(mmUVD_FW_START, keysel);
+
+@@ -550,6 +543,8 @@ static int uvd_v3_1_sw_init(void *handle
+ struct amdgpu_ring *ring;
+ struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+ int r;
++ void *ptr;
++ uint32_t ucode_len;
+
+ /* UVD TRAP */
+ r = amdgpu_irq_add_id(adev, AMDGPU_IRQ_CLIENTID_LEGACY, 124, &adev->uvd.inst->irq);
+@@ -560,6 +555,13 @@ static int uvd_v3_1_sw_init(void *handle
+ if (r)
+ return r;
+
++ /* Retrieval firmware validate key */
++ ptr = adev->uvd.inst[0].cpu_addr;
++ ptr += 192 + 16;
++ memcpy(&ucode_len, ptr, 4);
++ ptr += ucode_len;
++ memcpy(&adev->uvd.keyselect, ptr, 4);
++
+ ring = &adev->uvd.inst->ring;
+ sprintf(ring->name, "uvd");
+ r = amdgpu_ring_init(adev, ring, 512, &adev->uvd.inst->irq, 0,
--- /dev/null
+From 60734bd54679d7998a24a257b0403f7644005572 Mon Sep 17 00:00:00 2001
+From: Likun Gao <Likun.Gao@amd.com>
+Date: Mon, 23 Nov 2020 10:28:46 +0800
+Subject: drm/amdgpu: update golden setting for sienna_cichlid
+
+From: Likun Gao <Likun.Gao@amd.com>
+
+commit 60734bd54679d7998a24a257b0403f7644005572 upstream.
+
+Update golden setting for sienna_cichlid.
+
+Signed-off-by: Likun Gao <Likun.Gao@amd.com>
+Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org # 5.9.x
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+@@ -3105,6 +3105,8 @@ static const struct soc15_reg_golden gol
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DEBUG3, 0xffffffff, 0x00000280),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DEBUG4, 0xffffffff, 0x00800000),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_EXCEPTION_CONTROL, 0x7fff0f1f, 0x00b80000),
++ SOC15_REG_GOLDEN_VALUE(GC, 0 ,mmGCEA_SDP_TAG_RESERVE0, 0xffffffff, 0x10100100),
++ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGCEA_SDP_TAG_RESERVE1, 0xffffffff, 0x17000088),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGCR_GENERAL_CNTL_Sienna_Cichlid, 0x1ff1ffff, 0x00000500),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGE_PC_CNTL, 0x003fffff, 0x00280400),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGL2A_ADDR_MATCH_MASK, 0xffffffff, 0xffffffcf),
--- /dev/null
+From acfdd18591eaac25446e976a0c0d190f8b3dbfb1 Mon Sep 17 00:00:00 2001
+From: Amit Sunil Dhamne <amit.sunil.dhamne@xilinx.com>
+Date: Mon, 23 Nov 2020 21:52:41 -0800
+Subject: firmware: xilinx: Use hash-table for api feature check
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Amit Sunil Dhamne <amit.sunil.dhamne@xilinx.com>
+
+commit acfdd18591eaac25446e976a0c0d190f8b3dbfb1 upstream.
+
+Currently array of fix length PM_API_MAX is used to cache
+the pm_api version (valid or invalid). However ATF based
+PM APIs values are much higher then PM_API_MAX.
+So to include ATF based PM APIs also, use hash-table to
+store the pm_api version status.
+
+Signed-off-by: Amit Sunil Dhamne <amit.sunil.dhamne@xilinx.com>
+Reported-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Ravi Patel <ravi.patel@xilinx.com>
+Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+Tested-by: Michal Simek <michal.simek@xilinx.com>
+Fixes: f3217d6f2f7a ("firmware: xilinx: fix out-of-bounds access")
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/1606197161-25976-1-git-send-email-rajan.vaja@xilinx.com
+Signed-off-by: Michal Simek <michal.simek@xilinx.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/firmware/xilinx/zynqmp.c | 63 +++++++++++++++++++++++++++--------
+ include/linux/firmware/xlnx-zynqmp.h | 4 --
+ 2 files changed, 49 insertions(+), 18 deletions(-)
+
+--- a/drivers/firmware/xilinx/zynqmp.c
++++ b/drivers/firmware/xilinx/zynqmp.c
+@@ -20,12 +20,28 @@
+ #include <linux/of_platform.h>
+ #include <linux/slab.h>
+ #include <linux/uaccess.h>
++#include <linux/hashtable.h>
+
+ #include <linux/firmware/xlnx-zynqmp.h>
+ #include "zynqmp-debug.h"
+
++/* Max HashMap Order for PM API feature check (1<<7 = 128) */
++#define PM_API_FEATURE_CHECK_MAX_ORDER 7
++
+ static bool feature_check_enabled;
+-static u32 zynqmp_pm_features[PM_API_MAX];
++DEFINE_HASHTABLE(pm_api_features_map, PM_API_FEATURE_CHECK_MAX_ORDER);
++
++/**
++ * struct pm_api_feature_data - PM API Feature data
++ * @pm_api_id: PM API Id, used as key to index into hashmap
++ * @feature_status: status of PM API feature: valid, invalid
++ * @hentry: hlist_node that hooks this entry into hashtable
++ */
++struct pm_api_feature_data {
++ u32 pm_api_id;
++ int feature_status;
++ struct hlist_node hentry;
++};
+
+ static const struct mfd_cell firmware_devs[] = {
+ {
+@@ -142,29 +158,37 @@ static int zynqmp_pm_feature(u32 api_id)
+ int ret;
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ u64 smc_arg[2];
++ struct pm_api_feature_data *feature_data;
+
+ if (!feature_check_enabled)
+ return 0;
+
+- /* Return value if feature is already checked */
+- if (api_id > ARRAY_SIZE(zynqmp_pm_features))
+- return PM_FEATURE_INVALID;
++ /* Check for existing entry in hash table for given api */
++ hash_for_each_possible(pm_api_features_map, feature_data, hentry,
++ api_id) {
++ if (feature_data->pm_api_id == api_id)
++ return feature_data->feature_status;
++ }
+
+- if (zynqmp_pm_features[api_id] != PM_FEATURE_UNCHECKED)
+- return zynqmp_pm_features[api_id];
++ /* Add new entry if not present */
++ feature_data = kmalloc(sizeof(*feature_data), GFP_KERNEL);
++ if (!feature_data)
++ return -ENOMEM;
+
++ feature_data->pm_api_id = api_id;
+ smc_arg[0] = PM_SIP_SVC | PM_FEATURE_CHECK;
+ smc_arg[1] = api_id;
+
+ ret = do_fw_call(smc_arg[0], smc_arg[1], 0, ret_payload);
+- if (ret) {
+- zynqmp_pm_features[api_id] = PM_FEATURE_INVALID;
+- return PM_FEATURE_INVALID;
+- }
++ if (ret)
++ ret = -EOPNOTSUPP;
++ else
++ ret = ret_payload[1];
+
+- zynqmp_pm_features[api_id] = ret_payload[1];
++ feature_data->feature_status = ret;
++ hash_add(pm_api_features_map, &feature_data->hentry, api_id);
+
+- return zynqmp_pm_features[api_id];
++ return ret;
+ }
+
+ /**
+@@ -200,9 +224,12 @@ int zynqmp_pm_invoke_fn(u32 pm_api_id, u
+ * Make sure to stay in x0 register
+ */
+ u64 smc_arg[4];
++ int ret;
+
+- if (zynqmp_pm_feature(pm_api_id) == PM_FEATURE_INVALID)
+- return -ENOTSUPP;
++ /* Check if feature is supported or not */
++ ret = zynqmp_pm_feature(pm_api_id);
++ if (ret < 0)
++ return ret;
+
+ smc_arg[0] = PM_SIP_SVC | pm_api_id;
+ smc_arg[1] = ((u64)arg1 << 32) | arg0;
+@@ -1252,9 +1279,17 @@ static int zynqmp_firmware_probe(struct
+
+ static int zynqmp_firmware_remove(struct platform_device *pdev)
+ {
++ struct pm_api_feature_data *feature_data;
++ int i;
++
+ mfd_remove_devices(&pdev->dev);
+ zynqmp_pm_api_debugfs_exit();
+
++ hash_for_each(pm_api_features_map, i, feature_data, hentry) {
++ hash_del(&feature_data->hentry);
++ kfree(feature_data);
++ }
++
+ return 0;
+ }
+
+--- a/include/linux/firmware/xlnx-zynqmp.h
++++ b/include/linux/firmware/xlnx-zynqmp.h
+@@ -50,10 +50,6 @@
+ #define ZYNQMP_PM_CAPABILITY_WAKEUP 0x4U
+ #define ZYNQMP_PM_CAPABILITY_UNUSABLE 0x8U
+
+-/* Feature check status */
+-#define PM_FEATURE_INVALID -1
+-#define PM_FEATURE_UNCHECKED 0
+-
+ /*
+ * Firmware FPGA Manager flags
+ * XILINX_ZYNQMP_PM_FPGA_FULL: FPGA full reconfiguration
--- /dev/null
+From 9c3a205c5ffa36e96903c2e37eb5f41c0f03c43e Mon Sep 17 00:00:00 2001
+From: Pavel Begunkov <asml.silence@gmail.com>
+Date: Mon, 23 Nov 2020 23:20:27 +0000
+Subject: io_uring: fix ITER_BVEC check
+
+From: Pavel Begunkov <asml.silence@gmail.com>
+
+commit 9c3a205c5ffa36e96903c2e37eb5f41c0f03c43e upstream.
+
+iov_iter::type is a bitmask that also keeps direction etc., so it
+shouldn't be directly compared against ITER_*. Use proper helper.
+
+Fixes: ff6165b2d7f6 ("io_uring: retain iov_iter state over io_read/io_write calls")
+Reported-by: David Howells <dhowells@redhat.com>
+Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
+Cc: <stable@vger.kernel.org> # 5.9
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/io_uring.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/io_uring.c
++++ b/fs/io_uring.c
+@@ -2991,7 +2991,7 @@ static void io_req_map_rw(struct io_kioc
+ rw->free_iovec = NULL;
+ rw->bytes_done = 0;
+ /* can only be fixed buffers, no need to do anything */
+- if (iter->type == ITER_BVEC)
++ if (iov_iter_is_bvec(iter))
+ return;
+ if (!iovec) {
+ unsigned iov_off = 0;
--- /dev/null
+From d76b42e92780c3587c1a998a3a943b501c137553 Mon Sep 17 00:00:00 2001
+From: David Woodhouse <dwmw@amazon.co.uk>
+Date: Thu, 26 Nov 2020 11:13:51 +0000
+Subject: iommu/vt-d: Don't read VCCAP register unless it exists
+
+From: David Woodhouse <dwmw@amazon.co.uk>
+
+commit d76b42e92780c3587c1a998a3a943b501c137553 upstream.
+
+My virtual IOMMU implementation is whining that the guest is reading a
+register that doesn't exist. Only read the VCCAP_REG if the corresponding
+capability is set in ECAP_REG to indicate that it actually exists.
+
+Fixes: 3375303e8287 ("iommu/vt-d: Add custom allocator for IOASID")
+Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
+Reviewed-by: Liu Yi L <yi.l.liu@intel.com>
+Cc: stable@vger.kernel.org # v5.7+
+Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
+Link: https://lore.kernel.org/r/de32b150ffaa752e0cff8571b17dfb1213fbe71c.camel@infradead.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iommu/intel/dmar.c | 3 ++-
+ drivers/iommu/intel/iommu.c | 4 ++--
+ 2 files changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/iommu/intel/dmar.c
++++ b/drivers/iommu/intel/dmar.c
+@@ -964,7 +964,8 @@ static int map_iommu(struct intel_iommu
+ warn_invalid_dmar(phys_addr, " returns all ones");
+ goto unmap;
+ }
+- iommu->vccap = dmar_readq(iommu->reg + DMAR_VCCAP_REG);
++ if (ecap_vcs(iommu->ecap))
++ iommu->vccap = dmar_readq(iommu->reg + DMAR_VCCAP_REG);
+
+ /* the registers might be more than one page */
+ map_size = max_t(int, ecap_max_iotlb_offset(iommu->ecap),
+--- a/drivers/iommu/intel/iommu.c
++++ b/drivers/iommu/intel/iommu.c
+@@ -1798,7 +1798,7 @@ static void free_dmar_iommu(struct intel
+ if (ecap_prs(iommu->ecap))
+ intel_svm_finish_prq(iommu);
+ }
+- if (ecap_vcs(iommu->ecap) && vccap_pasid(iommu->vccap))
++ if (vccap_pasid(iommu->vccap))
+ ioasid_unregister_allocator(&iommu->pasid_allocator);
+
+ #endif
+@@ -3177,7 +3177,7 @@ static void register_pasid_allocator(str
+ * is active. All vIOMMU allocators will eventually be calling the same
+ * host allocator.
+ */
+- if (!ecap_vcs(iommu->ecap) || !vccap_pasid(iommu->vccap))
++ if (!vccap_pasid(iommu->vccap))
+ return;
+
+ pr_info("Register custom PASID allocator\n");
--- /dev/null
+From 23bde34771f1ea92fb5e6682c0d8c04304d34b3b Mon Sep 17 00:00:00 2001
+From: Zenghui Yu <yuzenghui@huawei.com>
+Date: Tue, 17 Nov 2020 23:16:29 +0800
+Subject: KVM: arm64: vgic-v3: Drop the reporting of GICR_TYPER.Last for userspace
+
+From: Zenghui Yu <yuzenghui@huawei.com>
+
+commit 23bde34771f1ea92fb5e6682c0d8c04304d34b3b upstream.
+
+It was recently reported that if GICR_TYPER is accessed before the RD base
+address is set, we'll suffer from the unset @rdreg dereferencing. Oops...
+
+ gpa_t last_rdist_typer = rdreg->base + GICR_TYPER +
+ (rdreg->free_index - 1) * KVM_VGIC_V3_REDIST_SIZE;
+
+It's "expected" that users will access registers in the redistributor if
+the RD has been properly configured (e.g., the RD base address is set). But
+it hasn't yet been covered by the existing documentation.
+
+Per discussion on the list [1], the reporting of the GICR_TYPER.Last bit
+for userspace never actually worked. And it's difficult for us to emulate
+it correctly given that userspace has the flexibility to access it any
+time. Let's just drop the reporting of the Last bit for userspace for now
+(userspace should have full knowledge about it anyway) and it at least
+prevents kernel from panic ;-)
+
+[1] https://lore.kernel.org/kvmarm/c20865a267e44d1e2c0d52ce4e012263@kernel.org/
+
+Fixes: ba7b3f1275fd ("KVM: arm/arm64: Revisit Redistributor TYPER last bit computation")
+Reported-by: Keqian Zhu <zhukeqian1@huawei.com>
+Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Reviewed-by: Eric Auger <eric.auger@redhat.com>
+Link: https://lore.kernel.org/r/20201117151629.1738-1-yuzenghui@huawei.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/kvm/vgic/vgic-mmio-v3.c | 22 ++++++++++++++++++++--
+ 1 file changed, 20 insertions(+), 2 deletions(-)
+
+--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
++++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+@@ -273,6 +273,23 @@ static unsigned long vgic_mmio_read_v3r_
+ return extract_bytes(value, addr & 7, len);
+ }
+
++static unsigned long vgic_uaccess_read_v3r_typer(struct kvm_vcpu *vcpu,
++ gpa_t addr, unsigned int len)
++{
++ unsigned long mpidr = kvm_vcpu_get_mpidr_aff(vcpu);
++ int target_vcpu_id = vcpu->vcpu_id;
++ u64 value;
++
++ value = (u64)(mpidr & GENMASK(23, 0)) << 32;
++ value |= ((target_vcpu_id & 0xffff) << 8);
++
++ if (vgic_has_its(vcpu->kvm))
++ value |= GICR_TYPER_PLPIS;
++
++ /* reporting of the Last bit is not supported for userspace */
++ return extract_bytes(value, addr & 7, len);
++}
++
+ static unsigned long vgic_mmio_read_v3r_iidr(struct kvm_vcpu *vcpu,
+ gpa_t addr, unsigned int len)
+ {
+@@ -593,8 +610,9 @@ static const struct vgic_register_region
+ REGISTER_DESC_WITH_LENGTH(GICR_IIDR,
+ vgic_mmio_read_v3r_iidr, vgic_mmio_write_wi, 4,
+ VGIC_ACCESS_32bit),
+- REGISTER_DESC_WITH_LENGTH(GICR_TYPER,
+- vgic_mmio_read_v3r_typer, vgic_mmio_write_wi, 8,
++ REGISTER_DESC_WITH_LENGTH_UACCESS(GICR_TYPER,
++ vgic_mmio_read_v3r_typer, vgic_mmio_write_wi,
++ vgic_uaccess_read_v3r_typer, vgic_mmio_uaccess_write_wi, 8,
+ VGIC_ACCESS_64bit | VGIC_ACCESS_32bit),
+ REGISTER_DESC_WITH_LENGTH(GICR_WAKER,
+ vgic_mmio_read_raz, vgic_mmio_write_wi, 4,
--- /dev/null
+From 75b49620267c700f0a07fec7f27f69852db70e46 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>
+Date: Thu, 5 Nov 2020 14:47:13 +0100
+Subject: KVM: PPC: Book3S HV: XIVE: Fix possible oops when accessing ESB page
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Cédric Le Goater <clg@kaod.org>
+
+commit 75b49620267c700f0a07fec7f27f69852db70e46 upstream.
+
+When accessing the ESB page of a source interrupt, the fault handler
+will retrieve the page address from the XIVE interrupt 'xive_irq_data'
+structure. If the associated KVM XIVE interrupt is not valid, that is
+not allocated at the HW level for some reason, the fault handler will
+dereference a NULL pointer leading to the oops below :
+
+ WARNING: CPU: 40 PID: 59101 at arch/powerpc/kvm/book3s_xive_native.c:259 xive_native_esb_fault+0xe4/0x240 [kvm]
+ CPU: 40 PID: 59101 Comm: qemu-system-ppc Kdump: loaded Tainted: G W --------- - - 4.18.0-240.el8.ppc64le #1
+ NIP: c00800000e949fac LR: c00000000044b164 CTR: c00800000e949ec8
+ REGS: c000001f69617840 TRAP: 0700 Tainted: G W --------- - - (4.18.0-240.el8.ppc64le)
+ MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 44044282 XER: 00000000
+ CFAR: c00000000044b160 IRQMASK: 0
+ GPR00: c00000000044b164 c000001f69617ac0 c00800000e96e000 c000001f69617c10
+ GPR04: 05faa2b21e000080 0000000000000000 0000000000000005 ffffffffffffffff
+ GPR08: 0000000000000000 0000000000000001 0000000000000000 0000000000000001
+ GPR12: c00800000e949ec8 c000001ffffd3400 0000000000000000 0000000000000000
+ GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+ GPR20: 0000000000000000 0000000000000000 c000001f5c065160 c000000001c76f90
+ GPR24: c000001f06f20000 c000001f5c065100 0000000000000008 c000001f0eb98c78
+ GPR28: c000001dcab40000 c000001dcab403d8 c000001f69617c10 0000000000000011
+ NIP [c00800000e949fac] xive_native_esb_fault+0xe4/0x240 [kvm]
+ LR [c00000000044b164] __do_fault+0x64/0x220
+ Call Trace:
+ [c000001f69617ac0] [0000000137a5dc20] 0x137a5dc20 (unreliable)
+ [c000001f69617b50] [c00000000044b164] __do_fault+0x64/0x220
+ [c000001f69617b90] [c000000000453838] do_fault+0x218/0x930
+ [c000001f69617bf0] [c000000000456f50] __handle_mm_fault+0x350/0xdf0
+ [c000001f69617cd0] [c000000000457b1c] handle_mm_fault+0x12c/0x310
+ [c000001f69617d10] [c00000000007ef44] __do_page_fault+0x264/0xbb0
+ [c000001f69617df0] [c00000000007f8c8] do_page_fault+0x38/0xd0
+ [c000001f69617e30] [c00000000000a714] handle_page_fault+0x18/0x38
+ Instruction dump:
+ 40c2fff0 7c2004ac 2fa90000 409e0118 73e90001 41820080 e8bd0008 7c2004ac
+ 7ca90074 39400000 915c0000 7929d182 <0b090000> 2fa50000 419e0080 e89e0018
+ ---[ end trace 66c6ff034c53f64f ]---
+ xive-kvm: xive_native_esb_fault: accessing invalid ESB page for source 8 !
+
+Fix that by checking the validity of the KVM XIVE interrupt structure.
+
+Fixes: 6520ca64cde7 ("KVM: PPC: Book3S HV: XIVE: Add a mapping for the source ESB pages")
+Cc: stable@vger.kernel.org # v5.2+
+Reported-by: Greg Kurz <groug@kaod.org>
+Signed-off-by: Cédric Le Goater <clg@kaod.org>
+Tested-by: Greg Kurz <groug@kaod.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20201105134713.656160-1-clg@kaod.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_xive_native.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/arch/powerpc/kvm/book3s_xive_native.c
++++ b/arch/powerpc/kvm/book3s_xive_native.c
+@@ -251,6 +251,13 @@ static vm_fault_t xive_native_esb_fault(
+ }
+
+ state = &sb->irq_state[src];
++
++ /* Some sanity checking */
++ if (!state->valid) {
++ pr_devel("%s: source %lx invalid !\n", __func__, irq);
++ return VM_FAULT_SIGBUS;
++ }
++
+ kvmppc_xive_select_irq(state, &hw_num, &xd);
+
+ arch_spin_lock(&sb->lock);
--- /dev/null
+From 71cc849b7093bb83af966c0e60cb11b7f35cd746 Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Fri, 27 Nov 2020 09:18:20 +0100
+Subject: KVM: x86: Fix split-irqchip vs interrupt injection window request
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+commit 71cc849b7093bb83af966c0e60cb11b7f35cd746 upstream.
+
+kvm_cpu_accept_dm_intr and kvm_vcpu_ready_for_interrupt_injection are
+a hodge-podge of conditions, hacked together to get something that
+more or less works. But what is actually needed is much simpler;
+in both cases the fundamental question is, do we have a place to stash
+an interrupt if userspace does KVM_INTERRUPT?
+
+In userspace irqchip mode, that is !vcpu->arch.interrupt.injected.
+Currently kvm_event_needs_reinjection(vcpu) covers it, but it is
+unnecessarily restrictive.
+
+In split irqchip mode it's a bit more complicated, we need to check
+kvm_apic_accept_pic_intr(vcpu) (the IRQ window exit is basically an INTACK
+cycle and thus requires ExtINTs not to be masked) as well as
+!pending_userspace_extint(vcpu). However, there is no need to
+check kvm_event_needs_reinjection(vcpu), since split irqchip keeps
+pending ExtINT state separate from event injection state, and checking
+kvm_cpu_has_interrupt(vcpu) is wrong too since ExtINT has higher
+priority than APIC interrupts. In fact the latter fixes a bug:
+when userspace requests an IRQ window vmexit, an interrupt in the
+local APIC can cause kvm_cpu_has_interrupt() to be true and thus
+kvm_vcpu_ready_for_interrupt_injection() to return false. When this
+happens, vcpu_run does not exit to userspace but the interrupt window
+vmexits keep occurring. The VM loops without any hope of making progress.
+
+Once we try to fix these with something like
+
+ return kvm_arch_interrupt_allowed(vcpu) &&
+- !kvm_cpu_has_interrupt(vcpu) &&
+- !kvm_event_needs_reinjection(vcpu) &&
+- kvm_cpu_accept_dm_intr(vcpu);
++ (!lapic_in_kernel(vcpu)
++ ? !vcpu->arch.interrupt.injected
++ : (kvm_apic_accept_pic_intr(vcpu)
++ && !pending_userspace_extint(v)));
+
+we realize two things. First, thanks to the previous patch the complex
+conditional can reuse !kvm_cpu_has_extint(vcpu). Second, the interrupt
+window request in vcpu_enter_guest()
+
+ bool req_int_win =
+ dm_request_for_irq_injection(vcpu) &&
+ kvm_cpu_accept_dm_intr(vcpu);
+
+should be kept in sync with kvm_vcpu_ready_for_interrupt_injection():
+it is unnecessary to ask the processor for an interrupt window
+if we would not be able to return to userspace. Therefore,
+kvm_cpu_accept_dm_intr(vcpu) is basically !kvm_cpu_has_extint(vcpu)
+ANDed with the existing check for masked ExtINT. It all makes sense:
+
+- we can accept an interrupt from userspace if there is a place
+ to stash it (and, for irqchip split, ExtINTs are not masked).
+ Interrupts from userspace _can_ be accepted even if right now
+ EFLAGS.IF=0.
+
+- in order to tell userspace we will inject its interrupt ("IRQ
+ window open" i.e. kvm_vcpu_ready_for_interrupt_injection), both
+ KVM and the vCPU need to be ready to accept the interrupt.
+
+... and this is what the patch implements.
+
+Reported-by: David Woodhouse <dwmw@amazon.co.uk>
+Analyzed-by: David Woodhouse <dwmw@amazon.co.uk>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Reviewed-by: Nikos Tsironis <ntsironis@arrikto.com>
+Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
+Tested-by: David Woodhouse <dwmw@amazon.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/kvm_host.h | 1 +
+ arch/x86/kvm/irq.c | 2 +-
+ arch/x86/kvm/x86.c | 18 ++++++++++--------
+ 3 files changed, 12 insertions(+), 9 deletions(-)
+
+--- a/arch/x86/include/asm/kvm_host.h
++++ b/arch/x86/include/asm/kvm_host.h
+@@ -1603,6 +1603,7 @@ int kvm_test_age_hva(struct kvm *kvm, un
+ int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+ int kvm_cpu_has_injectable_intr(struct kvm_vcpu *v);
+ int kvm_cpu_has_interrupt(struct kvm_vcpu *vcpu);
++int kvm_cpu_has_extint(struct kvm_vcpu *v);
+ int kvm_arch_interrupt_allowed(struct kvm_vcpu *vcpu);
+ int kvm_cpu_get_interrupt(struct kvm_vcpu *v);
+ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event);
+--- a/arch/x86/kvm/irq.c
++++ b/arch/x86/kvm/irq.c
+@@ -40,7 +40,7 @@ static int pending_userspace_extint(stru
+ * check if there is pending interrupt from
+ * non-APIC source without intack.
+ */
+-static int kvm_cpu_has_extint(struct kvm_vcpu *v)
++int kvm_cpu_has_extint(struct kvm_vcpu *v)
+ {
+ /*
+ * FIXME: interrupt.injected represents an interrupt whose
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -3839,21 +3839,23 @@ static int kvm_vcpu_ioctl_set_lapic(stru
+
+ static int kvm_cpu_accept_dm_intr(struct kvm_vcpu *vcpu)
+ {
++ /*
++ * We can accept userspace's request for interrupt injection
++ * as long as we have a place to store the interrupt number.
++ * The actual injection will happen when the CPU is able to
++ * deliver the interrupt.
++ */
++ if (kvm_cpu_has_extint(vcpu))
++ return false;
++
++ /* Acknowledging ExtINT does not happen if LINT0 is masked. */
+ return (!lapic_in_kernel(vcpu) ||
+ kvm_apic_accept_pic_intr(vcpu));
+ }
+
+-/*
+- * if userspace requested an interrupt window, check that the
+- * interrupt window is open.
+- *
+- * No need to exit to userspace if we already have an interrupt queued.
+- */
+ static int kvm_vcpu_ready_for_interrupt_injection(struct kvm_vcpu *vcpu)
+ {
+ return kvm_arch_interrupt_allowed(vcpu) &&
+- !kvm_cpu_has_interrupt(vcpu) &&
+- !kvm_event_needs_reinjection(vcpu) &&
+ kvm_cpu_accept_dm_intr(vcpu);
+ }
+
--- /dev/null
+From 72c3bcdcda494cbd600712a32e67702cdee60c07 Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Fri, 27 Nov 2020 08:53:52 +0100
+Subject: KVM: x86: handle !lapic_in_kernel case in kvm_cpu_*_extint
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+commit 72c3bcdcda494cbd600712a32e67702cdee60c07 upstream.
+
+Centralize handling of interrupts from the userspace APIC
+in kvm_cpu_has_extint and kvm_cpu_get_extint, since
+userspace APIC interrupts are handled more or less the
+same as ExtINTs are with split irqchip. This removes
+duplicated code from kvm_cpu_has_injectable_intr and
+kvm_cpu_has_interrupt, and makes the code more similar
+between kvm_cpu_has_{extint,interrupt} on one side
+and kvm_cpu_get_{extint,interrupt} on the other.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Filippo Sironi <sironi@amazon.de>
+Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
+Tested-by: David Woodhouse <dwmw@amazon.co.uk>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/irq.c | 83 ++++++++++++++++++++-------------------------------
+ arch/x86/kvm/lapic.c | 2 -
+ 2 files changed, 34 insertions(+), 51 deletions(-)
+
+--- a/arch/x86/kvm/irq.c
++++ b/arch/x86/kvm/irq.c
+@@ -42,27 +42,8 @@ static int pending_userspace_extint(stru
+ */
+ static int kvm_cpu_has_extint(struct kvm_vcpu *v)
+ {
+- u8 accept = kvm_apic_accept_pic_intr(v);
+-
+- if (accept) {
+- if (irqchip_split(v->kvm))
+- return pending_userspace_extint(v);
+- else
+- return v->kvm->arch.vpic->output;
+- } else
+- return 0;
+-}
+-
+-/*
+- * check if there is injectable interrupt:
+- * when virtual interrupt delivery enabled,
+- * interrupt from apic will handled by hardware,
+- * we don't need to check it here.
+- */
+-int kvm_cpu_has_injectable_intr(struct kvm_vcpu *v)
+-{
+ /*
+- * FIXME: interrupt.injected represents an interrupt that it's
++ * FIXME: interrupt.injected represents an interrupt whose
+ * side-effects have already been applied (e.g. bit from IRR
+ * already moved to ISR). Therefore, it is incorrect to rely
+ * on interrupt.injected to know if there is a pending
+@@ -75,6 +56,23 @@ int kvm_cpu_has_injectable_intr(struct k
+ if (!lapic_in_kernel(v))
+ return v->arch.interrupt.injected;
+
++ if (!kvm_apic_accept_pic_intr(v))
++ return 0;
++
++ if (irqchip_split(v->kvm))
++ return pending_userspace_extint(v);
++ else
++ return v->kvm->arch.vpic->output;
++}
++
++/*
++ * check if there is injectable interrupt:
++ * when virtual interrupt delivery enabled,
++ * interrupt from apic will handled by hardware,
++ * we don't need to check it here.
++ */
++int kvm_cpu_has_injectable_intr(struct kvm_vcpu *v)
++{
+ if (kvm_cpu_has_extint(v))
+ return 1;
+
+@@ -91,20 +89,6 @@ EXPORT_SYMBOL_GPL(kvm_cpu_has_injectable
+ */
+ int kvm_cpu_has_interrupt(struct kvm_vcpu *v)
+ {
+- /*
+- * FIXME: interrupt.injected represents an interrupt that it's
+- * side-effects have already been applied (e.g. bit from IRR
+- * already moved to ISR). Therefore, it is incorrect to rely
+- * on interrupt.injected to know if there is a pending
+- * interrupt in the user-mode LAPIC.
+- * This leads to nVMX/nSVM not be able to distinguish
+- * if it should exit from L2 to L1 on EXTERNAL_INTERRUPT on
+- * pending interrupt or should re-inject an injected
+- * interrupt.
+- */
+- if (!lapic_in_kernel(v))
+- return v->arch.interrupt.injected;
+-
+ if (kvm_cpu_has_extint(v))
+ return 1;
+
+@@ -118,16 +102,21 @@ EXPORT_SYMBOL_GPL(kvm_cpu_has_interrupt)
+ */
+ static int kvm_cpu_get_extint(struct kvm_vcpu *v)
+ {
+- if (kvm_cpu_has_extint(v)) {
+- if (irqchip_split(v->kvm)) {
+- int vector = v->arch.pending_external_vector;
+-
+- v->arch.pending_external_vector = -1;
+- return vector;
+- } else
+- return kvm_pic_read_irq(v->kvm); /* PIC */
+- } else
++ if (!kvm_cpu_has_extint(v)) {
++ WARN_ON(!lapic_in_kernel(v));
+ return -1;
++ }
++
++ if (!lapic_in_kernel(v))
++ return v->arch.interrupt.nr;
++
++ if (irqchip_split(v->kvm)) {
++ int vector = v->arch.pending_external_vector;
++
++ v->arch.pending_external_vector = -1;
++ return vector;
++ } else
++ return kvm_pic_read_irq(v->kvm); /* PIC */
+ }
+
+ /*
+@@ -135,13 +124,7 @@ static int kvm_cpu_get_extint(struct kvm
+ */
+ int kvm_cpu_get_interrupt(struct kvm_vcpu *v)
+ {
+- int vector;
+-
+- if (!lapic_in_kernel(v))
+- return v->arch.interrupt.nr;
+-
+- vector = kvm_cpu_get_extint(v);
+-
++ int vector = kvm_cpu_get_extint(v);
+ if (vector != -1)
+ return vector; /* PIC */
+
+--- a/arch/x86/kvm/lapic.c
++++ b/arch/x86/kvm/lapic.c
+@@ -2461,7 +2461,7 @@ int kvm_apic_has_interrupt(struct kvm_vc
+ struct kvm_lapic *apic = vcpu->arch.apic;
+ u32 ppr;
+
+- if (!kvm_apic_hw_enabled(apic))
++ if (!kvm_apic_present(vcpu))
+ return -1;
+
+ __apic_update_ppr(apic, &ppr);
--- /dev/null
+From cd81acc600a9684ea4b4d25a47900d38a3890eab Mon Sep 17 00:00:00 2001
+From: Nicholas Piggin <npiggin@gmail.com>
+Date: Tue, 17 Nov 2020 23:56:17 +1000
+Subject: powerpc/64s/exception: KVM Fix for host DSI being taken in HPT guest MMU context
+
+From: Nicholas Piggin <npiggin@gmail.com>
+
+commit cd81acc600a9684ea4b4d25a47900d38a3890eab upstream.
+
+Commit 2284ffea8f0c ("powerpc/64s/exception: Only test KVM in SRR
+interrupts when PR KVM is supported") removed KVM guest tests from
+interrupts that do not set HV=1, when PR-KVM is not configured.
+
+This is wrong for HV-KVM HPT guest MMIO emulation case which attempts
+to load the faulting instruction word with MSR[DR]=1 and MSR[HV]=1 with
+the guest MMU context loaded. This can cause host DSI, DSLB interrupts
+which must test for KVM guest. Restore this and add a comment.
+
+Fixes: 2284ffea8f0c ("powerpc/64s/exception: Only test KVM in SRR interrupts when PR KVM is supported")
+Cc: stable@vger.kernel.org # v5.7+
+Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20201117135617.3521127-1-npiggin@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/exceptions-64s.S | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/arch/powerpc/kernel/exceptions-64s.S
++++ b/arch/powerpc/kernel/exceptions-64s.S
+@@ -1410,6 +1410,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
+ * If none is found, do a Linux page fault. Linux page faults can happen in
+ * kernel mode due to user copy operations of course.
+ *
++ * KVM: The KVM HDSI handler may perform a load with MSR[DR]=1 in guest
++ * MMU context, which may cause a DSI in the host, which must go to the
++ * KVM handler. MSR[IR] is not enabled, so the real-mode handler will
++ * always be used regardless of AIL setting.
++ *
+ * - Radix MMU
+ * The hardware loads from the Linux page table directly, so a fault goes
+ * immediately to Linux page fault.
+@@ -1420,10 +1425,8 @@ INT_DEFINE_BEGIN(data_access)
+ IVEC=0x300
+ IDAR=1
+ IDSISR=1
+-#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
+ IKVM_SKIP=1
+ IKVM_REAL=1
+-#endif
+ INT_DEFINE_END(data_access)
+
+ EXC_REAL_BEGIN(data_access, 0x300, 0x80)
+@@ -1462,6 +1465,8 @@ ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TY
+ * ppc64_bolted_size (first segment). The kernel handler must avoid stomping
+ * on user-handler data structures.
+ *
++ * KVM: Same as 0x300, DSLB must test for KVM guest.
++ *
+ * A dedicated save area EXSLB is used (XXX: but it actually need not be
+ * these days, we could use EXGEN).
+ */
+@@ -1470,10 +1475,8 @@ INT_DEFINE_BEGIN(data_access_slb)
+ IAREA=PACA_EXSLB
+ IRECONCILE=0
+ IDAR=1
+-#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
+ IKVM_SKIP=1
+ IKVM_REAL=1
+-#endif
+ INT_DEFINE_END(data_access_slb)
+
+ EXC_REAL_BEGIN(data_access_slb, 0x380, 0x80)
--- /dev/null
+From 575cba20c421ecb6b563ae352e4e0468e4ca8b3c Mon Sep 17 00:00:00 2001
+From: Nicholas Piggin <npiggin@gmail.com>
+Date: Sat, 14 Nov 2020 21:47:43 +1000
+Subject: powerpc/64s: Fix KVM system reset handling when CONFIG_PPC_PSERIES=y
+
+From: Nicholas Piggin <npiggin@gmail.com>
+
+commit 575cba20c421ecb6b563ae352e4e0468e4ca8b3c upstream.
+
+pseries guest kernels have a FWNMI handler for SRESET and MCE NMIs,
+which is basically the same as the regular handlers for those
+interrupts.
+
+The system reset FWNMI handler did not have a KVM guest test in it,
+although it probably should have because the guest can itself run
+guests.
+
+Commit 4f50541f6703b ("powerpc/64s/exception: Move all interrupt
+handlers to new style code gen macros") convert the handler faithfully
+to avoid a KVM test with a "clever" trick to modify the IKVM_REAL
+setting to 0 when the fwnmi handler is to be generated (PPC_PSERIES=y).
+This worked when the KVM test was generated in the interrupt entry
+handlers, but a later patch moved the KVM test to the common handler,
+and the common handler macro is expanded below the fwnmi entry. This
+prevents the KVM test from being generated even for the 0x100 entry
+point as well.
+
+The result is NMI IPIs in the host kernel when a guest is running will
+use gest registers. This goes particularly badly when an HPT guest is
+running and the MMU is set to guest mode.
+
+Remove this trickery and just generate the test always.
+
+Fixes: 9600f261acaa ("powerpc/64s/exception: Move KVM test to common code")
+Cc: stable@vger.kernel.org # v5.7+
+Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20201114114743.3306283-1-npiggin@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/exceptions-64s.S | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/arch/powerpc/kernel/exceptions-64s.S
++++ b/arch/powerpc/kernel/exceptions-64s.S
+@@ -1000,8 +1000,6 @@ TRAMP_REAL_BEGIN(system_reset_idle_wake)
+ * Vectors for the FWNMI option. Share common code.
+ */
+ TRAMP_REAL_BEGIN(system_reset_fwnmi)
+- /* XXX: fwnmi guest could run a nested/PR guest, so why no test? */
+- __IKVM_REAL(system_reset)=0
+ GEN_INT_ENTRY system_reset, virt=0
+
+ #endif /* CONFIG_PPC_PSERIES */
smb3-avoid-mid-pending-list-corruption.patch
smb3-handle-error-case-during-offload-read-path.patch
cifs-fix-a-memleak-with-modefromsid.patch
+powerpc-64s-fix-kvm-system-reset-handling-when-config_ppc_pseries-y.patch
+powerpc-64s-exception-kvm-fix-for-host-dsi-being-taken-in-hpt-guest-mmu-context.patch
+kvm-ppc-book3s-hv-xive-fix-possible-oops-when-accessing-esb-page.patch
+kvm-arm64-vgic-v3-drop-the-reporting-of-gicr_typer.last-for-userspace.patch
+kvm-x86-handle-lapic_in_kernel-case-in-kvm_cpu_-_extint.patch
+kvm-x86-fix-split-irqchip-vs-interrupt-injection-window-request.patch
+iommu-vt-d-don-t-read-vccap-register-unless-it-exists.patch
+firmware-xilinx-use-hash-table-for-api-feature-check.patch
+drm-amdgpu-fix-si-uvd-firmware-validate-resume-fail.patch
+io_uring-fix-iter_bvec-check.patch
+trace-fix-potenial-dangerous-pointer.patch
+arm64-tegra-correct-the-uart-for-jetson-xavier-nx.patch
+arm64-tegra-fix-usb_vbus_en0-regulator-on-jetson-tx1.patch
+arm64-pgtable-fix-pte_accessible.patch
+arm64-pgtable-ensure-dirty-bit-is-preserved-across-pte_wrprotect.patch
+drm-amdgpu-fix-a-page-fault.patch
+drm-amdgpu-update-golden-setting-for-sienna_cichlid.patch
+drm-amd-amdgpu-fix-null-pointer-in-runtime-pm.patch
+drm-amd-display-avoid-hdcp-initialization-in-devices-without-output.patch
--- /dev/null
+From fdeb17c70c9ecae655378761accf5a26a55a33cf Mon Sep 17 00:00:00 2001
+From: Hui Su <sh_def@163.com>
+Date: Wed, 25 Nov 2020 00:52:05 +0800
+Subject: trace: fix potenial dangerous pointer
+
+From: Hui Su <sh_def@163.com>
+
+commit fdeb17c70c9ecae655378761accf5a26a55a33cf upstream.
+
+The bdi_dev_name() returns a char [64], and
+the __entry->name is a char [32].
+
+It maybe dangerous to TP_printk("%s", __entry->name)
+after the strncpy().
+
+CC: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20201124165205.GA23937@rlk
+Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Acked-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Hui Su <sh_def@163.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/trace/events/writeback.h | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/include/trace/events/writeback.h
++++ b/include/trace/events/writeback.h
+@@ -190,7 +190,7 @@ TRACE_EVENT(inode_foreign_history,
+ ),
+
+ TP_fast_assign(
+- strncpy(__entry->name, bdi_dev_name(inode_to_bdi(inode)), 32);
++ strscpy_pad(__entry->name, bdi_dev_name(inode_to_bdi(inode)), 32);
+ __entry->ino = inode->i_ino;
+ __entry->cgroup_ino = __trace_wbc_assign_cgroup(wbc);
+ __entry->history = history;
+@@ -219,7 +219,7 @@ TRACE_EVENT(inode_switch_wbs,
+ ),
+
+ TP_fast_assign(
+- strncpy(__entry->name, bdi_dev_name(old_wb->bdi), 32);
++ strscpy_pad(__entry->name, bdi_dev_name(old_wb->bdi), 32);
+ __entry->ino = inode->i_ino;
+ __entry->old_cgroup_ino = __trace_wb_assign_cgroup(old_wb);
+ __entry->new_cgroup_ino = __trace_wb_assign_cgroup(new_wb);
+@@ -252,7 +252,7 @@ TRACE_EVENT(track_foreign_dirty,
+ struct address_space *mapping = page_mapping(page);
+ struct inode *inode = mapping ? mapping->host : NULL;
+
+- strncpy(__entry->name, bdi_dev_name(wb->bdi), 32);
++ strscpy_pad(__entry->name, bdi_dev_name(wb->bdi), 32);
+ __entry->bdi_id = wb->bdi->id;
+ __entry->ino = inode ? inode->i_ino : 0;
+ __entry->memcg_id = wb->memcg_css->id;
+@@ -285,7 +285,7 @@ TRACE_EVENT(flush_foreign,
+ ),
+
+ TP_fast_assign(
+- strncpy(__entry->name, bdi_dev_name(wb->bdi), 32);
++ strscpy_pad(__entry->name, bdi_dev_name(wb->bdi), 32);
+ __entry->cgroup_ino = __trace_wb_assign_cgroup(wb);
+ __entry->frn_bdi_id = frn_bdi_id;
+ __entry->frn_memcg_id = frn_memcg_id;
projects / thirdparty / kernel / stable-queue.git / commitdiff
