[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH-for-4.13] x86/mm: don't needlessly veto migration
On 01.10.2019 10:52, Paul Durrant wrote: >> -----Original Message----- >> From: Jan Beulich <jbeulich@xxxxxxxx> >> Sent: 01 October 2019 09:46 >> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx> >> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Andrew Cooper >> <Andrew.Cooper3@xxxxxxxxxx>; Roger Pau Monne >> <roger.pau@xxxxxxxxxx>; George Dunlap <George.Dunlap@xxxxxxxxxx>; Juergen >> Gross <jgross@xxxxxxxx>; Wei >> Liu <wl@xxxxxxx> >> Subject: Re: [Xen-devel] [PATCH-for-4.13] x86/mm: don't needlessly veto >> migration >> >> On 01.10.2019 10:28, 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). >> >> But that's taking into account only half of the reason of the >> exclusion. The other half is that assigned devices may cause pages >> to be dirtied behind the back of the log-dirty logic. > > But that's no reason to veto logdirty. Some devices have drivers (in dom0) > which can extract DMA dirtying information and set dirty tracking > information appropriately. It still needs a positive identification then: Such drivers should tell Xen for which specific devices such information is going to be provided. I also wonder what interface I would have forgot about that would allow such a driver to propagate dirtying information in the first place: XEN_DMOP_modified_memory is for emulators only aiui, and does not provide a means for Xen to actively query dirtied state (or request updating thereof) of pages owned by a domain (as would be needed at least on the XEN_DOMCTL_SHADOW_LOGDIRTY_FINAL invocation). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |