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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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@xxxxxxxxxxxxxx>
> >> Signed-off-by: Andreas Herrmann <andreas.herrmann@xxxxxxxxxxx>
> >> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
> >>
> >> ---
> >>
> >>     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?

> >>     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...
?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel