From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
jroedel@suse.de, mlevitsk@redhat.com
Subject: Re: [PATCH] KVM: nSVM: prepare guest save area while is_guest_mode is true
Date: Thu, 18 Feb 2021 10:12:42 -0800 [thread overview]
Message-ID: <YC6uGgKgImRnuhTA@google.com> (raw)
In-Reply-To: <cf1b338c-68bc-6e7e-1a10-98bc653d34ce@redhat.com>
On Thu, Feb 18, 2021, Paolo Bonzini wrote:
> On 18/02/21 18:42, Sean Christopherson wrote:
> > > The bug is present since commit 06fc7772690d ("KVM: SVM: Activate nested
> > > state only when guest state is complete", 2010-04-25). Unfortunately,
> > > it is not clear from the commit message what issue exactly led to the
> > > change back then. It was probably related to svm_set_cr0 however because
> > > the patch series cover letter[1] mentioned lazy FPU switching.
> >
> > Aha! It was indeed related to svm_set_cr0(). Specifically, the next patch,
> > commit 66a562f7e257 ("KVM: SVM: Make lazy FPU switching work with nested svm"),
> > added is_nested() checks in update_cr0_intercept() to merge L1's intercepts with
> > L0's intercepts.
>
> Yeah, the problem is I don't understand why 06fc7772690d fixed things in 11
> year old KVM instead of breaking them, because effectively this patch is
> reverting it.
11 year old KVM didn't grab a different VMCB when updating the intercepts, it
had already copied/merged L1's stuff to L0's VMCB, and then updated L0's VMCB
regardless of is_nested().
> I don't care _that_ much because so much has changed since then; the world
> switch logic is abstracted better nowadays, and it is easier to review the
> change. But it is weird, nevertheless.
>
> Paolo
>
next prev parent reply other threads:[~2021-02-18 18:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 16:28 [PATCH] KVM: nSVM: prepare guest save area while is_guest_mode is true Paolo Bonzini
2021-02-18 17:42 ` Sean Christopherson
2021-02-18 18:00 ` Paolo Bonzini
2021-02-18 18:12 ` Sean Christopherson [this message]
2021-02-18 18:28 ` Paolo Bonzini
2021-02-22 15:25 ` Vitaly Kuznetsov
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=YC6uGgKgImRnuhTA@google.com \
--to=seanjc@google.com \
--cc=jroedel@suse.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.