All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Michael Roth <michael.roth@amd.com>,
	Alexey Kardashevskiy <aik@amd.com>
Subject: Re: [PATCH 0/8] KVM: SVM: Clean up VMRUN=>#VMEXIT assembly
Date: Mon, 26 Feb 2024 14:02:32 -0600	[thread overview]
Message-ID: <4f2d0790-fcd5-48cd-b299-ba90307ef103@amd.com> (raw)
In-Reply-To: <20240223204233.3337324-1-seanjc@google.com>

On 2/23/24 14:42, Sean Christopherson wrote:
> Clean up SVM's enter/exit assembly code so that it can be compiled
> without OBJECT_FILES_NON_STANDARD.  The "standard" __svm_vcpu_run() can't
> be made 100% bulletproof, as RBP isn't restored on #VMEXIT, but that's
> also the case for __vmx_vcpu_run(), and getting "close enough" is better
> than not even trying.
> 
> As for SEV-ES, after yet another refresher on swap types, I realized KVM
> can simply let the hardware restore registers after #VMEXIT, all that's
> missing is storing the current values to the host save area (I learned the
> hard way that they are swap Type B, *sigh*).  Unless I'm missing something,
> this provides 100% accuracy when using stack frames for unwinding, and
> requires less assembly (though probably not fewer code bytes; I didn't check).
> 
> In between, build the SEV-ES code iff CONFIG_KVM_AMD_SEV=y, and yank out
> "support" for 32-bit kernels, which was unncessarily polluting the code.
> 
> I'm pretty sure I actually managed to test all of this, thanks to the SEV-ES
> smoke selftests, and a bit of hacking to disable V_SPEC_CTRL, passthrough
> SPEC_CTRL unconditionally, and have the selftests W/R SPEC_CTRL from its
> guest.
> 
> Sean Christopherson (8):
>    KVM: SVM: Create a stack frame in __svm_vcpu_run() for unwinding
>    KVM: SVM: Wrap __svm_sev_es_vcpu_run() with #ifdef CONFIG_KVM_AMD_SEV
>    KVM: SVM: Drop 32-bit "support" from __svm_sev_es_vcpu_run()
>    KVM: SVM: Clobber RAX instead of RBX when discarding
>      spec_ctrl_intercepted
>    KVM: SVM: Save/restore non-volatile GPRs in SEV-ES VMRUN via host save
>      area
>    KVM: SVM: Save/restore args across SEV-ES VMRUN via host save area
>    KVM: SVM: Create a stack frame in __svm_sev_es_vcpu_run()
>    KVM: x86: Stop compiling vmenter.S with OBJECT_FILES_NON_STANDARD
> 
>   arch/x86/kvm/Makefile      |  4 --
>   arch/x86/kvm/svm/svm.c     | 17 ++++---
>   arch/x86/kvm/svm/svm.h     |  3 +-
>   arch/x86/kvm/svm/vmenter.S | 97 +++++++++++++++++---------------------
>   4 files changed, 56 insertions(+), 65 deletions(-)

Nice cleanup, thanks!

For the series:
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>

> 
> 
> base-commit: ec1e3d33557babed2c2c2c7da6e84293c2f56f58

  parent reply	other threads:[~2024-02-26 20:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 20:42 [PATCH 0/8] KVM: SVM: Clean up VMRUN=>#VMEXIT assembly Sean Christopherson
2024-02-23 20:42 ` [PATCH 1/8] KVM: SVM: Create a stack frame in __svm_vcpu_run() for unwinding Sean Christopherson
2024-02-23 20:42 ` [PATCH 2/8] KVM: SVM: Wrap __svm_sev_es_vcpu_run() with #ifdef CONFIG_KVM_AMD_SEV Sean Christopherson
2024-02-23 20:42 ` [PATCH 3/8] KVM: SVM: Drop 32-bit "support" from __svm_sev_es_vcpu_run() Sean Christopherson
2024-02-23 20:42 ` [PATCH 4/8] KVM: SVM: Clobber RAX instead of RBX when discarding spec_ctrl_intercepted Sean Christopherson
2024-02-23 20:42 ` [PATCH 5/8] KVM: SVM: Save/restore non-volatile GPRs in SEV-ES VMRUN via host save area Sean Christopherson
2024-02-23 20:42 ` [PATCH 6/8] KVM: SVM: Save/restore args across " Sean Christopherson
2024-02-23 20:42 ` [PATCH 7/8] KVM: SVM: Create a stack frame in __svm_sev_es_vcpu_run() Sean Christopherson
2024-02-23 20:42 ` [PATCH 8/8] KVM: x86: Stop compiling vmenter.S with OBJECT_FILES_NON_STANDARD Sean Christopherson
2024-02-26 20:02 ` Tom Lendacky [this message]
2024-04-10  0:19 ` [PATCH 0/8] KVM: SVM: Clean up VMRUN=>#VMEXIT assembly Sean Christopherson
2024-04-17 12:58   ` 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=4f2d0790-fcd5-48cd-b299-ba90307ef103@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=aik@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.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.