[RFC] PCI ACS Flags Clarification

[Sinan Kaya <okaya@codeaurora.org>]

I'm looking for a guideline on how Access Control Services (ACS) need to be
implemented in HW for cases where peer to peer is and isn't supported.

I see conflicting information in the code. 

iommu.c calls pci_acs_enabled() from pci_device_group() to determine if
ACS path is enabled for the following flags.

This paragraph lays out the requirements. 

 /*
  * 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)

I also see the following comment in pci_acs_flags_enabled() which gets
called from pci_acs_enabled()

/*
 * Except for egress control, capabilities are either required
 * or only required if controllable.  Features missing from the
 * capability field can therefore be assumed as hard-wired enabled.
 */

This comment in pci_acs_flags_enabled() is confusing. A capability that reads
0 usually means it is not enabled. This code is assuming enabled. 
Are we trying to say that we'll use the capability bits as a mask while
verifying the requested ACS flags?

For systems that don't support P2P, the code will check PCI_ACS_SV only. 
So, if I summarize this correctly;

The requirement is to have an 
1. ACS capability with PCI_ACS_SV if p2p is not supported
2. ACS capability with PCI_ACS_SV|PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF if p2p
is supported.

Did I get this right?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.