[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




On 30.09.19 23:58, Stefano Stabellini wrote:

Hi Stefano

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

I expected this could be a reason.


  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

Sounds good to me.


--
Regards,

Oleksandr Tyshchenko


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.