Re: [Xen-devel] [PATCH V6 0/8] iommu/arm: Add Renesas IPMMU-VMSA support + Linux's iommu_fwspec

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Sat, 28 Sep 2019, Julien Grall wrote:
> On 28/09/2019 00:52, Oleksandr Tyshchenko wrote:
> > сб, 28 сент. 2019 г., 01:50 Stefano Stabellini <sstabellini@xxxxxxxxxx 
> > <mailto:sstabellini@xxxxxxxxxx>>:
> > 
> >     On Thu, 26 Sep 2019, Oleksandr wrote:
> >      > On 26.09.19 17:56, Julien Grall wrote:
> >      > > Hi,
> >      >
> >      > Hi Julien
> >      >
> >      >
> >      > >
> >      > > On 9/26/19 12:20 PM, Oleksandr Tyshchenko wrote:
> >      > > > Oleksandr Tyshchenko (8):
> >      > > >    iommu/arm: Add iommu_helpers.c file to keep common for
> >     IOMMUs stuff
> >      > > >    iommu/arm: Add ability to handle deferred probing request
> >      > > >    xen/common: Introduce _xrealloc function
> >      > > >    xen/common: Introduce xrealloc_flex_struct() helper macros
> >      > > >    iommu/arm: Add lightweight iommu_fwspec support
> >      > > >    iommu: Order the headers alphabetically in device_tree.c
> >      > > >    iommu/arm: Introduce iommu_add_dt_device API
> >      > > >    iommu/arm: Add Renesas IPMMU-VMSA support
> >      > >
> >      > > This series is now merged.
> >      >
> >      > Thank you!
> > 
> >     I just wanted to provide early feedback that this series causes problems
> >     with the legacy mmu-masters binding:
> > 
> > 
> > This series was developed in a way to add new functionality, but not to 
> > brake existing (legacy bindings). Probably, I missed something 
> > important. iommu_add_dt_device() could return an error (I assume, this 
> > is what you are facing) if the device node in DT contains "iommus" 
> > property (I mean, uses new bindings), but the IOMMU driver doesn't 
> > implement required callbacks yet. Do the device nodes in your DT contain 
> > "iommus" property? And to which domain these devices (in your log) are 
> > going to be assigned (dom0 or other domains?).
> 
> Looking at the bindings, I don't think it is legit to have a node using 
> both legacy and generic binding together. If this is what happens, then 
> I would consider it as unsupported.

I have just sent a fix for this.

The issue is that some Xilinx device trees expose both the legacy and
generic bindings, however, only one set of bindings is supposed to be
used, either the legacy or the generic bindings (not both!). Linux
solves this problem by probing for the existence of "mmu-masters" (the
legacy bindings property) very early on and disabling the generic
bindings if "mmu-masters" is present.

Something like that would work for Xen too, but I chatted with Julien
and came up with something simpler. (Also keeping in mind that a new
colleague of mine has just started working on generic bindings support
for the ARM SMMU driver in Xen so this issue will go away soon). See:

https://marc.info/?l=xen-devel&m=156987707614744

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel