qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Liran Alon <liran.alon@oracle.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Maran Wilson <maran.wilson@oracle.com>,
	qemu-devel@nongnu.org,
	Nikita Leshenko <nikita.leshchenko@oracle.com>
Subject: Re: [Qemu-devel] [PATCH 3/7] KVM: i386: Add support for KVM_CAP_EXCEPTION_PAYLOAD
Date: Sun, 16 Jun 2019 15:38:37 +0300	[thread overview]
Message-ID: <0144E234-98F2-4D05-B2AB-8DA23E418D46@oracle.com> (raw)
In-Reply-To: <EB7EDEC6-BD44-460E-B7B2-29060631E4FF@oracle.com>



> On 15 Jun 2019, at 3:57, Liran Alon <liran.alon@oracle.com> wrote:
> 
>> On 15 Jun 2019, at 3:42, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> 
>> From: Liran Alon <liran.alon@oracle.com>
>> 
>> +static bool is_vmx_enabled(CPUX86State *env)
>> +{
>> +    return (IS_INTEL_CPU(env) && (env->cr[4] & CR4_VMXE_MASK));
>> +}
>> +
>> +static bool is_svm_enabled(CPUX86State *env)
>> +{
>> +    return (IS_AMD_CPU(env) && (env->efer & MSR_EFER_SVME));
>> +}
>> +
>> +static bool is_nested_virt_enabled(CPUX86State *env)
>> +{
>> +    return (is_vmx_enabled(env) || is_svm_enabled(env));
>> +}
> 
> I have later realised that this nested_virt_enabled() function is not enough to determine if nested_state is required to be sent.
> This is because it may be that vCPU is running L2 but have momentarily entered SMM due to SMI.
> In this case, CR4 & MSR_EFER are saved in SMRAM and are set to 0 on entering to SMM.
> This means that in case (env->hflags & HF_SMM_MASK), we theoretically should have read saved CR4 & MSR_EFER from SMRAM.
> However, because we cannot reference guest memory at this point (Not valid in case we migrate guest in post-copy), I should change
> code to assume that in case (env->hflags & HF_SMM_MASK), we need to assume that nested-state is needed.
> This should break backwards-compatability migration only in very rare cases and therefore I think it should be sufficient.
> Any objections to this idea?
> 

Actually, this is even worse than I originally thought.
Even in case guest is not currently in SMM mode, if it’s in VMX non-root mode, the CR4 read here is L2 CR4. Not L1 CR4.
Therefore, CR4.VMXE doesn’t necessarily indicate if guest have nested-virtualization enabled. Same is true for MSR_EFER in case of SVM.

Putting this all together, in case kernel doesn’t support extracting nested-state, there is no decent way to know if guest is running nested-virtualization.
Which means that in theory we always need to fail migration in case kernel doesn’t support KVM_CAP_NESTED_STATE or KVM_CAP_EXCEPTION_PAYLOAD
and vCPU is exposed with VMX/SVM capability.

I can condition this behaviour with a flag that can be manipulated using QMP to allow user to indicate it wishes to migrate guest anyway in this case.
This however bring me back to the entire discussion I had with Dr. David Alan Gilbert on migration backwards compatibility in general and the fact that I believe
we should have a generic QMP command which allows to provide list of VMState subsections that can be ignored in migration…
See: https://www.mail-archive.com/qemu-devel@nongnu.org/msg622274.html

Paolo, What are your thoughts on how I would proceed with this?

-Liran



  reply	other threads:[~2019-06-16 12:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-15  0:42 [Qemu-devel] [PATCH preliminary 0/7] target-i386/kvm: live migration support for nested VMX Paolo Bonzini
2019-06-15  0:42 ` [Qemu-devel] [PATCH 1/7] KVM: i386: Use symbolic constant for #DB/#BP exception constants Paolo Bonzini
2019-06-15  0:46   ` Liran Alon
2019-06-15  0:42 ` [Qemu-devel] [PATCH 2/7] KVM: i386: Re-inject #DB to guest with updated DR6 Paolo Bonzini
2019-06-15  0:42 ` [Qemu-devel] [PATCH 3/7] KVM: i386: Add support for KVM_CAP_EXCEPTION_PAYLOAD Paolo Bonzini
2019-06-15  0:57   ` Liran Alon
2019-06-16 12:38     ` Liran Alon [this message]
2019-06-17 11:34       ` Liran Alon
2019-06-17 17:27         ` Paolo Bonzini
2019-06-18 22:38           ` Maran Wilson
2019-06-15  0:42 ` [Qemu-devel] [PATCH 4/7] linux-headers: import improved definition of KVM_GET/SET_NESTED_STATE structs Paolo Bonzini
2019-06-16  8:29   ` Liran Alon
2019-06-17 17:32     ` Paolo Bonzini
2019-06-17 17:44       ` Liran Alon
2019-06-15  0:42 ` [Qemu-devel] [PATCH 5/7] vmstate: Add support for kernel integer types Paolo Bonzini
2019-06-15  0:42 ` [Qemu-devel] [PATCH 6/7] KVM: i386: Add support for save and restore nested state Paolo Bonzini
2019-06-15  1:14   ` Liran Alon
2019-06-17 17:31     ` Paolo Bonzini
2019-06-15  0:42 ` [Qemu-devel] [PATCH 7/7] Revert "target/i386: kvm: add VMX migration blocker" Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0144E234-98F2-4D05-B2AB-8DA23E418D46@oracle.com \
    --to=liran.alon@oracle.com \
    --cc=maran.wilson@oracle.com \
    --cc=nikita.leshchenko@oracle.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).