Hi Alex,
On 2019-12-11 17:53, Alexandru Elisei wrote:
Hi,
On 12/11/19 4:56 PM, Marc Zyngier wrote:
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.
Cc: stable@vger.kernel.org Reported-by: Alexandru Elisei alexandru.elisei@arm.com Signed-off-by: Marc Zyngier maz@kernel.org
virt/kvm/arm/mmu.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-)
[...]
I've tested this patch using the scenario that you described in the commit message. I've also tested it with the following scenarios:
- The region is mmap'ed as backed by a VFIO device fd and the memslot
is created, it is munmap'ed, then mmap'ed as anonymous.
- The region is mmap'ed as anonymous and the memslot is created, it
is munmap'ed, then mmap'ed as backed by a VFIO device fd.
Everything worked as expected, so:
Tested-by: Alexandru Elisei alexandru.elisei@arm.com
Thanks for that!
Just a nitpick, but stage2_set_pte has a local variable iomap which can be replaced with a call to is_iomap.
Yeah, I noticed. I'm just trying to keep the patch relatively small so that it can be easily backported. The cleanup can come later! ;-)
Cheers,
M.