lkml.org 
[lkml]   [2020]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] iommu: Relax ACS requirement for RCiEP devices.
On Tue, May 26, 2020 at 12:26:54PM -0600, Alex Williamson wrote:
> > >
> > > I don't think the language in the spec is anything sufficient to handle
> > > RCiEP uniquely. We've previously rejected kernel command line opt-outs
> > > for ACS, and the extent to which those patches still float around the
> > > user community and are blindly used to separate IOMMU groups are a
> > > testament to the failure of this approach. Users do not have a basis
> > > for enabling this sort of opt-out. The benefit is obvious in the IOMMU
> > > grouping, but the risk is entirely unknown. A kconfig option is even
> > > worse as that means if you consume a downstream kernel, the downstream
> > > maintainers might have decided universally that isolation is less
> > > important than functionality.
> >
> > We discussed this internally, and Intel vt-d spec does spell out clearly
> > in Section 3.16 Root-Complex Peer to Peer Considerations. The spec clearly
> > calls out that all p2p must be done on translated addresses and therefore
> > must go through the IOMMU.
> >
> > I suppose they should also have some similar platform gauranteed behavior
> > for RCiEP's or MFD's *Must* behave as follows. The language is strict and
> > when IOMMU is enabled in the platform, everything is sent up north to the
> > IOMMU agent.
> >
> > 3.16 Root-Complex Peer to Peer Considerations
> > When DMA remapping is enabled, peer-to-peer requests through the
> > Root-Complex must be handled
> > as follows:
> > • The input address in the request is translated (through first-level,
> > second-level or nested translation) to a host physical address (HPA).
> > The address decoding for peer addresses must be done only on the
> > translated HPA. Hardware implementations are free to further limit
> > peer-to-peer accesses to specific host physical address regions
> > (or to completely disallow peer-forwarding of translated requests).
> > • Since address translation changes the contents (address field) of the PCI
> > Express Transaction Layer Packet (TLP), for PCI Express peer-to-peer
> > requests with ECRC, the Root-Complex hardware must use the new ECRC
> > (re-computed with the translated address) if it decides to forward
> > the TLP as a peer request.
> > • Root-ports, and multi-function root-complex integrated endpoints, may
> > support additional peerto-peer control features by supporting PCI Express
> > Access Control Services (ACS) capability. Refer to ACS capability in
> > PCI Express specifications for details.
>
> That sounds like it might be a reasonable basis for quirking all RCiEPs
> on VT-d platforms if Intel is willing to stand behind it. Thanks,
>

Sounds good.. that's what i hear from our platform teams. If there is a
violation it would be a bug in silicon.

\
 
 \ /
  Last update: 2020-05-26 20:35    [W:0.034 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site