From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (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 B5A583F20F8 for ; Wed, 6 May 2026 09:53:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778061187; cv=none; b=fkFx9x19NCW2EjXOLTpSXOgcY+JS43/BheLs60fC3iOtf5xAMAWZG7SQ6YFIFLcm4h2DSm9Fq0l0BRQDAHyiILHpe4K/sgYPMN4e82SixEdslqQqZYc8+CecmWckL/JApfQP6wvFB03p6dPNocj6jftypg84MNxJ/zmchAhn1Ss= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778061187; c=relaxed/simple; bh=iy0/b1/iujcmeLTqUoVHzOR2Klz/M0/2Lh//DNx0Le0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=A+mvCiTg7nC9tjKsFCvMaC+Wi3NDoT65Q/5VWZvRYLeX410ChgJ539MmMEv8JQ97usYkWVbBFLsUYon/5PxFO388Rr9zSeqDrBLn4K22HQt/WGNHeLvgnv2jzapLOA3JA6NVd1ZR1+rhhd6TVwhKvm700knMhkzUIttQV/qbo6E= 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=QhMqXzaz; arc=none smtp.client-ip=209.85.128.41 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="QhMqXzaz" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-488b0e1b870so96131125e9.2 for ; Wed, 06 May 2026 02:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1778061182; x=1778665982; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=+7tvgQz0muvH8bYR5hJSB+XsuzIRTcHXfFlIskt4q6c=; b=QhMqXzazorZe2mVxDGoPWvJepyU231SUkR+CUrrqk0Rc6wfJrGl6A5ZAmrmV1TavxD uSNIesa0YoU/RZXfutItC4pvLjjMoVW9bUlY2trNmPuDfTxjh8v3MdqCM/kdcYxBorIu rsyQsRAWEva+QdRRPBPKmfgNpKFLL0jdQjZzBgbFxnLp/8rYEGGO15dbSO9AnxUUCmsi aRzW2AHIgRLw2HGJEUAtMBO6GLQ6krjkOlfxEkTb+VJQ4HZJ1lAl01hrUrGvd+NNFFBT /xjzHllVgPH/Rpgk9OYPB/J4E9FJmFkWheCFOHcSR9CxPJkI961spq9bYhwKPRH+OQSC ldHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778061182; x=1778665982; h=in-reply-to:content-transfer-encoding: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=+7tvgQz0muvH8bYR5hJSB+XsuzIRTcHXfFlIskt4q6c=; b=eaOFI6Fx9PxIkcd4ovYvgaOM6Ml0huLP0Ro5FmWbTdZDJzIvc+ljRVY2qkVj/mn/Rd M+uv4to+nKazSl/P63bGspLHP9csDfK1PF1kRQfEXrBCw3HSq2nsYnJYpeMDvJuUJlOW 8+Ng7D6pe9qwcuTGb8WFW1rf5+agnjU5lGJgNrHvEXn/pn1ZxTnx6LBpOeFnpbufepvj UDG9m1X4NTngJyk4w4VF92FIkbkeKFkIVWpQVt912oR506YpeSBzlWcgHh3BKQpWJ7O1 JQhkd+hFtG169YKY0CNj28diN2UXBtVn06p6nUIrDaI+O+Be3w8xvGfMqXFouEmFlCQx aRpg== X-Forwarded-Encrypted: i=1; AFNElJ8C/F9Sg8nfj9RvSeaji9waQcEP8kipekMnbbSMyv6XmlfvKUbH4YETCqhuc1vJyVxvgOEzjb5DJwRK2Pw=@vger.kernel.org X-Gm-Message-State: AOJu0YybDE5ghyF489Rs7RmRvhbt52HURWAXiW19lFvOA4lPoYKMz59j Rup9Uihi6+STTKLTCCzC1cErf1hIEgKFRlDZVXmEYSfKJwzSE3tuC+3TH/ADWzTRIEc= X-Gm-Gg: AeBDievhGts8T9X2eS7IiyJXT8Uc7yVCg2Mh+xdD6YyiaLiR6a/xyEcuI+EwKm/PQUQ KiUvc9Zrd/PHh9r9JnxJ0O6E1KogRcK+68yFdcTg5k1AwLDu6K1L9Y7tZ0kydf8+lFvzhqR4WYq +4E81XCPOi7pkI8EIPziQTt52ixwsTlO69oyTwVfLagRC5tcNlXUoJJJGbCFlHbDcw0Un7VlHMG 4Z4UYQG+2to5hRTrYTdo99BVqZhWPwN0Z/5H8hg8WH7V48eDs71vRObr+E+irZ+n0eVgl9LqP+k WCPEEkM8u65sD2NTwW69ckesuFyZzgD2+WsgkWgsO1pSnWr13HKfixOIbw6aCKJ/482MXYXj5Pl 97/TYQGLdibSWbaYDJhk2/LS+jcbJ7zQDY4+96Zl6I6GZtuHfJKTWyMpL+Cd5orMiItUx5PnoLL NwyEND8zyEGdqGB6bgvQ== X-Received: by 2002:a05:600c:b8a:b0:48a:5574:3a48 with SMTP id 5b1f17b1804b1-48e51f32bf7mr46777065e9.16.1778061182206; Wed, 06 May 2026 02:53:02 -0700 (PDT) Received: from ziepe.ca ([213.147.98.98]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48e538ca8c0sm33324735e9.13.2026.05.06.02.53.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 May 2026 02:53:01 -0700 (PDT) Received: from jgg by jggl with local (Exim 4.95) (envelope-from ) id 1wKYw8-0001fR-Fw; Wed, 06 May 2026 06:53:00 -0300 Date: Wed, 6 May 2026 06:53:00 -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: References: <20260501111928.259252-1-smostafa@google.com> <20260501111928.259252-5-smostafa@google.com> <20260501124143.GB6912@ziepe.ca> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, May 05, 2026 at 04:43:13PM +0000, Mostafa Saleh wrote: > On Tue, May 05, 2026 at 01:17:09PM -0300, Jason Gunthorpe wrote: > > On Mon, May 04, 2026 at 12:15:17PM +0000, Mostafa Saleh wrote: > > > > > I am not sure if it’s worth it, the hypervisor is much simpler, there > > > is a single page table, it’s locked (also identity mapped), it’s > > > updated on VM boot/teardown only, we don’t even use iotlb_gather at > > > the moment, although possible but I wanted to keep this series as > > > simple as I can then we can add more features later. > > > So this patch is the least intrusive change, as whatever the main SMMUv3 > > > driver does, the range tlb invalidation logic is the same. > > > But I am happy to experiment with that when posted. > > > > Okay, then maybe just always push a full invalidation? > > Like full address space invalidation? that will not be optimal and > will affect every device on the system, why would we do that if we > know the address? Not every device, just wipe the VMID. If you say it is rare then keep it simple. If you need to be narrow then use the proper infastructure with a gather. No reason to make something boutique for pkvm here. Jason