From: Will Deacon <will@kernel.org>
To: Quentin Perret <qperret@google.com>
Cc: catalin.marinas@arm.com, maz@kernel.org, james.morse@arm.com,
julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com,
android-kvm@google.com, linux-kernel@vger.kernel.org,
kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, tabba@google.com,
mark.rutland@arm.com, dbrazdil@google.com, mate.toth-pal@arm.com,
seanjc@google.com, robh+dt@kernel.org
Subject: Re: [PATCH v3 26/32] KVM: arm64: Introduce PROT_NONE mappings for stage 2
Date: Fri, 5 Mar 2021 19:03:51 +0000 [thread overview]
Message-ID: <20210305190350.GB23633@willie-the-truck> (raw)
In-Reply-To: <YEH/THAYbSjOuFrH@google.com>
On Fri, Mar 05, 2021 at 09:52:12AM +0000, Quentin Perret wrote:
> On Thursday 04 Mar 2021 at 20:00:45 (+0000), Will Deacon wrote:
> > On Tue, Mar 02, 2021 at 02:59:56PM +0000, Quentin Perret wrote:
> > > Once we start unmapping portions of memory from the host stage 2 (such
> > > as e.g. the hypervisor memory sections, or pages that belong to
> > > protected guests), we will need a way to track page ownership. And
> > > given that all mappings in the host stage 2 will be identity-mapped, we
> > > can use the host stage 2 page-table itself as a simplistic rmap.
> > >
> > > As a first step towards this, introduce a new protection attribute
> > > in the stage 2 page table code, called KVM_PGTABLE_PROT_NONE, which
> > > allows to annotate portions of the IPA space as inaccessible. For
> > > simplicity, PROT_NONE mappings are created as invalid mappings with a
> > > software bit set.
> >
> > Just as an observation, but given that they're invalid we can use any bit
> > from [63:2] to indicate that it's a PROT_NONE mapping, and that way we
> > can keep the real "software bits" for live mappings.
> >
> > But we can of course change that later when we need the bit for something
> > else.
>
> Right, so I used this approach for consistency with the kernel's
> PROT_NONE mappings:
>
> #define PTE_PROT_NONE (_AT(pteval_t, 1) << 58) /* only when !PTE_VALID */
>
> And in fact now that I think about it, it might be worth re-using the
> same bit in stage 2.
>
> But yes it would be pretty neat to use the other bits of invalid
> mappings to add metadata about the pages. I could even drop the
> PROT_NONE stuff straight away in favor of a more extensive mechanism for
> tracking page ownership...
>
> Thinking about it, it should be relatively straightforward to construct
> the host stage 2 with the following invariants:
>
> 1. everything is identity-mapped in the host stage 2;
>
> 2. all valid mappings imply the underlying PA range belongs to the
> host;
>
> 3. bits [63:32] (say) of all invalid mappings are used to store a
> unique identifier for the owner of the underlying PA range;
>
> 4. the host identifier is 0, such that it owns all of memory by
> default at boot as its pgd is zeroed;
>
> And then I could replace my PROT_NONE permission stuff by an ownership
> change. E.g. the hypervisor would have its own identifier, and I could
> use it to mark the .hyp memory sections as owned by the hyp (which
> implies inaccessible by the host). And that should scale quite easily
> when we start running protected guests as we'll assign them their own
> identifiers. Sharing pages between guests (or even worse, between host
> and guests) is a bit trickier, but maybe that is for later.
>
> Thoughts?
I think this sounds like a worthwhile generalisation to me, although virtio
brings an immediate need for shared pages and so we'll still need a software
bit for those so that we e.g. prevent the host from donating such a shared
page to the hypervisor.
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Quentin Perret <qperret@google.com>
Cc: android-kvm@google.com, catalin.marinas@arm.com,
mate.toth-pal@arm.com, seanjc@google.com, tabba@google.com,
linux-kernel@vger.kernel.org, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, maz@kernel.org,
kernel-team@android.com, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v3 26/32] KVM: arm64: Introduce PROT_NONE mappings for stage 2
Date: Fri, 5 Mar 2021 19:03:51 +0000 [thread overview]
Message-ID: <20210305190350.GB23633@willie-the-truck> (raw)
In-Reply-To: <YEH/THAYbSjOuFrH@google.com>
On Fri, Mar 05, 2021 at 09:52:12AM +0000, Quentin Perret wrote:
> On Thursday 04 Mar 2021 at 20:00:45 (+0000), Will Deacon wrote:
> > On Tue, Mar 02, 2021 at 02:59:56PM +0000, Quentin Perret wrote:
> > > Once we start unmapping portions of memory from the host stage 2 (such
> > > as e.g. the hypervisor memory sections, or pages that belong to
> > > protected guests), we will need a way to track page ownership. And
> > > given that all mappings in the host stage 2 will be identity-mapped, we
> > > can use the host stage 2 page-table itself as a simplistic rmap.
> > >
> > > As a first step towards this, introduce a new protection attribute
> > > in the stage 2 page table code, called KVM_PGTABLE_PROT_NONE, which
> > > allows to annotate portions of the IPA space as inaccessible. For
> > > simplicity, PROT_NONE mappings are created as invalid mappings with a
> > > software bit set.
> >
> > Just as an observation, but given that they're invalid we can use any bit
> > from [63:2] to indicate that it's a PROT_NONE mapping, and that way we
> > can keep the real "software bits" for live mappings.
> >
> > But we can of course change that later when we need the bit for something
> > else.
>
> Right, so I used this approach for consistency with the kernel's
> PROT_NONE mappings:
>
> #define PTE_PROT_NONE (_AT(pteval_t, 1) << 58) /* only when !PTE_VALID */
>
> And in fact now that I think about it, it might be worth re-using the
> same bit in stage 2.
>
> But yes it would be pretty neat to use the other bits of invalid
> mappings to add metadata about the pages. I could even drop the
> PROT_NONE stuff straight away in favor of a more extensive mechanism for
> tracking page ownership...
>
> Thinking about it, it should be relatively straightforward to construct
> the host stage 2 with the following invariants:
>
> 1. everything is identity-mapped in the host stage 2;
>
> 2. all valid mappings imply the underlying PA range belongs to the
> host;
>
> 3. bits [63:32] (say) of all invalid mappings are used to store a
> unique identifier for the owner of the underlying PA range;
>
> 4. the host identifier is 0, such that it owns all of memory by
> default at boot as its pgd is zeroed;
>
> And then I could replace my PROT_NONE permission stuff by an ownership
> change. E.g. the hypervisor would have its own identifier, and I could
> use it to mark the .hyp memory sections as owned by the hyp (which
> implies inaccessible by the host). And that should scale quite easily
> when we start running protected guests as we'll assign them their own
> identifiers. Sharing pages between guests (or even worse, between host
> and guests) is a bit trickier, but maybe that is for later.
>
> Thoughts?
I think this sounds like a worthwhile generalisation to me, although virtio
brings an immediate need for shared pages and so we'll still need a software
bit for those so that we e.g. prevent the host from donating such a shared
page to the hypervisor.
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: Quentin Perret <qperret@google.com>
Cc: catalin.marinas@arm.com, maz@kernel.org, james.morse@arm.com,
julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com,
android-kvm@google.com, linux-kernel@vger.kernel.org,
kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, tabba@google.com,
mark.rutland@arm.com, dbrazdil@google.com, mate.toth-pal@arm.com,
seanjc@google.com, robh+dt@kernel.org
Subject: Re: [PATCH v3 26/32] KVM: arm64: Introduce PROT_NONE mappings for stage 2
Date: Fri, 5 Mar 2021 19:03:51 +0000 [thread overview]
Message-ID: <20210305190350.GB23633@willie-the-truck> (raw)
In-Reply-To: <YEH/THAYbSjOuFrH@google.com>
On Fri, Mar 05, 2021 at 09:52:12AM +0000, Quentin Perret wrote:
> On Thursday 04 Mar 2021 at 20:00:45 (+0000), Will Deacon wrote:
> > On Tue, Mar 02, 2021 at 02:59:56PM +0000, Quentin Perret wrote:
> > > Once we start unmapping portions of memory from the host stage 2 (such
> > > as e.g. the hypervisor memory sections, or pages that belong to
> > > protected guests), we will need a way to track page ownership. And
> > > given that all mappings in the host stage 2 will be identity-mapped, we
> > > can use the host stage 2 page-table itself as a simplistic rmap.
> > >
> > > As a first step towards this, introduce a new protection attribute
> > > in the stage 2 page table code, called KVM_PGTABLE_PROT_NONE, which
> > > allows to annotate portions of the IPA space as inaccessible. For
> > > simplicity, PROT_NONE mappings are created as invalid mappings with a
> > > software bit set.
> >
> > Just as an observation, but given that they're invalid we can use any bit
> > from [63:2] to indicate that it's a PROT_NONE mapping, and that way we
> > can keep the real "software bits" for live mappings.
> >
> > But we can of course change that later when we need the bit for something
> > else.
>
> Right, so I used this approach for consistency with the kernel's
> PROT_NONE mappings:
>
> #define PTE_PROT_NONE (_AT(pteval_t, 1) << 58) /* only when !PTE_VALID */
>
> And in fact now that I think about it, it might be worth re-using the
> same bit in stage 2.
>
> But yes it would be pretty neat to use the other bits of invalid
> mappings to add metadata about the pages. I could even drop the
> PROT_NONE stuff straight away in favor of a more extensive mechanism for
> tracking page ownership...
>
> Thinking about it, it should be relatively straightforward to construct
> the host stage 2 with the following invariants:
>
> 1. everything is identity-mapped in the host stage 2;
>
> 2. all valid mappings imply the underlying PA range belongs to the
> host;
>
> 3. bits [63:32] (say) of all invalid mappings are used to store a
> unique identifier for the owner of the underlying PA range;
>
> 4. the host identifier is 0, such that it owns all of memory by
> default at boot as its pgd is zeroed;
>
> And then I could replace my PROT_NONE permission stuff by an ownership
> change. E.g. the hypervisor would have its own identifier, and I could
> use it to mark the .hyp memory sections as owned by the hyp (which
> implies inaccessible by the host). And that should scale quite easily
> when we start running protected guests as we'll assign them their own
> identifiers. Sharing pages between guests (or even worse, between host
> and guests) is a bit trickier, but maybe that is for later.
>
> Thoughts?
I think this sounds like a worthwhile generalisation to me, although virtio
brings an immediate need for shared pages and so we'll still need a software
bit for those so that we e.g. prevent the host from donating such a shared
page to the hypervisor.
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:[~2021-03-05 19:04 UTC|newest]
Thread overview: 192+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-02 14:59 [PATCH v3 00/32] KVM: arm64: A stage 2 for the host Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 01/32] arm64: lib: Annotate {clear,copy}_page() as position-independent Quentin Perret
2021-03-02 14:59 ` [PATCH v3 01/32] arm64: lib: Annotate {clear, copy}_page() " Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 02/32] KVM: arm64: Link position-independent string routines into .hyp.text Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 03/32] arm64: kvm: Add standalone ticket spinlock implementation for use at hyp Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 04/32] KVM: arm64: Initialize kvm_nvhe_init_params early Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 13:39 ` Will Deacon
2021-03-04 13:39 ` Will Deacon
2021-03-04 13:39 ` Will Deacon
2021-03-02 14:59 ` [PATCH v3 05/32] KVM: arm64: Avoid free_page() in page-table allocator Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 06/32] KVM: arm64: Factor memory allocation out of pgtable.c Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 14:06 ` Will Deacon
2021-03-04 14:06 ` Will Deacon
2021-03-04 14:06 ` Will Deacon
2021-03-02 14:59 ` [PATCH v3 07/32] KVM: arm64: Introduce a BSS section for use at Hyp Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 14:09 ` Will Deacon
2021-03-04 14:09 ` Will Deacon
2021-03-04 14:09 ` Will Deacon
2021-03-02 14:59 ` [PATCH v3 08/32] KVM: arm64: Make kvm_call_hyp() a function call " Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 09/32] KVM: arm64: Allow using kvm_nvhe_sym() in hyp code Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 10/32] KVM: arm64: Introduce an early Hyp page allocator Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 14:38 ` Will Deacon
2021-03-04 14:38 ` Will Deacon
2021-03-04 14:38 ` Will Deacon
2021-03-02 14:59 ` [PATCH v3 11/32] KVM: arm64: Stub CONFIG_DEBUG_LIST at Hyp Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 12/32] KVM: arm64: Introduce a Hyp buddy page allocator Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 15:30 ` Will Deacon
2021-03-04 15:30 ` Will Deacon
2021-03-04 15:30 ` Will Deacon
2021-03-04 15:49 ` Quentin Perret
2021-03-04 15:49 ` Quentin Perret
2021-03-04 15:49 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 13/32] KVM: arm64: Enable access to sanitized CPU features at EL2 Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 14/32] KVM: arm64: Factor out vector address calculation Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 15/32] KVM: arm64: Prepare the creation of s1 mappings at EL2 Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 18:47 ` Will Deacon
2021-03-04 18:47 ` Will Deacon
2021-03-04 18:47 ` Will Deacon
2021-03-02 14:59 ` [PATCH v3 16/32] KVM: arm64: Elevate hypervisor mappings creation " Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 19:25 ` Will Deacon
2021-03-04 19:25 ` Will Deacon
2021-03-04 19:25 ` Will Deacon
2021-03-05 9:14 ` Quentin Perret
2021-03-05 9:14 ` Quentin Perret
2021-03-05 9:14 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 17/32] KVM: arm64: Use kvm_arch for stage 2 pgtable Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 18/32] KVM: arm64: Use kvm_arch in kvm_s2_mmu Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 19/32] KVM: arm64: Set host stage 2 using kvm_nvhe_init_params Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 20/32] KVM: arm64: Refactor kvm_arm_setup_stage2() Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 19:35 ` Will Deacon
2021-03-04 19:35 ` Will Deacon
2021-03-04 19:35 ` Will Deacon
2021-03-02 14:59 ` [PATCH v3 21/32] KVM: arm64: Refactor __load_guest_stage2() Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 22/32] KVM: arm64: Refactor __populate_fault_info() Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 19:39 ` Will Deacon
2021-03-04 19:39 ` Will Deacon
2021-03-04 19:39 ` Will Deacon
2021-03-02 14:59 ` [PATCH v3 23/32] KVM: arm64: Make memcache anonymous in pgtable allocator Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 19:44 ` Will Deacon
2021-03-04 19:44 ` Will Deacon
2021-03-04 19:44 ` Will Deacon
2021-03-02 14:59 ` [PATCH v3 24/32] KVM: arm64: Reserve memory for host stage 2 Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 19:49 ` Will Deacon
2021-03-04 19:49 ` Will Deacon
2021-03-04 19:49 ` Will Deacon
2021-03-05 9:17 ` Quentin Perret
2021-03-05 9:17 ` Quentin Perret
2021-03-05 9:17 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 25/32] KVM: arm64: Sort the hypervisor memblocks Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 19:51 ` Will Deacon
2021-03-04 19:51 ` Will Deacon
2021-03-04 19:51 ` Will Deacon
2021-03-02 14:59 ` [PATCH v3 26/32] KVM: arm64: Introduce PROT_NONE mappings for stage 2 Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 20:00 ` Will Deacon
2021-03-04 20:00 ` Will Deacon
2021-03-04 20:00 ` Will Deacon
2021-03-05 9:52 ` Quentin Perret
2021-03-05 9:52 ` Quentin Perret
2021-03-05 9:52 ` Quentin Perret
2021-03-05 19:03 ` Will Deacon [this message]
2021-03-05 19:03 ` Will Deacon
2021-03-05 19:03 ` Will Deacon
2021-03-02 14:59 ` [PATCH v3 27/32] KVM: arm64: Refactor stage2_map_set_prot_attr() Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-04 20:03 ` Will Deacon
2021-03-04 20:03 ` Will Deacon
2021-03-04 20:03 ` Will Deacon
2021-03-05 9:18 ` Quentin Perret
2021-03-05 9:18 ` Quentin Perret
2021-03-05 9:18 ` Quentin Perret
2021-03-02 14:59 ` [PATCH v3 28/32] KVM: arm64: Add kvm_pgtable_stage2_idmap_greedy() Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-05 14:39 ` Will Deacon
2021-03-05 14:39 ` Will Deacon
2021-03-05 14:39 ` Will Deacon
2021-03-05 15:03 ` Quentin Perret
2021-03-05 15:03 ` Quentin Perret
2021-03-05 15:03 ` Quentin Perret
2021-03-05 16:59 ` Will Deacon
2021-03-05 16:59 ` Will Deacon
2021-03-05 16:59 ` Will Deacon
2021-03-02 14:59 ` [PATCH v3 29/32] KVM: arm64: Wrap the host with a stage 2 Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-02 14:59 ` Quentin Perret
2021-03-05 19:29 ` Will Deacon
2021-03-05 19:29 ` Will Deacon
2021-03-05 19:29 ` Will Deacon
2021-03-08 9:22 ` Quentin Perret
2021-03-08 9:22 ` Quentin Perret
2021-03-08 9:22 ` Quentin Perret
2021-03-08 12:46 ` Will Deacon
2021-03-08 12:46 ` Will Deacon
2021-03-08 12:46 ` Will Deacon
2021-03-08 13:38 ` Quentin Perret
2021-03-08 13:38 ` Quentin Perret
2021-03-08 13:38 ` Quentin Perret
2021-03-08 13:52 ` Will Deacon
2021-03-08 13:52 ` Will Deacon
2021-03-08 13:52 ` Will Deacon
2021-03-02 15:00 ` [PATCH v3 30/32] KVM: arm64: Page-align the .hyp sections Quentin Perret
2021-03-02 15:00 ` Quentin Perret
2021-03-02 15:00 ` Quentin Perret
2021-03-04 20:05 ` Will Deacon
2021-03-04 20:05 ` Will Deacon
2021-03-04 20:05 ` Will Deacon
2021-03-02 15:00 ` [PATCH v3 31/32] KVM: arm64: Disable PMU support in protected mode Quentin Perret
2021-03-02 15:00 ` Quentin Perret
2021-03-02 15:00 ` Quentin Perret
2021-03-05 19:02 ` Will Deacon
2021-03-05 19:02 ` Will Deacon
2021-03-05 19:02 ` Will Deacon
2021-03-02 15:00 ` [PATCH v3 32/32] KVM: arm64: Protect the .hyp sections from the host Quentin Perret
2021-03-02 15:00 ` Quentin Perret
2021-03-02 15:00 ` Quentin Perret
2021-03-05 19:13 ` Will Deacon
2021-03-05 19:13 ` Will Deacon
2021-03-05 19:13 ` Will Deacon
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=20210305190350.GB23633@willie-the-truck \
--to=will@kernel.org \
--cc=android-kvm@google.com \
--cc=catalin.marinas@arm.com \
--cc=dbrazdil@google.com \
--cc=james.morse@arm.com \
--cc=julien.thierry.kdev@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=mate.toth-pal@arm.com \
--cc=maz@kernel.org \
--cc=qperret@google.com \
--cc=robh+dt@kernel.org \
--cc=seanjc@google.com \
--cc=suzuki.poulose@arm.com \
--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.