> On 13 Nov 2018, at 2:07, Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > 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. Agreed. Nice addition :) Thanks, -Liran
