From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (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 E2D1F3264DA for ; Sun, 16 Aug 2026 07:53:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786866809; cv=none; b=qMJsVaXeYeTpWGgA18rafaPJ02VMbZlF1R6IJpFIby1WCVAL8+1b2mYv9oyQ/EukVxlgf39zx240KKBAEl+6oknbDIpEypqJtDRBIx4InA6HnMR7UdgxYfdAqY+gRbmQZPDPcHU7XkQJIDpgdr6Ax/92S7D4quiQyxRi829OGwc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786866809; c=relaxed/simple; bh=qeTfM1VkMk0+4bmCCogGKKwXhXDMIKGOfZW8zAb4pmY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IhstOr1QdMc9MRgGJzrO5+kxVy2LXTKYfN5xk/68VX64R1mFcqxxhbdQw5ADHrNimEcIvfxvEDuXcNpDQdpLO0kKK8+9uaqEj+6JRRh5DgdIUlDzxzIElPdfxY0xM1nTrQKSVLkKahPbneLXntFzQsrLRBCqOPFYG9gD1zHigOY= 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=IFO6jydn; arc=none smtp.client-ip=209.85.167.41 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="IFO6jydn" Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-5b2b92065ffso2219405e87.1 for ; Sun, 16 Aug 2026 00:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786866806; x=1787471606; 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=rgiclpiITCoA8RFUuKs2akILXvflZWj5Tf2R9RMw6kg=; b=IFO6jydnJMkaXbP7dWfMZNEg0fudx7/gXJaKdpSuLK5Hof1p1PcnFFkT4CyX7zOEFv Zrob8xrw69WBmpRGwH4PaaBx0/yryHdd5bYueWsngMse2Eb9b7BWUZg8Y4C/kdgfTh2l q67/tVrV1juyl9eYKRgLvpHnQJgjrujDSAA7PI2Lhk7cC34d2C3f6zXFtt9CdqHB0BkA seHhL4NLjQ4+vtv0aSVIaS1fQfy77ynbnoI2BMdVTuktexQvC7yVPeEE+ov2HvVziAqk o52C/gpeG61R1LqP+7RJFFMCGPbV4pWlhJhLL27h4KuXrtRukg8hBZjtmVcXXce55EeU Olww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786866806; x=1787471606; 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=rgiclpiITCoA8RFUuKs2akILXvflZWj5Tf2R9RMw6kg=; b=mxhiyp2x/VqOBFEnXRdS9Yqrd+skRk4VsrHKLf80DbD0cAeLoc7fA2MxW685xuSxnM e9g6FxlMbkMloRSypbFUPmrHT1GfBfATUwvhkRhifR0KcAIckaCkosVTSsNpbLVVYEX7 Ak/HImx/4/HHHu27nBhHt+GfIaD5pv1YQZ46x1CljpWyHrJwFmo9/tVZN2HHF0Vv/5zc lIGtw7HSDLcG+pux+jGnvwruU5UGT1wTKjsh0bv7cW9R19pZ8+xpaXLO/2xPD6nQA+Cb DgjlPsSU4J2/Bnk6Na0/j70lMa1Btqbfhou2du5M5Ut1D3VjIJe8Fq3dydYmppBiq1MX GWUA== X-Forwarded-Encrypted: i=1; AHgh+RrRZG3+mENjBXnVOthRO49uB5ygu1OuqCyOH+UDpNWnlBZbZdWyq8k97AmeYaNDEotyacGlDuGC6NAc63g=@vger.kernel.org X-Gm-Message-State: AOJu0YyaGGfgOQz+dbGFL7ibzxzx5NHTffQ8lx39J0JLT5vG59YaBvbI OTpuzTDYKi2KaqLJxIPT7sjKqfr06io3UxNzmuoNm9P7phASorV0beYV X-Gm-Gg: AR+sD11fIHcOfjM2Kkr1GY41f16yBX17E9xbIXfMwjC13F0jnr/MevsYGQ2PLgYPP7o 8/m/Hc85aJ/o9R9n1SczXM8LVg24H6bKZKPcr5JMUz0Lqurm5nLoH4K7ziGb2OQ8dS3gv34JWTT cm/yVdM5RPaDdGv1i4D7yM1YtWZroZFYMZ6OTQVYMcMS6K/awB+BJlr+zx+xVVeRHBpe9HB7C3N /6d/vqCC0vygHxVZGYO8Ws0csMFQezZ41h746KK4Qt8DvmnekwsPp8EhSu/HUi8O4HgztIB+TiV atq+CJU/+8lp83ZB+jk8mXav0rqjLvLSGpI35ZR2n3VYKV9CVwzZmYnn30BC2yV7PVFrSpvH+qW Vub5F/1fVP+6fKEXtMQnMlYpuIBHnqcBiXJqAQwtPNID+LkJLLC46/wGn0PsdFGi6VspdAY08Z1 +w48DDc2zMuF4CpZwBBt06csQNPA4o1Mm5Dbj6L/uRLEZXYvyvJZMDLlmLR2ib6hT5tG1V+hIeG vbbdZ55NIRhezpyy6Vmvks/JiNl8PXCp7+buYTMTQ== X-Received: by 2002:a05:6512:ac4:b0:5b0:1ae2:8b7a with SMTP id 2adb3069b0e04-5b45918c5c5mr2824941e87.45.1786866805942; Sun, 16 Aug 2026 00:53:25 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5b458b9a8d4sm1631136e87.15.2026.08.16.00.53.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Aug 2026 00:53:25 -0700 (PDT) From: Magnus Lindholm To: davem@davemloft.net, andreas@gaisler.com Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, Magnus Lindholm , Sam Ravnborg Subject: [PATCH v2 1/3] sparc32: honour phys_base in the viking cache flush routines Date: Sun, 16 Aug 2026 09:50:15 +0200 Message-ID: <20260816075141.3489194-2-linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260816075141.3489194-1-linmag7@gmail.com> References: <20260816075141.3489194-1-linmag7@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 viking_flush_page() and viking_mxcc_flush_page() derive the physical address of the page they are asked to flush by subtracting PAGE_OFFSET from the kernel virtual address: sethi %hi(PAGE_OFFSET), %g2 sub %o0, %g2, %g3 That is only the physical address when phys_base is zero. The C side spells the same conversion __pa(), which adds phys_base, and every caller passes a kernel virtual address expecting exactly that. With a kernel loaded away from the start of RAM the two disagree by phys_base. viking_flush_page() then compares cache tags against the wrong page and flushes nothing, and viking_mxcc_flush_page() streams a page that is phys_base lower than the one it was given, so the intended lines stay dirty in the cache while unrelated ones are pushed out. The visible effect is that anything relying on a flush to make memory visible to another bus master silently keeps working from stale data. On a SPARCstation 20 this shows up as every SCSI transfer failing with a DMA error: iommu_flush_iotlb() cannot get the IOPTEs out to RAM, so the IOMMU walks stale entries and the ESP DMA faults. Add phys_base, so these agree with __pa() again. No change when phys_base is zero, which is why this went unnoticed. Signed-off-by: Magnus Lindholm Reviewed-by: Sam Ravnborg --- arch/sparc/mm/viking.S | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/sparc/mm/viking.S b/arch/sparc/mm/viking.S index 48f062de7a7f..8b4e251bbba2 100644 --- a/arch/sparc/mm/viking.S +++ b/arch/sparc/mm/viking.S @@ -38,6 +38,9 @@ sun4dsmp_flush_tlb_spin: viking_flush_page: sethi %hi(PAGE_OFFSET), %g2 sub %o0, %g2, %g3 + sethi %hi(phys_base), %g2 + ld [%g2 + %lo(phys_base)], %g2 + add %g3, %g2, %g3 ! + phys_base = physical address srl %g3, 12, %g1 ! ppage >> 12 clr %o1 ! set counter, 0 - 127 @@ -91,6 +94,9 @@ viking_flush_page: viking_mxcc_flush_page: sethi %hi(PAGE_OFFSET), %g2 sub %o0, %g2, %g3 + sethi %hi(phys_base), %g2 + ld [%g2 + %lo(phys_base)], %g2 + add %g3, %g2, %g3 ! + phys_base = physical address sub %g3, -PAGE_SIZE, %g3 ! ppage + PAGE_SIZE sethi %hi(MXCC_SRCSTREAM), %o3 ! assume %hi(MXCC_SRCSTREAM) == %hi(MXCC_DESTSTREAM) mov 0x10, %g2 ! set cacheable bit -- 2.43.0