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

[Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>]

On 22/07/2025 15:34, Jan Beulich wrote:
> 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 ...

My point was to leave the decision making to the calls themselves.
So iommu_do_domctl will make a decision whether to process the node or 
not, same for the scmi call.
I can figure out if there is a need to call iommu_do_domctl or 
sci_do_domctl here but this means moving
part of the logic from specific calls to the common code.
>> +        /*
>> +         * 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