On Mon, Nov 12, 2018 at 4:00 PM, Liran Alon <liran.alon@xxxxxxxxxx> wrote: > > >> On 12 Nov 2018, at 18:54, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: >> >> On Mon, Nov 12, 2018 at 04:50:54PM +0000, Dr. David Alan Gilbert wrote: >>> * Daniel P. Berrangé (berrange@xxxxxxxxxx) wrote: >>>> On Sun, Nov 04, 2018 at 11:19:57PM +0100, Paolo Bonzini wrote: >>>>> On 02/11/2018 17:54, Daniel P. Berrangé wrote: >>>>>> We have usually followed a rule that new machine types must not >>>>>> affect runability of a VM on a host. IOW new machine types should >>>>>> not introduce dependancies on specific kernels, or hardware features >>>>>> such as CPU flags. >>>>> >>>>>> Anything that requires a new kernel feature thus ought to be an >>>>>> opt-in config tunable on the CLI, separate from machine type >>>>>> choice. >>>>> >>>>> Unless someone tinkered with the module parameters, they could not even >>>>> use nested virtualization before 4.20. So for everyone else, "-cpu >>>>> ...,+vmx" does count as an "opt-in config tunable on the CLI" that >>>>> requires 4.20. >>>>> >>>>> For those that did tinker with module parameters, we can grandfather in >>>>> the old machine types, so that they can use nested virtualization with >>>>> no live migration support. For those that did not, however, I don't >>>>> think it makes sense to say "oh by the way I really want to be able to >>>>> migrate this VM" on the command line, or even worse on the monitor. >>>> >>>> IIUC, 4.20 is only required from POV of migration state. Is it thus >>>> possible to just register a migration blocker if QEMU is launched >>>> on a host with kernel < 4.20. >>>> >>>> Migration has always been busted historically, so those people using >>>> nested VMX already won't be hurt by not having ability to live migrate >>>> their VM, but could otherwise continue using them without being forced >>>> to upgrade their kernel to fix a feature they're not even using. >>> >>> Yes, although I am a bit worried we might have a population of users >>> that: >>> a) Have enabled nesting >>> b) Run VMs with vmx enabled >> >> >>> c) Don't normally actually run nested guests >>> d) Currently happily migrate. >> >> True, and (b) would include anyone using libvirt's host-model CPU. So if >> you enabled nesting, have host-model for all guests, but only use nesting >> in one of the guests, you'd be doomed. >> >> Is it possible for QEMU to determine if there are nested guests running or >> not and conditionally block migration appropriately to ensure safety ? > > > Only if kernel supports KVM_CAP_NESTED_STATE. > See my reply to Dave in this thread. You could still allow migration if CR4.VMXE is clear.
