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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.08.2025 07:48, Oleksii Moisieiev wrote:
> 
> 
> 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.

To avoid that, maybe it needs doing the other way around? I.e. try ...

>>> +        /*
>>> +         * 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 first?

Jan