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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.05.17 at 21:52, <julien.grall@xxxxxxx> wrote:
> On 05/12/2017 03:31 PM, Jan Beulich wrote:
>>>>> On 10.05.17 at 16:03, <olekstysh@xxxxxxxxx> wrote:
>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
>>>
>>> The presence of this flag lets us know that the guest
>>> has devices which will most likely be used for passthrough
>>> and as the result the use of IOMMU is expected for this domain.
>>> In that case we have to call iommu_construct(), actually
>>> what the real assign_device call usually does.
>>>
>>> As iommu_domain_init() is called with use_iommu flag being forced
>>> to false for now, no functional change is intended for both ARM and x86.
>>>
>>> Basically, this patch is needed for non-shared IOMMUs on ARM only
>>> since the non-shared IOMMUs on x86 are ok if iommu_construct() is called
>>> later. But, in order to be more generic and for possible future optimization
>>> make this change appliable for both platforms.
>>
>> I continue to be unconvinced that this is wanted / needed, as I
>> continue to not see why shared vs unshared really matters here.
>> After all we have both modes working on x86 without this flag.
> 
> Well on x86 you allocate the page table on the fly in the unsharing 
> case. This is only useful if you don't know whether a domain will have 
> device assigned (e.g hotplug case).
> 
> When you know that the domain will have device pass-throughed, you can 
> populate the IOMMU page tables before hand avoiding to have to go 
> through the list of page at the first assigned device.
> 
> In embedded platform hotplug is likely to be inexistent. For servers, I 
> don't know but likely page tables are going to be shared (or as I 
> mentioned earlier partially shared).
> 
> So I don't see any benefit of the current code over populating the IOMMU 
> page tables from the beginning.

Interesting. To me, the primary benefit is that we wouldn't need to
introduce new code to handle yet another case specially. Anyway,
the changes in this patch are simple enough, so I don't mean to
block it despite being unconvinced of the basic idea.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel