From: James Morse <james.morse@arm.com> To: Marc Zyngier <marc.zyngier@arm.com>, kvmarm@lists.cs.columbia.edu Cc: Mark Rutland <mark.rutland@arm.com>, Peter Maydell <peter.maydell@linaro.org>, Andrew Jones <drjones@redhat.com>, Christoffer Dall <cdall@kernel.org>, kvm@vger.kernel.org, Steve Capper <steve.capper@arm.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, Kristina Martsenko <kristina.martsenko@arm.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v6 06/26] KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state Date: Thu, 15 Mar 2018 19:16:14 +0000 [thread overview] Message-ID: <5AAAC67E.4010002@arm.com> (raw) In-Reply-To: <20180314165049.30105-7-marc.zyngier@arm.com> Hi Marc, On 14/03/18 16:50, Marc Zyngier wrote: > kvm_vgic_global_state is part of the read-only section, and is > usually accessed using a PC-relative address generation (adrp + add). > > It is thus useless to use kern_hyp_va() on it, and actively problematic > if kern_hyp_va() becomes non-idempotent. On the other hand, there is > no way that the compiler is going to guarantee that such access is > always PC relative. > > So let's bite the bullet and provide our own accessor. > diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h > index de1b919404e4..a6808d2869f5 100644 > --- a/arch/arm/include/asm/kvm_mmu.h > +++ b/arch/arm/include/asm/kvm_mmu.h > @@ -28,6 +28,13 @@ > */ > #define kern_hyp_va(kva) (kva) > > +/* Resolving symbol addresses in a PC-relative way is easy... */ (So this is guaranteed on 32bit? I thought this was because 32bit uses the kernel-VA's at HYP, so any way the compiler generates the address will work.) > +#define hyp_symbol_addr(s) \ > + ({ \ > + typeof(s) *addr = &(s); \ > + addr; \ > + }) > + > /* > * KVM_MMU_CACHE_MIN_PAGES is the number of stage2 page table translation levels. > */ > diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h > index e3bc1d0a5e93..7120bf3f22c7 100644 > --- a/arch/arm64/include/asm/kvm_mmu.h > +++ b/arch/arm64/include/asm/kvm_mmu.h > @@ -110,6 +110,26 @@ static inline unsigned long __kern_hyp_va(unsigned long v) > > #define kern_hyp_va(v) ((typeof(v))(__kern_hyp_va((unsigned long)(v)))) > > +/* > + * Obtain the PC-relative address of a kernel symbol > + * s: symbol > + * > + * The goal of this macro is to return a symbol's address based on a > + * PC-relative computation, as opposed to a loading the VA from a > + * constant pool or something similar. This works well for HYP, as an > + * absolute VA is guaranteed to be wrong. Only use this if trying to > + * obtain the address of a symbol (i.e. not something you obtained by > + * following a pointer). > + */ > +#define hyp_symbol_addr(s) \ > + ({ \ > + typeof(s) *addr; \ > + asm volatile("adrp %0, %1\n" \ > + "add %0, %0, :lo12:%1\n" \ > + : "=r" (addr) : "S" (&s)); \ > + addr; \ > + }) Why does this need to be volatile? I see gcc v4.9 generate this sequence twice in __vgic_v2_save_state(). Can't it cache and reorder this sequence as it likes? Either-way: Reviewed-by: James Morse <james.morse@arm.com> (I had a go at using 'Ush', to let the compiler schedule the adrp, but couldn't get it to work.) Thanks, James
WARNING: multiple messages have this Message-ID (diff)
From: james.morse@arm.com (James Morse) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v6 06/26] KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state Date: Thu, 15 Mar 2018 19:16:14 +0000 [thread overview] Message-ID: <5AAAC67E.4010002@arm.com> (raw) In-Reply-To: <20180314165049.30105-7-marc.zyngier@arm.com> Hi Marc, On 14/03/18 16:50, Marc Zyngier wrote: > kvm_vgic_global_state is part of the read-only section, and is > usually accessed using a PC-relative address generation (adrp + add). > > It is thus useless to use kern_hyp_va() on it, and actively problematic > if kern_hyp_va() becomes non-idempotent. On the other hand, there is > no way that the compiler is going to guarantee that such access is > always PC relative. > > So let's bite the bullet and provide our own accessor. > diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h > index de1b919404e4..a6808d2869f5 100644 > --- a/arch/arm/include/asm/kvm_mmu.h > +++ b/arch/arm/include/asm/kvm_mmu.h > @@ -28,6 +28,13 @@ > */ > #define kern_hyp_va(kva) (kva) > > +/* Resolving symbol addresses in a PC-relative way is easy... */ (So this is guaranteed on 32bit? I thought this was because 32bit uses the kernel-VA's at HYP, so any way the compiler generates the address will work.) > +#define hyp_symbol_addr(s) \ > + ({ \ > + typeof(s) *addr = &(s); \ > + addr; \ > + }) > + > /* > * KVM_MMU_CACHE_MIN_PAGES is the number of stage2 page table translation levels. > */ > diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h > index e3bc1d0a5e93..7120bf3f22c7 100644 > --- a/arch/arm64/include/asm/kvm_mmu.h > +++ b/arch/arm64/include/asm/kvm_mmu.h > @@ -110,6 +110,26 @@ static inline unsigned long __kern_hyp_va(unsigned long v) > > #define kern_hyp_va(v) ((typeof(v))(__kern_hyp_va((unsigned long)(v)))) > > +/* > + * Obtain the PC-relative address of a kernel symbol > + * s: symbol > + * > + * The goal of this macro is to return a symbol's address based on a > + * PC-relative computation, as opposed to a loading the VA from a > + * constant pool or something similar. This works well for HYP, as an > + * absolute VA is guaranteed to be wrong. Only use this if trying to > + * obtain the address of a symbol (i.e. not something you obtained by > + * following a pointer). > + */ > +#define hyp_symbol_addr(s) \ > + ({ \ > + typeof(s) *addr; \ > + asm volatile("adrp %0, %1\n" \ > + "add %0, %0, :lo12:%1\n" \ > + : "=r" (addr) : "S" (&s)); \ > + addr; \ > + }) Why does this need to be volatile? I see gcc v4.9 generate this sequence twice in __vgic_v2_save_state(). Can't it cache and reorder this sequence as it likes? Either-way: Reviewed-by: James Morse <james.morse@arm.com> (I had a go at using 'Ush', to let the compiler schedule the adrp, but couldn't get it to work.) Thanks, James
next prev parent reply other threads:[~2018-03-15 19:16 UTC|newest] Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-14 16:50 [PATCH v6 00/26] KVM/arm64: Randomise EL2 mappings (variant 3a mitigation) Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 01/26] arm64: alternatives: Add dynamic patching feature Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 02/26] arm64: insn: Add N immediate encoding Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 03/26] arm64: insn: Add encoder for bitwise operations using literals Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 04/26] arm64: KVM: Dynamically patch the kernel/hyp VA mask Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-15 19:15 ` James Morse 2018-03-15 19:15 ` James Morse 2018-03-16 8:52 ` Marc Zyngier 2018-03-16 8:52 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 05/26] arm64: cpufeatures: Drop the ARM64_HYP_OFFSET_LOW feature flag Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 06/26] KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-15 19:16 ` James Morse [this message] 2018-03-15 19:16 ` James Morse 2018-03-16 9:31 ` Marc Zyngier 2018-03-16 9:31 ` Marc Zyngier 2018-03-16 11:35 ` Andrew Jones 2018-03-16 11:35 ` Andrew Jones 2018-03-16 11:38 ` Ard Biesheuvel 2018-03-16 11:38 ` Ard Biesheuvel 2018-03-16 11:51 ` Marc Zyngier 2018-03-16 11:51 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 07/26] KVM: arm/arm64: Demote HYP VA range display to being a debug feature Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 08/26] KVM: arm/arm64: Move ioremap calls to create_hyp_io_mappings Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 09/26] KVM: arm/arm64: Keep GICv2 HYP VAs in kvm_vgic_global_state Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 10/26] KVM: arm/arm64: Fix idmap size and alignment Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-15 19:15 ` James Morse 2018-03-15 19:15 ` James Morse 2018-03-16 8:55 ` Marc Zyngier 2018-03-16 8:55 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 11/26] KVM: arm64: Fix HYP idmap unmap when using 52bit PA Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-16 16:07 ` Catalin Marinas 2018-03-16 16:07 ` Catalin Marinas 2018-03-16 16:47 ` Suzuki K Poulose 2018-03-16 16:47 ` Suzuki K Poulose 2018-03-14 16:50 ` [PATCH v6 12/26] KVM: arm/arm64: Move HYP IO VAs to the "idmap" range Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-15 19:09 ` James Morse 2018-03-15 19:09 ` James Morse 2018-03-16 8:44 ` Marc Zyngier 2018-03-16 8:44 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 13/26] arm64; insn: Add encoder for the EXTR instruction Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 14/26] arm64: insn: Allow ADD/SUB (immediate) with LSL #12 Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 15/26] arm64: KVM: Dynamically compute the HYP VA mask Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 16/26] arm64: KVM: Introduce EL2 VA randomisation Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 17/26] arm64: Update the KVM memory map documentation Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 18/26] arm64: KVM: Move vector offsetting from hyp-init.S to kvm_get_hyp_vector Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 19/26] arm64: KVM: Move stashing of x0/x1 into the vector code itself Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-15 14:39 ` Andrew Jones 2018-03-15 14:39 ` Andrew Jones 2018-03-16 16:22 ` Catalin Marinas 2018-03-16 16:22 ` Catalin Marinas 2018-03-16 16:37 ` Marc Zyngier 2018-03-16 16:37 ` Marc Zyngier 2018-03-16 16:38 ` Marc Zyngier 2018-03-16 16:38 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 20/26] arm64: KVM: Move BP hardening vectors into .hyp.text section Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-15 14:42 ` Andrew Jones 2018-03-15 14:42 ` Andrew Jones 2018-03-16 16:24 ` Catalin Marinas 2018-03-16 16:24 ` Catalin Marinas 2018-03-14 16:50 ` [PATCH v6 21/26] arm64: KVM: Reserve 4 additional instructions in the BPI template Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-15 14:46 ` Andrew Jones 2018-03-15 14:46 ` Andrew Jones 2018-03-16 16:30 ` Catalin Marinas 2018-03-16 16:30 ` Catalin Marinas 2018-03-14 16:50 ` [PATCH v6 22/26] arm64: KVM: Allow far branches from vector slots to the main vectors Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 23/26] arm/arm64: KVM: Introduce EL2-specific executable mappings Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-15 15:03 ` Andrew Jones 2018-03-15 15:03 ` Andrew Jones 2018-03-15 15:53 ` Marc Zyngier 2018-03-15 15:53 ` Marc Zyngier 2018-03-14 16:50 ` [PATCH v6 24/26] arm64: Make BP hardening slot counter available Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-15 15:05 ` Andrew Jones 2018-03-15 15:05 ` Andrew Jones 2018-03-14 16:50 ` [PATCH v6 25/26] arm64: KVM: Allow mapping of vectors outside of the RAM region Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-15 15:54 ` Andrew Jones 2018-03-15 15:54 ` Andrew Jones 2018-03-15 16:17 ` Marc Zyngier 2018-03-15 16:17 ` Marc Zyngier 2018-03-15 17:08 ` Andrew Jones 2018-03-15 17:08 ` Andrew Jones 2018-03-15 18:47 ` Marc Zyngier 2018-03-15 18:47 ` Marc Zyngier 2018-03-16 12:33 ` Andrew Jones 2018-03-16 12:33 ` Andrew Jones 2018-03-14 16:50 ` [PATCH v6 26/26] arm64: Enable ARM64_HARDEN_EL2_VECTORS on Cortex-A57 and A72 Marc Zyngier 2018-03-14 16:50 ` Marc Zyngier 2018-03-15 15:57 ` [PATCH v6 00/26] KVM/arm64: Randomise EL2 mappings (variant 3a mitigation) Andrew Jones 2018-03-15 15:57 ` Andrew Jones 2018-03-15 16:19 ` Marc Zyngier 2018-03-15 16:19 ` Marc Zyngier 2018-03-15 16:40 ` Andrew Jones 2018-03-15 16:40 ` Andrew Jones 2018-03-15 16:52 ` Marc Zyngier 2018-03-15 16:52 ` Marc Zyngier 2018-03-16 17:46 ` Catalin Marinas 2018-03-16 17:46 ` Catalin Marinas 2018-03-16 18:05 ` Marc Zyngier 2018-03-16 18:05 ` Marc Zyngier
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=5AAAC67E.4010002@arm.com \ --to=james.morse@arm.com \ --cc=catalin.marinas@arm.com \ --cc=cdall@kernel.org \ --cc=drjones@redhat.com \ --cc=kristina.martsenko@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=mark.rutland@arm.com \ --cc=peter.maydell@linaro.org \ --cc=steve.capper@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: 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.