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

[Sergiy Kibrik <sakib@darkstar.site>]

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