Re: [RFC] PCI ACS Flags Clarification

2017-04-05 Thread Alex Williamson
On Wed, 5 Apr 2017 09:51:06 -0400 Sinan Kaya wrote: > Hi Alex, > > Thank you very much for the detailed explanation. > > On 4/4/2017 3:39 PM, Alex Williamson wrote: > > On Tue, 4 Apr 2017 14:47:58 -0400 > > Sinan Kaya wrote: > > > [cut] > > >> The requirement is to have an > >> 1. ACS cap

Re: [RFC] PCI ACS Flags Clarification

2017-04-05 Thread Sinan Kaya
Hi Alex, Thank you very much for the detailed explanation. On 4/4/2017 3:39 PM, Alex Williamson wrote: > On Tue, 4 Apr 2017 14:47:58 -0400 > Sinan Kaya wrote: > [cut] >> The requirement is to have an >> 1. ACS capability with PCI_ACS_SV if p2p is not supported >> 2. ACS capability with PCI_AC

Re: [RFC] PCI ACS Flags Clarification

2017-04-04 Thread Alex Williamson
On Tue, 4 Apr 2017 14:47:58 -0400 Sinan Kaya wrote: > 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

[RFC] PCI ACS Flags Clarification

2017-04-04 Thread Sinan Kaya
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 follow