[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 3/5] iommu: move iommu_get_ops() into common code


On 5/14/19 5:19 PM, Paul Durrant wrote:
-----Original Message-----
From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
Sent: 13 May 2019 09:11
To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
Cc: Brian Woods <brian.woods@xxxxxxx>; Suravee Suthikulpanit 
<suravee.suthikulpanit@xxxxxxx>; Julien
Grall <julien.grall@xxxxxxx>; Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Roger 
Pau Monne
<roger.pau@xxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; Kevin Tian 
<kevin.tian@xxxxxxxxx>; Stefano
Stabellini <sstabellini@xxxxxxxxxx>; xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH 3/5] iommu: move iommu_get_ops() into common code

On 08.05.19 at 15:24, <paul.durrant@xxxxxxxxxx> 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.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.