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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF909EB64D7 for ; Wed, 21 Jun 2023 15:11:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233183AbjFUPLM (ORCPT ); Wed, 21 Jun 2023 11:11:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233176AbjFUPKz (ORCPT ); Wed, 21 Jun 2023 11:10:55 -0400 Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC9A31BD3 for ; Wed, 21 Jun 2023 08:06:17 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id 5614622812f47-39eb3af4d8cso3685796b6e.2 for ; Wed, 21 Jun 2023 08:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1687359976; x=1689951976; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=i8mvm0Ua7VheRBgm3SyS2f+CUs+ip4U1HTEOUVIIBZg=; b=HeF1k6bjWFVW0gS1DrVZ7s5steRsGaEzzCs8cnUdWlatT2bkDGzEeLpNR3LkgWjlpq p8HL6SDTUDdeVvXm/6cwQSYiMFo2ig6zdYWYZYRvcIt2OdonMAxt6whMEOgcmqg7p0BF dPU6Z0XeeHzgXZA77Wy350iWlPXC/mrJ8FHlhhSWLKa6+lBZeHznH//y9z4bAY3LGV0j zqvGppwU1sAIn/juqALMn/DhUwL6ZEkKrFnYtinNlAhJCmQGQR3Y1kWid35u5o7SNQd+ RVdAghyucYBDYSFRI+E/A+VSJknTFyRKCufCH+0LtDTFImNCr4Kq/m4V+SxH4tzdMDdM dZCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687359976; x=1689951976; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=i8mvm0Ua7VheRBgm3SyS2f+CUs+ip4U1HTEOUVIIBZg=; b=UWXCTPChufwDT2SOciwXndbJUHqebNrNSZeb2mhZjo2dR8yUN9v8BklSuGytMns5ON 60nTuqn+WksryFr8TjRbcUyme3EaO03ZwqO7A/ANJGUPunC/2kuiqtlGRhcqwHSOHnVc Mv2wzWHMbu7CoDrN1w25dUDcYNcQ/PXHaFNny0DHy72BBltC8N7VSCCQ1n5JT9i2nCGd IVpFrPTHUS7ip2S1VitU0vAGrCzlqNMalX1fIdKznHMuuebilHPuG5RQQh2WF+pRoGe5 T91z/zxuMeDoONzCqvO1C/Hge74Q+OZ+tALIUWVNRGqLObzctblUE3PRbpTYCXvl4G6K z0rA== X-Gm-Message-State: AC+VfDyYUtBQtC+8rLqENf5oQzB1rvg4iHL1sLWCXRw9fhz02et4Tpva 9/UMMAg42QZehVHmVzjNXljFSw== X-Google-Smtp-Source: ACHHUZ636NWZSijMUe4oI3fgGZIHT/qTk8OtX3ic1/cT2sn7NBvatb98BNnqEYBTRAhrHhPIPOOMUg== X-Received: by 2002:a05:6808:1814:b0:39b:f558:8cab with SMTP id bh20-20020a056808181400b0039bf5588cabmr19969218oib.26.1687359976039; Wed, 21 Jun 2023 08:06:16 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-68-25-194.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.25.194]) by smtp.gmail.com with ESMTPSA id gl12-20020a17090b120c00b0025e7f7b46c3sm9142110pjb.25.2023.06.21.08.06.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jun 2023 08:06:15 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1qBzPR-007dQ6-Os; Wed, 21 Jun 2023 12:06:13 -0300 Date: Wed, 21 Jun 2023 12:06:13 -0300 From: Jason Gunthorpe To: Alistair Popple Cc: Andrew Morton , linux-mm@kvack.org, Robin Murphy , will@kernel.org, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, nicolinc@nvidia.com, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, John Hubbard , zhi.wang.linux@gmail.com, Sean Christopherson Subject: Re: [RFC PATCH 0/2] Invalidate secondary IOMMU TLB on permission upgrade Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 20, 2023 at 09:18:24PM +1000, Alistair Popple wrote: > 1. Add a call to mmu_notifier_invalidate_secondary_tlbs() to the arm64 > version of ptep_set_access_flags(). I prefer we modify the whole thing to only call mmu_notifier_arch_invalidate_secondary_tlbs() (note the arch in the name) directly beside the arch's existing tlb invalidation, and we only need to define this for x86 and ARM arches that have secondary TLB using drivers - eg it is very much not a generic general purpose mmu notifier that has any meaning outside arch code. > This is what this RFC series does as it is the simplest > solution. Arguably this call should be made by generic kernel code > though to catch other platforms that need it. But that is the whole point, the generic kernel cannot and does not know the rules for TLB invalidation the platform model requires. > It is unclear if mmu_notifier_invalidate_secondary_tlbs() should be > called from mmu_notifier_range_end(). Currently it is, as an analysis > of existing code shows most code doesn't explicitly invalidate > secondary TLBs and relies on it being called as part of the end() > call. If you do the above we don't need to answer this question. Calling it unconditionally at the arches tlbi points is always correct. > To solve that we could add secondary TLB invalidation calls to the TLB > batching code, but that adds complexity so I'm not sure it's worth it > but would appreciate feedback. It sounds like the right direction to me.. Batching is going to be important, we don't need to different verions of batching logic. We already call the notifier from the batch infrastructure anyhow. This still fits with the above as batching goes down to the arch's flush_tlb_range()/etc which can carry the batch to the notifier. We can decide if we leave the notifier call in the core code and let the arch elide it or push it to the arch so it the call is more consistently placed. eg we have arch_tlbbatch_flush() on x86 too that looks kind of suspicious that is already really funky to figure out where the notifier is actually called from. Calling from arch code closer to the actual TLB flush would be alot easier to reason about. Jason