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

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

 




> 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






[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux