From: Chao Gao <chao.gao@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: wangguangju <wangguangju@baidu.com>,
pbonzini@redhat.com, vkuznets@redhat.com, wanpengli@tencent.com,
jmattson@google.com, joro@8bytes.org, kvm@vger.kernel.org,
dave.hansen@linux.intel.co, tglx@linutronix.de, mingo@redhat.com,
x86@kernel.org, linux-kernel@vger.kernel.orga
Subject: Re: [PATCH] KVM: x86: add a bool variable to distinguish whether to use PVIPI
Date: Tue, 14 Jun 2022 23:03:25 +0800 [thread overview]
Message-ID: <20220614150319.GA13174@gao-cwp> (raw)
In-Reply-To: <YqieGua0ouUePWol@google.com>
On Tue, Jun 14, 2022 at 02:41:30PM +0000, Sean Christopherson wrote:
>> PVIPI is mainly [*] for sending multi-cast IPIs. Intel IPI virtualization
>> can virtualize only uni-cast IPIs. Their use cases don't overlap. So, I
>> don't think it makes sense to disable PVIPI if intel IPI virtualization
>> is supported.
>>
>> The question actually is how to deal with the exceptional case below.
>> Considering the migration case Sean said below, it is hard to let VM
>> always work in the ideal way unless KVM notifies VM of migration and VM
>> changes its behavior on receiving such notifications. But since x2apic
>> has better performance than xapic, if VM cares about performance, it can
>> simply switch to x2apic mode. All things considered, I think the
>> performance gain isn't worth the complexity added. So, I prefer to leave
>> it as is.
>>
>> [*]: when linux guest is in *xapic* mode, it uses PVIPI to send uni-case IPI.
>
>Hmm, there are definitely guests that run xAPIC though, even if x2apic is supported.
>
>That said, I tend to agree that trying to handle this in KVM and/or the guest kernel
>is going to get messy. The easiest solution is for VMMs to not advertise PV IPIs
>when the VM is going to predominately run on hosts with IPIv.
But it will hurt multi-cast IPIs in VMs. IMO, a feasible solution is to add
a new hint to indicate IPI virtualization is enabled and VM uses native
interface (writes to ICR) to send uni-cast IPIs in xapic mode if it sees
the new hint.
next prev parent reply other threads:[~2022-06-14 15:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1655124522-42030-1-git-send-email-wangguangju@baidu.com>
2022-06-13 17:16 ` [PATCH] KVM: x86: add a bool variable to distinguish whether to use PVIPI Sean Christopherson
2022-06-14 2:54 ` Chao Gao
2022-06-14 14:41 ` Sean Christopherson
2022-06-14 15:03 ` Chao Gao [this message]
2022-06-15 4:21 ` 答复: " Wang,Guangju
2022-06-15 5:33 ` Chao Gao
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=20220614150319.GA13174@gao-cwp \
--to=chao.gao@intel.com \
--cc=dave.hansen@linux.intel.co \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.orga \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wangguangju@baidu.com \
--cc=wanpengli@tencent.com \
--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.