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
