All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Sean Christopherson <seanjc@google.com>,
	"Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/8] KVM: nSVM: Sync next_rip field from vmcb12 to vmcb02
Date: Wed, 20 Apr 2022 18:33:07 +0200	[thread overview]
Message-ID: <41d956ab-3d25-2c2f-8b1a-2c49e03b4df4@redhat.com> (raw)
In-Reply-To: <YmAxqrbMRx76Ye5a@google.com>

On 4/20/22 18:15, Sean Christopherson wrote:
>>> Let's just require X86_FEATURE_NRIPS, either in general or just to
>>> enable nested virtualiazation
>> 👍
> Hmm, so requiring NRIPS for nested doesn't actually buy us anything.  KVM still
> has to deal with userspace hiding NRIPS from L1, so unless I'm overlooking something,
> the only change would be:
> 
> diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> index bdf8375a718b..7bed4e05aaea 100644
> --- a/arch/x86/kvm/svm/nested.c
> +++ b/arch/x86/kvm/svm/nested.c
> @@ -686,7 +686,7 @@ static void nested_vmcb02_prepare_control(struct vcpu_svm *svm,
>           */
>          if (svm->nrips_enabled)
>                  vmcb02->control.next_rip    = svm->nested.ctl.next_rip;
> -       else if (boot_cpu_has(X86_FEATURE_NRIPS))
> +       else
>                  vmcb02->control.next_rip    = vmcb12_rip;
> 
>          if (is_evtinj_soft(vmcb02->control.event_inj)) {
> 
> And sadly, because SVM doesn't provide the instruction length if an exit occurs
> while vectoring a software interrupt/exception, making NRIPS mandatory doesn't buy
> us much either.
> 
> I believe the below diff is the total savings (plus the above nested thing) against
> this series if NRIPS is mandatory (ignoring the setup code, which is a wash).  It
> does eliminate the rewind in svm_complete_soft_interrupt() and the funky logic in
> svm_update_soft_interrupt_rip(), but that's it AFAICT.  The most obnoxious code of
> having to unwind EMULTYPE_SKIP when retrieving the next RIP for software int/except
> injection doesn't go away:-(
> 
> I'm not totally opposed to requiring NRIPS, but I'm not in favor of it either.

Yeah, you're right.  However:

* the rewind might already be worth it;

* if we require NRIPS for nested, we can also assume that the SVM save 
state data has a valid next_rip; even if !svm->nrips_enabled.  There's 
the pesky issue of restoring from an old system that did not have NRIPS, 
but let's assume for now that NRIPS was set on the source as well.

Paolo

  reply	other threads:[~2022-04-20 16:33 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-02  1:08 [PATCH 0/8] KVM: SVM: Fix soft int/ex re-injection Sean Christopherson
2022-04-02  1:08 ` [PATCH 1/8] KVM: nSVM: Sync next_rip field from vmcb12 to vmcb02 Sean Christopherson
2022-04-04  9:54   ` Maxim Levitsky
2022-04-04 16:50   ` Maciej S. Szmigiero
2022-04-04 17:21     ` Sean Christopherson
2022-04-04 17:45       ` Maciej S. Szmigiero
2022-04-20 15:00       ` Paolo Bonzini
2022-04-20 15:05         ` Maciej S. Szmigiero
2022-04-20 16:15           ` Sean Christopherson
2022-04-20 16:33             ` Paolo Bonzini [this message]
2022-04-20 16:44               ` Sean Christopherson
2022-04-02  1:08 ` [PATCH 2/8] KVM: SVM: Downgrade BUG_ON() to WARN_ON() in svm_inject_irq() Sean Christopherson
2022-04-02  1:08 ` [PATCH 3/8] KVM: SVM: Unwind "speculative" RIP advancement if INTn injection "fails" Sean Christopherson
2022-04-04 10:03   ` Maxim Levitsky
2022-04-20 15:01   ` Paolo Bonzini
2022-04-02  1:08 ` [PATCH 4/8] KVM: SVM: Stuff next_rip on emualted INT3 injection if NRIPS is supported Sean Christopherson
2022-04-04 12:00   ` Maxim Levitsky
2022-04-02  1:09 ` [PATCH 5/8] KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction Sean Christopherson
2022-04-04 12:12   ` Maxim Levitsky
2022-04-04 16:49     ` Sean Christopherson
2022-04-04 16:53       ` Maciej S. Szmigiero
2022-04-04 19:33         ` Sean Christopherson
2022-04-04 19:50           ` Maciej S. Szmigiero
2022-04-04 19:54           ` Sean Christopherson
2022-04-04 20:46             ` Maciej S. Szmigiero
2022-04-04 20:44       ` Maciej S. Szmigiero
2022-04-06  1:48         ` Sean Christopherson
2022-04-06 13:13           ` Maciej S. Szmigiero
2022-04-06 17:10             ` Sean Christopherson
2022-04-06 19:08               ` Maciej S. Szmigiero
2022-04-06 19:48                 ` Sean Christopherson
2022-04-06 20:30                   ` Maciej S. Szmigiero
2022-04-06 20:52                     ` Sean Christopherson
2022-04-06 22:34                       ` Maciej S. Szmigiero
2022-04-06 23:03                         ` Sean Christopherson
2022-04-07 15:32                           ` Maciej S. Szmigiero
2022-04-02  1:09 ` [PATCH 6/8] KVM: SVM: Re-inject INTn instead of retrying the insn on "failure" Sean Christopherson
2022-04-04 17:14   ` Sean Christopherson
2022-04-04 20:27   ` Maciej S. Szmigiero
2022-04-02  1:09 ` [PATCH 7/8] KVM: x86: Trace re-injected exceptions Sean Christopherson
2022-04-04 12:14   ` Maxim Levitsky
2022-04-04 16:14     ` Sean Christopherson
2022-04-02  1:09 ` [PATCH 8/8] KVM: selftests: nSVM: Add svm_nested_soft_inject_test Sean Christopherson
2022-04-04 12:27   ` Maxim Levitsky
2022-04-04 16:59     ` Maciej S. Szmigiero

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=41d956ab-3d25-2c2f-8b1a-2c49e03b4df4@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mail@maciej.szmigiero.name \
    --cc=seanjc@google.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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.