From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F1883AE18B for ; Fri, 6 Mar 2026 14:02:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772805767; cv=none; b=epx0hkweInE4+X4kHCKD3XhXg/q+9grUQOstw19XbJIWKXAQ4/n8qB7XZdL8u7Qd9IfC1fqFXmED+yVl7lzipcH0vdwH4cKb/Jxq1aNctGjjpoKvkeFWqv2E+iNxE3eQXDG0Z5G3efwMdj3ZGjGYJke6G08Sae+xDTDz6M6Tm4U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772805767; c=relaxed/simple; bh=ulXlCU/gFt1vNFQq7ZcdgkCRx5AlFlt38S6K5GWCz10=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=rhS3PmqBp+Qajz8ilJINo14oY7s79zLJ3GJbdm8nABn8rIZPh5lFEc/B2vBjFRcN31GZNNLtXbn+x5HO9rQGoD2JEWZ2bqcXtDxW3OscM3OLzevTO8HoXGYwfx+rfQO62pv9uGfPbmVIEEp2hh6fNtEf0/tZq6LNiYOTcDJEbLE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=NTYkRgT1; arc=none smtp.client-ip=209.85.128.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="NTYkRgT1" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-483a24db6ecso117033385e9.1 for ; Fri, 06 Mar 2026 06:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772805762; x=1773410562; darn=lists.linux.dev; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=dq2CFWg/s/4LGPe7PH75WI1RwQG3qN/TUDsxF12q5kw=; b=NTYkRgT1esFK3Ew+nAXghp3tY10dy7ChsOTdjZNaf/TLD0gs9OUGRtvCKOza+JiuSy ULKMRztMRqfLvWs+XCGzQlhWuRmzcZ9fYboFvruintJVJmXwl/VTeiY17pQUwN8A2lo3 fxEkLskqMCOxM8Ry/FXnO13TcMXYj4N6YEpSfyJrwuzg9MLqfMxvMqGxfsurQ6QzuePT IMT3ARED5/TLeYKppp9P75D9xn03e68EGcoecep+AHFHMAkKjpXNXD3oBtW8Ytx1d8QE TRtExxlTHoMBIl5uiMac5JAMcQnTmsv+wIJvgs3FJ/GYMWtMPNxw/hSo2BzYddd9eiXy B1Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772805762; x=1773410562; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dq2CFWg/s/4LGPe7PH75WI1RwQG3qN/TUDsxF12q5kw=; b=vNz4HyjXNVS+ZsSF1UxrVpftO6vAlJzBFp7reQx89eng6vaZt8dGhJytmmf0ahSCH4 rwW37qJui80IxVaFfEj3xtC52S0Fpfuv62slHMXnjjj6vT8HSTqC4gxQ7DdvpIPWq05L WoUzuSQXGiZfL/ZnedMGKbXIj4O3ArJYleJOg9+ylncVEVRfAhvTjGOnrwmWLhYsEI0z Cig7IyWnfmCmom7oqjRarILbnnlI1uhERkTT3KKgUpQ6lOH4oTCvY7DOjRjIRgQHwLm6 2Lg5RH5iCWH4uNjTiMisHB/+JrWZsBQSZxX3vv+ulXz2VI4Q+YicADHP/M2CKEzG3aol WupA== X-Forwarded-Encrypted: i=1; AJvYcCVIU5K1NcnuqWAOephfjX153oiNdoBiQFJpMXV8SsWqR38MuT//B7h+JmzYhKBpSPLmC7ytp0c=@lists.linux.dev X-Gm-Message-State: AOJu0YyTQcie9oeKs92im+DqQ9H0uYVCrkmkJcmaAgVT5v2ke9gI6euS VCV7CdqpmHLb3ordMFwDONsMTRvVmDSiUsVgCgYBjxYzRUsrbFT4SheKOU9BxiFHIHXaIY9n6VX QKw== X-Received: from wmbjw16.prod.google.com ([2002:a05:600c:5750:b0:480:4a03:7b6f]) (user=tabba job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:474f:b0:477:af8d:203a with SMTP id 5b1f17b1804b1-48526964c79mr37178325e9.27.1772805761667; Fri, 06 Mar 2026 06:02:41 -0800 (PST) Date: Fri, 6 Mar 2026 14:02:25 +0000 In-Reply-To: <20260306140232.2193802-1-tabba@google.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260306140232.2193802-1-tabba@google.com> X-Mailer: git-send-email 2.53.0.473.g4a7958ca14-goog Message-ID: <20260306140232.2193802-7-tabba@google.com> Subject: [PATCH v1 06/13] KVM: arm64: Extract page table mapping in user_mem_abort() From: Fuad Tabba To: kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org Cc: maz@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, qperret@google.com, vdonnefort@google.com, tabba@google.com Content-Type: text/plain; charset="UTF-8" Extract the code responsible for locking the KVM MMU and mapping the PFN into the stage-2 page tables into a new helper, kvm_s2_fault_map(). This helper manages the kvm_fault_lock, checks for MMU invalidation retries, attempts to adjust for transparent huge pages (THP), handles MTE sanitization if needed, and finally maps or relaxes permissions on the stage-2 entries. With this change, the main user_mem_abort() function is now a sequential dispatcher that delegates to specialized helper functions. Signed-off-by: Fuad Tabba --- arch/arm64/kvm/mmu.c | 128 +++++++++++++++++++++++-------------------- 1 file changed, 68 insertions(+), 60 deletions(-) diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index b328299cc0f5..833a7f769467 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -1892,68 +1892,13 @@ static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault) return 0; } -static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, - struct kvm_s2_trans *nested, - struct kvm_memory_slot *memslot, unsigned long hva, - bool fault_is_perm) +static int kvm_s2_fault_map(struct kvm_s2_fault *fault, void *memcache) { - int ret = 0; - struct kvm_s2_fault fault_data = { - .vcpu = vcpu, - .fault_ipa = fault_ipa, - .nested = nested, - .memslot = memslot, - .hva = hva, - .fault_is_perm = fault_is_perm, - .ipa = fault_ipa, - .logging_active = memslot_is_logging(memslot), - .force_pte = memslot_is_logging(memslot), - .s2_force_noncacheable = false, - .vfio_allow_any_uc = false, - .prot = KVM_PGTABLE_PROT_R, - }; - struct kvm_s2_fault *fault = &fault_data; - struct kvm *kvm = vcpu->kvm; - void *memcache; + struct kvm *kvm = fault->vcpu->kvm; struct kvm_pgtable *pgt; + int ret; enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED; - if (fault->fault_is_perm) - fault->fault_granule = kvm_vcpu_trap_get_perm_fault_granule(fault->vcpu); - fault->write_fault = kvm_is_write_fault(fault->vcpu); - fault->exec_fault = kvm_vcpu_trap_is_exec_fault(fault->vcpu); - VM_WARN_ON_ONCE(fault->write_fault && fault->exec_fault); - - /* - * Permission faults just need to update the existing leaf entry, - * and so normally don't require allocations from the memcache. The - * only exception to this is when dirty logging is enabled at runtime - * and a write fault needs to collapse a block entry into a table. - */ - fault->topup_memcache = !fault->fault_is_perm || - (fault->logging_active && fault->write_fault); - ret = prepare_mmu_memcache(fault->vcpu, fault->topup_memcache, &memcache); - if (ret) - return ret; - - /* - * Let's check if we will get back a huge fault->page backed by hugetlbfs, or - * get block mapping for device MMIO region. - */ - ret = kvm_s2_fault_pin_pfn(fault); - if (ret != 1) - return ret; - - ret = 0; - - ret = kvm_s2_fault_compute_prot(fault); - if (ret == 1) { - ret = 1; /* fault injected */ - goto out_put_page; - } - if (ret) - goto out_put_page; - kvm_fault_lock(kvm); pgt = fault->vcpu->arch.hw_mmu->pgt; if (mmu_invalidate_retry(kvm, fault->mmu_seq)) { @@ -2001,8 +1946,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, * PTE, which will be preserved. */ fault->prot &= ~KVM_NV_GUEST_MAP_SZ; - ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, fault->fault_ipa, fault->prot, - flags); + ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, fault->fault_ipa, + fault->prot, flags); } else { ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, fault->fault_ipa, fault->vma_pagesize, __pfn_to_phys(fault->pfn), fault->prot, @@ -2018,6 +1963,69 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, mark_page_dirty_in_slot(kvm, fault->memslot, fault->gfn); return ret != -EAGAIN ? ret : 0; +} + +static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, + struct kvm_s2_trans *nested, + struct kvm_memory_slot *memslot, unsigned long hva, + bool fault_is_perm) +{ + int ret = 0; + struct kvm_s2_fault fault_data = { + .vcpu = vcpu, + .fault_ipa = fault_ipa, + .nested = nested, + .memslot = memslot, + .hva = hva, + .fault_is_perm = fault_is_perm, + .ipa = fault_ipa, + .logging_active = memslot_is_logging(memslot), + .force_pte = memslot_is_logging(memslot), + .s2_force_noncacheable = false, + .vfio_allow_any_uc = false, + .prot = KVM_PGTABLE_PROT_R, + }; + struct kvm_s2_fault *fault = &fault_data; + void *memcache; + + if (fault->fault_is_perm) + fault->fault_granule = kvm_vcpu_trap_get_perm_fault_granule(fault->vcpu); + fault->write_fault = kvm_is_write_fault(fault->vcpu); + fault->exec_fault = kvm_vcpu_trap_is_exec_fault(fault->vcpu); + VM_WARN_ON_ONCE(fault->write_fault && fault->exec_fault); + + /* + * Permission faults just need to update the existing leaf entry, + * and so normally don't require allocations from the memcache. The + * only exception to this is when dirty logging is enabled at runtime + * and a write fault needs to collapse a block entry into a table. + */ + fault->topup_memcache = !fault->fault_is_perm || + (fault->logging_active && fault->write_fault); + ret = prepare_mmu_memcache(fault->vcpu, fault->topup_memcache, &memcache); + if (ret) + return ret; + + /* + * Let's check if we will get back a huge fault->page backed by hugetlbfs, or + * get block mapping for device MMIO region. + */ + ret = kvm_s2_fault_pin_pfn(fault); + if (ret != 1) + return ret; + + ret = 0; + + ret = kvm_s2_fault_compute_prot(fault); + if (ret == 1) { + ret = 1; /* fault injected */ + goto out_put_page; + } + if (ret) + goto out_put_page; + + ret = kvm_s2_fault_map(fault, memcache); + return ret; out_put_page: kvm_release_page_unused(fault->page); -- 2.53.0.473.g4a7958ca14-goog