* [PATCH] KVM: Remove duplicated zero clear with dirty_bitmap buffer
@ 2024-06-13 12:54 Bibo Mao
2024-06-13 19:25 ` Christophe JAILLET
0 siblings, 1 reply; 5+ messages in thread
From: Bibo Mao @ 2024-06-13 12:54 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm, linux-kernel
Since dirty_bitmap pointer is allocated with function __vcalloc(),
there is __GFP_ZERO flag set in the implementation about this function
__vcalloc_noprof(). It is not necessary to clear dirty_bitmap buffer
with zero again.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
---
virt/kvm/kvm_main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 14841acb8b95..c7d4a041dcfa 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1669,9 +1669,6 @@ static int kvm_prepare_memory_region(struct kvm *kvm,
r = kvm_alloc_dirty_bitmap(new);
if (r)
return r;
-
- if (kvm_dirty_log_manual_protect_and_init_set(kvm))
- bitmap_set(new->dirty_bitmap, 0, new->npages);
}
}
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
--
2.39.3
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] KVM: Remove duplicated zero clear with dirty_bitmap buffer
2024-06-13 12:54 [PATCH] KVM: Remove duplicated zero clear with dirty_bitmap buffer Bibo Mao
@ 2024-06-13 19:25 ` Christophe JAILLET
2024-06-14 2:45 ` maobibo
0 siblings, 1 reply; 5+ messages in thread
From: Christophe JAILLET @ 2024-06-13 19:25 UTC (permalink / raw)
To: Bibo Mao, Paolo Bonzini; +Cc: kvm, linux-kernel
Le 13/06/2024 à 14:54, Bibo Mao a écrit :
> Since dirty_bitmap pointer is allocated with function __vcalloc(),
> there is __GFP_ZERO flag set in the implementation about this function
> __vcalloc_noprof(). It is not necessary to clear dirty_bitmap buffer
> with zero again.
>
> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
> ---
> virt/kvm/kvm_main.c | 3 ---
> 1 file changed, 3 deletions(-)
>
Hi,
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 14841acb8b95..c7d4a041dcfa 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1669,9 +1669,6 @@ static int kvm_prepare_memory_region(struct kvm *kvm,
> r = kvm_alloc_dirty_bitmap(new);
> if (r)
> return r;
> -
> - if (kvm_dirty_log_manual_protect_and_init_set(kvm))
> - bitmap_set(new->dirty_bitmap, 0, new->npages);
unless I miss something obvious, this does not clear anything, but set
all bits to 1.
0 is not for "write 0" (i.e. clear), but for "start at offset 0".
So all bits are set to 1 in this case.
CJ
> }
> }
>
>
> base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] KVM: Remove duplicated zero clear with dirty_bitmap buffer
2024-06-13 19:25 ` Christophe JAILLET
@ 2024-06-14 2:45 ` maobibo
2024-06-20 21:17 ` Paolo Bonzini
0 siblings, 1 reply; 5+ messages in thread
From: maobibo @ 2024-06-14 2:45 UTC (permalink / raw)
To: Christophe JAILLET, Paolo Bonzini; +Cc: kvm, linux-kernel
On 2024/6/14 上午3:25, Christophe JAILLET wrote:
> Le 13/06/2024 à 14:54, Bibo Mao a écrit :
>> Since dirty_bitmap pointer is allocated with function __vcalloc(),
>> there is __GFP_ZERO flag set in the implementation about this function
>> __vcalloc_noprof(). It is not necessary to clear dirty_bitmap buffer
>> with zero again.
>>
>> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
>> ---
>> virt/kvm/kvm_main.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>
> Hi,
>
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 14841acb8b95..c7d4a041dcfa 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -1669,9 +1669,6 @@ static int kvm_prepare_memory_region(struct kvm
>> *kvm,
>> r = kvm_alloc_dirty_bitmap(new);
>> if (r)
>> return r;
>> -
>> - if (kvm_dirty_log_manual_protect_and_init_set(kvm))
>> - bitmap_set(new->dirty_bitmap, 0, new->npages);
>
> unless I miss something obvious, this does not clear anything, but set
> all bits to 1.
>
> 0 is not for "write 0" (i.e. clear), but for "start at offset 0".
> So all bits are set to 1 in this case.
you are right, I had thought it is to write 0 :(
I do not know whether KVM_DIRTY_LOG_INITIALLY_SET should be enabled on
LoongArch. If it is set, write protection for second MMU will start one
by one in function kvm_arch_mmu_enable_log_dirty_pt_masked() when dirty
log is cleared if it is set, else write protection will start in
function kvm_arch_commit_memory_region() when flag of memslot is changed.
I do not see the obvious benefits between these two write protect
stages. Can anyone give me any hints?
Regards
Bibo Mao
>
> CJ
>
>> }
>> }
>>
>> base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] KVM: Remove duplicated zero clear with dirty_bitmap buffer
2024-06-14 2:45 ` maobibo
@ 2024-06-20 21:17 ` Paolo Bonzini
2024-06-21 1:59 ` maobibo
0 siblings, 1 reply; 5+ messages in thread
From: Paolo Bonzini @ 2024-06-20 21:17 UTC (permalink / raw)
To: maobibo, Christophe JAILLET; +Cc: kvm, linux-kernel
On 6/14/24 04:45, maobibo wrote:
> I do not know whether KVM_DIRTY_LOG_INITIALLY_SET should be enabled on
> LoongArch. If it is set, write protection for second MMU will start one
> by one in function kvm_arch_mmu_enable_log_dirty_pt_masked() when dirty
> log is cleared if it is set, else write protection will start in
> function kvm_arch_commit_memory_region() when flag of memslot is changed.
>
> I do not see the obvious benefits between these two write protect
> stages. Can anyone give me any hints?
The advantage is that you get (a lot) fewer vmexits to set the dirty
bitmap, and that write protection is not done in a single expensive
step. Instead it is done at the time that userspace first clears the
bits in the dirty bitmap. It provides much better performance.
Paolo
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] KVM: Remove duplicated zero clear with dirty_bitmap buffer
2024-06-20 21:17 ` Paolo Bonzini
@ 2024-06-21 1:59 ` maobibo
0 siblings, 0 replies; 5+ messages in thread
From: maobibo @ 2024-06-21 1:59 UTC (permalink / raw)
To: Paolo Bonzini, Christophe JAILLET; +Cc: kvm, linux-kernel
On 2024/6/21 上午5:17, Paolo Bonzini wrote:
> On 6/14/24 04:45, maobibo wrote:
>> I do not know whether KVM_DIRTY_LOG_INITIALLY_SET should be enabled on
>> LoongArch. If it is set, write protection for second MMU will start
>> one by one in function kvm_arch_mmu_enable_log_dirty_pt_masked() when
>> dirty log is cleared if it is set, else write protection will start in
>> function kvm_arch_commit_memory_region() when flag of memslot is changed.
>>
>> I do not see the obvious benefits between these two write protect
>> stages. Can anyone give me any hints?
>
> The advantage is that you get (a lot) fewer vmexits to set the dirty
> bitmap, and that write protection is not done in a single expensive
> step. Instead it is done at the time that userspace first clears the
> bits in the dirty bitmap. It provides much better performance.
Got it, thanks for the explanation .
Regards
Bibo Mao
>
> Paolo
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-06-21 1:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-13 12:54 [PATCH] KVM: Remove duplicated zero clear with dirty_bitmap buffer Bibo Mao
2024-06-13 19:25 ` Christophe JAILLET
2024-06-14 2:45 ` maobibo
2024-06-20 21:17 ` Paolo Bonzini
2024-06-21 1:59 ` maobibo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®