Re: [PATCH v5 2/5] KVM: arm64: Add pre_fault_memory implementation

Aneesh Kumar K.V <[email protected]>
Newsgroups org.infradead.lists.linux-arm-kernel,dev.linux.lists.kvmarm,org.kernel.vger.kvm,org.kernel.vger.linux-doc,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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.