From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
Cc: avi@redhat.com, mtosatti@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] KVM: Switch to srcu-less get_dirty_log()
Date: Fri, 16 Mar 2012 16:28:56 +0800 [thread overview]
Message-ID: <4F62F9C8.6090803@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120316165547.4df2abe4.yoshikawa.takuya@oss.ntt.co.jp>
On 03/16/2012 03:55 PM, Takuya Yoshikawa wrote:
> On Fri, 16 Mar 2012 15:30:45 +0800
> Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> wrote:
>
>>>> There is a example:
>>>>
>>>> CPU A CPU B
>>>> guest page is written by write-emulation
>>>>
>>>> hold mmu-lock and see dirty-bitmap
>>>> is not be changed, then migration is
>>>> completed.
>>>
>>> We do not allow this break.
>>>
>>
>>
>> Hmm? what can avoid this? Could you please point it out?
>
> Stopping the guest before actualy migrating the guest means VCPU threads
> must be back in the userspace at the moment, no?
>
> So when the final GET_DIRTY_LOG is being executed, thread A cannot be
> in KVM.
>
>> The problem is the guest page is written before dirty-bitmap is set,
>> we may log the dirty page in this window like above case...
>
> Exactly, but the next GET_DIRTY_LOG call can take that because, as I
> wrote above, at this time the GET_DIRTY_LOG must not be the final one.
>
Thanks for your explanation, maybe you are right, i do not know migration
much.
What i worried about is, you have changed the behaviour of GET_DIRTY_LOG,
in the current one, it can get all the dirty pages when it is called; after
your change, GET_DIRTY_LOG can get a empty dirty bitmap but dirty page exists.
Migration may work correctly depends on the final GET_DIRTY_LOG, in that time,
guest is stopped. But i am not sure whether other components using GET_DIRTY_LOG
are happy, e.g. frame-buffer.
next prev parent reply other threads:[~2012-03-16 8:38 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-01 10:30 [PATCH 0/4] KVM: srcu-less dirty logging -v2 Takuya Yoshikawa
2012-03-01 10:31 ` [PATCH 1/4] KVM: MMU: Split the main body of rmap_write_protect() off from others Takuya Yoshikawa
2012-03-12 7:39 ` Takuya Yoshikawa
2012-03-12 7:52 ` Takuya Yoshikawa
2012-03-01 10:32 ` [PATCH 2/4] KVM: Avoid checking huge page mappings in get_dirty_log() Takuya Yoshikawa
2012-03-02 2:56 ` Takuya Yoshikawa
2012-03-02 5:11 ` Takuya Yoshikawa
2012-03-12 18:04 ` Avi Kivity
2012-03-13 9:20 ` Takuya Yoshikawa
2012-03-13 10:12 ` Avi Kivity
2012-03-13 23:04 ` Marcelo Tosatti
2012-03-14 1:04 ` Takuya Yoshikawa
2012-03-14 5:34 ` Takuya Yoshikawa
2012-03-14 10:58 ` Marcelo Tosatti
2012-03-01 10:33 ` [PATCH 3/4] KVM: Switch to srcu-less get_dirty_log() Takuya Yoshikawa
2012-03-03 5:21 ` [PATCH 3/4 changelog-v2] " Takuya Yoshikawa
2012-03-06 11:15 ` Marcelo Tosatti
2012-03-06 14:43 ` Takuya Yoshikawa
2012-03-06 15:01 ` Marcelo Tosatti
2012-03-06 15:23 ` Takuya Yoshikawa
2012-03-06 15:28 ` Marcelo Tosatti
2012-03-07 8:07 ` Takuya Yoshikawa
2012-03-07 23:25 ` Marcelo Tosatti
2012-03-08 1:35 ` Takuya Yoshikawa
2012-03-09 0:08 ` Marcelo Tosatti
2012-03-12 12:05 ` Avi Kivity
2012-03-07 8:18 ` Takuya Yoshikawa
2012-03-07 23:20 ` Marcelo Tosatti
2012-03-16 5:03 ` [PATCH 3/4] " Xiao Guangrong
2012-03-16 6:55 ` Takuya Yoshikawa
2012-03-16 7:30 ` Xiao Guangrong
2012-03-16 7:55 ` Takuya Yoshikawa
2012-03-16 8:28 ` Xiao Guangrong [this message]
2012-03-16 9:44 ` Takuya Yoshikawa
2012-03-19 9:34 ` Xiao Guangrong
2012-03-19 10:15 ` Takuya Yoshikawa
2012-03-01 10:34 ` [PATCH 4/4] KVM: Remove unused dirty_bitmap_head and nr_dirty_pages Takuya Yoshikawa
2012-03-03 5:12 ` [PATCH 0/4] KVM: srcu-less dirty logging -v2 Takuya Yoshikawa
2012-03-20 14:43 ` Avi Kivity
-- strict thread matches above, loose matches on Subject: below --
2012-02-23 11:33 [PATCH 0/4] KVM: srcu-less dirty logging Takuya Yoshikawa
2012-02-23 11:35 ` [PATCH 3/4] KVM: Switch to srcu-less get_dirty_log() Takuya Yoshikawa
2012-02-28 11:46 ` Avi Kivity
2012-02-29 7:49 ` Takuya Yoshikawa
2012-02-29 9:25 ` Avi Kivity
2012-02-29 10:16 ` Takuya Yoshikawa
2012-02-29 12:27 ` Avi Kivity
2012-02-29 14:18 ` Takuya Yoshikawa
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=4F62F9C8.6090803@linux.vnet.ibm.com \
--to=xiaoguangrong@linux.vnet.ibm.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=yoshikawa.takuya@oss.ntt.co.jp \
/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.