On 19.04.2022 17:39, Andrew Cooper wrote: > 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.
Hence I guess someone thought allowing DOMID_INVALID there would be a good idea, irrespective of whether xend actually did things this way. Jan
