Re: [PATCH v9 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl

[Jan Beulich <jbeulich@xxxxxxxx>]

On 29.01.2026 15:16, Oleksii Moisieiev wrote:
> From: Grygorii Strashko <grygorii_strashko@xxxxxxxx>
> 
> Add chained handling of assigned DT devices to support access-controller
> functionality through SCI framework, so a DT device assign request can be
> passed to firmware for processing and enabling VM access to the requested
> device (for example, device power management through SCMI).
> 
> The SCI access-controller DT device processing is called before the IOMMU
> path. It runs for any DT-described device (protected or not, and even when
> the IOMMU is disabled). The IOMMU path remains unchanged for PCI devices;
> only the DT path is relaxed to permit non-IOMMU devices.
> 
> This lets xl.cfg:"dtdev" list both IOMMU-protected and non-protected DT
> devices:
> 
> dtdev = [
>     "/soc/video@e6ef0000", <- IOMMU protected device
>     "/soc/i2c@e6508000", <- not IOMMU protected device
> ]
> 
> The change is done in two parts:
> 1) call sci_do_domctl() in do_domctl() before IOMMU processing. If
> sci_do_domctl() reports an error other than -ENXIO, treat it as
> authoritative and skip the IOMMU path. A return of -ENXIO indicates
> that SCI did not handle the request and is ignored, allowing the
> existing IOMMU handling to run unchanged;
> 2) update iommu_do_dt_domctl() to check for dt_device_is_protected() and
> not fail if DT device is not protected by IOMMU. iommu_do_pci_domctl
> doesn't need to be updated because iommu_do_domctl first tries
> iommu_do_pci_domctl (when CONFIG_HAS_PCI) and falls back to
> iommu_do_dt_domctl only if PCI returns -ENODEV.
> 
> The new dt_device_is_protected() bypass in iommu_do_dt_domctl only
> applies to DT-described devices; SCI parameters are carried via DT
> nodes. PCI devices handled by iommu_do_pci_domctl do not carry DT/SCI
> metadata in this path, so there is no notion of “SCI parameters on a
> non-IOMMU-protected PCI device” for it to interpret or to skip. The PCI
> path should continue to report errors if assignment cannot be performed
> by the IOMMU layer. So we should leave iommu_do_pci_domctl unchanged; the
> SCI/DT-specific relaxations belong only in the DT path. Also SCI handling
> only exists when DT is present.
> 
> Signed-off-by: Grygorii Strashko <grygorii_strashko@xxxxxxxx>
> Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@xxxxxxxx>

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
provided you get an Arm person's R-b covering ...

> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -29,6 +29,9 @@
>  #include <xen/xvmalloc.h>
>  
>  #include <asm/current.h>
> +#ifdef CONFIG_ARM
> +#include <asm/firmware/sci.h>
> +#endif
>  #include <asm/irq.h>
>  #include <asm/page.h>
>  #include <asm/p2m.h>
> @@ -833,6 +836,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>      case XEN_DOMCTL_test_assign_device:
>      case XEN_DOMCTL_deassign_device:
>      case XEN_DOMCTL_get_device_group:
> +        /*
> +         * Chain SCI DT handling ahead of the IOMMU path so an SCI mediator
> +         * can authorise access-controlled DT devices. Unhandled cases report
> +         * -ENXIO, which is ignored. Any other SCI error aborts before the
> +         * IOMMU path runs.
> +         */
> +#ifdef CONFIG_ARM_SCI
> +        ret = sci_do_domctl(op, d, u_domctl);
> +        if ( ret < 0 && ret != -ENXIO )
> +            break;
> +#endif
> +
>          ret = iommu_do_domctl(op, d, u_domctl);
>          break;

... this change (among anything / everything else). I can't prove its 
correctness,
I can only state (by way of the tag) that I see nothing wrong anymore.

Jan