On 19/04/2022 11:59, Jan Beulich wrote: > On 19.04.2022 12:49, Andrew Cooper wrote: >> On 19/04/2022 10:39, Jan Beulich wrote: >> Furthermore, under what circumstances is test_assign_device legitimate >> when passing DOMID_INVALID ? This has been broken for 3 years now >> without report, so it's clearly an unused codepath under both xl's and >> xapi's idea of passthrough. > I guess xend had a way to drive the domctl this way.
Looking at the xend code, it always called with domid 0. I can't see any evidence that there has actually been a caller passing DOMID_INVALID, but this is an utter mess. > Iirc this was > to find out whether a device is assignable at all, without needing > to know of any particular valid domain. In a correctly architected IOMMU subsystem (which Xen most definitely does not have at this juncture), that question is "Does the device have an upstream IOMMU". Xen doesn't currently have a working idea of an x86 system with IOMMUs but not covering all devices. While such a system is unlikely to exist in reality, there are cases where quirks create asymmetric coverage. Either way, this is fully subsumed by the future work to assign IOMMU groups. Also at the moment, because Xen doesn't support per-device IOMMU contexts, another check not performed is whether this devices identity maps are compatible with the identity maps in the target domain. Extra complexity here is that it will not occur on a single system (Conflicting RMRRs/IVHDs on a single system is definitely a firmware bug, not an accurate description of the system); only with migration between systems where equivalent logical devices have differing identity requirements on different systems. I don't see anything useful the "with a domid" version gets you. ~Andrew
