On Fri, May 31, 2024 at 12:18 PM Oliver Upton oliver.upton@linux.dev wrote:
On Fri, May 31, 2024 at 12:11:33PM -0700, Oliver Upton wrote:
On Wed, May 29, 2024 at 06:05:09PM +0000, James Houghton wrote:
[...]
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c index 9e2bbee77491..eabb07c66a07 100644 --- a/arch/arm64/kvm/hyp/pgtable.c +++ b/arch/arm64/kvm/hyp/pgtable.c @@ -1319,10 +1319,8 @@ static int stage2_age_walker(const struct kvm_pgtable_visit_ctx *ctx, data->young = true;
/*
- stage2_age_walker() is always called while holding the MMU lock for
- write, so this will always succeed. Nonetheless, this deliberately
- follows the race detection pattern of the other stage-2 walkers in
- case the locking mechanics of the MMU notifiers is ever changed.
- This walk may not be exclusive; the PTE is permitted to change
*/ if (data->mkold && !stage2_try_set_pte(ctx, new)) return -EAGAIN;
- from under us.
It is probably worth mentioning that if there was a race to update the PTE then the GFN is most likely young, so failing to clear AF probably isn't even consequential.
Thanks Oliver.
Oh, and the WARN_ON() in kvm_pgtable_stage2_test_clear_young() is bogus now. Maybe demote it to:
r = kvm_pgtable_walk(...); WARN_ON_ONCE(r && r != -EAGAIN);
Oh, indeed, thank you. Just to make sure -- does it make sense to retry the cmpxchg if it fails? For example, the way I have it now for x86[1], we retry the cmpxchg if the spte is still a leaf, otherwise we move on to the next one having done nothing. Does something like that make sense for arm64?
[1]: https://lore.kernel.org/linux-mm/20240529180510.2295118-6-jthoughton@google....