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

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



On Thu, Dec 7, 2017 at 12:49 AM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
> Hi,
Hi Julien, Jan

>
>
> On 12/06/2017 07:53 PM, Oleksandr Tyshchenko wrote:
>>
>> 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 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
the current patch with "updated" commit message will be ready to get your ack?

>
>>>
>>> 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).
>
>
> Cheers,
>
> [1] https://lists.xen.org/archives/html/xen-devel/2017-05/msg01737.html
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

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

 


Rackspace

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