summaryrefslogtreecommitdiffstats
path: root/arch/metag
diff options
context:
space:
mode:
authorMarc Zyngier2017-12-04 18:04:38 +0100
committerMarc Zyngier2018-03-19 14:04:56 +0100
commite3f019b37b580c3b954419212da26ac5db412a08 (patch)
tree401fbc48e10dfb2585d7123bd4b0a79975a44045 /arch/metag
parentKVM: arm64: Fix HYP idmap unmap when using 52bit PA (diff)
downloadkernel-qcow2-linux-e3f019b37b580c3b954419212da26ac5db412a08.tar.gz
kernel-qcow2-linux-e3f019b37b580c3b954419212da26ac5db412a08.tar.xz
kernel-qcow2-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/metag')
0 files changed, 0 insertions, 0 deletions