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

From: Liran Alon <liran.alon@oracle.com>
To: "\"Daniel P. Berrangé\"" <berrange@redhat.com>
Cc: ehabkost@redhat.com, kvm@vger.kernel.org, mtosatti@redhat.com,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	rth@twiddle.net, jmattson@google.com
Subject: Re: [QEMU PATCH v2 0/2]: KVM: i386: Add support for save and restore nested state
Date: Tue, 13 Nov 2018 02:00:22 +0200	[thread overview]
Message-ID: <04AB82C1-F0AC-4BDB-A132-D39A49EA0A9A@oracle.com> (raw)
In-Reply-To: <20181112165437.GW3602@redhat.com>

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

-Liran

> 
> 
> Regards,
> Daniel
> -- 
> |: https://urldefense.proofpoint.com/v2/url?u=https-3A__berrange.com&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=eMOrT-7t7-tfRtTw2da9c1YTU0_tOFfkVIhj9mWv-Pc&s=DIzWfmRGWO1b6hzL9NRbIt41fiFcnPt0MC8917u4Qv0&e=      -o-    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.flickr.com_photos_dberrange&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=eMOrT-7t7-tfRtTw2da9c1YTU0_tOFfkVIhj9mWv-Pc&s=CjA-joyt2Y9t5B4YzIiupfY8EEO58m4vbmnd45adzFI&e= :|
> |: https://urldefense.proofpoint.com/v2/url?u=https-3A__libvirt.org&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=eMOrT-7t7-tfRtTw2da9c1YTU0_tOFfkVIhj9mWv-Pc&s=tD05tikOHMJhh_EeZ2Esoxb0oku3MPFmj-S2YHdUGm0&e=         -o-            https://urldefense.proofpoint.com/v2/url?u=https-3A__fstop138.berrange.com&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=eMOrT-7t7-tfRtTw2da9c1YTU0_tOFfkVIhj9mWv-Pc&s=YAh1WAoXQKEB6hkMmG6ZnJQETOFnq6eqQLmJokME80A&e= :|
> |: https://urldefense.proofpoint.com/v2/url?u=https-3A__entangle-2Dphoto.org&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=eMOrT-7t7-tfRtTw2da9c1YTU0_tOFfkVIhj9mWv-Pc&s=90Mm1Qb-SHe8P63xwGp6gzMU1I5DEW6YX0ttG6TL_7g&e=    -o-    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.instagram.com_dberrange&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=eMOrT-7t7-tfRtTw2da9c1YTU0_tOFfkVIhj9mWv-Pc&s=l4NrrDdRzPClvYQdxQdfIW0geHPWcukeyOGX8QapwYA&e= :|