From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9063F4398F5 for ; Mon, 24 Aug 2026 15:35:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787585750; cv=none; b=fGMKvCV/X6ZF+AbZkSDkn7R/kqWe7PFmA/ySzyJiZD2sJmnS0yzNTVMH43AxHt0D04JomIVUKZwoCnj9HQE7rZh4O3S1pQ0D5EyGQ3gLk4u37LYcr7iSBeDq70fmFIgD9NjR6Y8XttuKSNn9qispW7Y0Gw+pUKJD1pBh/EwjrQI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787585750; c=relaxed/simple; bh=rto21ZELtheuDyutE0JDdLMCZa6KNEc4S+Z9lSfsY30=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rynf2WmI7d1TFUg/U0/4iZjTEb4SqkRqitSPtLF+6r5Sos+JUeVd5KEHnQpRVSUVBJepvdCM0CyqAg+z23M/WIB9Bygq7THa1IoR56O6GcfmXsSZQkcZG6x27xxvGnCEpimZAYP8LtODr3Mwlp0p575Aw2Q/QpXKc4qd9o9fK2M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=OUWO4ZaY; arc=none smtp.client-ip=209.85.208.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OUWO4ZaY" Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-6a3e145e1bfso4823114a12.1 for ; Mon, 24 Aug 2026 08:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787585747; x=1788190547; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=7BQk+VaXHqbBwCEiciR9Pe8CWGZKMc/0gaA8PUIi/5A=; b=OUWO4ZaYQYEHR3o2174oI7oIY5UtzYh86glRbD8mzlXtg/Ijhkh1B7szh6q+oJgPAC 3yORxGmQJWGa3/JetI+/zTXpqb6EiS14wLactVAdudWA8RqejbmhDUN3XCfLJJrJHqDO FXi0nWIt4mxiyqRoUXebKyEnZaPGlDY5BhxN65vOStANP5ypo/gQc5SJ4WQ2myyIfAlp 9MADTi/EAJnD8rF6yubtAotW1yFZ5U9Xu6mHMXYlNjLghIF+JZRr5mOPfrKRIuJs1BcY 6zmLfqCRY0yZZWNlle0boZhNa6ZJ1uyDG2fs4ma6ClB10GcKNvASOmGD74H3BER8rTEo quJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787585747; x=1788190547; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=7BQk+VaXHqbBwCEiciR9Pe8CWGZKMc/0gaA8PUIi/5A=; b=QRCBqwAqp7ovVVaYl8e1siY9ae4T0ZtBGGq9WHlZkipKI2JZtfzaxtz6l+EIV8AlK9 9rDXg5dvNWJE5/lQJzvrmolVCT8oDuIZUdVKWgGE4H13gxi1g3FznlmDy1MWDE5fJoOi jk9AQjzTgslquN7kFz4SOUUyGN5qUvJOuMow41tMHlLfm7dNIilHDfoOIK8jjkFA+jxs HsWOBWlWzXN8PvKLHd7tpkD+RP2ngEg/K75HHQRQwqIt96+zZIK/3m+SbbslqbhPW68D fYVUUo5Wmoo95mHNpVBXrHTJ0imI1eKOkO2KG+5Smtkvtql7BQtDmy0EWtFWwgDJCZWO zn1Q== X-Forwarded-Encrypted: i=1; AHgh+Roy0CJLNWd4CftWN13AifrxlPIvXO2fkfYJW70NYUIe2CZTegJdS8Qy75MsVcW/e+zXJG2yjGhqWJsMOeo=@vger.kernel.org X-Gm-Message-State: AFuF++mnvV22IIWB+5slWjWcsOpSan+7J3lgJa2eIKGbULjRof1gw9aD YyLP0Z3PN7QxzYByl6Ptub1sRKccP8CCRZIJjFqNBhoFRpRNRfMUs213 X-Gm-Gg: AR+sD10LZtjdanAZUIIfG4S9JeWKIgkQgrVUJZ5JwxQdS0TZML/+RQEu85Ck2iJ0q3o +sXxdFM4CJOEWv2xEG7eYZvq+AsgObQicM9yUY+AVxBAII51KM+R6KUZ0V44oETY6XbO6OIyMw/ CqFni8YAFgas1Ted1MWYJf9x7VEBfX7/S/NlRWvdH10T9fMEhO0OpgGF+xPtZPQUv68/ioCEhMN zMP2y0uw+32q9HXfr8kRLWD0Sm/AkMUuT/sj4wB9BH+5NfjzY1m/LiYHCZM49DQ4iD5i1yJykJB agjDFF5qFjvSf+AR4EyFxUWa0HN58sw7TKV5+aReYBSdZQgRffHUviq2xAovSq037VO8CoBZFG0 +kBmfKeeRhsf70tpOPpLYDkhGUePwGmuXJbpw+5BEAzhMG9M3QUVWJDR5VGwx5GNnbrmPgcGnUM UCUbjbqw/HVCz01cRvDOTgC8BY3uNozpNQO9EKp/PiGWMJwEDAjiJCKJHL0KnRLuh2Od/Q5zjyb MAG8YF5a34Unf1HJerP0OwjFpKyh+gZtNjdufG3TMIeGi4LVKXTzNM7oUKke9/iW4cFXs+h2upg baM4KFBc0rcCWr9AJQ3Zh/QNcHHTIuo= X-Received: by 2002:a17:907:3d0a:b0:c20:74db:50c7 with SMTP id a640c23a62f3a-c246a697ac4mr3198662366b.13.1787585746578; Mon, 24 Aug 2026 08:35:46 -0700 (PDT) Received: from horsehead.monster-haddock.ts.net (p548c9e2a.dip0.t-ipconnect.de. [84.140.158.42]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c249606a8edsm1298978666b.6.2026.08.24.08.35.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Aug 2026 08:35:45 -0700 (PDT) From: Denis Pisarev To: amd-gfx@lists.freedesktop.org Cc: alexander.deucher@amd.com, christian.koenig@amd.com, mario.limonciello@amd.com, ionut_n2001@yahoo.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Denis Pisarev Subject: [RFC PATCH v3 0/1] drm/amdgpu: MMIO TLB invalidation fallback when KIQ is wedged after S4 resume Date: Mon, 24 Aug 2026 17:35:41 +0200 Message-ID: <20260824153542.491012-1-pisarevden@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260819185349.29407-1-pisarevden@gmail.com> References: <20260819185349.29407-1-pisarevden@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi, v3 addresses the two findings from the sashiko-bot review of v2. Failure data and trigger isolation are unchanged (bugzilla 219492): S4 resume on Cezanne (gmc_v9, GFXOFF) wedges KIQ TLB flushes at 80-140/hour for 9+ hours with sched.ready true throughout; holding GFXOFF off across the S4 cycle produces zero errors. 1. [High] "VFs and interrupt contexts silently drop TLB flushes once the threshold is reached" - correct, and fixed. In v3 the latch only reroutes bare metal process context to MMIO. VFs and IRQ contexts keep submitting to KIQ exactly as before this patch, with per-failure logging, because they have no MMIO alternative; there is no longer any code path that drops a flush without attempting and logging. 2. [High] "KIQ and MMIO race on the same invalidation engine if KIQ recovers" - this remains the documented open question; no code change in v3. Our analysis: once latched, this path submits no new KIQ commands, so the exposure is limited to already-queued stale commands and the recovery transition window. The engine serializes requests internally, so the realistic worst case is a lost flush request caught by the existing ACK timeout ("Timeout waiting for VM flush ACK!"), not silent state corruption. If maintainers consider a fence necessary (or a dedicated invalidate engine for the MMIO path), guidance on the preferred mechanism would be welcome. Full patch history: v1 (initial fallback+counter), v2 (GFXOFF hold, per-instance counter, irqsave, VF/IRQ restrictions, MES error propagation) - all from bot review; v3 (this one) fixes the VF/IRQ drop regression the bot found in v2. Also still open from the cover letters: the alternative direction of fixing the S4 resume ordering itself (RLC/ME vs GFXOFF) instead of a runtime fallback. Happy to run tracing on the affected hardware. Patch 1/1 follows. Denis Pisarev Denis Pisarev (1): drm/amdgpu: fall back to MMIO TLB invalidation when KIQ is unresponsive drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 18 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 2 +- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 123 +++++++++++++++++++----- 5 files changed, 114 insertions(+), 33 deletions(-) -- 2.55.0