Mohammed Gamal wrote:
> On Tue, Apr 20, 2010 at 8:36 PM, jvrao wrote:
>
> ... ...
>
>>> This'd be something interesting to do. I wonder if that would fit in
>>> the GSoC timeframe, or whether it'd be a little too short. So how long
>>> you'd estimate something like that would take?
>> I think i
21.04.2010 05:58, Ryan Harper wrote:
* Leszek Urbanski [2010-04-20 17:37]:
Hi,
this is a follow-up to bug 2989366:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2989366&group_id=180599
after extensive debugging with the guys on #kvm it turns out that the leak is
in the qemu-kv
Hi, Alex, Avi, Marcelo
I would like to ask you about the commit:
c8240bd6f0b4b1b21ffd36dd44114d05c7afe0c0 "Use Little Endian for Dirty Bitmap"
I pasted a snipet below!
I am now confused by the Alex's comment to my recent patch:
"change mark_page_dirty() to handle endian issues explicitly"
in
Introduce RAMSaveIO to use writev for saving ram blocks, and modifies
ram_save_block() and ram_save_remaining() to use
cpu_physical_memory_get_dirty_range() to check multiple dirty and
non-dirty pages at once.
Signed-off-by: Yoshiaki Tamura
Signed-off-by: OHMURA Kei
---
vl.c | 221
Signed-off-by: Yoshiaki Tamura
---
configure |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index 046c591..f0682d4 100755
--- a/configure
+++ b/configure
@@ -298,6 +298,7 @@ bsd_user="no"
guest_base=""
uname_release=""
io_thread="no"
+ft_m
Currently FdMigrationState doesn't support writev() and read().
writev() is introduced to send data efficiently, and read() is
necessary to get response from the other side.
Signed-off-by: Yoshiaki Tamura
---
migration-tcp.c | 20
migration.c | 27 +++
Currently buf size is fixed at 32KB. It would be useful if it could
be flexible.
Signed-off-by: Yoshiaki Tamura
---
hw/hw.h |2 ++
savevm.c | 26 +-
2 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/hw/hw.h b/hw/hw.h
index 05131a0..fc9ed29 100644
---
When ft_mode is on, migrate_fd_put_ready() would open ft_transaction
file and turn on event_tap. To end or cancel ft_transaction, ft_mode
and event_tap is turned off.
Signed-off-by: Yoshiaki Tamura
---
migration.c | 36 +---
1 files changed, 33 insertions(+), 3
It checks the first row and puts dirty addr in the array. If the
first row is empty, it skips to the first non-dirty row or the end
addr, and put the length in the first entry of the array.
Signed-off-by: Yoshiaki Tamura
Signed-off-by: OHMURA Kei
---
cpu-all.h |4 +++
exec.c| 67
Hi all,
We have been implementing the prototype of Kemari for KVM, and we're sending
this message to share what we have now and TODO lists. Hopefully, we would like
to get early feedback to keep us in the right direction. Although advanced
approaches in the TODO lists are fascinating, we would l
Modifies kvm_get_dirty_pages_log_range to use
cpu_physical_memory_set_dirty_range() to update the row of the
bit-based phys_ram_dirty bitmap at once.
Signed-off-by: Yoshiaki Tamura
Signed-off-by: OHMURA Kei
---
qemu-kvm.c | 19 +++
1 files changed, 7 insertions(+), 12 deletion
Replaces byte-based phys_ram_dirty bitmap with four (MASTER, VGA,
CODE, MIGRATION) bit-based phys_ram_dirty bitmap. On allocation, it
sets all bits in the bitmap. It uses ffs() to convert DIRTY_FLAG to
DIRTY_IDX.
Modifies wrapper functions for byte-based phys_ram_dirty bitmap to
bit-based phys_r
When -k option is set to migrate command, it will turn on ft_mode to
start FT migration mode (Kemari).
Signed-off-by: Yoshiaki Tamura
---
migration.c |3 +++
qemu-monitor.hx |7 ---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/migration.c b/migration.c
index c81
do_event_tap() is inserted to functions which actually fire outputs.
By synchronizing VMs before outputs are fired, we can failover to the
receiver upon failure. To save VM continuously, comment out assert()
on cpu_single_env temporally.
Signed-off-by: Yoshiaki Tamura
---
hw/virtio-blk.c |2
QEMUFile currently doesn't support writev(). For sending multiple
data, such as pages, using writev() should be more efficient.
Signed-off-by: Yoshiaki Tamura
---
buffered_file.c |2 +-
hw/hw.h | 16
savevm.c| 43 +
This code implements VM transaction protocol. Like buffered_file, it
sits between savevm and migration layer. With this architecture, VM
transaction protocol is implemented mostly independent from other
existing code.
Signed-off-by: Yoshiaki Tamura
Signed-off-by: OHMURA Kei
---
Makefile.objs
To utilize ft_transaction function, savevm needs interfaces to be
exported.
Signed-off-by: Yoshiaki Tamura
---
hw/hw.h |5 +
savevm.c | 41 +
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/hw/hw.h b/hw/hw.h
index 10e6dda..fcee66
Signed-off-by: Yoshiaki Tamura
---
cutils.c | 12
qemu-common.h |2 ++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/cutils.c b/cutils.c
index be99b21..1d35590 100644
--- a/cutils.c
+++ b/cutils.c
@@ -238,3 +238,15 @@ void qemu_iovec_from_buffer(QEMUIOVec
Signed-off-by: Yoshiaki Tamura
---
osdep.c | 13 +
qemu-char.c | 25 -
qemu_socket.h |4
3 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/osdep.c b/osdep.c
index 3bab79a..63444e7 100644
--- a/osdep.c
+++ b/osdep.c
@@ -201,6 +
Signed-off-by: Yoshiaki Tamura
---
migration-exec.c |2 +-
migration-fd.c |2 +-
migration-tcp.c |2 +-
migration-unix.c |2 +-
savevm.c | 25 ++---
sysemu.h |2 +-
6 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/migrat
event_tap controls when to start ft transaction. do_event_tap()
should be instered to the device emulators.
ft_tranx_ready() kicks the transaction.
Signed-off-by: Yoshiaki Tamura
---
migration.c | 77 +
migration.h |2 +
qemu-com
For fool proof purpose, qemu_put_vector_parepare should be called
before qemu_put_vector. Then, if qemu_put_* functions except this is
called after qemu_put_vector_prepare, program will abort().
Signed-off-by: Yoshiaki Tamura
---
hw/hw.h |2 ++
savevm.c | 53 +
Make a 32bit entry after QEMU_VM_FILE_VERSION to recognize whether the
transfered data is QEMU_VM_FT_MODE or QEMU_VM_LIVE_MIGRATION_MODE.
Signed-off-by: Yoshiaki Tamura
---
savevm.c | 76 -
sysemu.h |1 +
2 files changed, 75 inser
When ft_mode is set in the header, tcp_accept_incoming_migration()
receives ft_transaction iteratively. We also need a hack no to close
fd before moving to ft_transaction mode, so that we can reuse the fd
for it.
Signed-off-by: Yoshiaki Tamura
---
migration-tcp.c | 36
On 04/12/2010 02:08 AM, Avi Kivity wrote:
>> +#define __set_bit_user_asm(nr, addr, err, errret)\
>> +asm volatile("1:bts %1,%2\n"\
>> + "2:\n"\
>> + ".section .fixup,\"ax\"\n"\
>> + "3:
On Tue, Apr 20, 2010 at 8:36 PM, jvrao wrote:
... ...
>> This'd be something interesting to do. I wonder if that would fit in
>> the GSoC timeframe, or whether it'd be a little too short. So how long
>> you'd estimate something like that would take?
>
> I think it would take ~3PM for someone wi
* Leszek Urbanski [2010-04-20 17:37]:
> Hi,
>
> this is a follow-up to bug 2989366:
>
> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2989366&group_id=180599
>
> after extensive debugging with the guys on #kvm it turns out that the leak is
> in the qemu-kvm userland process, in v
On 04/20/2010 09:42 AM, Jeremy Fitzhardinge wrote:
On 04/20/2010 11:54 AM, Avi Kivity wrote:
On 04/20/2010 09:23 PM, Jeremy Fitzhardinge wrote:
On 04/20/2010 02:31 AM, Avi Kivity wrote:
btw, do you want this code in pvclock.c, or shall we keep it kvmclock
specific?
On 04/19/2010 11:39 PM, Avi Kivity wrote:
On 04/19/2010 09:35 PM, Zachary Amsden wrote:
Sockets and boards too? (IOW, how reliable is TSC_RELIABLE)?
Not sure, IIRC we clear that when the TSC sync test fails, eg when we
mark the tsc clocksource unusable.
Worrying. By the time we detect this
On 04/19/2010 11:35 PM, Avi Kivity wrote:
On 04/20/2010 04:57 AM, Marcelo Tosatti wrote:
Marcelo can probably confirm it, but he has a nehalem with an
appearently
very good tsc source. Even this machine warps.
It stops warping if we only write pvclock data structure once and
forget it,
(wh
On 21.04.2010, at 00:29, Leszek Urbanski wrote:
> Hi,
>
> this is a follow-up to bug 2989366:
>
> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2989366&group_id=180599
>
> after extensive debugging with the guys on #kvm it turns out that the leak is
> in the qemu-kvm userland pr
Hi,
this is a follow-up to bug 2989366:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2989366&group_id=180599
after extensive debugging with the guys on #kvm it turns out that the leak is
in the qemu-kvm userland process, in virtio-blk.
A summary of my setup is described in the b
On Tue, Apr 20, 2010 at 02:29:29PM +0800, Lai Jiangshan wrote:
> Marcelo Tosatti wrote:
> > On Mon, Apr 19, 2010 at 01:08:29PM +0300, Avi Kivity wrote:
> >> On 04/19/2010 12:58 PM, Lai Jiangshan wrote:
> >>> Applied the patch I just sent and let CONFIG_PROVE_RCU=y,
> >>> we can got the following dm
Hi Marcelo,
Thanks for the patch.
I put it into my kernel source tree and tested the freshly build kernel in my
testing environment. The problem is now - almost - gone. The only suspicious
message (ONE occurrence immediate after starting the Server 2008 R2 VM) in
syslog is now:
BUG: scheduling
On Mon, Apr 19, 2010 at 05:41:23PM +0800, Lai Jiangshan wrote:
> The RCU/SRCU API have already changed for proving RCU usage.
>
> I got the following dmesg when PROVE_RCU=y because we used incorrect API.
> This patch coverts rcu_deference() to srcu_dereference() or family API.
>
> ===
On 04/20/2010 11:54 AM, Avi Kivity wrote:
> On 04/20/2010 09:23 PM, Jeremy Fitzhardinge wrote:
>> On 04/20/2010 02:31 AM, Avi Kivity wrote:
>>
>>> btw, do you want this code in pvclock.c, or shall we keep it kvmclock
>>> specific?
>>>
>> I think its a pvclock-level fix. I'd been hoping to
On 04/20/2010 09:23 PM, Jeremy Fitzhardinge wrote:
On 04/20/2010 02:31 AM, Avi Kivity wrote:
btw, do you want this code in pvclock.c, or shall we keep it kvmclock
specific?
I think its a pvclock-level fix. I'd been hoping to avoid having
something like this, but I think its ultimatel
On Tue, Apr 20, 2010 at 10:09:57AM +0800, Lai Jiangshan wrote:
> Paul E. McKenney wrote:
> > On Mon, Apr 19, 2010 at 12:49:04PM +0300, Avi Kivity wrote:
> >> On 04/19/2010 12:41 PM, Lai Jiangshan wrote:
> >>> The RCU/SRCU API have already changed for proving RCU usage.
> >>>
> >>> I got the followi
Mohammed Gamal wrote:
> On Tue, Apr 20, 2010 at 12:54 AM, jvrao wrote:
>> Mohammed Gamal wrote:
>>> On Tue, Apr 13, 2010 at 9:08 PM, jvrao wrote:
jvrao wrote:
> Alexander Graf wrote:
>> On 12.04.2010, at 13:58, Jamie Lokier wrote:
>>
>>> Mohammed Gamal wrote:
On Mon,
On 04/20/2010 02:31 AM, Avi Kivity wrote:
> btw, do you want this code in pvclock.c, or shall we keep it kvmclock
> specific?
I think its a pvclock-level fix. I'd been hoping to avoid having
something like this, but I think its ultimately necessary.
J
--
To unsubscribe from this list: send t
The assigned device interrupt work handler calls kvm_set_irq, which
can sleep, for example, waiting for the ioapic mutex, from irq disabled
section.
https://bugzilla.kernel.org/show_bug.cgi?id=15725
Fix by dropping assigned_dev_lock (and re-enabling interrupts)
before invoking kvm_set_irq for th
On 04/20/2010 03:59 PM, Glauber Costa wrote:
Might be due to NMIs or SMIs interrupting the rdtsc(); ktime_get()
operation which establishes the timeline. We could limit it by
having a loop doing rdtsc(); ktime_get(); rdtsc(); and checking for
some bound, but it isn't worthwhile (and will break
call agenda
- send out a bit earlier
- cancel call if no agenda
0.12.4
- expect when Anthony is back online
KVM Forum 2010
- call for papers is out...send in your proposals!
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
Mor
> Does this mean that virtio-blk supports all three combinations?
>
>1. FLUSH that isn't a barrier
>2. FLUSH that is also a barrier
>3. Barrier that is not a flush
>
> 1 is good for fsync-like operations;
> 2 is good for journalling-like ordered operations.
> 3 sounds like it doesn't
On Tue, Apr 20, 2010 at 12:35:19PM +0300, Avi Kivity wrote:
> On 04/20/2010 04:57 AM, Marcelo Tosatti wrote:
> >
> >>Marcelo can probably confirm it, but he has a nehalem with an appearently
> >>very good tsc source. Even this machine warps.
> >>
> >>It stops warping if we only write pvclock data s
Fernando, sorry I have changed some part of this series and forgot to
change your Signed-off-by to Cc for some parts.
So please give me any comments(objections) as replies to this mail thread.
Thanks,
Takuya
(2010/04/20 19:53), Takuya Yoshikawa wrote:
Hi, this is the v2 of the "moving dirt
(2010/04/20 20:33), Alexander Graf wrote:
-#define KVM_API_VERSION 12
+#define KVM_API_VERSION 13
Is there a way to keep both interfaces around for some time at least? I'd
prefer the API version not to change if not _really_ necessary.
To enable the new dirty mapping you could for example us
On 20.04.2010, at 13:33, Takuya Yoshikawa wrote:
> (2010/04/20 20:15), Alexander Graf wrote:
>>
>> On 20.04.2010, at 13:03, Takuya Yoshikawa wrote:
>>
>>> We can now export the addree of the bitmap created by do_mmap()
>>> to user space. For the sake of this, we introduce a new API:
>>>
>>> K
(2010/04/20 20:15), Alexander Graf wrote:
On 20.04.2010, at 13:03, Takuya Yoshikawa wrote:
We can now export the addree of the bitmap created by do_mmap()
to user space. For the sake of this, we introduce a new API:
KVM_SWITCH_DIRTY_LOG: application can use this to trigger the
switch of t
(2010/04/20 20:10), Alexander Graf wrote:
On 20.04.2010, at 13:02, Takuya Yoshikawa wrote:
We move dirty bitmaps to user space.
- Allocation and destruction: we use do_mmap() and do_munmap().
The new bitmap space is twice longer than the original one and we
use the additional space for
(2010/04/20 20:00), Alexander Graf wrote:
On 20.04.2010, at 13:00, Takuya Yoshikawa wrote:
We are now using generic___set_le_bit() to make dirty bitmaps le.
Though this works well, we have to replace __set_bit() to appropriate
uaccess function to move dirty bitmaps to user space. So this patch
On 20.04.2010, at 13:03, Takuya Yoshikawa wrote:
> We can now export the addree of the bitmap created by do_mmap()
> to user space. For the sake of this, we introduce a new API:
>
> KVM_SWITCH_DIRTY_LOG: application can use this to trigger the
> switch of the bitmaps and get the address of the
On 20.04.2010, at 13:02, Takuya Yoshikawa wrote:
> We move dirty bitmaps to user space.
>
> - Allocation and destruction: we use do_mmap() and do_munmap().
> The new bitmap space is twice longer than the original one and we
> use the additional space for double buffering: this makes it
> p
(2010/04/20 19:54), Alexander Graf wrote:
On 20.04.2010, at 12:53, Takuya Yoshikawa wrote:
Hi, this is the v2 of the "moving dirty gitmaps to user space!"
By this patch, I think everything we need becomes clear.
So we want to step forward to be ready for the final version in the
near future:
On 20.04.2010, at 13:00, Takuya Yoshikawa wrote:
> We are now using generic___set_le_bit() to make dirty bitmaps le.
> Though this works well, we have to replace __set_bit() to appropriate
> uaccess function to move dirty bitmaps to user space. So this patch
> splits generic___set_le_bit() and pr
We can now export the addree of the bitmap created by do_mmap()
to user space. For the sake of this, we introduce a new API:
KVM_SWITCH_DIRTY_LOG: application can use this to trigger the
switch of the bitmaps and get the address of the bitmap which
has been used until now. This reduces the c
We move dirty bitmaps to user space.
- Allocation and destruction: we use do_mmap() and do_munmap().
The new bitmap space is twice longer than the original one and we
use the additional space for double buffering: this makes it
possible to update the active bitmap while letting the user
We are now using generic___set_le_bit() to make dirty bitmaps le.
Though this works well, we have to replace __set_bit() to appropriate
uaccess function to move dirty bitmaps to user space. So this patch
splits generic___set_le_bit() and prepares for that.
Signed-off-by: Takuya Yoshikawa
Signed-o
We will replace copy_to_user() to copy_in_user() when we move
the dirty bitmaps to user space.
But sadly, we have copy_in_user() only for 64 bits architectures.
So this function should work as a wrapper to hide ifdefs from outside.
Once we get copy_in_user() for 32 bits architectures, we can remov
On 20.04.2010, at 12:53, Takuya Yoshikawa wrote:
> Hi, this is the v2 of the "moving dirty gitmaps to user space!"
>
> By this patch, I think everything we need becomes clear.
> So we want to step forward to be ready for the final version in the
> near future: of course, this is dependent on x86
We will change the vmalloc() and vfree() to do_mmap() and do_munmap()
later. This patch makes it easy and cleanup the code.
Signed-off-by: Takuya Yoshikawa
Signed-off-by: Fernando Luis Vazquez Cao
---
virt/kvm/kvm_main.c | 27 ---
1 files changed, 20 insertions(+), 7 d
This patch introduces is_dirty member for each memory slot.
Using this member, we remove the dirty bitmap scan which is
done in the get_dirty_log function.
This also helps us when we move the dirty bitmaps to user space:
we don't have any good way to check the bitmaps in user space with
low cost,
Hi, this is the v2 of the "moving dirty gitmaps to user space!"
By this patch, I think everything we need becomes clear.
So we want to step forward to be ready for the final version in the
near future: of course, this is dependent on x86 and ppc asm issues.
BTW, by whom I can get ACK for ppc and
On 04/19/2010 09:35 PM, Zachary Amsden wrote:
Sockets and boards too? (IOW, how reliable is TSC_RELIABLE)?
Not sure, IIRC we clear that when the TSC sync test fails, eg when we
mark the tsc clocksource unusable.
Worrying. By the time we detect this the guest may already have
gotten confused
On 04/20/2010 06:32 AM, Sheng Yang wrote:
On Monday 19 April 2010 16:25:17 Avi Kivity wrote:
On 04/17/2010 09:12 PM, Avi Kivity wrote:
I think you were right the first time around.
Re-reading again (esp. the part about treatment of indirect NMI
vmexits), I think this was wron
On 04/20/2010 04:57 AM, Marcelo Tosatti wrote:
Marcelo can probably confirm it, but he has a nehalem with an appearently
very good tsc source. Even this machine warps.
It stops warping if we only write pvclock data structure once and forget it,
(which only updated tsc_timestamp once), accordin
On 04/19/2010 07:18 PM, Jeremy Fitzhardinge wrote:
On 04/19/2010 07:46 AM, Peter Zijlstra wrote:
What avi says! :-)
On a 32bit machine a 64bit read are two 32bit reads, so
last = last_value;
becomes:
last.high = last_value.high;
last.low = last_vlue.low;
(or the reverse of cou
On 04/19/2010 05:50 PM, Glauber Costa wrote:
On Sat, Apr 17, 2010 at 09:58:26PM +0300, Avi Kivity wrote:
On 04/15/2010 09:37 PM, Glauber Costa wrote:
Since we're changing the msrs kvmclock uses, we have to communicate
that to the guest, through cpuid. We can add a new KVM_CAP to the
h
68 matches
Mail list logo
