On 29.01.2026 15:16, Oleksii Moisieiev wrote: > From: Grygorii Strashko <[email protected]> > > 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 <[email protected]> > Signed-off-by: Oleksii Moisieiev <[email protected]>
Acked-by: Jan Beulich <[email protected]> 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
