All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oupton@kernel.org>
To: Vincent Donnefort <vdonnefort@google.com>
Cc: Fuad Tabba <fuad.tabba@linux.dev>, Marc Zyngier <maz@kernel.org>,
	kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Joey Gouly <joey.gouly@arm.com>,
	Steffen Eiden <seiden@linux.ibm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Raghavendra Rao Ananta <rananta@google.com>,
	Fuad Tabba <tabba@google.com>
Subject: Re: [PATCH 1/3] KVM: arm64: Don't walk the whole IPA space when destroying a pKVM stage-2
Date: Tue, 3 Nov 2026 08:48:14 -0800	[thread overview]
Message-ID: <auoQTpm_UJWs4RK1@kernel.org> (raw)
In-Reply-To: <auoQIzfM8tF4F98q@kernel.org>

On Tue, Nov 03, 2026 at 08:47:31AM -0800, Oliver Upton wrote:
> On Tue, Nov 03, 2026 at 04:37:54PM +0000, Vincent Donnefort wrote:
> > > @@ -513,10 +514,18 @@ void pkvm_pgtable_stage2_destroy_range(struct kvm_pgtable *pgt,
> > >  		kvm->arch.pkvm.is_dying = true;
> > >  	}
> > >  
> > > -	if (kvm_vm_is_protected(kvm))
> > > -		__pkvm_pgtable_stage2_reclaim(pgt, addr, addr + size);
> > > -	else
> > > -		__pkvm_pgtable_stage2_unshare(pgt, addr, addr + size);
> > > +	/* Called once for the whole IPA space, so reschedule between mappings */
> > > +	for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
> > > +		u64 start = __pkvm_mapping_start(mapping);
> > > +		u64 end = __pkvm_mapping_end(mapping) + 1;
> > > +
> > > +		if (kvm_vm_is_protected(kvm))
> > > +			__pkvm_pgtable_stage2_reclaim(pgt, start, end);
> > > +		else
> > > +			__pkvm_pgtable_stage2_unshare(pgt, start, end);
> > > +
> > > +		cond_resched();
> > > +	}
> > >  }
> > 
> > Just thought that it is a bit weird that pkvm_pgtable_stage2_destroy_range()
> > does cond_resched() while kvm_pgtable_stage2_destroy_range() does not.
> > 
> > How about instead kvm_stage2_destroy() refines start/end with some accessors
> > calling in pkvm.c pkvm_mapping_iter_first() / pkvm_mapping_iter_last()?
> 
> Yeah, I'd rather we tackle this as a general problem than doing some
> pKVM specific hacks.
> 
> Seems to me that we do a lot of wasted work even in the non-pKVM case
> where the outer loop will continue to iterate KVM_PGTABLE_MIN_BLOCK_LEVEL
> worth of IPA even if the underlying table is empty.
> 
> What we'd want is for the kvm_pgtable_stage2_destroy_range()
> implementation to report back how much of the IPA space it actually
> iterated over. We wouldn't want to keep re-visiting the same invalid PGD
> entry only because it's larger than our max block size.

Next patch heh :)


  reply	other threads:[~2026-11-03 16:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03  8:47 [PATCH 0/3] KVM: arm64: Stop stage-2 teardown scaling with the IPA size Fuad Tabba
2026-11-03  8:47 ` [PATCH 1/3] KVM: arm64: Don't walk the whole IPA space when destroying a pKVM stage-2 Fuad Tabba
2026-11-03 14:52   ` Vincent Donnefort
2026-11-03 16:15     ` Fuad Tabba
2026-11-03 16:26       ` Marc Zyngier
2026-11-03 16:27         ` Fuad Tabba
2026-11-03 16:37   ` Vincent Donnefort
2026-11-03 16:47     ` Oliver Upton
2026-11-03 16:48       ` Oliver Upton [this message]
2026-11-03  8:47 ` [PATCH 2/3] KVM: arm64: Skip empty IPA ranges when destroying stage-2 page-tables Fuad Tabba
2026-11-03 10:27   ` Suzuki K Poulose
2026-11-03 16:19     ` Fuad Tabba
2026-11-03 16:55       ` Oliver Upton
2026-11-03  8:47 ` [PATCH 3/3] KVM: arm64: Move stage-2 teardown into kvm_vm_s2_ops Fuad Tabba
2026-11-03  9:37   ` Suzuki K Poulose
2026-11-03 10:33     ` Suzuki K Poulose
2026-11-03 16:22       ` Fuad Tabba
2026-11-03 17:03 ` [PATCH 0/3] KVM: arm64: Stop stage-2 teardown scaling with the IPA size Oliver Upton
2026-11-03 19:08   ` Fuad Tabba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=auoQTpm_UJWs4RK1@kernel.org \
    --to=oupton@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=fuad.tabba@linux.dev \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=rananta@google.com \
    --cc=seiden@linux.ibm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=vdonnefort@google.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.