Re: [PATCH v5 2/5] KVM: arm64: Add pre_fault_memory implementation
Aneesh Kumar K.V <[email protected]> Mon, 03 Aug 2026 11:36:33 +0530
| Newsgroups | org.kernel.vger.linux-doc,dev.linux.lists.kvmarm,org.infradead.lists.linux-arm-kernel,org.kernel.vger.kvm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest |
|---|---|
| Message-ID | <[email protected]> |
Alexandru Elisei <[email protected]> writes: > Hi Jack, > > On Fri, Jun 12, 2026 at 05:23:50PM +0100, Jack Thomson wrote: >> From: Jack Thomson <[email protected]> .... >> + if (kvm_is_error_hva(hva)) { >> + ret = -EFAULT; >> + goto out; >> + } >> + >> + s2fd.hva = hva; >> + ret = user_mem_abort(&s2fd); > > If is_protected_kvm_enabled(), this function doesn't check if the mapping > already exists. user_mem_abort() will call **p**kvm_pgtable_stage2_map() > (emphasis is mine) to create the mapping, and pkvm_pgtable_stage2_map() will > return -EAGAIN, and keep returning -EAGAIN until the mapping is destroyed, which > might be some time away. > > Same thing happens **without** pKVM, kvm_pgtable_stage2_map() will return > -EAGAIN if the mapping exists. But that's not such a big issue, when the > user calls KVM_PRE_FAULT_MEMORY on the remaining range > kvm_pgtable_get_leaf() will detect the existing mapping. Which you have > already taken into consideration judging by the comment, so all good here. > But both gmem_abort() and user_mem_abort() handle -EAGAIN internally, don't they? For gmem_abort(), we have: 1692: return ret != -EAGAIN ? ret : 0; For user_mem_abort(), the call path is: user_mem_abort() -> kvm_s2_fault_map() -> KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, ...) and kvm_s2_fault_map() does: 2111: if (ret != -EAGAIN) return ret; return 0; -aneesh