On Fri, 4 Feb 2022, Rob Herring wrote:
> 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.
The tiny "xen,iommu-el2-v1" driver could be backported to the stable
trees, I would imagine. Otherwise, do you have another suggestion?
It looks like fw_devlink=on applies to supplier/consumer interfaces.
If that is the problem, then maybe we should avoid supplier/consumer
interfaces altogether. Instead, we could add a new Xen specific
property, e.g.:
device@ff0000 {
compatible = "this,device";
xen,iommu = "on";
};
