>>> On 14.05.19 at 18:19, <[email protected]> wrote: >> -----Original Message----- >> From: Jan Beulich [mailto:[email protected]] >> Sent: 13 May 2019 09:11 >> To: Paul Durrant <[email protected]> >> Cc: Brian Woods <[email protected]>; Suravee Suthikulpanit > <[email protected]>; Julien >> Grall <[email protected]>; Andrew Cooper <[email protected]>; >> Roger > Pau Monne >> <[email protected]>; Wei Liu <[email protected]>; Kevin Tian > <[email protected]>; Stefano >> Stabellini <[email protected]>; xen-devel >> <[email protected]> >> Subject: Re: [PATCH 3/5] iommu: move iommu_get_ops() into common code >> >> >>> On 08.05.19 at 15:24, <[email protected]> wrote: >> > Currently x86 and ARM differ in their implementation for no good reason. >> > This patch moves the ARM variant of iommu_get/set_ops() helpers into >> > common code and modifies them so they deal with the __initconstrel >> > ops structures used by the x86 IOMMU vendor implementations (adding >> > __initconstrel to the SMMU code to bring it in line). Consequently, a lack >> > of init() method is now taken to mean uninitialized iommu_ops. Also, the >> > printk warning in iommu_set_ops() now becomes an ASSERT. >> >> When having submitted the indirect call overhead reduction series >> including IOMMU changes for the first time, I was told that the Arm >> folks would like to retain the ability to eventually support >> heterogeneous IOMMUs (and hence I shouldn't provide patching >> infrastructure there). A single global iommu_[gs]et_ops() is sort of >> getting in the way of this as well, I think, and hence I'm not sure it >> is a desirable step to make this so far Arm-specific arrangement >> the general model. At least it would further complicate Arm side >> changes towards that (mid / long term?) goal. >> > > Ok. Do you have any more information on what such an architecture would look > like? I guess it is also conceivable that an x86 architecture might have > slightly different IOMMU implementations (or at least quirks) for different > PCI segments. So perhaps a global ops structure is not a good idea in the > long run.
Different quirks could likely be handled with a global ops instance. The indirect call overhead elimination alone will imo make it undesirable to switch to a non-global-ops model on x86, unless there's a strong reason (like truly different IOMMUs in a single system). Jan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
