[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 09.10.2019 16:14, George Dunlap wrote:
> On 10/9/19 11:23 AM, Jürgen Groß wrote:
>>> Regardless of the merits of the change Andy wants to see, it's not a one
>>> that should be made during a feature freeze.
>>
>> Indeed. So either we take this patch or we have to revert the patch(es)
>> introducing the regression.
> 
> Actually, just chatting with Ian -- the worse issue ATM, AFAICT, is that
> the IOMMU is enabled for a guest which has neither asked for PCI
> devices, nor explicitly enabled it; and he's currently working on a fix
> for that.  Once that issue is fixed, then osstest should become
> unblocked again.
> 
> It is, arguably, not ideal to refuse to migrate a VM with IOMMU enabled
> but no devices attached; but if it only affected guests who had
> specifically requested the IOMMU be enabled, that wouldn't be so
> terrible.  (And in fact it has highlighted the other, more important issue.)
> 
> In summary, this patch is not strictly needed to get a push to osstest.
> 
> That said, the behavior in 4.12 was, as far as I can tell:
> 
> 1. If a guest had never had a PCI device assigned, Xen will allow
> logdirty to be enabled.
> 
> 2. If a guest has a PCI device assigned, Xen will not allow logdirty to
> be enabled (blocking migration).
> 
> 3. If a guest had a PCI device assigned in the past but does not have
> one now, Xen will also not allow logdirty to be enabled (blocking
> migration).

No - the connection previously was to whether IOMMU page tables
had been set up; these page tables would have been torn down
upon de-assignment of the last device, allowing migration again.
People actually use this behavior afaik, using a bond of a
passed through SR-IOV NIC and netfront provided device. To
migrate the VM, the SR-IOV NIC is taken away without the domain
losing network access, and a new one might then be assigned
again after migration.

The "IOMMU page tables set up" property was previously identical
to "has devices assigned", i.e. even before we could have used
has_arch_pdevs() instead of is_iommu_enabled().

Jan

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.