[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260206145254.GK943673@ziepe.ca>
Date: Fri, 6 Feb 2026 10:52:54 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Manivannan Sadhasivam <mani@...nel.org>,
Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>,
Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, iommu@...ts.linux.dev,
Naresh Kamboju <naresh.kamboju@...aro.org>,
Pavankumar Kondeti <quic_pkondeti@...cinc.com>,
Xingang Wang <wangxingang5@...wei.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Robin Murphy <robin.murphy@....com>,
Alex Williamson <alex@...zbot.org>,
James Puthukattukaran <james.puthukattukaran@...cle.com>
Subject: Re: [PATCH v3 3/4] PCI: Disable ACS SV capability for the broken IDT
switches
On Fri, Feb 06, 2026 at 08:46:51AM -0600, Bjorn Helgaas wrote:
> IIUC the current situation is that for these IDT switches, ACS SV is
> enabled when downstream devices are passed through to guests, but
> after these patches, it will no longer be enabled.
ACS SV is enabled at boot time if an IOMMU driver is present
regardless if guests or virtualization is in use.
Linux doesn't change ACS flags dynamically.
> So my question is whether users are giving up some isolation. If so,
> should we even allow devices to be passed through to guests? If we do
> allow that, do users have any indication that they're not getting what
> they expect?
iommu_groups will correctly describe the system limitations with the
ACS quirk path and so all of the above concerns are taken care
of. Robin is saying the Juno SMMU forces a large iommu_group covering
the switch anyhow today, so at least that platform is not affected.
Jason
Powered by blists - more mailing lists