From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v3 11/13] xen/iommu: smmu: Introduce automatic stream-id-masking Date: Fri, 20 Feb 2015 13:55:11 +0000 Message-ID: <1424440511.30924.254.camel@citrix.com> References: <1422643768-23614-1-git-send-email-julien.grall@linaro.org> <1422643768-23614-12-git-send-email-julien.grall@linaro.org> <1424438123.30924.219.camel@citrix.com> <54E739C9.2090101@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YOo32-0003R1-H9 for xen-devel@lists.xenproject.org; Fri, 20 Feb 2015 13:55:16 +0000 In-Reply-To: <54E739C9.2090101@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: Andreas Herrmann , xen-devel@lists.xenproject.org, Andreas Herrmann , tim@xen.org, stefano.stabellini@citrix.com List-Id: xen-devel@lists.xenproject.org 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 > >> Signed-off-by: Andreas Herrmann > >> Signed-off-by: Julien Grall > >> > >> --- > >> > >> 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.