| Message ID | 1571220487-6582-1-git-send-email-olekstysh@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [for-4.13,v3] xen/arm: domain_build: Don't expose IOMMU specific properties to hwdom | expand |
Hi all Gentle reminder...
Hi Oleksandr,
On 22/10/2019 11:27, Oleksandr wrote:
> Gentle reminder...
This is in my queue of patches to review. But I have been focusing on more
urgent tasks the past week.
I will try to review it by the end of the week.
Cheers,
Hi Oleksandr, On 10/16/19 11:08 AM, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > > We always skip the IOMMU device when creating DT for hwdom if there is > an appropriate driver for it in Xen (device_get_class(iommu_node) > returns DEVICE_IOMMU). So, even if it is not used by Xen it will be skipped. > > We should also skip the IOMMU specific properties of the master device > behind that IOMMU in order to avoid exposing an half complete IOMMU > bindings to hwdom. > > According to the Linux's docs: > 1. Documentation/devicetree/bindings/iommu/iommu.txt > 2. Documentation/devicetree/bindings/pci/pci-iommu.txt > > Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Acked-by: Julien Grall <julien.grall@arm.com> @Juergen: while the driver relying on those bindings is experimental for Xen 4.13, it would be good to avoid exposing half the bindings of IOMMU. The bindings are generic but it is not used by the SMMU driver yet and therefore should not affect platform using SMMUs. Cheers,
On 24.10.19 10:57, Julien Grall wrote: > Hi Oleksandr, > > On 10/16/19 11:08 AM, Oleksandr Tyshchenko wrote: >> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >> >> We always skip the IOMMU device when creating DT for hwdom if there is >> an appropriate driver for it in Xen (device_get_class(iommu_node) >> returns DEVICE_IOMMU). So, even if it is not used by Xen it will be >> skipped. >> >> We should also skip the IOMMU specific properties of the master device >> behind that IOMMU in order to avoid exposing an half complete IOMMU >> bindings to hwdom. >> >> According to the Linux's docs: >> 1. Documentation/devicetree/bindings/iommu/iommu.txt >> 2. Documentation/devicetree/bindings/pci/pci-iommu.txt >> >> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > > Acked-by: Julien Grall <julien.grall@arm.com> > > @Juergen: while the driver relying on those bindings is experimental for > Xen 4.13, it would be good to avoid exposing half the bindings of IOMMU. > > The bindings are generic but it is not used by the SMMU driver yet and > therefore should not affect platform using SMMUs. Thanks for the background info. With that: Release-acked-by: Juergen Gross <jgross@suse.com> Juergen
On 24.10.19 12:05, Jürgen Groß wrote: > On 24.10.19 10:57, Julien Grall wrote: >> Hi Oleksandr, >> >> On 10/16/19 11:08 AM, Oleksandr Tyshchenko wrote: >>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >>> >>> We always skip the IOMMU device when creating DT for hwdom if there is >>> an appropriate driver for it in Xen (device_get_class(iommu_node) >>> returns DEVICE_IOMMU). So, even if it is not used by Xen it will be >>> skipped. >>> >>> We should also skip the IOMMU specific properties of the master device >>> behind that IOMMU in order to avoid exposing an half complete IOMMU >>> bindings to hwdom. >>> >>> According to the Linux's docs: >>> 1. Documentation/devicetree/bindings/iommu/iommu.txt >>> 2. Documentation/devicetree/bindings/pci/pci-iommu.txt >>> >>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >> >> Acked-by: Julien Grall <julien.grall@arm.com> >> >> @Juergen: while the driver relying on those bindings is experimental >> for Xen 4.13, it would be good to avoid exposing half the bindings of >> IOMMU. >> >> The bindings are generic but it is not used by the SMMU driver yet >> and therefore should not affect platform using SMMUs. > > Thanks for the background info. With that: > > Release-acked-by: Juergen Gross <jgross@suse.com> > > > Juergen Great, I thank you all.
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 1d5eac9..6e85ef4 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -480,10 +480,25 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo, const struct dt_property *prop, *status = NULL; int res = 0; int had_dom0_bootargs = 0; + struct dt_device_node *iommu_node; if ( kinfo->cmdline && kinfo->cmdline[0] ) bootargs = &kinfo->cmdline[0]; + /* + * We always skip the IOMMU device when creating DT for hwdom if there is + * an appropriate driver for it in Xen (device_get_class(iommu_node) + * returns DEVICE_IOMMU). + * We should also skip the IOMMU specific properties of the master device + * behind that IOMMU in order to avoid exposing an half complete IOMMU + * bindings to hwdom. + * Use "iommu_node" as an indicator of the master device which properties + * should be skipped. + */ + iommu_node = dt_parse_phandle(node, "iommus", 0); + if ( iommu_node && device_get_class(iommu_node) != DEVICE_IOMMU ) + iommu_node = NULL; + dt_for_each_property_node (node, prop) { const void *prop_data = prop->value; @@ -540,6 +555,19 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo, continue; } + if ( iommu_node ) + { + /* Don't expose IOMMU specific properties to hwdom */ + if ( dt_property_name_is_equal(prop, "iommus") ) + continue; + + if ( dt_property_name_is_equal(prop, "iommu-map") ) + continue; + + if ( dt_property_name_is_equal(prop, "iommu-map-mask") ) + continue; + } + res = fdt_property(kinfo->fdt, prop->name, prop_data, prop_len); if ( res )