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