From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FDE9C71148 for ; Fri, 13 Jun 2025 17:14:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E364B6B008A; Fri, 13 Jun 2025 13:14:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE7F36B008C; Fri, 13 Jun 2025 13:14:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D24F36B0092; Fri, 13 Jun 2025 13:14:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B3AF16B008A for ; Fri, 13 Jun 2025 13:14:42 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6FAE9C0DA3 for ; Fri, 13 Jun 2025 17:14:42 +0000 (UTC) X-FDA: 83551026804.19.47F30DD Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf07.hostedemail.com (Postfix) with ESMTP id 6CAB74000C for ; Fri, 13 Jun 2025 17:14:40 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749834880; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dHhT/9vCRjUN3YTO0u3ems5D9aA0HtvNCeJ9uyFGQTU=; b=7X+n0uqY63Lr+OBbUZnQ+lKQQHfDy+apIHj2uSOd8YIgPjKQOLwAcMrYUzquq3X3ZAGQ5l 5Bi7j5aJ6QbDo5UjP/046HEn/dTMt3mEQY0e+3YEDJ8kc6Ijy/ldLBnj/YjlvAAQllq4X2 707FK8QSxgAdDWdQ0Eqp8/agSEbQWco= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749834880; a=rsa-sha256; cv=none; b=Tvuw04/MXo0XDLn8bFl+YhNQ6Jeur8cQNY2cUR8A5atajPUhC4jCrihTfx6esWnAsngkHI xAGFNntalzALZjCQ/TeuRXDsbHENa+07bRsCE1rNUMc56x6m8rUAkXxhJXfCY427UyXNLC gTSLpAtg38ThIHRbgPuzN2dQwMLnS4g= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4bJmDQ068yz6L4wf; Sat, 14 Jun 2025 01:12:38 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id C596214033C; Sat, 14 Jun 2025 01:14:36 +0800 (CST) Received: from localhost (10.122.19.247) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 13 Jun 2025 19:14:36 +0200 Date: Fri, 13 Jun 2025 18:14:34 +0100 From: Jonathan Cameron To: Yicong Yang CC: Catalin Marinas , , , , , , , , , Yushan Wang , , , Lorenzo Pieralisi , Mark Rutland , Will Deacon , "Dan Williams" Subject: Re: [RFC PATCH 2/6] arm64: Support ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION Message-ID: <20250613181434.00004e7e@huawei.com> In-Reply-To: <64ae0e68-b025-4a33-9389-5393ee887fb4@huawei.com> References: <20250320174118.39173-1-Jonathan.Cameron@huawei.com> <20250320174118.39173-3-Jonathan.Cameron@huawei.com> <64ae0e68-b025-4a33-9389-5393ee887fb4@huawei.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.122.19.247] X-ClientProxiedBy: lhrpeml100006.china.huawei.com (7.191.160.224) To frapeml500008.china.huawei.com (7.182.85.71) X-Rspam-User: X-Rspamd-Queue-Id: 6CAB74000C X-Stat-Signature: ys4hrh7tkxsz79tywbjnunmwrdrd19ye X-Rspamd-Server: rspam04 X-HE-Tag: 1749834880-556325 X-HE-Meta: U2FsdGVkX1/UC10Gi9GU1+bdE0EwAI/NQzsKCE1S2AhmLBdvEFfO/r0TMgpHOWVgJyPDUjHgF1zWc8EAcYodk58xsNHRZoHfCVvi0plQsraYgw3w7rM6VrCZUNMrIdSLklS3RFD741YLL5C4Ebj1inl7edCBjD5gYDVHvsM3wzFZ+qveM43cS8mA6ybSiqn2MXXizG3T+Fm8NCiMHMZm6WyR2kx4k10nI9FDPNO/5DoE/wOtCR5J7RUJpeFSEj74o45Djytx1zMq0+MvhHQk/HV8frwUBVmV09NoAV/cFaR2DKtQMZJeEsQz4zNkiVgcIHD9q5j1TRkObU0IupXWLybxEZ4X6oFVChXHB5gYUhAN5qj6b+v7HNTqzxMmtAzTpDvcER83SD5kNj4IQ9XKTvoQ41DnktfjyqosLwOXfYEgyXP9eJW1f8Mei6FN9sbJNJyK/ZR23b1DWQIi4ZxNkyttJwDr1nAfbpuV0NykQbWs+smKAW4aM4p3VTczevsIlPD+1EcRskXWnelYJJCox4zZ0hLfmr3ZmgCeAprkmjVReVH7g16+uLpFqz9jw9T5Rtl+ZVu8BFlMFFsdoHlhQbrlVWTl9h+Z60vDWRErxBVZWDjvfxwM7ks6rI/raS+j0k2BjTMv0/9RvT1vxlMKalQpdS/M00lUAv5JNGBVHpqXp8uwzERB2JUHN2Zqv2n0I0Z1P7Yy+Akvq0JamK7IPAWAgAxzOadHrtekDmCdpOY5haoecSJa8qvFSJVVX4xtvulw3+hWjbmnPsK8/fRxiWwx+C00sCj+DnKjsAGvvT0i2FRIkPfjR0mSBSJ6SdjxSnQHx0OLq9cqZpAZzRaLInDvZhLOq4Kre7Kwj9JSV3vuTgafk0WNhjGUyUCghIG+sfi50UmLff8vj4EEZCj/biCSwx0n8GSVjDwXqoqx3w/0jHI8q0gCmFQVGuscqbyPMUdUj42BfUUAn6KobjK fLSsdDwU ULbu3BE5nEzrPzdGL0d9QEQd9HQ39vR3cX0Xjn8j+XpKgAKUb4XdY2xPBdnS52vLLu6YH05U1LJV012lofqf+yFwa2+ASTYjxx+YMXm1tJ6EErlXcBWmJSu7rFPWNhWzcVnCghWBKbdFx4VVUZv0Je/WNT3WYl/NhFQcz3w0ZYRD/Dv/92pFXFcRb9EJv2fkKVZ0M80yQysyZhKYYzJiHTCNbi8JaQyoUkcCQaW5l/ZbeFd8uiJUN+sW/ng+YNB3gsOI67mDzUojGrojpW5Zh0VnmnrLHapOgh0JDukdtIjDrMrg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat, 29 Mar 2025 15:14:14 +0800 Yicong Yang wrote: > On 2025/3/29 2:22, Catalin Marinas wrote: > > On Thu, Mar 20, 2025 at 05:41:14PM +0000, Jonathan Cameron wrote: > >> +struct system_cache_flush_method { > >> + int (*invalidate_memregion)(int res_desc, > >> + phys_addr_t start, size_t len); > >> +}; > > [...] > >> +int cpu_cache_invalidate_memregion(int res_desc, phys_addr_t start, size_t len) > >> +{ > >> + guard(spinlock_irqsave)(&scfm_lock); > >> + if (!scfm_data) > >> + return -EOPNOTSUPP; > >> + > >> + return scfm_data->invalidate_memregion(res_desc, start, len); > >> +} > > > > WBINVD on x86 deals with the CPU caches as well. Even the API naming in > > Linux implies CPU caches. IIUC, devices registering to the above on Arm > > SoCs can only deal with system caches. Is it sufficient? > > > > The device driver who register this method should handle this. If the > hardware support maintaining the coherency among the system, for example > on system cache invalidation the hardware is also able to invalidate the > involved cachelines on all the subordinate caches (L1/L2/etc, by back > invalidate snoop or other ways), then software don't need to invalidate > the non-system cache explicitly. Otherwise the driver need to explicitly > invalidate the non-system cache explicitly in their > scfm_data::invalidate_memregion() method. Here in the generally code we > simply don't know the capability of the hardware. Coming to this a little late. It would definitely be helpful to understand whether other hardware implementations where this is relevant (e.g. CXL capable systems) do require explicit flushes of the caches nearer the CPU and any dance that they need in that case to ensure no race conditions leave stale lines. The PSCI spec (that never was) did allow for reporting that it was necessary to stop all traffic prior to flushes, but that is crazy to support and someone built the wrong system if they need to do that under even vaguely normal software flows. Jonathan > > Thanks. >