From: Oliver Upton <oliver.upton@linux.dev>
To: Ben Gardon <bgardon@google.com>
Cc: kvm@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
Will Deacon <will@kernel.org>,
kvmarm@lists.linux.dev, David Matlack <dmatlack@google.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 05/14] KVM: arm64: Add a helper to tear down unlinked stage-2 subtrees
Date: Wed, 9 Nov 2022 22:54:41 +0000 [thread overview]
Message-ID: <Y2wvsR6DvyM5YzqN@google.com> (raw)
In-Reply-To: <CANgfPd_vAmVR0BTLTFAXuQhS-bP7+B_+2s6cDmTeM5=mf440Gg@mail.gmail.com>
On Wed, Nov 09, 2022 at 02:23:33PM -0800, Ben Gardon wrote:
> On Mon, Nov 7, 2022 at 1:57 PM Oliver Upton <oliver.upton@linux.dev> wrote:
> >
> > A subsequent change to KVM will move the tear down of an unlinked
> > stage-2 subtree out of the critical path of the break-before-make
> > sequence.
> >
> > Introduce a new helper for tearing down unlinked stage-2 subtrees.
> > Leverage the existing stage-2 free walkers to do so, with a deep call
> > into __kvm_pgtable_walk() as the subtree is no longer reachable from the
> > root.
> >
> > Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> > ---
> > arch/arm64/include/asm/kvm_pgtable.h | 11 +++++++++++
> > arch/arm64/kvm/hyp/pgtable.c | 23 +++++++++++++++++++++++
> > 2 files changed, 34 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> > index a752793482cb..93b1feeaebab 100644
> > --- a/arch/arm64/include/asm/kvm_pgtable.h
> > +++ b/arch/arm64/include/asm/kvm_pgtable.h
> > @@ -333,6 +333,17 @@ int __kvm_pgtable_stage2_init(struct kvm_pgtable *pgt, struct kvm_s2_mmu *mmu,
> > */
> > void kvm_pgtable_stage2_destroy(struct kvm_pgtable *pgt);
> >
> > +/**
> > + * kvm_pgtable_stage2_free_removed() - Free a removed stage-2 paging structure.
> > + * @mm_ops: Memory management callbacks.
> > + * @pgtable: Unlinked stage-2 paging structure to be freed.
> > + * @level: Level of the stage-2 paging structure to be freed.
> > + *
> > + * The page-table is assumed to be unreachable by any hardware walkers prior to
> > + * freeing and therefore no TLB invalidation is performed.
> > + */
> > +void kvm_pgtable_stage2_free_removed(struct kvm_pgtable_mm_ops *mm_ops, void *pgtable, u32 level);
> > +
> > /**
> > * kvm_pgtable_stage2_map() - Install a mapping in a guest stage-2 page-table.
> > * @pgt: Page-table structure initialised by kvm_pgtable_stage2_init*().
> > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > index 93989b750a26..363a5cce7e1a 100644
> > --- a/arch/arm64/kvm/hyp/pgtable.c
> > +++ b/arch/arm64/kvm/hyp/pgtable.c
> > @@ -1203,3 +1203,26 @@ void kvm_pgtable_stage2_destroy(struct kvm_pgtable *pgt)
> > pgt->mm_ops->free_pages_exact(pgt->pgd, pgd_sz);
> > pgt->pgd = NULL;
> > }
> > +
> > +void kvm_pgtable_stage2_free_removed(struct kvm_pgtable_mm_ops *mm_ops, void *pgtable, u32 level)
> > +{
> > + kvm_pte_t *ptep = (kvm_pte_t *)pgtable;
> > + struct kvm_pgtable_walker walker = {
> > + .cb = stage2_free_walker,
> > + .flags = KVM_PGTABLE_WALK_LEAF |
> > + KVM_PGTABLE_WALK_TABLE_POST,
> > + };
> > + struct kvm_pgtable_walk_data data = {
> > + .walker = &walker,
> > +
> > + /*
> > + * At this point the IPA really doesn't matter, as the page
> > + * table being traversed has already been removed from the stage
> > + * 2. Set an appropriate range to cover the entire page table.
> > + */
> > + .addr = 0,
> > + .end = kvm_granule_size(level),
> > + };
> > +
> > + WARN_ON(__kvm_pgtable_walk(&data, mm_ops, ptep, level));
> > +}
>
> Will this callback be able to yield? In my experience, if processing a
> large teardown (i.e. level >=3 / maps 512G region) it's possible to
> hit scheduler tick warnings.
No, but this is a pretty obvious problem with all of our table walkers,
which led to commit 5994bc9e05c2 ("KVM: arm64: Limit
stage2_apply_range() batch size to largest block").
We're lucky in that the largest supported granule across all page table
sizes is 1GB (no true 5-level paging yet), so it may not be too
horrendous.
But yeah, it is on the list of things to fix :)
--
Thanks,
Oliver
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oliver.upton@linux.dev>
To: Ben Gardon <bgardon@google.com>
Cc: Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
Reiji Watanabe <reijiw@google.com>,
Ricardo Koller <ricarkol@google.com>,
David Matlack <dmatlack@google.com>,
Quentin Perret <qperret@google.com>,
Gavin Shan <gshan@redhat.com>, Peter Xu <peterx@redhat.com>,
Will Deacon <will@kernel.org>,
Sean Christopherson <seanjc@google.com>,
kvmarm@lists.linux.dev
Subject: Re: [PATCH v5 05/14] KVM: arm64: Add a helper to tear down unlinked stage-2 subtrees
Date: Wed, 9 Nov 2022 22:54:41 +0000 [thread overview]
Message-ID: <Y2wvsR6DvyM5YzqN@google.com> (raw)
Message-ID: <20221109225441.NkdioU7iBAUv3-c_5uy1iRv8gYClmiE25SIXd2slJ7I@z> (raw)
In-Reply-To: <CANgfPd_vAmVR0BTLTFAXuQhS-bP7+B_+2s6cDmTeM5=mf440Gg@mail.gmail.com>
On Wed, Nov 09, 2022 at 02:23:33PM -0800, Ben Gardon wrote:
> On Mon, Nov 7, 2022 at 1:57 PM Oliver Upton <oliver.upton@linux.dev> wrote:
> >
> > A subsequent change to KVM will move the tear down of an unlinked
> > stage-2 subtree out of the critical path of the break-before-make
> > sequence.
> >
> > Introduce a new helper for tearing down unlinked stage-2 subtrees.
> > Leverage the existing stage-2 free walkers to do so, with a deep call
> > into __kvm_pgtable_walk() as the subtree is no longer reachable from the
> > root.
> >
> > Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> > ---
> > arch/arm64/include/asm/kvm_pgtable.h | 11 +++++++++++
> > arch/arm64/kvm/hyp/pgtable.c | 23 +++++++++++++++++++++++
> > 2 files changed, 34 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> > index a752793482cb..93b1feeaebab 100644
> > --- a/arch/arm64/include/asm/kvm_pgtable.h
> > +++ b/arch/arm64/include/asm/kvm_pgtable.h
> > @@ -333,6 +333,17 @@ int __kvm_pgtable_stage2_init(struct kvm_pgtable *pgt, struct kvm_s2_mmu *mmu,
> > */
> > void kvm_pgtable_stage2_destroy(struct kvm_pgtable *pgt);
> >
> > +/**
> > + * kvm_pgtable_stage2_free_removed() - Free a removed stage-2 paging structure.
> > + * @mm_ops: Memory management callbacks.
> > + * @pgtable: Unlinked stage-2 paging structure to be freed.
> > + * @level: Level of the stage-2 paging structure to be freed.
> > + *
> > + * The page-table is assumed to be unreachable by any hardware walkers prior to
> > + * freeing and therefore no TLB invalidation is performed.
> > + */
> > +void kvm_pgtable_stage2_free_removed(struct kvm_pgtable_mm_ops *mm_ops, void *pgtable, u32 level);
> > +
> > /**
> > * kvm_pgtable_stage2_map() - Install a mapping in a guest stage-2 page-table.
> > * @pgt: Page-table structure initialised by kvm_pgtable_stage2_init*().
> > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > index 93989b750a26..363a5cce7e1a 100644
> > --- a/arch/arm64/kvm/hyp/pgtable.c
> > +++ b/arch/arm64/kvm/hyp/pgtable.c
> > @@ -1203,3 +1203,26 @@ void kvm_pgtable_stage2_destroy(struct kvm_pgtable *pgt)
> > pgt->mm_ops->free_pages_exact(pgt->pgd, pgd_sz);
> > pgt->pgd = NULL;
> > }
> > +
> > +void kvm_pgtable_stage2_free_removed(struct kvm_pgtable_mm_ops *mm_ops, void *pgtable, u32 level)
> > +{
> > + kvm_pte_t *ptep = (kvm_pte_t *)pgtable;
> > + struct kvm_pgtable_walker walker = {
> > + .cb = stage2_free_walker,
> > + .flags = KVM_PGTABLE_WALK_LEAF |
> > + KVM_PGTABLE_WALK_TABLE_POST,
> > + };
> > + struct kvm_pgtable_walk_data data = {
> > + .walker = &walker,
> > +
> > + /*
> > + * At this point the IPA really doesn't matter, as the page
> > + * table being traversed has already been removed from the stage
> > + * 2. Set an appropriate range to cover the entire page table.
> > + */
> > + .addr = 0,
> > + .end = kvm_granule_size(level),
> > + };
> > +
> > + WARN_ON(__kvm_pgtable_walk(&data, mm_ops, ptep, level));
> > +}
>
> Will this callback be able to yield? In my experience, if processing a
> large teardown (i.e. level >=3 / maps 512G region) it's possible to
> hit scheduler tick warnings.
No, but this is a pretty obvious problem with all of our table walkers,
which led to commit 5994bc9e05c2 ("KVM: arm64: Limit
stage2_apply_range() batch size to largest block").
We're lucky in that the largest supported granule across all page table
sizes is 1GB (no true 5-level paging yet), so it may not be too
horrendous.
But yeah, it is on the list of things to fix :)
--
Thanks,
Oliver
next prev parent reply other threads:[~2022-11-09 22:54 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 21:56 [PATCH v5 00/14] KVM: arm64: Parallel stage-2 fault handling Oliver Upton
2022-11-07 21:56 ` Oliver Upton
2022-11-07 21:56 ` [PATCH v5 01/14] KVM: arm64: Combine visitor arguments into a context structure Oliver Upton
2022-11-07 21:56 ` Oliver Upton
2022-11-09 22:23 ` Ben Gardon
2022-11-09 22:23 ` Ben Gardon
2022-11-09 22:48 ` Oliver Upton
2022-11-09 22:48 ` Oliver Upton
2022-11-10 0:23 ` Gavin Shan
2022-11-10 0:23 ` Gavin Shan
2022-11-10 0:42 ` Oliver Upton
2022-11-10 0:42 ` Oliver Upton
2022-11-10 3:40 ` Gavin Shan
2022-11-10 3:40 ` Gavin Shan
2022-11-07 21:56 ` [PATCH v5 02/14] KVM: arm64: Stash observed pte value in visitor context Oliver Upton
2022-11-07 21:56 ` Oliver Upton
2022-11-09 22:23 ` Ben Gardon
2022-11-09 22:23 ` Ben Gardon
2022-11-10 4:55 ` Gavin Shan
2022-11-10 4:55 ` Gavin Shan
2022-11-07 21:56 ` [PATCH v5 03/14] KVM: arm64: Pass mm_ops through the " Oliver Upton
2022-11-07 21:56 ` Oliver Upton
2022-11-09 22:23 ` Ben Gardon
2022-11-09 22:23 ` Ben Gardon
2022-11-10 5:22 ` Gavin Shan
2022-11-10 5:22 ` Gavin Shan
2022-11-10 5:30 ` Gavin Shan
2022-11-10 5:30 ` Gavin Shan
2022-11-07 21:56 ` [PATCH v5 04/14] KVM: arm64: Don't pass kvm_pgtable through kvm_pgtable_walk_data Oliver Upton
2022-11-07 21:56 ` Oliver Upton
2022-11-09 22:23 ` Ben Gardon
2022-11-09 22:23 ` Ben Gardon
2022-11-10 5:30 ` Gavin Shan
2022-11-10 5:30 ` Gavin Shan
2022-11-10 5:38 ` Oliver Upton
2022-11-10 5:38 ` Oliver Upton
2022-11-07 21:56 ` [PATCH v5 05/14] KVM: arm64: Add a helper to tear down unlinked stage-2 subtrees Oliver Upton
2022-11-07 21:56 ` Oliver Upton
2022-11-09 22:23 ` Ben Gardon
2022-11-09 22:23 ` Ben Gardon
2022-11-09 22:54 ` Oliver Upton [this message]
2022-11-09 22:54 ` Oliver Upton
2022-11-07 21:56 ` [PATCH v5 06/14] KVM: arm64: Use an opaque type for pteps Oliver Upton
2022-11-07 21:56 ` Oliver Upton
2022-11-09 22:23 ` Ben Gardon
2022-11-09 22:23 ` Ben Gardon
2022-11-07 21:56 ` [PATCH v5 07/14] KVM: arm64: Tear down unlinked stage-2 subtree after break-before-make Oliver Upton
2022-11-07 21:56 ` Oliver Upton
2022-11-09 22:24 ` Ben Gardon
2022-11-09 22:24 ` Ben Gardon
2022-11-07 21:56 ` [PATCH v5 08/14] KVM: arm64: Protect stage-2 traversal with RCU Oliver Upton
2022-11-07 21:56 ` Oliver Upton
2022-11-09 21:53 ` Sean Christopherson
2022-11-09 21:53 ` Sean Christopherson
2022-11-09 23:55 ` Oliver Upton
2022-11-09 23:55 ` Oliver Upton
2022-11-15 18:47 ` Ricardo Koller
2022-11-15 18:47 ` Ricardo Koller
2022-11-15 18:57 ` Oliver Upton
2022-11-15 18:57 ` Oliver Upton
2022-11-09 22:25 ` Ben Gardon
2022-11-09 22:25 ` Ben Gardon
2022-11-10 13:34 ` Marc Zyngier
2022-11-10 13:34 ` Marc Zyngier
2022-11-14 14:29 ` Marek Szyprowski
2022-11-14 14:29 ` Marek Szyprowski
2022-11-14 17:42 ` Oliver Upton
2022-11-14 17:42 ` Oliver Upton
2022-12-05 5:51 ` Mingwei Zhang
2022-12-05 5:51 ` Mingwei Zhang
2022-12-05 7:47 ` Oliver Upton
2022-12-05 7:47 ` Oliver Upton
2022-11-07 21:56 ` [PATCH v5 09/14] KVM: arm64: Atomically update stage 2 leaf attributes in parallel walks Oliver Upton
2022-11-07 21:56 ` Oliver Upton
2022-11-09 22:26 ` Ben Gardon
2022-11-09 22:26 ` Ben Gardon
2022-11-09 22:42 ` Sean Christopherson
2022-11-09 22:42 ` Sean Christopherson
2022-11-09 23:00 ` Ben Gardon
2022-11-09 23:00 ` Ben Gardon
2022-11-10 13:40 ` Marc Zyngier
2022-11-10 13:40 ` Marc Zyngier
2022-11-07 21:56 ` [PATCH v5 10/14] KVM: arm64: Split init and set for table PTE Oliver Upton
2022-11-07 21:56 ` Oliver Upton
2022-11-09 22:26 ` Ben Gardon
2022-11-09 22:26 ` Ben Gardon
2022-11-09 23:00 ` Oliver Upton
2022-11-09 23:00 ` Oliver Upton
2022-11-07 21:58 ` [PATCH v5 11/14] KVM: arm64: Make block->table PTE changes parallel-aware Oliver Upton
2022-11-07 21:58 ` Oliver Upton
2022-11-09 22:26 ` Ben Gardon
2022-11-09 22:26 ` Ben Gardon
2022-11-09 23:03 ` Oliver Upton
2022-11-09 23:03 ` Oliver Upton
2022-11-07 21:59 ` [PATCH v5 12/14] KVM: arm64: Make leaf->leaf " Oliver Upton
2022-11-07 21:59 ` Oliver Upton
2022-11-09 22:26 ` Ben Gardon
2022-11-09 22:26 ` Ben Gardon
2022-11-07 22:00 ` [PATCH v5 13/14] KVM: arm64: Make table->block " Oliver Upton
2022-11-07 22:00 ` Oliver Upton
2022-11-07 22:00 ` [PATCH v5 14/14] KVM: arm64: Handle stage-2 faults in parallel Oliver Upton
2022-11-07 22:00 ` Oliver Upton
2022-11-11 15:47 ` [PATCH v5 00/14] KVM: arm64: Parallel stage-2 fault handling Marc Zyngier
2022-11-11 15:47 ` Marc Zyngier
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=Y2wvsR6DvyM5YzqN@google.com \
--to=oliver.upton@linux.dev \
--cc=bgardon@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=will@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox