Hi,
On 5/14/19 5:19 PM, Paul Durrant 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.
That's correct, it is a mid / long term plan.
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.
I can see two uses cases:
1) Finding the IOMMU associated to a device
2) Applying an operation (i.e domain creation/destruction,
map/unmap) on all the IOMMU
Actually, we already have similar concept within the SMMU driver because
a platform may contain multiple SMMUs.
Any generic interface would actually be quite beneficial as we could
simplify a lot the driver and avoid duplicating the logic in all the new
Arm drivers.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
