From patchwork Wed Oct 21 16:16:50 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Santosh Shukla X-Patchwork-Id: 11849381 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1160AC388F9 for ; Wed, 21 Oct 2020 16:18:44 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 85D9722249 for ; Wed, 21 Oct 2020 16:18:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Z3OHEQuH"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="Ye4yQZfV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 85D9722249 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:To:From: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=N13uDDsKVzWswN9zsAJX5f7E60SIB5I/ELkGDRi2ULw=; b=Z3OHEQuHTkWgXSEniM7F3SHCMT PVfxawubBoVLoWshsb1/mka36OqWQDIRCxLwav7PWyLWKgkmXzkZNvjSqex2m3UH6PvU2GJUhu2NH Jz0TYVYl2F20j5MJfkdrCvEB63PO/viIbSm86zls8Kq8V7c85NNfWe/yen3EAyGTAwukdNs/qOkAq 2kEYzNzkaTDot+ly00Q85WgDOgz+HArQcfNSCxn63A0OmAEwuTY07r0ViJWHqhwJgFbB1AfgthG0v 6soyP97lozsdQSr5ynP0R9Aq9SO1faKKqCuVhXtzZAO+JjqJ9b2f9dBWtdwHKG8Xoyb28pRWCSWYF /RzifBXA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVGnm-00037a-R9; Wed, 21 Oct 2020 16:17:26 +0000 Received: from hqnvemgate25.nvidia.com ([216.228.121.64]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVGnk-00036l-Dy for linux-arm-kernel@lists.infradead.org; Wed, 21 Oct 2020 16:17:25 +0000 Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate25.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Wed, 21 Oct 2020 09:16:32 -0700 Received: from HQMAIL105.nvidia.com (172.20.187.12) by HQMAIL105.nvidia.com (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Oct 2020 16:17:17 +0000 Received: from santosh-System-Product-Name.nvidia.com (10.124.1.5) by mail.nvidia.com (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 21 Oct 2020 16:17:13 +0000 From: Santosh Shukla To: , , , Subject: [PATCH] KVM: arm64: Correctly handle the mmio faulting Date: Wed, 21 Oct 2020 21:46:50 +0530 Message-ID: <1603297010-18787-1-git-send-email-sashukla@nvidia.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1603296992; bh=/pCPC1opPh5gWz/GYqPevuPPTN8cDasp68thhdStyhk=; h=From:To:CC:Subject:Date:Message-ID:X-Mailer:MIME-Version: Content-Type; b=Ye4yQZfVInpCS04DCvMYTSXJpuahcba6/U6nidiQxMqNQssOMZ4g2VJEwQroKxvqQ Yf2nDIGV9EivhJ8ySh9oQj3ftFP1xLtMEkYltiFs0AcRGtmDVhXZhKMJGfYYKiJqC7 QsFZY63fdcNO4HdLlWW8rlE7rZSbCrxpiLc90tb9jzWauzHT8lx4QIUFUzzddIbTvV 5eywN+ChvIu7lfUACARqOxZhxyVlcGPpzJ7B/CG4lScZLgkDU8TS0aIWEqxhPrewLE 01j7i219Z64zo7BaP7DM6krxjAm21dTya5l2q63zF2ur7l1K3VxIEeEIhe+4jn9tTT YWmH+jNo3/byw== X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201021_121724_540470_46122FA4 X-CRM114-Status: GOOD ( 16.58 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: cjia@nvidia.com, suzuki.poulose@arm.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, Santosh Shukla , linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org The Commit:6d674e28 introduces a notion to detect and handle the device mapping. The commit checks for the VM_PFNMAP flag is set in vma->flags and if set then marks force_pte to true such that if force_pte is true then ignore the THP function check (/transparent_hugepage_adjust()). There could be an issue with the VM_PFNMAP flag setting and checking. For example consider a case where the mdev vendor driver register's the vma_fault handler named vma_mmio_fault(), which maps the host MMIO region in-turn calls remap_pfn_range() and maps the MMIO's vma space. Where, remap_pfn_range implicitly sets the VM_PFNMAP flag into vma->flags. Now lets assume a mmio fault handing flow where guest first access the MMIO region whose 2nd stage translation is not present. So that results to arm64-kvm hypervisor executing guest abort handler, like below: kvm_handle_guest_abort() --> user_mem_abort()--> { ... 0. checks the vma->flags for the VM_PFNMAP. 1. Since VM_PFNMAP flag is not yet set so force_pte _is_ false; 2. gfn_to_pfn_prot() --> __gfn_to_pfn_memslot() --> fixup_user_fault() --> handle_mm_fault()--> __do_fault() --> vma_mmio_fault() --> // vendor's mdev fault handler remap_pfn_range()--> // Here sets the VM_PFNMAP flag into vma->flags. 3. Now that force_pte is set to false in step-2), will execute transparent_hugepage_adjust() func and that lead to Oops [4]. } The proposition is to check is_iomap flag before executing the THP function transparent_hugepage_adjust(). [4] THP Oops: > pc: kvm_is_transparent_hugepage+0x18/0xb0 > ... > ... > user_mem_abort+0x340/0x9b8 > kvm_handle_guest_abort+0x248/0x468 > handle_exit+0x150/0x1b0 > kvm_arch_vcpu_ioctl_run+0x4d4/0x778 > kvm_vcpu_ioctl+0x3c0/0x858 > ksys_ioctl+0x84/0xb8 > __arm64_sys_ioctl+0x28/0x38 Tested on Huawei Kunpeng Taishan-200 arm64 server, Using VFIO-mdev device. Linux tip: 583090b1 Fixes: 6d674e28 ("KVM: arm/arm64: Properly handle faulting of device mappings") Signed-off-by: Santosh Shukla --- arch/arm64/kvm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index 3d26b47..ff15357 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -1947,7 +1947,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, * If we are not forced to use page mapping, check if we are * backed by a THP and thus use block mapping if possible. */ - if (vma_pagesize == PAGE_SIZE && !force_pte) + if (vma_pagesize == PAGE_SIZE && !force_pte && !is_iomap(flags)) vma_pagesize = transparent_hugepage_adjust(memslot, hva, &pfn, &fault_ipa); if (writable)