[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri, Feb 20, 2015 at 01:34:16PM +0000, Julien Grall wrote:
> On 20/02/15 12:35, Ian Campbell wrote:
> > On Fri, 2015-01-30 at 18:49 +0000, 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>
> > 
> > I think you were going to drop this one as it is not strictly required?
> > 
> > I'm still not entirely clear on the motivation for this patch, looking
> > at the v2 thread I see "But, the developer made have written by mistake
> > twice the streamid for the device." which I think you were saying that
> > the DT might, hypothetically, be wrong and have duplicated IDs, is that
> > right?
> > 
> > Is it a hypothetical problem or have we seen it in a real device-tree?
> 
> It's an hypothetical problem. The algo on the next patch won't work
> correctly otherwise.

Seconded -- this patch is to avoid potential problems if the DT
information is bogus.

As the algorithm of the other patch assumes there are no duplicate
streamids I needed to double-check it. Of course I had created special
DTs containing this kind of error to test the check.

> I may need to rework a bit the next patch if we drop it.

I think it's easier to keep the check when DT information is gathered.

Alternative would be to drop it and to be prepared for potential bug
reports about multi-match errors or random other problems in case of
an overwrite of an already configured S2CR.


Andreas

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.