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 lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9E60ACD4F49 for ; Fri, 22 Sep 2023 10:31:57 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.606824.944873 (Exim 4.92) (envelope-from ) id 1qjdRk-0007cI-Lz; Fri, 22 Sep 2023 10:31:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 606824.944873; Fri, 22 Sep 2023 10:31:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qjdRk-0007cB-Im; Fri, 22 Sep 2023 10:31:40 +0000 Received: by outflank-mailman (input) for mailman id 606824; Fri, 22 Sep 2023 10:31:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qjdRj-0007c5-96 for xen-devel@lists.xenproject.org; Fri, 22 Sep 2023 10:31:39 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 353c633d-5933-11ee-878a-cb3800f73035; Fri, 22 Sep 2023 12:31:37 +0200 (CEST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 12CBE62263; Fri, 22 Sep 2023 10:31:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 705AAC433C8; Fri, 22 Sep 2023 10:31:35 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qjdRd-00FHue-1c; Fri, 22 Sep 2023 11:31:33 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 353c633d-5933-11ee-878a-cb3800f73035 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695378695; bh=YTEt1kxkIMkm1+nI3n50bWZAlpyXcbBEreGRryReUVI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=B5myd+yLK12q3EKpyGwEZ2fqVqoRNHNL5+HeRt2P+4lFn1x6V98ErB2S6KBpeApKi Z9TEs5gqZKdRuVPAp8g4r2w4pGZxhTa1SMzpXhgt3C8jyiJ5K4oyjvOcnFUfpYC4Z1 0R0B/3/1EFp1GrjOMy01jesB5/tT2Jd2BB2mnUzw26mIGlTHSQP+dDYF9Uw4mS9hfV 1RF+mp4W3mBIroBgTRClTRki+owHcxlQmBQSCmrAcLVJmmgyZAM8NdIDe8hYFNoCFI qCCBvDVKUIUUJjb26S7B0IGamYUCbyCTWPNzNjE16zgnqX9eoJfky6ycmwguXII+OW wWxhf3Soyfcpw== Date: Fri, 22 Sep 2023 11:31:31 +0100 Message-ID: <86wmwio5x8.wl-maz@kernel.org> From: Marc Zyngier To: Volodymyr Babchuk Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand , Stefano Stabellini , Bertrand Marquis , Julien Grall Subject: Re: [PATCH v1 2/3] ARM: GICv3 ITS: do not invalidate memory while sending a command In-Reply-To: <875y43f45p.fsf@epam.com> References: <20230919112827.1001484-1-volodymyr_babchuk@epam.com> <20230919112827.1001484-3-volodymyr_babchuk@epam.com> <1614d73f-72b0-44f2-8e34-0e6c58a1a375@xen.org> <87fs3afcxb.fsf@epam.com> <597db9f5-b959-4b75-9410-0d0c16e3acda@xen.org> <875y43f45p.fsf@epam.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: Volodymyr_Babchuk@epam.com, xen-devel@lists.xenproject.org, stewart.hildebrand@amd.com, sstabellini@kernel.org, bertrand.marquis@arm.com, julien@xen.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Volodymyr, On Fri, 22 Sep 2023 01:22:11 +0100, Volodymyr Babchuk wrote: > > > Hi Mark, s/k/c/ > > I am writing to you, because you are GICv3 maintainer in Linux. We are > updating ITS driver in Xen and we have a question about cache > maintenance WRT memory shared with ITS. As I can see, the Linux ITS > driver uses gic_flush_dcache_to_poc() all over the code. This boils down > to "dc civac" instruction which does both clean and invalidate. But do > we really need to invalidate a cache when we are sending an ITS command? > In my understanding it is sufficient to clean a cache only and Linux > uses clean&invalidate just out of convenience. Is this correct? It really depends how you look at it. We use DC CIVA as the standard way to give a buffer to a device, as that's what the DMA API does. Switching to a simple clean is possible, but I don't really see what it brings you. ITS commands are usually written as a single command followed by a SYNC/VSYNC. That's a total a 8 64bit words, which makes a cache line on 99.999% of the implementations. What do you gain by keeping the cache line around? Not much. By the time you go around the command queue and need the same data again, it will have been evicted from your L1 already. So while I don't see a problem with what you are suggesting, I also think the change is pretty much irrelevant. HTH, M. -- Without deviation from the norm, progress is not possible.