All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Marc Zyngier <maz@kernel.org>, Guo Ren <guoren@kernel.org>,
	Nick Hu <nickhu@andestech.com>, Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Juergen Gross <jgross@suse.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, linux-csky@vger.kernel.org,
	linux-riscv@lists.infradead.org, kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Artem Kashkanov <artem.kashkanov@intel.com>,
	Like Xu <like.xu.linux@gmail.com>,
	Zhu Lingshan <lingshan.zhu@intel.com>
Subject: Re: [PATCH v2 00/13] perf: KVM: Fix, optimize, and clean up callbacks
Date: Fri, 17 Sep 2021 16:53:52 +0000	[thread overview]
Message-ID: <YUTIIG4ZCKMbqrFi@google.com> (raw)
In-Reply-To: <YURDqVZ1UXKCiKPV@hirez.programming.kicks-ass.net>

On Fri, Sep 17, 2021, Peter Zijlstra wrote:
> On Thu, Sep 16, 2021 at 09:37:43PM +0000, Sean Christopherson wrote:
> So I don't mind exporting __static_call_return0, but exporting a raw
> static_call is much like exporting a function pointer :/

Ya, that part is quite gross.

> > The unregister path would also need its own synchronize_rcu().  In general, I
> > don't love duplicating the logic, but it's not the end of the world.
> > 
> > Either way works for me.  Paolo or Peter, do either of you have a preference?
> 
> Can we de-feature kvm as a module and only have this PT functionality
> when built-in? :-)

I agree that many of the for-KVM exports are ugly, especially several of the
perf exports, but I will fight tooth and nail to keep KVM-as-a-module.  It is
invaluable for development and testing, and in the not-too-distant future there
is KVM-maintenance related functionality that we'd like to implement that relies
on KVM being a module.

I would be more than happy to help explore approaches that reduce the for-KVM
exports, but I am strongly opposed to defeaturing KVM-as-a-module.  I have a few
nascent ideas for eliminating a handful of a random exports, but no clever ideas
for eliminating perf's for-KVM exports.

WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Marc Zyngier <maz@kernel.org>, Guo Ren <guoren@kernel.org>,
	Nick Hu <nickhu@andestech.com>, Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Juergen Gross <jgross@suse.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, linux-csky@vger.kernel.org,
	linux-riscv@lists.infradead.org, kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Artem Kashkanov <artem.kashkanov@intel.com>,
	Like Xu <like.xu.linux@gmail.com>,
	Zhu Lingshan <lingshan.zhu@intel.com>
Subject: Re: [PATCH v2 00/13] perf: KVM: Fix, optimize, and clean up callbacks
Date: Fri, 17 Sep 2021 16:53:52 +0000	[thread overview]
Message-ID: <YUTIIG4ZCKMbqrFi@google.com> (raw)
In-Reply-To: <YURDqVZ1UXKCiKPV@hirez.programming.kicks-ass.net>

On Fri, Sep 17, 2021, Peter Zijlstra wrote:
> On Thu, Sep 16, 2021 at 09:37:43PM +0000, Sean Christopherson wrote:
> So I don't mind exporting __static_call_return0, but exporting a raw
> static_call is much like exporting a function pointer :/

Ya, that part is quite gross.

> > The unregister path would also need its own synchronize_rcu().  In general, I
> > don't love duplicating the logic, but it's not the end of the world.
> > 
> > Either way works for me.  Paolo or Peter, do either of you have a preference?
> 
> Can we de-feature kvm as a module and only have this PT functionality
> when built-in? :-)

I agree that many of the for-KVM exports are ugly, especially several of the
perf exports, but I will fight tooth and nail to keep KVM-as-a-module.  It is
invaluable for development and testing, and in the not-too-distant future there
is KVM-maintenance related functionality that we'd like to implement that relies
on KVM being a module.

I would be more than happy to help explore approaches that reduce the for-KVM
exports, but I am strongly opposed to defeaturing KVM-as-a-module.  I have a few
nascent ideas for eliminating a handful of a random exports, but no clever ideas
for eliminating perf's for-KVM exports.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Marc Zyngier <maz@kernel.org>, Guo Ren <guoren@kernel.org>,
	Nick Hu <nickhu@andestech.com>, Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Juergen Gross <jgross@suse.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, linux-csky@vger.kernel.org,
	linux-riscv@lists.infradead.org, kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Artem Kashkanov <artem.kashkanov@intel.com>,
	Like Xu <like.xu.linux@gmail.com>,
	Zhu Lingshan <lingshan.zhu@intel.com>
Subject: Re: [PATCH v2 00/13] perf: KVM: Fix, optimize, and clean up callbacks
Date: Fri, 17 Sep 2021 16:53:52 +0000	[thread overview]
Message-ID: <YUTIIG4ZCKMbqrFi@google.com> (raw)
In-Reply-To: <YURDqVZ1UXKCiKPV@hirez.programming.kicks-ass.net>

