From: Sean Christopherson <seanjc@google.com>
To: 黄科乐 <huangkele@bytedance.com>
Cc: Chao Gao <chao.gao@intel.com>,
zhenwei pi <pizhenwei@bytedance.com>,
Wanpeng Li <kernellwp@gmail.com>,
Maxim Levitsky <mlevitsk@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
chaiwen.cc@bytedance.com, xieyongji@bytedance.com,
dengliang.1214@bytedance.com, Wanpeng Li <wanpengli@tencent.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
the arch/x86 maintainers <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>, kvm <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [External] Re: Re: [RFC] KVM: x86: SVM: don't expose PV_SEND_IPI feature with AVIC
Date: Tue, 16 Nov 2021 15:57:52 +0000 [thread overview]
Message-ID: <YZPVAHMp+aIaEkXT@google.com> (raw)
In-Reply-To: <CAKUug92xp7mU_KB66jGtdYRhgQpgfCm67r+3kMOMdbrGOrTQcA@mail.gmail.com>
On Tue, Nov 16, 2021, 黄科乐 wrote:
> > The recently posted Intel IPI virtualization will accelerate unicast
> > ipi but not broadcast ipis, AMD AVIC accelerates unicast ipi well but
> > accelerates broadcast ipis worse than pv ipis. Could we just handle
> > unicast ipi here?
>
> Thanks for the explanation! It is true that AVIC does not always perform
> better
> than PV IPI, actually not even swx2apic.
>
> > So agree with Wanpeng's point, is it possible to separate single IPI and
> > broadcast IPI on a hardware acceleration platform?
>
>
> > how about just correcting the logic for xapic:
>
> > From 13447b221252b64cd85ed1329f7d917afa54efc8 Mon Sep 17 00:00:00 2001
> > From: Jiaqing Zhao <jiaqing.zhao@intel.com>
> > Date: Fri, 9 Apr 2021 13:53:39 +0800
> > Subject: [PATCH 1/2] x86/apic/flat: Add specific send IPI logic
>
> > Currently, apic_flat.send_IPI() uses default_send_IPI_single(), which
> > is a wrapper of apic->send_IPI_mask(). Since commit aaffcfd1e82d
> > ("KVM: X86: Implement PV IPIs in linux guest"), KVM PV IPI driver will
> > override apic->send_IPI_mask(), and may cause unwated side effects.
>
> > This patch removes such side effects by creating a specific send_IPI
> > method.
>
> > Signed-off-by: Jiaqing Zhao <jiaqing.zhao@intel.com>
>
> Actually, I think this issue is more about how to sort out the relationship
> between AVIC and PV IPI. As far as I understand, currently, no matter
> the option from userspace or the determination made in kernel works
> in some way, but not in the migration scenario. For instance, migration with
> AVIC feature changes can make guests lose the PV IPI feature needlessly.
> Besides, the current patch is not consistent with
> KVM_CAP_ENFORCE_PV_FEATURE_CPUID.
> Paolo's advice about using a new hint shall work well. Currently try
> working on it.
IIUC, you want to have the guest switch between AVIC and PV IPI when the guest
is migrated? That doesn't require a new hint, it would be just as easy for the
host to manipulate CPUID.KVM_FEATURE_PV_SEND_IPI as it would a new CPUID hint.
The real trick will be getting the guest to be aware of the CPUID and reconfigure
it's APIC setup on the fly.
Or did I misundersetand what you meant by "migration with AVIC feature changes"?
next prev parent reply other threads:[~2021-11-16 15:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-08 9:59 [RFC] KVM: x86: SVM: don't expose PV_SEND_IPI feature with AVIC Kele Huang
2021-11-08 10:30 ` Paolo Bonzini
2021-11-08 11:08 ` Maxim Levitsky
2021-11-08 11:14 ` zhenwei pi
2021-11-08 11:18 ` Paolo Bonzini
2021-11-16 2:48 ` Wanpeng Li
2021-11-16 2:56 ` zhenwei pi
2021-11-16 9:06 ` Chao Gao
2021-11-16 9:30 ` [External] " 黄科乐
2021-11-16 9:30 ` Wanpeng Li
[not found] ` <CAKUug92xp7mU_KB66jGtdYRhgQpgfCm67r+3kMOMdbrGOrTQcA@mail.gmail.com>
2021-11-16 15:57 ` Sean Christopherson [this message]
2021-11-08 10:45 ` Vitaly Kuznetsov
2021-11-16 2:04 ` 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=YZPVAHMp+aIaEkXT@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=chaiwen.cc@bytedance.com \
--cc=chao.gao@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dengliang.1214@bytedance.com \
--cc=hpa@zytor.com \
--cc=huangkele@bytedance.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kernellwp@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pizhenwei@bytedance.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
--cc=xieyongji@bytedance.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.