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

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



FYI, I am not actively working on the SMMU driver anymore.


Andreas

--
Pawns in the Game (W.G. Carr).

Think twice: People addicted to media (all?) who believe w/o
questioning all personalized information presented to them, are
massively manipulable via social media and designed plots might become
self-fulfilling prophecies.

--

On Tue, Jan 27, 2015 at 05:51:52PM +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. 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

_______________________________________________
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®.