Re: [RFC PATCH v5 06/10] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.07.2025 13:41, Oleksii Moisieiev wrote:
> @@ -859,7 +860,25 @@ 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:
> +        int ret1;
> +        
>          ret = iommu_do_domctl(op, d, u_domctl);
> +        if ( ret < 0 && ret != -ENXIO )
> +            return ret;

If this is where you want the ENXIO for that the previous patch switched to,
then I see no reason for that earlier change at all. Inside the hypervisor
you can simply figure out what the right thing to do is; you could avoid
calling iommu_do_domctl() altogether and call ...

> +        /*
> +         * Add chained handling of assigned DT devices to support
> +         * access-controller functionality through SCI framework, so
> +         * DT device assign request can be passed to FW for processing and
> +         * enabling VM access to requested device.
> +         * The access-controller DT device processing is chained after IOMMU
> +         * processing and expected to be executed for any DT device
> +         * regardless if DT device is protected by IOMMU or not (or IOMMU
> +         * is disabled).
> +         */
> +        ret1 = sci_do_domctl(op, d, u_domctl);

... this one right away, for example. (Which of course doesn't eliminate the
question towards the overloading done here, which iirc was raised before.)

Jan