Re: [PATCH v3 0/3] Generic SMMU Bindings

[Julien Grall <julien@xxxxxxx>]

Hi Stefano,

On 02/02/2021 18:27, Stefano Stabellini wrote:
> On Tue, 2 Feb 2021, Julien Grall wrote:
> > On 02/02/2021 17:44, Stefano Stabellini wrote:
> > > On Tue, 2 Feb 2021, Rahul Singh wrote:
> > > > Hello Stefano,
> > > >
> > > > > On 26 Jan 2021, at 10:58 pm, Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > > > > wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > This series introduces support for the generic SMMU bindings to
> > > > > xen/drivers/passthrough/arm/smmu.c.
> > > > >
> > > > > The last version of the series was
> > > > > https://marc.info/?l=xen-devel&m=159539053406643
> > > > >
> > > > > I realize that it is late for 4.15 -- I think it is OK if this series
> > > > > goes in afterwards.
> > > > I tested the series on the Juno board it is woking fine.
> > > > I found one issue in SMMU driver while testing this series that is not
> > > > related to this series but already existing issue in SMMU driver.
> > > >
> > > > If there are more than one device behind SMMU and they share the same
> > > > Stream-Id, SMMU driver is creating the new SMR entry without checking the
> > > > already configured SMR entry if SMR entry correspond to stream-id is
> > > > already configured.  Because of this I observed the stream match conflicts
> > > > on Juno board.
> > > >
> > > > (XEN) smmu: /iommu@7fb30000: Unexpected global fault, this could be
> > > > serious
> > > > (XEN) smmu: /iommu@7fb30000:    GFSR 0x00000004, GFSYNR0 0x00000006,
> > > > GFSYNR1 0x00000000, GFSYNR2 0x00000000
> > > >
> > > >
> > > > Below two patches is required to be ported to Xen to fix the issue from
> > > > Linux driver.
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/iommu/arm-smmu.c?h=linux-5.8.y&id=1f3d5ca43019bff1105838712d55be087d93c0da
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/iommu/arm-smmu.c?h=linux-5.8.y&id=21174240e4f4439bb8ed6c116cdbdc03eba2126e
> > >
> > > Good catch and thanks for the pointers! Do you have any interest in
> > > backporting these two patches or should I put them on my TODO list?
> > >
> > > Unrelated to who does the job, we should discuss if it makes sense to
> > > try to fix the bug for 4.15. The patches don't seem trivial so I am
> > > tempted to say that it might be best to leave the bug unfixed for 4.15
> > > and fix it later.
> > SMMU support on Juno is not that interesting because IIRC the stream-ID is the
> > same for all the devices. So it is all or nothing passthrough.
> >
> > For other HW, this may be a useful feature. Yet we would need a way to group
> > the devices for passthrough.
> >
> > In this context, I would consider it more a feature than a bug because the
> > SMMU driver never remotely work on such HW.
> I see. To be honest I wasn't thinking of Juno (I wasn't aware of its
> limitations) but of potential genuine situations where stream-ids are
> the same for 2 devices. I know it can happen with PCI devices for
> instance, although I am aware we don't have PCI passthrough yet. I don't
> know if it is possible for it to happen with non-PCI devices but I
> wouldn't be surprised if it can.
I merely pointed out Juno because this is where the discussion started. 
Although, my conclusion wasn't solely based on this system nor PCI devices.
It was based on the fact that this could never have worked with the 
current SMMU driver. So this is not a regression and more an improvement 
of the driver to support passthrough for devices using the same stream-ID.
At this stage of the release, I would only consider trivial improvement 
to be merged.
Cheers,

--
Julien Grall