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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 01 October 2019 10:19
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap 
> <George.Dunlap@xxxxxxxxxx>; Roger Pau
> Monne <roger.pau@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; 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: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.

Why does the hypervisor need have the right of veto though? Surely it is the 
toolstack that should decide whether a VM is migratable in the presence of 
assigned h/w. Xen need only be concerned with the integrity of the host, which 
is why the check for ETP sharing remains.

> 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).

XEN_DMOP_modified_memory is indeed the interface. After each round of live 
memory copy, the toolstack can use an 'emulator' process running in dom0 to 
query the assigned device for pages dirtied by DMA and then add those into the 
set of pages to be copied in the next round. Similarly, prior to final memory 
copy, the devices is quiesced (i.e. bus master it turned off) and then the 
final set of dirtied pages is determined.

 Paul

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