On Fri, Sep 17, 2021, Peter Zijlstra wrote:
> On Thu, Sep 16, 2021 at 09:37:43PM +0000, Sean Christopherson wrote:
> So I don't mind exporting __static_call_return0, but exporting a raw
> static_call is much like exporting a function pointer :/

Ya, that part is quite gross.

> > The unregister path would also need its own synchronize_rcu().  In general, I
> > don't love duplicating the logic, but it's not the end of the world.
> > 
> > Either way works for me.  Paolo or Peter, do either of you have a preference?
> 
> Can we de-feature kvm as a module and only have this PT functionality
> when built-in? :-)

I agree that many of the for-KVM exports are ugly, especially several of the
perf exports, but I will fight tooth and nail to keep KVM-as-a-module.  It is
invaluable for development and testing, and in the not-too-distant future there
is KVM-maintenance related functionality that we'd like to implement that relies
on KVM being a module.

I would be more than happy to help explore approaches that reduce the for-KVM
exports, but I am strongly opposed to defeaturing KVM-as-a-module.  I have a few
nascent ideas for eliminating a handful of a random exports, but no clever ideas
for eliminating perf's for-KVM exports.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Wanpeng Li <wanpengli@tencent.com>,
	kvm@vger.kernel.org,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Guo Ren <guoren@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	linux-riscv@lists.infradead.org,
	Vincent Chen <deanbo422@gmail.com>, Jiri Olsa <jolsa@redhat.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	xen-devel@lists.xenproject.org, Marc Zyngier <maz@kernel.org>,
	Joerg Roedel <joro@8bytes.org>,
	x86@kernel.org, linux-csky@vger.kernel.org,
	kvmarm@lists.cs.columbia.edu, Ingo Molnar <mingo@redhat.com>,
	Like Xu <like.xu.linux@gmail.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Zhu Lingshan <lingshan.zhu@intel.com>,
	Will Deacon <will@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Borislav Petkov <bp@alien8.de>, Greentime Hu <green.hu@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Artem Kashkanov <artem.kashkanov@intel.com>,
	linux-arm-kernel@lists.infradead.org,
	Jim Mattson <jmattson@google.com>,
	Juergen Gross <jgross@suse.com>, Nick Hu <nickhu@andestech.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH v2 00/13] perf: KVM: Fix, optimize, and clean up callbacks
Date: Fri, 17 Sep 2021 16:53:52 +0000	[thread overview]
Message-ID: <YUTIIG4ZCKMbqrFi@google.com> (raw)
In-Reply-To: <YURDqVZ1UXKCiKPV@hirez.programming.kicks-ass.net>

On Fri, Sep 17, 2021, Peter Zijlstra wrote:
> On Thu, Sep 16, 2021 at 09:37:43PM +0000, Sean Christopherson wrote:
> So I don't mind exporting __static_call_return0, but exporting a raw
> static_call is much like exporting a function pointer :/

Ya, that part is quite gross.

> > The unregister path would also need its own synchronize_rcu().  In general, I
> > don't love duplicating the logic, but it's not the end of the world.
> > 
> > Either way works for me.  Paolo or Peter, do either of you have a preference?
> 
> Can we de-feature kvm as a module and only have this PT functionality
> when built-in? :-)

I agree that many of the for-KVM exports are ugly, especially several of the
perf exports, but I will fight tooth and nail to keep KVM-as-a-module.  It is
invaluable for development and testing, and in the not-too-distant future there
is KVM-maintenance related functionality that we'd like to implement that relies
on KVM being a module.

I would be more than happy to help explore approaches that reduce the for-KVM
exports, but I am strongly opposed to defeaturing KVM-as-a-module.  I have a few
nascent ideas for eliminating a handful of a random exports, but no clever ideas
for eliminating perf's for-KVM exports.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  reply	other threads:[~2021-09-17 16:54 UTC|newest]

