diff options
| author | Marc Zyngier <marc.zyngier@arm.com> | 2017-12-04 17:04:38 +0000 |
|---|---|---|
| committer | Marc Zyngier <marc.zyngier@arm.com> | 2018-03-19 13:04:56 +0000 |
| commit | e3f019b37b580c3b954419212da26ac5db412a08 (patch) | |
| tree | 401fbc48e10dfb2585d7123bd4b0a79975a44045 /arch/arm | |
| parent | 3ddd45565373604d4f49cb0496fc0168e3863c1f (diff) | |
| download | linux-e3f019b37b580c3b954419212da26ac5db412a08.tar.gz linux-e3f019b37b580c3b954419212da26ac5db412a08.tar.bz2 linux-e3f019b37b580c3b954419212da26ac5db412a08.zip | |
KVM: arm/arm64: Move HYP IO VAs to the "idmap" range
We so far mapped our HYP IO (which is essentially the GICv2 control
registers) using the same method as for memory. It recently appeared
that is a bit unsafe:
We compute the HYP VA using the kern_hyp_va helper, but that helper
is only designed to deal with kernel VAs coming from the linear map,
and not from the vmalloc region... This could in turn cause some bad
aliasing between the two, amplified by the upcoming VA randomisation.
A solution is to come up with our very own basic VA allocator for
MMIO. Since half of the HYP address space only contains a single
page (the idmap), we have plenty to borrow from. Let's use the idmap
as a base, and allocate downwards from it. GICv2 now lives on the
other side of the great VA barrier.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Diffstat (limited to 'arch/arm')
| -rw-r--r-- | arch/arm/include/asm/kvm_mmu.h | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h index 4c5c8a386baf..b0b0cde77ca6 100644 --- a/arch/arm/include/asm/kvm_mmu.h +++ b/arch/arm/include/asm/kvm_mmu.h @@ -49,6 +49,9 @@ #include <asm/pgalloc.h> #include <asm/stage2_pgtable.h> +/* Ensure compatibility with arm64 */ +#define VA_BITS 32 + int create_hyp_mappings(void *from, void *to, pgprot_t prot); int create_hyp_io_mappings(phys_addr_t phys_addr, size_t size, void __iomem **kaddr, |