From: David Matlack <dmatlack@google.com>
To: Vipin Sharma <vipinsh@google.com>
Cc: seanjc@google.com, pbonzini@redhat.com, bgardon@google.com,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Patch v3 6/7] KVM: x86/mmu: Remove handle_changed_spte_dirty_log()
Date: Wed, 22 Feb 2023 11:36:16 -0800 [thread overview]
Message-ID: <Y/ZusFTMlUUWsWLF@google.com> (raw)
In-Reply-To: <20230211014626.3659152-7-vipinsh@google.com>
On Fri, Feb 10, 2023 at 05:46:25PM -0800, Vipin Sharma wrote:
> Remove handle_changed_spte_dirty_log() as there is no code flow which
> sets 4KiB SPTE writable and hit this path. This function marks the page
> dirty in a memslot only if new SPTE is 4KiB in size and writable.
>
> Current users of handle_changed_spte_dirty_log() are:
> 1. set_spte_gfn() - Create only non writable SPTEs.
> 2. write_protect_gfn() - Change an SPTE to non writable.
> 3. zap leaf and roots APIs - Everything is 0.
> 4. handle_removed_pt() - Sets SPTEs to REMOVED_SPTE
> 5. tdp_mmu_link_sp() - Makes non leaf SPTEs.
>
> There is also no path which creates a writable 4KiB without going
> through make_spte() and this functions takes care of marking SPTE dirty
> in the memslot if it is PT_WRITABLE.
>
> Signed-off-by: Vipin Sharma <vipinsh@google.com>
Aside from the comment suggestion,
Reviewed-by: David Matlack <dmatlack@google.com>
> ---
> arch/x86/kvm/mmu/tdp_mmu.c | 22 ----------------------
> 1 file changed, 22 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> index e50e869bf879..0c031319e901 100644
> --- a/arch/x86/kvm/mmu/tdp_mmu.c
> +++ b/arch/x86/kvm/mmu/tdp_mmu.c
> @@ -345,24 +345,6 @@ static void handle_changed_spte_acc_track(u64 old_spte, u64 new_spte, int level)
> kvm_set_pfn_accessed(spte_to_pfn(old_spte));
> }
>
> -static void handle_changed_spte_dirty_log(struct kvm *kvm, int as_id, gfn_t gfn,
> - u64 old_spte, u64 new_spte, int level)
> -{
> - bool pfn_changed;
> - struct kvm_memory_slot *slot;
> -
> - if (level > PG_LEVEL_4K)
> - return;
> -
> - pfn_changed = spte_to_pfn(old_spte) != spte_to_pfn(new_spte);
> -
> - if ((!is_writable_pte(old_spte) || pfn_changed) &&
> - is_writable_pte(new_spte)) {
> - slot = __gfn_to_memslot(__kvm_memslots(kvm, as_id), gfn);
> - mark_page_dirty_in_slot(kvm, slot, gfn);
> - }
> -}
> -
> static void tdp_account_mmu_page(struct kvm *kvm, struct kvm_mmu_page *sp)
> {
> kvm_account_pgtable_pages((void *)sp->spt, +1);
> @@ -614,8 +596,6 @@ static void handle_changed_spte(struct kvm *kvm, int as_id, gfn_t gfn,
> __handle_changed_spte(kvm, as_id, gfn, old_spte, new_spte, level,
> shared);
> handle_changed_spte_acc_track(old_spte, new_spte, level);
> - handle_changed_spte_dirty_log(kvm, as_id, gfn, old_spte,
> - new_spte, level);
Please leave a comment somewhere in handle_changed_spte() to document
why mark_page_dirty_in_slot() is not needed to help future readers and
in case something changes in the future.
next prev parent reply other threads:[~2023-02-22 19:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-11 1:46 [Patch v3 0/7] Optimize clear dirty log Vipin Sharma
2023-02-11 1:46 ` [Patch v3 1/7] KVM: x86/mmu: Add a helper function to check if an SPTE needs atomic write Vipin Sharma
2023-02-11 1:46 ` [Patch v3 2/7] KVM: x86/mmu: Atomically clear SPTE dirty state in the clear-dirty-log flow Vipin Sharma
2023-02-15 21:12 ` David Matlack
2023-03-17 22:59 ` Sean Christopherson
2023-03-17 23:50 ` Vipin Sharma
2023-02-11 1:46 ` [Patch v3 3/7] KVM: x86/mmu: Remove "record_dirty_log" in __tdp_mmu_set_spte() Vipin Sharma
2023-02-15 21:10 ` David Matlack
2023-02-11 1:46 ` [Patch v3 4/7] KVM: x86/mmu: Optimize SPTE change for aging gfn range Vipin Sharma
2023-02-15 21:15 ` David Matlack
2023-03-21 0:51 ` Sean Christopherson
2023-02-11 1:46 ` [Patch v3 5/7] KVM: x86/mmu: Remove "record_acc_track" in __tdp_mmu_set_spte() Vipin Sharma
2023-02-22 19:31 ` David Matlack
2023-02-11 1:46 ` [Patch v3 6/7] KVM: x86/mmu: Remove handle_changed_spte_dirty_log() Vipin Sharma
2023-02-22 19:36 ` David Matlack [this message]
2023-02-11 1:46 ` [Patch v3 7/7] KVM: x86/mmu: Merge all handle_changed_pte* functions Vipin Sharma
2023-02-22 19:42 ` David Matlack
2023-03-17 22:51 ` Sean Christopherson
2023-03-17 23:48 ` Vipin Sharma
2023-03-17 22:57 ` [Patch v3 0/7] Optimize clear dirty log Sean Christopherson
2023-03-17 23:51 ` Vipin Sharma
2023-03-21 0:41 ` Sean Christopherson
2023-03-21 18:11 ` Vipin Sharma
2023-03-21 19:57 ` Sean Christopherson
2023-03-21 20:40 ` Sean Christopherson
2023-03-21 21:38 ` Sean Christopherson
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=Y/ZusFTMlUUWsWLF@google.com \
--to=dmatlack@google.com \
--cc=bgardon@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=vipinsh@google.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.