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 9C7C6365A12 for ; Mon, 11 May 2026 11:45:58 +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=1778499961; cv=none; b=k5uAGtdabmGeGWvBIOGhgf6W9dM8b6O3VBPOwV06Nc0N6uz/2eSxvPrESbQVNPkxsIRSWFTtnrW78Iw3BjcGS/nSgNAG/HFlOlZKXMn/iGHsohjlkeLhIPKqn9ZUHXqTpQgCxI6l6EYsvC3WYqTPHPUpA/qHrbruENMbI4l9E1M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778499961; c=relaxed/simple; bh=VpRWbnLBmOW52eWfeba/JJdhQXbjyJk0Idet3KASW58=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VBUaGDTs0mfz6mKBid6efyAmLpyB1ya/7LgYSfXsMk1EOSZsG/ElAl99KftFAeFaELcK64xq+fFmBqqVXdch9Z0DXdCdoG80yEO3hnQjHD3N8NHvuPka6PELXaOqdJ12Vcqo3/m63N36Lmgj1r7zoVKs98P0mB2DJrRJkXov9L8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=iiOfhfoS; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="iiOfhfoS" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4891ca4ce02so875e9.1 for ; Mon, 11 May 2026 04:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778499956; x=1779104756; 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=QffmlXKfGIQMvoSpoqBH5tpd14K+nt5m82a+AK1qlTw=; b=iiOfhfoSNdxGzh3kmqetDnZ8iGDCUOslOv+1XEtMRwU5dpq6IAvrFSotzk9teSVuR8 3o4IJhqwTHEr0B8xk7TVmART4K4SUJCOXWS2u0YFG7hsP+cPmmS37EjcSmE1MmEkqpNW 5iKLXDVFsKUoSYXeCN5ah69Njh4ZKSqtDj9JXt9sx3QW4K3GABGhj3qAMAYcFF0z9Teu vKF8p6CkfcK4St4N1KW3VKsSa5hk8e3cOh2jyaj10FhTpI9smen4BjaSXgKomDWeTiYO Uu5e9Bo1WGXIVmeXwVDQkcoEef9jis22bvZOUY6EwDBYi1bhMdlJqCQe8n73Nb56Qef4 0SaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778499956; x=1779104756; 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=QffmlXKfGIQMvoSpoqBH5tpd14K+nt5m82a+AK1qlTw=; b=oQk/Baz+lRyf72HvQH0D+6C23VXZeM9jU+dUK5BIiDDmil6qTQSZvOxSh3zkl7/UxF hJbMrs3c7N1J/laYK+fIniL8BDoYqTsK+ylOS1mv0bItz+l8mrg29/L/JXf+1xRh1Pny sZ0gRAbBT8nkybOGeZUPn4PsZV80BklO9vwa776E3qsSY+JbBVp3txgaOeUMMWEmbb/I AVdn30SN+CnfOa61+MEeDhUGPcDIW6tZef+uf1rY4OlfsaQmF/yH3tQFib6fmsv8XeRs SPwbMM201Cci3nRWnTb1C/vL5aPxY4pSSPxrSw74lBh2kCUalhZFsIsT319h8HhcXQIQ MH6g== X-Forwarded-Encrypted: i=1; AFNElJ8PrfxPl/wahXOviuw1gKWHfl17MHFB1keA0ZEwTykIoOYuQEg28Rgoz/HHkBA310ZohQlehKihO92C+cM=@vger.kernel.org X-Gm-Message-State: AOJu0YwvpWQ4y4UYZgO94SrNRmz63aZYE/zkv2ave9oNTMN3ltRLL8qW 8TuvfCkuBuPS/CdIiTWBFMs9J/k2IMrG0Z2xFRhlzhDQUXHbNaTX1YXpjk8kitEaGg== X-Gm-Gg: Acq92OHxzWVm/ru/iww2vZjLL8vdBFOpoqsmTwncdMWMXiLKGlKHcTfjSrnlRFe/QEw tB+QwZHt4CrfgzC3IlZB+ac9XIozOslIN93N3ZCt3vKKedztg+x6OrVIk0+rfedhqsUSANT9L++ 3PEV+cVqcDtOQ/Spz/JDNsRni0dJOWsZL7psGo75SauzMfCRfuPrlZmqZI6RuZvV8HWGf2fqJoo j72sUmcCw+GlEjDEsCxXJ3zdrq+pwCAHAzwLp/6gTyMzJC42trMw8Wggu3IiU1QI+YPw1yuTuj0 H5HF9UXyjVIczlX9kVIM0/RF2z9QdDnsG0CBUYcaGT/l1+3DVwz5D1G2cBif1S2c6buv9ycHPo0 WByTsFtANgO9Hu9ZMqWv96NDFXj48UScZJ3xJu1Etb7TT9BDlqLLOIwCqdKu8DaV1UsqHJvfY8d UviwbkVoy06o6jxQWVg5HrA6yBtrgFNV+eXF9e7STlmNg2IODkfHSnk5EkLSvyE4t7OVU= X-Received: by 2002:a05:600c:348f:b0:48a:5618:b4d4 with SMTP id 5b1f17b1804b1-48e6f4f6da0mr2636305e9.1.1778499955998; Mon, 11 May 2026 04:45:55 -0700 (PDT) Received: from google.com (8.181.38.34.bc.googleusercontent.com. [34.38.181.8]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-454917d57aesm25552833f8f.26.2026.05.11.04.45.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2026 04:45:55 -0700 (PDT) Date: Mon, 11 May 2026 11:45:51 +0000 From: Mostafa Saleh To: Jason Gunthorpe 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> <20260509232931.GJ9285@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: <20260509232931.GJ9285@ziepe.ca> On Sat, May 09, 2026 at 08:29:31PM -0300, Jason Gunthorpe wrote: > On Thu, May 07, 2026 at 09:40:00AM +0000, Mostafa Saleh wrote: > > But that doesn’t solve the problem, which is: At some point, whether > > eagerly from the page table code, through gather sync or a fancy > > invalidation array, the driver will need to populate a range > > invalidation command (tg, ttl, scale...) and this logic is better > > shared with the main driver which is this patch does. > > My point is this patch doesn't share enough. If you do need to issue > invalidations then share everything below the top level tlbi entry > point and don't try to make a pkvm version of the entire logic just by > ripping out the range logic. > > There is no reason for pkvm to need a different algorithm > here. Especially when you get to supporting ATS and multiple devices > and smmus you may as well just use the whole thing. > > Which is why I suggested to copy the entire call chain into a shared > file Agh, actually this seires doesn't deal with ATS, which I think is wrong, propably we have to issue CMDQ_OP_ATC_INV for the whole space on every S2 invalidation which has to be done per-SID and as it can't be done by VMID :/ or just hide ATS support from host for now, I will look into more for v7. But anyway, we don’t have to share any logic, the kernel driver is quite complicated as it is designed for a different use-case. Doing that makes the hypervisor unnecessary complicated and oversharing this logic makes the kernel driver less maintainable IMO. The hypervisor only needs to share the architecture spec of populating commands. If that’s a problem. I am happy to re-write the RIL part in the hypervisor. It's not that complicated, but I thought it makes sense to share as it is a HW contract. Otherwise, we can break this part into some macros that are called by this function and the hypervisor but that's maybe over-engineered. Thanks, Mostafa > > Jason