Re: [Xen-devel] [PATCH-for-4.13 v2] x86/mm: don't needlessly veto migration

[Jan Beulich <jbeulich@xxxxxxxx>]

On 01.10.2019 17:11, Paul Durrant wrote:
> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
> domain, migration may be needlessly vetoed due to the check of
> is_iommu_enabled() in paging_log_dirty_enable().
> There is actually no need to prevent logdirty from being enabled unless
> devices are assigned to a domain and that domain is sharing HAP mappings
> with the IOMMU (in which case disabling write permissions in the P2M may
> cause DMA faults). It is quite possible that some assigned devices may
> provide information about which pages may have been dirtied by DMA via
> an API exported by their managing emulator. Thus Xen's logdirty map is only
> one source of information that may be available to the toolstack when
> performing a migration and hence it is the toolstack that is best placed
> to decide under what circumstances it can be performed, not the hypervisor.

While I'm happy about the extended description, it's still written in
a way suggesting that this is the only possible way of viewing things.
As expressed by George and me, putting the hypervisor in a position to
be able to judge is at least an alternative worth considering.

What's worse though - you don't go all the way to the end of what your
argumentation would lead to: There's no reason for Xen to veto the
request then even in the shared page table case. The only device
assigned to a guest in question may be doing DMA reads only. Following
your reasoning, Xen shouldn't be getting in the way then either. Once
again the situation could be taken care of by informing Xen about this
property of a device (assuming it can't tell all by itself).

Jan

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