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: Thu, 18 Jan 2018 14:08:23 +0100 [thread overview]
Message-ID: <20180118130823.GC27865@cbox> (raw)
In-Reply-To: <dce891ed-3e43-a136-9d7b-c7186fe2ff3c@arm.com>
On Wed, Jan 17, 2018 at 05:52:21PM +0000, Julien Thierry wrote:
>
>
> On 12/01/18 12:07, 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.
> >
>
> The patch is fine, however I'd suggest adding a comment in the pointing out
> that the IMMEDIATE/DEFERRABLE apply to save/restore to the vcpu struct.
> Instinctively I would expect the deferrable/immediate to apply to the actual
> hardware register access, so a comment would prevent people like me to get
> on the wrong track.
>
I tried to explain that a bit in the first sentence of the commit
message, but I can try to make it more clear that we introduce
terminology.
> >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.
> >
> > [ Most of this logic was contributed by Marc Zyngier ]
> >
> >Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> >Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>
> Reviewed-by: Julien Thierry <julien.thierry@arm.com>
>
> >---
> > arch/arm64/include/asm/kvm_host.h | 8 +-
> > arch/arm64/kvm/sys_regs.c | 160 ++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 166 insertions(+), 2 deletions(-)
> >
> >diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> >index 91272c35cc36..4b5ef82f6bdb 100644
> >--- a/arch/arm64/include/asm/kvm_host.h
> >+++ b/arch/arm64/include/asm/kvm_host.h
> >@@ -281,6 +281,10 @@ struct kvm_vcpu_arch {
> > /* Detect first run of a vcpu */
> > bool has_run_once;
> >+
> >+ /* True when deferrable sysregs are loaded on the physical CPU,
> >+ * see kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs. */
> >+ bool sysregs_loaded_on_cpu;
> > };
> > #define vcpu_gp_regs(v) (&(v)->arch.ctxt.gp_regs)
> >@@ -293,8 +297,8 @@ struct kvm_vcpu_arch {
> > */
> > #define __vcpu_sys_reg(v,r) ((v)->arch.ctxt.sys_regs[(r)])
> >-#define vcpu_read_sys_reg(v,r) __vcpu_sys_reg(v,r)
> >-#define vcpu_write_sys_reg(v,r,n) do { __vcpu_sys_reg(v,r) = n; } while (0)
> >+u64 vcpu_read_sys_reg(struct kvm_vcpu *vcpu, int reg);
> >+void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, int reg, u64 val);
> > /*
> > * CP14 and CP15 live in the same array, as they are backed by the
> >diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> >index 96398d53b462..9d353a6a55c9 100644
> >--- a/arch/arm64/kvm/sys_regs.c
> >+++ b/arch/arm64/kvm/sys_regs.c
> >@@ -35,6 +35,7 @@
> > #include <asm/kvm_coproc.h>
> > #include <asm/kvm_emulate.h>
> > #include <asm/kvm_host.h>
> >+#include <asm/kvm_hyp.h>
> > #include <asm/kvm_mmu.h>
> > #include <asm/perf_event.h>
> > #include <asm/sysreg.h>
> >@@ -76,6 +77,165 @@ static bool write_to_read_only(struct kvm_vcpu *vcpu,
> > return false;
> > }
> >+struct sys_reg_accessor {
> >+ u64 (*rdsr)(struct kvm_vcpu *, int);
> >+ void (*wrsr)(struct kvm_vcpu *, int, u64);
>
> Nit:
>
> Why use a signed integer for the register index argument?
>
The type name is short? ;) No particular reason, could be an unsigned
int, but I don't think it matters here does it?
> >+};
> >+
> >+#define DECLARE_IMMEDIATE_SR(i) \
> >+ static u64 __##i##_read(struct kvm_vcpu *vcpu, int r) \
> >+ { \
> >+ return __vcpu_sys_reg(vcpu, r); \
> >+ } \
> >+ \
> >+ static void __##i##_write(struct kvm_vcpu *vcpu, int r, u64 v) \
> >+ { \
> >+ __vcpu_sys_reg(vcpu, r) = v; \
> >+ } \
> >+
> >+#define DECLARE_DEFERRABLE_SR(i, s) \
> >+ static u64 __##i##_read(struct kvm_vcpu *vcpu, int r) \
> >+ { \
> >+ if (vcpu->arch.sysregs_loaded_on_cpu) { \
> >+ WARN_ON(kvm_arm_get_running_vcpu() != vcpu); \
> >+ return read_sysreg_s((s)); \
> >+ } \
> >+ return __vcpu_sys_reg(vcpu, r); \
> >+ } \
> >+ \
> >+ static void __##i##_write(struct kvm_vcpu *vcpu, int r, u64 v) \
> >+ { \
> >+ if (vcpu->arch.sysregs_loaded_on_cpu) { \
> >+ WARN_ON(kvm_arm_get_running_vcpu() != vcpu); \
> >+ write_sysreg_s(v, (s)); \
> >+ } else { \
> >+ __vcpu_sys_reg(vcpu, r) = v; \
> >+ } \
> >+ } \
> >+
> >+
> >+#define SR_HANDLER_RANGE(i,e) \
> >+ [i ... e] = (struct sys_reg_accessor) { \
> >+ .rdsr = __##i##_read, \
> >+ .wrsr = __##i##_write, \
>
> Nit:
> Could we have __vcpu_##i##_read and __vcpu_##i##_write?
>
They don't necessarily read from the vcpu do they?
Unrelated: I also thought about just having a single function a switch
statement instead, which may make it easier to follow the code as there
would be no macros generating functions, but it would be slightly less
declarative.
For example:
u64 vcpu_read_sys_reg(struct kvm_vcpu *vcpu, int reg)
{
if (!vcpu->arch.sysregs_loaded_on_cpu)
goto immediate_read;
/*
* All system registers listed in the switch are deferred
* save/restored on VHE systems.
*/
switch (reg) {
case CSSELR_EL1: return read_sysreg_s(SYS_CSSELR_EL1));
case SCTLR_EL1: return read_sysreg_s(sctlr_EL12));
case ACTLR_EL1: return read_sysreg_s(SYS_ACTLR_EL1));
case CPACR_EL1: return read_sysreg_s(cpacr_EL12));
case TTBR0_EL1: return read_sysreg_s(ttbr0_EL12));
case TTBR1_EL1: return read_sysreg_s(ttbr1_EL12));
case TCR_EL1: return read_sysreg_s(tcr_EL12));
case ESR_EL1: return read_sysreg_s(esr_EL12));
case AFSR0_EL1: return read_sysreg_s(afsr0_EL12));
case AFSR1_EL1: return read_sysreg_s(afsr1_EL12));
case FAR_EL1: return read_sysreg_s(far_EL12));
case MAIR_EL1: return read_sysreg_s(mair_EL12));
case VBAR_EL1: return read_sysreg_s(vbar_EL12));
case CONTEXTIDR_EL1: return read_sysreg_s(contextidr_EL12));
case TPIDR_EL0: return read_sysreg_s(SYS_TPIDR_EL0));
case TPIDRRO_EL0: return read_sysreg_s(SYS_TPIDRRO_EL0));
case TPIDR_EL1: return read_sysreg_s(SYS_TPIDR_EL1));
case AMAIR_EL1: return read_sysreg_s(amair_EL12));
case CNTKCTL_EL1: return read_sysreg_s(cntkctl_EL12));
case PAR_EL1: return read_sysreg_s(SYS_PAR_EL1));
case DACR32_EL2: return read_sysreg_s(SYS_DACR32_EL2));
case IFSR32_EL2: return read_sysreg_s(SYS_IFSR32_EL2));
case DBGVCR32_EL2: return read_sysreg_s(SYS_DBGVCR32_EL2));
}
immediate_read:
return __vcpu_sys_reg(vcpu, reg);
}
Since you're having a look at this, what are your thoughts?
Marc, what's your preference?
Thanks,
-Christoffer
> >+ }
> >+
> >+#define SR_HANDLER(i) SR_HANDLER_RANGE(i, i)
> >+
> >+static void bad_sys_reg(int reg)
> >+{
> >+ WARN_ONCE(1, "Bad system register access %d\n", reg);
> >+}
> >+
> >+static u64 __default_read_sys_reg(struct kvm_vcpu *vcpu, int reg)
> >+{
> >+ bad_sys_reg(reg);
> >+ return 0;
> >+}
> >+
> >+static void __default_write_sys_reg(struct kvm_vcpu *vcpu, int reg, u64 val)
> >+{
> >+ bad_sys_reg(reg);
> >+}
> >+
> >+/* Ordered as in enum vcpu_sysreg */
> >+DECLARE_IMMEDIATE_SR(MPIDR_EL1);
> >+DECLARE_IMMEDIATE_SR(CSSELR_EL1);
> >+DECLARE_IMMEDIATE_SR(SCTLR_EL1);
> >+DECLARE_IMMEDIATE_SR(ACTLR_EL1);
> >+DECLARE_IMMEDIATE_SR(CPACR_EL1);
> >+DECLARE_IMMEDIATE_SR(TTBR0_EL1);
> >+DECLARE_IMMEDIATE_SR(TTBR1_EL1);
> >+DECLARE_IMMEDIATE_SR(TCR_EL1);
> >+DECLARE_IMMEDIATE_SR(ESR_EL1);
> >+DECLARE_IMMEDIATE_SR(AFSR0_EL1);
> >+DECLARE_IMMEDIATE_SR(AFSR1_EL1);
> >+DECLARE_IMMEDIATE_SR(FAR_EL1);
> >+DECLARE_IMMEDIATE_SR(MAIR_EL1);
> >+DECLARE_IMMEDIATE_SR(VBAR_EL1);
> >+DECLARE_IMMEDIATE_SR(CONTEXTIDR_EL1);
> >+DECLARE_IMMEDIATE_SR(TPIDR_EL0);
> >+DECLARE_IMMEDIATE_SR(TPIDRRO_EL0);
> >+DECLARE_IMMEDIATE_SR(TPIDR_EL1);
> >+DECLARE_IMMEDIATE_SR(AMAIR_EL1);
> >+DECLARE_IMMEDIATE_SR(CNTKCTL_EL1);
> >+DECLARE_IMMEDIATE_SR(PAR_EL1);
> >+DECLARE_IMMEDIATE_SR(MDSCR_EL1);
> >+DECLARE_IMMEDIATE_SR(MDCCINT_EL1);
> >+DECLARE_IMMEDIATE_SR(PMCR_EL0);
> >+DECLARE_IMMEDIATE_SR(PMSELR_EL0);
> >+DECLARE_IMMEDIATE_SR(PMEVCNTR0_EL0);
> >+/* PMEVCNTR30_EL0 */
> >+DECLARE_IMMEDIATE_SR(PMCCNTR_EL0);
> >+DECLARE_IMMEDIATE_SR(PMEVTYPER0_EL0);
> >+/* PMEVTYPER30_EL0 */
> >+DECLARE_IMMEDIATE_SR(PMCCFILTR_EL0);
> >+DECLARE_IMMEDIATE_SR(PMCNTENSET_EL0);
> >+DECLARE_IMMEDIATE_SR(PMINTENSET_EL1);
> >+DECLARE_IMMEDIATE_SR(PMOVSSET_EL0);
> >+DECLARE_IMMEDIATE_SR(PMSWINC_EL0);
> >+DECLARE_IMMEDIATE_SR(PMUSERENR_EL0);
> >+DECLARE_IMMEDIATE_SR(DACR32_EL2);
> >+DECLARE_IMMEDIATE_SR(IFSR32_EL2);
> >+DECLARE_IMMEDIATE_SR(FPEXC32_EL2);
> >+DECLARE_IMMEDIATE_SR(DBGVCR32_EL2);
> >+
> >+static const struct sys_reg_accessor sys_reg_accessors[NR_SYS_REGS] = {
> >+ [0 ... NR_SYS_REGS - 1] = {
> >+ .rdsr = __default_read_sys_reg,
> >+ .wrsr = __default_write_sys_reg,
> >+ },
> >+
> >+ SR_HANDLER(MPIDR_EL1),
> >+ SR_HANDLER(CSSELR_EL1),
> >+ SR_HANDLER(SCTLR_EL1),
> >+ SR_HANDLER(ACTLR_EL1),
> >+ SR_HANDLER(CPACR_EL1),
> >+ SR_HANDLER(TTBR0_EL1),
> >+ SR_HANDLER(TTBR1_EL1),
> >+ SR_HANDLER(TCR_EL1),
> >+ SR_HANDLER(ESR_EL1),
> >+ SR_HANDLER(AFSR0_EL1),
> >+ SR_HANDLER(AFSR1_EL1),
> >+ SR_HANDLER(FAR_EL1),
> >+ SR_HANDLER(MAIR_EL1),
> >+ SR_HANDLER(VBAR_EL1),
> >+ SR_HANDLER(CONTEXTIDR_EL1),
> >+ SR_HANDLER(TPIDR_EL0),
> >+ SR_HANDLER(TPIDRRO_EL0),
> >+ SR_HANDLER(TPIDR_EL1),
> >+ SR_HANDLER(AMAIR_EL1),
> >+ SR_HANDLER(CNTKCTL_EL1),
> >+ SR_HANDLER(PAR_EL1),
> >+ SR_HANDLER(MDSCR_EL1),
> >+ SR_HANDLER(MDCCINT_EL1),
> >+ SR_HANDLER(PMCR_EL0),
> >+ SR_HANDLER(PMSELR_EL0),
> >+ SR_HANDLER_RANGE(PMEVCNTR0_EL0, PMEVCNTR30_EL0),
> >+ SR_HANDLER(PMCCNTR_EL0),
> >+ SR_HANDLER_RANGE(PMEVTYPER0_EL0, PMEVTYPER30_EL0),
> >+ SR_HANDLER(PMCCFILTR_EL0),
> >+ SR_HANDLER(PMCNTENSET_EL0),
> >+ SR_HANDLER(PMINTENSET_EL1),
> >+ SR_HANDLER(PMOVSSET_EL0),
> >+ SR_HANDLER(PMSWINC_EL0),
> >+ SR_HANDLER(PMUSERENR_EL0),
> >+ SR_HANDLER(DACR32_EL2),
> >+ SR_HANDLER(IFSR32_EL2),
> >+ SR_HANDLER(FPEXC32_EL2),
> >+ SR_HANDLER(DBGVCR32_EL2),
> >+};
> >+
> >+u64 vcpu_read_sys_reg(struct kvm_vcpu *vcpu, int reg)
> >+{
> >+ return sys_reg_accessors[reg].rdsr(vcpu, reg);
> >+}
> >+
> >+void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, int reg, u64 val)
> >+{
> >+ sys_reg_accessors[reg].wrsr(vcpu, reg, val);
> >+}
> >+
> > /* 3 bits per cache level, as per CLIDR, but non-existent caches always 0 */
> > static u32 cache_levels;
> >
>
> --
> Julien Thierry
next prev parent reply other threads:[~2018-01-18 13:08 UTC|newest]
Thread overview: 112+ 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 ` [PATCH v3 01/41] KVM: arm/arm64: Avoid vcpu_load for other vcpu ioctls than KVM_RUN Christoffer Dall
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-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-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-02-05 18:04 ` Julien Grall
2018-02-05 18:10 ` Julien Grall
2018-02-08 13:24 ` Christoffer Dall
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-02-09 11:38 ` Julien Grall
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 ` [PATCH v3 07/41] KVM: arm/arm64: Add kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs Christoffer Dall
2018-01-12 12:07 ` [PATCH v3 08/41] KVM: arm/arm64: Introduce vcpu_el1_is_32bit Christoffer Dall
2018-01-17 14:44 ` Julien Thierry
2018-01-18 12:57 ` Christoffer Dall
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-22 17:33 ` Dave Martin
2018-01-25 19:46 ` Christoffer Dall
2018-02-07 16:49 ` Dave Martin
2018-02-07 17:56 ` Christoffer Dall
2018-02-09 15:59 ` Dave Martin
2018-02-13 8:51 ` Christoffer Dall
2018-02-13 14:08 ` Dave Martin
2018-02-14 10:15 ` Christoffer Dall
2018-02-14 14:43 ` Dave Martin
2018-02-14 17:38 ` Christoffer Dall
2018-02-14 17:43 ` Ard Biesheuvel
2018-02-14 21:08 ` Marc Zyngier
2018-02-15 9:51 ` Dave Martin
2018-02-09 15:26 ` Julien Grall
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-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 ` [PATCH v3 12/41] KVM: arm64: Improve debug register save/restore flow 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-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-24 16:13 ` Dave Martin
2018-01-25 8:45 ` Christoffer Dall
2018-02-09 17:34 ` Julien Grall
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-24 16:24 ` Dave Martin
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 ` [PATCH v3 17/41] KVM: arm64: Remove noop calls to timer save/restore from VHE switch Christoffer Dall
2018-02-09 17:53 ` Julien Grall
2018-02-13 8:53 ` Christoffer Dall
2018-02-13 22:31 ` Christoffer Dall
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-02-09 18:50 ` Julien Grall
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 ` [PATCH v3 20/41] KVM: arm64: Introduce separate VHE/non-VHE sysreg save/restore functions 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 ` [PATCH v3 22/41] KVM: arm64: Unify non-VHE host/guest sysreg save and restore functions 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 ` [PATCH v3 24/41] KVM: arm64: Change 32-bit handling of VM system registers 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 ` [PATCH v3 26/41] KVM: arm64: Introduce framework for accessing deferred sysregs Christoffer Dall
2018-01-17 17:52 ` Julien Thierry
2018-01-18 13:08 ` Christoffer Dall [this message]
2018-01-18 13:39 ` Julien Thierry
2018-01-23 16:04 ` Dave Martin
2018-01-25 19:54 ` Christoffer Dall
2018-02-09 16:17 ` Dave Martin
2018-02-13 8:55 ` Christoffer Dall
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 ` [PATCH v3 28/41] KVM: arm64: Prepare to handle deferred save/restore of ELR_EL1 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 ` [PATCH v3 30/41] KVM: arm64: Prepare to handle deferred save/restore of 32-bit registers Christoffer Dall
2018-01-17 18:22 ` Julien Thierry
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 ` [PATCH v3 32/41] KVM: arm64: Move common VHE/non-VHE trap config in separate functions Christoffer Dall
2018-01-12 12:07 ` [PATCH v3 33/41] KVM: arm64: Configure FPSIMD traps on vcpu load/put Christoffer Dall
2018-01-18 9:31 ` Julien Thierry
2018-01-31 12:17 ` Tomasz Nowicki
2018-02-05 10:06 ` Christoffer Dall
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 ` [PATCH v3 35/41] KVM: arm64: Separate activate_traps and deactive_traps for VHE and non-VHE 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 ` [PATCH v3 37/41] KVM: arm/arm64: Handle VGICv2 save/restore from the main VGIC code 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 ` [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 ` [PATCH v3 40/41] KVM: arm/arm64: Move VGIC APR save/restore to vgic put/load 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-02-05 13:29 ` Tomasz Nowicki
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 15:50 ` Christoffer Dall
2018-01-17 8:34 ` Yury Norov
2018-01-17 10:48 ` Christoffer Dall
2018-01-18 11:16 ` Christoffer Dall
2018-01-18 12:18 ` Yury Norov
2018-01-18 13:32 ` Christoffer Dall
2018-01-22 13:40 ` Tomasz Nowicki
2018-02-01 13:57 ` Tomasz Nowicki
2018-02-01 16:15 ` Yury Norov
2018-02-02 10:05 ` Tomasz Nowicki
2018-02-02 10:07 ` Tomasz Nowicki
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=20180118130823.GC27865@cbox \
--to=christoffer.dall@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).