From: Christoffer Dall <christoffer.dall@linaro.org> To: Dave Martin <Dave.Martin@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com>, Shih-Wei Li <shihwei@cs.columbia.edu>, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org Subject: Re: [PATCH v3 26/41] KVM: arm64: Introduce framework for accessing deferred sysregs Date: Tue, 13 Feb 2018 09:55:02 +0100 [thread overview] Message-ID: <20180213085502.GF23189@cbox> (raw) In-Reply-To: <20180209161739.GE5862@e103592.cambridge.arm.com> On Fri, Feb 09, 2018 at 04:17:39PM +0000, Dave Martin wrote: > On Thu, Jan 25, 2018 at 08:54:13PM +0100, Christoffer Dall wrote: > > On Tue, Jan 23, 2018 at 04:04:40PM +0000, Dave Martin wrote: > > > On Fri, Jan 12, 2018 at 01:07:32PM +0100, Christoffer Dall wrote: > > > > We are about to defer saving and restoring some groups of system > > > > registers to vcpu_put and vcpu_load on supported systems. This means > > > > that we need some infrastructure to access system registes which > > > > supports either accessing the memory backing of the register or directly > > > > accessing the system registers, depending on the state of the system > > > > when we access the register. > > > > > > > > We do this by defining a set of read/write accessors for each system > > > > register, and letting each system register be defined as "immediate" or > > > > "deferrable". Immediate registers are always saved/restored in the > > > > world-switch path, but deferrable registers are only saved/restored in > > > > vcpu_put/vcpu_load when supported and sysregs_loaded_on_cpu will be set > > > > in that case. > > > > > > > > Not that we don't use the deferred mechanism yet in this patch, but only > > > > introduce infrastructure. This is to improve convenience of review in > > > > the subsequent patches where it is clear which registers become > > > > deferred. > > > > > > Might this table-driven approach result in a lot of branch mispredicts, > > > particularly across load/put boundaries? > > > > > > If we were to move the whole construct to a header, then it could get > > > constant-folded at the call site down to the individual reg accessed, > > > say: > > > > > > if (sys_regs_loaded) > > > read_sysreg_s(TPIDR_EL0); > > > else > > > __vcpu_sys_reg(v, TPIDR_EL0); > > > > > > Where multiple regs are accessed close to each other, the compiler > > > may be able to specialise the whole sequence for the loaded and !loaded > > > cases so that there is only one conditional branch. > > > > > > > That's an interesting thing to consider indeed. I wasn't really sure > > how to put this in a header file which wouldn't look overly bloated for > > inclusion elsewhere, so we ended up with this. > > > > I don't think the alternative suggestion that I discused with Julien on > > this patch changes this much, but since you've had a look at this, I'm > > curious which one of the two (lookup table vs. giant switch) you prefer? > > The giant switch approach has the advantage that it is likely to be > folded down to a single case when the switch control expression is > const-foldable; the flipside is that when that fails the entire > switch would be inlined. > > > > The individual accessor functions also become unnecessary in this case, > > > because we wouldn't need to derive function pointers from them any > > > more. > > > > > > I don't know how performance would compare in practice though. > > > > I don't know either. But I will say that the whole idea behind put/load > > is that you do this rarely, and going to userspace from KVM is > > notriously expensive, also on x86. > > I guess that makes sense. I'm still a bit hazy on the big picture > for KVM. > > > > I'm also assuming that all calls to these accessors are const-foldable. > > > If not, relying on inlining would bloat the generated code a lot. > > > > We have places where this is not the cae, access_vm_reg() for example. > > But if we really, really, wanted to, we could rewrite that to have a > > function for each register, but that's pretty horrid on its own. > > That might not be too bad if there is only one giant inline expansion > and the rest are folded down. > > > I guess this is something to revisit _if_ we suspect a performance > bottleneck later on. > > For now, I was lacking some understanding regarding how this code gets > run, so I was guessing about potential issues rather then proven > issues. > This was a very useful discussion. I think I'll change this to a big switch statement in the header file using a static inline, because it makes the code more readable, and if we notice a huge code size explosion, we can take measures to make sure things are const-foldable. > As you might guess, I'm still at the "stupid questions" stage for > this series :) > Not at all. Thanks, -Christoffer
WARNING: multiple messages have this Message-ID (diff)
From: christoffer.dall@linaro.org (Christoffer Dall) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v3 26/41] KVM: arm64: Introduce framework for accessing deferred sysregs Date: Tue, 13 Feb 2018 09:55:02 +0100 [thread overview] Message-ID: <20180213085502.GF23189@cbox> (raw) In-Reply-To: <20180209161739.GE5862@e103592.cambridge.arm.com> On Fri, Feb 09, 2018 at 04:17:39PM +0000, Dave Martin wrote: > On Thu, Jan 25, 2018 at 08:54:13PM +0100, Christoffer Dall wrote: > > On Tue, Jan 23, 2018 at 04:04:40PM +0000, Dave Martin wrote: > > > On Fri, Jan 12, 2018 at 01:07:32PM +0100, Christoffer Dall wrote: > > > > We are about to defer saving and restoring some groups of system > > > > registers to vcpu_put and vcpu_load on supported systems. This means > > > > that we need some infrastructure to access system registes which > > > > supports either accessing the memory backing of the register or directly > > > > accessing the system registers, depending on the state of the system > > > > when we access the register. > > > > > > > > We do this by defining a set of read/write accessors for each system > > > > register, and letting each system register be defined as "immediate" or > > > > "deferrable". Immediate registers are always saved/restored in the > > > > world-switch path, but deferrable registers are only saved/restored in > > > > vcpu_put/vcpu_load when supported and sysregs_loaded_on_cpu will be set > > > > in that case. > > > > > > > > Not that we don't use the deferred mechanism yet in this patch, but only > > > > introduce infrastructure. This is to improve convenience of review in > > > > the subsequent patches where it is clear which registers become > > > > deferred. > > > > > > Might this table-driven approach result in a lot of branch mispredicts, > > > particularly across load/put boundaries? > > > > > > If we were to move the whole construct to a header, then it could get > > > constant-folded at the call site down to the individual reg accessed, > > > say: > > > > > > if (sys_regs_loaded) > > > read_sysreg_s(TPIDR_EL0); > > > else > > > __vcpu_sys_reg(v, TPIDR_EL0); > > > > > > Where multiple regs are accessed close to each other, the compiler > > > may be able to specialise the whole sequence for the loaded and !loaded > > > cases so that there is only one conditional branch. > > > > > > > That's an interesting thing to consider indeed. I wasn't really sure > > how to put this in a header file which wouldn't look overly bloated for > > inclusion elsewhere, so we ended up with this. > > > > I don't think the alternative suggestion that I discused with Julien on > > this patch changes this much, but since you've had a look at this, I'm > > curious which one of the two (lookup table vs. giant switch) you prefer? > > The giant switch approach has the advantage that it is likely to be > folded down to a single case when the switch control expression is > const-foldable; the flipside is that when that fails the entire > switch would be inlined. > > > > The individual accessor functions also become unnecessary in this case, > > > because we wouldn't need to derive function pointers from them any > > > more. > > > > > > I don't know how performance would compare in practice though. > > > > I don't know either. But I will say that the whole idea behind put/load > > is that you do this rarely, and going to userspace from KVM is > > notriously expensive, also on x86. > > I guess that makes sense. I'm still a bit hazy on the big picture > for KVM. > > > > I'm also assuming that all calls to these accessors are const-foldable. > > > If not, relying on inlining would bloat the generated code a lot. > > > > We have places where this is not the cae, access_vm_reg() for example. > > But if we really, really, wanted to, we could rewrite that to have a > > function for each register, but that's pretty horrid on its own. > > That might not be too bad if there is only one giant inline expansion > and the rest are folded down. > > > I guess this is something to revisit _if_ we suspect a performance > bottleneck later on. > > For now, I was lacking some understanding regarding how this code gets > run, so I was guessing about potential issues rather then proven > issues. > This was a very useful discussion. I think I'll change this to a big switch statement in the header file using a static inline, because it makes the code more readable, and if we notice a huge code size explosion, we can take measures to make sure things are const-foldable. > As you might guess, I'm still at the "stupid questions" stage for > this series :) > Not at all. Thanks, -Christoffer
next prev parent reply other threads:[~2018-02-13 8:55 UTC|newest] Thread overview: 223+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-12 12:07 [PATCH v3 00/41] Optimize KVM/ARM for VHE systems Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 01/41] KVM: arm/arm64: Avoid vcpu_load for other vcpu ioctls than KVM_RUN Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-02-05 12:32 ` Julien Grall 2018-02-05 12:32 ` Julien Grall 2018-01-12 12:07 ` [PATCH v3 02/41] KVM: arm/arm64: Move vcpu_load call after kvm_vcpu_first_run_init Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-02-05 14:34 ` Julien Grall 2018-02-05 14:34 ` Julien Grall 2018-01-12 12:07 ` [PATCH v3 03/41] KVM: arm64: Avoid storing the vcpu pointer on the stack Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-02-05 17:14 ` Julien Grall 2018-02-05 17:14 ` Julien Grall 2018-01-12 12:07 ` [PATCH v3 04/41] KVM: arm64: Rework hyp_panic for VHE and non-VHE Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-02-05 18:04 ` Julien Grall 2018-02-05 18:04 ` Julien Grall 2018-02-05 18:10 ` Julien Grall 2018-02-05 18:10 ` Julien Grall 2018-02-08 13:24 ` Christoffer Dall 2018-02-08 13:24 ` Christoffer Dall 2018-02-09 10:55 ` Julien Grall 2018-02-09 10:55 ` Julien Grall 2018-01-12 12:07 ` [PATCH v3 05/41] KVM: arm64: Move HCR_INT_OVERRIDE to default HCR_EL2 guest flag Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-02-09 11:38 ` Julien Grall 2018-02-09 11:38 ` Julien Grall 2018-02-13 21:47 ` Christoffer Dall 2018-02-13 21:47 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 06/41] KVM: arm/arm64: Get rid of vcpu->arch.irq_lines Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 07/41] KVM: arm/arm64: Add kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 08/41] KVM: arm/arm64: Introduce vcpu_el1_is_32bit Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-17 14:44 ` Julien Thierry 2018-01-17 14:44 ` Julien Thierry 2018-01-18 12:57 ` Christoffer Dall 2018-01-18 12:57 ` Christoffer Dall 2018-02-09 12:31 ` Julien Grall 2018-02-09 12:31 ` Julien Grall 2018-01-12 12:07 ` [PATCH v3 09/41] KVM: arm64: Defer restoring host VFP state to vcpu_put Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-22 17:33 ` Dave Martin 2018-01-22 17:33 ` Dave Martin 2018-01-25 19:46 ` Christoffer Dall 2018-01-25 19:46 ` Christoffer Dall 2018-02-07 16:49 ` Dave Martin 2018-02-07 16:49 ` Dave Martin 2018-02-07 17:56 ` Christoffer Dall 2018-02-07 17:56 ` Christoffer Dall 2018-02-09 15:59 ` Dave Martin 2018-02-09 15:59 ` Dave Martin 2018-02-13 8:51 ` Christoffer Dall 2018-02-13 8:51 ` Christoffer Dall 2018-02-13 14:08 ` Dave Martin 2018-02-13 14:08 ` Dave Martin 2018-02-14 10:15 ` Christoffer Dall 2018-02-14 10:15 ` Christoffer Dall 2018-02-14 14:43 ` Dave Martin 2018-02-14 14:43 ` Dave Martin 2018-02-14 17:38 ` Christoffer Dall 2018-02-14 17:38 ` Christoffer Dall 2018-02-14 17:43 ` Ard Biesheuvel 2018-02-14 17:43 ` Ard Biesheuvel 2018-02-14 21:08 ` Marc Zyngier 2018-02-14 21:08 ` Marc Zyngier 2018-02-15 9:51 ` Dave Martin 2018-02-15 9:51 ` Dave Martin 2018-02-09 15:26 ` Julien Grall 2018-02-09 15:26 ` Julien Grall 2018-02-13 8:52 ` Christoffer Dall 2018-02-13 8:52 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 10/41] KVM: arm64: Move debug dirty flag calculation out of world switch Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-17 15:11 ` Julien Thierry 2018-01-17 15:11 ` Julien Thierry 2018-01-12 12:07 ` [PATCH v3 11/41] KVM: arm64: Slightly improve debug save/restore functions Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 12/41] KVM: arm64: Improve debug register save/restore flow Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 13/41] KVM: arm64: Factor out fault info population and gic workarounds Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-17 15:35 ` Julien Thierry 2018-01-12 12:07 ` [PATCH v3 14/41] KVM: arm64: Introduce VHE-specific kvm_vcpu_run Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-24 16:13 ` Dave Martin 2018-01-24 16:13 ` Dave Martin 2018-01-25 8:45 ` Christoffer Dall 2018-01-25 8:45 ` Christoffer Dall 2018-02-09 17:34 ` Julien Grall 2018-02-09 17:34 ` Julien Grall 2018-02-13 8:52 ` Christoffer Dall 2018-02-13 8:52 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 15/41] KVM: arm64: Remove kern_hyp_va() use in VHE switch function Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-24 16:24 ` Dave Martin 2018-01-24 16:24 ` Dave Martin 2018-01-25 19:48 ` Christoffer Dall 2018-01-25 19:48 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 16/41] KVM: arm64: Don't deactivate VM on VHE systems Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 17/41] KVM: arm64: Remove noop calls to timer save/restore from VHE switch Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-02-09 17:53 ` Julien Grall 2018-02-09 17:53 ` Julien Grall 2018-02-13 8:53 ` Christoffer Dall 2018-02-13 8:53 ` Christoffer Dall 2018-02-13 22:31 ` Christoffer Dall 2018-02-13 22:31 ` Christoffer Dall 2018-02-19 16:30 ` Julien Grall 2018-02-19 16:30 ` Julien Grall 2018-01-12 12:07 ` [PATCH v3 18/41] KVM: arm64: Move userspace system registers into separate function Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-02-09 18:50 ` Julien Grall 2018-02-09 18:50 ` Julien Grall 2018-02-14 11:22 ` Christoffer Dall 2018-02-14 11:22 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 19/41] KVM: arm64: Rewrite sysreg alternatives to static keys Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 20/41] KVM: arm64: Introduce separate VHE/non-VHE sysreg save/restore functions Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 21/41] KVM: arm/arm64: Remove leftover comment from kvm_vcpu_run_vhe Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 22/41] KVM: arm64: Unify non-VHE host/guest sysreg save and restore functions Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 23/41] KVM: arm64: Don't save the host ELR_EL2 and SPSR_EL2 on VHE systems Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 24/41] KVM: arm64: Change 32-bit handling of VM system registers Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 25/41] KVM: arm64: Rewrite system register accessors to read/write functions Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 26/41] KVM: arm64: Introduce framework for accessing deferred sysregs Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-17 17:52 ` Julien Thierry 2018-01-17 17:52 ` Julien Thierry 2018-01-18 13:08 ` Christoffer Dall 2018-01-18 13:08 ` Christoffer Dall 2018-01-18 13:39 ` Julien Thierry 2018-01-18 13:39 ` Julien Thierry 2018-01-23 16:04 ` Dave Martin 2018-01-23 16:04 ` Dave Martin 2018-01-25 19:54 ` Christoffer Dall 2018-01-25 19:54 ` Christoffer Dall 2018-02-09 16:17 ` Dave Martin 2018-02-09 16:17 ` Dave Martin 2018-02-13 8:55 ` Christoffer Dall [this message] 2018-02-13 8:55 ` Christoffer Dall 2018-02-13 14:27 ` Dave Martin 2018-02-13 14:27 ` Dave Martin 2018-01-12 12:07 ` [PATCH v3 27/41] KVM: arm/arm64: Prepare to handle deferred save/restore of SPSR_EL1 Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 28/41] KVM: arm64: Prepare to handle deferred save/restore of ELR_EL1 Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 29/41] KVM: arm64: Defer saving/restoring 64-bit sysregs to vcpu load/put on VHE Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 30/41] KVM: arm64: Prepare to handle deferred save/restore of 32-bit registers Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-17 18:22 ` Julien Thierry 2018-01-17 18:22 ` Julien Thierry 2018-01-18 13:12 ` Christoffer Dall 2018-01-18 13:12 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 31/41] KVM: arm64: Defer saving/restoring 32-bit sysregs to vcpu load/put Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 32/41] KVM: arm64: Move common VHE/non-VHE trap config in separate functions Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 33/41] KVM: arm64: Configure FPSIMD traps on vcpu load/put Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-18 9:31 ` Julien Thierry 2018-01-18 9:31 ` Julien Thierry 2018-01-31 12:17 ` Tomasz Nowicki 2018-01-31 12:17 ` Tomasz Nowicki 2018-02-05 10:06 ` Christoffer Dall 2018-02-05 10:06 ` Christoffer Dall 2018-01-31 12:24 ` Tomasz Nowicki 2018-01-31 12:24 ` Tomasz Nowicki 2018-01-12 12:07 ` [PATCH v3 34/41] KVM: arm64: Configure c15, PMU, and debug register traps on cpu load/put for VHE Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 35/41] KVM: arm64: Separate activate_traps and deactive_traps for VHE and non-VHE Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 36/41] KVM: arm/arm64: Get rid of vgic_elrsr Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 37/41] KVM: arm/arm64: Handle VGICv2 save/restore from the main VGIC code Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 38/41] KVM: arm/arm64: Move arm64-only vgic-v2-sr.c file to arm64 Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 39/41] KVM: arm/arm64: Handle VGICv3 save/restore from the main VGIC code on VHE Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 40/41] KVM: arm/arm64: Move VGIC APR save/restore to vgic put/load Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-01-12 12:07 ` [PATCH v3 41/41] KVM: arm/arm64: Avoid VGICv3 save/restore on VHE with no IRQs Christoffer Dall 2018-01-12 12:07 ` Christoffer Dall 2018-02-05 13:29 ` Tomasz Nowicki 2018-02-05 13:29 ` Tomasz Nowicki 2018-02-08 15:48 ` Christoffer Dall 2018-02-08 15:48 ` Christoffer Dall 2018-01-15 14:14 ` [PATCH v3 00/41] Optimize KVM/ARM for VHE systems Yury Norov 2018-01-15 14:14 ` Yury Norov 2018-01-15 15:50 ` Christoffer Dall 2018-01-15 15:50 ` Christoffer Dall 2018-01-17 8:34 ` Yury Norov 2018-01-17 8:34 ` Yury Norov 2018-01-17 10:48 ` Christoffer Dall 2018-01-17 10:48 ` Christoffer Dall 2018-01-18 11:16 ` Christoffer Dall 2018-01-18 11:16 ` Christoffer Dall 2018-01-18 12:18 ` Yury Norov 2018-01-18 12:18 ` Yury Norov 2018-01-18 13:32 ` Christoffer Dall 2018-01-18 13:32 ` Christoffer Dall 2018-01-22 13:40 ` Tomasz Nowicki 2018-01-22 13:40 ` Tomasz Nowicki 2018-02-01 13:57 ` Tomasz Nowicki 2018-02-01 13:57 ` Tomasz Nowicki 2018-02-01 16:15 ` Yury Norov 2018-02-01 16:15 ` Yury Norov 2018-02-02 10:05 ` Tomasz Nowicki 2018-02-02 10:05 ` Tomasz Nowicki 2018-02-02 10:07 ` Tomasz Nowicki 2018-02-02 10:07 ` Tomasz Nowicki 2018-02-08 15:47 ` Christoffer Dall 2018-02-08 15:47 ` Christoffer Dall
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=20180213085502.GF23189@cbox \ --to=christoffer.dall@linaro.org \ --cc=Dave.Martin@arm.com \ --cc=kvm@vger.kernel.org \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=marc.zyngier@arm.com \ --cc=shihwei@cs.columbia.edu \ /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: linkBe 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.