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

[Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>]

Hi Jan.

On Wed, Dec 6, 2017 at 6:51 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 25.07.17 at 19:26, <olekstysh@xxxxxxxxx> 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 patch itself looks mechanical enough that it could get my ack,
> but I really want to understand the background without having to
> dig out old discussions (which would be even more difficult for
> future archaeologists running into this change in a few years time).
>
> Jan
>

-- 
Regards,

Oleksandr Tyshchenko

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