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
