From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v2 10/12] xen/iommu: smmu: Check for duplicate stream IDs when registering master devices Date: Tue, 27 Jan 2015 17:51:52 +0000 Message-ID: <54C7D038.4010808@linaro.org> References: <1421418247-30068-1-git-send-email-julien.grall@linaro.org> <1421418247-30068-11-git-send-email-julien.grall@linaro.org> <54C7C263.7090806@linaro.org> <54C7CC04.9000509@linaro.org> <1422380675.16180.38.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YGAJK-00043j-1d for xen-devel@lists.xenproject.org; Tue, 27 Jan 2015 17:52:22 +0000 Received: by mail-wg0-f46.google.com with SMTP id l2so16178465wgh.5 for ; Tue, 27 Jan 2015 09:52:20 -0800 (PST) In-Reply-To: <1422380675.16180.38.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Stefano Stabellini , tim@xen.org, Andreas Herrmann , stefano.stabellini@citrix.com, Andreas Herrmann , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 27/01/15 17:44, Ian Campbell wrote: > On Tue, 2015-01-27 at 17:33 +0000, Julien Grall wrote: >> On 27/01/15 17:02, Stefano Stabellini wrote: >>> On Tue, 27 Jan 2015, Julien Grall wrote: >>>> On 27/01/15 16:30, Stefano Stabellini wrote: >>>>> On Fri, 16 Jan 2015, Julien Grall wrote: >>>>>> From: Andreas Herrmann >>>>>> >>>>>> If DT information lists one stream ID twice for the master devices of >>>>>> an SMMU this can cause a multi match when stream ID matching is used. >>>>>> For stream ID indexing this might trigger an overwrite of an S2CR that >>>>>> is already in use. >>>>>> >>>>>> So better check for duplicates when DT information is parsed. >>>>>> >>>>>> Taken from the linux ML: >>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226099.html >>>>>> >>>>>> Cc: Andreas Herrmann >>>>>> Signed-off-by: Andreas Herrmann >>>>>> Signed-off-by: Julien Grall >>>>> >>>>> Why didn't you just take a more recent version of the Linux smmu driver? >>>> >>>> The SMMU driver very is recent (see commit in the previous patch)... >>>> Just this patch has never reached upstream. >>> >>> That is not good. It might be worth to wait for it to go upstream. >> >> The patch was sent one year ago. Just before Calxeda was shutdown. >> >> This is a requirement for the following patch. Do you think the other >> patch should be upstream to Linux before? > > In general we should be reluctant to diverge over these things, since it > just ends up making things harder for us in the future (e.g. the next > resync or the one after). > > Is the issue being fixed here specific to Calxeda? e.g. is duplicate > stream ids a h/w bug which has yet to be observed elsewhere or is it a > valid configuration per the h/w specs which it just happens only Calxeda > implemented? It's for catching possible error in the device tree. If the ID is duplicated the multi match algo in the following patch may not work correctly. > > Unless it's a h/w bug I don't see why it couldn't go upstream first. > Even if it is it might still stand a chance. Because nobody take care to upstream it (see why below). >> If so, Calxeda server won't be able to use properly SMMU. >> >> Even though the server will never be used, I do all my SMMU development >> on it. > > The fact that Calxeda are no longer around doesn't in itself preclude > getting these patches upstreamed. After all, no one is deleting CX > support and some people do have them (not just us). It's hardly the most > obscure platform supported by Linux... By default Linux is by-passing the stream ID and the device is not using the SMMU. You will have to use either passthrough or manually said : "I want to enforce this device". And then you will see the error. So by default both patches are not necessary. On Xen, we can't by-pass the SMMU by default. At least it's not the way it should work. Regards, -- Julien Grall