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

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



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



 


Rackspace

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