aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/bin/stackcollapse-record
diff options
context:
space:
mode:
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-record')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2026-02-02 15:13:43 +0000
rm/amdkfd: Separate pinned BOs destruction from general routineLang Yu5-37/+118 Currently, all kfd BOs use same destruction routine. But pinned BOs are not unpinned properly. Separate them from general routine. v2 (Felix): Add safeguard to prevent user space from freeing signal BO. Kunmap signal BO in the event of setting event page error. Just kunmap signal BO to avoid duplicating the code. Signed-off-by: Lang Yu <lang.yu@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-28drm/amdkfd: restore userptr ignore bad address errorPhilip Yang2-10/+20 The userptr can be unmapped by application and still registered to driver, restore userptr work return user pages will get -EFAULT bad address error. Pretend this error as succeed. GPU access this userptr will have VM fault later, it is better than application soft hangs with stalled user mode queues. v2: squash in warning fix (Alex) Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-28drm/amdgpu: Add kernel parameter support for ignoring bad page thresholdKent Russell3-5/+13 When a GPU hits the bad_page_threshold, it will not be initialized by the amdgpu driver. This means that the table cannot be cleared, nor can information gathering be performed (getting serial number, BDF, etc). If the bad_page_threshold kernel parameter is set to -2, continue to initialize the GPU, while printing a warning to dmesg that this action has been done v2: squash in Luben's fix to restore RAS info reporting Cc: Luben Tuikov <luben.tuikov@amd.com> Cc: Mukul Joshi <Mukul.Joshi@amd.com> Signed-off-by: Kent Russell <kent.russell@amd.com> Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Luben Tuikov <luben.tuikov@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-28drm/amdgpu: Warn when bad pages approaches 90% thresholdKent Russell1-0/+7 dmesg doesn't warn when the number of bad pages approaches the threshold for page retirement. WARN when the number of bad pages is at 90% or greater for easier checks and planning, instead of waiting until the GPU is full of bad pages. Cc: Luben Tuikov <luben.tuikov@amd.com> Cc: Mukul Joshi <Mukul.Joshi@amd.com> Signed-off-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Luben Tuikov <luben.tuikov@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-28drm: Add R10 and R12 FourCCLaurent Pinchart2-0/+8 Add FourCCs for 10- and 12-bit red formats with padding to 16 bits. They correspond to the V4L2 10- and 12-bit greyscale (V4L2_PIX_FMT_Y10 and V4L2_PIX_FMT_Y12) formats, as well as the Bayer formats with the same bit depth (V4L2_PIX_FMT_SBGGR{10,12} and all other Bayer pattern permutations). These formats are not used by any kernel driver at this point, but need to be exposed to applications by libcamera, which uses DRM FourCCs for pixel formats. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211027233140.12268-1-laurent.pinchart@ideasonboard.com 2021-10-27drm/amdgpu/display: fix build when CONFIG_DRM_AMD_DC_DCN is not setAlex Deucher2-2/+4 Need to guard some things with CONFIG_DRM_AMD_DC_DCN. Fixes: 41724ea273cdda ("drm/amd/display: Add DP 2.0 MST DM Support") Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Dave Airlie <airlied@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211027223914.1776061-1-alexander.deucher@amd.com 2021-10-26drm/msm/dp: fix missing #includeArnd Bergmann1-0/+1 Some randconfig builds fail when drm/drm_bridge.h is not included implicitly in this file: drivers/gpu/drm/msm/dp/dp_parser.c:279:25: error: implicit declaration of function 'devm_drm_panel_bridge_add' [-Werror,-Wimplicit-function-declaration] parser->panel_bridge = devm_drm_panel_bridge_add(dev, panel); Fixes: 4b296d15b355 ("drm/msm/dp: Allow attaching a drm_panel") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20211026083254.3396322-1-arnd@kernel.org Signed-off-by: Rob Clark <robdclark@chromium.org> 2021-10-26drm/msm/dpu: Remove commit and its uses in dpu_crtc_set_crc_source()Nathan Chancellor1-3/+0 Clang warns: drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:162:6: error: variable 'commit' is uninitialized when used here [-Werror,-Wuninitialized] if (commit) ^~~~~~ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:106:32: note: initialize the variable 'commit' to silence this warning struct drm_crtc_commit *commit; ^ = NULL 1 error generated. The assignment and use of commit in the main body of dpu_crtc_set_crc_source() were removed from v1 to v2 but the call to drm_crtc_commit_put() at the end was not. Do that now so there is no more warning. Fixes: 78d9b458cc21 ("drm/msm/dpu: Add CRC support for DPU") Link: https://github.com/ClangBuiltLinux/linux/issues/1493 Reported-by: "kernelci.org bot" <bot@kernelci.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211026142435.3606413-1-nathan@kernel.org Signed-off-by: Rob Clark <robdclark@chromium.org> 2021-10-25drm/amd/display: Add DP 2.0 MST DM SupportBhawanpreet Lakha3-1/+36 [Why] Add DP2 MST and debugfs support [How] Update the slot info based on the link encoding format Reviewed-by: "Lin, Wayne" <Wayne.Lin@amd.com> Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-5-lyude@redhat.com 2021-10-25drm/amd/display: Add DP 2.0 MST DC SupportFangzhi Zuo5-0/+345 [Why] configure/call DC interface for DP2 mst support. This is needed to make DP2 mst work. [How] - add encoding type, logging, mst update/reduce payload functions Use the link encoding to determine the DP type (1.4 or 2.0) and add a flag to dc_stream_update to determine whether to increase/reduce payloads. v2: * add DP_UNKNOWN_ENCODING handling Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Reviewed-by: "Lin, Wayne" <Wayne.Lin@amd.com> Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-4-lyude@redhat.com 2021-10-25drm: Update MST First Link Slot Information Based on Encoding FormatBhawanpreet Lakha6-11/+42 8b/10b encoding format requires to reserve the first slot for recording metadata. Real data transmission starts from the second slot, with a total of available 63 slots available. In 128b/132b encoding format, metadata is transmitted separately in LLCP packet before MTP. Real data transmission starts from the first slot, with a total of 64 slots available. v2: * Move total/start slots to mst_state, and copy it to mst_mgr in atomic_check v3: * Only keep the slot info on the mst_state * add a start_slot parameter to the payload function, to facilitate non atomic drivers (this is a temporary workaround and should be removed when we are moving out the non atomic driver helpers) v4: *fixed typo and formatting v5: (no functional changes) * Fixed formatting in drm_dp_mst_update_slots() * Reference mst_state instead of mst_state->mgr for debugging info Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> [v5 nitpicks] Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-3-lyude@redhat.com 2021-10-25drm: Remove slot checks in dp mst topology during commitBhawanpreet Lakha1-5/+1 This code path is used during commit, and we dont expect things to fail during the commit stage, so remove this. Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-2-lyude@redhat.com 2021-10-25Linux 5.15-rc7v5.15-rc7Linus Torvalds1-1/+1 2021-10-25secretmem: Prevent secretmem_users from wrapping to zeroMatthew Wilcox (Oracle)1-0/+2 Commit 110860541f44 ("mm/secretmem: use refcount_t instead of atomic_t") attempted to fix the problem of secretmem_users wrapping to zero and allowing suspend once again. But it was reverted in commit 87066fdd2e30 ("Revert 'mm/secretmem: use refcount_t instead of atomic_t'") because of the problems it caused - a refcount_t was not semantically the right type to use. Instead prevent secretmem_users from wrapping to zero by forbidding new users if the number of users has wrapped from positive to negative. This stops a long way short of reaching the necessary 4 billion users where it wraps to zero again, so there's no need to be clever with special anti-wrap types or checking the return value from atomic_inc(). Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Jordy Zomer <jordy@pwning.systems> Cc: Kees Cook <keescook@chromium.org>, Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2021-10-25spi: Fix tegra20 build with CONFIG_PM=n once againLinus Torvalds1-1/+1 Commit efafec27c565 ("spi: Fix tegra20 build with CONFIG_PM=n") already fixed the build without PM support once. There was an alternative fix by Guenter in commit 2bab94090b01 ("spi: tegra20-slink: Declare runtime suspend and resume functions conditionally"), and Mark then merged the two correctly in ffb1e76f4f32 ("Merge tag 'v5.15-rc2' into spi-5.15"). But for some inexplicable reason, Mark then merged things _again_ in commit 59c4e190b10c ("Merge tag 'v5.15-rc3' into spi-5.15"), and screwed things up at that point, and the __maybe_unused attribute on tegra_slink_runtime_resume() went missing. Reinstate it, so that alpha (and other architectures without PM support) builds cleanly again. Btw, this is another prime example of how random back-merges are not good. Just don't do them. Subsystem developers should not merge my tree in any normal circumstances. Both of those merge commits pointed to above are bad: even the one that got the merge result right doesn't even mention _why_ it was done, and the one that got it wrong is obviously broken. Reported-by: Guenter Roeck <linux@roeck-us.net> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2021-10-25ARM: 9148/1: handle CONFIG_CPU_ENDIAN_BE32 in arch/arm/kernel/head.SLABBE Corentin1-2/+2 My intel-ixp42x-welltech-epbx100 no longer boot since 4.14. This is due to commit 463dbba4d189 ("ARM: 9104/2: Fix Keystone 2 kernel mapping regression") which forgot to handle CONFIG_CPU_ENDIAN_BE32 as possible BE config. Suggested-by: Krzysztof Hałasa <khalasa@piap.pl> Fixes: 463dbba4d189 ("ARM: 9104/2: Fix Keystone 2 kernel mapping regression") Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> 2021-10-25ata: sata_mv: Fix the error handling of mv_chip_id()Zheyu Ma1-2/+2 mv_init_host() propagates the value returned by mv_chip_id() which in turn gets propagated by mv_pci_init_one() and hits local_pci_probe(). During the process of driver probing, the probe function should return < 0 for failure, otherwise, the kernel will treat value > 0 as success. Since this is a bug rather than a recoverable runtime error we should use dev_alert() instead of dev_err(). Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> 2021-10-24Revert "mm/secretmem: use refcount_t instead of atomic_t"Linus Torvalds1-5/+4 This reverts commit 110860541f443f950c1274f217a1a3e298670a33. Converting the "secretmem_users" counter to a refcount is incorrect, because a refcount is special in zero and can't just be incremented (but a count of users is not, and "no users" is actually perfectly valid and not a sign of a free'd resource). Reported-by: syzbot+75639e6a0331cd61d3e2@syzkaller.appspotmail.com Cc: Jordy Zomer <jordy@pwning.systems> Cc: Kees Cook <keescook@chromium.org>, Cc: Jordy Zomer <jordy@jordyzomer.github.io> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2021-10-23drm/msm/dpu: Remove dynamic allocation from atomic contextRob Clark1-11/+5 We know the upper bound on # of mixers (ie. two), so lets just allocate this on the stack. Fixes: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:201 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/0 INFO: lockdep is turned off. irq event stamp: 43642 hardirqs last enabled at (43641): [<ffffffe24dd276bc>] cpuidle_enter_state+0x158/0x25c hardirqs last disabled at (43642): [<ffffffe24dfff450>] enter_el1_irq_or_nmi+0x10/0x1c softirqs last enabled at (43620): [<ffffffe24d4103fc>] __do_softirq+0x1e4/0x464 softirqs last disabled at (43615): [<ffffffe24d48bd90>] __irq_exit_rcu+0x104/0x150 CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.15.0-rc3-debug+ #105 Hardware name: Google Lazor (rev1 - 2) with LTE (DT) Call trace: dump_backtrace+0x0/0x18c show_stack+0x24/0x30 dump_stack_lvl+0xa0/0xd4 dump_stack+0x18/0x34 ___might_sleep+0x1e0/0x1f0 __might_sleep+0x78/0x8c slab_pre_alloc_hook.constprop.0+0x48/0x6c __kmalloc+0xc8/0x21c dpu_crtc_vblank_callback+0x158/0x1f8 dpu_encoder_vblank_callback+0x70/0xc4 dpu_encoder_phys_vid_vblank_irq+0x50/0x12c dpu_core_irq+0x1bc/0x1d0 dpu_irq+0x1c/0x28 msm_irq+0x34/0x40 __handle_irq_event_percpu+0x15c/0x308 handle_irq_event_percpu+0x3c/0x90 handle_irq_event+0x54/0x98 handle_level_irq+0xa0/0xd0 handle_irq_desc+0x2c/0x44 generic_handle_domain_irq+0x28/0x34 dpu_mdss_irq+0x90/0xe8 handle_irq_desc+0x2c/0x44 handle_domain_irq+0x54/0x80 gic_handle_irq+0xd4/0x148 call_on_irq_stack+0x2c/0x54 do_interrupt_handler+0x4c/0x64 el1_interrupt+0x30/0xd0 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x78/0x7c arch_local_irq_enable+0xc/0x14 cpuidle_enter+0x44/0x5c do_idle+0x248/0x268 cpu_startup_entry+0x30/0x48 rest_init+0x188/0x19c arch_call_rest_init+0x1c/0x28 start_kernel+0x704/0x744 __primary_switched+0xc0/0xc8 Fixes: 78d9b458cc21 ("drm/msm/dpu: Add CRC support for DPU") Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211023160016.3322052-2-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org> 2021-10-23drm/msm/dpu: Remove impossible NULL checkRob Clark1-5/+0 Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jessica Zhang <jesszhan@codeaurora.org> Link: https://lore.kernel.org/r/20211023160016.3322052-1-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org> 2021-10-22hyperv/vmbus: include linux/bitops.hArnd Bergmann1-0/+1 On arm64 randconfig builds, hyperv sometimes fails with this error: In file included from drivers/hv/hv_trace.c:3: In file included from drivers/hv/hyperv_vmbus.h:16: In file included from arch/arm64/include/asm/sync_bitops.h:5: arch/arm64/include/asm/bitops.h:11:2: error: only <linux/bitops.h> can be included directly In file included from include/asm-generic/bitops/hweight.h:5: include/asm-generic/bitops/arch_hweight.h:9:9: error: implicit declaration of function '__sw_hweight32' [-Werror,-Wimplicit-function-declaration] include/asm-generic/bitops/atomic.h:17:7: error: implicit declaration of function 'BIT_WORD' [-Werror,-Wimplicit-function-declaration] Include the correct header first. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20211018131929.2260087-1-arnd@kernel.org Signed-off-by: Wei Liu <wei.liu@kernel.org> 2021-10-22amd/display: remove ChromeOS workaroundSimon Ser1-51/+0 This reverts commits ddab8bd788f5 ("drm/amd/display: Fix two cursor duplication when using overlay") and e7d9560aeae5 ("Revert "drm/amd/display: Fix overlay validation by considering cursors""). tl;dr ChromeOS uses the atomic interface for everything except the cursor. This is incorrect and forces amdgpu to disable some hardware features. Let's revert the ChromeOS-specific workaround in mainline and allow the Chrome team to keep it internally in their own tree. See [1] for more details. This patch is an alternative to [2], which added ChromeOS detection. [1]: https://lore.kernel.org/amd-gfx/JIQ_93_cHcshiIDsrMU1huBzx9P9LVQxucx8hQArpQu7Wk5DrCl_vTXj_Q20m_L-8C8A5dSpNcSJ8ehfcCrsQpfB5QG_Spn14EYkH9chtg0=@emersion.fr/ [2]: https://lore.kernel.org/amd-gfx/20211011151609.452132-1-contact@emersion.fr/ Signed-off-by: Simon Ser <contact@emersion.fr> 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> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Sean Paul <seanpaul@chromium.org> Fixes: ddab8bd788f5 ("drm/amd/display: Fix two cursor duplication when using overlay") Fixes: e7d9560aeae5 ("Revert "drm/amd/display: Fix overlay validation by considering cursors"") Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-22drm/amd/pm: Disable fan control if not supportedLijo Lazar1-0/+14 On arcturus, not all platforms use PMFW based fan control. On such ASICs fan control by PMFW will be disabled in PPTable. Disable hwmon knobs for fan control also as it is not possible to report or control fan speed on such platforms through driver. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-22drm/amdgpu/nbio7.4: use original HDP_FLUSH bitsAlex Deucher3-1/+20 The extended bits were not available for use on vega20 and presumably arcturus as well. Fixes: a0f9f854666834 ("drm/amdgpu/nbio7.4: don't use GPU_HDP_FLUSH bit 12") Reviewed-and-tested-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-22drm/amdgpu/smu11.0: add missing IP version checkAlex Deucher1-0/+1 Add missing check in smu_v11_0_init_display_count(), Fixes: af3b89d3a639d5 ("drm/amdgpu/smu11.0: convert to IP version checking") Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-22KVM: SEV-ES: go over the sev_pio_data buffer in multiple passes if neededPaolo Bonzini2-16/+57 The PIO scratch buffer is larger than a single page, and therefore it is not possible to copy it in a single step to vcpu->arch/pio_data. Bound each call to emulator_pio_in/out to a single page; keep track of how many I/O operations are left in vcpu->arch.sev_pio_count, so that the operation can be restarted in the complete_userspace_io callback. For OUT, this means that the previous kvm_sev_es_outs implementation becomes an iterator of the loop, and we can consume the sev_pio_data buffer before leaving to userspace. For IN, instead, consuming the buffer and decreasing sev_pio_count is always done in the complete_userspace_io callback, because that is when the memcpy is done into sev_pio_data. Cc: stable@vger.kernel.org Fixes: 7ed9abfe8e9f ("KVM: SVM: Support string IO operations for an SEV-ES guest") Reported-by: Felix Wilhelm <fwilhelm@google.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 2021-10-22KVM: SEV-ES: keep INS functions togetherPaolo Bonzini1-9/+9 Make the diff a little nicer when we actually get to fixing the bug. No functional change intended. Cc: stable@vger.kernel.org Fixes: 7ed9abfe8e9f ("KVM: SVM: Support string IO operations for an SEV-ES guest") Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 2021-10-22KVM: x86: remove unnecessary arguments from complete_emulator_pio_inPaolo Bonzini1-5/+6 complete_emulator_pio_in can expect that vcpu->arch.pio has been filled in, and therefore does not need the size and count arguments. This makes things nicer when the function is called directly from a complete_userspace_io callback. No functional change intended. Cc: stable@vger.kernel.org Fixes: 7ed9abfe8e9f ("KVM: SVM: Support string IO operations for an SEV-ES guest") Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 2021-10-22KVM: x86: split the two parts of emulator_pio_inPaolo Bonzini1-17/+28 emulator_pio_in handles both the case where the data is pending in vcpu->arch.pio.count, and the case where I/O has to be done via either an in-kernel device or a userspace exit. For SEV-ES we would like to split these, to identify clearly the moment at which the sev_pio_data is consumed. To this end, create two different functions: __emulator_pio_in fills in vcpu->arch.pio.count, while complete_emulator_pio_in clears it and releases vcpu->arch.pio.data. Because this patch has to be backported, things are left a bit messy. kernel_pio() operates on vcpu->arch.pio, which leads to emulator_pio_in() having with two calls to complete_emulator_pio_in(). It will be fixed in the next release. While at it, remove the unused void* val argument of emulator_pio_in_out. The function currently hardcodes vcpu->arch.pio_data as the source/destination buffer, which sucks but will be fixed after the more severe SEV-ES buffer overflow. No functional change intended. Cc: stable@vger.kernel.org Fixes: 7ed9abfe8e9f ("KVM: SVM: Support string IO operations for an SEV-ES guest") Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 2021-10-22KVM: SEV-ES: clean up kvm_sev_es_ins/outsPaolo Bonzini1-16/+15 A few very small cleanups to the functions, smushed together because the patch is already very small like this: - inline emulator_pio_in_emulated and emulator_pio_out_emulated, since we already have the vCPU - remove the data argument and pull setting vcpu->arch.sev_pio_data into the caller - remove unnecessary clearing of vcpu->arch.pio.count when emulation is done by the kernel (and therefore vcpu->arch.pio.count is already clear on exit from emulator_pio_in and emulator_pio_out). No functional change intended. Cc: stable@vger.kernel.org Fixes: 7ed9abfe8e9f ("KVM: SVM: Support string IO operations for an SEV-ES guest") Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 2021-10-22KVM: x86: leave vcpu->arch.pio.count alone in emulator_pio_in_outPaolo Bonzini1-4/+9 Currently emulator_pio_in clears vcpu->arch.pio.count twice if emulator_pio_in_out performs kernel PIO. Move the clear into emulator_pio_out where it is actually necessary. No functional change intended. Cc: stable@vger.kernel.org Fixes: 7ed9abfe8e9f ("KVM: SVM: Support string IO operations for an SEV-ES guest") Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 2021-10-22KVM: SEV-ES: rename guest_ins_data to sev_pio_dataPaolo Bonzini2-3/+3 We will be using this field for OUTS emulation as well, in case the data that is pushed via OUTS spans more than one page. In that case, there will be a need to save the data pointer across exits to userspace. So, change the name to something that refers to any kind of PIO. Also spell out what it is used for, namely SEV-ES. No functional change intended. Cc: stable@vger.kernel.org Fixes: 7ed9abfe8e9f ("KVM: SVM: Support string IO operations for an SEV-ES guest") Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 2021-10-21memblock: exclude MEMBLOCK_NOMAP regions from kmemleakMike Rapoport3-0/+8 Vladimir Zapolskiy reports: Commit a7259df76702 ("memblock: make memblock_find_in_range method private") invokes a kernel panic while running kmemleak on OF platforms with nomaped regions: Unable to handle kernel paging request at virtual address fff000021e00000 [...] scan_block+0x64/0x170 scan_gray_list+0xe8/0x17c kmemleak_scan+0x270/0x514 kmemleak_write+0x34c/0x4ac The memory allocated from memblock is registered with kmemleak, but if it is marked MEMBLOCK_NOMAP it won't have linear map entries so an attempt to scan such areas will fault. Ideally, memblock_mark_nomap() would inform kmemleak to ignore MEMBLOCK_NOMAP memory, but it can be called before kmemleak interfaces operating on physical addresses can use __va() conversion. Make sure that functions that mark allocated memory as MEMBLOCK_NOMAP take care of informing kmemleak to ignore such memory. Link: https://lore.kernel.org/all/8ade5174-b143-d621-8c8e-dc6a1898c6fb@linaro.org Link: https://lore.kernel.org/all/c30ff0a2-d196-c50d-22f0-bd50696b1205@quicinc.com Fixes: a7259df76702 ("memblock: make memblock_find_in_range method private") Reported-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Tested-by: Qian Cai <quic_qiancai@quicinc.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2021-10-21Revert "memblock: exclude NOMAP regions from kmemleak"Mike Rapoport1-6/+1 Commit 6e44bd6d34d6 ("memblock: exclude NOMAP regions from kmemleak") breaks boot on EFI systems with kmemleak and VM_DEBUG enabled: efi: Processing EFI memory map: efi: 0x000090000000-0x000091ffffff [Conventional| | | | | | | | | | |WB|WT|WC|UC] efi: 0x000092000000-0x0000928fffff [Runtime Data|RUN| | | | | | | | | |WB|WT|WC|UC] ------------[ cut here ]------------ kernel BUG at mm/kmemleak.c:1140! Internal error: Oops - BUG: 0 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0-rc6-next-20211019+ #104 pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kmemleak_free_part_phys+0x64/0x8c lr : kmemleak_free_part_phys+0x38/0x8c sp : ffff800011eafbc0 x29: ffff800011eafbc0 x28: 1fffff7fffb41c0d x27: fffffbfffda0e068 x26: 0000000092000000 x25: 1ffff000023d5f94 x24: ffff800011ed84d0 x23: ffff800011ed84c0 x22: ffff800011ed83d8 x21: 0000000000900000 x20: ffff800011782000 x19: 0000000092000000 x18: ffff800011ee0730 x17: 0000000000000000 x16: 0000000000000000 x15: 1ffff0000233252c x14: ffff800019a905a0 x13: 0000000000000001 x12: ffff7000023d5ed7 x11: 1ffff000023d5ed6 x10: ffff7000023d5ed6 x9 : dfff800000000000 x8 : ffff800011eaf6b7 x7 : 0000000000000001 x6 : ffff800011eaf6b0 x5 : 00008ffffdc2a12a x4 : ffff7000023d5ed7 x3 : 1ffff000023dbf99 x2 : 1ffff000022f0463 x1 : 0000000000000000 x0 : ffffffffffffffff Call trace: kmemleak_free_part_phys+0x64/0x8c memblock_mark_nomap+0x5c/0x78 reserve_regions+0x294/0x33c efi_init+0x2d0/0x490 setup_arch+0x80/0x138 start_kernel+0xa0/0x3ec __primary_switched+0xc0/0xc8 Code: 34000041 97d526e7 f9418e80 36000040 (d4210000) random: get_random_bytes called from print_oops_end_marker+0x34/0x80 with crng_init=0 ---[ end trace 0000000000000000 ]--- The crash happens because kmemleak_free_part_phys() tries to use __va() before memstart_addr is initialized and this triggers a VM_BUG_ON() in arch/arm64/include/asm/memory.h: Revert 6e44bd6d34d6 ("memblock: exclude NOMAP regions from kmemleak"), the issue it is fixing will be fixed differently. Reported-by: Qian Cai <quic_qiancai@quicinc.com> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2021-10-21drm/amdgpu/swsmu: handle VCN harvesting for VCN SMU setupAlex Deucher1-71/+24 Check if VCN instances are harvested when controlling VCN power gating and setting up VCN clocks. Fixes: 1b592d00b4ac83 ("drm/amdgpu/vcn: remove manual instance setting") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1743 Reviewed-and-tested-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-21drm/amdgpu: Workaround harvesting info for some navy flounder boardsAlex Deucher1-0/+4 Some navy flounder boards do not properly mark harvested VCN instances. Fix that here. v2: use IP versions Fixes: 1b592d00b4ac83 ("drm/amdgpu/vcn: remove manual instance setting") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1743 Reviewed-and-tested-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-21drm/amdgpu/vcn3.0: remove intermediate variableAlex Deucher1-9/+2 No need to use the id variable, just use the constant plus instance offset directly. Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-21drm/amdgpu/vcn2.0: remove intermediate variableAlex Deucher1-3/+2 No need to use the tmp variable, just use the constant directly. Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-21drm/amdgpu: Consolidate VCN firmware setup codeAlex Deucher6-50/+33 Roughly the same code was present in all VCN versions. Consolidate it into a single function. v2: use AMDGPU_UCODE_ID_VCN + i, check if num_inst >= 2 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Reviewed-by: James Zhu <James.Zhu@amd.com> 2021-10-21drm/amdgpu/vcn3.0: handle harvesting in firmware setupAlex Deucher1-8/+8 Only enable firmware for the instance that is enabled. v2: use AMDGPU_UCODE_ID_VCN + i Fixes: 1b592d00b4ac83 ("drm/amdgpu/vcn: remove manual instance setting") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1743 Reviewed-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-21drm/amdkfd: debug message to count successfully migrated pagesPhilip Yang1-0/+21 Not all migrate.cpages returned from migrate_vma_setup can be migrated, for example non anonymous page, or out of device memory. So after migrate_vma_pages returns, add debug message to count pages are successfully migrated which has MIGRATE_PFN_VALID and MIGRATE_PFN_MIGRATE flag set. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-21drm/amdkfd: clarify the origin of cpages returned by migration functionsPhilip Yang1-21/+22 cpages is only updated by migrate_vma_setup. So capture its value at that point to clarify the significance of the number. The next patch will add counting of actually migrated pages after migrate_vma_pages for debug purposes. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-21drm/amd/amdgpu: add dummy_page_addr to sriov msgJingwen Chen2-1/+3 Add dummy_page_addr to sriov msg for host driver to set GCVM_L2_PROTECTION_DEFAULT_ADDR* registers correctly. v2: should update vf2pf msg instead Signed-off-by: Jingwen Chen <Jingwen.Chen2@amd.com> Reviewed-by: Horace Chen <horace.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-21drm/amdgpu: remove grbm cam index/data operations for gfx v10Huang Rui1-22/+0 PSP firmware will be responsible for applying the GRBM CAM remapping in the production. And the GRBM_CAM_INDEX / GRBM_CAM_DATA registers will be protected by PSP under security policy. So remove it according to the new security policy. Signed-off-by: Huang Rui <ray.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-21drm/amd/pm: Enable GPU metrics for One VF modeVignesh Chander1-7/+7 Enable GPU metrics feature in one VF mode. These are only possible in one VF mode because the VF is dedicated in that case. Signed-off-by: Vignesh Chander <Vignesh.Chander@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2021-10-21drm/msm/dsi: fix wrong type in msm_dsi_hostJessica Zhang1-12/+12 Change byte_clk_rate, pixel_clk_rate, esc_clk_rate, and src_clk_rate from u32 to unsigned long, since clk_get_rate() returns an unsigned long. Fixes: a6bcddbc2ee1 ("drm/msm: dsi: Handle dual-channel for 6G as well") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jessica Zhang <jesszhan@codeaurora.org> Link: https://lore.kernel.org/r/20211020183438.32263-1-jesszhan@codeaurora.org Signed-off-by: Rob Clark <robdclark@chromium.org> 2021-10-21drm/msm: Fix potential NULL dereference in DPU SSPPJessica Zhang1-3/+5 Move initialization of sblk in _sspp_subblk_offset() after NULL check to avoid potential NULL pointer dereference. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jessica Zhang <jesszhan@codeaurora.org> Link: https://lore.kernel.org/r/20211020175733.3379-1-jesszhan@codeaurora.org Signed-off-by: Rob Clark <robdclark@chromium.org>