All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Xiao Guangrong <guangrong.xiao@gmail.com>,
	mtosatti@redhat.com, avi.kivity@gmail.com, rkrcmar@redhat.com
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	qemu-devel@nongnu.org, Xiao Guangrong <xiaoguangrong@tencent.com>
Subject: Re: [PATCH 0/7] KVM: MMU: fast write protect
Date: Wed, 3 May 2017 16:57:19 +0200	[thread overview]
Message-ID: <878cbc47-316c-d508-a5a3-22029dee2203@redhat.com> (raw)
In-Reply-To: <ff732c49-de24-eebd-ae8e-2de00281f211@gmail.com>



On 03/05/2017 16:50, Xiao Guangrong wrote:
> Furthermore, userspace has no knowledge about if PML is enable (it
> can be required from sysfs, but it is a good way in QEMU), so it is
> difficult for the usespace to know when to use write-protect-all.
> Maybe we can make KVM_CAP_X86_WRITE_PROTECT_ALL_MEM return false if
> PML is enabled?

Yes, that's a good idea.  Though it's a pity that, with PML, setting the
dirty bit will still do the massive walk of the rmap.  At least with
reset_dirty_pages it's done a little bit at a time.

>> Also, I wonder how the alternative write protection mechanism would
>> affect performance of the dirty page ring buffer patches.  You would do
>> the write protection of all memory at the end of
>> kvm_vm_ioctl_reset_dirty_pages.  You wouldn't even need a separate
>> ioctl, which is nice.  On the other hand, checkpoints would be more
>> frequent and most pages would be write-protected, so it would be more
>> expensive to rebuild the shadow page tables...
> 
> Yup, write-protect-all can improve reset_dirty_pages indeed, i will
> apply your idea after reset_dirty_pages is merged.
> 
> However, we still prefer to have a separate ioctl for write-protect-all
> which cooperates with KVM_GET_DIRTY_LOG to improve live migration that
> should not always depend on checkpoint. 

Ok, I plan to merge the dirty ring pages early in 4.13 development.

Paolo

WARNING: multiple messages have this Message-ID
From: Paolo Bonzini <pbonzini@redhat.com>
To: Xiao Guangrong <guangrong.xiao@gmail.com>,
	mtosatti@redhat.com, avi.kivity@gmail.com, rkrcmar@redhat.com
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	qemu-devel@nongnu.org, Xiao Guangrong <xiaoguangrong@tencent.com>
Subject: Re: [Qemu-devel] [PATCH 0/7] KVM: MMU: fast write protect
Date: Wed, 3 May 2017 16:57:19 +0200	[thread overview]
Message-ID: <878cbc47-316c-d508-a5a3-22029dee2203@redhat.com> (raw)
In-Reply-To: <ff732c49-de24-eebd-ae8e-2de00281f211@gmail.com>



On 03/05/2017 16:50, Xiao Guangrong wrote:
> Furthermore, userspace has no knowledge about if PML is enable (it
> can be required from sysfs, but it is a good way in QEMU), so it is
> difficult for the usespace to know when to use write-protect-all.
> Maybe we can make KVM_CAP_X86_WRITE_PROTECT_ALL_MEM return false if
> PML is enabled?

Yes, that's a good idea.  Though it's a pity that, with PML, setting the
dirty bit will still do the massive walk of the rmap.  At least with
reset_dirty_pages it's done a little bit at a time.

>> Also, I wonder how the alternative write protection mechanism would
>> affect performance of the dirty page ring buffer patches.  You would do
>> the write protection of all memory at the end of
>> kvm_vm_ioctl_reset_dirty_pages.  You wouldn't even need a separate
>> ioctl, which is nice.  On the other hand, checkpoints would be more
>> frequent and most pages would be write-protected, so it would be more
>> expensive to rebuild the shadow page tables...
> 
> Yup, write-protect-all can improve reset_dirty_pages indeed, i will
> apply your idea after reset_dirty_pages is merged.
> 
> However, we still prefer to have a separate ioctl for write-protect-all
> which cooperates with KVM_GET_DIRTY_LOG to improve live migration that
> should not always depend on checkpoint. 

Ok, I plan to merge the dirty ring pages early in 4.13 development.

Paolo

  reply	other threads:[~2017-05-03 14:57 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-03 10:52 guangrong.xiao
2017-05-03 10:52 ` [Qemu-devel] " guangrong.xiao
2017-05-03 10:52 ` [PATCH 1/7] KVM: MMU: correct the behavior of mmu_spte_update_no_track guangrong.xiao
2017-05-03 10:52   ` [Qemu-devel] " guangrong.xiao
2017-05-03 10:52 ` [PATCH 2/7] KVM: MMU: introduce possible_writable_spte_bitmap guangrong.xiao
2017-05-03 10:52   ` [Qemu-devel] " guangrong.xiao
2017-05-03 10:52 ` [PATCH 3/7] KVM: MMU: introduce kvm_mmu_write_protect_all_pages guangrong.xiao
2017-05-03 10:52   ` [Qemu-devel] " guangrong.xiao
2017-05-03 10:52 ` [PATCH 4/7] KVM: MMU: enable KVM_WRITE_PROTECT_ALL_MEM guangrong.xiao
2017-05-03 10:52   ` [Qemu-devel] " guangrong.xiao
2017-05-03 10:52 ` [PATCH 5/7] KVM: MMU: allow dirty log without write protect guangrong.xiao
2017-05-03 10:52   ` [Qemu-devel] " guangrong.xiao
2017-05-03 10:52 ` [PATCH 6/7] KVM: MMU: clarify fast_pf_fix_direct_spte guangrong.xiao
2017-05-03 10:52   ` [Qemu-devel] " guangrong.xiao
2017-05-03 10:52 ` [PATCH 7/7] KVM: MMU: stop using mmu_spte_get_lockless under mmu-lock guangrong.xiao
2017-05-03 10:52   ` [Qemu-devel] " guangrong.xiao
2017-05-03 12:28 ` [PATCH 0/7] KVM: MMU: fast write protect Paolo Bonzini
2017-05-03 12:28   ` [Qemu-devel] " Paolo Bonzini
2017-05-03 14:50   ` Xiao Guangrong
2017-05-03 14:50     ` [Qemu-devel] " Xiao Guangrong
2017-05-03 14:57     ` Paolo Bonzini [this message]
2017-05-03 14:57       ` Paolo Bonzini
2017-05-04  3:36       ` Xiao Guangrong
2017-05-04  3:36         ` [Qemu-devel] " Xiao Guangrong
2017-05-04  7:06         ` Paolo Bonzini
2017-05-04  7:06           ` [Qemu-devel] " Paolo Bonzini
2017-05-23  2:23           ` Xiao Guangrong
2017-05-23  2:23             ` [Qemu-devel] " Xiao Guangrong
2017-05-29 16:48             ` Paolo Bonzini
2017-05-29 16:48               ` [Qemu-devel] " Paolo Bonzini
2017-06-09  3:19               ` Xiao Guangrong
2017-06-09  3:19                 ` [Qemu-devel] " Xiao Guangrong
2017-06-05  7:36 ` Jay Zhou
2017-06-05  7:36   ` Jay Zhou
2017-06-06  2:56   ` Xiao Guangrong

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=878cbc47-316c-d508-a5a3-22029dee2203@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=avi.kivity@gmail.com \
    --cc=guangrong.xiao@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rkrcmar@redhat.com \
    --cc=xiaoguangrong@tencent.com \
    --subject='Re: [PATCH 0/7] KVM: MMU: fast write protect' \
    /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

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.