KVM: arm/arm64: Properly handle faulting of device mappings
authorMarc Zyngier <maz@kernel.org>
Wed, 11 Dec 2019 16:56:48 +0000 (16:56 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 31 Dec 2019 15:46:24 +0000 (16:46 +0100)
commit9408013caae6de84a2b137c7dab627a4bd4b8b7b
tree6a8baf79e6dc17dc547f1579ef329e95a150dcb0
parent7ea735683adcc53bb12f7a13dee07e31f751a2ef
KVM: arm/arm64: Properly handle faulting of device mappings

commit 6d674e28f642e3ff676fbae2d8d1b872814d32b6 upstream.

A device mapping is normally always mapped at Stage-2, since there
is very little gain in having it faulted in.

Nonetheless, it is possible to end-up in a situation where the device
mapping has been removed from Stage-2 (userspace munmaped the VFIO
region, and the MMU notifier did its job), but present in a userspace
mapping (userpace has mapped it back at the same address). In such
a situation, the device mapping will be demand-paged as the guest
performs memory accesses.

This requires to be careful when dealing with mapping size, cache
management, and to handle potential execution of a device mapping.

Reported-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191211165651.7889-2-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
virt/kvm/arm/mmu.c