[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |