From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Zhuangyanying <ann.zhuangyanying@huawei.com>
Cc: liu.jinsong@huawei.com, kvm@vger.kernel.org,
wangxinxin.wang@huawei.com, xiaoguangrong@tencent.com,
qemu-devel@nongnu.org, arei.gonglei@huawei.com,
pbonzini@redhat.com
Subject: Re: [PATCH 1/4] KVM: MMU: correct the behavior of mmu_spte_update_no_track
Date: Thu, 17 Jan 2019 07:44:54 -0800 [thread overview]
Message-ID: <20190117154454.GA22169@linux.intel.com> (raw)
In-Reply-To: <1547733331-16140-2-git-send-email-ann.zhuangyanying@huawei.com>
On Thu, Jan 17, 2019 at 01:55:28PM +0000, Zhuangyanying wrote:
> From: Xiao Guangrong <xiaoguangrong@tencent.com>
>
> Current behavior of mmu_spte_update_no_track() does not match
> the name of _no_track() as actually the A/D bits are tracked
> and returned to the caller
Sentences should be terminated with periods.
> This patch introduces the real _no_track() function to update
"This patch" is redundant, e.g. simply state "Introduce ...".
> the spte regardless of A/D bits and rename the original function
> to _track()
The function also avoids __update_clear_spte_slow(), i.e. AFAICT it
doesn't guarantee volatile bits will be preserved. I assume this is
intentional, but it'd be nice to explain why this is ok.
> The _no_track() function will be used by later patches to update
> upper spte which need not care of A/D bits indeed
The _no_track() variant is already used (by mmu_spte_age()), I don't
see any point in having this blurb on the changelog, e.g. it led me
to incorrectly think an unused function was being introduced.
> Signed-off-by: Xiao Guangrong <xiaoguangrong@tencent.com>
> ---
> arch/x86/kvm/mmu.c | 25 ++++++++++++++++++++++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index ce770b4..eeb3bac 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -731,10 +731,29 @@ static void mmu_spte_set(u64 *sptep, u64 new_spte)
> }
>
> /*
> - * Update the SPTE (excluding the PFN), but do not track changes in its
> + * Update the SPTE (excluding the PFN) regardless of accessed/dirty
> + * status which is used to update the upper level spte.
> + */
> +static void mmu_spte_update_no_track(u64 *sptep, u64 new_spte)
> +{
> + u64 old_spte = *sptep;
No need to snapshot the old spte since it's not being returned.
> + WARN_ON(!is_shadow_present_pte(new_spte));
> +
> + if (!is_shadow_present_pte(old_spte)) {
> + mmu_spte_set(sptep, new_spte);
> + return;
Similarly, this is more complex than it needs to be, e.g. the function
can be simplified to:
static void mmu_spte_update_no_track(u64 *sptep, u64 new_spte)
{
WARN_ON(!is_shadow_present_pte(new_spte));
if (!is_shadow_present_pte(*sptep))
mmu_spte_set(sptep, new_spte);
else
__update_clear_spte_fast(sptep, new_spte);
}
> + }
> +
> + __update_clear_spte_fast(sptep, new_spte);
> +}
> +
> +/*
> + * Update the SPTE (excluding the PFN), the original value is
> + * returned, based on it, the caller can track changes of its
> * accessed/dirty status.
> */
> -static u64 mmu_spte_update_no_track(u64 *sptep, u64 new_spte)
> +static u64 mmu_spte_update_track(u64 *sptep, u64 new_spte)
> {
> u64 old_spte = *sptep;
>
> @@ -769,7 +788,7 @@ static u64 mmu_spte_update_no_track(u64 *sptep, u64 new_spte)
> static bool mmu_spte_update(u64 *sptep, u64 new_spte)
> {
> bool flush = false;
> - u64 old_spte = mmu_spte_update_no_track(sptep, new_spte);
> + u64 old_spte = mmu_spte_update_track(sptep, new_spte);
>
> if (!is_shadow_present_pte(old_spte))
> return false;
> --
> 1.8.3.1
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Zhuangyanying <ann.zhuangyanying@huawei.com>
Cc: xiaoguangrong@tencent.com, pbonzini@redhat.com,
arei.gonglei@huawei.com, qemu-devel@nongnu.org,
kvm@vger.kernel.org, wangxinxin.wang@huawei.com,
liu.jinsong@huawei.com
Subject: Re: [Qemu-devel] [PATCH 1/4] KVM: MMU: correct the behavior of mmu_spte_update_no_track
Date: Thu, 17 Jan 2019 07:44:54 -0800 [thread overview]
Message-ID: <20190117154454.GA22169@linux.intel.com> (raw)
In-Reply-To: <1547733331-16140-2-git-send-email-ann.zhuangyanying@huawei.com>
On Thu, Jan 17, 2019 at 01:55:28PM +0000, Zhuangyanying wrote:
> From: Xiao Guangrong <xiaoguangrong@tencent.com>
>
> Current behavior of mmu_spte_update_no_track() does not match
> the name of _no_track() as actually the A/D bits are tracked
> and returned to the caller
Sentences should be terminated with periods.
> This patch introduces the real _no_track() function to update
"This patch" is redundant, e.g. simply state "Introduce ...".
> the spte regardless of A/D bits and rename the original function
> to _track()
The function also avoids __update_clear_spte_slow(), i.e. AFAICT it
doesn't guarantee volatile bits will be preserved. I assume this is
intentional, but it'd be nice to explain why this is ok.
> The _no_track() function will be used by later patches to update
> upper spte which need not care of A/D bits indeed
The _no_track() variant is already used (by mmu_spte_age()), I don't
see any point in having this blurb on the changelog, e.g. it led me
to incorrectly think an unused function was being introduced.
> Signed-off-by: Xiao Guangrong <xiaoguangrong@tencent.com>
> ---
> arch/x86/kvm/mmu.c | 25 ++++++++++++++++++++++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index ce770b4..eeb3bac 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -731,10 +731,29 @@ static void mmu_spte_set(u64 *sptep, u64 new_spte)
> }
>
> /*
> - * Update the SPTE (excluding the PFN), but do not track changes in its
> + * Update the SPTE (excluding the PFN) regardless of accessed/dirty
> + * status which is used to update the upper level spte.
> + */
> +static void mmu_spte_update_no_track(u64 *sptep, u64 new_spte)
> +{
> + u64 old_spte = *sptep;
No need to snapshot the old spte since it's not being returned.
> + WARN_ON(!is_shadow_present_pte(new_spte));
> +
> + if (!is_shadow_present_pte(old_spte)) {
> + mmu_spte_set(sptep, new_spte);
> + return;
Similarly, this is more complex than it needs to be, e.g. the function
can be simplified to:
static void mmu_spte_update_no_track(u64 *sptep, u64 new_spte)
{
WARN_ON(!is_shadow_present_pte(new_spte));
if (!is_shadow_present_pte(*sptep))
mmu_spte_set(sptep, new_spte);
else
__update_clear_spte_fast(sptep, new_spte);
}
> + }
> +
> + __update_clear_spte_fast(sptep, new_spte);
> +}
> +
> +/*
> + * Update the SPTE (excluding the PFN), the original value is
> + * returned, based on it, the caller can track changes of its
> * accessed/dirty status.
> */
> -static u64 mmu_spte_update_no_track(u64 *sptep, u64 new_spte)
> +static u64 mmu_spte_update_track(u64 *sptep, u64 new_spte)
> {
> u64 old_spte = *sptep;
>
> @@ -769,7 +788,7 @@ static u64 mmu_spte_update_no_track(u64 *sptep, u64 new_spte)
> static bool mmu_spte_update(u64 *sptep, u64 new_spte)
> {
> bool flush = false;
> - u64 old_spte = mmu_spte_update_no_track(sptep, new_spte);
> + u64 old_spte = mmu_spte_update_track(sptep, new_spte);
>
> if (!is_shadow_present_pte(old_spte))
> return false;
> --
> 1.8.3.1
>
>
next prev parent reply other threads:[~2019-01-17 15:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-17 13:55 [PATCH 0/4] KVM: MMU: fast cleanup D bit based on fast write protect Zhuangyanying
2019-01-17 13:55 ` [Qemu-devel] " Zhuangyanying
2019-01-17 13:55 ` [PATCH 1/4] KVM: MMU: correct the behavior of mmu_spte_update_no_track Zhuangyanying
2019-01-17 13:55 ` [Qemu-devel] " Zhuangyanying
2019-01-17 15:44 ` Sean Christopherson [this message]
2019-01-17 15:44 ` Sean Christopherson
2019-01-17 13:55 ` [PATCH 2/4] KVM: MMU: introduce possible_writable_spte_bitmap Zhuangyanying
2019-01-17 13:55 ` [Qemu-devel] " Zhuangyanying
2019-01-17 15:55 ` Sean Christopherson
2019-01-17 15:55 ` [Qemu-devel] " Sean Christopherson
2019-01-17 13:55 ` [PATCH 3/4] KVM: MMU: introduce kvm_mmu_write_protect_all_pages Zhuangyanying
2019-01-17 13:55 ` [Qemu-devel] " Zhuangyanying
2019-01-17 16:09 ` Sean Christopherson
2019-01-17 16:09 ` [Qemu-devel] " Sean Christopherson
2019-01-17 13:55 ` [PATCH 4/4] KVM: MMU: fast cleanup D bit based on fast write protect Zhuangyanying
2019-01-17 13:55 ` [Qemu-devel] " Zhuangyanying
2019-01-17 16:32 ` Sean Christopherson
2019-01-17 16:32 ` [Qemu-devel] " Sean Christopherson
2019-01-21 6:37 ` Zhuangyanying
2019-01-21 6:37 ` [Qemu-devel] " Zhuangyanying
2019-01-22 15:17 ` Sean Christopherson
2019-01-22 15:17 ` [Qemu-devel] " Sean Christopherson
2019-01-23 18:38 ` Zhuangyanying
2019-01-23 18:38 ` [Qemu-devel] " Zhuangyanying
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=20190117154454.GA22169@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=ann.zhuangyanying@huawei.com \
--cc=arei.gonglei@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=liu.jinsong@huawei.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wangxinxin.wang@huawei.com \
--cc=xiaoguangrong@tencent.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.