>>> On 14.05.19 at 18:19, <paul.durr...@citrix.com> wrote: >> -----Original Message----- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 13 May 2019 09:11 >> To: Paul Durrant <paul.durr...@citrix.com> >> Cc: Brian Woods <brian.wo...@amd.com>; Suravee Suthikulpanit > <suravee.suthikulpa...@amd.com>; Julien >> Grall <julien.gr...@arm.com>; Andrew Cooper <andrew.coop...@citrix.com>; >> Roger > Pau Monne >> <roger....@citrix.com>; Wei Liu <wei.l...@citrix.com>; Kevin Tian > <kevin.t...@intel.com>; Stefano >> Stabellini <sstabell...@kernel.org>; xen-devel >> <xen-devel@lists.xenproject.org> >> Subject: Re: [PATCH 3/5] iommu: move iommu_get_ops() into common code >> >> >>> On 08.05.19 at 15:24, <paul.durr...@citrix.com> 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 Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
