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

Re: [Xen-devel] [PATCH v4 10/12] IOMMU: introduce IOMMU_MIXED config option

>>> On 02.10.18 at 13:00, <julien.grall@xxxxxxx> wrote:
> On 02/10/2018 11:42, Jan Beulich wrote:
>>>>> On 02.10.18 at 12:38, <julien.grall@xxxxxxx> wrote:
>>> On 02/10/2018 11:18, Jan Beulich wrote:
>>>> ARM is intended to gain support for heterogeneous IOMMUs on a single
>>>> system. This not only disallows boot time replacement of respective
>>>> indirect calls (handling of which is the main goal of the introduction
>>>> here), but more generally disallows calls using the iommu_ops() return
>>>> value directly - all such calls need to have means (commonly a domain
>>>> pointer) to know the targeted IOMMU.
>>>> Disallow all hooks lacking such context for the time being, which in
>>>> effect is some dead code elimination for ARM. Once extended suitably,
>>>> individual of these hooks can be moved out of their guards again in the
>>>> future.
>>> While in theory it is possible to have platform with hetereneous IOMMUs.
>>>    I don't see such such support coming in Xen for the foreseeable
>>> future. Note that even Linux does not support such case.
>>> This patch is going to make more complicate to unshare page-tables as
>>> now we would need to care of mixed case. So I would rather not set
>>> IOMMU_MIXED on Arm until we have a use case for it.
>> Interesting. I essence this is the exact opposite of what you've
>> told me when I inquired about indirect call patching of the IOMMU
>> code. The sole purpose of this new option is to have a key off of
>> which I can tell whether to use patchable indirect calls or plain
>> ones.
> I don't think I am saying the opposite. I opened the door for mixed use 
> case. It does not mean, I want to see half of the helpers dropped on Arm 
> because you want them to be patchable. There are other way to do it.

I drop no helpers (or really hooks), I merely hide ones which can't
(currently) be used in mixed-IOMMU environments. And the
mixed-IOMMU case was what you've used to request that indirect
calls here not be patched for ARM.

>> I'm also not following how this change would complicate anything
>> for you. There's effectively no change for ARM, except for some
>> dead code not getting built anymore.
> Well, with your patch free_page_table, resume & co are under 
> !IOMMU_MIXED. So they are unusable on Arm until we effectively rework
> the code to handle mixed case. More likely those callback will be 
> necessary on Arm before mixed case. So I don't think this patch as such 
> is what we want for Arm at the moment.
> I would much prefer if you drop IOMMU_MIXED and implement iommu_{v,}call 
> on Arm as a iommu_ops->fun(...) (i.e no alternative for now). So call 
> are still not patchable for Arm, yet we still have access to all IOMMU 
> functions.

Well, that's what I would have done if you hadn't brought up the
mixed-IOMMU case - clearly, without being able to test, I wouldn't
have dared to try and implement patching of indirect calls for ARM.

I can certainly drop that patch, but in the end it means you've
made me do more work than would have been needed to reach
the immediate goal I have.


Xen-devel mailing list



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