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