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 11:15
> 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 11:36, Paul Durrant wrote:
> >> -----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.
> 
> While the tool stack is to decide, the hypervisor is expected to guarantee
> correct data coming back from XEN_DOMCTL_SHADOW_OP_{PEEK,CLEAN}.

For some definition of 'correct', yes, and I don't think that this change 
violates any definition I can find in the domctl header.

Note: there are already emulators that will be playing with the dirty map on an 
arbitrary and unsynchronized basis because they are emulating bus mastering h/w.

  Paul

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