From: Santosh Shukla <sashukla@nvidia.com>
To: <maz@kernel.org>, <kvm@vger.kernel.org>,
<kvmarm@lists.cs.columbia.edu>, <linux-kernel@vger.kernel.org>
Cc: mcrossley@nvidia.com, cjia@nvidia.com, kwankhede@nvidia.com,
will@kernel.org, linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/1] KVM: arm64: fix the mmio faulting
Date: Mon, 26 Oct 2020 16:54:06 +0530 [thread overview]
Message-ID: <1603711447-11998-1-git-send-email-sashukla@nvidia.com> (raw)
Description of the Reproducer scenario as asked in the thread [1].
Tried to create the reproducer scenario with vfio-pci driver using
nvidia GPU in PT mode, As because vfio-pci driver now supports
vma faulting (/vfio_pci_mmap_fault) so could create a crude reproducer
situation with that.
To create the repro - I did an ugly hack into arm64/kvm/mmu.c.
The hack is to make sure that stage2 mapping are not created
at the time of vm_init by unsetting VM_PFNMAP flag. This `unsetting` flag
needed because vfio-pci's mmap func(/vfio_pci_mmap) by-default
sets the VM_PFNMAP flag for the MMIO region but I want
the remap_pfn_range() func to set the _PFNMAP flag via vfio's fault
handler func vfio_pci_mmap_fault().
So with above, when guest access the MMIO region, this will
trigger the mmio fault path at arm64-kvm hypervisor layer like below:
user_mem_abort() {->...
--> Check the VM_PFNMAP flag, since not set so marks force_pte=false
....
__gfn_to_pfn_memslot()-->
...
handle_mm_fault()-->
do_fault()-->
vfio_pci_mmio_fault()-->
remap_pfn_range()--> Now will set the VM_PFNMAP flag.
}
Since the force_pte flag is set to false so will lead to THP oops.
By setting the force_pte=true will avoid the THP Oops which was
mentioned in the [2] and patch proposition [1/1] fixes that.
hackish change to reproduce scenario:
--->
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index d4cd25334610..b0a999aa6a95 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1318,6 +1318,12 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
vm_start = max(hva, vma->vm_start);
vm_end = min(reg_end, vma->vm_end);
+ /* Hack to make sure stage2 mapping not present, thus trigger
+ * user_mem_abort for stage2 mapping
+ */
+ if (vma->vm_flags & VM_PFNMAP) {
+ vma->vm_flags = vma->vm_flags & (~VM_PFNMAP);
+ }
if (vma->vm_flags & VM_PFNMAP) {
gpa_t gpa = mem->guest_phys_addr +
(vm_start - mem->userspace_addr);
Thanks.
Santosh
[1] https://lkml.org/lkml/2020/10/23/310
[2] https://lkml.org/lkml/2020/10/21/460
Santosh Shukla (1):
KVM: arm64: Correctly handle the mmio faulting
arch/arm64/kvm/mmu.c | 1 +
1 file changed, 1 insertion(+)
--
2.7.4
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next reply other threads:[~2020-10-26 11:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 11:24 Santosh Shukla [this message]
2020-10-26 11:24 ` [PATCH v2 1/1] KVM: arm64: Correctly handle the mmio faulting Santosh Shukla
2020-10-27 4:04 ` Gavin Shan
2020-10-29 21:09 ` [PATCH v2 0/1] KVM: arm64: fix " Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1603711447-11998-1-git-send-email-sashukla@nvidia.com \
--to=sashukla@nvidia.com \
--cc=cjia@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=kwankhede@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=mcrossley@nvidia.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox