All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
	Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
	Julien Grall <julien@xen.org>,
	Oleksandr Tyshchenko <olekstysh@gmail.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 1/2] dt-bindings: arm: xen: document Xen iommu device
Date: Fri, 4 Feb 2022 20:14:21 -0600	[thread overview]
Message-ID: <Yf3dfUtYoB8wpWkl@robh.at.kernel.org> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2201261050300.27308@ubuntu-linux-20-04-desktop>

On Wed, Jan 26, 2022 at 10:56:39AM -0800, Stefano Stabellini wrote:
> 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.

fw_devlink=on is now the default (for at least a couple of cycles).

> 
> 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.

You would have to add that IOMMU driver to old, existing kernels if you 
want compatibility with a new DT. Otherwise, that kernel would stop 
booting with a new DT.

Rob



WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
	Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
	Julien Grall <julien@xen.org>,
	Oleksandr Tyshchenko <olekstysh@gmail.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 1/2] dt-bindings: arm: xen: document Xen iommu device
Date: Fri, 4 Feb 2022 20:14:21 -0600	[thread overview]
Message-ID: <Yf3dfUtYoB8wpWkl@robh.at.kernel.org> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2201261050300.27308@ubuntu-linux-20-04-desktop>

On Wed, Jan 26, 2022 at 10:56:39AM -0800, Stefano Stabellini wrote:
> 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.

fw_devlink=on is now the default (for at least a couple of cycles).

> 
> 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.

You would have to add that IOMMU driver to old, existing kernels if you 
want compatibility with a new DT. Otherwise, that kernel would stop 
booting with a new DT.

Rob


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-02-05  2:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-17 12:32 [PATCH v3 0/2] Avoid using Xen DMA ops when the device is protected by an IOMMU Sergiy Kibrik
2022-01-17 12:32 ` Sergiy Kibrik
2022-01-17 12:32 ` [PATCH v3 1/2] dt-bindings: arm: xen: document Xen iommu device Sergiy Kibrik
2022-01-17 12:32   ` Sergiy Kibrik
2022-01-17 15:30   ` Robin Murphy
2022-01-17 15:30     ` Robin Murphy
2022-01-18 22:32     ` Stefano Stabellini
2022-01-18 22:32       ` Stefano Stabellini
2022-01-26 15:09     ` Sergiy Kibrik
2022-01-26 15:09       ` Sergiy Kibrik
2022-01-26 15:54       ` Robin Murphy
2022-01-26 15:54         ` Robin Murphy
2022-01-26 18:56         ` Stefano Stabellini
2022-01-26 18:56           ` Stefano Stabellini
2022-02-05  2:14           ` Rob Herring [this message]
2022-02-05  2:14             ` Rob Herring
2022-02-08  0:53             ` Stefano Stabellini
2022-02-08  0:53               ` Stefano Stabellini
2023-05-04  9:33               ` Oleksii Moisieiev
2023-05-04  9:33                 ` Oleksii Moisieiev
2022-01-17 12:32 ` [PATCH v3 2/2] arm/xen: don't use xen DMA ops when the device is protected by an IOMMU Sergiy Kibrik
2022-01-17 12:32   ` Sergiy Kibrik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yf3dfUtYoB8wpWkl@robh.at.kernel.org \
    --to=robh@kernel.org \
    --cc=Sergiy_Kibrik@epam.com \
    --cc=devicetree@vger.kernel.org \
    --cc=julien@xen.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=olekstysh@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.