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}.
Jan
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
