Re: [PATCH 12/15] arm-soc: omap: replace open coded VA->PA calculations

On 10 August 2017 at 15:03, Tony Lindgren <t...@atomide.com> wrote: > * Ard Biesheuvel <ard.biesheu...@linaro.org> [170810 02:23]: >> On 9 August 2017 at 22:05, Tony Lindgren <t...@atomide.com> wrote: >> > * Ard Biesheuvel <ard.biesheu...@linaro.org> [1708

Re: [PATCH 05/15] ARM: head: use PC-relative insn sequence for __smp_alt

On 11 August 2017 at 21:06, Nicolas Pitre <nicolas.pi...@linaro.org> wrote: > On Fri, 11 Aug 2017, Ard Biesheuvel wrote: > >> On 11 August 2017 at 20:58, Nicolas Pitre <nicolas.pi...@linaro.org> wrote: >> > On Fri, 11 Aug 2017, Ard Biesheuvel wrote: >> &

Re: [PATCH 05/15] ARM: head: use PC-relative insn sequence for __smp_alt

On 11 August 2017 at 16:13, Tony Lindgren <t...@atomide.com> wrote: > * Ard Biesheuvel <ard.biesheu...@linaro.org> [170805 13:54]: >> Replace the open coded PC relative offset calculations with a pair >> of adr_l invocations. >> >> Signed-off-by: Ar

Re: [PATCH 05/15] ARM: head: use PC-relative insn sequence for __smp_alt

On 14 August 2017 at 17:19, Tony Lindgren <t...@atomide.com> wrote: > * Ard Biesheuvel <ard.biesheu...@linaro.org> [170811 12:37]: >> On 11 August 2017 at 16:13, Tony Lindgren <t...@atomide.com> wrote: >> > * Ard Biesheuvel <ard.biesheu...@linaro.org> [1

Re: [PATCH v2] arm64: Add ASM modifier for xN register operands

On 28 April 2017 at 10:53, Mark Rutland <mark.rutl...@arm.com> wrote: > On Fri, Apr 28, 2017 at 08:18:52AM +0100, Ard Biesheuvel wrote: >> On 27 April 2017 at 23:52, Matthias Kaehlcke <m...@chromium.org> wrote: >> > El Thu, Apr 27, 2017 at 12:02:56PM +0100 Mark Rutlan

Re: [PATCH v2] arm64: Add ASM modifier for xN register operands

On 28 April 2017 at 15:33, Mark Rutland <mark.rutl...@arm.com> wrote: > On Fri, Apr 28, 2017 at 08:18:52AM +0100, Ard Biesheuvel wrote: >> On 27 April 2017 at 23:52, Matthias Kaehlcke <m...@chromium.org> wrote: >> > El Thu, Apr 27, 2017 at 12:02:56PM +0100 Mark Rutlan

Re: [PATCH v2] arm64: Add ASM modifier for xN register operands

On 27 April 2017 at 23:52, Matthias Kaehlcke wrote: > Hi Mark, > > Thanks for your comments. > > El Thu, Apr 27, 2017 at 12:02:56PM +0100 Mark Rutland ha dit: > >> Hi, >> >> On Wed, Apr 26, 2017 at 02:46:16PM -0700, Matthias Kaehlcke wrote: >> > Many inline assembly statements

[PATCH 03/15] ARM: head-common.S: use PC-relative insn sequence for __turn_mmu_on

Replace the open coded PC relative offset calculations with a pair of adr_l invocations. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/kernel/head.S | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/arch/arm/kernel/head.S b/arch/arm/

[PATCH 09/15] ARM: kvm: replace open coded VA->PA calculations with adr_l call

Replace the open coded calculations of the actual physical address of the KVM stub vector table with a single adr_l invocation. Cc: Marc Zyngier <marc.zyng...@arm.com> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/boot/compressed/head.S | 15 ++--- arc

[PATCH 10/15] arm-soc: exynos: replace open coded VA->PA conversions

This replaces a couple of open coded calculations to obtain the physical address of a far symbol with calls to the new adr_l etc macros. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/mach-exynos/headsmp.S | 9 +-- arch/arm/mach-exynos/sleep.S

[PATCH 04/15] ARM: head.S: use PC-relative insn sequence for secondary_data

Replace the open coded PC relative offset calculations with adr_l and ldr_l invocations. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/kernel/head.S | 19 --- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/arch/arm/kernel/head.S b/ar

[PATCH 12/15] arm-soc: omap: replace open coded VA->PA calculations

This replaces a couple of open coded calculations to obtain the physical address of a far symbol with calls to the new adr_l etc macros. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/mach-omap2/sleep34xx.S | 21 arch/arm/mach-omap2/sleep44xx.

[PATCH 13/15] arm-soc: various: replace open coded VA->PA calculation of pen_release

This replaces a few copies of the open coded calculations of the physical address of 'pen_release' in the secondary startup code of a couple of platforms. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/mach-prima2/headsmp.S| 11 +++ arch/arm/mach

[PATCH 11/15] arm-soc: mvebu: replace open coded VA->PA conversion

This replaces an open coded calculation to obtain the physical address of a far symbol with a call to the new ldr_l etc macro. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/mach-mvebu/coherency_ll.S | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff

[PATCH 06/15] ARM: sleep.S: use PC-relative insn sequence for sleep_save_sp/mpidr_hash

Replace the open coded PC relative offset calculations with adr_l and ldr_l invocations. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/kernel/sleep.S | 16 +++- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/arch/arm/kernel/sleep.S b/ar

[PATCH 01/15] ARM: assembler: introduce adr_l, ldr_l and str_l macros

rs on v7 and later CPUs, and use PC-relative literals otherwise. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/include/asm/assembler.h | 70 1 file changed, 70 insertions(+) diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/a

[PATCH 05/15] ARM: head: use PC-relative insn sequence for __smp_alt

Replace the open coded PC relative offset calculations with a pair of adr_l invocations. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/kernel/head.S | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/arch/arm/kernel/head.S b/arch/arm/

[PATCH 02/15] ARM: head-common.S: use PC-relative insn sequence for __proc_info

Replace the open coded PC relative offset calculations with a pair of adr_l invocations. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/kernel/head-common.S | 22 ++-- 1 file changed, 6 insertions(+), 16 deletions(-) diff --git a/arch/arm/kerne

[PATCH 08/15] ARM: head.S: use PC relative insn sequence to calculate PHYS_OFFSET

Replace the open coded arithmetic with a simple adr_l/sub pair. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/kernel/head.S | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index 939543

[PATCH 07/15] ARM: head.S: use PC-relative insn sequences for __fixup_pv_table

Replace the open coded PC relative offset calculations with adr_l and mov_l invocations. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/kernel/head.S | 27 ++-- 1 file changed, 8 insertions(+), 19 deletions(-) diff --git a/arch/arm/kernel/head.S

[PATCH 15/15] ARM: l2c: replace open coded VA->PA calculation

This replaces an open coded calculation to obtain the physical address of a far symbol with a call to the new adr_l macro. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/mm/l2c-l2x0-resume.S | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git

[PATCH 14/15] arm-soc: shmobile: replace open coded VA->PA calculation

This replaces a couple of open coded calculations to obtain the physical address of a far symbol with calls to the new adr_l etc macros. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/mach-shmobile/headsmp.S | 14 -- 1 file changed, 4 insertions(

[PATCH 00/15] ARM: add and use convenience macros for PC relative references

on the first one. I understand there may be concerns about churn, but some of these cleanups are really quite nice so please don't dismiss the series wholesale for that reason. Ard Biesheuvel (15): ARM: assembler: introduce adr_l, ldr_l and str_l macros ARM: head-common.S: use PC-relative insn

Re: [PATCH 12/15] arm-soc: omap: replace open coded VA->PA calculations

On 9 August 2017 at 20:05, Tony Lindgren <t...@atomide.com> wrote: > * Ard Biesheuvel <ard.biesheu...@linaro.org> [170805 13:54]: >> This replaces a couple of open coded calculations to obtain the >> physical address of a far symbol with calls to the new adr_l etc >&g

Re: [PATCH 01/15] ARM: assembler: introduce adr_l, ldr_l and str_l macros

On 8 August 2017 at 16:10, Nicolas Pitre <nicolas.pi...@linaro.org> wrote: > On Sat, 5 Aug 2017, Ard Biesheuvel wrote: > >> Like arm64, ARM supports position independent code sequences that >> produce symbol references with a greater reach than the ordinary >> adr/ldr

Re: [PATCH 11/27] arm64/sve: Core task context handling

On 17 August 2017 at 17:42, Dave Martin <dave.mar...@arm.com> wrote: > On Tue, Aug 15, 2017 at 06:31:05PM +0100, Ard Biesheuvel wrote: >> Hi Dave, >> >> On 9 August 2017 at 13:05, Dave Martin <dave.mar...@arm.com> wrote: >> > This patch adds the core

Re: [PATCH 1/5] arm64: KVM: Do not use stack-protector to compile EL2 code

On 11 May 2017 at 17:42, Marc Zyngier <marc.zyng...@arm.com> wrote: > On 11/05/17 17:36, Ard Biesheuvel wrote: >> On 11 May 2017 at 17:11, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: >>> On 11 May 2017 at 17:02, Marc Zyngier <marc.zyng...@arm.com> wrote:

Re: [PATCH 1/5] arm64: KVM: Do not use stack-protector to compile EL2 code

On 11 May 2017 at 17:02, Marc Zyngier wrote: > On 02/05/17 15:50, Marc Zyngier wrote: >> On 02/05/17 15:40, Catalin Marinas wrote: >>> On Tue, May 02, 2017 at 02:30:37PM +0100, Marc Zyngier wrote: We like living dangerously. Nothing explicitely forbids stack-protector

Re: [PATCH 1/5] arm64: KVM: Do not use stack-protector to compile EL2 code

On 11 May 2017 at 17:11, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 11 May 2017 at 17:02, Marc Zyngier <marc.zyng...@arm.com> wrote: >> On 02/05/17 15:50, Marc Zyngier wrote: >>> On 02/05/17 15:40, Catalin Marinas wrote: >>>> On Tue, May 02, 20

Re: [PATCH V17 08/11] efi: print unrecognized CPER section

y: Tyler Baicar <tbai...@codeaurora.org> > CC: Jonathan (Zhixiong) Zhang <zjzh...@codeaurora.org> > Reviewed-by: James Morse <james.mo...@arm.com> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > --- > drivers/firmware/efi/cper.c | 11 +-- >

Re: [PATCH V17 02/11] ras: acpi/apei: cper: add support for generic data v3 structure

arm64, but I need an ack from Ard or Matt on the EFI changes > in this patch and the subsequent one. > Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org> ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH V17 03/11] cper: add timestamp print to CPER status printing

rora.org> > CC: Jonathan (Zhixiong) Zhang <zjzh...@codeaurora.org> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > --- > drivers/firmware/efi/cper.c | 26 ++ > 1 file changed, 26 insertions(+) > > diff --git a/drivers/firmware/efi/cper

Re: [PATCH 1/5] arm64: KVM: Do not use stack-protector to compile EL2 code

On 2 May 2017 at 15:40, Catalin Marinas wrote: > On Tue, May 02, 2017 at 02:30:37PM +0100, Marc Zyngier wrote: >> We like living dangerously. Nothing explicitely forbids stack-protector >> to be used in the EL2 code, while distributions routinely compile their >> kernel

Re: [RFC 00/11] KVM, EFI, arm64: EFI Runtime Services Sandboxing

On 25 August 2017 at 01:31, Florent Revest wrote: > Hi, > > This series implements a mechanism to sandbox EFI Runtime Services on arm64. > It can be enabled with CONFIG_EFI_SANDBOX. At boot it spawns an internal KVM > virtual machine that is ran everytime an EFI Runtime

[PATCH] kvm: arm: don't treat unavailable HYP mode as an error

'quiet' console. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- virt/kvm/arm/arm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c index 772bf74ac2e9..988c888a9667 100644 --- a/virt/kvm/arm/arm.c +++ b/virt/kvm/arm

Re: [PATCH 07/12] arm64: mm: Place kImage at bottom of VA space

On 4 December 2017 at 17:18, Steve Capper <steve.cap...@arm.com> wrote: > Hi Ard, > > On Mon, Dec 04, 2017 at 04:25:18PM +, Ard Biesheuvel wrote: >> On 4 December 2017 at 14:13, Steve Capper <steve.cap...@arm.com> wrote: >> > Re-arrange the kernel memo

Re: [PATCH 07/12] arm64: mm: Place kImage at bottom of VA space

On 4 December 2017 at 14:13, Steve Capper wrote: > Re-arrange the kernel memory map s.t. the kernel image resides in the > bottom 514MB of memory. I guess this breaks KASLR entirely, no? Given that it adds an offset in the range [0 ... sizeof(VMALLOC_SPACE) /4 ]. In any

Re: [PATCH] KVM: arm/arm64: drop resource size check for GICV window

> On 9 Jun 2018, at 12:06, Christoffer Dall wrote: > >> On Fri, Jun 01, 2018 at 05:06:28PM +0200, Ard Biesheuvel wrote: >> When booting a 64 KB pages kernel on a ACPI GICv3 system that >> implements support for v2 emulation, the following warning is >> pro

[PATCH] KVM: arm/arm64: drop resource size check for GICV window

_init: implement kvm_vgic_hyp_init") Signed-off-by: Ard Biesheuvel --- virt/kvm/arm/vgic/vgic-v3.c | 5 - 1 file changed, 5 deletions(-) diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c index bdcf8e7a6161..72fc688c3e9d 100644 --- a/virt/kvm/arm/vgic/vgic-v3.c +++ b/virt/kv

Re: [PATCH v2 2/2] arm64: Implement branch predictor hardening for Falkor

On 8 January 2018 at 21:31, Shanker Donthineni wrote: > Falkor is susceptible to branch predictor aliasing and can > theoretically be attacked by malicious code. This patch > implements a mitigation for these attacks, preventing any > malicious entries from affecting

Re: [PATCH v2 15/16] arm/arm64: smccc: Implement SMCCC v1.1 inline primitive

On 29 January 2018 at 17:45, Marc Zyngier wrote: > One of the major improvement of SMCCC v1.1 is that it only clobbers > the first 4 registers, both on 32 and 64bit. This means that it > becomes very easy to provide an inline version of the SMC call > primitive, and avoid

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 29 January 2018 at 17:45, Marc Zyngier wrote: > Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1. > It is lovely. Really. > > Signed-off-by: Marc Zyngier > --- > arch/arm64/include/asm/kvm_psci.h | 63

Re: [PATCH v2 15/16] arm/arm64: smccc: Implement SMCCC v1.1 inline primitive

On 30 January 2018 at 12:27, Marc Zyngier <marc.zyng...@arm.com> wrote: > On 29/01/18 21:45, Ard Biesheuvel wrote: >> On 29 January 2018 at 17:45, Marc Zyngier <marc.zyng...@arm.com> wrote: >>> One of the major improvement of SMCCC v1.1 is that it only clobbers &

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 31 January 2018 at 14:11, Marc Zyngier wrote: > On 31/01/18 13:56, Hanjun Guo wrote: >> Hi Marc, >> >> On 2018/1/30 1:45, Marc Zyngier wrote: >>> static int enable_psci_bp_hardening(void *data) >>> { >>> const struct arm64_cpu_capabilities *entry = data; >>> >>> -

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 31 January 2018 at 14:35, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 31 January 2018 at 14:11, Marc Zyngier <marc.zyng...@arm.com> wrote: >> On 31/01/18 13:56, Hanjun Guo wrote: >>> Hi Marc, >>> >>> On 2018/1/30 1:45, Marc Zyngier

Re: [PATCH v3 15/18] arm/arm64: smccc: Make function identifiers an unsigned quantity

issue, but the argument, which, for SMCCC_ARCH_FEATURES is also defined as uint32_t, but did end up being interpreted incorrectly by the SMCCCv1.1 implementation that is now upstream in ARM-TF > >> Cc: sta...@vger.kernel.org >> Reported-by: Ard Biesheuvel <ard.biesheu...@linar

Re: [PATCH v3 00/18] arm64: Add SMCCC v1.1 support and CVE-2017-5715 (Spectre variant 2) mitigation

smccc: Implement SMCCC v1.1 inline primitive > arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support > arm64: Kill PSCI_GET_VERSION as a variant-2 workaround > I have given this a spin on my Overdrive, and everything seems to work as

Re: [PATCH 14/14] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 26 January 2018 at 14:28, Marc Zyngier wrote: > Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1. > It is lovely. Really. > > Signed-off-by: Marc Zyngier > --- > arch/arm64/kernel/bpi.S| 20 >

Re: [PATCH 14/14] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 29 January 2018 at 10:07, Marc Zyngier <marc.zyng...@arm.com> wrote: > On 29/01/18 09:42, Ard Biesheuvel wrote: >> On 29 January 2018 at 09:36, Marc Zyngier <marc.zyng...@arm.com> wrote: >>> On 28/01/18 23:08, Ard Biesheuvel wrote: >>>> On 26 Janu

Re: [PATCH 13/14] firmware/psci: Expose SMCCC version through psci_ops

On 26 January 2018 at 14:28, Marc Zyngier wrote: > Since PSCI 1.0 allows the SMCCC version to be (indirectly) probed, > let's do that at boot time, and expose the version of the calling > convention as part of the psci_ops structure. > > Signed-off-by: Marc Zyngier

Re: [PATCH 12/14] firmware/psci: Expose PSCI conduit

On 26 January 2018 at 14:28, Marc Zyngier wrote: > In order to call into the firmware to apply workarounds, it is > useful to find out whether we're using HVC or SMC. Let's expose > this through the psci_ops. > > Signed-off-by: Marc Zyngier > --- >

Re: [PATCH 14/14] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 29 January 2018 at 09:36, Marc Zyngier <marc.zyng...@arm.com> wrote: > On 28/01/18 23:08, Ard Biesheuvel wrote: >> On 26 January 2018 at 14:28, Marc Zyngier <marc.zyng...@arm.com> wrote: >>> Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROU

Re: [PATCH v3 14/18] firmware/psci: Expose SMCCC version through psci_ops

On 1 February 2018 at 11:46, Marc Zyngier wrote: > Since PSCI 1.0 allows the SMCCC version to be (indirectly) probed, > let's do that at boot time, and expose the version of the calling > convention as part of the psci_ops structure. > > Acked-by: Lorenzo Pieralisi

Re: [PATCH v3 09/41] KVM: arm64: Defer restoring host VFP state to vcpu_put

On 14 February 2018 at 17:38, Christoffer Dall wrote: > On Wed, Feb 14, 2018 at 02:43:42PM +, Dave Martin wrote: >> [CC Ard, in case he has a view on how much we care about softirq NEON >> performance regressions ... and whether my suggestions make sense] >> >> On

Re: Clang arm64 build is broken

On 20 April 2018 at 17:38, Mark Rutland wrote: > Hi Andrey, > > On Fri, Apr 20, 2018 at 04:59:35PM +0200, Andrey Konovalov wrote: >> On Fri, Apr 20, 2018 at 10:13 AM, Marc Zyngier wrote: >> >> The issue is that >> >> clang doesn't know about the "S"

Re: arm64 kvm built with clang doesn't boot

(+ Thomas) On 16 March 2018 at 17:13, Mark Rutland wrote: > On Fri, Mar 16, 2018 at 04:52:08PM +, Nick Desaulniers wrote: >> + Sami (Google), Takahiro (Linaro) >> >> Just so I fully understand the problem enough to articulate it, we'd be >> looking for the compiler to

Re: [PATCH v6 06/26] KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state

On 16 March 2018 at 11:35, Andrew Jones wrote: > On Fri, Mar 16, 2018 at 09:31:57AM +, Marc Zyngier wrote: >> On 15/03/18 19:16, James Morse wrote: >> > >> > (I had a go at using 'Ush', to let the compiler schedule the adrp, but >> > couldn't >> > get it to work.) >> >> I

Re: kvm-unit-tests gicv2 cases fail

On 19 October 2018 at 11:25, Andrew Jones wrote: > On Thu, Oct 18, 2018 at 05:17:57PM +0800, Li Zhang wrote: >> Hi, >> >> I run kvm-units-test on ARM server(QDF2400), but gicv2-ipi, >> gicv2-active cases fail. >> By debuging kvm-unit-tests source code, I found that interrupt is not >> handled.

[PATCH v2 0/2] arm64: kvm: cache ID register trapping

, and it disabled otherwise - add Christoffer's ack Cc: suzuki.poul...@arm.com Cc: marc.zyng...@arm.com Cc: christoffer.d...@arm.com Ard Biesheuvel (2): arm64: kvm: expose sanitised cache type register to guest arm64: kvm: describe data or unified caches as having 1 set and 1 way arch/arm64/include/asm

[PATCH v2 2/2] arm64: kvm: describe data or unified caches as having 1 set and 1 way

system software (i.e., the kind that only receives odd fixes) doesn't take a performance hit due to the trapping when iterating over the cachelines. Acked-by: Christoffer Dall Signed-off-by: Ard Biesheuvel --- arch/arm64/include/asm/kvm_emulate.h | 3 ++- arch/arm64/kvm/sys_regs.c| 15

[PATCH v2 1/2] arm64: kvm: expose sanitised cache type register to guest

, so update that part as well. Acked-by: Christoffer Dall Signed-off-by: Ard Biesheuvel --- arch/arm64/include/asm/kvm_emulate.h | 3 + arch/arm64/include/asm/sysreg.h | 1 + arch/arm64/kvm/sys_regs.c| 59 +++- 3 files changed, 61 insertions(+), 2 deletions

Re: Memory regions and VMAs across architectures

On 11/8/19 12:19 PM, Christoffer Dall wrote: > Hi, > > I had a look at our relatively complicated logic in > kvm_arch_prepare_memory_region(), and was wondering if there was room to > unify some of this handling between architectures. > > (If you haven't seen our implementation, you can find it in

Re: [PATCH 12/18] arm64: kernel: Convert to modern annotations for assembly functions

Hi Mark, On Tue, 18 Feb 2020 at 21:02, Mark Brown wrote: > > In an effort to clarify and simplify the annotation of assembly functions > in the kernel new macros have been introduced. These replace ENTRY and > ENDPROC and also add a new annotation for static functions which previously > had no

Re: [PATCH 0/3] KVM: arm64: Ask the compiler to __always_inline functions used by KVM at HYP

On Thu, 20 Feb 2020 at 17:58, James Morse wrote: > > Hello! > > It turns out KVM relies on the inline hint being honoured by the compiler > in quite a few more places than expected. Something about the Shadow Call > Stack support[0] causes the compiler to avoid inline-ing and to place > these

Re: [PATCH 0/3] KVM: arm64: Ask the compiler to __always_inline functions used by KVM at HYP

On Thu, 20 Feb 2020 at 18:33, James Morse wrote: > > Hi Ard, > > On 20/02/2020 17:04, Ard Biesheuvel wrote: > > On Thu, 20 Feb 2020 at 17:58, James Morse wrote: > >> It turns out KVM relies on the inline hint being honoured by the compiler > >> in quite a few

Re: [PATCH 3/3] arm64: Ask the compiler to __always_inline functions used by KVM at HYP

On Fri, 21 Feb 2020 at 14:13, Will Deacon wrote: > > On Thu, Feb 20, 2020 at 04:58:39PM +, James Morse wrote: > > KVM uses some of the static-inline helpers like icache_is_vipt() from > > its HYP code. This assumes the function is inlined so that the code is > > mapped to EL2. The compiler

Re: [PATCH v7 7/7] ARM: Enable KASan for ARM

(+ Linus) On Fri, 10 Apr 2020 at 12:45, Ard Biesheuvel wrote: > > On Fri, 17 Jan 2020 at 23:52, Florian Fainelli wrote: > > > > From: Andrey Ryabinin > > > > This patch enables the kernel address sanitizer for ARM. XIP_KERNEL has > > not been tested and is

Re: [PATCH v7 7/7] ARM: Enable KASan for ARM

On Fri, 17 Jan 2020 at 23:52, Florian Fainelli wrote: > > From: Andrey Ryabinin > > This patch enables the kernel address sanitizer for ARM. XIP_KERNEL has > not been tested and is therefore not allowed. > > Acked-by: Dmitry Vyukov > Tested-by: Linus Walleij > Signed-off-by: Abbott Liu >

Re: [PATCH kvmtool v4 0/5] Add CFI flash emulation

On Thu, 23 Apr 2020 at 19:55, Ard Biesheuvel wrote: > > On Thu, 23 Apr 2020 at 19:39, Andre Przywara wrote: > > > > Hi, > > > > an update for the CFI flash emulation, addressing Alex' comments and > > adding direct mapping support. > > The actual code

Re: [PATCH kvmtool v4 0/5] Add CFI flash emulation

On Thu, 23 Apr 2020 at 23:32, André Przywara wrote: > > On 23/04/2020 21:43, Ard Biesheuvel wrote: > > Hi Ard, > > > On Thu, 23 Apr 2020 at 19:55, Ard Biesheuvel wrote: > >> > >> On Thu, 23 Apr 2020 at 19:39, Andre Przywara > >> wrote: > &g

Re: [PATCH kvmtool v4 0/5] Add CFI flash emulation

On Fri, 24 Apr 2020 at 14:08, André Przywara wrote: > > On 24/04/2020 07:45, Ard Biesheuvel wrote: > > Hi, > > (adding Leif for EDK-2 discussion) > > > On Thu, 23 Apr 2020 at 23:32, André Przywara wrote: > >> > >> On 23/04/2020 21:43, Ard Biesheuv

Re: [PATCH kvmtool v4 0/5] Add CFI flash emulation

On Fri, 24 Apr 2020 at 19:03, Will Deacon wrote: > > On Fri, Apr 24, 2020 at 09:40:51AM +0100, Will Deacon wrote: > > On Thu, Apr 23, 2020 at 06:38:39PM +0100, Andre Przywara wrote: > > > an update for the CFI flash emulation, addressing Alex' comments and > > > adding direct mapping support. > >

Re: [PATCH kvmtool v4 0/5] Add CFI flash emulation

On Thu, 23 Apr 2020 at 19:39, Andre Przywara wrote: > > Hi, > > an update for the CFI flash emulation, addressing Alex' comments and > adding direct mapping support. > The actual code changes to the flash emulation are minimal, mostly this > is about renaming and cleanups. > This versions now

Re: [PATCH kvmtool v3] Add emulation for CFI compatible flash memory

On Wed, 15 Apr 2020 at 18:11, André Przywara wrote: > > On 15/04/2020 16:55, Ard Biesheuvel wrote: > > On Wed, 15 Apr 2020 at 17:43, Ard Biesheuvel wrote: > >> > >> On Tue, 7 Apr 2020 at 17:15, Alexandru Elisei > >> wrote: > >>> > >>&

Re: [PATCH kvmtool v3] Add emulation for CFI compatible flash memory

On Wed, 15 Apr 2020 at 17:43, Ard Biesheuvel wrote: > > On Tue, 7 Apr 2020 at 17:15, Alexandru Elisei > wrote: > > > > Hi, > > > > I've tested this patch by running badblocks and fio on a flash device > > inside a > > guest, everything

Re: [PATCH kvmtool v3] Add emulation for CFI compatible flash memory

On Tue, 7 Apr 2020 at 17:15, Alexandru Elisei wrote: > > Hi, > > I've tested this patch by running badblocks and fio on a flash device inside a > guest, everything worked as expected. > > I've also looked at the flowcharts for device operation from Intel Application > Note 646, pages 12-21, and

Re: [PATCH kvmtool v3] Add emulation for CFI compatible flash memory

On Wed, 15 Apr 2020 at 18:36, André Przywara wrote: > > On 15/04/2020 17:20, Ard Biesheuvel wrote: > > On Wed, 15 Apr 2020 at 18:11, André Przywara wrote: > >> > >> On 15/04/2020 16:55, Ard Biesheuvel wrote: > >>> On Wed, 15 Apr 2020 at 17:43, Ard Bies

[PATCH] KVM: arm64: implement the TRNG hypervisor call

: Suzuki K Poulose Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Cc: Lorenzo Pieralisi Cc: Sudeep Holla Cc: Sami Mujawar Cc: Andre Przywara Cc: Alexandru Elisei Cc: Laszlo Ersek Cc: Leif Lindholm Signed-off-by: Ard Biesheuvel --- arch/arm64/include/asm/kvm_host.h | 2 + arch/arm64/kvm

Re: [PATCH] KVM: arm64: implement the TRNG hypervisor call

On Sat, 3 Oct 2020 at 12:30, Andrew Jones wrote: > > Hi Ard, > Hi Drew, Thanks for taking a look. > On Sat, Oct 03, 2020 at 10:56:04AM +0200, Ard Biesheuvel wrote: > > Provide a hypervisor implementation of the ARM architected TRNG firmware > > interface described

Re: [RFC PATCH v1 0/3] put arm64 kvm_config on a diet

On Tue, 4 Aug 2020 at 14:45, Alex Bennée wrote: > > Hi, > > When building guest kernels for virtualisation we were bringing in a > bunch of stuff from physical hardware which we don't need for our > idealised fixable virtual PCI devices. This series makes some Kconfig > changes to allow the

Re: [PATCH v3 08/15] arm64: kvm: Split hyp/switch.c to VHE/nVHE

On Thu, 25 Jun 2020 at 10:16, Marc Zyngier wrote: > > On 2020-06-25 06:03, kernel test robot wrote: > > Hi David, > > > > Thank you for the patch! Perhaps something to improve: > > > > [auto build test WARNING on linus/master] > > [also build test WARNING on v5.8-rc2 next-20200624] > > [cannot

Re: [PATCH] arm64: Work around broken GCC handling of "S" constraint

On Mon, 7 Dec 2020 at 16:43, Marc Zyngier wrote: > > GCC 4.9 seems to have a problem with the "S" asm constraint > when the symbol lives in the same compilation unit, and pretends > the constraint is impossible: > > $ cat x.c > void *foo(void) > { > static int x; > int *addr; >

Re: [PATCH] arm64: Work around broken GCC handling of "S" constraint

(resend with David's email address fixed) On Mon, 7 Dec 2020 at 18:17, Ard Biesheuvel wrote: > > On Mon, 7 Dec 2020 at 16:43, Marc Zyngier wrote: > > > > GCC 4.9 seems to have a problem with the "S" asm constraint > > when the symbol lives in the s

Re: [PATCH] arm64: Work around broken GCC handling of "S" constraint

On Mon, 7 Dec 2020 at 18:41, Marc Zyngier wrote: > > On 2020-12-07 17:19, Ard Biesheuvel wrote: > > (resend with David's email address fixed) > > Irk. Thanks for that. > > >> > +#ifdef CONFIG_CC_HAS_BROKEN_S_CONSTRAINT > >> > +#define SYM

Re: [RFC PATCH 1/6] kvm: arm64: Set up .hyp.rodata ELF section

On Thu, 19 Nov 2020 at 17:25, David Brazdil wrote: > > We will need to recognize pointers in .rodata specific to hyp, Why? > so > establish a .hyp.rodata ELF section. Merge it with the existing > .hyp.data..ro_after_init as they are treated the same at runtime. > Does this mean HYP .text,

Re: [RFC PATCH 2/6] kvm: arm64: Fix up RELA relocations in hyp code/data

On Thu, 19 Nov 2020 at 17:25, David Brazdil wrote: > > KVM nVHE code runs under a different VA mapping than the kernel, hence > so far it relied only on PC-relative addressing to avoid accidentally > using a relocated kernel VA from a constant pool (see hyp_symbol_addr). > > So as to reduce the

Re: [RFC PATCH 3/6] kvm: arm64: Fix up RELR relocation in hyp code/data

On Thu, 19 Nov 2020 at 17:25, David Brazdil wrote: > > The arm64 kernel also supports packing of relocation data using the RELR > format. Implement a parser of RELR data and fixup the relocations using > the same infra as RELA relocs. > > Signed-off-by: David Brazdil > --- >

Re: [RFC PATCH 4/6] kvm: arm64: Remove patching of fn pointers in hyp

On Thu, 19 Nov 2020 at 17:25, David Brazdil wrote: > > Taking a function pointer will now generate a R_AARCH64_RELATIVE that is > fixed up at early boot. Remove the alternative-based mechanism for > converting the address from a kernel VA. > > Signed-off-by: David Brazd

Re: [RFC PATCH 5/6] kvm: arm64: Fix constant-pool users in hyp

On Thu, 19 Nov 2020 at 17:26, David Brazdil wrote: > > Hyp code used to use absolute addressing via a constant pool to obtain > the kernel VA of 3 symbols - panic, __hyp_panic_string and > __kvm_handle_stub_hvc. This used to work because the kernel would > relocate the addresses in the constant

Re: [RFC PATCH 6/6] kvm: arm64: Remove hyp_symbol_addr

ver they wanted to take a pointer. > > Now that hyp relocations are fixed up, there is no need for the helper > any logner. Remove it. > > Signed-off-by: David Brazdil Acked-by: Ard Biesheuvel > --- > arch/arm64/include/asm/kvm_asm.h | 20 >

Re: [PATCH] arm64: Work around broken GCC 4.9 handling of "S" constraint

rsion prior to 5.0, > which *seems* to do the right thing. Hopefully we will be able to > remove this at some point, but in the meantime this gets us going. > > Signed-off-by: Marc Zyngier Acked-by: Ard Biesheuvel > --- > * From v1: Dropped the detection hack and rely on GCC_VERSION >

Re: [PATCH v3 0/5] ARM: arm64: Add SMCCC TRNG entropy service

M initialisation from the SMCCC firmware driver > - use a single bool in smccc.c to hold the initialisation state for arm64 > - handle endianess correctly in the KVM provider > > Andre Przywara (2): > firmware: smccc: Introduce SMCCC TRNG framework > arm64: Add support for SMCC

Re: [PATCH v3 4/5] arm64: Add support for SMCCC TRNG entropy source

On Fri, 20 Nov 2020 at 11:52, André Przywara wrote: > > On 19/11/2020 13:41, Ard Biesheuvel wrote: > > Hi, > > > On Fri, 13 Nov 2020 at 19:24, Andre Przywara wrote: > >> > >> The ARM architected TRNG firmware interface, described in ARM spec > >&g

Re: [PATCH v3 4/5] arm64: Add support for SMCCC TRNG entropy source

On Fri, 13 Nov 2020 at 19:24, Andre Przywara wrote: > > The ARM architected TRNG firmware interface, described in ARM spec > DEN0098, defines an ARM SMCCC based interface to a true random number > generator, provided by firmware. > This can be discovered via the SMCCC >=v1.1 interface, and

Re: [PATCH v2 4/5] arm64: Add support for SMCCC TRNG entropy source

On Thu, 5 Nov 2020 at 15:03, Mark Rutland wrote: > > On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote: > > On Thu, Nov 05, 2020 at 12:56:55PM +, Andre Przywara wrote: > > > > > static inline bool __must_check arch_get_random_seed_int(unsigned int *v) > > > { > > > + struct

Re: [PATCH v2 4/5] arm64: Add support for SMCCC TRNG entropy source

On Thu, 5 Nov 2020 at 15:30, Mark Rutland wrote: > > On Thu, Nov 05, 2020 at 03:04:57PM +0100, Ard Biesheuvel wrote: > > On Thu, 5 Nov 2020 at 15:03, Mark Rutland wrote: > > > On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote: > > > > On Thu, Nov 05

Re: [PATCH v2 5/5] KVM: arm64: implement the TRNG hypervisor call

On Thu, 5 Nov 2020 at 15:13, Marc Zyngier wrote: > > On 2020-11-05 12:56, Andre Przywara wrote: > > From: Ard Biesheuvel > > > > Provide a hypervisor implementation of the ARM architected TRNG > > firmware > > interface described in ARM spec DEN0098.

Re: [PATCH v2 3/5] ARM: implement support for SMCCC TRNG entropy source

On Fri, 6 Nov 2020 at 16:30, Marc Zyngier wrote: > > On 2020-11-05 12:56, Andre Przywara wrote: > > From: Ard Biesheuvel > > > > Implement arch_get_random_seed_*() for ARM based on the firmware > > or hypervisor provided entropy source described in ARM D

Re: [PATCH 2/2] KVM: arm64: Workaround firmware wrongly advertising GICv2-on-v3 compatibility

On Fri, 8 Jan 2021 at 19:13, Marc Zyngier wrote: > > On 2021-01-08 17:59, Ard Biesheuvel wrote: > > On Fri, 8 Jan 2021 at 18:12, Marc Zyngier wrote: > >> > >> It looks like we have broken firmware out there that wrongly > >> advertises > >> a

Re: [PATCH 2/2] KVM: arm64: Workaround firmware wrongly advertising GICv2-on-v3 compatibility

On Fri, 8 Jan 2021 at 18:12, Marc Zyngier wrote: > > It looks like we have broken firmware out there that wrongly advertises > a GICv2 compatibility interface, despite the CPUs not being able to deal > with it. > > To work around this, check that the CPU initialising KVM is actually able > to

<    1   2   3   >