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: sta...@vger.kernel.org
Reported-by: Alexandru Elisei <alexandru.eli...@arm.com>
Signed-off-by: Marc Zyngier <m...@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.eli...@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.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
