On 03/16/2012 05:44 PM, Takuya Yoshikawa wrote:
On Fri, 16 Mar 2012 16:28:56 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
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
On Mon, 19 Mar 2012 17:34:49 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
The current code is under the protection of s-rcu:
IIRC, it always holds s-rcu when write guest page and set dirty bit,
that mean the dirty page is logged either in the old dirty_bitmap or in the
current
On Fri, 16 Mar 2012 13:03:48 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
For my quickly review, mmu_lock can not protect everything, if the guest page
Yes and ...
is written out of the shadow page/ept table, dirty page will be lost.
No.
There is a example:
On 03/16/2012 02:55 PM, Takuya Yoshikawa wrote:
On Fri, 16 Mar 2012 13:03:48 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
For my quickly review, mmu_lock can not protect everything, if the guest page
Yes and ...
is written out of the shadow page/ept table, dirty page
On Fri, 16 Mar 2012 15:30:45 +0800
Xiao Guangrong xiaoguangr...@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
On Fri, 16 Mar 2012 16:28:56 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
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
On 03/01/2012 06:33 PM, Takuya Yoshikawa wrote:
+ spin_lock(kvm-mmu_lock);
- r = -ENOMEM;
- slots = kmemdup(kvm-memslots, sizeof(*kvm-memslots),
GFP_KERNEL);
- if (!slots)
- goto out;
+ for (i = 0; i n / sizeof(long);
We have seen some problems of the current implementation of
get_dirty_log() which uses synchronize_srcu_expedited() for updating
dirty bitmaps; e.g. it is noticeable that this sometimes gives us ms
order of latency when we use VGA displays.
Furthermore the recent discussion on the following
On 02/29/2012 09:49 AM, Takuya Yoshikawa wrote:
Avi Kivity a...@redhat.com wrote:
The key part of the implementation is the use of xchg() operation for
clearing dirty bits atomically. Since this allows us to update only
BITS_PER_LONG pages at once, we need to iterate over the dirty
Avi Kivity a...@redhat.com wrote:
Okay. But note you don't need the alignment check; simply allocate the
array aligned, and a multiple of 16 bytes, in the first place.
OKay, then we can do something like:
for each (x = bitmap[i], y = bitmap[i+1])
if (!x !y)
On 02/29/2012 12:16 PM, Takuya Yoshikawa wrote:
We may see partial display updates if we do not hold the mmu_lock during
xchg loop: it is possible that pages near the end of the framebuffer alone
gets updated sometimes - I noticed this problem when I fixed the TLB flush
issue.
I
Avi Kivity a...@redhat.com wrote:
We cannot get a complete snapshot without mmu_lock; if the guest faults on
the Nth page during xchg'ing i = 1, 2, ... then the i = N alone will
become newer.
Ah, so there is no data corruption (missed dirty bits), just the display
is updated
On 02/23/2012 01:35 PM, Takuya Yoshikawa wrote:
We have seen some problems of the current implementation of
get_dirty_log() which uses synchronize_srcu_expedited() for updating
dirty bitmaps; e.g. it is noticeable that this sometimes gives us ms
order of latency when we use VGA displays.
Avi Kivity a...@redhat.com wrote:
The key part of the implementation is the use of xchg() operation for
clearing dirty bits atomically. Since this allows us to update only
BITS_PER_LONG pages at once, we need to iterate over the dirty bitmap
until every dirty bit is cleared again for the
We have seen some problems of the current implementation of
get_dirty_log() which uses synchronize_srcu_expedited() for updating
dirty bitmaps; e.g. it is noticeable that this sometimes gives us ms
order of latency when we use VGA displays.
Furthermore the recent discussion on the following
15 matches
Mail list logo
