Re: [RFC 1/1] xen/arm: set iommu property for IOMMU-protected devices

[Sergiy Kibrik <sakib@xxxxxxxxxxxxx>]

hi Stefano, Julien,

On 11/10/21 11:12 пп, Stefano Stabellini wrote:
> On Mon, 8 Nov 2021, Julien Grall wrote:
[..]
> > A few years ago, I attempted to disable the swiotlb when Xen configured the
> > IOMMU for the device (see [1]). Did you have a chance to go through the
> > thread? In particular, I think Ian Campbell suggestion about creating an IOMMU
> > binding is quite interesting.
> >
> > Stefano, what do you think?
> Yes I think it is a good idea. In fact, thinking more about it, it is
> really the best option. Regardless of the implementation (swiotlb or
> whatever) the device tree description is likely to look similar to the
> description of an IOMMU because it is the common pattern shared by all
> controllers (reset, power, clocks, etc.) so it makes sense to re-use it.
>
> - there is one controller node (the "IOMMU")
> - there is one property under each device node that is protected,
>    pointing to the controller with a phandle and optional parameters (in
>    the case of IOMMUs it is called "iommus")
Code in arch_setup_dma_ops() always forces swiotlb for dom0 regardless 
of any prior IOMMU configuration for the device. So if we are to re-use 
IOMMU bindings and implement kind of dummy iommu (that merely does 
direct allocation and mapping) we'll have to check whether device is 
protected anyway, e.g.:
  diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
  index 49f566ad9acb..6ddef3233095 100644
  --- a/arch/arm/xen/enlighten.c
  +++ b/arch/arm/xen/enlighten.c
  @@ -425,6 +425,10 @@ static int __init xen_pm_init(void)
   }
   late_initcall(xen_pm_init);

  +bool xen_is_device_protected(struct device *dev) {
  +     return dev->dma_ops == &dummy_xen_iommu_ops;
  +}

   /* empty stubs */
   void xen_arch_pre_suspend(void) { }


Have I got it right?

 - Sergiy