| Message ID | 20220117123251.140867-1-Sergiy_Kibrik@epam.com |
|---|---|
| Headers | show |
| Series | Avoid using Xen DMA ops when the device is protected by an IOMMU | expand |
Hi Robin, > > This could break Linux guests, since depending on the deferred probe > timeout setting it could lead to drivers never probing because the "IOMMU" > never becomes available. > I've noticed no deferred probe timeouts when booting with this patch. Could you please explain more on how this would break guests? Thank you! -- Sergiy
On 2022-01-26 15:09, Sergiy Kibrik wrote: > Hi Robin, > >> >> This could break Linux guests, since depending on the deferred probe >> timeout setting it could lead to drivers never probing because the "IOMMU" >> never becomes available. >> > > I've noticed no deferred probe timeouts when booting with this patch. Could you please explain more on how this would break guests? Right now I think it would actually require command-line intervention, e.g. "fw_devlink=on" or "deferred_probe_timeout=3600" (with modules enabled for the latter to take full effect), but I'm wary of the potential for future config options to control those behaviours by default. Robin. > Thank you! > > -- Sergiy
On Wed, 26 Jan 2022, Robin Murphy wrote: > On 2022-01-26 15:09, Sergiy Kibrik wrote: > > Hi Robin, > > > > > > > > This could break Linux guests, since depending on the deferred probe > > > timeout setting it could lead to drivers never probing because the "IOMMU" > > > never becomes available. > > > > > > > I've noticed no deferred probe timeouts when booting with this patch. Could > > you please explain more on how this would break guests? > > Right now I think it would actually require command-line intervention, e.g. > "fw_devlink=on" or "deferred_probe_timeout=3600" (with modules enabled for the > latter to take full effect), but I'm wary of the potential for future config > options to control those behaviours by default. If deferred_probe_timeout=3600 was specified, we would just need an IOMMU driver in Linux for the "xen,iommu-el2-v1" node to solve the problem, right? I guess I am trying to say that it wouldn't be a device tree interface problem but rather a Linux implementation discussion.
At the moment, dom0 can't distinguish which devices are protected by IOMMU and which are not. In some cases, this can cause swiotlb bounce buffer use for DMA addresses above 32 bits, which in turn can lead to poor performance. Previous discussions at [1,2] agreed upon passing info about IOMMU via device tree. This series does that in a way consistent with existing iommu bindings. [1] https://lore.kernel.org/all/1392913234-25429-1-git-send-email-julien.grall__16109.9684810781$1392913341$gmane$org@linaro.org/ [2] https://lore.kernel.org/all/cover.1633106362.git.roman_skakun@epam.com/ Sergiy Kibrik (2): dt-bindings: arm: xen: document Xen iommu device arm/xen: don't use xen DMA ops when the device is protected by an IOMMU Documentation/devicetree/bindings/arm/xen.txt | 26 +++++++++++++++++++ arch/arm/mm/dma-mapping.c | 2 +- arch/arm/xen/enlighten.c | 9 +++++++ arch/arm64/mm/dma-mapping.c | 2 +- include/xen/swiotlb-xen.h | 1 + 5 files changed, 38 insertions(+), 2 deletions(-) Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Julien Grall <julien@xen.org> Cc: Oleksandr Tyshchenko <olekstysh@gmail.com> Cc: devicetree@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org