From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0ABC3A542C for ; Fri, 1 May 2026 12:41:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777639307; cv=none; b=cT4xksi1OG/7mWNwc/+s+VZVMY0b5oM8i8WGdpMcpKS91pWckqD9cSlYnKtoLYzVmlyXIamCMCRi2yPDhKAowoLDoOOg2kqf6LUrbyQEjGOQ8HPhKWW99aNR9+v/w7ii6yqSRCsFWz/m5yxqMaxUJF1gupUe4l2zrfYVNw/JYo8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777639307; c=relaxed/simple; bh=yfsSDvdRmO1iaabYp9r8F4bUp37m0+9RdlEMuJAwRXU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LaSDF4mdoXdNEmt8iecQd+qL9yrIvnKl7BBS3oRGPTl5r1ea9crpDcoEXfG65ItNgLus67yP6srhmelmuDJIz8OBLadjw7im0jP+K+R7gWfklatGHW4w1t9AcyP+IdwE7X2dye+g/tStayLCp/qgVyxGFgkD7KWn320oYO9fSS4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=Wc23Ja3J; arc=none smtp.client-ip=209.85.160.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="Wc23Ja3J" Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-50fbd79350dso17008891cf.3 for ; Fri, 01 May 2026 05:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1777639305; x=1778244105; darn=vger.kernel.org; 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=2W3ZOFfDhqX8vh6C4yIuWTuxJv6mmoplDTMsMIIiSDs=; b=Wc23Ja3J19iMbC5DwwbBr2rdsmzUOLD4hTjsUKLMAFl9YBHG7fwpbr7NIc8hBnpGy2 CFaGqmHMkMfc1F1Dkj6QZJPn1ISfPv3tXpYxQ9i0O2pjz74QDIoZJL/BFQwMIYVZEg8f 75CN7JQJOf2HiY8mVPqmKL9ruQwznK8rQSxsl8rw/lXxWQSScinrlCt1nDyplfUluIGy PnTZKU9S2FK4awvFZ7VjMKnJg4JQyh3bGiLBc65KyhJ3T4/roYfdi/engNESBPRIx91v 66pIakjWeE0JWJ3Va/uOXS9q+Y6H2bAMvi7S6KnpkSX+pKingXvmy+CzfxbG5OYkIaOq 9ayA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777639305; x=1778244105; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2W3ZOFfDhqX8vh6C4yIuWTuxJv6mmoplDTMsMIIiSDs=; b=ZStq+RBhUCjQ97CQTfAOoiYCN9OvT1h37vETwKmqsJ1Kx4rwNBj2qoOTiM/MotKHq+ E1+u1p7sarxwDwGKc0h8bw0SoqAjEIsi9DbdLMagy/Bo/YITus8QkolOIR/NcbxxOBEK 6txEFnwL57LrIXMG9KbFsfjw1aE20Ridf+BLLnoNVTiDzsB8gdjtXy+80T8EQVKB74rY xeLIAFyLwH4KJpmkl0WXuQkI8CypH4U3KTyd9arISCRIa1i0ERJcjfnR2Ld8xDKCaDjy iKqGcPYBH2ZqrVT4/J8m8UlaITqplCR6Q0OLyfWx1G2U2Ci0cPRUBlqQ/FiuXCRntTcq 7pxA== X-Forwarded-Encrypted: i=1; AFNElJ8tu6URoo4FYVHGuKdDwXBD33+2nyBn+6uzjuQlQMXZFUfk8iUMNIpcrQJfjPGVqsk2LquX+KcSqvesSUg=@vger.kernel.org X-Gm-Message-State: AOJu0YzuTnXtp7Y2NsgTUtWxul5KYRJanwkkxmZYSg4KGeDtGZJ4EbPb pF0m0NsiBetxytOtx7ZMl1jFTwOw30sFOesrzpqP17L4C9gEdFp7iw3Q2NAXrp4FECk= X-Gm-Gg: AeBDieuX/4JgbIDbpa8xbbIAh121QNVW0zTYZBfDN5A7IkAfqxrtVtwnZofEVuf8bu7 TmflcvGjXMExfvsop4p4I0jnhQVVP5fYTyITj24qX1sL2F2YHbqSW1uYjSh8B5czt5uSVspa1Le LRcojxXkRNyuWLggFQZ0GiL6nJ/wP6PFfib6ey6YYh7KBTRX4hZCrn2ZGctf9BhTTSq+LUJAmXD mHgZkj6F7LQOFwnXEFWOstnrSXd/a9OfVoc/APX1PnQQvlPLoGqnv0vkS29Z2ibUKsh113rqIlD M41O8//UJzlzjbfLpyoNfC1mwv8I+pOEnZA6CoJoiC2OIIaBYVJIQSaaUNOvQnzB3mUNHbu8fhp P9zFoiKfHewn5zbu5uy5xGDWBuJ7G3Si8Xn9ZjPQHFqhQxa1IVZYHVvOTCFbE7bWrThU/zcU2Kb Wfi0MvHZV8SuS4oU9tBOWd+cwzf4rTRMBupEvJWcLkz8Bh3cI8g2/cZF5bwU9VYodHyC9Juj1aI mds/NlTH0a+7nrd X-Received: by 2002:ac8:7f84:0:b0:510:1b61:d0e4 with SMTP id d75a77b69052e-5103e8fad49mr37362611cf.35.1777639304723; Fri, 01 May 2026 05:41:44 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-51040b8174csm14655201cf.25.2026.05.01.05.41.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 May 2026 05:41:44 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wInBf-000000058bc-2ERN; Fri, 01 May 2026 09:41:43 -0300 Date: Fri, 1 May 2026 09:41:43 -0300 From: Jason Gunthorpe To: Mostafa Saleh Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, iommu@lists.linux.dev, catalin.marinas@arm.com, will@kernel.org, maz@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, joro@8bytes.org, jean-philippe@linaro.org, mark.rutland@arm.com, qperret@google.com, tabba@google.com, vdonnefort@google.com, sebastianene@google.com, keirf@google.com Subject: Re: [PATCH v6 04/25] iommu/arm-smmu-v3: Move TLB range invalidation into common code Message-ID: <20260501124143.GB6912@ziepe.ca> References: <20260501111928.259252-1-smostafa@google.com> <20260501111928.259252-5-smostafa@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260501111928.259252-5-smostafa@google.com> On Fri, May 01, 2026 at 11:19:06AM +0000, Mostafa Saleh wrote: > Range TLB invalidation has a very specific algorithm. Instead of > re-writing it for the hypervisor, move it to a function that can > be re-used. I think this is too narrow. You should start at __arm_smmu_domain_inv_range() and shove all of that callchain into a new file "arm-smmuv3-tlbi.c" which you can then double compile for pkvm. pkvm would have to present the tlbi description and the invs array which shouldn't be hard for it. Then it will enjoy all the same hypervisor optimizations we are working on for the normal driver. I am about to send a patch series here for iommupt that significantly alters this. I think it will help your pkvm effort as the invalidation entry point becomes significantly decoupled from the iommu subsystem: static void arm_smmu_domain_tlbi_inv(struct arm_smmu_tlbi *tlbi, struct arm_smmu_invs *invs) struct arm_smmu_tlbi { struct arm_smmu_domain *smmu_domain; // Can be removed unsigned long start; unsigned long last; u8 leaf_levels_bitmap; u8 table_levels_bitmap; }; Which pkvm should have no trouble invoking. It has to build an invs, but I guess that is pretty simple and done once at boot for pkvm? Once done all the fiddly bits about building the commands would be shared. There is really no reason this should differ anyhow. https://github.com/jgunthorpe/linux/commits/iommu_pt_arm64/ cover-letter: Organize SMMUv3 the invalidation flow so iommupt can use it Jason