Re: [Qemu-devel] [QEMU PATCH v2 0/2]: KVM: i386: Add support for save and restore nested state

[Jim Mattson]

On Mon, Nov 12, 2018 at 4:00 PM, Liran Alon <address@hidden> wrote:
>
>
>> On 12 Nov 2018, at 18:54, Daniel P. Berrangé <address@hidden> wrote:
>>
>> On Mon, Nov 12, 2018 at 04:50:54PM +0000, Dr. David Alan Gilbert wrote:
>>> * Daniel P. Berrangé (address@hidden) 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.