> -----Original Message----- > From: Jan Beulich <[email protected]> > Sent: 01 October 2019 11:15 > To: Paul Durrant <[email protected]> > Cc: Andrew Cooper <[email protected]>; George Dunlap > <[email protected]>; Roger Pau > Monne <[email protected]>; [email protected]; Juergen Gross > <[email protected]>; Wei Liu > <[email protected]> > 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 <[email protected]> > >> Sent: 01 October 2019 10:19 > >> To: Paul Durrant <[email protected]> > >> Cc: Andrew Cooper <[email protected]>; George Dunlap > >> <[email protected]>; Roger Pau > >> Monne <[email protected]>; [email protected]; Juergen > >> Gross <[email protected]>; Wei > Liu > >> <[email protected]> > >> 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 <[email protected]> > >>>> Sent: 01 October 2019 09:46 > >>>> To: Paul Durrant <[email protected]> > >>>> Cc: [email protected]; Andrew Cooper > >>>> <[email protected]>; Roger Pau Monne > >>>> <[email protected]>; George Dunlap <[email protected]>; > >>>> Juergen Gross > <[email protected]>; > >> Wei > >>>> Liu <[email protected]> > >>>> 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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
