linux-kernel - RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 6 Aug 2015 19:46:49 +0000
From:	Stuart Yoder <stuart.yoder@...escale.com>
To:	Mark Rutland <mark.rutland@....com>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Will Deacon <Will.Deacon@....com>
CC:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"Lorenzo Pieralisi" <Lorenzo.Pieralisi@....com>,
	"arnd@...db.de" <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ddaney@...iumnetworks.com" <ddaney@...iumnetworks.com>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	"tirumalesh.chalamarla@...iumnetworks.com" 
	<tirumalesh.chalamarla@...iumnetworks.com>,
	"laurent.pinchart@...asonboard.com" 
	<laurent.pinchart@...asonboard.com>,
	"thunder.leizhen@...wei.com" <thunder.leizhen@...wei.com>,
	"treding@...dia.com" <treding@...dia.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"majun258@...wei.com" <majun258@...wei.com>
Subject: RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings



> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland@....com]
> Sent: Thursday, August 06, 2015 1:15 PM
> To: Yoder Stuart-B08248; Marc Zyngier; Will Deacon
> Cc: devicetree@...r.kernel.org; Lorenzo Pieralisi; arnd@...db.de; linux-kernel@...r.kernel.org;
> ddaney@...iumnetworks.com; iommu@...ts.linux-foundation.org; tirumalesh.chalamarla@...iumnetworks.com;
> laurent.pinchart@...asonboard.com; thunder.leizhen@...wei.com; treding@...dia.com; linux-arm-
> kernel@...ts.infradead.org; majun258@...wei.com
> Subject: Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
> 
> [...]
> 
> > > +PCI root complex
> > > +================
> > > +
> > > +Optional properties
> > > +-------------------
> > > +
> > > +- msi-map: Maps a Requester ID to an MSI controller and associated
> > > +  msi-specifier data. The property is an arbitrary number of tuples of
> > > +  (rid-base,msi-controller,msi-base,length), where:
> > > +
> > > +  * rid-base is a single cell describing the first RID matched by the entry.
> > > +
> > > +  * msi-controller is a single phandle to an MSI controller
> > > +
> > > +  * msi-base is an msi-specifier describing the msi-specifier produced for the
> > > +    first RID matched by the entry.
> > > +
> > > +  * length is a single cell describing how many consecutive RIDs are matched
> > > +    following the rid-base.
> > > +
> > > +  Any RID r in the interval [rid-base, rid-base + length) is associated with
> > > +  the listed msi-controller, with the msi-specifier (r - rid-base + msi-base).
> > > +
> > > +- msi-map-mask: A mask to be applied to each Requester ID prior to being mapped
> > > +  to an msi-specifier per the msi-map property.
> >
> > Can we extend the msi-map-mask definition to say:  "A mask value of 0x0 is valid
> > and indicates that no RIDs are _currently_ mapped to any msi-specifier."
> 
> That would break a valid case of the mask being all zeroes.
> 
> Consider the case that all RIDs get mapped to a single msi-specifier;
> the obvious way to write that is:
> 
> msi-map-mask = <0x0000>;
> msi-map = <0x0000 &msi (msi-specifier) 1>;
> 
> In this case all RIDS are always mapped to the single msi-specifier.

Does it really break that case?

We could have this (your example):

  msi-map-mask = <0x0000>;
  msi-map = <0x0000 &msi 7 1>;  // map all RIDs to msi-spec 7

Or, my example:

  msi-map-mask = <0x0000>;
  msi-map = <0x0000 &msi 7 4>;  // all RIDs map to any of msi-spec 7,8,9,10

> > We have an SoC with a programmable hardware table in the PCI controller that maps
> > requester ID to stream ID, so the overall msi-map (and iommu-map) definition fit
> > into that scheme.  But, we would like to be able make the RID->stream-ID mapping
> > decision _lazily_, in Linux, based on actual usage of PCI devices.
> 
> Dynamically programming the mapping is at odds to this binding. I don't
> see how that can fit.

My example above obviously doesn't make sense for a static
binding, but can't we allow both a mask value of 0x0 and
a length > 1 at the same time.
 
> Why can the RID->SID mapping not be statically configured prior to
> entering the OS?

The problem for us is the limited number of SIDs available on our SoC.  We
have an SMMU-500 with 128 SIDs / 64-contexts total.  An SR-IOV card could
enable VFs dynamically and suddenly there are 64 new RIDs on a PCI
bus.  There are 4 PCI controllers and firmware doesn't know what
might be enabled on which bus.  We run out of available SIDs.

In that example we want all RIDs mapped to one SID by default, but want
the option of setting our dynamic RID->SID table for a situation where
say someone assigns a VF to a KVM VM and thus needs an SID to use
for SMMU mappings.

I think the binding can work for the dynamic case as long as we allow
the example I showed above.  So, I would propose changing
my proposed text to:

   "A mask value of 0x0 is valid and indicates that all RIDS map to
    the specified msi-specifier(s).  If the mask is 0x0 and length > 1
    it indicates that all RIDs map to any of the msi-specifiers with
    the actual mapping left unspecified by the msi-map property."

Thanks,
Stuart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/