Re: [PATCH v2 06/13] iommu: Add extra use_iommu argument to iommu_domain_init()

From: "Jan Beulich" <JBeulich@suse.com>
To: Oleksandr Tyshchenko <olekstysh@gmail.com>,
	Julien Grall <julien.grall@linaro.org>
Cc: Kevin Tian <kevin.tian@intel.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Julien Grall <julien.grall@arm.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 06/13] iommu: Add extra use_iommu argument to iommu_domain_init()
Date: Thu, 07 Dec 2017 05:51:15 -0700	[thread overview]
Message-ID: <5A29475302000078001957FE@prv-mh.provo.novell.com> (raw)
In-Reply-To: <CAPD2p-ngOvoqkFnZGDB81Eqe3Jj73cEEZSJHvVN8P5s33MTMaQ@mail.gmail.com>

>>> On 07.12.17 at 13:08, <olekstysh@gmail.com> wrote:
> On Thu, Dec 7, 2017 at 12:49 AM, Julien Grall <julien.grall@linaro.org> wrote:
>> On 12/06/2017 07:53 PM, Oleksandr Tyshchenko wrote:
>>> On Wed, Dec 6, 2017 at 6:51 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>
>>>>>>> On 25.07.17 at 19:26, <olekstysh@gmail.com> wrote:
>>>>>
>>>>> The presence of this flag lets us know that the guest domain has
>>>>> statically
>>>>> assigned devices which will most likely be used for passthrough
>>>>> and as the result the IOMMU is expected to be used for this domain.
>>>>>
>>>>> Taking into the account this hint when dealing with non-shared IOMMUs
>>>>> we can populate IOMMU page tables before hand avoid going through
>>>>> the list of pages at the first assigned device.
>>>>> As this flag doesn't cover hotplug case, we will continue to populate
>>>>> IOMMU page tables on the fly.
>>>>
>>>>
>>>> While of course it would have been nice if I would have found time
>>>> earlier to look at this patch (and hence closer to when the discussion
>>>> happened), I still don't see it being made sufficiently clear here why
>>>> current behavior (without a need for such a flag) is a problem for the
>>>> non-shared IOMMU case on ARM, when it isn't on x86.
>>>
>>>
>>> The answer is the lack of M2P on ARM. When the first device is being
>>> assigned to domain we are populating non-shared IOMMU page-table.
>>> What does it mean? We are iterating through the list of the pages
>>> (d->page_list) and retrieving a pair of mfn <-> gfn for each page on
>>> x86.
>>> We can't do the same on ARM, since there is no M2P table. The
>>> mfn_to_gmfn macros is just a stub:
>>> #define mfn_to_gmfn(_d, mfn)  (mfn)
>>>
>>> To be honest I haven't played with non-shared IOMMU on ARM
>>> since the end of this summer to be 100% sure that it is still an
>>> issue. But, it seems to be.
>>
>>
>> The situation has not changed. I still see no point of waste memory for the
>> M2P (see the full discussion here [1]).
>>
>> However, I agree with Jan that we need a summary of the discussion in the
>> commit message.
> Sure.
> 
> Jan, is the clarification I have provided (why it is a problem for the
> non-shared IOMMU case on ARM, when it isn't on x86) sufficiently clear and

Yes, mentioning the lack of M2P is goin g to be sufficient rationale.

> the current patch with "updated" commit message will be ready to get your 
> ack?

I think so, albeit I haven't fully settled yet whether to push back
on the ARM folks not wanting to introduce M2P.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel