Re: [PATCH v3 11/13] xen/iommu: smmu: Introduce automatic stream-id-masking

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2015-02-20 at 15:07 +0000, Julien Grall wrote:
> On 20/02/15 13:55, Ian Campbell wrote:
> > On Fri, 2015-02-20 at 13:42 +0000, Julien Grall wrote:
> >>>>     - Use num_s2crs rather than num_streamids in the arm_smmu_free_smrs.
> >>>>     This former is the field used to configure SRMS
> >>>>
> >>>> Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
> >>>> Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
> >>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> >>>>
> >>>> ---
> >>>>
> >>>>     This patch was sent on Linux ML back to January 2014. It has never
> >>>>     been pushed upstream as it was only useful for Calxeda.
> >>>
> >>> I know that until know Calxeda has been our only platform with an SMMU,
> >>> but that is no longer the case, so I'm not really convinced we want to
> >>> carry divergence from the upstream driver just for the benefit of this
> >>> effectively obsolete platform.
> >>
> >> Nothing prevent a platform to use more streamids than the number the
> >> number of stream matching registers.
> >>
> >> It appears that Calxeda is only one for now. But it may change later...
> >>
> >> About diverging, Linux is moving fast on the SMMU drivers and rework
> >> often. We will diverge quickly from the code. Actually 3.20 reworked
> >> heavily the driver, but I don't plan to resync the code again for Xen
> >> 4.6 (I would loose at least 2 weeks for it).
> >>
> >> As Calxeda is the only platform we have which support SMMU for now. I'm
> >> doing all my work on it, so this patch is useful for me.
> > 
> > I appreciate that, but does that mean we need to take code for an
> > already obsolete platform into mainline Xen when there are at least 2
> > platforms very close on the horizon which will eventually fill this
> > niche just as well?
> 
> I agree that we will have ARM64 board with SMMU very soon. But this is
> the only ARM32 box the SMMU we have on OSStest.
> 
> Even though the platform is deprecated, it would be nice if we can catch
> ARM32 SMMU regression.
> 
> 
> On a side note, we consider this platform deprecated we should either
> drop the code from Xen or write on the wiki that we don't fully support
> it anymore.

It's all about degrees, I think we are fine to support the existing
feature set and commit to keeping that working, but I'm not sure we
should be enabling new features for the platform, in particular when the
patches in question cause us to have to diverge from the upstream for a
particular driver.


> 
> >>>>     The SMMU used to protect the SATA on this platform has more stream
> >>>>     id than the number of stream matching registers. Therefore we have
> >>>>     to use stream id masking to configure correctly all the stream IDs.
> >>>
> >>> What controls which stream IDs are used by the SATA h/w when issuing
> >>> requests? Can we constrain it somehow (ideally by omitting them from the
> >>> DT) to only use a subset of the stream IDs, such that the number used is
> >>> less than the number of matching registers?
> >>
> >> The StreamIDs is controlled by the device. It identifies a stream of
> >> transactions which originate from a device.
> > 
> > I understand that.
> > 
> > What I mean is, if an SMMU has e.g. 4 stream ids (0x1, 0x2, 0x3, 0x4)
> > and protects e.g. a single SATA device, what determines which stream id
> > a given DMA originating from that SATA device uses?
> >
> > i.e. is it one of:
> >      1. The SATA device uses a single hardcoded (in silicon) stream ID,
> >         the other three are unused,redundant.
> >      2. The SATA device can only use a single stream ID which is
> >         configured somehow by software (either firmware or OS driver).
> >      3. The SATA device can use multiple hardcoded stream IDs and a
> >         given DMA uses one of them based up $ALGORITHMN.
> >      4. The SATA device can use multiple stream IDs as configured by the
> >         OS driver.
> >      5. Something else...
> 
> There is a unique ID per-stream. Having multiple streamIDs means
> multiple DMA request can generated at the same time.
> 
> The StreamID is decided between the SMMU and the device. We can't
> interfere and say use only those streamIDs.

OK I didn't realise there could be a stream per DMA request (as opposed
to one stream per device etc).

> The only things that a guest can do is associating a specific streamIDs
> to a context in the SMMU.

Ack.