Re: [PATCH v3 3/4] PCI: Disable ACS SV capability for the broken IDT switches

[Bjorn Helgaas <helgaas@kernel.org>]

On Fri, Feb 06, 2026 at 10:30:14AM -0400, Jason Gunthorpe wrote:
> On Fri, Feb 06, 2026 at 02:41:36PM +0530, Manivannan Sadhasivam wrote:
> > > It'd be worth expanding on this and what the effect of avoiding
> > > ACS SV is.  Does this change which devices can be safely passed
> > > through to virtual guests?  Does it give up isolation that users
> > > expect?
> > 
> > IMO, ACS SV is somewhat broken on this switch. But we can still
> > passthrough the downstream devices to the guests. There won't be
> > ACS SV apparently, but that's what users will get with broken hw.
> 
> I agree with this, the HW is very broken, let's have it at least
> work properly in Linux on bare metal out of the box.

I'm assuming the bare metal part could be done by something like this:

  @@ -2555,7 +2555,7 @@ bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l,
	   * ACS Source Validation errors on completions for config reads.
	   */
	  if (bridge && bridge->vendor == PCI_VENDOR_ID_IDT &&
  -	    bridge->device == 0x80b5)
  +	    (bridge->device == 0x80b5 || bridge->device == 0x8090)
		  return pci_idt_bus_quirk(bus, devfn, l, timeout);

> If someone really insists they need virtualization with narrow
> groups on this HW then they need to come with a more complete fix.
> Using VFIO is going to open up the reset flows that are problematic
> with the current solution, so it isn't like that is already working
> fully.

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.

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?