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