- 11 Mar, 2013 2 commits
-
-
Paolo Bonzini authored
Only the migration_bitmap_sync() call needs the iothread lock. Reviewed-by:
Orit Wasserman <owasserm@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Paolo Bonzini authored
This makes it possible to do blocking writes directly to the socket, with no buffer in the middle. For RAM, only the migration_bitmap_sync() call needs the iothread lock. For block migration, it is needed by the block layer (including bdrv_drain_all and dirty bitmap access), but because some code is shared between iterate and complete, all of mig_save_device_dirty is run with the lock taken. In the savevm case, the iterate callback runs within the big lock. This is annoying because it complicates the rules. Luckily we do not need to do anything about it: the RAM iterate callback does not need the iothread lock, and block migration never runs during savevm. Reviewed-by:
Orit Wasserman <owasserm@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
- 22 Feb, 2013 1 commit
-
-
Juan Quintela authored
We removed the calculation in commit e4ed1541 Now we add it back. We need to create dirty_bytes_rate because we can't include cpu-all.h from migration.c, and there is no other way to include TARGET_PAGE_SIZE. Signed-off-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Orit Wasserman <owasserm@redhat.com>
-
- 01 Feb, 2013 1 commit
-
-
Orit Wasserman authored
Before this fix we couldn't load a guest from XBZRLE compressed file. For example: The user activated the XBZRLE capability The user run migrate -d "exec:gzip -c > vm.gz" The user won't be able to load vm.gz and get an error. Signed-off-by:
Orit Wasserman <owasserm@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
- 17 Jan, 2013 2 commits
-
-
Paolo Bonzini authored
Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Reviewed-by: Eric Blake <eblake@redhat.com>
-
Paolo Bonzini authored
Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Reviewed-by: Eric Blake <eblake@redhat.com>
-
- 20 Dec, 2012 13 commits
-
-
Juan Quintela authored
It could only return 0 if we only found dirty xbzrle pages that hadn't changed (i.e. they were written with the same content). We don't care about that case, it is the same than nothing dirty. So now the return of the function is how much have it written, nothing else. Adjust callers. And we also made ram_save_iterate() return the number of transferred bytes, not the number of transferred pages. Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Juan Quintela authored
Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Juan Quintela authored
Instead of testing each page individually, we search what is the next dirty page with a bitmap operation. We have to reorganize the code to move from a "for" loop, to a while(dirty) loop. Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Juan Quintela authored
This avoids having to do two walks over the dirty bitmap, once reading the dirty bits, and anthoer cleaning them. Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Juan Quintela authored
This is the last block from where we have sent data. Signed-off-by:
Orit Wasserman <owasserm@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Juan Quintela authored
Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Juan Quintela authored
Code just now does (simplified for clarity) if (qemu_savevm_state_iterate(s->file) == 1) { vm_stop_force_state(RUN_STATE_FINISH_MIGRATE); qemu_savevm_state_complete(s->file); } Problem here is that qemu_savevm_state_iterate() returns 1 when it knows that remaining memory to sent takes less than max downtime. But this means that we could end spending 2x max_downtime, one downtime in qemu_savevm_iterate, and the other in qemu_savevm_state_complete. Changed code to: pending_size = qemu_savevm_state_pending(s->file, max_size); DPRINTF("pending size %lu max %lu\n", pending_size, max_size); if (pending_size >= max_size) { ret = qemu_savevm_state_iterate(s->file); } else { vm_stop_force_state(RUN_STATE_FINISH_MIGRATE); qemu_savevm_state_complete(s->file); } So what we do is: at current network speed, we calculate the maximum number of bytes we can sent: max_size. Then we ask every save_live section how much they have pending. If they are less than max_size, we move to complete phase, otherwise we do an iterate one. This makes things much simpler, because now individual sections don't have to caluclate the bandwidth (it was implossible to do right from there). Signed-off-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Umesh Deshpande authored
Add the new mutex that protects shared state between ram_save_live and the iothread. If the iothread mutex has to be taken together with the ramlist mutex, the iothread shall always be _outside_. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Umesh Deshpande <udeshpan@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Orit Wasserman <owasserm@redhat.com>
-
Umesh Deshpande authored
This will be used to detect if last_block might have become invalid across different calls to ram_save_live. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Umesh Deshpande <udeshpan@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Orit Wasserman <owasserm@redhat.com>
-
Paolo Bonzini authored
Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Paolo Bonzini authored
Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Paolo Bonzini authored
Most of the time, only 2 items will be active (from/to for a string operation, or code/data). But TCG guests likely won't have gigabytes of memory, so this actually goes down to 1 item. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Paolo Bonzini authored
Cc: qemu-stable@nongnu.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
- 19 Dec, 2012 7 commits
-
-
Paolo Bonzini authored
Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
Various header files rely on qemu-char.h including qemu-config.h or main-loop.h, but they really do not need qemu-char.h at all (particularly interesting is the case of the block layer!). Clean this up, and also add missing inclusions of qemu-char.h itself. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- 17 Dec, 2012 1 commit
-
-
Michael S. Tsirkin authored
update all users so we can remove the makefile hack. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com>
-
- 12 Dec, 2012 2 commits
-
-
David Gibson authored
madvise(DONTNEED) will throw away the contents of the whole page at the given address, even if the given length is less than the page size. One can argue about whether that's the correct behaviour, but that's what it's done for a long time in Linux at least. That means that the madvise() in ram_load(), on a setup where TARGET_PAGE_SIZE is smaller than the host page size, can throw away data in guest pages adjacent to the one it's actually processing right now, leading to guest memory corruption on an incoming migration. This patch therefore, disables the madvise() if the host page size is larger than TARGET_PAGE_SIZE. This means we don't get the benefits of that madvise() in this case, but a more complete fix is more difficult to accomplish. This at least fixes the guest memory corruption. Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Reported-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
Anthony Liguori <aliguori@us.ibm.com>
-
David Gibson authored
The code for migrating (or savevm-ing) memory pages starts off by creating a dirty bitmap and filling it with 1s. Except, actually, because bit addresses are 0-based it fills every bit except bit 0 with 1s and puts an extra 1 beyond the end of the bitmap, potentially corrupting unrelated memory. Oops. This patch fixes it. Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
Anthony Liguori <aliguori@us.ibm.com>
-
- 17 Oct, 2012 10 commits
-
-
Juan Quintela authored
It indicates how many pages were dirtied during the last second. Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Juan Quintela authored
This patch creates a migration bitmap, which is periodically kept in sync with the qemu bitmap. A separate copy of the dirty bitmap for the migration limits the amount of concurrent access to the qemu bitmap from iothread and migration thread (which requires taking the big lock). We use the qemu bitmap type. We have to "undo" the dirty_pages counting optimization on the general dirty bitmap and do the counting optimization with the migration local bitmap. Signed-off-by:
Umesh Deshpande <udeshpan@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Juan Quintela authored
Signed-off-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Juan Quintela authored
Helper that we use each time that we need to syncronize the migration bitmap with the other dirty bitmaps. Signed-off-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Juan Quintela authored
It just test if the dirty bit is set, and clears it. Signed-off-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Reviewed-by:
Orit Wasserman <owasserm@redhat.com>
-
Juan Quintela authored
It just marks a region of memory as dirty. Signed-off-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Reviewed-by:
Orit Wasserman <owasserm@redhat.com>
-
Juan Quintela authored
Signed-off-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Reviewed-by:
Orit Wasserman <owasserm@redhat.com>
-
Juan Quintela authored
Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Juan Quintela authored
Signed-off-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Reviewed-by:
Orit Wasserman <owasserm@redhat.com>
-
Juan Quintela authored
Signed-off-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- 21 Sep, 2012 1 commit
-
-
Eduardo Habkost authored
This file is not needed anymore, as QEMU won't ship any config-based cpudefs out of the box, relying only on the builtin CPU models. Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com> Reviewed-by:
Igor Mammedov <imammedo@redhat.com> Signed-off-by:
Andreas Färber <afaerber@suse.de>
-