From nobody Mon Jun 8 08:28:40 2026 Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (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 BB40237E304 for ; Thu, 4 Jun 2026 13:50:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.180 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780581054; cv=none; b=ct81oC3JHD3+CW7aj91gN9sv9JxqLKT6N21W+CdFc4gTmhlFVMe/zoScsgQ6EvwnG/aiDvL28pI94MavIlgvcTY3aFZJZpTbkdeViifAJfod5cdAcBR7eyIm7wDdwHALMx4xsV0CLBi1UKF77zJmIwFBKBnNnamPOele5Qt+7as= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780581054; c=relaxed/simple; bh=/jdjsxvL4aeTdyRjLTf+GIij/Stt3VATxC7ctZWpQBE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=KXrD0fJIIB4OxhJswCyFCC2oRK3SKhPXitSYrr8A4EztqelRyOJv7SD+PauTVkp1PkmtVjgj8Sujk3AWlWaly/5CG7pNjcO1oKqnxuhOjxFg64SwCxkWq5UU2Ht8j3Gwn9fDzk1OTMPDrfWqIu2wNKe0bH8xMLJi/4wzf0/vbH4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=I3T6SXkB; arc=none smtp.client-ip=209.85.208.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="I3T6SXkB" Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-396779b9a7fso6381121fa.3 for ; Thu, 04 Jun 2026 06:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780581051; x=1781185851; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=mLp8sJf8fzDOqqtj5uwx1QYbggbPxRQslMsoXQj9LcU=; b=I3T6SXkBJtSDYCdxjpb+Efp2vUCoJIT7QLEqybbV7u83QzaoUjvsvRm1lw95ZTi5um AwdYaiQLVY1h1yfr/3nU/164ZeRq5Y6XFOgh71ydAvBYiupcXizwDrISC/DvRYXoHafs NhYlDlyJdOCbQlqufrLPp+Zl1xFijRGF/A8HwpQ2SJDuxPrieS5/VBEfCIk6EisflSHv /gDUVv3wMk/FFa0i+t85HhgAhGNKvUWQM+uyFfHf7R99HdLDsqTVu1OdKxHUpGmPjMOt mNMttCjZpU70WimMKmHPGsmBlNy6yey3olFwZuy9rwi7LqxkCfuZLeeZYqtRYeA8Mdgs jhGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780581051; x=1781185851; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mLp8sJf8fzDOqqtj5uwx1QYbggbPxRQslMsoXQj9LcU=; b=hsCPZmwOUFx9+WGSZXc9hnqT6PyIE4tgOGCduEEFzjA9iDkHDCuqlotON1pGYcmGNg fT56trUgd9Tcbp0MiqKyoNG+L3df8shX0IyZA/LXph5TFXlo8wzkfK2dF8ZdCE2jt48e ityNfN1EYogIG/kzDwWIQCOaFWE6hlH/xdtuBkXgbEVhXypwoagvvwyvrDMv8S5KcJnq ufnO3nhxalIpOkv0jDXOZK+zJUCoOGXGxTBgsj/qsGK9ACIcqSGM46wXx4yUOaKmv5oA WJmsH3h1fN6mjAJJkgoe9KVeQUaZb/upwMD+Gbi2xfdn7CwAefI6UHNhkuPi3NFfwOlY JUVw== X-Forwarded-Encrypted: i=1; AFNElJ//k8/qlQf6c5SAk6QQK4PlMJ8knNR/vg1DXpfaNm97OeeginiMtY23Sv9Ekl027DZvnu2vaWcY5Rjnf/E=@vger.kernel.org X-Gm-Message-State: AOJu0YzrZ4v8216GTgnjeF9XHPGWXdsvyyO+SU6T1/58Si1jwMGNvA/a LyPNIhqz8uh414Uyhrt8IfrZE54hbJJvwMB9DZxIVJaZalL6RrrFTUOvtyRzqUCE X-Gm-Gg: Acq92OHped/E0ZSqS2EQ7jl8PgU6yeqFIqvLRqQL9/8PtYms/t+jyuX92IsE33ZCL6w iHMiwRHOaCVNCBnwugebjVvu8pi3rNZ7l9Mxt3iHYRNuvsJoxlVW6oCt4jItvEKZ1bjwqjqDpjo GKPGOmf8o2YeyoEZ1W9wqLGBlgPMEG9rN5zca8N8WkdWogAmLJoMStYAPtK8C16ICimMzPCk3iJ 4TvUPcMX8skb6696qPIQVZtbcEp+mMApUii0nBS8mpdhNp6c3zwYCpTtAMorgj3Rfiao6JW1oFN 8ENN23FB/bSjocD+AQjHF8J//wAN1VMZz977A5+VFGHE8Ncs4qL2sAmOVPoJ8dbQ7XRpn54Qymu Q/GGvLySPCi7DH2ODTxkEX5qmkYpA5JCfJKx74v9kbWSMlMzHWYWtVXGsRZ2gheYrrHWgCCGqOR ZZ1kjICP45UBcDnYuH62hFUg67YPnVHpkVdXk7FSXEfAWlhnSAlA== X-Received: by 2002:a05:651c:2226:b0:38d:e220:8daa with SMTP id 38308e7fff4ca-396af063d37mr26758341fa.3.1780581050660; Thu, 04 Jun 2026 06:50:50 -0700 (PDT) Received: from dschervov-lin.yandex.net ([2a02:6bf:8009:1404:e250:47f1:a6b5:92c5]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-396ac2e9a9esm16038051fa.36.2026.06.04.06.50.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jun 2026 06:50:50 -0700 (PDT) From: Dmitrii Chervov To: stable@vger.kernel.org Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com Subject: [PATCH 6.12] iommu: Skip PASID validation for devices without PASID capability Date: Thu, 4 Jun 2026 16:47:53 +0300 Message-ID: <20260604134753.57739-1-fary.ru@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tushar Dave [ Upstream commit b3f6fcd8404f9f92262303369bb877ec5d188a81 ] Generally PASID support requires ACS settings that usually create single device groups, but there are some niche cases where we can get multi-device groups and still have working PASID support. The primary issue is that PCI switches are not required to treat PASID tagged TLPs specially so appropriate ACS settings are required to route all TLPs to the host bridge if PASID is going to work properly. pci_enable_pasid() does check that each device that will use PASID has the proper ACS settings to achieve this routing. However, no-PASID devices can be combined with PASID capable devices within the same topology using non-uniform ACS settings. In this case the no-PASID devices may not have strict route to host ACS flags and end up being grouped with the PASID devices. This configuration fails to allow use of the PASID within the iommu core code which wrongly checks if the no-PASID device supports PASID. Fix this by ignoring no-PASID devices during the PASID validation. They will never issue a PASID TLP anyhow so they can be ignored. Fixes: c404f55c26fc ("iommu: Validate the PASID in iommu_attach_device_pasi= d()") Cc: stable@vger.kernel.org Signed-off-by: Tushar Dave Reviewed-by: Lu Baolu Reviewed-by: Vasant Hegde Link: https://lore.kernel.org/r/20250520011937.3230557-1-tdave@nvidia.com Signed-off-by: Joerg Roedel [ Refactored to apply cleanly without support attaching PASID to the blocke= d domain ] Signed-off-by: Dmitrii Chervov --- My greeting to you LTS maintainers! This is my first kernel patch. I did a manual backport because cherry-pick failed (6.12 LTS did not have this series: https://lore.kernel.org/all/20241204122928.11987-1-yi.l.liu@in= tel.com/). This patch is tremendously helpful for Nvidia Grace servers. Without it their GPU direct technology did not work. kdrivers/iommu/iommu.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 0ad55649e2d0..62e1d6372503 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -3341,9 +3341,11 @@ static int __iommu_set_group_pasid(struct iommu_doma= in *domain, int ret; =20 for_each_group_device(group, device) { - ret =3D domain->ops->set_dev_pasid(domain, device->dev, pasid); - if (ret) - goto err_revert; + if (device->dev->iommu->max_pasids > 0) { + ret =3D domain->ops->set_dev_pasid(domain, device->dev, pasid); + if (ret) + goto err_revert; + } } =20 return 0; @@ -3355,7 +3357,8 @@ static int __iommu_set_group_pasid(struct iommu_domai= n *domain, =20 if (device =3D=3D last_gdev) break; - ops->remove_dev_pasid(device->dev, pasid, domain); + if (device->dev->iommu->max_pasids > 0) + ops->remove_dev_pasid(device->dev, pasid, domain); } return ret; } @@ -3368,8 +3371,10 @@ static void __iommu_remove_group_pasid(struct iommu_= group *group, const struct iommu_ops *ops; =20 for_each_group_device(group, device) { - ops =3D dev_iommu_ops(device->dev); - ops->remove_dev_pasid(device->dev, pasid, domain); + if (device->dev->iommu->max_pasids > 0) { + ops =3D dev_iommu_ops(device->dev); + ops->remove_dev_pasid(device->dev, pasid, domain); + } } } =20 @@ -3403,7 +3408,13 @@ int iommu_attach_device_pasid(struct iommu_domain *d= omain, =20 mutex_lock(&group->mutex); for_each_group_device(group, device) { - if (pasid >=3D device->dev->iommu->max_pasids) { + /* + * Skip PASID validation for devices without PASID support + * (max_pasids =3D 0). These devices cannot issue transactions + * with PASID, so they don't affect group's PASID usage. + */ + if ((device->dev->iommu->max_pasids > 0) && + (pasid >=3D device->dev->iommu->max_pasids)) { ret =3D -EINVAL; goto out_unlock; } --=20 2.43.0