Thread overview: 130+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-28  0:35 [PATCH v2 00/13] perf: KVM: Fix, optimize, and clean up callbacks Sean Christopherson
2021-08-28  0:35 ` Sean Christopherson
2021-08-28  0:35 ` Sean Christopherson
2021-08-28  0:35 ` Sean Christopherson
2021-08-28  0:35 ` Sean Christopherson
2021-08-28  0:35 ` [PATCH v2 01/13] perf: Ensure perf_guest_cbs aren't reloaded between !NULL check and deref Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28 19:44   ` Peter Zijlstra
2021-08-28 19:44     ` Peter Zijlstra
2021-08-28 19:44     ` Peter Zijlstra
2021-08-28 19:44     ` Peter Zijlstra
2021-09-16 21:41     ` Sean Christopherson
2021-09-16 21:41       ` Sean Christopherson
2021-09-16 21:41       ` Sean Christopherson
2021-09-16 21:41       ` Sean Christopherson
2021-08-28  0:35 ` [PATCH v2 02/13] KVM: x86: Register perf callbacks after calling vendor's hardware_setup() Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35 ` [PATCH v2 03/13] KVM: x86: Register Processor Trace interrupt hook iff PT enabled in guest Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35 ` [PATCH v2 04/13] perf: Stop pretending that perf can handle multiple guest callbacks Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35 ` [PATCH v2 05/13] perf: Force architectures to opt-in to " Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28 19:47   ` Peter Zijlstra
2021-08-28 19:47     ` Peter Zijlstra
2021-08-28 19:47     ` Peter Zijlstra
2021-08-28 19:47     ` Peter Zijlstra
2021-09-16 22:30     ` Sean Christopherson
2021-09-16 22:30       ` Sean Christopherson
2021-09-16 22:30       ` Sean Christopherson
2021-09-16 22:30       ` Sean Christopherson
2021-09-21 16:44     ` Paolo Bonzini
2021-09-21 16:44       ` Paolo Bonzini
2021-09-21 16:44       ` Paolo Bonzini
2021-09-21 16:44       ` Paolo Bonzini
2021-09-21 21:29       ` Sean Christopherson
2021-09-21 21:29         ` Sean Christopherson
2021-09-21 21:29         ` Sean Christopherson
2021-09-21 21:29         ` Sean Christopherson
2021-08-28  0:35 ` [PATCH v2 06/13] perf/core: Rework guest callbacks to prepare for static_call support Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35 ` [PATCH v2 07/13] perf/core: Use static_call to optimize perf_guest_info_callbacks Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35 ` [PATCH v2 08/13] KVM: x86: Drop current_vcpu for kvm_running_vcpu + kvm_arch_vcpu variable Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35 ` [PATCH v2 09/13] KVM: x86: More precisely identify NMI from guest when handling PMI Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35 ` [PATCH v2 10/13] KVM: Move x86's perf guest info callbacks to generic KVM Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35 ` [PATCH v2 11/13] KVM: x86: Move Intel Processor Trace interrupt handler to vmx.c Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35 ` [PATCH v2 12/13] KVM: arm64: Convert to the generic perf callbacks Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35 ` [PATCH v2 13/13] KVM: arm64: Drop perf.c and fold its tiny bits of code into arm.c / pmu.c Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28  0:35   ` Sean Christopherson
2021-08-28 20:13 ` [PATCH v2 00/13] perf: KVM: Fix, optimize, and clean up callbacks Peter Zijlstra
2021-08-28 20:13   ` Peter Zijlstra
2021-08-28 20:13   ` Peter Zijlstra
2021-08-28 20:13   ` Peter Zijlstra
2021-09-16 21:37   ` Sean Christopherson
2021-09-16 21:37     ` Sean Christopherson
2021-09-16 21:37     ` Sean Christopherson
2021-09-16 21:37     ` Sean Christopherson
2021-09-17  7:28     ` Peter Zijlstra
2021-09-17  7:28       ` Peter Zijlstra
2021-09-17  7:28       ` Peter Zijlstra
2021-09-17  7:28       ` Peter Zijlstra
2021-09-17 16:53       ` Sean Christopherson [this message]
2021-09-17 16:53         ` Sean Christopherson
2021-09-17 16:53         ` Sean Christopherson
2021-09-17 16:53         ` Sean Christopherson
2021-09-20 12:05       ` Paolo Bonzini
2021-09-20 12:05         ` Paolo Bonzini
2021-09-20 12:05         ` Paolo Bonzini
2021-09-20 12:05         ` Paolo Bonzini
2021-09-20 12:22         ` Marc Zyngier
2021-09-20 12:22           ` Marc Zyngier
2021-09-20 12:22           ` Marc Zyngier
2021-09-20 12:22           ` Marc Zyngier
2021-09-20 13:18           ` Paolo Bonzini
2021-09-20 13:18             ` Paolo Bonzini
2021-09-20 13:18             ` Paolo Bonzini
2021-09-20 13:18             ` Paolo Bonzini
2021-09-20 13:40             ` Marc Zyngier
2021-09-20 13:40               ` Marc Zyngier
2021-09-20 13:40               ` Marc Zyngier
2021-09-20 13:40               ` Marc Zyngier
2021-09-20 18:22               ` Paolo Bonzini
2021-09-20 18:22                 ` Paolo Bonzini
2021-09-20 18:22                 ` Paolo Bonzini
2021-09-20 18:22                 ` 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=YUTIIG4ZCKMbqrFi@google.com \
    --to=seanjc@google.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexandru.elisei@arm.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=artem.kashkanov@intel.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=deanbo422@gmail.com \
    --cc=green.hu@gmail.com \
    --cc=guoren@kernel.org \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=jgross@suse.com \
    --cc=jmattson@google.com \
    --cc=jolsa@redhat.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=like.xu.linux@gmail.com \
    --cc=lingshan.zhu@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=nickhu@andestech.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sstabellini@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.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.