[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 11/13] xen/iommu: smmu: Introduce automatic stream-id-masking
On 20/02/15 13:15, Ian Campbell wrote: > On Fri, 2015-01-30 at 18:49 +0000, Julien Grall wrote: >> From: Andreas Herrmann <andreas.herrmann@xxxxxxxxxxx> >> >> Try to determine mask/id values that match several stream IDs of a >> master device when doing Stream ID matching. Thus the number of used >> SMR groups that are required to map all stream IDs of a master device >> to a context should be less than the number of SMR groups used so far >> (currently one SMR group is used for one stream ID). >> >> Taken from the Linux ML: >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226100.html >> >> Changes compare to the Linux ML version: >> - _fls doesn't exist on Xen so use fls > > Did you mean __fls? I don't see a single _ variant in Linux. I meant __fls. > It's important since I think __fls and fls behave slightly > differently... On ARM __fls is defined as fls() - 1. I take into account in the algo. >> - 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. >> 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. The guest doesn't have any control on it. Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |