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 4057DC3600C for ; Sat, 29 Mar 2025 07:14:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB32F280177; Sat, 29 Mar 2025 03:14:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E63F0280165; Sat, 29 Mar 2025 03:14:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D2C32280177; Sat, 29 Mar 2025 03:14:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id AF614280165 for ; Sat, 29 Mar 2025 03:14:24 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8993E81009 for ; Sat, 29 Mar 2025 07:14:24 +0000 (UTC) X-FDA: 83273725248.13.A13E0BD Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf14.hostedemail.com (Postfix) with ESMTP id 1AFAE100002 for ; Sat, 29 Mar 2025 07:14:21 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf14.hostedemail.com: domain of yangyicong@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=yangyicong@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743232462; a=rsa-sha256; cv=none; b=Bcgj/PlrUDv9QAgfk/y4oXpHWpV3zdvpbhO0U5ICSBAGyGrZH4oZSE7XOyGA5ObMgfzHjB zgi39Gl599NIsw8f/RPgF+BlCOmJnLg4W1jv3IZQd5lPUQJJMYmdItTxf7arfgfrtbJRUR 6fAslbAdqkuDMmL1mbInrbDa7hTqXuA= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf14.hostedemail.com: domain of yangyicong@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=yangyicong@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743232462; 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=noChvPur7yLlpxVr63pQSgTrBj8ipPoeygGXSV7NvIk=; b=NYr4aoTnRVMIBzDxhdnFmavXOTR0jo0srQtVUtrklvetgE2q+FQExGf0TuUPz2DpHUDqf7 ah1dIYXqnAUXLvKYlMXRwSu7mVTxkv3RK5S2B2HN/R8ml1s1EpVNnVE1RKJPJAeqD0Ao+U Q9jZwThXC62qhxyNeGnJEz54CswJYVU= Received: from mail.maildlp.com (unknown [172.19.162.254]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4ZPpWQ2TNJztRbD; Sat, 29 Mar 2025 15:12:50 +0800 (CST) Received: from kwepemd200014.china.huawei.com (unknown [7.221.188.8]) by mail.maildlp.com (Postfix) with ESMTPS id 4C43E1800B4; Sat, 29 Mar 2025 15:14:16 +0800 (CST) Received: from [10.67.121.177] (10.67.121.177) by kwepemd200014.china.huawei.com (7.221.188.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.10; Sat, 29 Mar 2025 15:14:15 +0800 CC: , , , , , , , , Yushan Wang , , , Lorenzo Pieralisi , Mark Rutland , Will Deacon , Dan Williams Subject: Re: [RFC PATCH 2/6] arm64: Support ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION To: Catalin Marinas , Jonathan Cameron References: <20250320174118.39173-1-Jonathan.Cameron@huawei.com> <20250320174118.39173-3-Jonathan.Cameron@huawei.com> From: Yicong Yang Message-ID: <64ae0e68-b025-4a33-9389-5393ee887fb4@huawei.com> Date: Sat, 29 Mar 2025 15:14:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.177] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemd200014.china.huawei.com (7.221.188.8) X-Rspamd-Queue-Id: 1AFAE100002 X-Stat-Signature: sj3jfyjxmoacoddksyd4os76r5p5nwgd X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1743232461-805130 X-HE-Meta: U2FsdGVkX19RtfQJp2Z8WYFKS4Qiefxbh/rejrw1j07w5I4/bgteDkiU5uckuh+3dUvYjdVCDCXvFAW828IP6odSNabxS/bMEhcXQmGOYnq7V7DbVf3xfpHC/tSfdS9T4pRLf2TQdcJmmEoYpkkNDfcZd9bkPzxLfauRwOYIiMMHQfU+OjN83GDXB/xNSNJCIEJnIoZe1+wCw49ZTv+vXX9uvp5IHI8nR4GiMdYYNOpeb4KraznhXxf/doML7XAxaxl7oqRZNY9I5UN6lVlIpvETyPUVEK9fTznov91nFcV5YupX11ZSngrX/tTinWyqrjBpuWLCEI09OPImRVadpgdccTjtqso2cGy9KXF8+65cB4he43w15FVb1KVZiGewEePE3S6e38CE3IlezVPOVQ+Wvk7cnKd91QBvScVjcbJop7FEpokzU6LWrdmlyRpKY12dpyNrBlzgyNk+NQq3laxYTvLh3Rfl2uByJjZ+52dyoqY/GX96c+csRdUvZRxSUVrJXECcQk96hAMwolKT2uGEoGnryBHOQEgCu1ii7gZEDVbdS+VFvDnw94ehRwz3QtHq1ZHXOpJz1LxENbNS9GFshD729C7xlpOfTTqlBoapmUSR40MjnPtr3Eocfb3q5kVO6fj4vDmJ38aYW2kni+grvAvHq3+A0cUFmTthgoGC4h4fTJVkI/cWocmBQc73WBQ/YqCSymAR26ji8Tutt3rbxGX0rvKAoPgUMRUmhGuDCwp5x7sG2ORezkURV2oAeNYhNRYXJ1VqxNRCucB3zkpKI5yqljfKNy3CuOm2Q9jeyA6hs+LD7V6N4lrB5T8pZYV95WyfRhrUt3YULcjF1EVQqR/iDWUzBMsKuOqTk0WSUTn/MgMMSYDo4/rn8tqBxWl8Q1l6MyIAqGudyCV0Z2G+iUVQKEHNFXU5Nwdb2mVjwStIemNLX5qx93f8Cu2A4bMqWPn1dZSSpMDTU+h OvVTtSEh KSFThzMJiwCc/h9HnPKnHJY3mwbMuDKcn3ZLi6KouBiuXvwkZUYlz8OJVJ4dxwLO1EPAvvC0rY0vqdwfEZh8z1o/yrZk2EQ5fRjzyn/8H895Iq3p4nUujHbk5Nl/AzxPl/LQiGvfw6LwTrWHtU1eRcAZMREtXSQ1Xm2FuMT/vrle2Jj/zqMBKk2fqaQ== 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 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. Thanks.