From: Will Deacon <will@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Quentin Perret <qperret@google.com>,
"moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)"
<linux-arm-kernel@lists.infradead.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE"
<devicetree@vger.kernel.org>,
kernel-team@android.com, Android KVM <android-kvm@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
open list <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>, Fuad Tabba <tabba@google.com>,
Marc Zyngier <maz@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
"open list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)"
<kvmarm@lists.cs.columbia.edu>
Subject: Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection
Date: Mon, 7 Dec 2020 11:10:14 +0000 [thread overview]
Message-ID: <20201207111013.GA4379@willie-the-truck> (raw)
In-Reply-To: <20201207110528.GA18365@C02TD0UTHF1T.local>
On Mon, Dec 07, 2020 at 11:05:45AM +0000, Mark Rutland wrote:
> On Mon, Dec 07, 2020 at 10:20:03AM +0000, Will Deacon wrote:
> > On Fri, Dec 04, 2020 at 06:01:52PM +0000, Quentin Perret wrote:
> > > On Thursday 03 Dec 2020 at 12:57:33 (+0000), Fuad Tabba wrote:
> > > <snip>
> > > > > +SYM_FUNC_START(__kvm_init_switch_pgd)
> > > > > + /* Turn the MMU off */
> > > > > + pre_disable_mmu_workaround
> > > > > + mrs x2, sctlr_el2
> > > > > + bic x3, x2, #SCTLR_ELx_M
> > > > > + msr sctlr_el2, x3
> > > > > + isb
> > > > > +
> > > > > + tlbi alle2
> > > > > +
> > > > > + /* Install the new pgtables */
> > > > > + ldr x3, [x0, #NVHE_INIT_PGD_PA]
> > > > > + phys_to_ttbr x4, x3
> > > > > +alternative_if ARM64_HAS_CNP
> > > > > + orr x4, x4, #TTBR_CNP_BIT
> > > > > +alternative_else_nop_endif
> > > > > + msr ttbr0_el2, x4
> > > > > +
> > > > > + /* Set the new stack pointer */
> > > > > + ldr x0, [x0, #NVHE_INIT_STACK_HYP_VA]
> > > > > + mov sp, x0
> > > > > +
> > > > > + /* And turn the MMU back on! */
> > > > > + dsb nsh
> > > > > + isb
> > > > > + msr sctlr_el2, x2
> > > > > + isb
> > > > > + ret x1
> > > > > +SYM_FUNC_END(__kvm_init_switch_pgd)
> > > > > +
> > > >
> > > > Should the instruction cache be flushed here (ic iallu), to discard
> > > > speculatively fetched instructions?
> > >
> > > Hmm, Will? Thoughts?
> >
> > The I-cache is physically tagged, so not sure what invalidation would
> > achieve here. Fuad -- what do you think could go wrong specifically?
>
> While the MMU is off, instruction fetches can be made from the PoC
> rather than the PoU, so where instructions have been modified/copied and
> not cleaned to the PoC, it's possible to fetch stale copies into the
> I-caches. The physical tag doesn't prevent that.
Oh yeah, we even have a comment about that in
idmap_kpti_install_ng_mappings(). Maybe we should wrap disable_mmu and
enable_mmu in some macros so we don't have to trip over this every time (and
this would mean we could get rid of pre_disable_mmu_workaround too).
> In the regular CPU boot paths, __enabble_mmu() has an IC IALLU after
> enabling the MMU to ensure that we get rid of anything stale (e.g. so
> secondaries don't miss ftrace patching, which is only cleaned to the
> PoU).
>
> That might not be a problem here, if things are suitably padded and
> never dynamically patched, but if so it's probably worth a comment.
It's fragile enough that we should just do the invalidation.
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE"
<devicetree@vger.kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Android KVM <android-kvm@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
open list <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>, Fuad Tabba <tabba@google.com>,
Marc Zyngier <maz@kernel.org>,
kernel-team@android.com,
"open list:KERNEL VIRTUAL MACHINE FOR ARM64 \(KVM/arm64\)"
<kvmarm@lists.cs.columbia.edu>,
"moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection
Date: Mon, 7 Dec 2020 11:10:14 +0000 [thread overview]
Message-ID: <20201207111013.GA4379@willie-the-truck> (raw)
In-Reply-To: <20201207110528.GA18365@C02TD0UTHF1T.local>
On Mon, Dec 07, 2020 at 11:05:45AM +0000, Mark Rutland wrote:
> On Mon, Dec 07, 2020 at 10:20:03AM +0000, Will Deacon wrote:
> > On Fri, Dec 04, 2020 at 06:01:52PM +0000, Quentin Perret wrote:
> > > On Thursday 03 Dec 2020 at 12:57:33 (+0000), Fuad Tabba wrote:
> > > <snip>
> > > > > +SYM_FUNC_START(__kvm_init_switch_pgd)
> > > > > + /* Turn the MMU off */
> > > > > + pre_disable_mmu_workaround
> > > > > + mrs x2, sctlr_el2
> > > > > + bic x3, x2, #SCTLR_ELx_M
> > > > > + msr sctlr_el2, x3
> > > > > + isb
> > > > > +
> > > > > + tlbi alle2
> > > > > +
> > > > > + /* Install the new pgtables */
> > > > > + ldr x3, [x0, #NVHE_INIT_PGD_PA]
> > > > > + phys_to_ttbr x4, x3
> > > > > +alternative_if ARM64_HAS_CNP
> > > > > + orr x4, x4, #TTBR_CNP_BIT
> > > > > +alternative_else_nop_endif
> > > > > + msr ttbr0_el2, x4
> > > > > +
> > > > > + /* Set the new stack pointer */
> > > > > + ldr x0, [x0, #NVHE_INIT_STACK_HYP_VA]
> > > > > + mov sp, x0
> > > > > +
> > > > > + /* And turn the MMU back on! */
> > > > > + dsb nsh
> > > > > + isb
> > > > > + msr sctlr_el2, x2
> > > > > + isb
> > > > > + ret x1
> > > > > +SYM_FUNC_END(__kvm_init_switch_pgd)
> > > > > +
> > > >
> > > > Should the instruction cache be flushed here (ic iallu), to discard
> > > > speculatively fetched instructions?
> > >
> > > Hmm, Will? Thoughts?
> >
> > The I-cache is physically tagged, so not sure what invalidation would
> > achieve here. Fuad -- what do you think could go wrong specifically?
>
> While the MMU is off, instruction fetches can be made from the PoC
> rather than the PoU, so where instructions have been modified/copied and
> not cleaned to the PoC, it's possible to fetch stale copies into the
> I-caches. The physical tag doesn't prevent that.
Oh yeah, we even have a comment about that in
idmap_kpti_install_ng_mappings(). Maybe we should wrap disable_mmu and
enable_mmu in some macros so we don't have to trip over this every time (and
this would mean we could get rid of pre_disable_mmu_workaround too).
> In the regular CPU boot paths, __enabble_mmu() has an IC IALLU after
> enabling the MMU to ensure that we get rid of anything stale (e.g. so
> secondaries don't miss ftrace patching, which is only cleaned to the
> PoU).
>
> That might not be a problem here, if things are suitably padded and
> never dynamically patched, but if so it's probably worth a comment.
It's fragile enough that we should just do the invalidation.
Will
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE"
<devicetree@vger.kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Quentin Perret <qperret@google.com>,
Android KVM <android-kvm@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
open list <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>, Fuad Tabba <tabba@google.com>,
Marc Zyngier <maz@kernel.org>,
kernel-team@android.com,
"open list:KERNEL VIRTUAL MACHINE FOR ARM64 \(KVM/arm64\)"
<kvmarm@lists.cs.columbia.edu>,
"moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection
Date: Mon, 7 Dec 2020 11:10:14 +0000 [thread overview]
Message-ID: <20201207111013.GA4379@willie-the-truck> (raw)
In-Reply-To: <20201207110528.GA18365@C02TD0UTHF1T.local>
On Mon, Dec 07, 2020 at 11:05:45AM +0000, Mark Rutland wrote:
> On Mon, Dec 07, 2020 at 10:20:03AM +0000, Will Deacon wrote:
> > On Fri, Dec 04, 2020 at 06:01:52PM +0000, Quentin Perret wrote:
> > > On Thursday 03 Dec 2020 at 12:57:33 (+0000), Fuad Tabba wrote:
> > > <snip>
> > > > > +SYM_FUNC_START(__kvm_init_switch_pgd)
> > > > > + /* Turn the MMU off */
> > > > > + pre_disable_mmu_workaround
> > > > > + mrs x2, sctlr_el2
> > > > > + bic x3, x2, #SCTLR_ELx_M
> > > > > + msr sctlr_el2, x3
> > > > > + isb
> > > > > +
> > > > > + tlbi alle2
> > > > > +
> > > > > + /* Install the new pgtables */
> > > > > + ldr x3, [x0, #NVHE_INIT_PGD_PA]
> > > > > + phys_to_ttbr x4, x3
> > > > > +alternative_if ARM64_HAS_CNP
> > > > > + orr x4, x4, #TTBR_CNP_BIT
> > > > > +alternative_else_nop_endif
> > > > > + msr ttbr0_el2, x4
> > > > > +
> > > > > + /* Set the new stack pointer */
> > > > > + ldr x0, [x0, #NVHE_INIT_STACK_HYP_VA]
> > > > > + mov sp, x0
> > > > > +
> > > > > + /* And turn the MMU back on! */
> > > > > + dsb nsh
> > > > > + isb
> > > > > + msr sctlr_el2, x2
> > > > > + isb
> > > > > + ret x1
> > > > > +SYM_FUNC_END(__kvm_init_switch_pgd)
> > > > > +
> > > >
> > > > Should the instruction cache be flushed here (ic iallu), to discard
> > > > speculatively fetched instructions?
> > >
> > > Hmm, Will? Thoughts?
> >
> > The I-cache is physically tagged, so not sure what invalidation would
> > achieve here. Fuad -- what do you think could go wrong specifically?
>
> While the MMU is off, instruction fetches can be made from the PoC
> rather than the PoU, so where instructions have been modified/copied and
> not cleaned to the PoC, it's possible to fetch stale copies into the
> I-caches. The physical tag doesn't prevent that.
Oh yeah, we even have a comment about that in
idmap_kpti_install_ng_mappings(). Maybe we should wrap disable_mmu and
enable_mmu in some macros so we don't have to trip over this every time (and
this would mean we could get rid of pre_disable_mmu_workaround too).
> In the regular CPU boot paths, __enabble_mmu() has an IC IALLU after
> enabling the MMU to ensure that we get rid of anything stale (e.g. so
> secondaries don't miss ftrace patching, which is only cleaned to the
> PoU).
>
> That might not be a problem here, if things are suitably padded and
> never dynamically patched, but if so it's probably worth a comment.
It's fragile enough that we should just do the invalidation.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-07 11:11 UTC|newest]
Thread overview: 162+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-17 18:15 [RFC PATCH 00/27] KVM/arm64: A stage 2 for the host Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 01/27] arm64: lib: Annotate {clear,copy}_page() as position-independent Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 01/27] arm64: lib: Annotate {clear, copy}_page() " Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 02/27] KVM: arm64: Link position-independent string routines into .hyp.text Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-23 12:34 ` David Brazdil
2020-11-23 12:34 ` David Brazdil
2020-11-23 12:34 ` David Brazdil
2020-11-23 14:06 ` Quentin Perret
2020-11-23 14:06 ` Quentin Perret
2020-11-23 14:06 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 03/27] KVM: arm64: Add standalone ticket spinlock implementation for use at hyp Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 04/27] KVM: arm64: Initialize kvm_nvhe_init_params early Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 05/27] KVM: arm64: Avoid free_page() in page-table allocator Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 06/27] KVM: arm64: Factor memory allocation out of pgtable.c Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 07/27] KVM: arm64: Introduce a BSS section for use at Hyp Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 08/27] KVM: arm64: Make kvm_call_hyp() a function call " Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-23 12:51 ` David Brazdil
2020-11-23 12:51 ` David Brazdil
2020-11-23 12:51 ` David Brazdil
2020-11-17 18:15 ` [RFC PATCH 09/27] KVM: arm64: Allow using kvm_nvhe_sym() in hyp code Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-23 12:57 ` David Brazdil
2020-11-23 12:57 ` David Brazdil
2020-11-23 12:57 ` David Brazdil
2020-11-23 14:02 ` Quentin Perret
2020-11-23 14:02 ` Quentin Perret
2020-11-23 14:02 ` Quentin Perret
2020-11-23 14:54 ` David Brazdil
2020-11-23 14:54 ` David Brazdil
2020-11-23 14:54 ` David Brazdil
2020-11-17 18:15 ` [RFC PATCH 10/27] KVM: arm64: Introduce an early Hyp page allocator Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 11/27] KVM: arm64: Stub CONFIG_DEBUG_LIST at Hyp Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 12/27] KVM: arm64: Introduce a Hyp buddy page allocator Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 13/27] KVM: arm64: Enable access to sanitized CPU features at EL2 Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-23 10:55 ` Fuad Tabba
2020-11-23 10:55 ` Fuad Tabba
2020-11-23 10:55 ` Fuad Tabba
2020-11-23 13:51 ` Quentin Perret
2020-11-23 13:51 ` Quentin Perret
2020-11-23 13:51 ` Quentin Perret
2020-11-23 13:22 ` David Brazdil
2020-11-23 13:22 ` David Brazdil
2020-11-23 13:22 ` David Brazdil
2020-11-23 14:39 ` Quentin Perret
2020-11-23 14:39 ` Quentin Perret
2020-11-23 14:39 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 14/27] KVM: arm64: Factor out vector address calculation Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 15/27] of/fdt: Introduce early_init_dt_add_memory_hyp() Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 19:44 ` Rob Herring
2020-11-17 19:44 ` Rob Herring
2020-11-17 19:44 ` Rob Herring
2020-11-18 9:25 ` Quentin Perret
2020-11-18 9:25 ` Quentin Perret
2020-11-18 9:25 ` Quentin Perret
2020-11-18 14:31 ` Quentin Perret
2020-11-18 14:31 ` Quentin Perret
2020-11-18 14:31 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-12-03 12:57 ` Fuad Tabba
2020-12-03 12:57 ` Fuad Tabba
2020-12-03 12:57 ` Fuad Tabba
2020-12-04 18:01 ` Quentin Perret
2020-12-04 18:01 ` Quentin Perret
2020-12-04 18:01 ` Quentin Perret
2020-12-07 10:20 ` Will Deacon
2020-12-07 10:20 ` Will Deacon
2020-12-07 10:20 ` Will Deacon
2020-12-07 11:05 ` Mark Rutland
2020-12-07 11:05 ` Mark Rutland
2020-12-07 11:05 ` Mark Rutland
2020-12-07 11:10 ` Will Deacon [this message]
2020-12-07 11:10 ` Will Deacon
2020-12-07 11:10 ` Will Deacon
2020-12-07 11:14 ` Fuad Tabba
2020-12-07 11:14 ` Fuad Tabba
2020-12-07 11:14 ` Fuad Tabba
2020-12-07 11:16 ` Fuad Tabba
2020-12-07 11:16 ` Fuad Tabba
2020-12-07 11:16 ` Fuad Tabba
2020-12-07 11:58 ` Quentin Perret
2020-12-07 11:58 ` Quentin Perret
2020-12-07 11:58 ` Quentin Perret
2020-12-07 13:54 ` Marc Zyngier
2020-12-07 13:54 ` Marc Zyngier
2020-12-07 13:54 ` Marc Zyngier
2020-12-07 14:17 ` Quentin Perret
2020-12-07 14:17 ` Quentin Perret
2020-12-07 14:17 ` Quentin Perret
2020-12-07 13:40 ` Will Deacon
2020-12-07 13:40 ` Will Deacon
2020-12-07 13:40 ` Will Deacon
2020-12-07 14:11 ` Quentin Perret
2020-12-07 14:11 ` Quentin Perret
2020-12-07 14:11 ` Quentin Perret
2020-12-08 9:40 ` Will Deacon
2020-12-08 9:40 ` Will Deacon
2020-12-08 9:40 ` Will Deacon
2020-11-17 18:15 ` [RFC PATCH 17/27] KVM: arm64: Elevate Hyp mappings creation at EL2 Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 18/27] KVM: arm64: Use kvm_arch for stage 2 pgtable Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` [RFC PATCH 19/27] KVM: arm64: Use kvm_arch in kvm_s2_mmu Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:15 ` Quentin Perret
2020-11-17 18:16 ` [RFC PATCH 20/27] KVM: arm64: Set host stage 2 using kvm_nvhe_init_params Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` [RFC PATCH 21/27] KVM: arm64: Refactor kvm_arm_setup_stage2() Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` [RFC PATCH 22/27] KVM: arm64: Refactor __load_guest_stage2() Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` [RFC PATCH 23/27] KVM: arm64: Refactor __populate_fault_info() Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` [RFC PATCH 24/27] KVM: arm64: Make memcache anonymous in pgtable allocator Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` [RFC PATCH 25/27] KVM: arm64: Reserve memory for host stage 2 Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` [RFC PATCH 26/27] KVM: arm64: Sort the memblock regions list Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` [RFC PATCH 27/27] KVM: arm64: Wrap the host with a stage 2 Quentin Perret
2020-11-17 18:16 ` Quentin Perret
2020-11-17 18:16 ` Quentin Perret
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=20201207111013.GA4379@willie-the-truck \
--to=will@kernel.org \
--cc=android-kvm@google.com \
--cc=catalin.marinas@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=qperret@google.com \
--cc=robh+dt@kernel.org \
--cc=tabba@google.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.