From: Chao Gao <chao.gao@intel.com>
To: Jon Kohler <jon@nutanix.com>
Cc: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] KVM: X86: set EXITING_GUEST_MODE as soon as vCPU exits
Date: Wed, 30 Nov 2022 14:29:37 +0800 [thread overview]
Message-ID: <Y4b4UURccshroVV9@gao-cwp> (raw)
In-Reply-To: <20221129182226.82087-1-jon@nutanix.com>
On Tue, Nov 29, 2022 at 01:22:25PM -0500, Jon Kohler wrote:
>@@ -7031,6 +7042,18 @@ void noinstr vmx_update_host_rsp(struct vcpu_vmx *vmx, unsigned long host_rsp)
> void noinstr vmx_spec_ctrl_restore_host(struct vcpu_vmx *vmx,
> unsigned int flags)
> {
>+ struct kvm_vcpu *vcpu = &vmx->vcpu;
>+
>+ /* Optimize IPI reduction by setting mode immediately after vmexit
>+ * without a memmory barrier as this as not paired anywhere. vcpu->mode
>+ * is will be set to OUTSIDE_GUEST_MODE in x86 common code with a memory
>+ * barrier, after the host is done fully restoring various host states.
>+ * Since the rdmsr and wrmsr below are expensive, this must be done
>+ * first, so that the IPI suppression window covers the time dealing
>+ * with fixing up SPEC_CTRL.
>+ */
>+ vcpu->mode = EXITING_GUEST_MODE;
Does this break kvm_vcpu_kick()? IIUC, kvm_vcpu_kick() does nothing if
vcpu->mode is already EXITING_GUEST_MODE, expecting the vCPU will exit
guest mode. But ...
>+
> u64 hostval = this_cpu_read(x86_spec_ctrl_current);
>
> if (!cpu_feature_enabled(X86_FEATURE_MSR_SPEC_CTRL))
>diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>index 2835bd796639..0e0d228f3fa5 100644
>--- a/arch/x86/kvm/x86.c
>+++ b/arch/x86/kvm/x86.c
>@@ -2160,6 +2160,14 @@ fastpath_t handle_fastpath_set_msr_irqoff(struct kvm_vcpu *vcpu)
> data = kvm_read_edx_eax(vcpu);
> if (!handle_fastpath_set_tscdeadline(vcpu, data)) {
> kvm_skip_emulated_instruction(vcpu);
>+ /* Reset IN_GUEST_MODE since we're going to reenter
>+ * guest as part of this fast path. This is done as
>+ * an optimization without a memory barrier since
>+ * EXITING_GUEST_MODE is also set without a memory
>+ * barrier.
>+ */
>+ if (vcpu->mode == EXITING_GUEST_MODE)
>+ vcpu->mode = IN_GUEST_MODE;
... the vCPU enters guest mode again.
I believe mode transition from EXITING_GUEST_MODE to IN_GUEST_MODE
directly isn't valid for current KVM.
next prev parent reply other threads:[~2022-11-30 6:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 18:22 [PATCH] KVM: X86: set EXITING_GUEST_MODE as soon as vCPU exits Jon Kohler
2022-11-29 19:47 ` Maxim Levitsky
2022-11-29 19:56 ` Jon Kohler
2022-12-01 15:45 ` Maxim Levitsky
2022-11-30 6:29 ` Chao Gao [this message]
2022-11-30 14:07 ` Jon Kohler
2022-12-01 4:55 ` Chao Gao
2022-12-01 14:57 ` Jon Kohler
2022-12-01 19:17 ` Sean Christopherson
2022-12-05 15:09 ` Jon Kohler
2022-12-07 20:18 ` Sean Christopherson
2022-12-09 8:06 ` 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=Y4b4UURccshroVV9@gao-cwp \
--to=chao.gao@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jon@nutanix.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 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.