From: Paolo Bonzini <pbonzini@redhat.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>,
Wanpeng Li <kernellwp@gmail.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
Haiwei Li <lihaiwei@tencent.com>
Subject: Re: [PATCH v2] KVM: X86: Ultra fast single target IPI fastpath
Date: Fri, 10 Apr 2020 17:50:35 +0200 [thread overview]
Message-ID: <f51251cc-885e-2f7a-b18d-faa76db15b87@redhat.com> (raw)
In-Reply-To: <20200410153539.GD22482@linux.intel.com>
On 10/04/20 17:35, Sean Christopherson wrote:
> IMO, this should come at the very end of vmx_vcpu_run(). At a minimum, it
> needs to be moved below the #MC handling and below
>
> if (vmx->fail || (vmx->exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY))
> return;
Why? It cannot run in any of those cases, since the vmx->exit_reason
won't match.
> KVM more or less assumes vmx->idt_vectoring_info is always valid, and it's
> not obvious that a generic fastpath call can safely run before
> vmx_complete_interrupts(), e.g. the kvm_clear_interrupt_queue() call.
Not KVM, rather vmx.c. You're right about a generic fastpath, but in
this case kvm_irq_delivery_to_apic_fast is not touching VMX state; even
if you have a self-IPI, the modification of vCPU state is only scheduled
here and will happen later via either kvm_x86_ops.sync_pir_to_irr or
KVM_REQ_EVENT.
Paolo
next prev parent reply other threads:[~2020-04-10 15:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-10 1:03 [PATCH v2] KVM: X86: Ultra fast single target IPI fastpath Wanpeng Li
2020-04-10 15:17 ` Paolo Bonzini
2020-04-13 1:43 ` Wanpeng Li
2020-04-10 15:35 ` Sean Christopherson
2020-04-10 15:50 ` Paolo Bonzini [this message]
2020-04-10 17:47 ` Sean Christopherson
2020-04-10 17:47 ` [PATCH v3 1/2] KVM: VMX: Optimize handling of VM-Entry failures in vmx_vcpu_run() Sean Christopherson
2020-04-10 17:47 ` [PATCH v3 2/2] KVM: X86: Ultra fast single target IPI fastpath Sean Christopherson
2020-04-10 18:43 ` [PATCH v2] " Paolo Bonzini
2020-04-11 0:34 ` Wanpeng Li
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=f51251cc-885e-2f7a-b18d-faa76db15b87@redhat.com \
--to=pbonzini@redhat.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kernellwp@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=lihaiwei@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sean.j.christopherson@intel.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.