[vfio-users] Requesting USB Card Quad Bus advice

[Alex Williamson]

On Tue, 7 Nov 2017 21:42:32 -0800
Steve Freitas <sflist at ihonk.com> wrote:
> On 11/07/2017 08:37 AM, Alex Williamson wrote:
> >          ACSCap:    SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ 
> > UpstreamFwd+ EgressCtrl+ DirectTrans+
> >          ACSCtl:    SrcValid+ TransBlk- ReqRedir+ CmpltRedir+ 
> > UpstreamFwd+ EgressCtrl- DirectTrans-
> >
> >  
> 
> Thanks for giving this a look!
> 
> One more question. I see that each ACSCap listing has 7 different 
> attributes. SrcValid, TransBlk and so on. When you decide whether a 
> switch port supports ACS, are you looking for any particular attributes? 
> Or is the presence of "ACSCap", whatever might follow it, generally enough?

It depends... :-\

We start with:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iommu/iommu.c#n809
/*
 * To consider a PCI device isolated, we require ACS to support Source
 * Validation, Request Redirection, Completer Redirection, and Upstream
 * Forwarding.  This effectively means that devices cannot spoof their
 * requester ID, requests and completions cannot be redirected, and all
 * transactions are forwarded upstream, even as it passes through a
 * bridge where the target device is downstream.
 */
#define REQ_ACS_FLAGS   (PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF)

Depending on the type of device, endpoint vs downstream port, some of
these are required and some of these are required only if the device
supports the described p2p behavior.  So for instance, it's valid for
an endpoint to have an ACSCap where all of the capabilities are '-',
which indicates the device does not perform that form of p2p, which
means we don't need to set the control bit for it.  For downstream
ports, such as root ports or downstream switch ports, at least the
above four capabilities and control are required.  Thanks,

Alex