Re: [Xen-devel] [PATCH v2 10/12] xen/iommu: smmu: Check for duplicate stream IDs when registering master devices

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2015-01-27 at 17:51 +0000, Julien Grall wrote:
> 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 <andreas.herrmann@xxxxxxxxxxx>
> >>>>>>
> >>>>>> 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 <herrmann.der.user@xxxxxxxxxxxxxx>
> >>>>>> Signed-off-by: Andreas Herrmann <andreas.herrmann@xxxxxxxxxxx>
> >>>>>> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
> >>>>>
> >>>>> 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.

So Calxeda h/w was buggy and provided a DT with duplicate IDs? Or does
the hardware actually use duplicate IDs?

Can we fix this up in xen/arch/arm/platforms/midway.c somehow, perhaps
with a new quirk or hook (e.g. ->fixup_dtb) instead of patching the
imported code. Or by doing a post-hoc fixup after we init the smmu, i.e.
out of line from the imported code.

>  If the ID is
> duplicated the multi match algo in the following patch may not work
> correctly.

Are either of these situations (duplicates in DT or in h/w) actually
improper according to the spec? If not then the multi match algo ought
to cope somehow, even if only by detecting and ignoring.

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

I'm afraid I'm none the wiser having read 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.

Are you talking about under Xen or under Linux here?

If Linux then the fact that you need to use passthrough or take other
manual action to expose the issue doesn't invalidate the possibility of
upstreaming the fix.

Ian.



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