From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) (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 3EA0F3FD15C for ; Mon, 11 May 2026 14:24:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778509468; cv=none; b=re8yZmNIYzyCWeAMkS4P9Bf2QWYZo4certZTIaQgXQARExma7U8I1tUr4GfAFzsp5IhjsKKlXGNgdaPVK6Uctfo5D3QKzm8Md/UkCABZmCZ8NqSed65IaZsb03L+9F4gc4tfr41gCEXB7BbitYNS/87NFmj8MZq3dDF8Is1GZFs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778509468; c=relaxed/simple; bh=7tNpnX1gFQ6tZ3oOp3leOMqhI0tgTzBeVDf3yJe9700=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=s8g42z+k38PZ5RjmAJIy++OKC+2r0EY25APH+/N/7SpzMkEFYI6dW0/KivHfGzsZU91PUdrNf8+yoKZvtSIZUbbxck18zQoXeemcBrNjXHZfCFC83imkKWV3Zwfhsp7sIyHujNO98G842U+1vtSUjPnC/iee3FsXGUNRlkSytZk= 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=mRMR81/G; arc=none smtp.client-ip=209.85.222.179 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="mRMR81/G" Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-8eea23d01f7so587983385a.0 for ; Mon, 11 May 2026 07:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1778509466; x=1779114266; 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=jkQyUrfkqfz8XQIv/dWok02t1PybehRH8tb5fDYY/+I=; b=mRMR81/G1jrEBY/kV+bNgRBPyKUuR+QLLxa4UNcezJJIkgpXsicX1AvJebF+TqjxB0 hxIQy0rs0WBMFF5lpzSsViws2VnMes1F2I/uRpW0eJ7KoAeqjX0SC83jhjIRYNl9lTK4 +rdsP+J6+3BNa6vNlXHma7GVokWSFJ8g/woKfXaT4wXdNTIx6AKUggCF6pmQQcHTgkfR npiPZ6ObJaC/Txujey9Erf6muIDBp0sweMIxl5XKbj6xsljpRWWPo68FV0F7Z4MdFUFA jptAFMbnxbluexWKx+wuk8w9Ym0X5ZwA8KZbSHRw3BP6MmGGXbIBi92C9VUWy1l+/k4a O7SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778509466; x=1779114266; 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=jkQyUrfkqfz8XQIv/dWok02t1PybehRH8tb5fDYY/+I=; b=JqqX9Cb5Y7+FhrDKm/g90/xJoCXJk1oVZBDVWaExBa0U60GqshBwWslJyPML3QdjLS uSoEphr0QRAfQZCK1V1/1DVHrMGD0lNGkEKBRpND5INZHHXgNeawoLl8+slKC3lTjRNU 0FBKIXWaFRAk8xgxmIFEjgISAhDc4LCjXDPnUPHHjWj52tgxg6YuGYVi7JPH/Po8/4Gx qrDPk90YQ+vzjJMwN9uoT+h2jUJSgQnBgye+8HkhuVpilZcAr/eNqhfPYcbDMknpD2zE ACI/jF7K4lQgcxzD+NgbZWXwzhJWr/MUySMfcoGMVXeaXGx1o+gQiHMjIa0OonEMW2Ca dV4Q== X-Forwarded-Encrypted: i=1; AFNElJ+wK3RDn81F9cECQRD6+egOwgzYY9adH2uvuc+PPRqpqEZ8SnyBwq8IE3SRx0I28hiucw3QxXhzpxsNL7w=@vger.kernel.org X-Gm-Message-State: AOJu0Yzl330h+NtJdEE/yyVCwtPCuuWIDoJNj6vEGDRHiH9r4RXLKRaC YaRTqCKrJIpS4ue5ALrQ9oyU1Unyyv3G/0y8Pzrhd8quPGle2A+UjRpiSwF+GaRdVBg= X-Gm-Gg: Acq92OEh29IbQ2bg4y/W/ksYp/dVQaLw6xw+XIcFHQQ0qHNxbeXev1YivgOaK52BSS3 I+wg90oVeDYEK2/xq8KSwBv8nIGH+++HSzIODERPAyep/+2VR9CvvdJjdgXk9fDfAzpaSTaagRP wyNY3wbtPfz2ZQ2dZ0KxpH5OvI7OACp+DeL/+lohIB2ZqSdad30IZzpjBz6c8Lf/zFzQrBae7Wr c/VgVsRSDaES9JAH8ORz81wh8V+hiovgmy87akev386kzQyxBePWzyTeD1Aq2TOWRc12x9mO9ZU WCoCWS/5ThyIqvXN5gchs8F9WvhJjH7/KJNrJft2bD7W/pZScQo68GaQi3zUy9w8KkgVZyEmo3E MB76rQYFSDueHLkpJscDvbzoL2qasZTDr3+GEnhCAJaKkuTSyxZeWAPTYBXjBX0S/t47Hsc0xDh uNIVkL84bJFiqTsHyRMOMv1aTY4K/1B2hauB52u14fn+0Tfu//U7UR+gvJCIE3PbeUppvVodroU xhlEw== X-Received: by 2002:a05:620a:19a0:b0:8ef:6b87:5c5b with SMTP id af79cd13be357-904d3eafa08mr3652391585a.9.1778509466038; Mon, 11 May 2026 07:24:26 -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 af79cd13be357-8fc2c91cd89sm3166863085a.35.2026.05.11.07.24.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2026 07:24:25 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wMRYX-00000004oFc-0DRM; Mon, 11 May 2026 11:24:25 -0300 Date: Mon, 11 May 2026 11:24:25 -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: <20260511142425.GQ9285@ziepe.ca> 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: On Mon, May 11, 2026 at 11:45:51AM +0000, Mostafa Saleh wrote: > 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. Hiding from the host is a fine solution to start with. > 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. invalidation is complicated, you should not try to open code your own version. You really cannot make it any simpler than what is in the driver, just use the code it is already decently modular. Jason