From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 12/19] KVM: arm/arm64: Move ioremap calls to create_hyp_io_mappings
Date: Mon, 15 Jan 2018 19:07:28 +0100 [thread overview]
Message-ID: <20180115180728.GN21403@cbox> (raw)
In-Reply-To: <20180104184334.16571-13-marc.zyngier@arm.com>
On Thu, Jan 04, 2018 at 06:43:27PM +0000, Marc Zyngier wrote:
> Both HYP io mappings call ioremap, followed by create_hyp_io_mappings.
> Let's move the ioremap call into create_hyp_io_mappings itself, which
> simplifies the code a bit and allows for further refactoring.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/include/asm/kvm_mmu.h | 3 ++-
> arch/arm64/include/asm/kvm_mmu.h | 3 ++-
> virt/kvm/arm/mmu.c | 24 ++++++++++++++----------
> virt/kvm/arm/vgic/vgic-v2.c | 31 ++++++++-----------------------
> 4 files changed, 26 insertions(+), 35 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index fa6f2174276b..cb3bef71ec9b 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -41,7 +41,8 @@
> #include <asm/stage2_pgtable.h>
>
> int create_hyp_mappings(void *from, void *to, pgprot_t prot);
> -int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
> +int create_hyp_io_mappings(phys_addr_t phys_addr, size_t size,
> + void __iomem **kaddr);
> void free_hyp_pgds(void);
>
> void stage2_unmap_vm(struct kvm *kvm);
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index b0c3cbe9b513..09a208014457 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -119,7 +119,8 @@ static inline unsigned long __kern_hyp_va(unsigned long v)
> #include <asm/stage2_pgtable.h>
>
> int create_hyp_mappings(void *from, void *to, pgprot_t prot);
> -int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
> +int create_hyp_io_mappings(phys_addr_t phys_addr, size_t size,
> + void __iomem **kaddr);
> void free_hyp_pgds(void);
>
> void stage2_unmap_vm(struct kvm *kvm);
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index 84d09f1a44d4..38adbe0a016c 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -709,26 +709,30 @@ int create_hyp_mappings(void *from, void *to, pgprot_t prot)
> }
>
> /**
> - * create_hyp_io_mappings - duplicate a kernel IO mapping into Hyp mode
> - * @from: The kernel start VA of the range
> - * @to: The kernel end VA of the range (exclusive)
> + * create_hyp_io_mappings - Map IO into both kernel and HYP
> * @phys_addr: The physical start address which gets mapped
> + * @size: Size of the region being mapped
> + * @kaddr: Kernel VA for this mapping
> *
> * The resulting HYP VA is the same as the kernel VA, modulo
> * HYP_PAGE_OFFSET.
> */
> -int create_hyp_io_mappings(void *from, void *to, phys_addr_t phys_addr)
> +int create_hyp_io_mappings(phys_addr_t phys_addr, size_t size,
> + void __iomem **kaddr)
nit: you could make this return a "void __iomem *" and use ERR_PTR etc.
as well, but it'll probably look worse on the calling side, so either
way is fine with me.
> {
> - unsigned long start = kern_hyp_va((unsigned long)from);
> - unsigned long end = kern_hyp_va((unsigned long)to);
> + unsigned long start, end;
>
> - if (is_kernel_in_hyp_mode())
> + *kaddr = ioremap(phys_addr, size);
> + if (!*kaddr)
> + return -ENOMEM;
> +
> + if (is_kernel_in_hyp_mode()) {
> return 0;
> + }
nit: we don't need the curly braces
>
> - /* Check for a valid kernel IO mapping */
> - if (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1))
> - return -EINVAL;
>
> + start = kern_hyp_va((unsigned long)*kaddr);
> + end = kern_hyp_va((unsigned long)*kaddr + size);
> return __create_hyp_mappings(hyp_pgd, start, end,
> __phys_to_pfn(phys_addr), PAGE_HYP_DEVICE);
> }
> diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
> index 80897102da26..bc49d702f9f0 100644
> --- a/virt/kvm/arm/vgic/vgic-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-v2.c
> @@ -332,16 +332,10 @@ int vgic_v2_probe(const struct gic_kvm_info *info)
> if (!PAGE_ALIGNED(info->vcpu.start) ||
> !PAGE_ALIGNED(resource_size(&info->vcpu))) {
> kvm_info("GICV region size/alignment is unsafe, using trapping (reduced performance)\n");
> - kvm_vgic_global_state.vcpu_base_va = ioremap(info->vcpu.start,
> - resource_size(&info->vcpu));
> - if (!kvm_vgic_global_state.vcpu_base_va) {
> - kvm_err("Cannot ioremap GICV\n");
> - return -ENOMEM;
> - }
>
> - ret = create_hyp_io_mappings(kvm_vgic_global_state.vcpu_base_va,
> - kvm_vgic_global_state.vcpu_base_va + resource_size(&info->vcpu),
> - info->vcpu.start);
> + ret = create_hyp_io_mappings(info->vcpu.start,
> + resource_size(&info->vcpu),
> + &kvm_vgic_global_state.vcpu_base_va);
> if (ret) {
> kvm_err("Cannot map GICV into hyp\n");
> goto out;
> @@ -350,26 +344,17 @@ int vgic_v2_probe(const struct gic_kvm_info *info)
> static_branch_enable(&vgic_v2_cpuif_trap);
> }
>
> - kvm_vgic_global_state.vctrl_base = ioremap(info->vctrl.start,
> - resource_size(&info->vctrl));
> - if (!kvm_vgic_global_state.vctrl_base) {
> - kvm_err("Cannot ioremap GICH\n");
> - ret = -ENOMEM;
> + ret = create_hyp_io_mappings(info->vctrl.start,
> + resource_size(&info->vctrl),
> + &kvm_vgic_global_state.vctrl_base);
> + if (ret) {
> + kvm_err("Cannot map VCTRL into hyp\n");
> goto out;
> }
>
> vtr = readl_relaxed(kvm_vgic_global_state.vctrl_base + GICH_VTR);
> kvm_vgic_global_state.nr_lr = (vtr & 0x3f) + 1;
>
> - ret = create_hyp_io_mappings(kvm_vgic_global_state.vctrl_base,
> - kvm_vgic_global_state.vctrl_base +
> - resource_size(&info->vctrl),
> - info->vctrl.start);
> - if (ret) {
> - kvm_err("Cannot map VCTRL into hyp\n");
> - goto out;
> - }
> -
> ret = kvm_register_vgic_device(KVM_DEV_TYPE_ARM_VGIC_V2);
> if (ret) {
> kvm_err("Cannot register GICv2 KVM device\n");
> --
> 2.14.2
>
Otherwise looks good:
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
next prev parent reply other threads:[~2018-01-15 18:07 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-04 18:43 [PATCH v4 00/19] KVM/arm64: Randomise EL2 mappings Marc Zyngier
2018-01-04 18:43 ` [PATCH v4 01/19] arm64: asm-offsets: Avoid clashing DMA definitions Marc Zyngier
2018-01-04 18:43 ` [PATCH v4 02/19] arm64: asm-offsets: Remove unused definitions Marc Zyngier
2018-01-04 18:43 ` [PATCH v4 03/19] arm64: asm-offsets: Remove potential circular dependency Marc Zyngier
2018-01-15 8:34 ` Christoffer Dall
2018-01-15 8:42 ` Marc Zyngier
2018-01-15 9:46 ` Christoffer Dall
2018-01-04 18:43 ` [PATCH v4 04/19] arm64: alternatives: Enforce alignment of struct alt_instr Marc Zyngier
2018-01-15 9:11 ` Christoffer Dall
2018-01-04 18:43 ` [PATCH v4 05/19] arm64: alternatives: Add dynamic patching feature Marc Zyngier
2018-01-15 11:26 ` Christoffer Dall
2018-01-04 18:43 ` [PATCH v4 06/19] arm64: insn: Add N immediate encoding Marc Zyngier
2018-01-15 11:26 ` Christoffer Dall
2018-01-04 18:43 ` [PATCH v4 07/19] arm64: insn: Add encoder for bitwise operations using literals Marc Zyngier
2018-01-15 11:26 ` Christoffer Dall
2018-01-04 18:43 ` [PATCH v4 08/19] arm64: KVM: Dynamically patch the kernel/hyp VA mask Marc Zyngier
2018-01-15 11:47 ` Christoffer Dall
2018-02-15 13:11 ` Marc Zyngier
2018-02-16 9:02 ` Christoffer Dall
2018-01-04 18:43 ` [PATCH v4 09/19] arm64: cpufeatures: Drop the ARM64_HYP_OFFSET_LOW feature flag Marc Zyngier
2018-01-15 11:48 ` Christoffer Dall
2018-01-04 18:43 ` [PATCH v4 10/19] KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state Marc Zyngier
2018-01-15 15:36 ` Christoffer Dall
2018-02-15 13:22 ` Marc Zyngier
2018-02-16 9:05 ` Christoffer Dall
2018-02-16 9:33 ` Marc Zyngier
2018-02-19 14:39 ` Christoffer Dall
2018-02-20 11:40 ` Marc Zyngier
2018-01-04 18:43 ` [PATCH v4 11/19] KVM: arm/arm64: Demote HYP VA range display to being a debug feature Marc Zyngier
2018-01-15 15:54 ` Christoffer Dall
2018-01-04 18:43 ` [PATCH v4 12/19] KVM: arm/arm64: Move ioremap calls to create_hyp_io_mappings Marc Zyngier
2018-01-15 18:07 ` Christoffer Dall [this message]
2018-01-04 18:43 ` [PATCH v4 13/19] KVM: arm/arm64: Keep GICv2 HYP VAs in kvm_vgic_global_state Marc Zyngier
2018-01-18 14:39 ` Christoffer Dall
2018-01-04 18:43 ` [PATCH v4 14/19] KVM: arm/arm64: Move HYP IO VAs to the "idmap" range Marc Zyngier
2018-01-18 14:39 ` Christoffer Dall
2018-02-15 13:52 ` Marc Zyngier
2018-02-16 9:25 ` Christoffer Dall
2018-02-16 15:20 ` Marc Zyngier
2018-01-04 18:43 ` [PATCH v4 15/19] arm64; insn: Add encoder for the EXTR instruction Marc Zyngier
2018-01-18 20:27 ` Christoffer Dall
2018-01-04 18:43 ` [PATCH v4 16/19] arm64: insn: Allow ADD/SUB (immediate) with LSL #12 Marc Zyngier
2018-01-18 20:28 ` Christoffer Dall
2018-01-04 18:43 ` [PATCH v4 17/19] arm64: KVM: Dynamically compute the HYP VA mask Marc Zyngier
2018-01-18 20:28 ` Christoffer Dall
2018-02-15 13:58 ` Marc Zyngier
2018-01-04 18:43 ` [PATCH v4 18/19] arm64: KVM: Introduce EL2 VA randomisation Marc Zyngier
2018-01-18 20:28 ` Christoffer Dall
2018-02-15 15:32 ` Marc Zyngier
2018-02-16 9:33 ` Christoffer Dall
2018-01-04 18:43 ` [PATCH v4 19/19] arm64: Update the KVM memory map documentation Marc Zyngier
2018-01-18 20:28 ` 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=20180115180728.GN21403@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).