From: Sean Christopherson <seanjc@google.com>
To: Wei Wang <wei.w.wang@intel.com>
Cc: pbonzini@redhat.com, bgardon@google.com, dmatlack@google.com,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] KVM: x86/mmu: refactor kvm_tdp_mmu_map
Date: Wed, 2 Aug 2023 08:14:58 -0700 [thread overview]
Message-ID: <ZMpy8qvKTtAqaDWM@google.com> (raw)
In-Reply-To: <20230802142737.5572-1-wei.w.wang@intel.com>
On Wed, Aug 02, 2023, Wei Wang wrote:
> The implementation of kvm_tdp_mmu_map is a bit long. It essentially does
> three things:
> 1) adjust the leaf entry level (e.g. 4KB, 2MB or 1GB) to map according to
> the hugepage configurations;
> 2) map the nonleaf entries of the tdp page table; and
> 3) map the target leaf entry.
>
> Improve the readabiliy by moving the implementation of 2) above into a
> subfunction, kvm_tdp_mmu_map_nonleaf, and removing the unnecessary
> "goto"s. No functional changes intended.
Eh, I prefer the current code from a readability perspective. I like being able
to see the entire flow, and I especially like that this
if (iter.level == fault->goal_level)
goto map_target_level;
very clearly and explicitly captures that reaching the goal leavel means that it's
time to map the target level, whereas IMO this does not, in no small part because
seeing "continue" in a loop makes me think "continue the loop", not "continue on
to the next part of the page fault"
if (iter->level == fault->goal_level)
return RET_PF_CONTINUE;
And the existing code follows the patter of the other page fault paths, direct_map()
and FNAME(fetch). That doesn't necessarily mean that the existing pattern is
"better", but I personally place a lot of value on consistency.
> +/*
> + * Handle a TDP page fault (NPT/EPT violation/misconfiguration) by installing
> + * page tables and SPTEs to translate the faulting guest physical address.
> + */
> +int kvm_tdp_mmu_map(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
> +{
> + struct tdp_iter iter;
> + int ret;
> +
> + kvm_mmu_hugepage_adjust(vcpu, fault);
> +
> + trace_kvm_mmu_spte_requested(fault);
> +
> + rcu_read_lock();
> +
> + ret = kvm_tdp_mmu_map_nonleafs(vcpu, fault, &iter);
> + if (ret == RET_PF_CONTINUE)
> + ret = tdp_mmu_map_handle_target_level(vcpu, fault, &iter);
And I also don't like passing in an uninitialized tdp_iter, and then consuming
it too.
>
> -retry:
> rcu_read_unlock();
> return ret;
> }
> --
> 2.27.0
>
prev parent reply other threads:[~2023-08-02 15:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 14:27 [PATCH v1] KVM: x86/mmu: refactor kvm_tdp_mmu_map Wei Wang
2023-08-02 15:14 ` Sean Christopherson [this message]
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=ZMpy8qvKTtAqaDWM@google.com \
--to=seanjc@google.com \
--cc=bgardon@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=wei.w.wang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox