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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 AF0D3C25B07 for ; Wed, 10 Aug 2022 21:50:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=d002HtoVlTIajXhrU79j/NeEEByAVJqm6nW6pJ2azoI=; b=Zr6hqUUI5jDMGh18xL0+uwSyle xzMFrzSJK8z6xxCsw8PKu2F4/sLEcbVz4AAvt3fPpZA7mdN5+y7MGnLkHJZo+yx421FQeEl4IW+DJ /0xErRP74Xz9oiTaRkusYNAL7QGGMO9fAtw2naNAk/NvZNt0Ns0tz4j2Ak4l4SSjj7+GXK4Ox9Rq9 WCRDHLJuMr8YgNyEQB2dgbs07Z/MXDT9V5m6lzK6TyNJU9BgFuonxgEBitTvzcNUKnGn9H9YS5/bQ HYumhEPoAinokViWGG/XCoZJN/1VuNOeEpl8QhQyMPuGinEjoZUxx8F6FlXrMY2IvbtheSCOcZrSM BlbJe64A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oLtZE-00FO2a-CE; Wed, 10 Aug 2022 21:48:44 +0000 Received: from olivedrab.birch.relay.mailchannels.net ([23.83.209.135]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oLtZ8-00FNur-TO for linux-arm-kernel@lists.infradead.org; Wed, 10 Aug 2022 21:48:41 +0000 X-Sender-Id: dreamhost|x-authsender|dave@stgolabs.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C1C606C176F; Wed, 10 Aug 2022 21:48:33 +0000 (UTC) Received: from pdx1-sub0-mail-a301.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A8F856C1F1A; Wed, 10 Aug 2022 21:48:32 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1660168113; a=rsa-sha256; cv=none; b=WYJMxqrkeP4XCTOieBVD2PSb5p6fs8JP3LLyF0OZ80zLtfrBHUZZvzwCyUFnGl2pyeYpFg OSAky+QGuVZ4Bs2fbjFz1Uzh2vbJUcQZqSRIX8RTP8ZdigDjHfYM2ycaGOuZL7vKROGHC5 EIfXZDiz3XZ9E9PppwWKOHRM5C3mXO+53L1MFO2mw94J6NhUBuAtKnZo8dl1x6cQCopWJN hCNV3v99/GrjoCFy6WMiLE62qvBo/oEBwdI5SfNQ1Z41usxp/WBUy0Y4qYgD0SM5HRnI9T iybn/hUccU8mziu16/2OOfMxI+nchMsj4TCOlXSv/FHNyP2UzY4zT30NwBMscw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1660168113; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jWp01Hcl4j0YiL9/n7IqCl4dh/n8uPqHFzk1dZ4hNj8=; b=INNStFOlxSuXXOwUF/tkf8NmHL8KePZuDc2lWL2jv7EBB633F3vaq2ymNKkD80dnh5yNSo bWl5PbePBYG/esel1y+16Svr16VzqJ6Q67KJw5B7kYk/UoXlMUPlc02xg4oFBhZIEZTd8W u4VHk5T5P9E3piV41193RGytTWwCZUEl/g9ZtJ3R55Zmdz3QD3B13YHzmxHvj7lrORM6Xa mPzwW8ebFpPbKEJLrF64kPLtD0bUx6uZy4pM9ndtbQ4BIamUmD2wRqraYIrDG8thApP2Mu tee669SrSzwmLl2+9xpQD/11viUm79fr7zMSSOdoiDyfkicvGi9GGXvx3xSVmg== ARC-Authentication-Results: i=1; rspamd-7c478d8c66-wmbcj; auth=pass smtp.auth=dreamhost smtp.mailfrom=dave@stgolabs.net X-Sender-Id: dreamhost|x-authsender|dave@stgolabs.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|dave@stgolabs.net X-MailChannels-Auth-Id: dreamhost X-Lonely-Unite: 2587f2a53c744ae3_1660168113268_3568757427 X-MC-Loop-Signature: 1660168113268:3572167391 X-MC-Ingress-Time: 1660168113267 Received: from pdx1-sub0-mail-a301.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.112.55.239 (trex/6.7.1); Wed, 10 Aug 2022 21:48:33 +0000 Received: from offworld (unknown [104.36.25.245]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dave@stgolabs.net) by pdx1-sub0-mail-a301.dreamhost.com (Postfix) with ESMTPSA id 4M33Tq2F6MzMD; Wed, 10 Aug 2022 14:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stgolabs.net; s=dreamhost; t=1660168112; bh=jWp01Hcl4j0YiL9/n7IqCl4dh/n8uPqHFzk1dZ4hNj8=; h=Date:From:To:Cc:Subject:Content-Type; b=A6GKJe13/0xcGDk13MOtD/Lf29AjbXwG7DsGw8gAvvZtFwA3xgbgYPqjHxiN7iPDv D5k7AqupovSKVi//+eIPG84PE3FCZMln9AyHay2+GllzOCv2EnHZOKou364UCxz+ib j4O4AFEjnlRErLj1vowWcX+OiRmqciu1sZwW8N8XaFyB3sFZ1bgVkvEUzW2IUQint/ YCYxGvHeunNiEGk9FJ9ratMlpHkt03pT9eejxjNvh+nuAUgk0SWzgpQegOKqBnq1Gv WvIb054m7ixCjZT6ReFxkDztcdkkfH6ZghMFTjtQ563pV9fRkX2U1CrCqwp5du+oFw dg9dzgrWnGqqw== Date: Wed, 10 Aug 2022 14:31:12 -0700 From: Davidlohr Bueso To: Dan Williams Cc: Mark Rutland , Dave Jiang , Jonathan Cameron , linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev, bwidawsk@kernel.org, ira.weiny@intel.com, vishal.l.verma@intel.com, alison.schofield@intel.com, a.manzanares@samsung.com, linux-arch@vger.kernel.org, Arnd Bergmann , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH RFC 10/15] x86: add an arch helper function to invalidate all cache for nvdimm Message-ID: <20220810213112.p4fdclh4zbd3vta6@offworld> References: <165791918718.2491387.4203738301057301285.stgit@djiang5-desk3.ch.intel.com> <165791937063.2491387.15277418618265930924.stgit@djiang5-desk3.ch.intel.com> <20220718053039.5whjdcxynukildlo@offworld> <4bedc81d-62fa-7091-029e-a2e56b4f8f7a@intel.com> <20220803183729.00002183@huawei.com> <9f3705e1-de21-0f3c-12af-fd011b6d613d@intel.com> <62f40fba338af_3ce6829466@dwillia2-xfh.jf.intel.com.notmuch> <20220810211337.ha27cl24splm4wjh@offworld> <62f4238b5ce8a_3ce6829447@dwillia2-xfh.jf.intel.com.notmuch> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <62f4238b5ce8a_3ce6829447@dwillia2-xfh.jf.intel.com.notmuch> User-Agent: NeoMutt/20220429 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220810_144839_357044_98B4B4B8 X-CRM114-Status: GOOD ( 19.71 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 10 Aug 2022, Dan Williams wrote: >Davidlohr Bueso wrote: >> On Wed, 10 Aug 2022, Dan Williams wrote: >> >> >I expect the interface would not be in the "flush_cache_" namespace >> >since those functions are explicitly for virtually tagged caches that >> >need maintenance on TLB operations that change the VA to PA association. >> >In this case the cache needs maintenance because the data at the PA >> >changes. That also means that putting it in the "nvdimm_" namespace is >> >also wrong because there are provisions in the CXL spec where volatile >> >memory ranges can also change contents at a given PA, for example caches >> >might need to be invalidated if software resets the device, but not the >> >platform. >> > >> >Something like: >> > >> > region_cache_flush(resource_size_t base, resource_size_t n, bool nowait) >> > >> >...where internally that function can decide if it can rely on an >> >instruction like wbinvd, use set / way based flushing (if set / way >> >maintenance can be made to work which sounds like no for arm64), or map >> >into VA space and loop. If it needs to fall back to that VA-based loop >> >it might be the case that the caller would want to just fail the >> >security op rather than suffer the loop latency. >> >> Yep, I was actually prototyping something similar, but want to still >> reuse cacheflush.h machinery and just introduce cache_flush_region() >> or whatever name, which returns any error. So all the logic would >> just be per-arch, where x86 will do the wbinv and return 0, and arm64 >> can just do -EINVAL until VA-based is no longer the only way. > >cache_flush_region() works for me, but I wonder if there should be a >cache_flush_region_capable() call to shut off dependent code early >rather than discovering it at runtime? For example, even archs like x86, >that have wbinvd, have scenarios where wbinvd is prohibited, or painful. >TDX, and virtualization in general, comes to mind. Yeah I'm no fan of wbinv, but in these cases (cxl/nvdimm), at least from the performance angle, I am not worried: the user is explicity doing a security/cleaning specific op, probably decomisioning, so it's rare and should not expect better. Thanks, Davidlohr _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel