2018-01-15 16:33 GMT+08:00 Christoffer Dall <christoffer.dall@xxxxxxxxxx>: > On Fri, Jan 12, 2018 at 06:05:23PM +0000, James Morse wrote: >> On 15/12/17 03:30, gengdongjiu wrote: >> > On 2017/12/7 14:37, gengdongjiu wrote: > > [...] > >> >> (I recall someone saying migration is needed for any new KVM/cpu features, but I >> can't find the thread) >> > > I don't know of any hard set-in-stone rule for this, but I have > certainly argued that since migration is a popular technique in data > centers and often a key motivation behind using virtual machines as it > provides both load-balancing and high availability, we should think > about migration support for all features and state. Further, experience > has shown that retroactively trying to support migration can result in > really complex interfaces for saving/restoring state (see the ITS > ordering requirements in > Documentation/virtual/kvm/devices/arm-vgic-its.txt as an example) so > thinking about this problem when introducing functionality is a good > idea. yes, agree it. > > Of course, if there are really good arguments for having some state that > simply cannot be migrated, then that's fine, and we should just make > sure that userspace (e.g. QEMU) and higher level components in the > stack (libvirt, openstack, etc.) can detect this state being used, and > ideally enable/disable it, so that it can predict that a particular VM > cannot be migrated off a particular host, or between a particular set of > two hosts. As an example, migration is typically prohibited when using > VFIO direct device assignment, but userspace etc. are already aware of > this. Ok, I think this problem is similar to migrating a VM that uses an irqchip in userspace and has set the IRQ or FIQ lines using KVM_IRQ_LINE. > > As a final note, if we add support for some architectural feature, which > may be present on some particular hardware and/or implementation, if the > KVM support for said feature is automatically enabled (and not > selectively from userspace), I would push back quite strongly on > something that doesn't support migration, because it would effectively > prevent migration of VMs on ARM. Ok, got it. > > Thanks, > -Christoffer > _______________________________________________ > kvmarm mailing list > kvmarm@xxxxxxxxxxxxxxxxxxxxx > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
