Kernel KVM virtualization development
 help / color / mirror / Atom feed
* [PATCH] KVM: x86/mmu: fix counting of rmap entries in pte_list_add
@ 2020-09-01  9:26 Li RongQing
  0 siblings, 0 replies; 4+ messages in thread
From: Li RongQing @ 2020-09-01  9:26 UTC (permalink / raw)
  To: x86, kvm

counting of rmap entries was missed when desc->sptes is full
and desc->more is false

Cc: <stable@vger.kernel.org>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
 arch/x86/kvm/mmu/mmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index a5d0207e7189..8ffa4e40b650 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -1280,6 +1280,7 @@ static int pte_list_add(struct kvm_vcpu *vcpu, u64 *spte,
 		if (desc->sptes[PTE_LIST_EXT-1]) {
 			desc->more = mmu_alloc_pte_list_desc(vcpu);
 			desc = desc->more;
+			count += PTE_LIST_EXT;
 		}
 		for (i = 0; desc->sptes[i]; ++i)
 			++count;
-- 
2.16.2


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [PATCH] KVM: x86/mmu: fix counting of rmap entries in pte_list_add
@ 2020-09-21 10:29 Li RongQing
  2020-09-21 19:40 ` Sean Christopherson
  0 siblings, 1 reply; 4+ messages in thread
From: Li RongQing @ 2020-09-21 10:29 UTC (permalink / raw)
  To: lirongqing, kvm, x86

counting of rmap entries was missed when desc->sptes is full
and desc->more is NULL

Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
 arch/x86/kvm/mmu/mmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index a5d0207e7189..8ffa4e40b650 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -1280,6 +1280,7 @@ static int pte_list_add(struct kvm_vcpu *vcpu, u64 *spte,
 		if (desc->sptes[PTE_LIST_EXT-1]) {
 			desc->more = mmu_alloc_pte_list_desc(vcpu);
 			desc = desc->more;
+			count += PTE_LIST_EXT;
 		}
 		for (i = 0; desc->sptes[i]; ++i)
 			++count;
-- 
2.16.2


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] KVM: x86/mmu: fix counting of rmap entries in pte_list_add
  2020-09-21 10:29 [PATCH] KVM: x86/mmu: fix counting of rmap entries in pte_list_add Li RongQing
@ 2020-09-21 19:40 ` Sean Christopherson
  2020-09-22  5:23   ` Li,Rongqing
  0 siblings, 1 reply; 4+ messages in thread
From: Sean Christopherson @ 2020-09-21 19:40 UTC (permalink / raw)
  To: Li RongQing; +Cc: kvm, x86

On Mon, Sep 21, 2020 at 06:29:26PM +0800, Li RongQing wrote:
> counting of rmap entries was missed when desc->sptes is full
> and desc->more is NULL
> 
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
>  arch/x86/kvm/mmu/mmu.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index a5d0207e7189..8ffa4e40b650 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -1280,6 +1280,7 @@ static int pte_list_add(struct kvm_vcpu *vcpu, u64 *spte,
>  		if (desc->sptes[PTE_LIST_EXT-1]) {
>  			desc->more = mmu_alloc_pte_list_desc(vcpu);
>  			desc = desc->more;
> +			count += PTE_LIST_EXT;

Kind of a nit, but what do you think about merging the two PTE_LIST_EXT-1
check?  For me, that makes the resulting code more obviously correct, and it
might be slightly more performant as it avoids the extra comparison, though
the compiler may be smart enough to optimize that away without help.

		while (desc->sptes[PTE_LIST_EXIT-1]) {
			count += PTE_LIST_EXT;

			if (!desc->more) {
				desc->more = mmu_alloc_pte_list_desc(vcpu);
				desc = desc->more;
				break;
			}
			desc = desc->more;
		}

>  		}
>  		for (i = 0; desc->sptes[i]; ++i)
>  			++count;
> -- 
> 2.16.2
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [PATCH] KVM: x86/mmu: fix counting of rmap entries in pte_list_add
  2020-09-21 19:40 ` Sean Christopherson
@ 2020-09-22  5:23   ` Li,Rongqing
  0 siblings, 0 replies; 4+ messages in thread
From: Li,Rongqing @ 2020-09-22  5:23 UTC (permalink / raw)
  To: Sean Christopherson; +Cc: kvm@vger.kernel.org, x86@kernel.org



> -----Original Message-----
> From: Sean Christopherson [mailto:sean.j.christopherson@intel.com]
> Sent: Tuesday, September 22, 2020 3:41 AM
> To: Li,Rongqing <lirongqing@baidu.com>
> Cc: kvm@vger.kernel.org; x86@kernel.org
> Subject: Re: [PATCH] KVM: x86/mmu: fix counting of rmap entries in
> pte_list_add
> 
> On Mon, Sep 21, 2020 at 06:29:26PM +0800, Li RongQing wrote:
> > counting of rmap entries was missed when desc->sptes is full and
> > desc->more is NULL
> >
> > Signed-off-by: Li RongQing <lirongqing@baidu.com>
> > ---
> >  arch/x86/kvm/mmu/mmu.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index
> > a5d0207e7189..8ffa4e40b650 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -1280,6 +1280,7 @@ static int pte_list_add(struct kvm_vcpu *vcpu, u64
> *spte,
> >  		if (desc->sptes[PTE_LIST_EXT-1]) {
> >  			desc->more = mmu_alloc_pte_list_desc(vcpu);
> >  			desc = desc->more;
> > +			count += PTE_LIST_EXT;
> 
> Kind of a nit, but what do you think about merging the two PTE_LIST_EXT-1
> check?  For me, that makes the resulting code more obviously correct, and it
> might be slightly more performant as it avoids the extra comparison, though
> the compiler may be smart enough to optimize that away without help.
> 
> 		while (desc->sptes[PTE_LIST_EXIT-1]) {
> 			count += PTE_LIST_EXT;
> 
> 			if (!desc->more) {
> 				desc->more = mmu_alloc_pte_list_desc(vcpu);
> 				desc = desc->more;
> 				break;
> 			}
> 			desc = desc->more;
> 		}
> 

Ok, I will send V2 as you suggested

Thanks

-Li

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-09-22  5:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-21 10:29 [PATCH] KVM: x86/mmu: fix counting of rmap entries in pte_list_add Li RongQing
2020-09-21 19:40 ` Sean Christopherson
2020-09-22  5:23   ` Li,Rongqing
  -- strict thread matches above, loose matches on Subject: below --
2020-09-01  9:26 Li RongQing

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox