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

[Jan Beulich <jbeulich@xxxxxxxx>]

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

Jan

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