All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amit Daniel Kachhap <amit.kachhap@arm.com>
To: Julien Thierry <julien.thierry@arm.com>,
	linux-arm-kernel@lists.infradead.org
Cc: Christoffer Dall <christoffer.dall@arm.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Andrew Jones <drjones@redhat.com>,
	Dave Martin <Dave.Martin@arm.com>,
	Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>,
	kvmarm@lists.cs.columbia.edu,
	Kristina Martsenko <kristina.martsenko@arm.com>,
	linux-kernel@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,
	James Morse <james.morse@arm.com>
Subject: Re: [PATCH v7 7/10] KVM: arm/arm64: context-switch ptrauth registers
Date: Thu, 21 Mar 2019 11:38:35 +0530	[thread overview]
Message-ID: <44e16529-4792-0ec2-d2d5-f5c14c6bb2c4@arm.com> (raw)
In-Reply-To: <a3252299-b1ac-3d39-31a4-ca653daa815f@arm.com>

Hi Julien,

On 3/20/19 5:43 PM, Julien Thierry wrote:
> Hi Amit,
> 
> On 19/03/2019 08:30, Amit Daniel Kachhap wrote:
>> From: Mark Rutland <mark.rutland@arm.com>
>>
>> When pointer authentication is supported, a guest may wish to use it.
>> This patch adds the necessary KVM infrastructure for this to work, with
>> a semi-lazy context switch of the pointer auth state.
>>
>> Pointer authentication feature is only enabled when VHE is built
>> in the kernel and present in the CPU implementation so only VHE code
>> paths are modified.
>>
>> When we schedule a vcpu, we disable guest usage of pointer
>> authentication instructions and accesses to the keys. While these are
>> disabled, we avoid context-switching the keys. When we trap the guest
>> trying to use pointer authentication functionality, we change to eagerly
>> context-switching the keys, and enable the feature. The next time the
>> vcpu is scheduled out/in, we start again. However the host key save is
>> optimized and implemented inside ptrauth instruction/register access
>> trap.
>>
>> Pointer authentication consists of address authentication and generic
>> authentication, and CPUs in a system might have varied support for
>> either. Where support for either feature is not uniform, it is hidden
>> from guests via ID register emulation, as a result of the cpufeature
>> framework in the host.
>>
>> Unfortunately, address authentication and generic authentication cannot
>> be trapped separately, as the architecture provides a single EL2 trap
>> covering both. If we wish to expose one without the other, we cannot
>> prevent a (badly-written) guest from intermittently using a feature
>> which is not uniformly supported (when scheduled on a physical CPU which
>> supports the relevant feature). Hence, this patch expects both type of
>> authentication to be present in a cpu.
>>
>> This switch of key is done from guest enter/exit assembly as preperation
>> for the upcoming in-kernel pointer authentication support. Hence, these
>> key switching routines are not implemented in C code as they may cause
>> pointer authentication key signing error in some situations.
>>
>> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>> [Only VHE, key switch in full assembly, vcpu_has_ptrauth checks
>> , save host key in ptrauth exception trap]
>> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
>> Reviewed-by: Julien Thierry <julien.thierry@arm.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Christoffer Dall <christoffer.dall@arm.com>
>> Cc: kvmarm@lists.cs.columbia.edu
>> ---
>>   arch/arm64/include/asm/kvm_host.h        |  17 ++++++
>>   arch/arm64/include/asm/kvm_ptrauth_asm.h | 100 +++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/asm-offsets.c          |   6 ++
>>   arch/arm64/kvm/guest.c                   |  14 +++++
>>   arch/arm64/kvm/handle_exit.c             |  24 +++++---
>>   arch/arm64/kvm/hyp/entry.S               |   7 +++
>>   arch/arm64/kvm/reset.c                   |   7 +++
>>   arch/arm64/kvm/sys_regs.c                |  46 +++++++++++++-
>>   virt/kvm/arm/arm.c                       |   2 +
>>   9 files changed, 212 insertions(+), 11 deletions(-)
>>   create mode 100644 arch/arm64/include/asm/kvm_ptrauth_asm.h
>>
[...]
>> +#ifdef	CONFIG_ARM64_PTR_AUTH
>> +
>> +#define PTRAUTH_REG_OFFSET(x)	(x - CPU_APIAKEYLO_EL1)
> 
> I don't really see the point of this macro. You move the pointers of
> kvm_cpu_contexts to point to where the ptr auth registers are (which is
> in the middle of an array) by adding the offset of APIAKEYLO and then we
> have to recompute all offsets with this macro.
> 
> Why not just pass the kvm_cpu_context pointers to
> ptrauth_save/restore_state and use the already defined offsets
> (CPU_AP*_EL1) directly?
> 
> I think this would also allow to use one less register for the
> ptrauth_switch_to_* macros.
Actually the values of CPU_AP*_EL1 are exceeding the immediate range 
(i.e 512), so this was done to keep the immediate offset within the range.
The other way would have been to calculate the destination register but 
these would add one more add instruction everywhere.
I should have mentioned them as comments somewhere.
> 
>> +
>> +.macro	ptrauth_save_state base, reg1, reg2
>> +	mrs_s	\reg1, SYS_APIAKEYLO_EL1
>> +	mrs_s	\reg2, SYS_APIAKEYHI_EL1
>> +	stp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APIAKEYLO_EL1)]
>> +	mrs_s	\reg1, SYS_APIBKEYLO_EL1
>> +	mrs_s	\reg2, SYS_APIBKEYHI_EL1
>> +	stp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APIBKEYLO_EL1)]
>> +	mrs_s	\reg1, SYS_APDAKEYLO_EL1
>> +	mrs_s	\reg2, SYS_APDAKEYHI_EL1
>> +	stp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APDAKEYLO_EL1)]
>> +	mrs_s	\reg1, SYS_APDBKEYLO_EL1
>> +	mrs_s	\reg2, SYS_APDBKEYHI_EL1
>> +	stp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APDBKEYLO_EL1)]
>> +	mrs_s	\reg1, SYS_APGAKEYLO_EL1
>> +	mrs_s	\reg2, SYS_APGAKEYHI_EL1
>> +	stp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APGAKEYLO_EL1)]
>> +.endm
>> +
>> +.macro	ptrauth_restore_state base, reg1, reg2
>> +	ldp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APIAKEYLO_EL1)]
>> +	msr_s	SYS_APIAKEYLO_EL1, \reg1
>> +	msr_s	SYS_APIAKEYHI_EL1, \reg2
>> +	ldp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APIBKEYLO_EL1)]
>> +	msr_s	SYS_APIBKEYLO_EL1, \reg1
>> +	msr_s	SYS_APIBKEYHI_EL1, \reg2
>> +	ldp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APDAKEYLO_EL1)]
>> +	msr_s	SYS_APDAKEYLO_EL1, \reg1
>> +	msr_s	SYS_APDAKEYHI_EL1, \reg2
>> +	ldp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APDBKEYLO_EL1)]
>> +	msr_s	SYS_APDBKEYLO_EL1, \reg1
>> +	msr_s	SYS_APDBKEYHI_EL1, \reg2
>> +	ldp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APGAKEYLO_EL1)]
>> +	msr_s	SYS_APGAKEYLO_EL1, \reg1
>> +	msr_s	SYS_APGAKEYHI_EL1, \reg2
>> +	.endm
> 
> Nit: Bad indentation.
oops.
> 
>> +
>> +.macro ptrauth_switch_to_guest g_ctxt, reg1, reg2, reg3
>> +	ldr	\reg1, [\g_ctxt, #CPU_HCR_EL2]
>> +	and	\reg1, \reg1, #(HCR_API | HCR_APK)
>> +	cbz	\reg1, skip_switch_to_guest
>> +	add	\reg1, \g_ctxt, #CPU_APIAKEYLO_EL1
>> +	ptrauth_restore_state	\reg1, \reg2, \reg3
> 
> As mentioned we probably can get rid of one temporary register and
> directly pass g_ctxt here.
> 
>> +skip_switch_to_guest:
> 
> I believe you should use numbered labels for assembly macros, otherwise
> multiple references to that macros will lead to symbol redefinitions.
Yes agreed.

Thanks,
Amit
> 
>> +.endm
>> +
>> +.macro ptrauth_switch_to_host g_ctxt, h_ctxt, reg1, reg2, reg3
>> +	ldr	\reg1, [\g_ctxt, #CPU_HCR_EL2]
>> +	and	\reg1, \reg1, #(HCR_API | HCR_APK)
>> +	cbz	\reg1, skip_switch_to_host
>> +	add	\reg1, \g_ctxt, #CPU_APIAKEYLO_EL1
>> +	ptrauth_save_state	\reg1, \reg2, \reg3
>> +	add	\reg1, \h_ctxt, #CPU_APIAKEYLO_EL1
>> +	ptrauth_restore_state	\reg1, \reg2, \reg3
>> +	isb
>> +skip_switch_to_host:
> 
> Same.
> 
> Cheers,
> 
> Julien
> 
>> +.endm
>> +
>> +#else /* !CONFIG_ARM64_PTR_AUTH */
>> +.macro ptrauth_switch_to_guest g_ctxt, reg1, reg2, reg3
>> +.endm
>> +.macro ptrauth_switch_to_host g_ctxt, h_ctxt, reg1, reg2, reg3
[...]
>>
> 

WARNING: multiple messages have this Message-ID (diff)
From: Amit Daniel Kachhap <amit.kachhap@arm.com>
To: Julien Thierry <julien.thierry@arm.com>,
	linux-arm-kernel@lists.infradead.org
Cc: Mark Rutland <mark.rutland@arm.com>,
	Andrew Jones <drjones@redhat.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Christoffer Dall <christoffer.dall@arm.com>,
	Kristina Martsenko <kristina.martsenko@arm.com>,
	kvmarm@lists.cs.columbia.edu, James Morse <james.morse@arm.com>,
	Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>,
	Dave Martin <Dave.Martin@arm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 7/10] KVM: arm/arm64: context-switch ptrauth registers
Date: Thu, 21 Mar 2019 11:38:35 +0530	[thread overview]
Message-ID: <44e16529-4792-0ec2-d2d5-f5c14c6bb2c4@arm.com> (raw)
In-Reply-To: <a3252299-b1ac-3d39-31a4-ca653daa815f@arm.com>

Hi Julien,

On 3/20/19 5:43 PM, Julien Thierry wrote:
> Hi Amit,
> 
> On 19/03/2019 08:30, Amit Daniel Kachhap wrote:
>> From: Mark Rutland <mark.rutland@arm.com>
>>
>> When pointer authentication is supported, a guest may wish to use it.
>> This patch adds the necessary KVM infrastructure for this to work, with
>> a semi-lazy context switch of the pointer auth state.
>>
>> Pointer authentication feature is only enabled when VHE is built
>> in the kernel and present in the CPU implementation so only VHE code
>> paths are modified.
>>
>> When we schedule a vcpu, we disable guest usage of pointer
>> authentication instructions and accesses to the keys. While these are
>> disabled, we avoid context-switching the keys. When we trap the guest
>> trying to use pointer authentication functionality, we change to eagerly
>> context-switching the keys, and enable the feature. The next time the
>> vcpu is scheduled out/in, we start again. However the host key save is
>> optimized and implemented inside ptrauth instruction/register access
>> trap.
>>
>> Pointer authentication consists of address authentication and generic
>> authentication, and CPUs in a system might have varied support for
>> either. Where support for either feature is not uniform, it is hidden
>> from guests via ID register emulation, as a result of the cpufeature
>> framework in the host.
>>
>> Unfortunately, address authentication and generic authentication cannot
>> be trapped separately, as the architecture provides a single EL2 trap
>> covering both. If we wish to expose one without the other, we cannot
>> prevent a (badly-written) guest from intermittently using a feature
>> which is not uniformly supported (when scheduled on a physical CPU which
>> supports the relevant feature). Hence, this patch expects both type of
>> authentication to be present in a cpu.
>>
>> This switch of key is done from guest enter/exit assembly as preperation
>> for the upcoming in-kernel pointer authentication support. Hence, these
>> key switching routines are not implemented in C code as they may cause
>> pointer authentication key signing error in some situations.
>>
>> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>> [Only VHE, key switch in full assembly, vcpu_has_ptrauth checks
>> , save host key in ptrauth exception trap]
>> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
>> Reviewed-by: Julien Thierry <julien.thierry@arm.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Christoffer Dall <christoffer.dall@arm.com>
>> Cc: kvmarm@lists.cs.columbia.edu
>> ---
>>   arch/arm64/include/asm/kvm_host.h        |  17 ++++++
>>   arch/arm64/include/asm/kvm_ptrauth_asm.h | 100 +++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/asm-offsets.c          |   6 ++
>>   arch/arm64/kvm/guest.c                   |  14 +++++
>>   arch/arm64/kvm/handle_exit.c             |  24 +++++---
>>   arch/arm64/kvm/hyp/entry.S               |   7 +++
>>   arch/arm64/kvm/reset.c                   |   7 +++
>>   arch/arm64/kvm/sys_regs.c                |  46 +++++++++++++-
>>   virt/kvm/arm/arm.c                       |   2 +
>>   9 files changed, 212 insertions(+), 11 deletions(-)
>>   create mode 100644 arch/arm64/include/asm/kvm_ptrauth_asm.h
>>
[...]
>> +#ifdef	CONFIG_ARM64_PTR_AUTH
>> +
>> +#define PTRAUTH_REG_OFFSET(x)	(x - CPU_APIAKEYLO_EL1)
> 
> I don't really see the point of this macro. You move the pointers of
> kvm_cpu_contexts to point to where the ptr auth registers are (which is
> in the middle of an array) by adding the offset of APIAKEYLO and then we
> have to recompute all offsets with this macro.
> 
> Why not just pass the kvm_cpu_context pointers to
> ptrauth_save/restore_state and use the already defined offsets
> (CPU_AP*_EL1) directly?
> 
> I think this would also allow to use one less register for the
> ptrauth_switch_to_* macros.
Actually the values of CPU_AP*_EL1 are exceeding the immediate range 
(i.e 512), so this was done to keep the immediate offset within the range.
The other way would have been to calculate the destination register but 
these would add one more add instruction everywhere.
I should have mentioned them as comments somewhere.
> 
>> +
>> +.macro	ptrauth_save_state base, reg1, reg2
>> +	mrs_s	\reg1, SYS_APIAKEYLO_EL1
>> +	mrs_s	\reg2, SYS_APIAKEYHI_EL1
>> +	stp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APIAKEYLO_EL1)]
>> +	mrs_s	\reg1, SYS_APIBKEYLO_EL1
>> +	mrs_s	\reg2, SYS_APIBKEYHI_EL1
>> +	stp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APIBKEYLO_EL1)]
>> +	mrs_s	\reg1, SYS_APDAKEYLO_EL1
>> +	mrs_s	\reg2, SYS_APDAKEYHI_EL1
>> +	stp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APDAKEYLO_EL1)]
>> +	mrs_s	\reg1, SYS_APDBKEYLO_EL1
>> +	mrs_s	\reg2, SYS_APDBKEYHI_EL1
>> +	stp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APDBKEYLO_EL1)]
>> +	mrs_s	\reg1, SYS_APGAKEYLO_EL1
>> +	mrs_s	\reg2, SYS_APGAKEYHI_EL1
>> +	stp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APGAKEYLO_EL1)]
>> +.endm
>> +
>> +.macro	ptrauth_restore_state base, reg1, reg2
>> +	ldp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APIAKEYLO_EL1)]
>> +	msr_s	SYS_APIAKEYLO_EL1, \reg1
>> +	msr_s	SYS_APIAKEYHI_EL1, \reg2
>> +	ldp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APIBKEYLO_EL1)]
>> +	msr_s	SYS_APIBKEYLO_EL1, \reg1
>> +	msr_s	SYS_APIBKEYHI_EL1, \reg2
>> +	ldp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APDAKEYLO_EL1)]
>> +	msr_s	SYS_APDAKEYLO_EL1, \reg1
>> +	msr_s	SYS_APDAKEYHI_EL1, \reg2
>> +	ldp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APDBKEYLO_EL1)]
>> +	msr_s	SYS_APDBKEYLO_EL1, \reg1
>> +	msr_s	SYS_APDBKEYHI_EL1, \reg2
>> +	ldp	\reg1, \reg2, [\base, #PTRAUTH_REG_OFFSET(CPU_APGAKEYLO_EL1)]
>> +	msr_s	SYS_APGAKEYLO_EL1, \reg1
>> +	msr_s	SYS_APGAKEYHI_EL1, \reg2
>> +	.endm
> 
> Nit: Bad indentation.
oops.
> 
>> +
>> +.macro ptrauth_switch_to_guest g_ctxt, reg1, reg2, reg3
>> +	ldr	\reg1, [\g_ctxt, #CPU_HCR_EL2]
>> +	and	\reg1, \reg1, #(HCR_API | HCR_APK)
>> +	cbz	\reg1, skip_switch_to_guest
>> +	add	\reg1, \g_ctxt, #CPU_APIAKEYLO_EL1
>> +	ptrauth_restore_state	\reg1, \reg2, \reg3
> 
> As mentioned we probably can get rid of one temporary register and
> directly pass g_ctxt here.
> 
>> +skip_switch_to_guest:
> 
> I believe you should use numbered labels for assembly macros, otherwise
> multiple references to that macros will lead to symbol redefinitions.
Yes agreed.

Thanks,
Amit
> 
>> +.endm
>> +
>> +.macro ptrauth_switch_to_host g_ctxt, h_ctxt, reg1, reg2, reg3
>> +	ldr	\reg1, [\g_ctxt, #CPU_HCR_EL2]
>> +	and	\reg1, \reg1, #(HCR_API | HCR_APK)
>> +	cbz	\reg1, skip_switch_to_host
>> +	add	\reg1, \g_ctxt, #CPU_APIAKEYLO_EL1
>> +	ptrauth_save_state	\reg1, \reg2, \reg3
>> +	add	\reg1, \h_ctxt, #CPU_APIAKEYLO_EL1
>> +	ptrauth_restore_state	\reg1, \reg2, \reg3
>> +	isb
>> +skip_switch_to_host:
> 
> Same.
> 
> Cheers,
> 
> Julien
> 
>> +.endm
>> +
>> +#else /* !CONFIG_ARM64_PTR_AUTH */
>> +.macro ptrauth_switch_to_guest g_ctxt, reg1, reg2, reg3
>> +.endm
>> +.macro ptrauth_switch_to_host g_ctxt, h_ctxt, reg1, reg2, reg3
[...]
>>
> 

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

  reply	other threads:[~2019-03-21  6:08 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-19  8:30 [PATCH v7 0/10] Add ARMv8.3 pointer authentication for kvm guest Amit Daniel Kachhap
2019-03-19  8:30 ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 1/10] KVM: arm64: Propagate vcpu into read_id_reg() Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 2/10] KVM: arm64: Support runtime sysreg visibility filtering Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 3/10] KVM: arm64: Move hyp_symbol_addr to fix dependency Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-20  8:49   ` Julien Thierry
2019-03-20  8:49     ` Julien Thierry
2019-03-21  5:29     ` Amit Daniel Kachhap
2019-03-21  5:29       ` Amit Daniel Kachhap
2019-03-21  5:29       ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 4/10] KVM: arm/arm64: preserve host HCR_EL2 value Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 5/10] KVM: arm/arm64: preserve host MDCR_EL2 value Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-25 20:04   ` Kristina Martsenko
2019-03-25 20:04     ` Kristina Martsenko
2019-03-26  3:55     ` Amit Daniel Kachhap
2019-03-26  3:55       ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 6/10] KVM: arm64: Add vcpu feature flags to control ptrauth accessibility Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 7/10] KVM: arm/arm64: context-switch ptrauth registers Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-20 12:13   ` Julien Thierry
2019-03-20 12:13     ` Julien Thierry
2019-03-21  6:08     ` Amit Daniel Kachhap [this message]
2019-03-21  6:08       ` Amit Daniel Kachhap
2019-03-21  8:29       ` Julien Thierry
2019-03-21  8:29         ` Julien Thierry
2019-03-25 20:04   ` Kristina Martsenko
2019-03-25 20:04     ` Kristina Martsenko
2019-03-26  4:03     ` Amit Daniel Kachhap
2019-03-26  4:03       ` Amit Daniel Kachhap
2019-03-26 18:01       ` Kristina Martsenko
2019-03-26 18:01         ` Kristina Martsenko
2019-03-27  3:21         ` Amit Daniel Kachhap
2019-03-27  3:21           ` Amit Daniel Kachhap
2019-03-27  3:21           ` Amit Daniel Kachhap
2019-03-27 18:16           ` James Morse
2019-03-27 18:16             ` James Morse
2019-03-27 18:16             ` James Morse
2019-03-28 11:29             ` Amit Daniel Kachhap
2019-03-28 11:29               ` Amit Daniel Kachhap
2019-03-28 18:51   ` James Morse
2019-03-28 18:51     ` James Morse
2019-03-29  5:54     ` Amit Daniel Kachhap
2019-03-29  5:54       ` Amit Daniel Kachhap
2019-03-29  5:54       ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 8/10] KVM: arm64: Add capability to advertise ptrauth for guest Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-25 20:05   ` Kristina Martsenko
2019-03-25 20:05     ` Kristina Martsenko
2019-03-26  4:12     ` Amit Daniel Kachhap
2019-03-26  4:12       ` Amit Daniel Kachhap
2019-03-26  4:12       ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 9/10] KVM: arm64: docs: document KVM support of pointer authentication Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-20 13:37   ` Julien Thierry
2019-03-20 13:37     ` Julien Thierry
2019-03-20 15:04     ` Kristina Martsenko
2019-03-20 15:04       ` Kristina Martsenko
2019-03-20 18:06       ` Julien Thierry
2019-03-20 18:06         ` Julien Thierry
2019-03-20 20:56         ` Kristina Martsenko
2019-03-20 20:56           ` Kristina Martsenko
2019-03-21  6:41           ` Amit Daniel Kachhap
2019-03-21  6:41             ` Amit Daniel Kachhap
2019-03-25 20:05   ` Kristina Martsenko
2019-03-25 20:05     ` Kristina Martsenko
2019-03-27 10:44     ` Dave Martin
2019-03-27 10:44       ` Dave Martin
2019-03-27 11:49       ` Amit Daniel Kachhap
2019-03-27 11:49         ` Amit Daniel Kachhap
2019-03-27 13:50         ` Dave Martin
2019-03-27 13:50           ` Dave Martin
2019-03-28 10:13           ` Amit Daniel Kachhap
2019-03-28 10:13             ` Amit Daniel Kachhap
2019-03-19  8:30 ` [kvmtool PATCH v7 10/10] KVM: arm/arm64: Add a vcpu feature for " Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap

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=44e16529-4792-0ec2-d2d5-f5c14c6bb2c4@arm.com \
    --to=amit.kachhap@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@arm.com \
    --cc=drjones@redhat.com \
    --cc=james.morse@arm.com \
    --cc=julien.thierry@arm.com \
    --cc=kristina.martsenko@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=ramana.radhakrishnan@arm.com \
    --cc=will.deacon@arm.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.